您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

自动缩放最佳实践Best practices for Autoscale

Azure Monitor 自动缩放仅适用于虚拟机规模集云服务应用服务 - Web 应用API 管理服务Azure Monitor autoscale applies only to Virtual Machine Scale Sets, Cloud Services, App Service - Web Apps, and API Management services.

自动缩放概念Autoscale concepts

  • 一个资源只能具有一个自动缩放设置A resource can have only one autoscale setting
  • 自动缩放设置可以具有一个或多个配置文件,每个配置文件可以具有一个或多个自动缩放规则。An autoscale setting can have one or more profiles and each profile can have one or more autoscale rules.
  • 自动缩放设置可水平缩放实例,它在增加实例时是扩大,在减少实例数时是缩小An autoscale setting scales instances horizontally, which is out by increasing the instances and in by decreasing the number of instances. 自动缩放设置具有最大、最小和默认实例值。An autoscale setting has a maximum, minimum, and default value of instances.
  • 自动缩放作业始终读取要作为缩放依据的关联指标,检查它是否超过针对扩大或缩小配置的阈值。An autoscale job always reads the associated metric to scale by, checking if it has crossed the configured threshold for scale-out or scale-in. 可以在 Azure 监视器自动缩放常用指标查看可以作为自动缩放依据的指标列表。You can view a list of metrics that autoscale can scale by at Azure Monitor autoscaling common metrics.
  • 所有阈值都在实例级别进行计算。All thresholds are calculated at an instance level. 例如,“如果实例计数为 2,则在平均 CPU > 80% 时横向扩展增加 1 个实例”表示在所有实例间的平均 CPU 大于 80% 时进行扩大。For example, "scale out by one instance when average CPU > 80% when instance count is 2", means scale-out when the average CPU across all instances is greater than 80%.
  • 所有自动缩放失败都会记录到活动日志中。All autoscale failures are logged to the Activity Log. 然后可以配置活动日志警报,以便在自动缩放失败时通过电子邮件、短信或 Webhook 获得通知。You can then configure an activity log alert so that you can be notified via email, SMS, or webhooks whenever there is an autoscale failure.
  • 同样,所有成功的缩放操作也会发布到活动日志中。Similarly, all successful scale actions are posted to the Activity Log. 然后可以配置活动日志警报,以便在自动缩放操作成功时通过电子邮件、短信或 Webhook 获得通知。You can then configure an activity log alert so that you can be notified via email, SMS, or webhooks whenever there is a successful autoscale action. 还可以配置电子邮件或 Webhook 通知,以通过自动缩放设置上的通知选项卡获取有关成功缩放操作的通知。You can also configure email or webhook notifications to get notified for successful scale actions via the notifications tab on the autoscale setting.

自动缩放最佳做法Autoscale best practices

使用自动缩放时,可使用以下最佳做法。Use the following best practices as you use autoscale.

确保最大和最小值不同,并且它们之间具有足够的余量Ensure the maximum and minimum values are different and have an adequate margin between them

如果设置的最小值为 2,最大值为 2,并且当前实例计数为 2,则不可能进行缩放操作。If you have a setting that has minimum=2, maximum=2 and the current instance count is 2, no scale action can occur. 在最大和最小实例计数之间保留足够的余量(包括端值)。Keep an adequate margin between the maximum and minimum instance counts, which are inclusive. 自动缩放始终在这些限制之间进行。Autoscale always scales between these limits.

手动缩放通过自动缩放最小和最大值来重置Manual scaling is reset by autoscale min and max

