Azure 中的自动缩放入门Get started with Autoscale in Azure

本文介绍如何在 Azure 门户中为资源指定自动缩放设置。This article describes how to set up your Autoscale settings for your resource in the Azure portal.

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

了解订阅中的自动缩放设置Discover the Autoscale settings in your subscription

可在 Azure Monitor 中查找自动缩放功能适用的所有资源。You can discover all the resources for which Autoscale is applicable in Azure Monitor. 按下列步骤进行分步演练:Use the following steps for a step-by-step walkthrough:

  1. 打开 Azure 门户Open the Azure portal.
  2. 单击左窗格中的“Azure Monitor”图标。Click the Azure Monitor icon in the left pane. 打开 Azure MonitorOpen Azure Monitor
  3. 单击“自动缩放”以查看自动缩放适用的所有资源及其当前的自动缩放状态。Click Autoscale to view all the resources for which Autoscale is applicable, along with their current Autoscale status. 了解 Azure Monitor 中的自动缩放功能Discover Autoscale in Azure Monitor

可使用顶部的筛选器窗格缩小列表的范围,以选择特定资源组中的资源、特定的资源类型或特定资源。You can use the filter pane at the top to scope down the list to select resources in a specific resource group, specific resource types, or a specific resource.

对于每个资源,将会看到其当前实例计数和自动缩放状态。For each resource, you will find the current instance count and the Autoscale status. 自动缩放状态可以是:The Autoscale status can be:

  • 未配置:尚未对此资源启用自动缩放功能。Not configured: You have not enabled Autoscale yet for this resource.
  • 已启用:已对此资源启用自动缩放功能。Enabled: You have enabled Autoscale for this resource.
  • Disabled:已对此资源禁用自动缩放功能。Disabled: You have disabled Autoscale for this resource.

创建第一个自动缩放设置Create your first Autoscale setting

