4

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

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

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

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

有什么建议么？

4

2 回答 2

6

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

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

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

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

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

我最近写了一篇关于三种产品比较的博客

披露：我隶属于 AzureWatch

高温高压

于 2013-08-09T16:39:25.933 回答
0

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

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

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

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

于 2016-09-26T11:00:36.553 回答