| Новые программы oszone.net |  |
В прошлой статье мы ознакомили вас с концепциями, относящимися к созданию мультитенантных приложений (multi-tenant apps), и рассказали о двух из четырех столпах, которые следует учитывать при разработке этого типа системы: идентификации и защите, а также изоляции и разделении данных. На этот раз мы сосредоточимся на двух других важных и тесно связанных столпах: анализе производительности (metering) и автоматическом масштабировании (autoscaling). Первый из них позволяет компаниям собирать информацию о различных компонентах, общих для всех тенантов, а второй гарантирует, что на работу конечных пользователей не повлияют периоды интенсивного трафика и что серверы будут отсоединяться по мере снижения потребностей в ресурсах. Сбор информации об использовании ресурсов часто применяется при выявлении и устранении проблем с приложениями, особенно в ходе разработки и тестирования. При этом могут быть заданы пороговые значения и аппаратные требования, гарантирующие оптимальную производительность решения, а также могут быть рекомендованы минимальные требования к оборудованию. В Windows эта задача решается применением счетчиков производительности, помогающих выявить узкие места в системе и условия состояния «ошибка» (error conditions). Анализ производительности становится особенно важным при выполнении мультитенантных решений в облаке — не только на этапах разработки. Поддержка множества пользователей, обращающихся к общим ресурсам, создает специфические трудности, например как ввести принудительные квоты для тенантов, выявлять любых пользователей, которые могут потреблять избыточные ресурсы, или решить, надо ли переопределять уровни тарификации. Учитывайте, что анализ производительности мультитенантных решений — это не только определение или проверка счетов за использование ресурсов от провайдера облака (в данном случае — Windows Azure), но и оптимизация ресурсов, гарантирующая ожидаемый тенантами уровень обслуживания, который обычно отражается в соглашении об уровне обслуживания (service-level agreement, SLA). В этой статье мы сосредоточимся на вычислительной части анализа производительности и автоматического масштабирования мультитенантного решения, которое в наибольшей степени затрагивается колебаниями в количестве пользователей, обращающихся к приложению. Теперь, когда Windows Azure поддерживает несколько моделей развертывания в облаке (Cloud Services, Virtual Machines и Web Sites), важно понимать различные варианты и параметры протоколирования и диагностики, предлагаемые каждой из моделей, и то, как эти модели могут автоматически масштабироваться на основе данной информации. Если вы хотите детальнее разобраться в основных различиях, преимуществах и ограничениях моделей развертывания, прочитайте неплохое руководство по ссылке bit.ly/Z7YwX0. Сбор данных от Windows Azure Cloud ServicesВ Cloud Services (основанной на концепции Platform as a Service) сбор данных осуществляется через инфраструктуру Windows Azure Diagnostics (WAD), построенную на базе инфраструктуры Event Tracing for Windows (ETW). Поскольку Cloud Services основана на виртуальных машинах (VM) без поддержки состояний, WAD позволяет сохранять данные локально и по расписанию переносить их в центральный репозитарий в хранилищах Windows Azure, использующих двоичные объекты и таблицы. После сбора диагностических данных из нескольких экземпляров роли их можно анализировать и применять для различных целей. Как происходит этот процесс, показано на рис. 1.
Рис. 1. Windows Azure Diagnostics для Cloud Services
Рис. 2. Базовое определение сервиса и конфигурационные файлы диагностики для Cloud Services <?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyHostedService" xmlns="http://
schemas.microsoft.com/ServiceHosting/2008/10/
ServiceDefinition" schemaVersion="2012-10.1.8">
<WebRole name="WebRole1">
<!--<Sites> ... </Sites> -->
<!-- <Endpoints> ... </Endpoints> -->
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
</WebRole>
</ServiceDefinition>
<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns=
"http://schemas.microsoft.com/ServiceHosting/2010/
10/DiagnosticsConfiguration"
configurationChangePollInterval="PT1M"
overallQuotaInMB="4096">
<Directories bufferQuotaInMB="0"
scheduledTransferPeriod="PT30M">
<IISLogs container="wad-iis" directoryQuotaInMB="0" />
</Directories>
</DiagnosticMonitorConfiguration>Атрибут configurationChangePollInterval определяет, как экземпляр проверяет изменения в конфигурации, а scheduledTransferPeriod указывает интервал, через который локальные файлы перемещаются в Windows Azure Storage (в примере на рис. 2 они перемещаются в контейнер двоичных объектов «wad-iis»). Учтите, что одна минута (PT1M) является значением по умолчанию и минимальной величиной для параметра перемещения файлов по расписанию, но в большинстве сценариев это может оказаться перебором. Атрибут overallQuotaInMB определяет общий объем хранилища файловой системы, выделяемый для буферов журналов. Атрибут bufferQuotaInMB для каждого источника данных может быть либо оставлен равным нулю по умолчанию — тогда его значение меньше значения свойства overallQuotaInMB, — либо установлен явным образом. OverallQuotaInMB должен быть меньше суммы значений всех свойств bufferQuotainMB. Хотя для сбора диагностической информации от облачных сервисов можно задействовать различные источники данных, определить на их основе, какие тенанты потребляют большую часть вычислительных ресурсов не так-то легко. Ближайшая метрика, которую можно использовать для этой цели, предоставляется журналами IIS World Wide Web Consortium (W3C) — при условии, что трафик от различных пользователей и тенантов отслеживается через URL-параметры или специфические виртуальные каталоги. Чтобы активировать эту систему, в конфигурационный файл диагностики можно добавить XML-узел IISLogs (он также включен в код на рис. 2), но вы должны знать, что эти журналы IIS могут весьма быстро разрастаться до огромных размеров. Также помните, что эта диагностическая информация хранится под учетной записью хранилища Windows Azure, и изменения конфигурации можно вносить в развернутые и работающие сервисы. Чтобы узнать больше о других типах источников данных через конфигурационный файл, в том числе о журналах событий Windows и счетчиках производительности, почитайте документацию Windows Azure по ссылке bit.ly/GTXAvo. Кроме того, начиная с Windows Azure SDK версии 2.0, процесс настройки диагностики в Visual Studio был значительно усовершенствован. В разделе диагностики теперь предлагается план Custom, который можно модифицировать для включения одного или более источников данных; эти источники будут протоколироваться, и информация из них будет перемещаться в указанную учетную запись хранилища Windows Azure (рис. 3).
Щелкнув кнопку Edit, можно определить, какие именно данные нужно собирать, в том числе информацию счетчиков производительности Windows, журналов событий и каталогов журналов (рис. 4). В этом примере будет собираться диагностическая информация о проценте используемого процессорного времени, доступных мегабайтах памяти и количестве запросов в секунду, а затем она будет передаваться учетной записи хранилища Windows через каждые 30 минут (параметр интервала передачи). Этот новый интерфейс упрощает настройку диагностики для облачных сервисов и получение данных для последующего анализа и другого использования.
Помимо параметров мониторинга Cloud Services, предоставляемых платформой Windows Azure, вы можете задействовать Cloud Ninja Metering Block, выпущенный группой Windows Azure Incubation; этот пакет включает в простую в использовании библиотеку многие из упомянутых средств и доступен по ссылке cnmb.codeplex.com. Сбор данных от Windows Azure Virtual MachinesVirtual Machines — это экземпляры без состояния, выполняемые на платформе Windows Azure, и их можно развертывать индивидуально или с подключением к Cloud Services через виртуальные сети. Поскольку эти экземпляры выполняют полные версии Windows и Linux, сбор диагностической информации аналогичен таковому на корпоративных компьютерах с использованием счетчиков производительности и сохранением в локальном хранилище. Процесс извлечения этой информации может варьироваться, но обычно осуществляется установкой локальных агентов, которые передают данные внешним сервисам. CСбор данных от Windows Azure Web SitesТеперь переключимся на Windows Azure Web Sites. Сбор диагностической информации от Web Sites — простой процесс, который можно активировать прямо на портале управления. Для мониторинга мультитенантных приложений следует активировать Web Server Logging (файловый формат журналов, расширенный W3C), а файлы журналов скачиваются по FTP. Вот какой схемы вы должны придерживаться.
Как и в случае Windows Azure Cloud Services, информация из файлов журналов позволяет определять использование ресурсов различными тенантами за счет отслеживания параметров URL или индивидуальных виртуальных каталогов. Мониторинг как сервисПомимо вариантов диагностики, предоставляемых самой Windows Azure, несколько компаний предлагает сервисы мониторинга для Windows Azure. Например, Dell Inc. создала продукт Foglight, который обеспечивает сбор данных о состоянии приложений в реальном времени и связывает эти данные с удобством использования приложений. Кроме того, он включает сервис уведомления, который оповещает разработчиков и критических проблемах. Сегодня Foglight поддерживает Cloud Services и Windows Azure SQL Database на основе инфраструктуры WAD, как показано на рис. 5.
Варианты автоматического масштабированияПосле сбора аналитические данные и счетчики производительности можно задействовать для определения уровня обеспечения, необходимого для удовлетворения требований приложения к производительности. Автоматическое масштабирование в Windows Azure означает добавление или удаление экземпляров из конкретной развернутой системы (горизонтальное масштабирование [scaling out]) с упором на то, чтобы решения работали при минимально возможных затратах. Хотя возможно вертикальное масштабирование (scaling up) (увеличение ресурсов для одной машины), это обычно ведет к простою приложения, что никогда нежелательно. В целом, существуют три способа автоматического масштабирования системы, развернутой в Windows Azure. Применение блока автоматического масштабирования (autoscaling block) Один из подходов к автоматическому масштабированию системы, развернутой в Windows Azure, который применяется конкретно в Windows Azure Cloud Services, — добавление в решение прикладного блока автоматического масштабирования. Для этой цели есть пара библиотек, готовых к использованию. Одна из библиотек является частью Enterprise Integration Pack for Windows Azure и использует набор пользовательских правил, задающих лимиты для минимального и максимального количества экземпляров ролей в развернутой системе на основе счетчиков или результатов мониторинга, собранных с помощью WAD. Этот подход полностью документирован группой Microsoft Patterns & Practices, и все необходимое вы найдете по ссылке bit.ly/18cr5mD. На рис. 6 показано базовое мультитенантное приложение с блоком автоматического масштабирования, добавленным в решение.
Применение скриптов Windows PowerShell Третий метод основан на скриптах Windows PowerShell, которые создаются вручную и выполняются напрямую через Windows Azure Management API. Этот подход дает высокий уровень контроля и гибкости, поскольку данные скрипты можно использовать в собственных приложениях или в инфраструктурах с непрерывной интеграцией (continuous integration frameworks). Более того, командлеты Windows PowerShell для Windows Azure поддерживают три модели развертывания, включая автоматизацию процесса предоставления ресурсов для Windows Azure Web Sites. Например, для изменения количества экземпляров для конкретной развернутой системы достаточно выполнить следующую команду: PS C:\> Set-AzureWebsite –Name {WebSiteName}
–NumberOfWorkers {Instances}О том, как настраивать и устанавливать командлеты для Windows Azure, см. по ссылке bit.ly/QqctsU. Документацию по каждому из этих командлетов см. по ссылке bit.ly/U0vOEp. ЗаключениеЭта статья завершает серию из двух частей по созданию мультитенантных решений в Windows Azure. В дополнение к идентификации и изоляции данных в первой статье мы познакомили вас с процессом конфигурирования и извлечения информации о производительности в каждой модели развертывания в Windows Azure: Cloud Services, Virtual Machines и Web Sites. Попутно мы проанализировали три способа автоматического масштабирования через внутренние и внешние компоненты и сервисы. Благодаря преимуществам экономической модели облака (основанной на стоимости используемый ресурсов и пулах общих ресурсов) все больше компаний выпускают решения, которые можно эффективно адаптировать под их потребности.
Теги:
Windows Azure.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.png)
.png)
.png)
.png)
.png)
.png)
.png)