如果手动将实例计数更新为高于或低于最大值的值,则自动缩放引擎会自动缩放回最小值(如果低于)或最大值(如果高于)。If you manually update the instance count to a value above or below the maximum, the autoscale engine automatically scales back to the minimum (if below) or the maximum (if above). 例如,将范围设置在 3 和 6 之间。For example, you set the range between 3 and 6. 如果有一个正在运行的实例,则自动缩放引擎会在下次运行时缩放为三个实例。If you have one running instance, the autoscale engine scales to three instances on its next run. 同样,如果将缩放规模手动设置为八个实例,则自动缩放会在下次运行时收缩回六个实例。Likewise, if you manually set the scale to eight instances, on the next run autoscale will scale it back to six instances on its next run. 手动缩放效果只是暂时的,除非也重置了自动缩放规则。Manual scaling is temporary unless you reset the autoscale rules as well.

始终使用执行增加和减少的扩大和缩小规则组合Always use a scale-out and scale-in rule combination that performs an increase and decrease

如果仅使用组合的一个部件,则自动缩放将仅在单个方向采取操作(横向扩展或收缩),直至它达到配置文件中定义的最大或最小实例计数。If you use only one part of the combination, autoscale will only take action in a single direction (scale out, or in) until it reaches the maximum, or minimum instance counts of defined in the profile. 这不是最佳的,理想情况下,你希望资源在使用率过高时纵向扩展以确保可用性。This is not optimal, ideally you want your resource to scale up at times of high usage to ensure availability. 同样,当使用率过低时,你希望资源纵向收缩,以便可以实现成本节省。Similarly, at times of low usage you want your resource to scale down, so you can realize cost savings.

为诊断指标选择相应统计信息Choose the appropriate statistic for your diagnostics metric

对于诊断指标,可以选择“平均值”、“最小值”、“最大值”** 和“总计”** 作为用作缩放依据的指标。For diagnostics metrics, you can choose among Average, Minimum, Maximum and Total as a metric to scale by. 最常见的统计信息是“平均值”**。The most common statistic is Average.

认真为所有指标类型选择阈值Choose the thresholds carefully for all metric types

我们建议基于实际情况为扩大和缩小认真选择不同阈值。We recommend carefully choosing different thresholds for scale-out and scale-in based on practical situations.

我们建议不要使用如同以下示例的自动缩放设置,其中针对扩大和缩小条件的阈值相同或相似**:We do not recommend autoscale settings like the examples below with the same or similar threshold values for out and in conditions:

  • 当线程计数 >= 600 时,按 1 计数增加实例Increase instances by 1 count when Thread Count >= 600
  • 当线程计数 <= 600 时,按 1 计数减少实例Decrease instances by 1 count when Thread Count <= 600

让我们看一下可能会导致看起来令人困惑的行为的示例。Let's look at an example of what can lead to a behavior that may seem confusing. 考虑以下序列。Consider the following sequence.

  1. 假设开始时有两个实例,随后每个实例的平均线程数增长到 625。Assume there are two instances to begin with and then the average number of threads per instance grows to 625.
  2. 自动缩放会通过添加第三个实例进行横向扩展。Autoscale scales out adding a third instance.
  3. 接下来,假定实例间的平均线程数下降到 575。Next, assume that the average thread count across instance falls to 575.
  4. 进行减少之前,自动缩放会尝试估计缩小后的最终状态。Before scaling down, autoscale tries to estimate what the final state will be if it scaled in. 例如,575 x 3(当前实例计数)= 1,725/2(减少后的最终实例数)= 862.5 个线程。For example, 575 x 3 (current instance count) = 1,725 / 2 (final number of instances when scaled down) = 862.5 threads. 这意味着如果平均线程计数保持不变,甚至只是略有下降,自动缩放就必须立即再次扩大(即使是在缩小后)。This means autoscale would have to immediately scale out again even after it scaled in, if the average thread count remains the same or even falls only a small amount. 但是,如果它再次增加,则整个过程会重复,从而导致无限循环。However, if it scaled up again, the whole process would repeat, leading to an infinite loop.
  5. 为了避免这种情况(称之为“波动”),自动缩放根本不会减少。To avoid this situation (termed "flapping"), autoscale does not scale down at all. 相反,它会跳过,并在服务作业下次执行时再次重新评估条件。Instead, it skips and reevaluates the condition again the next time the service's job executes. 这种摇摆状态可能会使许多人感到困惑,因为在平均线程计数是 575 时,自动缩放似乎未起作用。The flapping state can confuse many people because autoscale wouldn't appear to work when the average thread count was 575.

