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

Question

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

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

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

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

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

4. 有没有办法设置自动扩展，以确保云服务中当前的所有实例都能够在扩展操作期间不间断地服务请求？ (无论如何，不​​仅仅是使用 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

Answer 1

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

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

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

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

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

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

HTH