Экспорт (0) Печать
Развернуть все
Развернуть Свернуть
1 из 1 оценили этот материал как полезный - Оценить эту тему

Рекомендации по проектированию крупномасштабных служб в облачных службах Windows Azure

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

Авторы: Марк Симмс (Mark Simms) и Майкл Томасси (Michael Thomassy)

Соавторы: Джейсон Рот (Jason Roth) и Ральф Скуиллейс (Ralph Squillace)

Рецензенты: Брэд Кэлдер (Brad Calder), Деннис Малдер (Dennis Mulder), Марк Озур (Mark Ozur), Нина Саравжи (Nina Sarawgi), Марк Меркури (Marc Mercuri), Конор Каннингем (Conor Cunningham), Питер Карлин (Peter Carlin), Стюарт Озер (Stuart Ozer), Лара Раббилк (Lara Rubbelke), Николас Дрицас (Nicholas Dritsas).

Общие сведения

Облачные вычисления являются распределенными, а распределенные вычисления требуют тщательного планирования и доставки данных независимо от выбранной платформы. Цель данного документа — дать подробное руководство по созданию реальных клиентских сценариев создания масштабируемых приложений на Windows Azure и базах данных SQL Server на основе подхода «платформа как служба» (PaaS). Такие приложения создаются в виде облачных служб Windows Azure, где используются веб-роли и рабочие роли.

ImportantВажно!
ПРИМЕЧАНИЕ. Практическая польза от этого руководства основана на тесной работе с клиентами, производственный код которых работает в Windows Azure. В настоящем документе рассматривается платформа PaaS облачных служб Windows Azure, построенная на основе пакета SDK версии 1.6. Обсуждение не касается таких функций, как веб-сайты Windows Azure или виртуальные машины Windows Azure (IaaS).

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

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

  • Трансформация или консолидация капиталовложений в эксплуатационные расходы.

  • Сокращение затрат (и повышение эффективности) за счет более точного соответствия нагрузки и производительности.

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

  • Повышение доступности для аудитории новых рынков (например, мобильных услуг).

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

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

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

Необходима оценка приложения по следующим важнейшим аспектам:

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

  • Распределенные пользователи и устройства. Запуск в Windows Azure дает немедленный доступ к глобальному развертыванию приложений. Если же рабочая нагрузка имеет кучную пользовательскую базу на единственной площадке (например, в одном офисе), то облачное развертывание не поможет добиться оптимальной рентабельности инвестиций.

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

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

Концепции проектирования

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

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

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

Горизонтальное масштабирование — это не наращивание мощности

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

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

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

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

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

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

Все имеет свои пределы: будьте готовы к масштабированию

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

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

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

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

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

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

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

В данном документе мы будем пользоваться термином «единица масштабирования» для обозначения группы ресурсов, которые могут (а) обрабатываться с определенной степенью нагрузки и (б) соединяться вместе для обработки дополнительной нагрузки. Например, учетная запись хранилища Windows Azure имеет максимальный размер 100 ТБ. Если вам необходимо сохранить более 100 ТБ данных, то потребуется использование нескольких учетных записей (т. е. будет как минимум две единицы масштабирования хранилища).

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

Проектирование для повышения доступности

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

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

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

Высокоуровневые компоненты обеспечивают гибкость посредством тесно связанной избыточности, когда имеется плотная «интеграция» между компонентами. Примеры:

  • SQL Server. Добавление избыточного экземпляра SQL Server в составе активного или пассивного кластера требует тщательного выбора совместимого (то есть идентичного!) оборудования и общего хранилища (например, сети хранения данных), чтобы обеспечить транзакционную согласованность отработки отказа между несколькими узлами.

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

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

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

