Экспорт (0) Печать
Развернуть все

Разработка многопользовательских приложений в Windows Azure

Обновлено: Январь 2014 г.

Авторы: Сурен Мачираджу (Suren Machiraju) и Ральф Сквиллейс (Ralph Squillace)

Рецензенты: Кристиан Мартинес (Christian Martinez), Джеймс Подгорски (James Podgorski), Валерий Мизонов (Valery Mizonov) и Майкл Томасси (Michael Thomassy)

В документе описаны подходы к проектированию более эффективных многопользовательских приложений для Windows Azure (обычно это сторонние приложения, предоставляющие службы для других организаций) — либо более быстродействующих, надежных и масштабируемых приложений, либо с более низкой стоимостью поддержки и разработки. Вначале описываются общие принципы построения многопользовательских приложений, структура и поведение платформы Windows Azure, которые важно учитывать при создании и эксплуатации таких приложений. Далее рассматриваются некоторые особенности поддержки многочисленных клиентов применительно к Windows Azure: ресурсы приложений и данных, их провизионирование и управление этими ресурсами. Для каждой темы рассмотрены проблемы безопасности, стоимости и масштабирования, для которых необходимо найти правильный баланс, чтобы создать эффективное многопользовательское приложение Windows Azure.

Что такое многопользовательское приложение?

В Википедии дается следующее определение многопользовательской архитектуры.

ImportantВажно!
Если вы уже знакомы с темой этой статьи, переходите сразу к чтению Обзор многопользовательской службы Windows Azure. Можно вернуться к этому разделу позднее, если что-то будет не вполне понятно.

Многопользовательская архитектура — это архитектурное решение, при котором на сервере работает один экземпляр программы, обслуживая несколько клиентских организаций (клиентов). Многопользовательская архитектура противопоставляется многоэкземплярной архитектуре, при которой разные клиентские организации обслуживаются разными экземплярами программ (или аппаратными системами). При использовании многопользовательской архитектуры приложение проектируется так, чтобы виртуально разделять данные и конфигурации, а клиентские организации работают с отдельными виртуальными экземплярами приложения. (Wikipedia.org)

Простой пример В качестве примера можно привести приложение для бронирования мест в ресторанах. Сами рестораны не обладают ИТ-инфраструктурой для построения полноценной службы бронирования мест через Интернет, которая почти в реальном времени связывается со стойкой для бронирования мест или отмены брони. (В большинстве случаев рестораны нанимают другие компании для построения своих статических веб-сайтов!) Можно создать одно приложение, которое обеспечит отдельным ресторанам регистрацию, создание учетной записи, настройку внешнего вида веб-страниц с помощью логотипа и цветовой схемы, загрузку меню, связь веб-приложения с компьютером на стойке регистрации, обработку запросов на бронирование мест от других приложений и тому подобное.

В этом примере каждый ресторан видит используемое приложение, которое после входа в систему является приложением только этого ресторана. Их заказчики видят только веб-сайт ресторана и предполагают, что ресторан сам разработал весь сайт. (Это предоставляемая проголодавшемуся заказчику добавленная стоимость, которую ресторан платит независимому разработчику приложений!) На следующей диаграмме показан пример, в котором приложение бронирования мест поддерживает нескольких клиентов, в данном случае рестораны Contoso и Fabrikiam. На ней показано, как Боб, Лилия, Жасмин и другие заказчики обдумывают, забронировать ли места, исходя из представленного меню.

На следующей диаграмме приведен возможный пример.

Диаграмма службы резервирования Contoso

С позиции архитектуры можно создать такое приложение, размещая для каждого заказчика свой экземпляр приложения с настроенными параметрами. Возможно, каждый заказчик получит свою собственную виртуальную машину (ВМ). Это достаточно распространенное решение, но оно имеет множество недостатков для независимого разработчика приложений, которые проявляются, когда приложение становится относительно популярным (о данной архитектуре мы еще позже поговорим, сейчас же достаточно сказать, что в статье подробно не рассматривается эта архитектура, которую часто называют однопользовательской многоэкземплярной архитектурой).

Если желательно сделать приложение популярным у ресторанов и, возможно, у любых компаний, нуждающихся в реализации системы бронирования, то целесообразно разработать одно приложение, которое распределяет ресурсы среди клиентов (в данном случае среди ресторанов) таким образом, чтобы затраты на обслуживание и ресурсы существенно уменьшались, что обеспечит более высокую производительность и снизит затраты при увеличении рабочей нагрузки. Приложение с подобной архитектурой и является согласно Википедии многопользовательским одноэкземплярным приложением.

Экземпляр приложения

Следует отметить, что в данном случае под «экземпляром» подразумевается все логическое приложение, а не ВМ, исполняемый файл, процесс или что-то в таком роде. На самом деле приложение бронирования мест, схема которого приведена выше, состоит из различных внешних и внутренних «служб» — компонентов, которые взаимодействуют через веб-службы.

Такие веб-приложения обычно разрабатываются для работы с «веб-фермами», в которых группы серверов обрабатывают несколько экземпляров важных компонентов приложения, сохраняя данные состояния приложения во время его выполнения в удаленном хранилище, так что если какой-либо экземпляр приложения перестает работать по каким-либо причинам, то с помощью другого экземпляра можно восстановить или завершить выполняемый процесс. Иными словами, современные масштабируемые веб-приложения разбиваются на компоненты процессов и компоненты хранения, которые вместе с компонентами коммуникации и безопасности составляют единый, видимый внешнему миру «экземпляр» всего приложения.

Подъем многопользовательских служб

Многопользовательская архитектура платформы Windows Azure предусматривает декомпозицию приложений на службы без сохранения состояния и на хранилище. Управление потоком данных проводится при необходимости на основе удостоверений. Состояние вводится только для тех служб, которые напрямую работают с удостоверениями клиентов приложения. Все это следует общему принципу приложения, ориентированного на службы без сохранения состояния. Например, службы верхнего уровня, такие как веб-страницы и публично доступные веб-службы или сами службы безопасности, должны напрямую обрабатывать утверждения безопасности и токены. Однако другие компоненты и службы, которые являются частью более крупного приложения, должны разрабатываться с учетом того, что они могут повторно использоваться в любой части приложения при работе с любым клиентом.

