Azure 云服务内置自动缩放如何工作？

Posted 2023-03-04

【中文标题】Azure 云服务内置自动缩放如何工作？

【英文标题】：How does Azure cloud service built-in auto-scaling works?

【发布时间】：2016-06-14 22:12:35

【问题描述】：

在对 Azure 文档进行深入研究后，我们仍然错过了一些关于 Azure 内置云服务自动缩放如何工作的重要细节。我们的云服务是具有单一 Web 角色的简单 ASP.NET 应用程序。默认情况下，我们部署到 2 个实例以获得 SLA 覆盖率，然后根据 CPU 使用率一次扩大或缩小一个实例。我们确实使用启动任务来配置 IIS 并在 csdef 中定义它们。我们确实使用 RoleEntryPoint 在 OnStart 事件中指定自定义预热逻辑。我们确信启动任务和 OnStart 不会因错误而失败。

以下问题来自我的观察，旨在澄清这是否是预期行为。

当云服务向上或向下扩展时，当前存在的每个实例将在短时间内从负载均衡器中取出，并且不会处理请求。这是真的吗？

csdef 中的topologyChangeDiscovery="Blast" 不会更改此行为，并且在扩展操作期间实例仍会从负载均衡器中取出。这是真的吗？

如果您在云服务中有 N 个实例并且它扩展到 N+1，那么有时只有 N-1 个实例为请求提供服务。该时间等于 N *（单实例配置更改所需的时间）。这是真的吗？

有没有办法设置自动缩放以确保当前在云服务中的所有实例在缩放操作期间都将服务请求而不会中断？ （无论如何，不​​仅使用 Azure 内置的自动缩放）

更新：

我已经进行了测试，以实际检查在规模事件期间哪些实例正在为请求提供服务。简单的控制台应用程序轮询云服务并记录响应请求的实例。我已将 Azure 门户中所有更改的屏幕截图添加到日志文件中。

以下是结果： 从 2 个实例扩展到 3 个实例： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaleuplog_withscreens-txt

从 3 个实例缩减到 2 个实例： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaledownlogs_with_screens-txt

控制台应用源代码和日志格式说明： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a

【问题讨论】：

您的问题与this question 非常相似，其中有一些讨论行为的答案。

在我们的案例中没有角色回收（IIS进程没有重启）。您提到的问题专门询问导致回收的原因。

【参考方案1】：

当您处理缩小到 1 个实例或从 1 个实例放大时，您会遇到令人不快的结果，这是因为 Azure 将现有的“好”实例从负载均衡器中取出。

假设您只处理 2 个以上的实例并且从不缩减到 2 个以下实例，以下是基于 5 年为 Azure 运行 CloudMonix/AzureWatch 自动扩展服务的一些响应

仅当只剩下 1 个实例时，如上所述

Blast 对负载平衡器的影响应该很小。但是，如果在拓扑事件发生时所有实例都在重新启动，请确保您在 Web/WorkerRole.cs 中的拓扑更改事件期间不会意外返回“真”以进行重新启动

如果您有 N 个实例，其中 N>=2，并且扩展到 N+1，则需要大约 10 分钟才能达到 N+1。在这种情况下，您绝不应该有 N-1 个活动的。 Microsoft 的一个文档解释了它扩展到多个实例的速度有多快，但它与启动实例计数无关，但与它启动多少新实例有关。我相信可以保证在 30 或 60 分钟内启动多达 100 个新实例。不要引用我的话。

您可以使用第三方服务，例如我所属的CloudMonix。但在所有情况下，当您处理 1 个实例并尝试缩小到该实例或从该实例放大时，都会出现标准扩展问题。

HTH

【讨论】：

您好，感谢您的回复。当您从 2 个实例扩展到 3 个实例时，我们观察到内置 Azure 自动缩放的不同行为。请检查原始问题中的更新以获取详细的测试结果。这是预期的行为吗？对于这种情况，CloudMonix 的行为是否与 Azure 内置的自动缩放不同？