在缩减期间进行评估的目的是避免“反复”情况:缩减和扩展操作不断交替。Estimation during a scale-in is intended to avoid "flapping" situations, where scale-in and scale-out actions continually go back and forth. 为扩展和缩减选择相同阈值时,请记住此行为。Keep this behavior in mind when you choose the same thresholds for scale-out and in.

我们建议在扩大与缩小阈值之间选择足够的余量。We recommend choosing an adequate margin between the scale-out and in thresholds. 作为示例,请考虑以下更好的规则组合。As an example, consider the following better rule combination.

  • 当 CPU% >= 80 时,按 1 计数增加实例Increase instances by 1 count when CPU% >= 80
  • 当 CPU% <= 60 时,按 1 计数减少实例Decrease instances by 1 count when CPU% <= 60

在这种情况下,In this case

  1. 假定开始有 2 个实例。Assume there are 2 instances to start with.
  2. 如果实例间的平均 CPU% 达到 80,则自动缩放会通过添加第三个实例来进行扩大。If the average CPU% across instances goes to 80, autoscale scales out adding a third instance.
  3. 现在假定随着时间的推移,CPU% 下降到 60。Now assume that over time the CPU% falls to 60.
  4. 自动缩放的缩小规则会估计缩小后的最终动态。Autoscale's scale-in rule estimates the final state if it were to scale-in. 例如,60 x 3(当前实例计数)= 180/2(减少后的最终实例数)= 90。For example, 60 x 3 (current instance count) = 180 / 2 (final number of instances when scaled down) = 90. 因此自动缩放不会缩小,因为它必须立即再次扩大。So autoscale does not scale-in because it would have to scale-out again immediately. 相反,它会跳过减少。Instead, it skips scaling down.
  5. 下次进行自动缩放检查时,CPU 会继续减少到 50。The next time autoscale checks, the CPU continues to fall to 50. 随后再次估计 - 50 x 3 个实例 = 150/2 个实例 = 75,这低于扩大阈值 80,因此可以成功缩小为 2 个实例。It estimates again - 50 x 3 instance = 150 / 2 instances = 75, which is below the scale-out threshold of 80, so it scales in successfully to 2 instances.

有关特殊指标的缩放阈值的注意事项Considerations for scaling threshold values for special metrics

对于特殊指标(如存储或服务总线队列长度指标),阈值是按照当前实例数可用的消息平均数。For special metrics such as Storage or Service Bus Queue length metric, the threshold is the average number of messages available per current number of instances. 请慎重选择此指标的阈值。Carefully choose the threshold value for this metric.

我们来通过一个示例演示它,以确保更好地了解行为。Let's illustrate it with an example to ensure you understand the behavior better.

  • 当存储队列消息计数 >= 50 时,按 1 计数增加实例Increase instances by 1 count when Storage Queue message count >= 50
  • 当存储队列消息计数 <= 10 时,按 1 计数减少实例Decrease instances by 1 count when Storage Queue message count <= 10