Клиентов и их заказчиков не интересует вопрос о том, какая используется архитектура

В данном разделе подчеркивается одно: компании, выступающие в роли клиентов, и их заказчики не обязаны знать, на какой архитектуре построено приложение. Их интересует ТОЛЬКО то, как работает приложение: его надежность, производительность, набор функций и стоимость использования. Тем, что выходит за эти рамки, могут интересоваться только любопытные компьютерные фанаты. (Мы должны признать, что действительно бывают такие случаи, в которых может потребоваться продемонстрировать с помощью какой-то проверки, что вы ДЕЙСТВИТЕЛЬНО разрабатываете приложение с правильным учетом правовых или нормативных требований и требований к безопасности. Но это исключения, доказывающие правила. Это проверка соответствия предъявляемым требованиям, а не проверка архитектуры в чистом виде.)

Обзор многопользовательской службы Windows Azure

Ключевой проблемой при проектировании многопользовательской системы является обеспечение правильного баланса средств изоляции ресурсов клиента и стоимости предоставления этих выделенных ресурсов. Другими словами, следует рассчитать, сколько ресурсов может использоваться клиентами совместно, чтобы решение работало должным образом, но расходы были бы минимальными. Как правило, чем больше ресурсов может использоваться клиентами совместно, тем менее затратным является решение. Разумеется, при условии, что решение по-прежнему удовлетворяет требованиям к производительности и безопасности.

noteПримечание
Если вам не совсем понятны принцип многопользовательской поддержки или его значимость для приложений Windows Azure, прочитайте раздел Что такое многопользовательское приложение?. Затем можно продолжить чтение данного раздела.

В этой крупной проблеме основное внимание надо уделить следующим вопросам:

  • Безопасность — изоляция хранимых данных, механизмы авторизации и аутентификации

  • Масштабирование — автоматическое масштабирование вычислительной платформы, масштабирование платформы хранения

  • Управление и мониторинг

  • Подготовка ресурсов клиентов

  • Измерение показателей и выставление счетов

Учтите, что разработка многопользовательской архитектуры — это непростой процесс с различными аспектами, и в данной статье не дается описание каждого шага разработки. Скорее здесь приводится общий обзор основных соображений с многочисленными полезными советами и отсылками к деталям реализации. С учетом этих соображений начнем изучать архитектуру с верхнего уровня.

Архитектура верхнего уровня

Один из подходов к поддержке нескольких отдельных заказчиков заключается в полном отказе от многопользовательской поддержки и выделении ресурсов каждому клиенту по запросу. Применение такого однопользовательского (single tenant) подхода автоматизирует подготовку и предоставление клиентам выделяемых ресурсов. Если представить весь спектр архитектур распределенных приложений, то этот подход будет представлять, с одной стороны, полное выделение ресурсов, а с другой — полностью совместное использование ресурсов. В данной статье предпринята попытка описать метод разработки распределенных приложений, которые ближе к той части спектра архитектур, где все ресурсы используются совместно: это распределенные приложения с общими (или многопользовательскими) ресурсами данных и приложения.

При разработке многопользовательского приложения необходимо взвесить затраты на ресурсы и уровень изоляции, предоставляемый каждому заказчику. Легко понять, что необходимо продумать, какие ресурсы данных и приложения будут совместно использоваться заказчиками, а какие будут им выделяться индивидуально. Но следует помнить, что многопользовательская поддержка не подразумевает распределение ресурсов только методом «все или ничего». В сервисно ориентированном приложении в зависимости от требований вы можете и, скорее всего, будете какие-то ресурсы предоставлять всем заказчикам, а некоторые ресурсы выделять только отдельным заказчикам. Стоит подчеркнуть это снова: именно вы должны решить, какие службы приложений могут быть общими (и в какой степени), а какие не могут. Это дает огромную свободу проектирования приложения. Воспользуйтесь ею.

Какие ресурсы можно использовать совместно?

На рисунке ниже показаны рассматриваемые ресурсы Windows Azure; мы изучим некоторые из решений по использованию каждого из них. Полезный способ изучить все ресурсы на этой диаграмме (и в многопользовательской архитектуре в целом) заключается в том, чтобы для каждого компонента определить его местоположение в приложении или уровне данных.

Многопользовательские компоненты в Azure

На этой диаграмме вычислительная платформа Windows Azure и служба Access Control явно являются ресурсами уровня приложения и выступают в качестве промежуточных узлов, связывающих экземпляры, на которых производятся вычисления. Таблицы, большие двоичные объекты и база данных SQL явно являются ресурсами уровня данных. Службы кэширования и очереди часто выступают в качестве временного хранилища, которое позволяет использовать определенные приемы проектирования приложений и шаблоны взаимодействия. В результате зависимости от их использования эти службы могут рассматриваться и как хранилище, и как ресурсы уровня приложения.

Таким образом, выбранный подход зависит от того, сколько функций должно быть предоставлено клиенту приложения. К примеру, если вы хотите разрешить клиенту предоставлять своим заказчикам отдельную службу идентификации, то может потребоваться общая и независимая от клиентов служба токенов безопасности (STS) на основе пары из имени пользователя и пароля. Но можно также позволить клиенту реализовать собственную службу и интегрировать ее в службу управления доступом Access Control. Еще одним примером является разрешение заказчикам ваших клиентов загружать и выполнять код в экземплярах веб-ролей и рабочих ролей клиента. Для этого может потребоваться определенное многопользовательское решение, в котором сочетаются однопользовательские и многопользовательские экземпляры ролей.

Учитывая приведенные выше идеи, рассмотрим, как успешно совместно использовать ресурс. Хотя в этом и других разделах мы будем обсуждать с точки зрения приложения общие подходы к поддержке клиентов на одном ресурсе, мы также рассмотрим, как подготавливать эти ресурсы и управлять ими с помощью средств Azure. Подготовка совместно используемых ресурсов и управление ими не представляет проблемы, но в некоторых случаях следует уделить этим процессам более пристальное внимание.

Ресурсы приложения

Проектирование многопользовательского приложения подразумевает, что возможные компоненты вычислений, данных и другие компоненты приложения обрабатывают несколько удостоверений клиентов и, возможно, также удостоверения заказчиков каждого клиента. В этом разделе рассматриваются различные подходы к использованию Windows Azure и предлагаются лучшие способы их реализации в проекте приложения.