现在,让我们完成一个简单的分步演练,以创建第一个自动缩放设置。Let's now go through a simple step-by-step walkthrough to create your first Autoscale setting.

  1. 在 Azure Monitor 中打开“自动缩放”边栏选项卡,然后选择要缩放的资源。Open the Autoscale blade in Azure Monitor and select a resource that you want to scale. (以下步骤使用与某 Web 应用关联的应用服务计划。(The following steps use an App Service plan associated with a web app. 仅需 5 分钟,就可在 Azure 中创建首个 ASP.NET Web 应用。You can create your first ASP.NET web app in Azure in 5 minutes.)

  2. 请注意当前实例计数为 1。Note that the current instance count is 1. 单击“启用自动缩放”。Click Enable autoscale. 新 Web 应用的缩放设置Scale setting for new web app

  3. 提供缩放设置的名称,然后单击“添加规则”。Provide a name for the scale setting, and then click Add a rule. 请注意右侧以上下文窗格形式打开的缩放规则选项。Notice the scale rule options that open as a context pane on the right side. 默认情况下,这将选项设置为当资源的 CPU 百分比超过 70% 时,将实例计数缩放 1 个单位。By default, this sets the option to scale your instance count by 1 if the CPU percentage of the resource exceeds 70 percent. 请将此选项保留默认值,并单击“添加”。Leave it at its default values and click Add. 为 Web 应用创建缩放设置Create scale setting for a web app

  4. 现已创建第一个缩放规则。You've now created your first scale rule. 请注意,UX 建议了最佳做法,并指出“建议至少在规则中包含一个缩放设置”。Note that the UX recommends best practices and states that "It is recommended to have at least one scale in rule." 为此,请执行以下操作:To do so:

    a.a. 单击“添加规则”。Click Add a rule.

    b.b. 将“运算符”设置为“小于”。 Set Operator to Less than.

    c.c. 将“阈值”设置为 20。 Set Threshold to 20.

    d.d. 将“操作”设置为“按以下值递减计数”。 Set Operation to Decrease count by.

    现在应已创建一个可以根据 CPU 使用率进行扩展/缩减的缩放设置。You should now have a scale setting that scales out/scales in based on CPU usage. 基于 CPU 进行缩放Scale based on CPU

  5. 单击“保存” 。Click Save.

祝贺!Congratulations! 现已成功创建第一个缩放设置,用于根据 CPU 使用率自动缩放 Web 应用。You've now successfully created your first scale setting to autoscale your web app based on CPU usage.

备注

若要开始使用虚拟机规模集或云服务角色,才可采用相同步骤操作。The same steps are applicable to get started with a virtual machine scale set or cloud service role.

其他注意事项Other considerations

基于计划的缩放Scale based on a schedule

除了基于 CPU 进行缩放,还可设置为在特定的星期日期按其他方式缩放。In addition to scale based on CPU, you can set your scale differently for specific days of the week.

  1. 单击“添加缩放条件”。Click Add a scale condition.
  2. 缩放模式和规则的设置方式与默认条件的相同。Setting the scale mode and the rules is the same as the default condition.
  3. 为计划选择“重复特定的星期日期”。Select Repeat specific days for the schedule.
  4. 选择星期日期,以及需应用缩放条件的开始/结束时间。Select the days and the start/end time for when the scale condition should be applied.

基于计划的缩放条件

在特定的日期以不同的方式缩放Scale differently on specific dates

除了基于 CPU 进行缩放,还可设置为在特定日期按其他方式缩放。In addition to scale based on CPU, you can set your scale differently for specific dates.

  1. 单击“添加缩放条件”。Click Add a scale condition.
  2. 缩放模式和规则的设置方式与默认条件的相同。Setting the scale mode and the rules is the same as the default condition.
  3. 为计划选择“指定开始/结束日期”。Select Specify start/end dates for the schedule.
  4. 选择开始/结束日期,以及需应用缩放条件的开始/结束时间。Select the start/end dates and the start/end time for when the scale condition should be applied.

基于日期的缩放条件

查看资源的缩放历史记录View the scale history of your resource

每次增加或缩小资源后,都会在活动日志中记录一个事件。Whenever your resource is scaled up or down, an event is logged in the activity log. 切换到“运行历史记录”选项卡即可查看资源在过去 24 小时的缩放历史记录。You can view the scale history of your resource for the past 24 hours by switching to the Run history tab.

运行历史记录

若要查看完整的缩放历史记录(最长 90 天),请选择“单击此处查看更多详细信息”。If you want to view the complete scale history (for up to 90 days), select Click here to see more details. 随后将启动活动日志,其中包含已预先选择“自动缩放”的资源和类别。The activity log opens, with Autoscale pre-selected for your resource and category.

查看资源的缩放定义View the scale definition of your resource

“自动缩放”是一种 Azure 资源管理器资源。Autoscale is an Azure Resource Manager resource. 切换到“JSON”选项卡即可在 JSON 中查看缩放定义。You can view the scale definition in JSON by switching to the JSON tab.

缩放定义

如果需要,可以直接在 JSON 中进行更改。You can make changes in JSON directly, if required. 这些更改将在保存后生效。These changes will be reflected after you save them.

禁用“自动缩放”并手动缩放实例Disable Autoscale and manually scale your instances

有时,可能需要禁用当前的缩放设置并手动缩放资源。There might be times when you want to disable your current scale setting and manually scale your resource.

单击顶部的“禁用自动缩放”按钮。Click the Disable autoscale button at the top. 禁用自动缩放Disable Autoscale

备注

此选项将禁用你的配置。This option disables your configuration. 但是,再次启用“自动缩放”后,则可恢复此设置。However, you can get back to it after you enable Autoscale again.

现在,可手动设置要缩放到的实例数。You can now set the number of instances that you want to scale to manually.

设置手动缩放

始终可单击“启用自动缩放”,再单击“保存”来恢复自动缩放。 You can always return to Autoscale by clicking Enable autoscale and then Save.

将流量路由到正常运行的实例(应用服务)Route traffic to healthy instances (App Service)

横向扩展到多个实例时,应用服务可以对实例执行运行状况检查,以仅将流量路由到正常运行的实例。When you are scaled out to multiple instances, App Service can perform health checks on your instances to route traffic only to the healthy instances. 为此,请打开门户并转到应用服务,然后选择“监视”下的“运行状况检查” 。To do so, open the Portal to your App Service, then select Health check under Monitoring. 选择“启用”,然后在应用程序上提供有效的 URL 路径,例如 /health/api/healthSelect Enable and provide a valid URL path on your application, such as /health or /api/health. 单击“保存” 。Click Save.

若要在 ARM 模板中启用该功能,请将 Microsoft.Web/sites 资源的 healthcheckpath 属性设置为站点中的运行状况检查路径,例如:"/api/health/"To enable the feature with ARM templates, set the healthcheckpath property of the Microsoft.Web/sites resource to the health check path on your site, for example: "/api/health/". 若要禁用该功能,请将属性重新设置为空字符串 ""To disable the feature, set the property back to the empty string, "".

运行状况检查路径Health check path

路径必须在一分钟内响应,且状态码介于 200 到 299(含)之间。The path must respond within one minute with a status code between 200 and 299 (inclusive). 如果路径未在一分钟内响应,或返回范围之外的状态代码,则将该实例视为“运行不正常”。If the path does not respond within one minute, or returns a status code outside the range, then the instance is considered "unhealthy". 应用服务未遵循关于运行状况检查路径的 302 重定向。App Service does not follow 302 redirects on the health check path. 运行状况检查与应用服务的身份验证和授权功能集成,即使启用了这些安全功能,系统也将到达终结点。Health Check integrates with App Service's authentication and authorization features, the system will reach the endpoint even if these secuity features are enabled. 如果使用自己的身份验证系统,则必须允许匿名访问运行状况检查路径。If you are using your own authentication system, the health check path must allow anonymous access. 如果站点启用了“仅限 HTTPS”,则将通过 HTTPS 发送运行状况检查请求 。If the site has HTTP S-Only enabled, the healthcheck request will be sent via HTTP S.

运行状况检查路径应检查应用程序的关键组件。The health check path should check the critical components of your application. 例如,如果应用程序依赖于数据库和消息传递系统,则运行状况检查终结点应连接到这些组件。For example, if your application depends on a database and a messaging system, the health check endpoint should connect to those components. 如果应用程序无法连接到关键组件,则路径应返回介于 500 级别的响应代码,以指示应用运行不正常。If the application cannot connect to a critical component, then the path should return a 500-level response code to indicate that the app is unhealthy.

安全性Security

大型企业的开发团队通常需要遵守已公开 API 的安全性要求。Development teams at large enterprises often need to adhere to security requirements for their exposed APIs. 若要保护运行状况检查终结点,应先使用 IP 限制客户端证书或虚拟网络等功能来限制对应用程序的访问。To secure the healthcheck endpoint, you should first use features such as IP restrictions, client certificates, or a Virtual Network to restrict access to the application. 可以要求传入请求的 User-AgentReadyForRequest/1.0 匹配,以保护运行状况检查终结点。You can secure the healthcheck endpoint itself by requiring that the User-Agent of the incoming request matches ReadyForRequest/1.0. 由于先前的安全功能已对该请求进行了保护,因此无法冒名顶替用户代理。The User-Agent cannot be spoofed since the request was already secured by the prior security features.

行为Behavior

提供运行状况检查路径后,应用服务将在所有实例上 ping 通该路径。When the health check path is provided, App Service will ping the path on all instances. 如果进行 5 次 ping 后未收到表示成功的响应代码,则将该实例视为“运行不正常”。If a successful response code is not received after 5 pings, that instance is considered "unhealthy". 负载均衡器轮换将排除运行不正常的实例。Unhealthy instance(s) will be excluded from the load balancer rotation. 此外,纵向或横向扩展时,应用服务将对运行状况检查路径执行 ping 操作,确保新实例可用于请求。Furthermore, when you are scaling up or out, App Service will ping the health check path to ensure that the new instances are ready for requests.

其余正常运行的实例的负载可能会增大。The remaining healthy instances may experience increased load. 为避免其余实例不堪重负,排除的实例不得过半。To avoid overwhelming the remaining instances, no more than half of your instances will be excluded. 例如,如果应用服务计划横向扩展到 4 个实例,且其中 3 个运行不正常,则负载均衡器轮换最多排除 2 个。For example, if an App Service Plan is scaled out to 4 instances and 3 of which are unhealthy, at most 2 will be excluded from the loadbalancer rotation. 其他 2 个实例(1 个运行正常的实例和 1 个运行不正常的实例)将继续接收请求。The other 2 instances (1 healthy and 1 unhealthy) will continue to receive requests. 在所有实例均不正常的最坏情况下,不排除任何实例。如果要替代此行为,可以将 WEBSITE_HEALTHCHECK_MAXUNHEALTYWORKERPERCENT 应用设置设置为介于 0100 之间的值。In the worst-case scenario where all instances are unhealthy, none will be excluded.If you would like to override this behavior, you can set the WEBSITE_HEALTHCHECK_MAXUNHEALTYWORKERPERCENT app setting to a value between 0 and 100. 将此值设置为较高值意味着将删除更多运行不正常的实例(默认值为 50)。Setting this to a higher value means more unhealthy instances will be removed (the default value is 50).

如果实例在一小时内仍无法正常运行,则将其更换为新实例。If an instance remains unhealthy for one hour, it will be replaced with new instance. 每小时最多更换一个实例,每个应用服务计划每天最多更换三个实例。At most one instance will be replaced per hour, with a maximum of three instances per day per App Service Plan.

监视Monitoring

提供应用程序的运行状况检查路径后,可以使用 Azure Monitor 监视站点的运行状况。After providing your application's health check path, you can monitor the health of your site using Azure Monitor. 在门户的“运行状况检查”边栏选项卡中,单击顶部工具栏中的“指标” 。From the Health check blade in the Portal, click the Metrics in the top toolbar. 此操作将打开新的边栏选项卡,可以在其中查看站点的历史运行状况以及新建预警规则。This will open a new blade where you can see the site's historical health status and create a new alert rule. 有关监视站点的更多信息,请参阅 Azure Monitor 指南For more information on monitoring your sites, see the guide on Azure Monitor.

后续步骤Next steps