如何在 Windows azure 中有效扩展？答案

【问题标题】：How to scale effectively in windows azure?如何在 Windows azure 中有效扩展？
【发布时间】：2013-08-11 15:11:56
【问题描述】：

我在确定有效扩展我的云服务的正确配置方面遇到了一些困难。我假设我们只需要使用管理门户的比例部分而不以编程方式进行吗？我当前的 Web Role 配置是

中型虚拟机（4 GB RAM）自动缩放 - CPUInstance 范围 - 1 到 10 目标 CPU - 50 到 80 一次向上和向下缩放 1 个实例向上和向下缩放等待时间 - 5 分钟

我使用http://loader.io/ 站点通过向 API 发送并发请求来进行负载测试。它只能支持 50 -100 个用户。之后我收到超时（10 秒）错误。我的应用将面向数百万用户，因此我不确定如何有效地扩展以满足服务器上的如此大负载。

我认为问题可能是 5 分钟的扩展时间（我认为它非常高），而在管理门户中，最低选项是 5 分钟，所以不知道如何减少它？

有什么建议吗？

【问题讨论】：

标签： c# azure concurrency scalability azure-web-roles

【解决方案1】：

Azure 的自动缩放引擎每 5 分钟检查一次 60 分钟的 CPU 利用率平均值。这意味着每 5 分钟它就有机会确定您的 CPU 利用率是否过高并向上扩展。

如果您需要更强大的功能，我建议您考虑以下几点：

CPU 使用率很少是衡量网站扩展的良好指标。看转换为 Requests/sec 或 requests/current 而不是 CPU 利用率。
考虑检查是否需要更频繁地扩展（每 1 分钟一次？） Azure 门户无法执行此操作。您需要WASABi 或 AzureWatch 这个
根据您的使用模式，考虑查看较短的平均时间来做出决定（即：平均超过 20 分钟而不是 60 分钟）。再一次，您的选择是 WASABi 或 AzureWatch
考虑查看 /rate/ 的增加在指标中，而不仅仅是最新的平均值本身。 IE：在过去 20 分钟内，每秒请求数增加了 20%。再次，蔚蓝自动缩放引擎无法做到这一点，请考虑 WASABi（可能这样做）或 AzureWatch 绝对可以做到这一点。

WASABi 是 Microsoft 的一个应用程序块（即：一个 DLL），您需要自己在某处进行配置、托管和监控。它非常灵活，您可以覆盖任何功能，因为它是开源的。

AzureWatch 是第三方托管服务，可监控/自动缩放/修复您的 Azure 角色/虚拟机/网站/SQL Azure/等。这要花钱，但你让别人做所有的脏活。

我最近wrote a blog关于三款产品的对比

披露：我隶属于 AzureWatch

HTH

【讨论】：

澄清一下：您不需要 WASABi 或AzureWatch。还有其他服务，例如 MetricsHub。您甚至可以通过检查性能计数器、应用程序日志、队列长度等来创建自己的应用程序，并且可以使用 PowerShell 调用执行缩放操作。说了这么多：自动缩放很复杂，您可能最好使用@Igorek 提到的库或服务。但还有其他选择。
谢谢，我已经注册了Azure手表的试用版。我仍然掌握它，因为所有性能计数器都放在其中......有很多选择。我确实查看了 Web 服务部分中的 requests/sec 选项，其最小聚合时间为 5 分钟。如果在 1 分钟内有 1000 个请求并且我的网络角色直到 5 分钟才扩展，这对我有什么帮助？
不幸的是，对于没有相关领先指标的超突然峰值，我想不出任何解决方案。您需要等待至少 5 分钟才能启动 X 数量的服务器。但是，如果这些高峰与某种营销/促销计划、一天中的时间、注册数量或其他一些领先指标有关，那么肯定可以适应规模超前战略。
突然的、意想不到的尖峰很难。您可以携带额外的容量来处理相当大的峰值（比如多出 30%-50%，具体取决于您的风险承受能力/成本平均水平）。当然，您可能无法同时承受大量负载的冲击，但是通过承载一些额外的容量，您可以在其他服务器启动时减少影响。此外，如果您的网站检测到它已承受重负载，请查看减少功能的想法。降低体验，而不是网站失败。

【解决方案2】：

最短时间为 5 分钟的另一个原因是，Azure 需要一些时间来为您的云服务分配额外的机器并将您的软件复制到这些机器上。（WebApps 没有那个“问题”）在我作为 SaaS 管理员的工作中，我发现对于云服务，我们的软件包在扩展后的加速时间可能约为 3-5 分钟。

如果您想在 Azure 门户中配置缩放，那么我的建议是显着降低您的 CPU 范围。正如 Igorek 提到的，Azure 缩放查看过去 60 分钟的平均值。如果云服务大部分时间以 5% 的 CPU 运行，然后突然达到峰值并以 99% 运行，则平均值需要一段时间才能上升并触发您的规模设置。将其保持在 80% 将导致缩放发生得太晚。强化学习示例：我管理一个运行一些 CPU 密集型计算的门户。在正常使用情况下，我们的云服务往往以 2-5% 的 CPU 运行，但在极少数情况下，我们会看到它上升到 99% 并保持一段时间。

我的第一次扩展尝试是 2 个实例，并以 80% 的平均 CPU 扩展了 2 个实例，但随后触发事件大约需要 40 分钟，因为平均 CPU 没有那么快上升。现在，当平均 CPU 超过 25% 时，我已将一切设置为可扩展，我看到我们的服务将在 10-12 分钟后扩展。我并不是说 25% 是一个神奇的数字，我是说请记住，您正在使用“平均超过 60 分钟”

第二件事是，Azure 门户仅显示一组有限的缩放选项，使用 Powershell / REST 时可以更详细地设置缩放。例如，计算平均值的 60 分钟间隔可以降低。

【讨论】：