Вычисления

Начнем с рассмотрения предоставляемых веб-ролями и рабочими ролями Windows Azure ресурсов приложения и их применения в многопользовательском решении для размещения веб-служб, веб-сайтов и общей обработки.

Прямое назначение веб-ролей и рабочих ролей Windows Azure в многопользовательском приложении заключается в увеличении (или уменьшении!) предоставляемых клиентам вычислительных ресурсов с учетом того, что экземпляр одной роли обслуживает несколько клиентов.

Сегментирование клиентов веб-сайта по заголовкам узлов

В наиболее простой реализации каждый экземпляр веб-роли настраивается на поддержку множества веб-сайтов и веб-приложений, возможно с использованием одного экземпляра для каждого клиента. Это может быть достигнуто путем изменения элемента Sites в определении службы. Веб-сайты могут быть привязаны к одной и той же конечной точке, тогда для их изоляции можно использовать заголовок узла HTTP/1.1, или же они могут быть привязаны к собственным конечным точкам. Обратите внимание, что привязка каждого веб-сайта к его собственной конечной точке не позволяет выполнять масштабирование для каждого клиента, так как Windows Azure имеет ограничение в 5 входных конечных точек для экземпляра роли.

Если для поддержки нескольких клиентов используются заголовки узлов HTTP/1.1, то клиенты (и их заказчики) посещают различные URL-адреса (например, www.fabrikam.com или www.contoso.com) и открывают нужный веб-сайт, даже если они на самом деле обращаются к одной конечной точке одного экземпляра роли. Этот подход позволяет изолировать различные файлы веб-сайта клиента с минимальными усилиями. Как дополнительное преимущество, этот подход позволяет изолировать клиентов с помощью пула приложений, потому что по умолчанию каждый веб-сайт получает свой собственный пул приложений. Обратите внимание, что URL-адреса, которые обеспечивают заголовки узла HTTP/1.1, определены в службе доменных имен (DNS), поэтому необходимо настроить DNS на использование конкретного поставщика домена и задать ему конкретный адрес *.cloudapp.net. Помните, что может потребоваться 24 часа для того, чтобы новый URL-адрес клиента стал доступен в сети Интернет. Хороший пример того, как на одном экземпляре можно разместить несколько веб-сайтов, дифференцированных по заголовкам узлов, приведен в статье Акселератор Windows Azure и веб-роли.

Взаимодействие по протоколу SSL

Важная особенность использования заголовков узла HTTP/1.1 состоит в том, что Windows Azure не создает безопасные границы между веб-сайтами. Это означает, что SSL-сертификаты, используемые одним веб-сайтом, можно использовать на других сайтах. Дело усложняется тем, что IIS 7.0 не поддерживает несколько веб-сайтов с собственными сертификатами, если у них отличаются только заголовки узлов.

ImportantВажно!
Может быть несколько веб-сайтов SSL с уникальными сертификатами сервера, если каждый веб-сайт использует отдельный IP-адрес или порт для HTTPS-привязки. Как и IIS 6.0, версия IIS 7.0 не поддерживает несколько веб-сайтов с собственными сертификатами сервера, если HTTPS-привязки сайтов относятся к одному и тому же IP-адресу или порту и отличаются только заголовками узлов. Это связано с тем, что данные заголовка узла недоступны, когда происходит согласование по протоколу SSL. Из-за этого единственный способ иметь несколько веб-сайтов на одном IP-адресе с заголовками узлов заключается в том, что необходимо настроить все веб-сайты на использование одного и того же SSL-сертификата с подстановочным CN. Для получения дополнительной информации см. статью http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true.

Таким образом, при использовании SSL-сертификатов может потребоваться другой подход. Первый способ состоит в использовании одного сертификата с подстановочным CN (вида *.yourdomain.com) или сертификата унифицированных коммуникационных решений (где все поддомены указываются явно). Эти типы сертификатов можно получить в центрах сертификации, таких как GoDaddy и Thawte, создать их несложно. Каждый клиент будет иметь доступ к ресурсам через SSL с использованием URL-адреса вида https://fabrikam.yourdomain.com или https://contoso.yourdomain.com.

Альтернативный способ заключается в использовании для каждого веб-сайта отдельной веб-роли и только одного сертификата клиента. Поскольку это не многопользовательский подход, масштабирование происходит хуже, при этом требуется больше вычислительных ресурсов и увеличиваются затраты на управление системой. Но в некоторых случаях следует использовать именно этот подход.

Сегментация клиентов веб-сайта по параметрам запроса

Другой подход заключается в том, чтобы использовать единый веб-сайт для предоставления ресурсов нескольким клиентам. Если веб-сайт создан с использованием ASP.NET MVC, то для каждого клиента можно создать отдельную область MVC. В качестве альтернативы они могут совместно использовать область по умолчанию, при этом контроллеры будут формировать выходные результаты в зависимости от параметров запроса (например, по идентификатору клиента). Для изоляции процесса каждого клиента требуется на веб-сайте определить виртуальные приложения. Фактически каждый клиент получает виртуальное приложение в пределах веб-сайта. Это также выполняется путем редактирования элемента Sites в определении службы, но вместо добавления нового сайта для каждого клиента в главном элементе Site добавляется один элемент VirtualApplication для каждого клиента.

Веб-службы в рабочих ролях

В полностью многопользовательских решениях рабочие роли, размещающие веб-службы, ведут себя так же, как и объекты, размещенные в веб-роли, — все клиенты обращаются к одним и тем же конечным точкам службы.

Рабочие роли используются также для выполнения фоновой обработки. В полностью многопользовательском сценарии используется подход, при котором метод RoleEntryPoint.Run рабочей роли обрабатывает рабочие элементы независимо от того, какой клиент создал роль, так как вычислительные ресурсы распределяются по всем клиентам.

Хранилище

Многопользовательские приложения должны учитывать, как их данные хранятся и изолируются, обеспечивая при этом хорошую производительность. В этом разделе обсуждаются технологии хранения данных в Windows Azure, используемые в многопользовательском приложении, включая базы данных SQL, большие двоичные объекты, таблицы и очереди, очереди Service Bus и службу Caching Service.

