如何在windows azure中有效扩展？

Question

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

中型VM（4 GB RAM） 自动缩放 - CPUInstance范围 - 1到10Target CPU - 50到80Scale一次上下1个实例，上下缩放等待时间 - 5分钟

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

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

有什么建议吗？

Answer 1

Azure的自动扩展引擎每5分钟检查一次60分钟的cpu利用率平均值。这意味着每隔5分钟它就有机会决定你的CPU利用率是否过高并扩大规模。

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

• CPU使用率很少是扩展网站的良好指标。看 到请求/秒或请求/当前而不是CPU利用率。
• 考虑更频繁地进行扩展的需要（每1分钟？） Azure门户无法执行此操作。您需要WASABi或 {/ 3}} {/ 3>}
• 根据您的使用模式，考虑查看较短的时间平均值来做出决定（即：平均超过20分钟而不是60分钟）。您再次选择WASABi或AzureWatch
• 考虑一下/率/增长 在指标而不仅仅是最新的平均值本身。 IE： 请求/秒在过去20分钟内上升了20％。再一次，Azure 自动调节引擎不能这样做，考虑WASABi（可能 这样做）或AzureWatch肯定可以做到这一点。

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

WASABi是第三方托管服务，用于监控/自动协调/修复Azure角色/虚拟机/网站/ SQL Azure /等。这需要钱，但你让其他人做了所有肮脏的工作。

我最近AzureWatch关于三种产品的比较

披露：我隶属于AzureWatch

HTH

Answer 2

最短时间为5分钟的另一个原因是Azure花了一些时间将其他计算机分配给您的Cloud Service并将软件复制到它们上。 （WebApps没有那个＆＃39;问题＆＃39;） 在我作为saas管理员的工作中，我发现对于云服务，缩放后的这个加速时间对于我们的软件包大约需要3-5分钟。

如果要在Azure门户中配置扩展，那么我的建议是显着降低CPU范围。正如Igorek所提到的，Azure缩放在过去的60分钟内看到了平均值。 如果Cloud Service在大多数情况下以5％的CPU运行，则突然达到峰值并以99％运行，平均值需要一段时间才能启动并触发您的比例设置。将其保持在80％将导致缩放发生得太晚。 RL例子： 我管理一个运行一些CPU密集型计算的门户。在正常使用情况下，我们的云服务往往以2-5％的CPU运行，但在极少数情况下，我们已经看到它达到99％并在那里停留一段时间。

我的第一次扩展尝试是2个实例，并且在平均CPU的80％时扩展为2，但是事件触发大约需要40分钟，因为平均CPU没有那么快。现在，当平均CPU超过25％时，我将所有设置都按比例缩放，我看到的是我们的服务将在10-12分钟后扩展。 我并不是说25％是一个神奇的数字，我要说的是你要记住你的平均时间超过60分钟＆＃34;

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