Разработка глобально доступных служб с помощью Базы данных SQL Azure

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных SQL Azure

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

Примечание

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

Сценарий 1. Использование двух регионов Azure для обеспечения непрерывности бизнес-процессов с минимальным временем простоя

В этом сценарии приложения имеют следующие характеристики:

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

В этом случае топология развертывания приложения оптимизирована для обработки аварий в регионе, когда все компоненты приложения должны отрабатывать отказ совместно. Такая топология показана на схеме ниже. Для географической избыточности ресурсы приложения развертываются в регионах А и Б. Однако ресурсы в регионе Б не используются до тех пор, пока не произойдет сбой в регионе А. Группа отработки отказа настроена между двумя регионами для управления подключением к базе данных, а также репликацией и отработкой отказа. Веб-служба в обоих регионах настроена для доступа к базе данных через прослушиватель записи и чтения <имя_группы_отработки_ отказа>.database.windows.net (1). В диспетчере трафика Azure настроено использование метода маршрутизации по приоритету (2).

Примечание

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

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

Сценарий 1. Конфигурация до сбоя.

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

Примечание

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

Сценарий 1. Конфигурация после отработки отказа

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

Примечание

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

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

Примечание

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

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

Сценарий 1. Конфигурация после сбоя в дополнительном регионе.

Эта модель разработки имеет такие преимущества :

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

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

Сценарий 2. Регионы Azure для обеспечения непрерывности бизнес-процессов с сохранением максимального объема данных

Этот вариант лучше всего подходит для приложений со следующими характеристиками:

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

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

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

Сценарий 2. Конфигурация до сбоя.

Когда диспетчер трафика обнаруживает сбой подключения в регионе А, он автоматически переключает пользовательский трафик на экземпляр приложения в регионе Б. При использовании этого шаблона важно установить достаточно высокое значение периода отсрочки до отработки отказа с потерей данных, например 24 часа. Это обеспечит предотвращение потери данных, если в течение этого времени сбой будет устранен. При активации веб-приложения в регионе Б операции чтения и записи будут завершаться сбоем. На этом этапе следует переключиться в режим только для чтения (1). В этом режиме запросы будут автоматически направляться в базу данных-получатель. Если причиной сбоя является разрушительный сбой, скорее всего? его нельзя устранить в течение льготного периода. При его истечении группа отработки отказа запускает процесс отработки отказа. После этого прослушиватель записи и чтения станет доступен и подключения к нему перестанут завершаться сбоем (2). На следующей схеме показаны два этапа процесса восстановления.

Примечание

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

Сценарий 2. Этапы аварийного восстановления.

В случае сбоя в регионе Б диспетчер трафика обнаруживает сбой конечной точки web-app-2 в регионе Б и отмечает ее деградировавшую (1). В то же время группа отработки отказа переключает прослушиватель только для чтения на регион А (2). Этот сбой не влияет на конечного пользователя, но база данных-источник будет скомпрометирована во время сбоя. На следующей схеме показан сбой в дополнительном регионе.

Сценарий 2. Сбой в дополнительном регионе.

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

Эта модель разработки имеет несколько преимуществ:

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

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

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

В этом сценарии приложение имеет следующие характеристики:

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

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

Ресурсы приложения должны быть развернуты в каждом географическом регионе, где у вас есть значительные потребности в использовании. Например, если приложение активно используется в Соединенных Штатах, ЕС и Юго-Восточной Азии, оно должно быть развернуто во всех этих географических регионах. База данных-источник должна динамически переключаться с одного региона на другой по завершении рабочего времени. Этот способ называется "следовать за солнцем". Рабочая нагрузка OLTP всегда подключается к базе данных через прослушиватель чтения-записи <имя_группы_отработки_отказа>.database.windows.net (1). Рабочая нагрузка только для чтения подключается к локальной базе данных напрямую с использованием конечной точки сервера баз данных <имя_сервера>.database.windows.net (2). В диспетчере трафика настроен метод маршрутизации производительности. Это гарантирует, что устройство конченого пользователя будет подключаться к веб-службе в ближайшем регионе. В диспетчере трафика следует настроить мониторинг каждой конечной точки веб-службы (3).

Примечание

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

Сценарий 3. Конфигурация с базой данных-источником в регионе "Восточная часть США".

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

  • Переключение сервера-источника в группе отработки отказа на регион "Северная Европа" с использованием адаптированной отработки отказа (1).
  • Удаление группы отработки отказа между регионами "Восточная часть США" и "Северная Европа".
  • Создание группы отработки отказа с тем же именем, но между регионами "Северная Европа" и "Восточная Азия" (2).
  • Добавление базы данных-источника в регионе "Северная Европа" и базы данных-получателя в регионе "Восточная Азия" в эту группу отработки отказа (3).

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

Сценарий 3. Переход базы данных-источника в регион "Северная Европа".

Например, если в регионе "Северная Европа" происходит сбой, группа отработки отказа инициирует автоматическую отработку отказа базы данных, что фактически приводит к переносу приложения в следующий регион досрочно (1). В этом случае восточная часть США является единственным оставшимся вторичным регионом до тех пор, пока регион "Северная Европа" не вернется в рабочее состояние. Остальные два региона обслуживают клиентов во всех трех географических регионах с помощью переключения ролей. Azure Logic Apps должно быть настроено соответствующим образом. Так как остальные регионы получают дополнительный пользовательский трафик из Европы, производительность приложения зависит не только от дополнительной задержки, но и от увеличения количества подключений конечных пользователей. После устранения сбоя в регионе "Северная Европа" база данных-получатель будет сразу синхронизирована с текущей базой данных-источником. На следующей схеме показан сбой в регионе "Северная Европа".

Сценарий 3. Сбой в регионе "Северная Европа".

Примечание

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

Преимущества этой стратегии перечислены ниже.

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

Однако существуют некоторые компромиссы:

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

Планирование непрерывности бизнеса-процессов: выбор проекта приложения для аварийного восстановления облака

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

Модель RPO ERT
Активное — пассивное развертывание для аварийного восстановления с доступом к совмещенной базе данных Доступ для чтения и записи < 5 секунд Время обнаружения сбоя и срок жизни DNS
Активное — активное развертывание для балансировки нагрузки приложения Доступ для чтения и записи < 5 секунд Время обнаружения сбоя и срок жизни DNS
Активное — пассивное развертывание для сохранения данных Доступ только для чтения < 5 с Доступ только для чтения = 0
Доступ только для чтения = 0 Доступ только для чтения = время обнаружения сбоя + льготный период с потерей данных

Дальнейшие действия