Хранилище в виде базы данных SQL, несомненно, является важным местом хранения данных приложения, но его роль в многопользовательском приложении расширяется: база данных используется для провизионирования новых клиентов и хранения сведений для управления системой.

Использование базы данных SQL для ресурсов приложения

В этом сценарии данные приложения для нескольких клиентов хранятся в одной логической базе данных. Хотя есть очевидная выгода в использовании многопользовательской базы данных (расходы распределяются по всем клиентам), но обеспечить соответствие специфическим требованиям этого сценария становится сложнее. При этом необходимо:

  • Обеспечивать адекватную изоляцию данных и предотвращать случайный или злонамеренный доступ одного клиента к данным другого клиента.

  • Поддерживать достаточную производительность запросов для всех клиентов в дополнение к ограничению потребностей одного клиента, потребляющего ресурсы в больших количествах.

  • Учитывать быстро увеличивающий размер общей базы данных, который может превысить максимальный размер базы данных в 150 ГБ, который в настоящее время поддерживается для баз данных SQL.

По существу при распределении данных клиентов и запросов по нескольким базам данных наблюдается прирост производительности. Вопрос в том, какие архитектуры позволяют использовать подобный подход. Прежде чем мы ответим на этот вопрос, будет полезно взглянуть на спектр архитектур. На одном конце этого спектра находится традиционное вертикальное масштабирование, при котором для решения проблемы просто выделяется больше оборудования. Как и при обсуждении архитектуры для приложения одного клиента, мы не будем уделять внимание вертикальному масштабированию, кроме тех случаев, когда это помогает пониманию обсуждаемой темы. Традиционный подход слишком ограничен при использовании в многопользовательских решениях. Мы сосредоточим внимание на различных подходах к горизонтальному масштабированию, используя следующие методы сегментирования:

  • линейное сегментирование,

  • расширенное сегментирование,

  • сжатое сегментирование и

  • гибридное линейное/расширенное сегментирование.

Диаграмма базовых подходов к сегментированию.

Все предыдущие четыре полезных метода сегментирования используются в архитектуре базы данных для обеспечения горизонтального сегментирования, и в каждом подходе предусмотрено логическое разделение хранимых данных (домены данных или федерации данных), определяющее сегменты. Эти домены данных могут быть заданы с помощью определенных значений ключа (например, по идентификатору заказчика) или атрибута (например, по году). Для упрощения статьи и в контексте многопользовательских архитектур под доменом данных мы будем подразумевать клиента.

Вернемся к диаграмме спектра. На одном конце спектра находится традиционная модель вертикального масштабирования. В данном подходе все клиенты используют одну и ту же базу данных SQL. Иными словами, на базу данных приходится несколько клиентов. В центральной части спектра диаграммы представлена архитектура линейного сегментирования, в которой каждый клиент получает свою собственную базу данных SQL. На дальнем конце спектра каждый клиент может получить несколько баз данных SQL, это расширенное сегментирование.

Два других подхода используют промежуточные решения. В архитектуре сжатого сегментирования баз данных меньше, чем клиентов, но используется более одной базы данных SQL. Аналогично сценарии с несколькими доменами данных, для которых принимаются решения по сегментированию (например, по региону и клиенту), называются сценариями с гибридным линейным и расширенным сегментированием, при этом каждый регион получает определенный расширенный сегмент с несколькими базами данных. Данные конкретного клиента распределяются по нескольким базам данных в этом сегменте. Другими словами, архитектура масштабируется по регионам линейно, а для клиентов в расширенной форме. Эти подходы к сегментированию требуют наличия уровня абстракции, например на основе библиотеки Enzo SQL Shard Library, в которой можно осуществлять навигацию по реализованной архитектуре сегментирования, в частности распределение запросов по всем сегментам и направление операций по изменению данных в соответствующий сегмент.

Обеспечение безопасности данных клиентов в базе данных SQL

Вначале рассмотрим методы обеспечения безопасности данных клиентов. По сути обеспечение безопасности на уровне базы данных SQL идентично ее обеспечению в локальном SQL Server. Это равносильно созданию субъектов безопасности и их использованию для управления доступом к определенным объектам схемы (таблицам, представлениям, хранимым процедурам, схемам и т. д.). Затем для каждого клиента создаются соответствующие имена пользователей SQL Server, пользователи и роли базы данных и применяются разрешения к объектам схемы с помощью этих субъектов безопасности. Первый подход состоит в определении одной схемы для одного клиента; меры безопасности, применяемые к схемам, обеспечивают доступ только этому клиенту.

Другой подход заключается в том, что данные всех клиентов хранятся в одном наборе таблиц, разделение их происходит по некоторому ключу (например, по столбцу с идентификатором клиента), тем самым создается логическое разделение данных. В этом подходе логика бизнес-уровня отвечает за правильную фильтрацию обращений клиентов к данным. Суть этого подхода заключается в том, что все запросы к данным должны проходить через эту логику, тем самым доступ предоставляется только правильно заданным клиентам. Технология OData (использующая службы WCF Data Service на основе перехватчиков запросов и изменений) является отличным примером реализации данного подхода. Некоторые платформы, такие как описываемая ниже Enzo, избавляют от необходимости реализовывать эту логику.

Учитывая это, применим подобный подход к ранее описанным архитектурам вертикального масштабирования. Меры безопасности в архитектуре линейного сегментирования могут быть довольно простыми: каждый клиент получает свою собственную базу данных и в силу этого получает отдельные учетные данные и пользователей для своего сегмента. Во всех других архитектурах сегментирования меры безопасности должны быть более тонкими и полагаться на сочетание разрешений, определенных на уровне объекта схемы и обеспечиваемых на уровне бизнес-логики.

Вопросы производительности

Далее рассмотрим производительность. В базе данных SQL поддерживаются три реплики любой базы данных SQL. Хотя данные реплицируются между основной и двумя вторичными репликами, все операции чтения и записи происходят только в основной реплике, вторичные реплики используются только при обработке запросов во время восстановления после сбоя. Структура базы данных SQL Windows Azure определяет расположение основной и двух вторичных реплик. Если машина, на которой размещается основная реплика, испытывает значительную нагрузку (из-за обращений ваших или других клиентов), то структура базы данных SQL может сделать вторичную реплику основной на другой машине с меньшей рабочей нагрузкой. Переключение происходит быстро, но это приводит к отключению активных сеансов — к ситуации, с которой должно справляться многопользовательское приложение.

