基于XML文件的Azure可扩展性

Question

以编程方式更改定义了实例数量的XML文件的最佳实践解决方案是什么？我知道通过Windows Azure API的这个csmanage.exe，这是可能的。我如何衡量哪些工作人员角色VM实际正在工作？我也在MSDN社区论坛上问了这个问题：http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/02ae7321-11df-45a7-95d1-bfea402c5db1

Answer 1

要修改配置，您可能需要查看PowerShell Azure Cmdlets。这确实简化了任务。例如，下面是一个将生产环境中'WebRole1‘的实例计数增加1的PowerShell代码片段：

$cert = Get-Item cert:\CurrentUser\My\<YourCertThumbprint>
$sub = "<YourAzureSubscriptionId>"
$servicename = '<YourAzureServiceName>'
Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub |
Get-Deployment -Slot Production |
Set-DeploymentConfiguration {$_.RolesConfiguration["WebRole1"].InstanceCount += 1}

现在，就实际监控系统负载和吞吐量而言:您将需要Azure API调用和性能计数器数据的组合。例如:您可以请求Azure队列中当前的消息数量：

http://yourstorageaccount.queue.core.windows.net/myqueue?comp=metadata

您还可以设置您的角色以捕获特定的性能计数器。例如：

 public override bool OnStart()
 {
    var diagObj= DiagnosticMonitor.GetDefaultInitialConfiguration();
    AddPerfCounter(diagObj,@"\Processor(*)\% Processor Time",60.0);
    AddPerfCounter(diagObj, @"\ASP.NET Applications(*)\Request Execution Time", 60.0);
    AddPerfCounter(diagObj,@"\ASP.NET Applications(*)\Requests Executing", 60.0);
    AddPerfCounter(diagObj, @"\ASP.NET Applications(*)\Requests/Sec", 60.0);

    //Set the service to transfer logs every minute to the storage account
    diagObj.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(1.0);

    //Start Diagnostics Monitor with the new storage account configuration
    DiagnosticMonitor.Start("DiagnosticsConnectionString",diagObj);
}

因此，此代码将一些性能计数器捕获到每个角色实例的本地存储中，然后每分钟将这些值传输到表存储中。

现在，技巧是检索这些值，解析它们，评估它们，然后相应地调整您的角色实例。Azure API将允许您轻松地从表存储中提取性能计数器。然而，解析和评估将需要一些时间来构建。

这导致我建议您查看MSDN代码站点上的Azure Dynamic Scaling Example。这是一个很好的示例，它提供了：

• 托管wcf服务的演示行业应用程序
• 以您指定的速率将消息推送到服务的负载生成工具
• 负载监视web UI
• 可以在本地或Azure角色中运行的缩放引擎。

这是您要仔细查看的最后一项。根据阈值，它会将您的性能计数器数据以及队列长度数据与这些阈值进行比较。根据比较结果，它会相应地放大或缩小实例。

即使您最终不使用此引擎，您也可以看到数据是如何从表存储中抓取、处理并用于驱动实例更改的。

Answer 2

量化负载实际上是非常特定于应用程序的-特别是在考虑工作人员角色时。例如，如果您正在做一个大型并行处理应用程序，预期/希望的行为将是所有CPU利用率的100%，并且“规模决策”可能基于工作队列是增长还是缩小。

更复杂的决策是各个步骤的滞后时间-增加角色实例计数，加入负载均衡器，和/或从负载均衡器删除。很容易进入这样一种情况，即你在“追逐”曲线，不断地上下翻腾。

对于您关于特定虚拟机的特定问题，由于角色定义中的所有虚拟机都是相同的，因此测量单个虚拟机(除非部署从虚拟机计数1开始)实际上不会告诉您太多-所有虚拟机都位于负载平衡器后面和/或从同一队列中提取。任何变化都应该是暂时的。

我的建议是选择一些本质上不是高度可变的东西来监控(例如CPU)。通常，你想要找到一个趋势点--对于web应用，它可能是响应队列，对于并行应用，它可能是azure队列深度，等等，但对于任何一个来说，它们都是趋势，而不是绝对数字。我还建议以相当宽的间隔测量它们-分钟，而不是秒。如果您有一个负载需要在几秒钟内响应，那么实际上您将需要提前增加您的运行实例计数。

Answer 3

关于第一个问题，您还可以使用Autoscaling Application Block根据一组预定义的规则动态更改实例计数。