Опыт масштабирования систем (подробнее дискуссию см. в документе http://www.mvdirona.com/jrh/TalksAndPapers/JamesRH_Lisa.pdf) показывает, что в любой достаточно крупной системе (какими являются системы масштаба Windows Azure) из-за большого числа физически движущихся деталей некоторые из них всегда выходят из строя. Платформа Windows Azure спроектирована таким образом, чтобы она могла работать без этого ограничения и даже вопреки ему, производя автоматическое восстановление в случае возникновения сбоя на уровне узла. Этот принцип проходит красной нитью через все базовые службы Windows Azure и является ключевым в проектировании приложений, работающих в рамках модели высокой доступности Windows Azure.

Переход на Windows Azure переносит акценты гибкости с избыточности инфраструктуры на избыточность на уровне служб. Многие из базовых служб, где критичным является планирование доступности, просто «продолжат работать» в Azure:

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

  • Хранилище Windows Azure автоматически поддерживает несколько согласованных копий данных (далее см. в документе http://sigops.org/sosp/sosp11/current/2011-Cascais/11-calder-online.pdf). При возникновении сбоя на уровне узла для тома хранилища будет автоматически выполнена отработка отказа с переходом на согласованную вторичную реплику. Что касается базы данных SQL, то обеспечивается полное управление гибким хранилищем на локальном кластере или в сети хранения данных.

Однако озаглавлен этот раздел «доступность», а не «гибкость». Гибкость — это только одно из высоких потребительских качеств, предоставляемых в рамках соглашения об уровне обслуживания. Если все компоненты инфраструктуры службы работоспособны, но служба не может работать с ожидаемым объемом пользователей, то служба недоступна и не представляет никакой ценности.

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

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

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

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

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

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

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

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

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

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

    • Реализуйте соответствующую логику повтора, чтобы избежать эффекта «сопровождения» служб. Без соответствующего механизма повтора нижестоящие службы не получат возможности повторить данные после пиковой нагрузки (так как приложение будет непрерывно увеличивать нагрузку на службу, включая политику регулирования или провоцируя дефицит ресурсов).

  • Службы, которые сталкиваются с быстрыми пиками, должны правильно обрабатывать эти пики, как правило за счет сброса.

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

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

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

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

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

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

  • Автономное развертывание приложений, чтобы свести к минимуму зависимости между центрами обработки данных (т. е. избежать ситуаций, когда сбой в центре обработки данных А вызывает сбой в центре обработки данных Б).

Проектирование непрерывности бизнеса

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

Обеспечение непрерывности бизнеса имеет следующие составляющие:

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

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

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

Первые два элемента традиционно решаются в контексте географического аварийного восстановления (geo-DR), а третий относится к резервному копированию и восстановлению данных.

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

По-прежнему приходится решать сложную задачу управления доступом к долговременно хранимым данным. Обмен долговременно хранимыми данными между службами центров обработки данных (такими как хранилище Windows Azure и база данных SQL Server) обычно приводит к получению неоптимальных результатов в связи с высокими или непостоянными задержками и не позволяет обеспечить непрерывность функционирования бизнеса в случае сбоя центра обработки данных.

Что же касается эластичности, то многие службы Windows Azure обеспечивают (планируют обеспечивать) автоматическую географическую репликацию. Например, если в конфигурации не задано иное, то все операции записи в хранилище Windows Azure (с большими двоичными объектами, очередями и таблицами) автоматически реплицируются в другом центре обработки данных (каждый центр обработки данных имеет конкретное «зеркальное» назначение в пределах одного и того же географического региона). Это способствует существенному сокращению времени и усилий, необходимых для поставки традиционных решений по аварийному восстановлению на основе Windows Azure. Общие сведения о возможностях географической репликации основных служб Windows Azure, управляющих долговременным хранением данных, приведены в следующих разделах.

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

База данных SQL Server предусматривает основные функциональные возможности по поддержке моментальных снимков с предысторией данных, включая применение программы DB Copy, а также импорт и экспорт с помощью BACPAC. Эти варианты подробно обсуждаются ниже в данном документе.

Плотность, равнозначная стоимости товара

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

При гибком масштабировании стоимость товара определяется следующим.

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

  • Насколько эффективно эти единицы масштабирования выполняют свои функции.

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

  • Насколько эффективно выполняется работа в единице масштабирования. В этом состоит традиционная форма оптимизации производительности — управление конфликтами потоков и блокировками, оптимизация алгоритмов, настройка SQL-запросов.

  • Насколько эффективно распределяется работа между единицами масштабирования. В мире, где системы состоят из большого числа небольших единиц, решающим фактором обеспечения эффективности является способность успешно организовывать их взаимодействие. При этом нельзя обойтись без платформ и инструментов, которые осуществляют обмен данными между компонентами, такими как стек передачи сообщений SOAP (наподобие WCF), объектно-реляционные преобразователи (например, Entity Framework), вызовы потоков табличных данных (клиентский код SQL) и сериализация объектов (на основе контрактов данных или формата JSON).

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

  • «Фрагментированные», но не «многословные». С каждой распределенной операцией (т. е. операцией, результатом которой является обращение к сети) связан определенный объем издержек на фреймирование, сериализацию, обработку пакетов и т. д. Чтобы свести издержки к минимуму, можно попробовать объединить операции в пакеты, получив меньшее число «фрагментированных» операций вместо большого числа «многословных». Но при этом следует учитывать, что пакетная обработка операций приводит к повышению числа задержек и чревата потерей данных. Ниже приведены примеры правильной организации пакетной обработки.

    • SQL. Выполнение нескольких операций в одном пакете.

    • Службы REST и SOAP (такие как WCF). Применение сосредоточенных на сообщениях интерфейсов обработки операций вместо «многословного» стиля RPC и реализация по возможности подхода на основе REST.

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

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

    • Применение высокоэффективных платформ сериализации.

    • Использование JSON для связи с устройствами или для создания интероперабельных приложений (предназначенных для чтения человеком).

    • Использование очень эффективной двоичной сериализации (такой как protobuf или Avro) для связи между службами, если обе конечные точки находятся под вашим контролем.

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

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

Описание облачных служб Windows Azure

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

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

Подписка Windows Azure

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

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

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

 

Служба Ограничение по умолчанию

Облачные службы

20

Учетные записи хранилища

5

Ядра

20

Логические серверы базы данных SQL Server

5

Облачные службы

Основной единицей развертывания и масштабирования является облачная служба Windows Azure (ранее «размещенная служба»). Каждая облачная служба состоит из двух развертываний (производственного и промежуточного), в каждом из которых имеется свой набор ролей. Облачная служба имеет общедоступную запись DNS (в формате servicename.cloudapp.net) для производственного развертывания и запись DNS промежуточного развертывания (в формате someguid.cloudapp.net).

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

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

Предварительная настройка веб-ролей осуществляется в экземпляре IIS, в котором размещен код приложения. Код приложения, размещаемый в рабочих ролях, выполняется в заранее заданной конфигурации в постоянно работающем сервере приложения. Каждая облачная служба может иметь до 25 ролей. Применяемая по умолчанию конфигурация ролей предусматривает выполнение кода .NET, но роль может также иметь конфигурацию, позволяющую выполнять любой код, совместимый с Windows Server: Java, Python, Ruby, node.js и т. д. Доступ ко всем функциональным средствам платформы, упомянутым в этом документе, может быть получен с любой платформы, но может потребоваться дополнительная разработка клиентского класса-посредника, предназначенного для работы с API на основе REST.

В пределах облачной службы всем экземплярам присваиваются закрытые IP-адреса (блоками по 10.x); все исходящие соединения выглядят как поступающие из одного виртуального IP-адреса, или VIP-адреса (который представляет собой VIP-адрес развертывания облачной службы), поскольку применяется преобразование сетевых адресов (NAT). Все входящие соединения должны проходить через настроенные конечные точки; эти конечные точки предоставляют сбалансированный по нагрузке доступ к внутренним ролям и портам. Например, по умолчанию входящие соединения HTTP/HTTPS (порт 80 и 443) с развертыванием облачной службы балансируются по нагрузке по всем доступным экземплярам первичной веб-роли.

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

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

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

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

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

Домены обновления и домены отказоустойчивости

Структура Windows Azure имеет два основных метода управления восстановлением после сбоев, реконфигурацией, обновлением и исправлением компонентов: посредством доменов обновления и доменов отказоустойчивости.

Домены обновления — это логические группирования в пределах службы Windows Azure; по умолчанию каждая служба имеет пять (5) доменов обновления (это значение может быть изменено в определении облачной службы). Любое изменение или обновление в службе влияет только на единственный домен обновления одновременно. К примерам этих изменений относится применение исправлений к ОС, изменение размерных показателей виртуальной машины, добавление ролей или экземпляров ролей к работающей службе или изменение настройки конечной точки.

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

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

Сводка

Подведем итог.

  • Основной единицей развертывания и масштабирования в Windows Azure является облачная служба, состоящая из комплекта ролей. Каждая роль содержит ряд идентичных экземпляров роли. В каждом из экземпляров роли эксплуатируется специализированная (с учетом требований облачной службы) версия Windows Server.

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

  • Каждый экземпляр роли содержит недолговременные данные (изменения, файлы и т. д, сохранение которых не гарантируется при возникновении событий перегрузки, исправления и сбоя).

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

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

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

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

Вычисление (экземпляры роли)

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

 

Размерная категория виртуальной машины Число ядер ЦП Память Место на диске для локальных ресурсов хранения в веб-ролях и рабочих ролях Место на диске для локальных ресурсов хранения в роли виртуальной машины Выделенная полоса пропускания (Мбит/с)

Сверхмалый

Общий

768 МБ

19 480 МБ

(6144 МБ зарезервировано для системных файлов)

20 ГБ

5

Малый

1

1,75 ГБ

229 400 МБ

(6144 МБ зарезервировано для системных файлов)

165 ГБ

100

Средний

2

3,5 ГБ

500 760 МБ

(6144 МБ зарезервировано для системных файлов)

340 ГБ

200

Крупный

4

7 ГБ

1 023 000 МБ

(6144 МБ зарезервировано для системных файлов)

850 ГБ

400

Сверхкрупный

8

14 ГБ

2 087 960 МБ

(6144 МБ зарезервировано для системных файлов)

1890 ГБ

800

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

  • Возможность подключения извне с вероятностью 99,95 % для ролей, работающих с Интернетом (ролей с внешними конечными точками).

  • 99,9 % вероятность обнаружения проблем с экземпляром роли в течение двух минут и запуска действий по исправлению.

И размерные показатели, и количество экземпляров роли могут быть динамически изменены в работающем приложении (следует учитывать, что изменение размерных показателей экземпляра роли вызывает последовательное повторное развертывание). Учитывая, что для создания приложений Windows Azure применяется подход с горизонтальным масштабированием, «больше» — не всегда значит «лучше», когда речь идет о выборе размеров экземпляра. Это относится и к стоимости (зачем платить за то, что не используется?), и к производительности (учитывая то, ограничивается ли конкретная рабочая нагрузка ЦП подсистемой ввода-вывода и т. д.). Предпочтительные подходы к выбору количества экземпляров и размерных показателей экземпляра рассматриваются более подробно в разделе «Рекомендации» настоящего документа.

Хранилище

Хранилище Windows Azure — это базовая служба долговременного хранения данных для Windows Azure, которая обеспечивает хранение больших двоичных объектов (файлов), очередей и таблиц («ключ-значение»). Учетная запись хранилища — это основная единица масштабирования и доступности, предоставляющая следующие возможности. Вся связь со службой хранилища основана на интерфейсе REST, действующем по протоколу HTTP.

 

Пределы для учетной записи хранилища Предел

Емкость запоминающего устройства

100 ТБ

Операции (транзакции)

5000 в секунду

Полоса пропускания

3 Гбит/с

Доступность

99.9%

Регулирующий ответ

503. Сервер занят (HTTP)

Соглашение об уровне обслуживания в части доступности хранилища Windows Azure гарантирует, что, во-первых, как минимум в 99,9 % случаев правильно отформатированные запросы на добавление, обновление, чтение и удаление данных будут успешно и правильно обработаны, а, во-вторых, учетные записи хранилища будут иметь возможность подключения к интернет-шлюзу.

Эти пределы являются общими для всех вариантов использования отдельной учетной записи хранилища, т. е. количество операций в секунду и общая полоса пропускания разделяются между таблицами, большими двоичными объектами и очередями. Если приложение превышает общее количество операций в секунду, то служба может возвратить код HTTP «503. Сервер занят». Операции конкретизированы по отношению к каждому аспекту хранилища (таблицы, очереди или большие двоичные объекты) и описаны в приведенных ниже разделах.

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

Хранилище Windows Azure обеспечивает доступность и эластичность по умолчанию; все операции записи или обновления в хранилище Windows Azure прозрачно и единообразно реплицируются по трем узлам хранения (существующим в различных доменах обновления и отказоустойчивости). Доступ к хранилищу Windows Azure контролируется с использованием однофакторной проверки подлинности в форме ключей доступа. Каждая учетная запись хранилища имеет первичный и вторичный ключи, что обеспечивает постоянную доступность при смене первичного ключа. Данные в хранилище Windows Azure автоматически подвергаются географической репликации в «зеркальном» центре обработки данных (если это средство не отключено специально с использованием портала). Географическая репликация является непрозрачной и предусматривает использование DNS для перенаправления клиентов в целях возобновления их работы во вторичном местоположении в случае сбоя в первичном центре обработки данных.

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

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

Большие двоичные объекты

Хранилище больших двоичных объектов предоставляет службу управления файлами в Windows Azure, позволяя использовать максимально доступный и эффективный метод хранения больших объемов неструктурированных данных. Служба поддерживает два типа больших двоичных объектов:

  • Блочные большие двоичные объекты. Блочные большие двоичные объекты предназначены для эффективной обработки больших двоичных объектов данных. Каждый блочный большой двоичный объект может включать до 50 000 блоков размером до 4 МБ (что составляет общий максимальный размер блочного большого двоичного объекта в 200 ГБ). Блочные большие двоичные объекты поддерживают параллельную передачу для эффективного и одновременного перемещения больших файлов по сетям. К отдельным блокам могут применяться операции вставки, замены или удаления, но блоки не могут редактироваться на месте.

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

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

 

Категория большого двоичного объекта Предел

Максимальный размер большого двоичного объекта (блочного)

200 ГБ (блоки по 50 КБ)

Максимальный размер блока

4 МБ

Максимальный размер большого двоичного объекта (страничного)

1 ТБ

Размер страницы

512 байт

Максимальная полоса пропускания в расчете на большой двоичный объект

480 Мбит/с

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

Очереди

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

Запросы Windows Azure

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

 

Категория очереди Предел

Максимальное число сообщений в очереди

Н/д (в рамках одной учетной записи хранилища)

Макс. время существования сообщения

1 неделя (автоматическое удаление)

Максимальный размер сообщения

64 КБ

Макс. пропускная способность

ок. 500 сообщений/с

Очереди предназначены для пересылки контрольных сообщений, а не необработанных данных. Если сообщения слишком велики и не умещаются в очереди, то необходимо разделить их на данные и команды. Сохраните данные в хранилище больших двоичных объектов со ссылкой (URI) на данные и намерение (т. е. что нужно сделать с данными в хранилище больших двоичных объектов) в сообщении очереди.

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

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

Таблицы

Табличное хранилище Windows Azure обеспечивает масштабируемое связанное хранилище с высокой устойчивостью для табличных (двухмерных) данных. Для хранения данных и доступа к ним используется логика { ключ секции, ключ строки } -> { данные[] }, как показано на диаграмме ниже. Каждая таблица подразделяется на секции, которые, в свою очередь, содержат сущности. Каждая сущность может иметь собственную (плоскую) схему или список свойств (столбцов).

Таблицы Windows Azure

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

 

Категория таблицы Предел

Макс. число операций в секунду на одну секцию

500

Макс. размер сущности (имена столбцов + данные)

1 МБ

Макс. размер столбца (массив byte[] или строка)

64 КБ

Максимальное количество строк

Н/д (в рамках одной учетной записи хранилища)

Поддерживаемые типы данных

byte[], Boolean, datetime, double, Guid, int32, int64, string

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

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

Любая обработка запроса, которая длится более 5 секунд, возвращает токен продолжения, с помощью которого приложение продолжает получать результаты выполнения запроса. Запросы, которые возвращают более 1000 сущностей, должны реализовывать модель разбивки на страницы, когда данные возвращаются фрагментами данных по 1000 сущностей, поскольку именно такая схема поддерживается интерфейсом табличного хранилища.

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

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

  • Время. Обычно используется для хранения данных в виде временных рядов, например счетчиков производительности диагностики Windows Azure (подробнее см. далее в разделе о телеметрии). Функции секционирования по времени преобразуют текущее время в значение, представляющее временное окно (текущую минуту, час и т. д.).

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

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

    • Однопольный. Ключ секции — это единственное поле в исходных данных (например, идентификатор заказчика в сведениях о заказе).

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

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

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

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

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

  • Несколько учетных записей хранилища — несколько секций. Если нагрузка будет превышать 5000 операций в секунду, потребуется использование таблиц для нескольких учетных записей хранилища.

Чтобы заменить одну функцию секционирования на другую, потребуется скопировать все сущности с новыми ключами секций, затем удалить старые данные. Обратите внимание, что для секции не существует ограничения на минимальный размер. Секции могут состоять из одной сущности (т. е. одной строки).

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

Сеть доставки содержимого (CDN)

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

Соглашение об уровне обслуживания сети доставки содержимого гарантирует, что кэшированные объекты будут доставляться ежемесячно с доступностью 99,9 %.

Для использования CDN эта функция должна быть активирована по подписке. После этого содержимое больших двоичных объектов (из открытых контейнеров и контейнеров с анонимным доступом) и анонимные выходные данные приложений (например, http://www.myapp.com/cdn/somepage.aspx) можно будет кэшировать.

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

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

Диагностика Windows Azure

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

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

Диагностика Windows Azure

Конфигурация WAD предусматривает ряд источников данных, для каждого из которых выполняется периодический сбор, объединение посредством трассировки событий для сеанса Windows (так называемого сеанса ETW) и публикация в целевой учетной записи хранилища. Агент обрабатывает кратковременные потери соединения, повторные попытки и т. д. Доступны следующие источники данных:

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

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

  • Журналы Windows Azure. Журналы приложений (сообщения трассировки), публикуемые кодом приложения (через System.Diagnostic.Trace) и записываемые прослушивателем трассировки DiagnosticMonitorTraceListener. Журналы публикуются в таблице счетчиков производительности WAD в целевой учетной записи хранилища.

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

  • Журналы сбоев запросов служб IIS. Данные из служб IIS о сбоях запросов, собираемые в локальные файлы и периодически передаваемые в хранилище больших двоичных объектов.

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

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

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

ImportantВажно!
Протоколирование телеметрических данных в отдельную учетную запись хранилища. Протоколирование телеметрических данных и данных приложения в одну и ту же учетную запись хранилища приведет к серьезным конфликтам в процессе масштабирования.

База данных SQL

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

noteПримечание
База данных SQL не обеспечивает паритет функций 1:1 применительно к SQL Server и предназначена для выполнения другого набора задач, подходящих только для облачных приложений (гибкое масштабирование, база данных в качестве службы для снижения затрат обслуживания и т. д.). Дополнительные сведения см. в разделе http://blogs.msdn.com/b/windowsazure/archive/2012/06/26/data-series-sql-server-in-windows-azure-virtual-machine-vs-sql-database.aspx.

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

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

Каждому логическому серверу присваивается внешнее уникальное DNS-имя (вида [servername].database.windows.net), при этом каждый логический сервер в подписке имеет один и тот же внешний IP-адрес. Доступ к логическим серверам (и базам данных) осуществляется через стандартный порт SQL (TCP/1433), при этом интерфейс управления на основе REST получает доступ через порт TCP/833.

По умолчанию доступ к логическим серверам (и ко всем его базам данных) ограничивается правилами брандмауэра по IP-адресам на портале управления Windows Azure (правила можно задавать как для логических серверов, так и для отдельных баз данных). Для включения доступа к приложениям Windows Azure и прямой возможности подключения приложений за пределами Windows Azure (например, для подключения SQL Server Management Studio) потребуется настройка правил брандмауэра. Правила можно настроить на портале управления Windows Azure с помощью вызова API службы управления.

База данных SQL обеспечивает поддержку большинства важнейших функций SQL Server, однако имеется ряд исключений, которые описаны ниже.

  • Все таблицы должны содержать кластеризованный индекс. Данные нельзя вставить в таблицу базы данных SQL, если кластеризованный индекс не был определен.

  • Отсутствует поддержка языка среды CLR, зеркального отображения базы данных, компонента Service Broker, сжатия данных и секционирования таблиц.

  • Нельзя использовать XML-индексы. Тип данных XML поддерживается.

  • Отсутствует поддержка прозрачного шифрования данных (TDE) и аудита данных.

  • Отсутствует поддержка полнотекстового поиска.

Для каждой базы данных настраивается верхний предел размера в момент создания. В настоящий момент можно задать следующий верхний предел: 1 ГБ, 5 ГБ, 10 ГБ, 20 ГБ, 30 ГБ, 40 ГБ, 50 ГБ, 100 ГБ и 150 ГБ (максимально допустимый размер в настоящее время). Если база данных достигает верхнего предела по размеру, то все последующие команды INSERT и UPDATE будут отклоняться (запрос и удаление данных по-прежнему возможны). Размер базы данных можно также создать (увеличить или уменьшить) путем выполнения команды ALTER DATABASE.

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

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

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

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

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

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

В настоящий момент поддерживается только проверка подлинности SQL, однофакторные имена входа (имя пользователя и пароль) исходя из зарегистрированных в базе данных пользователей. Active Directory или двухфакторная проверка подлинности пока не поддерживается. Рекомендуется шифрование подключения к базе данных SQL с помощью встроенной поддержки шифрования ADO.NET, ODBC и др. Разрешения на уровне баз данных совместимы с SQL Server. Дополнительные сведения о настройке безопасности баз данных SQL Windows Azure см. в разделе Управление базами данных и именами входа в базы данных SQL Windows Azure.

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

Общие ресурсы и регулирование

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

 

Ресурс Максимальное значение на одну транзакцию (один сеанс) Макс. значение на один физический узел Мягкий предел регулирования Жесткий предел регулирования

Рабочие потоки

Н/Д

512

305

410

Размер базы данных

Заданный максимальный размер составляет не более 150 ГБ на одну базу данных

Н/Д

Нет

100 %, вставки или обновления при достижении предела отклоняются

Рост журнала транзакций

2 ГБ на одну транзакцию

500 ГБ

Н/Д

Н/Д

Длина журнала транзакций

20 % от общего пространства журнала (100 ГБ)

500 ГБ

Н/Д

Н/Д

Счетчик блокировок

1 миллион на одну транзакцию

Н/Д

Н/Д

Н/Д

Блокирование системных задач

20 секунд

Н/Д

Н/Д

Н/Д

Пространство базы данных temp

5 ГБ

Н/Д

Н/Д

5 ГБ

Память

Н/Д

Н/Д

Н/Д

16 МБ в течение 20 секунд

Макс. число параллельных запросов

400 на одну базу данных

Н/Д

Н/Д

Н/Д

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

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

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

Код клиентского приложения SQL должен выполнять следующее:

  • Реализовывать код повтора, которому известны коды ошибок SQL, связанных с регулированием, и который обеспечивает логику отсрочки. Без наличия в приложении определенной формы логики отсрочки базу данных можно заблокировать в постоянном состоянии регулирования из-за постоянной пиковой нагрузки на нее.

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

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

    • Перейти на другую службу или подход. Если приложению не удалось вставить новые данные в базу данных SQL (при этом не требуется немедленно обеспечить доступность данных), то вместо этого данные можно сериализовать в DataTable (или другой формат XML/JSON) и записать в файл в хранилище больших двоичных объектов. После этого приложение может возвратить пользователю код успешного выполнения (или вызов API-интерфейса) и вставить данные в базу данных позднее.

    • Завершиться без сообщений, возвратив значение NULL, если данные или рабочий процесс были необязательными (не влияющими на работу пользователя).

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

Обеспечение горизонтального масштабирования

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

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

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

    Горизонтальное секционирование.
  • Вертикальное секционирование. При вертикальном секционировании набор данных распределяется по нескольким физическим таблицам или базам данных в соответствии с секционированием схемы. Например, данные клиентов и данные заказов могут быть разнесены по разным физическим базам данных. На приведенной далее диаграмме набор данных вертикально секционирован в две разные базы данных. Базовые сведения о пользователе (имя, адрес эл. почты) хранятся в DB1, а данные профилей пользователей (например, URI изображения для аватара) — в DB2.

    Вертикальное секционирование.

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

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

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

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

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

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

  • Стандартные «хорошие» конструкции хранилища данных и запросов SQL оптимизированы для хранения и обеспечения согласованности за счет использования в значительной степени нормализованных моделей данных. Такой вариант предполагает наличие глобально согласованного пространства данных, в котором используются перекрестные ссылки и приложения JOIN между таблицами. Когда данные разнесены по физически распределенным узлам, предложения JOIN и перекрестные ссылки можно реализовать только в пределах одного сегмента. База данных SQL не поддерживает распределенные запросы к нескольким базам данных; требуется выполнение слияния данных на уровне клиента и также денормализация и репликация данных по сегментам.

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

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

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

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

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

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

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

  • Процессы обеспечения непрерывности бизнеса (резервное копирование или восстановление и так далее) должны учитывать наличие нескольких сегментов данных.

Рекомендации по проектированию в отношении решения этих проблем рассматриваются в соответствующем разделе этого документа.

Рекомендации

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

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

Каждая рекомендация относится к одному или нескольким аспектам оптимизации.

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

  • Задержка. Как сократить задержку как в среднем, так и для отдельных операций.

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

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

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

Облачные службы

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

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

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

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

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

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

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

Распределенное кэширование

Для крупномасштабных распределенных приложений доступ к данным приложения с сохраненным состоянием имеет важнейшее значение. Общая пропускная способность и задержка приложения обычно обусловливаются тем, как быстро оно может получить, обменяться и обновить требуемые данные и контекст. Службы распределенного кэша, например Windows Azure Caching и memcached, появились в ответ на эту потребность. Приложения должны использовать платформу распределенного кэша. Необходимо учитывать следующие правила.

  • Используйте платформу распределенного кэша в размещенной службе в качестве рабочей роли. Такая близость к клиентам кэша позволяет сократить задержку и барьеры на пути данных, создаваемые обходом подсистемы балансировки нагрузки. In-Role Cache в кэше Windows Azure поддерживает кэширование в рабочих ролях в рамках облачной службы.

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

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

  • Кэши представляют семантику key->byte[]; помните о возможности возникновения перекрывающихся записей, когда в кэше возникают несогласованные данные. Обычно распределенный кэш не предоставляет API-интерфейс для обновлений, выполняемых как одна неделимая операция, хранимых в нем данных, поскольку им неизвестна структура находящихся в кэше данных.

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

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

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

Сходство соединения

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

Сходство соединения

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

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

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

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

Вычисление и код приложения

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

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

    • Реализуйте соответствующие политики повтора для всех вызовов службы (база данных SQL, хранилище и так далее) для устранения временных сбоев и действия при потере возможности подключения.

    • Реализуйте политики отсрочки в логике повтора во избежание эффекта «сопровождения» (повторы, которые накапливаются в службе и продлевают ее простой).

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

  • Не создавайте потоки для планирования работы напрямую, вместо этого используйте платформу планирования и параллелизма, например .NET Task Parallel Library. Потоки являются относительно тяжелыми объектами, их сложно создавать и удалять. Планировщики, работающие в общем пуле потоков, могут планировать и выполнять работу более эффективно. Эта архитектура также обеспечивает семантику более высокого уровня для описания продолжения и обработки ошибок.

  • Оптимизируйте объекты передачи данных для сериализации и передачи по сети. С учетом высокой степени распределенности приложений Windows Azure масштабируемость определяется тем, насколько эффективно отдельные компоненты системы могут обмениваться данными по сети. Любые данные, передаваемые по сети для связи или хранения, должны реализовывать сериализацию текста JSON или более эффективный двоичный формат с соответствующими указаниями для сведения к минимуму объема метаданных, передаваемых по сети (например, более короткие имена полей «на проводе»).

    • Если важно взаимодействие, то используйте для него и для передаваемых по сети метаданных эффективный текстовый формат, например JSON.

    • Если важна более высокая пропускная способность, например при обмене данными между службами, в котором вы управляете обеими сторонами, рассмотрите возможность использования высокоэффективного пакетного двоичного формата, например bson или protobuf.

      • Избегайте частой передачи данных мелких объектов. Частый обмен данными между службами требует значительных ресурсов системы, при этом весьма велика вероятность возникновения различных задержек.

      • Тесты сериализации и десериализации объектов должны быть базовым компонентом платформы автоматизированных тестов. Тестирование функциональности обеспечивает сериализацию классов данных и отсутствие циклических зависимостей. Тестирование производительности проверяет соответствие требуемому времени задержки и размерам шифрования.

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

    • Если взаимодействие протоколов или расширенная поддержка протоколов не требуется, рассмотрите возможность использования веб-API-интерфейса ASP.NET вместо WCF для реализации веб-служб.

    • Если вам не требуются богатые функции Entity Framework, рассмотрите возможность использования микро-ORM, например Dapper, для реализации уровня клиента SQL.

  • Сократите объем данных, отправляемых за пределы центра обработки данных, включив сжатие HTTP в службах IIS для исходящих данных.

  • Связывайте соединения между уровнями для сокращения числа вызовов и переключений контекстов соединений.

  • Для сокращения нагрузки на приложение используйте хранилище больших двоичных объектов для предоставления статического содержимого большего размера (> 100 КБ).

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

  • Не используйте базу данных SQL для данных сеанса. Вместо этого используйте распределенный кэш или куки-файлы.

Хранилище

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

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

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

    • Выбор функции секционирования также будет иметь основополагающее влияние на производительность запросов. Хранилище таблиц обеспечивает достаточные возможности подстановки с помощью функции {ключ секции, ключ строки} с менее эффективной обработкой функции {ключ секции, фильтр совпадения строк} и {фильтр совпадения ключей секций, фильтр совпадения ключей строк}. Запросы, требующие глобального просмотра таблицы ({фильтр совпадения ключей строк}).

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

  • По возможности создавайте пакеты операций в хранилище. Операции записи в таблицы должны быть оформлены в пакеты. Обычно это делается с помощью метода SaveChanges в клиентском API-интерфейсе платформы .NET. Вставьте ряд строк в таблицу, затем зафиксируйте изменения единым пакетом с помощью метода SaveChanges. Обновления в хранилище больших двоичных объектов также должны фиксироваться пакетно с помощью метода PutBlockList. Аналогично API-интерфейсу хранилища таблиц вызывайте метод PutBlockList для диапазона блоков, а не для отдельных блоков.

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

База данных SQL

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

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

  • Активное кэширование. Сведения в базе данных конфигурации должны активно кэшироваться в распределенный кэш (например, через memcache или кэширование Windows Azure Caching).

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

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

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

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

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

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

    • Такое секционирование усложняет методы управления. Такие операции, как перестроение индекса, должны выполняться последовательно для всех таблиц-компонентов.

  • Размер отдельных баз данных (сегментов) следует поддерживать достаточно небольшим. Такие непрерывные операции, как DB Copy или экспорт в базах данных объемом более 50 ГБ, могут длиться часами (служба отменяет операции, выполняющиеся более 24 часов).

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

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

Управление соединениями

При переходе к горизонтально масштабируемому набору баз данных возникают задачи, связанные с управлением соединениями. Каждое соединение базы данных SQL является относительно дорогим ресурсом, о чем свидетельствует широкое использование пулов соединений в клиентских API-интерфейсах (ADO.NET, ODBC, PHP и т. д.). Вместо того чтобы поддерживать несколько соединений с центральным SQL Server, каждый экземпляр приложения должен в принципе поддерживать соединение с несколькими серверами баз данных.

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

using (var conn = new SqlConnection(connStr))
{
    // SQL client calls here
}

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

База данных SQL поддерживает только соединения TCP (именованные каналы не поддерживаются), поэтому настоятельно рекомендуется шифровать соединение между кодом приложения и базой данных SQL. Чтобы предотвратить непредвиденные попытки подключения (например, попытки использовать именованные каналы), необходимо использовать в приложениях следующий формат строки подключения SQL:

Server=tcp:{servername}.database.windows.net,1433;Database={database};User ID={userid}@{database};Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

Для крупномасштабных развертываний приложений количество возможных соединений по умолчанию между развертыванием размещаемой службы и логическими серверами баз данных SQL в кластере баз данных SQL (у каждого из которых есть свой внешний IP-адрес) может расти экспоненциально. В качестве примера возьмем размещаемую службу с 100 экземплярами, 50 базами данных и количеством соединений по умолчанию, которое в ADO.NET составляет 100.

MaxConnections=DatabaseCount*Instance Count*MaxConnectionPoolSize

См. топологию сети для размещаемой службы. Каждая сторона соединения (размещаемая служба и логические серверы базы данных SQL) находится за подсистемой балансировки нагрузки Windows Azure. . Все подсистемы балансировки нагрузки Windows Azure имеют верхний предел в 64 тысячи соединений между любыми двумя адресами IPv4. Сочетание этой сетевой топологии с количеством доступных соединений по умолчанию дает серьезные сбои сети у крупных приложений.

  • Развертывайте большие приложения на нескольких размещенных службах.

  • Развертывайте базы данных в нескольких подписках (не только на нескольких логических серверах в пределах одной подписки) для получения большего количества уникальных IP-адресов.

  • Реализация многоуровневых приложений для соединения исходящих операций с целевым экземпляром приложения (см. предыдущий раздел по размещаемым службам).

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

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

Проектирование схем и запросов

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

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

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

В коде клиентских приложений должен быть предусмотрен ряд аспектов доставки распределенной модели данных.

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

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

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

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

    • Максимальное время запроса (чтобы сократить общее число задержек от долго выполняющихся запросов или медленных сегментов).

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

  • Ссылочные таблицы. В отсутствие глобально согласованного пространства запросов ссылочные данные для команд JOIN в запросах должны копироваться в каждый отдельный сегмент. Поддержание и репликация данных в ссылочных таблицах в отдельных сегментах необходимы для обеспечения достаточно согласованных локальных ссылочных данных.

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

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

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

  • Удаление лишних данных. По мере того как приложение растет и набирает все больше данных, следует рассмотреть периодическое удаление старых неиспользуемых данных, что обеспечит запас мощности и ресурсов в основной системе. Удаляемые данные исчезают из базы данных SQL несинхронно: они отмечаются к удалению и очищаются фоновым процессом. Общий способ пометки данных для удаления — столбец флагов, который отмечает строку как активную, неактивную или выбранную для удаления. Это на некоторое время позволяет закрыть данные от запросов, что дает возможность легко вернуть данные обратно в работу, если пользователи сообщат, что эти данные все еще нужны.

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

    • В хранилище в сети (базу данных SQL-получатель). Это обеспечивает запас мощности в основной системе, но без сокращения затрат.

    • В хранилище вне сети, например файл BCP или BACPAC в хранилище больших двоичных объектов. Это дает запас мощности в основной системе и сокращает затраты.

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

Обработка временных ошибок и отсрочки

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

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

  • Управление регулированием с логикой повторов и отсрочек. Код доступа к данным должен предусматривать механизм повторов и отсрочек на основе политик для обработки условий регулирования. Механизм повторов должен распознавать регулирование и постепенно откладывать попытки повторного выполнения команды (во избежание эффекта «сопровождения», который продлевает период условия регулирования).

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

Приложения .NET могут использовать платформы логики повторов и отсрочки с поддержкой баз данных SQL, например Cloud Application Framework (CloudFx) или Enterprise Library Transient Fault Handler. В этих платформах предусмотрены оболочки для общих классов доступа к данным (например, SqlConnection и SqlCommand), а также политики, которые можно вызывать напрямую.

var retryPolicy = RetryPolicy.Create<SqlAzureTransientErrorDetectionStrategy>(
    retryCount: 3, 
    initialInterval: TimeSpan.FromSeconds(5),
    increment: TimeSpan.FromSeconds(2));
                
using (var conn = new ReliableSqlConnection(connStr))
{
    conn.Open();
    using (var cmd = conn.CreateCommand())
    {

    }
    conn.Close();
}

В предыдущем фрагменте кода демонстрируется использование класса CloudFx ReliableSqlConnection для обработки временных ошибок соединения при работе с базой данных SQL.

Приложение / клиентская телеметрия

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

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

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

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

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

  • Идентификатор сеанса соединения, доступный в свойстве CONTEXT_INFO() (или свойстве SessionTracingId, если используется ReliableSqlConnection). Однако не следует получать свойство идентификатора сеанса из CONTEXT_INFO() при каждом клиентском вызове, поскольку эта команда вызывает еще один цикл приема-передачи на сервер.

Пакетная обработка и асинхронное выполнение

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

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

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

Непрерывность бизнеса и обслуживание данных

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

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

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

Телеметрия для базы данных SQL

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

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

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

Телеметрия и диагностика

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

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

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

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

    • Для «многословных» данных используйте стандартные источники диагностики Windows Azure, например счетчики производительности и трассировки.

    • Для реализации массового протоколирования в локальные файлы используйте общие библиотеки ведения журналов, например Enterprise Application Framework Library, log4net или NLog. Для периодического копирования этих сведений в хранилище больших двоичных объектов применяйте пользовательский источник данных в конфигурации монитора диагностики.

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

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

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

    • Выберите подходящий интервал сбора (5–15 мин), чтобы сократить объем передаваемых и анализируемых данных.

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

Диагностика Windows Azure не предусматривает сбор данных для зависимых служб, например базы данных SQL или распределенного кэша. Чтобы получить комплексное представление о работе приложения и его характеристиках производительности, добавьте инфраструктуру сбора данных для зависимых служб:

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

    • Хранилище Windows Azure через аналитику хранилища Windows Azure.

    • База данных SQL через динамические административные представления.

    • Распределенный кэш через счетчики производительности или API-интерфейсы контроля исправности.

  • Периодически анализируйте необработанные телеметрические данные, создавайте статистику и свертки (с помощью планируемой задачи).

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв

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

ДОБАВИТЬ
Показ:
© 2014 Microsoft. Все права защищены.