Поэтому, если производительность приложения для отдельных клиентов является главным приоритетом, следует рассматривать архитектуру сегментирования, в которой выделяется одна или несколько баз данных для каждого клиента (это архитектуры линейного, расширенного и гибридного сегментирования). Но если клиентов, для которых базы данных выделяются подобным образом, много, то возникнет несколько препятствий. Разумеется, каждая создаваемая база данных требует некоторых расходов на ее содержание, но препятствие заключается в том, что на сервере баз данных SQL может размещаться 149 баз. Этот предел может быть повышен при обращении в службу поддержки облачных служб Cloud Support Services (CSS). В сценариях с многопользовательским приложением с большим количеством баз данных необходимо также иметь возможность выделить дополнительные серверы баз данных SQL при приближении к этому пределу.

Использование таблиц Windows Azure в качестве ресурсов приложения

Безопасность таблиц Windows Azure обеспечивается с помощью имени учетной записи хранения и ключа, которые могут быть выделены только глобально для всех ресурсов хранения. Это означает, что для обеспечения изолированного хранения данных каждого клиента поставщик услуг должен создать учетную запись хранения для каждого клиента. Это может быть выполнено с помощью API-интерфейса Windows Azure Service Management. Дополнительные расходы при выделении новых учетных записей хранения отсутствуют, и за счет этого может быть также получен прирост производительности, поскольку разным учетным записям могут выделяться различные ресурсы. Тем не менее существуют квоты, регулирующие количество учетных записей хранения на одну подписку, и эти квоты могут быть изменены при обращении в службу поддержки облачных служб Cloud Services Support (CSS).

Если конкретному приложению требуется хранить большое количество данных нескольких клиентов в одной учетной записи, то необходимо создать собственный уровень абстракции для фильтрации данных, возвращаемых конкретному клиенту. Первый подход состоит в создании одной таблицы для каждого клиента и предоставлении доступа на уровне таблиц. Этот подход полезен тем, что можно использовать полный ключ раздела и ключ строки для быстрого доступа к данным, при этом логика маршрутизации запросов к нужной таблице очень проста. Недостатком является дополнительная сложность, заключающаяся в том, что приходится направлять запросы в соответствующую таблицу клиента. Другой подход заключается в горизонтальном разделении данных по клиентам в пределах таблицы. На уровне доступа к данным клиенту возвращаются только данные с определенным ключом раздела. Это устраняет необходимость направлять запросы в соответствующую таблицу, но в связи с этим приходится ограничиваться использованием одного значения ключа раздела, что в свою очередь может повлиять на производительность при использовании очень больших наборов данных для отдельных клиентов.

Использование больших двоичных объектов Windows Azure в качестве ресурсов приложения

Большие двоичные объекты Windows Azure — это отличное средство хранения данных многопользовательских приложений. Следует создавать открытые BLOB-контейнеры с доступом только для чтения и хранить в них общие данные, например изображения для веб-сайта, графику и логотипы клиентов. Закрытые BLOB-контейнеры (доступные только клиентам приложения или клиентам системы) будут использоваться для хранения данных приложения, таких как документы или файлы конфигурации отдельных клиентов. Без учета анонимного доступа ключевой подход заключается в том, чтобы указать политики доступа уровня контейнера для контейнеров или больших двоичных объектов, защищенных с помощью подписей коллективного доступа, для различных действий, таких как операции чтения/записи, использование черного списка, свойств или метаданных, удаление, лизинг и перечисление больших двоичных объектов в контейнере. Определение политики доступа на уровне контейнера обеспечивает настройку разрешений без необходимости выпускать новый URL-адрес для ресурсов, защищенных подписями коллективного доступа.

Использование очередей Windows Azure в качестве ресурсов приложения

Очереди Windows Azure обычно используются для обработки задач клиентов, но также могут использоваться для распределения задач по провизионированию и управлению системой.

Следует определиться, будет ли использоваться определенная очередь для управления объектами нескольких клиентов, или каждому клиенту будет выделена своя очередь. Модель хранения Windows Azure действует только на уровне учетной записи хранения, поэтому если очереди должны быть изолированы для отдельных клиентов, то они должны создаваться под отдельными учетными записями хранения, так же как и таблицы. Кроме того, в случае использования отдельных очередей не представляется возможным определить разрешения, ограничивающие использование очереди только для отправления или получения сообщений: как только клиент получает доступ к учетной записи хранения, то может использовать все функции API-интерфейса Azure Queue и даже удалять общие очереди! Короче говоря, очереди не должны предоставляться клиенту, службе следует управлять ими автоматически.

Применение очередей Service Bus в качестве ресурсов приложения

Для специфических клиентских функций приложения, отправляющих запросы к общей службе, можно использовать одну очередь, в которую каждый клиент-отправитель имеет разрешение (определяемое утверждениями, выданными сервером управления доступом) помещать сообщения. Считывать из очереди данные от различных клиентов имеют право только получатели службы. Реализация обратного направления подобного потока данных возможна с помощью очередей шины обслуживания, где системные службы отправляют в одну очередь сообщения, предназначенные для конкретных клиентов-получателей. Эти сообщения также можно отправлять с помощью многоадресной рассылки, используя функциональность подписок очередей шины обслуживания. И наконец, можно использовать сессионные сообщения для передачи задач отдельных заказчиков соответствующим получателям, но при использовании только одной общей очереди.

Безусловно, эти подходы минимизируют количество используемых очередей, которыми нужно управлять (что в некоторой степени снижает общую сложность системы), но они могут ограничить пропускную способность операций отправки и получения данных из очереди, потому что нагрузка не распределяется по нескольким ресурсам (как это может быть при использовании нескольких очередей). Кроме того, если существует множество клиентов-отправителей, следует учитывать опасность того, что отдельный клиент может заполнить всю очередь своими запросами, а это приведет к тому, что запросы остальных обслуживаться не будут. При использовании очередей шины обслуживания сообщения могут быть отложены, поэтому есть возможность обнаружить лавину сообщений, поступающих от одного клиента, временно отложить эти сообщения для обработки сообщений от других клиентов и позднее вернуться к обработке отложенных сообщений.