考虑以下序列:Consider the following sequence:

  1. 有两个存储队列实例。There are two storage queue instances.
  2. 消息不断传入,而检查存储队列时,总计数达到 50。Messages keep coming and when you review the storage queue, the total count reads 50. 可能认为自动缩放应启动扩大操作。You might assume that autoscale should start a scale-out action. 但请注意,它仍是 50/2 = 25 个消息/实例。However, note that it is still 50/2 = 25 messages per instance. 因此,不会进行扩大。So, scale-out does not occur. 要进行第一次扩大,存储队列中的总消息计数应是 100。For the first scale-out to happen, the total message count in the storage queue should be 100.
  3. 接下来,假定总消息计数达到 100。Next, assume that the total message count reaches 100.
  4. 此时会因为横向扩展操作而添加第三个存储队列实例。A third storage queue instance is added due to a scale-out action. 在队列中的总消息计数达到 150 之前,不会进行下一次扩大操作,因为 150/3 = 50。The next scale-out action will not happen until the total message count in the queue reaches 150 because 150/3 = 50.
  5. 现在队列中的消息数量变小。Now the number of messages in the queue gets smaller. 在有三个实例的情况下,当所有队列中的总消息数加起来达到 30 时,会进行第一缩小操作,因为 30/3 = 10 个消息/实例(这是缩小阈值)。With three instances, the first scale-in action happens when the total messages in all queues add up to 30 because 30/3 = 10 messages per instance, which is the scale-in threshold.

有关在自动缩放设置中配置多个配置文件时进行自动缩放的注意事项Considerations for scaling when multiple profiles are configured in an autoscale setting

在自动缩放设置中,可以选择默认配置文件(这会始终应用,对计划或时间没有任何依赖),也可以选择定期配置文件或用于具有日期和时间范围的固定期间的配置文件。In an autoscale setting, you can choose a default profile, which is always applied without any dependency on schedule or time, or you can choose a recurring profile or a profile for a fixed period with a date and time range.

当自动缩放服务处理它们时,它始终按照以下顺序进行检查:When autoscale service processes them, it always checks in the following order:

  1. 固定的日期配置文件Fixed Date profile
  2. 定期配置文件Recurring profile
  3. 默认(“始终”)配置文件Default ("Always") profile

如果满足配置文件条件,则自动缩放不会检查位于其下的下一个配置文件条件。If a profile condition is met, autoscale does not check the next profile condition below it. 自动缩放一次只处理一个配置文件。Autoscale only processes one profile at a time. 这意味着如果还要包括来自较低层配置文件的处理条件,则必须在当前配置文件中也包含这些规则。This means if you want to also include a processing condition from a lower-tier profile, you must include those rules as well in the current profile.

我们来看一个示例:Let's review using an example:

下图显示一个自动缩放设置,其默认配置文件的最小实例数 = 2,最大实例数 = 10。The image below shows an autoscale setting with a default profile of minimum instances = 2 and maximum instances = 10. 在此示例中,规则配置为在队列中的消息计数大于 10 时进行横向扩展,在队列中的消息计数小于 3 时进行缩小。In this example, rules are configured to scale out when the message count in the queue is greater than 10 and scale-in when the message count in the queue is less than three. 因此,现在资源可以在 2 到 10 个实例之间进行缩放。So now the resource can scale between two and ten instances.

此外,为星期一设置了定期配置文件。In addition, there is a recurring profile set for Monday. 它设置为最小实例数 = 3,并且最大实例数 = 10。It is set for minimum instances = 3 and maximum instances = 10. 这意味着在星期一,自动缩放首次检查此条件时,如果实例计数是 2,则它缩放为新的最小值 3。This means on Monday, the first-time autoscale checks for this condition, if the instance count is two, it scales to the new minimum of three. 只要自动缩放继续发现匹配此配置文件条件(星期一),它便只处理为此配置文件配置的基于 CPU 的扩大/缩小规则。As long as autoscale continues to find this profile condition matched (Monday), it only processes the CPU-based scale-out/in rules configured for this profile. 此时,它不会检查队列长度。At this time, it does not check for the queue length. 但是,如果还要检查队列长度条件,则应在星期一配置文件中也包括默认配置文件中的那些规则。However, if you also want the queue length condition to be checked, you should include those rules from the default profile as well in your Monday profile.

