基于 XML 文件的 Azure 可扩展性答案

【问题标题】：Azure scalability over XML File基于 XML 文件的 Azure 可扩展性
【发布时间】：2010-04-23 16:56:48
【问题描述】：

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

【问题讨论】：

标签： windows azure cloud

【解决方案1】：

要修改配置，您可能需要查看PowerShell Azure Cmdlets。这确实简化了任务。例如，这是一个 PowerShell sn-p，用于将生产环境中“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 Queue 中的消息数：

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 服务的演示业务线应用程序
一种负载生成工具，以您指定的速率将消息推送到服务
负载监控网络用户界面
可在本地或以 Azure 角色运行的扩展引擎。

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

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

【讨论】：

谢谢。这使得增加实例数量的任务更快。但是：如何在实例上“量化负载”，以便可以通过编程方式更改实例的数量 - 所以我们不需要任何“人工干预”。
希望我刚刚添加的信息对您的任务有所帮助。我现在意识到，仅 powershell cmdlet 示例本身并不能真正将您带到您需要的地方。

【解决方案2】：

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

使决策更加复杂的是各个步骤的滞后时间 - 增加角色实例计数、加入负载平衡器和/或从负载平衡器中删除。很容易陷入“追逐”曲线，不断上下颠簸的情况。

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

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

【讨论】：

【解决方案3】：

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

【讨论】：