Служба кэширования в качестве ресурсов приложения

В рамках многопользовательского приложения кэш традиционно используется для часто запрашиваемых данных приложения, относящихся к определенным клиентам. Для поддержки нескольких клиентов в службе кэша можно создать именованные кэши или предусмотреть по одному экземпляру службы кэша для каждого клиента.

Службы безопасности и соединения

Многопользовательские приложения Windows Azure используют другие «промежуточные» службы для подключения и обеспечения безопасности: службы ретрансляции шины обслуживания и службы управления доступом (ACS) Windows Azure.

Использование ACS для ресурсов приложения

Служба управления доступом (ACS) Windows Azure

Это облачная служба, предоставляющая простой способ аутентификации и авторизации пользователей, которым нужен доступ к конкретным веб-приложениям и службам; при этом функции аутентификации и авторизации вынесены за пределы используемого кода. Вместо реализации системы аутентификации с учетными записями пользователей, которые предназначены специально для данного приложения, можно передать управление процессами проверки подлинности и авторизации пользователей службе ACS. ACS интегрируется с поставщиками удостоверений, использующими стандарты идентификации, такие как каталоги предприятий наподобие Active Directory, и веб-удостоверения, в частности Windows Live ID, Google, Yahoo! и Facebook. (Дополнительные сведения приведены в статье.)

ACS предоставляет способ ограничить доступ к приложению, независимо от того, является оно многопользовательским или нет. С помощью ACS можно создать приложение, использующее один API-интерфейс аутентификации (ACS API), который будет обрабатывать токены безопасности от любого поставщика удостоверений. Это означает, что не надо писать отдельный код для Facebook, Google, Yahoo, Windows Live, других сторонних поставщиков удостоверений или сервера федерации Active Directory (ADFS). Вместо этого создается код только для работы с ACS, и системы контроля доступа вместе с поставщиками удостоверений сами выполняют всю необходимую работу.

Подготовка удостоверений в ACS

Подробности настройки ACS или вопросы, касающиеся реализации собственной службы токенов безопасности, не освещаются в рамках данного документа, но вы можете получить нужные сведения в статье «Авторизация на основе утверждений безопасности в веб-службах и приложениях». Чтобы изучить основы подхода, при котором вопросы безопасности приложения решаются за счет федеративной безопасности, см. это отличное руководство. Можно получить основные сведения о построении собственной службы токенов безопасности с помощью платформы Windows Identity Foundation (WIF) в данной статье, но лучше всего начать с использования полноценной службы, такой как Thinktecture Starter STS, и ее настройки для конкретных потребностей.

В рамках многопользовательского приложения, использующего ACS, подготовка удостоверений на верхнем уровне обычно осуществляется следующим образом.

  • Создаются сертификаты (например, для каждого клиента).

  • Выделяются ресурсы пространства имен ACS (если изоляция проводится по пространству имен) с конфигурацией защищаемого приложения клиента, которое называется проверяющей стороной (relying party - RP), и задаются правила преобразования утверждений. Это делается с помощью API-интерфейса или портала ACS.

  • Создается учетная запись основного администратора, в которую клиент выполняет вход (с использованием API-интерфейса службы поставщика токенов безопасности).

Использование ретрансляции Service Bus для ресурсов приложения

Службы, которые представляются как конечные точки, могут принадлежать клиенту (как службы, размещаемые вне системы, на локальном сервере и т. п.) или это могут быть службы, специально выделенные клиенту (потому что через них проходят важные данные, относящиеся к клиенту). В любом случае поддержка нескольких клиентов не является проблемой, а вот обеспечение принудительного использования ресурсов клиентами является затруднительным. Доступ к этим конечным точкам обеспечивается с помощью службы управления доступом (ACS), в которой клиенты должны предоставить имя поставщика и ключ, токен SAML или токен Simple Web Token. Это можно настроить программно с помощью API-интерфейсов Service Bus и ACS.

noteПримечание
Помните, что очереди и подписки Service Bus рассматриваются в качестве средств хранения, хотя они часто служат для обработки определенным образом потока данных приложения.

Провизионирование ресурсов

В этом разделе рассматривается провизионирование ресурсов для поддержки многопользовательских приложений. Проектирование системы управления ресурсами для многопользовательских приложений подразумевает принятие нескольких ключевых решений, которые зависят от функций приложения и используемых служб Windows Azure.

Мы обсудим, какие службы хранения, подключения, безопасности и вычислительные службы используются для провизионирования многопользовательских приложений.

Предоставление ресурсов и управление ими с помощью ролей Azure

Обычно для предоставления ресурсов клиентам и их отзыва используется выделенная рабочая роль (например, когда регистрируется новый клиент или удаляется старый), также она используется для сбора метрик и масштабирования по расписанию или в ответ на превышение определенных пороговых значений ключевых показателей эффективности. Эта же роль может использоваться для проведения обновлений и обновления версии решения.

Веб-роль обычно позволяет поставщику услуг управлять системными ресурсами и отслеживать их, просматривать журналы, счетчики производительности, провизионировать систему вручную и так далее.

Использование ACS для подготовки и предоставления ресурсов

При провизионировании ресурсов клиентов, защищенных с помощью ACS, необходимо использовать API-интерфейс управления ACS или портал ACS, чтобы создать первоначальную учетную запись администратора для вновь добавленных клиентов.

Использование службы кэша для подготовки и предоставления ресурсов

При провизионировании ресурсов клиентов, защищенных с помощью ACS, необходимо использовать API-интерфейс управления ACS или портал ACS, чтобы создать первоначальную учетную запись администратора для вновь добавленных клиентов.

Рекомендации по подготовке и предоставлению хранилища

В многопользовательском приложении при работе с таблицами, большими двоичными объектами и базами данных SQL Windows Azure следует учитывать их географическое распределение. Идентификационные данные должны быть уникальными по всей системе (на всех центрах обработки данных, используемых в решении), при этом требуется обеспечить баланс с производительностью работы пользователей. Одним из вариантов является создание собственной стратегии репликации, чтобы данные находились рядом с конечными пользователями (при этом необходимо обеспечить уникальность новых данных; возможно, для этого вставка данных должна происходить в главном источнике данных). Другой вариант — секционирование данных таким образом, чтобы минимизировать объем и частоту доступа к глобальным данным.

