Масштабируемость Azure по XML-файлу
Каково решение для наиболее успешной практики для того, чтобы программно изменить XML-файл, где количество экземпляров является definied? Я знаю, что это так или иначе возможно с этим csmanage.exe для Windows Azure API. Как я могу иметь размеры, какая Роль Рабочего VMs на самом деле работают? Я задал этот вопрос на форумах Сообщества MSDN также: http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/02ae7321-11df-45a7-95d1-bfea402c5db1
2 ответа
Чтобы изменить конфигурацию, вам стоит обратиться к PowerShell Azure Cmdlets. Это действительно упрощает задачу. Например, вот фрагмент PowerShell для увеличения количества экземпляров 'WebRole1' в Production на 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);
}
Итак, этот код захватывает несколько счетчиков производительности в локальное хранилище на каждом экземпляре роли, затем каждую минуту эти значения переносятся в табличное хранилище.
Теперь дело за малым - получить эти значения, проанализировать их, оценить, а затем соответствующим образом настроить экземпляры роли. API Azure позволит вам легко извлечь счетчики perf из хранилища таблиц. Однако на разбор и оценку потребуется некоторое время.
В связи с этим я предлагаю вам взглянуть на пример Azure Dynamic Scaling Example на сайте кода MSDN. Это отличный пример, который предоставляет:
- демонстрационное приложение для бизнеса, размещающее службу wcf
- инструмент генерации нагрузки, который отправляет сообщения в службу с заданной вами скоростью
- веб-интерфейс мониторинга нагрузки
- механизм масштабирования, который может быть запущен локально или в роли Azure.
Именно на последний пункт вам стоит обратить пристальное внимание. На основе пороговых значений он сравнивает данные счетчика производительности, а также данные о длине очереди с этими пороговыми значениями. На основании этих сравнений он соответственно увеличивает или уменьшает количество экземпляров.
Даже если в конечном итоге вы не будете использовать этот механизм, вы сможете увидеть, как данные берутся из табличного хранилища, обрабатываются и используются для изменения экземпляров.
Количественная оценка нагрузки на самом деле очень специфична для приложения, особенно если продумывать рабочие роли. Например, если вы выполняете большое приложение с параллельной обработкой, ожидаемым / ожидаемым поведением будет 100% загрузка ЦП по всем направлениям, а «масштабное решение» может зависеть от того, растет или уменьшается рабочая очередь.
Еще больше усложняет решение время задержки для различных шагов - увеличения количества экземпляров роли, присоединения к балансировщику нагрузки и / или выхода из балансировщика нагрузки. Очень легко попасть в ситуацию, когда вы «преследуете» кривую, постоянно взбивая вверх и вниз.
Что касается вашего конкретного вопроса о конкретных виртуальных машинах, поскольку все виртуальные машины в определении роли идентичны, измерение одной виртуальной машины (если развертывание не начинается с количества виртуальных машин 1) на самом деле мало что вам скажет - все виртуальные машины сидят за нагрузкой. балансировщик и / или тянут из одной очереди. Любое отклонение должно быть временным.
Я бы порекомендовал выбрать то, что по своей природе не является очень изменчивым для мониторинга (например, ЦП). Как правило, вы хотите найти точку тренда - для веб-приложений это может быть очередь ответов, для параллельных приложений это может быть глубина очереди Azure и т. Д., Но для любого из них они будут тенденцией, а не абсолютным числом. Я бы также посоветовал измерять их через довольно широкие интервалы - минуты, а не секунды. Если у вас есть нагрузка, на которую вам нужно отреагировать за секунды, то реально вам нужно будет заранее увеличить количество запущенных экземпляров.