同样,当自动缩放切换回默认配置文件时,它会首先检查是否符合最小值和最大值条件。Similarly, when autoscale switches back to the default profile, it first checks if the minimum and maximum conditions are met. 如果当时的实例数是 12,则它会缩小为 10(默认配置文件允许的最大值)。If the number of instances at the time is 12, it scales in to 10, the maximum allowed for the default profile.

自动缩放设置

有关在配置文件中配置多个规则时进行自动缩放的注意事项Considerations for scaling when multiple rules are configured in a profile

在某些情况下可能必须在一个配置文件中设置多个规则。There are cases where you may have to set multiple rules in a profile. 自动缩放引擎在设置多个规则时使用以下自动缩放规则。The following autoscale rules are used by the autoscale engine when multiple rules are set.

进行横向扩展时,只要满足任一规则,自动缩放就会运行**。On scale-out, autoscale runs if any rule is met. 进行缩小** 时,自动缩放需要满足所有规则。On scale-in, autoscale require all rules to be met.

为了进一步说明,假定你具有以下 4 个自动缩放规则:To illustrate, assume that you have the following four autoscale rules:

  • 如果 CPU < 30%,则减少 1 个If CPU < 30%, scale-in by 1
  • 如果内存 < 50%,则减少 1 个If Memory < 50%, scale-in by 1
  • 如果 CPU > 75 %,则增加 1 个If CPU > 75%, scale-out by 1
  • 如果内存 > 75%,则增加 1 个If Memory > 75%, scale-out by 1

随后发生以下事件:Then the follow occurs:

  • 如果 CPU 是 76% 且内存是 50%,则我们会进行扩大。If CPU is 76% and Memory is 50%, we scale out.
  • 如果 CPU 是 50% 且内存是 76%,我们会进行横向扩展。If CPU is 50% and Memory is 76%, we scale out.

另一方面,如果 CPU 是 25% 且内存是 51%,则自动缩放不会缩小。On the other hand, if CPU is 25% and memory is 51% autoscale does not scale-in. 要进行缩小,CPU 必须是 29% 且内存是 49%。In order to scale-in, CPU must be 29% and Memory 49%.

始终选择安全的默认实例计数Always select a safe default instance count

默认实例计数很重要,因为自动缩放将服务缩放到指标不可用时的计数。The default instance count is important because autoscale scales your service to that count when metrics are not available. 因此,请选择对工作负荷安全的默认实例计数。Therefore, select a default instance count that's safe for your workloads.

配置自动缩放通知Configure autoscale notifications

发生以下任何一种情况时,自动缩放会发布至活动日志:Autoscale will post to the Activity Log if any of the following conditions occur:

  • 自动缩放将发出缩放操作。Autoscale issues a scale operation.
  • 自动缩放服务成功完成缩放操作。Autoscale service successfully completes a scale action.
  • 自动缩放服务未能执行缩放操作。Autoscale service fails to take a scale action.
  • 自动缩放服务无法使用指标进行缩放决策。Metrics are not available for autoscale service to make a scale decision.
  • 指标再次可用(恢复)于进行缩放决策。Metrics are available (recovery) again to make a scale decision.

还可以使用活动日志警报监视自动缩放引擎的运行状况。You can also use an Activity Log alert to monitor the health of the autoscale engine. 下面举例说明如何创建活动日志警报以监视订阅上的所有自动缩放引擎操作创建活动日志警报以监视订阅上所有失败的自动缩放缩小/扩大操作Here are examples to create an Activity Log Alert to monitor all autoscale engine operations on your subscription or to create an Activity Log Alert to monitor all failed autoscale scale in/scale out operations on your subscription.

除了使用活动日志警报以外,还可以配置电子邮件或 Webhook 通知,以通过自动缩放设置上的通知选项卡获取有关成功缩放操作的通知。In addition to using activity log alerts, you can also configure email or webhook notifications to get notified for successful scale actions via the notifications tab on the autoscale setting.

后续步骤Next Steps