Еще одним соображением, которое следует учитывать, являются пределы размеров хранения в Azure Storage, которые не бесконечны, хотя и велики. При планировании многопользовательского решения следует учитывать эти ограничения масштабирования во внимание.

Использование базы данных SQL для подготовки и предоставления ресурсов

В некоторых сценариях для нескольких клиентов, где задействовано большое количество данных, лучше всего подготовить создание новых баз данных SQL путем копирования существующего эталонного экземпляра базы данных SQL. Следует оценить получаемое в результате улучшение скорости выделения ресурсов с учетом расходов на содержание дополнительной базы данных SQL помимо тех баз, что требуются клиентам и самой системе.

Подготовка и предоставление ресурсов базы данных SQL

Подготовка и предоставление ресурсов новой базы данных SQL клиента может выполняться следующими способами:

  • Использование инструкций языка DDL в скриптах или в качестве внедренных в сборки ресурсов.

  • Создание пакетов приложения уровня данных SQL Server 2008 R2 и их развертывание с помощью API-интерфейсов. Можно также выполнять развертывание из пакета приложения уровня данных хранилища больших двоичных объектов Windows Azure в базу данных SQL, как показано в этом примере.

  • Копирование основной эталонной базы данных

  • Использование функций импортирования и экспортирования базы данных для подготовки и предоставления новых баз из файлов.

Провизионирование хранилища больших двоичных объектов Windows Azure

Подход к провизионированию хранилища больших двоичных объектов заключается в том, что вначале создаются контейнеры, после чего к каждому из них применяется политика, создаются и применяется ключи общего доступа к защищенным контейнерам и большим двоичным объектам.

Использование больших двоичных объектов Windows Azure для подготовки и предоставления ресурсов

Что касается провизионирования вычислительных ресурсов и предварительно инициализированных ресурсов хранения для новых клиентов, то хранилище больших двоичных объектов Azure должно быть защищено политикой уровня контейнера (как описано выше) для защиты CS-пакетов, VHD-изображений и других ресурсов.

Управление ресурсами

И наконец, проект многопользовательского приложения должен учитывать очень важный аспект управления приложением, клиентами и их службами, всеми ресурсами данных и любыми вопросами, связанными с безопасностью и обеспечением связи при использовании этих ресурсов. В этом разделе обсуждаются общие методы использования вычислительных ресурсов, данных и других служб, применяемых при реализации многопользовательского приложения с помощью Windows Azure.

Использование ролей Windows Azure для управления ресурсами

Поставщику услуг требуется способ мониторинга и управления системными ресурсами. Веб-роль обычно предназначена для того, чтобы поставщик услуг мог управлять системными ресурсами и отслеживать их, просматривать журналы, счетчики производительности, осуществлять провизионирование вручную и т. п.

Использование ACS для ресурсов управления

Большинству многопользовательских систем требуется пространство имен, созданное в рамках ACS, которое используется для обеспечения безопасности системных ресурсов, а также для создания отдельных пространств имен для клиентов и управления ими. Для этого также используется пространство имен управления ACS.

Использование службы кэша для ресурсов управления

Если поставщик услуг предоставляет определенные ключевые показатели эффективности или вычисляемую статистику всем клиентам, то, возможно, потребуется кэшировать эти часто запрашиваемые значения. Сами клиенты не получают прямой доступ к кэшу и должны проходить через некоторый промежуточный уровень (например, через службы WCF), на котором хранятся фактический ключ авторизации и URL-адрес для доступа к кэшу.

Использование базы данных SQL для ресурсов управления

Примером может служить одиночная, системная, не зависящая от центра обработки и ролей база данных для нефедеративных клиентов или тех клиентов, которые используют нестандартную службу токенов безопасности, настроенную на использование с ACS. В многопользовательских системах с широким географическим распределением пользователей создание централизованной системы управления данными может вызвать проблемы. Для решения этих проблем может использоваться подход, описанный ранее для ресурсов приложения, когда географические регионы определяются как сегменты в архитектуре гибридного сегментирования или более простой архитектуре линейного сегментирования. В обоих случаях используется логика промежуточного уровня для сбора и обобщения данных для запросов мониторинга и управления системой.

Использование таблиц Windows Azure в качестве ресурсов управления

Инфраструктура диагностики Windows Azure (WAD) по умолчанию предусматривает ведение журналов в таблицах Windows Azure. При использовании подобных WAD-таблиц (для трассировки, ведения журналов событий и хранения счетчиков производительности) необходимо учитывать конфиденциальность данных журнала, кто имеет к ним доступ, и на этом основании решить, будут ли они изолированы для отдельных заказчиков, или будут совместно использоваться по всей системе. Например, маловероятно, что всем клиентам будет предоставлен прямой доступ к таблицам журнала диагностики, в которых накапливаются сведения о событиях по всем экземплярам решения, что позволит одним клиентам получать доступ к данным других клиентов.

Использование больших двоичных объектов Windows Azure в качестве ресурсов управления

Обычно в качестве ресурсов управления в BLOB-хранилище хранятся журналы IIS и аварийные дампы. Журналы IIS передаются в хранилище больших двоичных объектов из экземпляров ролей. Если мониторинг системы полагается на журналы IIS, то доступ к этим журналам следует предоставить только системе через политику доступа на уровне контейнера. Если клиентам понадобятся некоторые из этих данных, то, возможно, потребуется выполнить некоторую обработку данных (чтобы гарантировать предоставление клиенту только его набора данных) и далее передать результаты в конкретный контейнер клиента. Доступ к аварийным дампам обычно имеет только поставщик услуг, так как они помогают устранять неполадки в инфраструктуре и содержат данные, касающиеся всех клиентов.

Сбор значений показателей

В многопользовательских приложениях сбор показателей осуществляется для выставления счетов клиентам с учетом использования системы, а также для сбора системных значений ключевых показателей эффективности, которые учитываются при планировании загрузки системы и принятии решений, касающихся ее архитектуры. Что измеряется? Обычно измеряется следующее.

  • Потребление ресурсов в чистом виде: использование ресурсов Windows Azure (например, продолжительность вычислений в часах, размер хранилища данных, количество сообщений)

  • Использование определенных функций приложения (например, может взиматься оплата за использование операций премиум-класса)

  • Использование приложения пользователями клиента

Два последних случая, как правило, определяются конкретными требованиями к приложению, поэтому мы сосредоточим внимание на сборе показателей потребления первичных ресурсов, что касается всех приложений на основе платформы Azure. Из первичных ресурсов для большинства облачных приложений SaaS наибольшую важность имеет продолжительность вычислений в часах, далее следуют размер хранилища и в меньшей степени объем передаваемых (исходящих) данных из центров обработки, ведь теперь данные в центры обработки данных Azure передаются бесплатно.

Так как же получить данные измерений продолжительности вычислений и использования хранилища? Рассмотрим несколько примеров.

Продолжительность вычислений в часах

К сожалению, в настоящее время API-интерфейс для запроса подобной информации в рамках подписки поставщика услуг отсутствует. Наилучший подход заключается в том, чтобы дать приблизительную оценку в соответствии с тарификацией времени в Windows Azure. Например, для каждого выделенного экземпляра вычисляется время его работы. Время округляется до часа и умножается на стоимость часа работы экземпляра соответствующего размера.

Хранение данных

Не существует открытого API-интерфейса выставления счетов или управления для объектов хранения Windows Azure (BLOB-данных, таблиц и в меньшей степени очередей), а также кэшей и очередей Service Bus, который позволял бы получить точные данные об использовании, но можно получить экстраполированные данные на основе определения размера хранимых сущностей и оценки среднего количества сущностей, хранимых для клиента за период тарификации. Размер базы данных SQL является исключением. Можно определить размер базы данных, за дневное использование которой выставляется счет, с помощью запроса sys.database_usage к базе данных master и суммирования результатов за месяц для получения фактической стоимости использования базы.

Масштабирование вычислительных мощностей для многопользовательских решений

Хотя, безусловно, конкретные требования различаются от приложения к приложению, при автоматическом масштабировании все сводится к тому, что количество экземпляров уменьшается или увеличивается в зависимости от определенной эвристики. Этот эвристический алгоритм может зависеть от некоторых ключевых показателей эффективности, полученных, например, из журналов производительности, журналов IIS или установленных даже с учетом глубины очередей. С другой стороны, масштабирование можно выполнять в соответствии с определенным расписанием, например увеличивать количество экземпляров в конце месяца, когда происходит всплеск активности (например, в бухгалтерских приложениях), и уменьшать это количество во всех остальных случаях.

Следует учитывать, что масштабирование количества экземпляров не происходит мгновенно. В применяемых алгоритмах это должно учитываться двумя способами. При масштабировании с увеличением лучше всего иметь возможность прогнозировать рост нагрузки, причем это не обязательно должен быть долговременный прогноз (в пределах 20 минут), чтобы экземпляры успевали запуститься. При масштабировании с уменьшением следует помнить, что при частичном использовании часа оплата осуществляется как за полный час, поэтому экономически выгодно сохранять ненужные экземпляры до конца часа.

Заключение и другие полезные материалы

Платформы и примеры

Прочитав данную статью, вы, пожалуй, согласитесь с тем, что разработка многопользовательского решения связана со значительными вложениями. Учитывая это, рекомендуется приступать к работе с использованием примера или платформы разработки. Ниже перечислены важные стартовые точки.

Пакет интеграции Enterprise Library 5.0 для Windows Azure

Библиотека Microsoft Enterprise Library — это набор многократно используемых прикладных блоков, которые используются при решении общих задач разработки программного обеспечения предприятий. Пакет интеграции библиотеки Microsoft Enterprise Library для Windows Azure является расширением библиотеки Enterprise Library 5.0, который позволяет использовать ее с платформой Windows Azure. Он включает в себя блок автоматического масштабирования приложения, блок обработки временных сбоев, источник больших двоичных объектов конфигураций, защищенный поставщик конфигураций и учебные материалы. Этот набор блоков — отличное начало.

CloudNinja

Пример CloudNinja, доступный на CodePlex, демонстрирует следующие аспекты многопользовательской архитектуры, описанные в этой статье.

  • Веб-роли в многопользовательском приложении

  • Выделенные рабочие роли управления и провизионирования

  • Линейное сегментирование в базе данных SQL

  • Выделенные таблицы управления Windows Azure

  • Выделенные очереди Azure для провизионирования

  • Выделенные открытые и закрытые хранилища больших двоичных объектов

  • Кэш для многопользовательских приложений

  • Автоматическое масштабирование на основе расписания и ключевых показателей эффективности

  • Сбор значений показателей

  • Федеративная безопасность на основе собственной системы токенов безопасности и ACS

Fabrikam Shipping

Пример «Fabrikam Shipping», доступный на сайте Codeplex, демонстрирует многие аспекты многопользовательского решения.

  • Выделенные веб-роли в многопользовательском приложении

  • Выделенные рабочие роли управления и провизионирования

  • Линейное сегментирование в базе данных SQL

  • Выделенные открытые и закрытые хранилища больших двоичных объектов

  • Федеративная безопасность с нестандартной системой токенов безопасности, Facebook, Google, Live ID и ACS

  • Интеграция с PayPal

Библиотека Enzo SQL Shard

Библиотека Enzo SQL Shard, доступная на сайте CodePlex, демонстрирует и помогает использовать многочисленные методы сегментирования баз данных SQL, которые обсуждались в данной статье.

Платформа Lokad Cloud

Платформа Lokad Cloud — это платформа с богатыми возможностями, позволяющая реализовать многие описанные в этой статье методы.

  • Автоматическое масштабирование

  • Строго типизированное хранилище больших двоичных объектов, таблиц и очередей (его принято называть модулем сопоставления объектов в облако).

  • Диспетчер задач

  • Ведение журнала

Автоматическое масштабирование Azure

Если вы ищете простой, понятный пример, на основе которого можно реализовать собственное автоматическое масштабирование, то стоит посмотреть данный пример, доступный на сайте CodePlex. Конечно, имеются также некоторые платные решения, помогающие реализовать некоторые наиболее сложные аспекты. В частности, решение Paraleap AzureWatch может помочь в реализации автомасштабирования приложения.  

Ссылки и материалы

Многопользовательская архитектура

См. также

Добавления сообщества

Показ:
© 2014 Microsoft