azure vnc控制台
Depending on our design and security, we can create functions or use built-in tools to control our Azure costs. In some contexts, we may look at the overall cost of what tools we’re using, which the Azure portal conveniently shows. Applying what we’ve looked at on the organization and development level, we can organize resources on their design (or ad hoc, as we’ll see) along with creating scripts that control our scale for situations where we may want higher or lower scale. We’ll look at both of these scenarios and how they can help us in both organization and development contexts.
根据我们的设计和安全性，我们可以创建功能或使用内置工具来控制Azure成本。 在某些情况下，我们可能会查看Azure门户方便显示的正在使用的工具的总体成本。 应用我们在组织和开发级别上所研究的内容，我们可以在其设计（或特设 ，如下所示）上组织资源，并创建脚本来控制我们的规模，以适应可能需要更高或更低规模的情况。 我们将研究这两种情况，以及它们如何在组织和开发环境中为我们提供帮助。
实践场景 (Scenarios in Practice)
We’ll design example scripts for the below scenarios relating to Azure costs that I’ve seen both on the development and organizational level:
我们将针对以下与Azure成本相关的方案设计示例脚本，我已经在开发和组织级别上看到了这些脚本：
- Developers scale up a resource for a test (functional, performance, or penetration) and complete the test, but forget to scale down the resource when complete. For this, we’ll look at wrapping scripts that increase scale for testing by using a step in our testing which increases scale (if necessary), then decreases it when the testing is finished and validated 开发人员按比例增加测试资源（功能，性能或渗透性）并完成测试，但是忘记完成时按比例缩小资源。 为此，我们将研究包装脚本，该脚本通过在测试中使用一个步骤来增加测试的规模，该步骤增加了规模（如有必要），然后在测试完成并验证后减小规模
- We create Azure resources managed by teams and organized by the teams and the applications the teams are developing. In addition to handling changes or multiple teams (or applications), we look at organizing what we currently have by these teams through adding or updating details and look at getting these tags in the portal 我们创建由团队管理，由团队和团队正在开发的应用程序组织的Azure资源。 除了处理变更或多个团队（或应用程序）之外，我们还将研究通过添加或更新详细信息来组织这些团队目前拥有的东西，并研究如何在门户网站中获取这些标签。
扩展测试 (Scaling for Testing)
In environments where we run tests in our Azure resources that involve functional, security and performance, developers may increase the scale of resources to validate their tests quickly and move forward with development. We can rely on developers increasing and decreasing scale, but this is error prone and allows for forgetfulness that may result in high Azure costs. A superior approach is to add steps to our testing to increase scale before the tests are run and decrease scale after the tests are run.
在我们在涉及功能，安全性和性能的Azure资源中运行测试的环境中，开发人员可能会增加资源规模以快速验证其测试并继续进行开发。 我们可以依靠开发人员增加和减少规模，但这容易出错，并且容易遗忘，可能导致高昂的Azure成本。 一种更好的方法是在测试中增加步骤，以在测试运行之前增加规模，并在测试运行之后降低规模。
For the sake of our example, we’ll assume that all our testing includes functional, penetration (security) and performance. In the below steps, we’ll increase the scale of our Azure SQL database prior to running unit tests to S0 from the Basic Tier and following the tests, we’ll decrease the scale to Basic. This technique can be adapted regardless of our tiers, such as scaling from S2 to S3 and scaling back down to S2 or any other scales.
为了我们的示例，我们假定所有测试都包括功能，渗透（安全）和性能。 在以下步骤中，在将单元测试从基本层运行到S0之前，我们将增加Azure SQL数据库的规模，然后在测试之后，将规模减小到基本。 无论我们使用哪种级别，例如从S2缩放到S3并缩小到S2或任何其他比例，都可以采用此技术。
The below code will require the AzureRM module (in the first line we install this and this installation can be done in a separate script window). If our execution policy is set to restricted, we’ll need to set this to unrestricted (see in the below script) – this part of the script is not required if we’re already set at unrestricted. After we’re done installing the AzureRM module, we will import the profile module and login to our testing account – we will do this according to our Azure authentication setup (credentialed, MFA, certificate, etc). At the end of the script, we set our execution policy back to restricted – in general, this is good practice.
下面的代码将需要AzureRM模块（在第一行中，我们安装了该模块，并且可以在单独的脚本窗口中完成此安装）。 如果执行策略设置为受限，则需要将其设置为非受限（请参见下面的脚本）–如果我们已经设置为非受限，则不需要脚本的这一部分。 完成安装AzureRM模块后，我们将导入配置文件模块并登录到我们的测试帐户-我们将根据Azure身份验证设置（凭据，MFA，证书等）进行此操作。 在脚本的最后，我们将执行策略重新设置为“受限” –通常，这是一种好习惯。
### Run in another script window - required module
Install-Module -Name AzureRM -AllowClobber ###admin execution needed
### Notice that once we're finished, we restrict this
Set-ExecutionPolicy unrestricted
Import-Module AzureRM.profile
Login-AzureRmAccount
Set-AzureRmSqlDatabase -ResourceGroupName "ourResourceGroup" `
-ServerName "hlthserver" `
-DatabaseName "hlthdev" `
-Edition "Standard" `
-RequestedServiceObjectiveName "S0"
Set-ExecutionPolicy restricted
As we see, we scale up our Basic Azure SQL database to the lowest Standard tier – S0 in this case – which will increase our Azure cost, but also increase resources for our testing, such as functional, performance and penetration testing. Depending on the intensity of our testing, we may scale to a higher version, especially if this reduces the time of testing and allows us to develop faster. We can take this same script following our validation and reverse it by scaling down to Basic again. For instance, the below code reverses our increased scale after our testing has completed.
如我们所见，我们将基本Azure SQL数据库扩展到最低的标准层（在这种情况下为S0），这将增加Azure成本，但同时也会增加用于测试（例如功能，性能和渗透测试）的资源。 根据测试的强度，我们可以扩展到更高的版本，尤其是如果这可以减少测试时间并允许我们更快地发展。 验证后，我们可以使用相同的脚本，并通过再次缩小到“基本”来反转它。 例如，下面的代码在测试完成后可以逆转我们增加的规模。
Set-ExecutionPolicy unrestricted
Import-Module AzureRM.profile
Login-AzureRmAccount
Set-AzureRmSqlDatabase -ResourceGroupName "ourResourceGroup" `
-ServerName "hlthserver" `
-DatabaseName "hlthdev" `
-Edition "Basic"
Set-ExecutionPolicy restricted
It’s possible that we want to use the same scale in our tests or in a few tests only, if we demarcate our tests by their purpose (like performance tests or penetration testing, both of which can be resource intensive). Likewise, we may run functional tests frequently, whereas other testing, like penetration testing, we may run less frequent.
如果我们按测试的目的（例如性能测试或渗透测试，这两者都可能占用大量资源）来划分测试的范围，则可能只想在测试中使用相同的比例，或者仅在几个测试中使用相同的比例。 同样，我们可能会频繁运行功能测试，而其他测试（例如渗透测试）可能会运行频率较低。
In both time-based use and testing, these are two areas where we can use scale to our advantage in the cloud – both involve periods of time where we expect to see users (clients or developers) to use significant resources. Outside of these periods, we should keep our scale to its lowest required state to reduce Azure costs.
在基于时间的使用和测试中，这都是我们可以在云中利用规模优势的两个方面–都涉及到一段时间，我们希望看到用户（客户或开发人员）使用大量资源。 在这些时间段之外，我们应该将规模保持在最低要求，以降低Azure成本。
通过Azure标记进行组织 (Organization Through Azure Tagging)
One feature that we can use in Azure involves tags. Let’s consider a scenario where we have five teams (Team One through Five) that own assets in Azure in the form of development responsibility and testing. These teams develop the assets, test them, and improve based on the feedback from testing. In design of the assets, we want our Azure assets to be organized by team so that we can identify Azure costs, but this is not always the case, so we’ll look at developing a script that we can use to update existing assets with our team organization.
我们可以在Azure中使用的一项功能涉及标签。 让我们考虑一个场景，我们有五个团队（团队一到五个）以开发责任和测试的形式拥有Azure中的资产。 这些团队根据测试的反馈来开发资产，对其进行测试并进行改进。 在资产设计中，我们希望我们的Azure资产由团队进行组织，以便我们可以确定Azure成本，但这并非总是如此，因此，我们将研究开发可用于更新现有资产的脚本。我们的团队组织。
As we’ll see, we can update an Azure resource by using tags that operate with a key-value format. In our example, we’ll use two keys – team and application partition (apppartition in the script). The value of the team will be Team 2 and the apppartition will be ETL-ETH. The reason that we do this from an organization standpoint is that it’s possible an application has multiple teams working on it, though the asset may be different. For monitoring Azure costs, we may track parts of an application separately (database versus application) – though in this example, we’ll keep it in the same tag. Think of an example where we have a database team working on an Azure SQL database and an application team working on an App Service for the same application. Depending on how our organization works, we want to be flexible with how we tag our resources – though as we’ll see, we can update these resources with scripts.
正如我们将看到的，我们可以通过使用以键值格式操作的标签来更新Azure资源。 在我们的示例中，我们将使用两个键-team和应用程序分区（脚本中的apppartition）。 该团队的价值将是第2团队，而分配则是ETL-ETH。 从组织的角度来看，这样做的原因是，尽管资产可能不同，但一个应用程序可能有多个团队在工作。 为了监视Azure成本，我们可以分别跟踪应用程序的各个部分（数据库还是应用程序）–尽管在此示例中，我们将其保留在同一标签中。 以一个示例为例，我们有一个数据库团队在一个Azure SQL数据库上工作，而一个应用程序团队在为同一应用程序提供App Service。 根据组织的工作方式，我们希望对资源的标记方式保持灵活性-尽管我们将看到，我们可以使用脚本来更新这些资源。
Set-ExecutionPolicy unrestricted
Import-Module AzureRM.profile
Login-AzureRmAccount
Select-AzureRmSubscription "ourSubscriptionName" | Out-Null
$addtags = (Get-AzureRmResource -ResourceName "hlthserver/hlthdev" -ResourceGroupName "ourResourceGroup")
Set-AzureRmResource -ResourceId $addtags.ResourceId -Tag @{ team="Team 2"; apppartition="ETL-ETH"} -Force
Set-ExecutionPolicy restricted
What about multiple values for the same key? Suppose that we wanted our Azure SQL Database to have Team 2 and Team 4? In the below script, we use both of these values in the team key.
相同键的多个值呢？ 假设我们希望我们的Azure SQL数据库具有Team 2和Team 4？ 在下面的脚本中，我们在团队密钥中使用这两个值。
Set-ExecutionPolicy unrestricted
Import-Module AzureRM.profile
Login-AzureRmAccount
Select-AzureRmSubscription "ourSubscriptionName" | Out-Null
$addtags = (Get-AzureRmResource -ResourceName "hlthserver/hlthdev" -ResourceGroupName "ourResourceGroup")
Set-AzureRmResource -ResourceId $addtags.ResourceId -Tag @{ team="Team 2, Team 4"; apppartition="ETL-ETH"} -Force
Set-ExecutionPolicy restricted
With tagging, we can also use the Azure portal to add a tag to a resource, which we’ll do for our preproduction database as seen in the below image (click save):
通过标记，我们还可以使用Azure门户向资源添加标记，如下图所示，我们将对预生产数据库进行标记（单击保存）：
Now, when we go to the Azure portal’s home and look under tags, we can filter by the tags that have Team 4 – and as we see, two tags have this – one is a shared tag, the other is the individual tag.
现在，当我们转到Azure门户的主页并在标签下查看时，我们可以按具有Team 4的标签进行过滤-正如我们看到的，两个标签都具有此标签-一个是共享标签，另一个是单个标签。
For tracking Azure costs, these examples help show why organization matters in situations where we may have multiple applications and teams. We should still expect some organization to change in time – such as the change of an application being shared by two teams from one team, so it’s helpful to know that we can update these tags to match our organization. For some organizations, such as startups, we may have very few assets or only one team and we can tag as necessary – if necessary. We also have the alternative in these smaller situations to group our assets by subscription – such as different subscriptions for different applications. As we have more assets, tags offer us a feature that we can use to organize our development.
为了跟踪Azure成本，这些示例有助于说明为什么在我们可能有多个应用程序和团队的情况下组织如此重要。 我们仍然应该期望某个组织会及时更改-例如，一个团队的两个团队共享一个应用程序的更改，因此了解我们可以更新这些标签以匹配我们的组织会很有帮助。 对于某些组织（如初创公司），我们可能只有很少的资产或只有一个团队，并且可以根据需要进行标记-必要时。 在较小的情况下，我们还可以选择按订阅对资产进行分组-例如针对不同应用程序的不同订阅。 随着我们拥有更多的资产，标签为我们提供了一项功能，可用于组织我们的开发。
结论 (Conclusion)
As we’ve seen, we can use some automation techniques to limit a range of possible issues related to Azure costs growing. In some cases, if we increase the scale of a resource for a temporary purpose, we have the option to immediately scale the same resource down when the temporary purpose completes. Testing provides a great example of this and we could also apply this same logic in scenarios where we expect a large amount of traffic over a time period. For organization of teams, we can use Azure’s tagging feature – and as we see, we can use this feature with shared teams or individual teams. Even if we don’t use it initially, we can add these tags ad hoc with scripts to organize our resources to find weaknesses for improvement.
如我们所见，我们可以使用一些自动化技术来限制与Azure成本增长相关的一系列可能问题。 在某些情况下，如果我们出于临时目的增加资源的规模，则可以选择在临时目的完成后立即将同一资源缩减。 测试提供了一个很好的例子，我们也可以在预计一段时间内会有大量流量的场景中应用相同的逻辑。 对于团队的组织，我们可以使用Azure的标记功能-并且如我们所见，我们可以将此功能用于共享团队或单个团队。 即使我们一开始不使用它，我们也可以在脚本中临时添加这些标签，以组织我们的资源以发现有待改进的地方。
目录 (Table of contents)
| 具有安全性和设计注意事项的Azure成本跟踪 |
| 使用扩展和标签控制Azure成本 |
| 用户安全和Azure成本风险 |
| 使用PowerShell提取Azure成本 |
| 通过成本管理跟踪Azure成本 |
| 处理影响Azure成本的未使用和不必要的资源 |
| 查找影响Azure成本的未使用资源 |
| 我们可能需要更高的Azure成本的情况 |
翻译自: https://www.sqlshack.com/controlling-azure-costs-using-scaling-and-tags/
azure vnc控制台
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
