Question

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

Answer 1

要修改配置，您可能需要查看PowerShell Azure Cmdlets。这真的简化了任务。例如，这是一个PowerShell片段，用于将生产中“WebRole1”的实例数增加1：

$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将允许您轻松从表存储中提取perf计数器。但是，解析和评估将需要一些时间来构建。

这导致我建议你查看MSDN代码网站上的Azure Dynamic Scaling Example。这是一个很好的样本，提供：

托管wcf服务的演示业务线应用
以指定的速率将消息推送到服务的负载生成工具
负载监控Web UI
可以在本地运行或以Azure角色运行的扩展引擎。

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

即使您最终没有使用此引擎，您也可以看到如何从表存储中获取数据，按摩并用于驱动实例更改。

Answer 2

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

进一步使决策复杂化的是各个步骤的延迟时间 - 增加角色实例计数，加入负载均衡器和/或从负载均衡器中删除。很容易陷入“追逐”曲线，不断上下搅动的情况。

关于特定虚拟机的具体问题，由于角色定义中的所有虚拟机都是相同的，因此测量单个虚拟机（除非部署以虚拟机数量1开始）不应该真正告诉您 - 所有虚拟机都位于负载后面平衡器和/或从同一队列拉出。任何差异都应该是暂时的。

我的建议是选择一些本身不具有高度可变性的东西（例如CPU）。通常，您希望找到一个趋势点 - 对于Web应用程序，它可能是响应队列，对于并行应用程序，它可能是天蓝色队列深度等，但对于它们或者它们将是趋势而不是绝对数字。我还建议以相当宽的间隔测量它们 - 分钟，而不是秒。如果您有负载需要在几秒钟内响应，那么实际上您需要提前增加运行实例计数。

Answer 3

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

Azure文件的Azure可伸缩性

3 个答案: