Разработка глобально доступных служб с помощью Базы данных SQL Azure
Применимо к:
База данных SQL Azure
При создании и развертывании облачных служб с База данных SQL Azure используются активные георепликации или группы отработки отказа для обеспечения устойчивости к региональным сбоям и катастрофическим сбоям. Таким же образом можно создать глобально распределенные приложения, оптимизированные для локального доступа к данным. В этой статье мы рассмотрим общие шаблоны приложений, в том числе преимущества и недостатки каждого из них.
Примечание.
Если вы используете базы данных уровня "Премиум" или "Критически важный для бизнеса" и эластичные пулы, их можно сделать устойчивыми к региональным сбоям, переведя их на избыточную в пределах зоны конфигурацию развертывания. Ознакомьтесь с базами данных, избыточными между зонами.
Сценарий 1. Использование двух регионов Azure для обеспечения непрерывности бизнес-процессов с минимальным временем простоя
В этом сценарии приложения имеют следующие характеристики:
- Приложение активно в одном регионе Azure.
- Для всех сеансов баз данных требуются права доступа на чтение и запись к данным.
- Для сокращения задержки и стоимости трафика веб-уровень и уровень данных должны быть расположены вместе.
- По существу, простой представляет собой больший бизнес-риск для этих приложений, чем потеря данных.
В этом случае топология развертывания приложения оптимизирована для обработки аварий в регионе, когда все компоненты приложения должны отрабатывать отказ совместно. Такая топология показана на схеме ниже. Для географической избыточности ресурсы приложения развертываются в регионе А и B. Однако ресурсы в регионе B не используются, пока регион A не завершается ошибкой. Группа отработки отказа настроена между двумя регионами для управления подключением к базе данных, а также репликацией и отработкой отказа. Веб-служба в обоих регионах настроена для доступа к базе данных через прослушиватель записи и чтения <имя_группы_отработки_ отказа>.database.windows.net (1). В диспетчере трафика Azure настроено использование метода маршрутизации по приоритету (2).
Примечание.
Диспетчер трафика Azure используется в этой статье только в качестве иллюстрации. Можно использовать любое решение балансировки нагрузки, поддерживающее метод маршрутизации по приоритету.
На следующей схеме показана эта конфигурация до сбоя.
После сбоя в основном регионе база данных SQL Database обнаружит, что база данных-источник недоступна и запустит отработку отказа в дополнительном регионе на основе параметров, приведенных в политике автоматической отработки отказа (1). В зависимости от соглашения об уровне обслуживания приложения вы можете задать льготный период, который контролирует время между обнаружением сбоя и отработкой отказа. Возможно, что диспетчер трафика Azure инициирует отработку отказа конечной точки, прежде чем группа отработки отказа запустит отработку отказа базы данных. В этом случае веб-приложение не сможет сразу же повторно подключиться к базе данных. При этом попытки повторного подключения будут выполнены автоматически, как только отработка отказа базы данных завершится. После восстановления работоспособности региона старая база данных-источник автоматически стает базой данных-получателем. На схеме ниже показана конфигурация после отработки отказа.
Примечание.
Все транзакции, зафиксированные после отработки отказа, будут потеряны во время повторного подключения. После завершения отработки отказа приложение в регионе Б может повторно подключиться и перезапустить обработку запросов пользователя. Веб-приложение и база данных-источник находятся в регионе Б и расположены совместно.
В случае сбоя в регионе Б процесс репликации между базой данных-источником и базой данных-получателем приостанавливается, а связь между ними остается без изменений (1). Диспетчер трафика обнаруживает разрыв соединения с регионом Б и назначает веб-приложению конечной точки 2 состояние "Деградация" (2). Это не влияет на работу приложения, но база данных становится открытой и, следовательно, имеет высокий риск потери данных в случае сбоя региона A.
Примечание.
Для аварийного восстановления рекомендуется конфигурация с ограниченным развертыванием приложения в двух регионах. Это связано с тем, что большинство географических расположений Azure имеет только два региона. Эта конфигурация не позволяет защитить ваши приложения от одновременного разрушительного сбоя в обоих регионах. В маловероятной ситуации такого сбоя можно восстановить базы данных в третьем регионе с помощью операции геовосстановления. Дополнительные сведения см. в руководстве по аварийному восстановлению База данных SQL Azure.
После устранения сбоя база данных-получатель будет автоматически синхронизирована с базой данных-источником. Синхронизация может повлиять на производительность базы данных-источника. Степень влияния зависит от объема данных новой базы данных-источника, полученных с момента отработки отказа.
Примечание.
После устранения сбоя Диспетчер трафика начинает маршрутизацию подключений к приложению в регионе A, как к конечной точке с более высоким приоритетом. Если вы планируете хранить основное значение в регионе B в течение некоторого времени, необходимо изменить таблицу приоритета в профиле Диспетчер трафика соответствующим образом.
На следующей схеме показан сбой в дополнительном регионе.
Эта модель разработки имеет такие преимущества :
- Одно и то же веб-приложение развертывается в обоих регионах без какой-либо конфигурации конкретного региона и не требует дополнительной логики для управления отработки отказа.
- Отработка отказа не влияет на работу приложения, так как веб-приложение и база данных всегда находятся в одном расположении.
Главный компромисс заключается в том, что ресурсы приложения в регионе Б недогружены большую часть времени.
Сценарий 2. Регионы Azure для обеспечения непрерывности бизнес-процессов с сохранением максимального объема данных
Этот вариант лучше всего подходит для приложений со следующими характеристиками:
- Любая потеря данных представляет собой большой риск для бизнеса. Отработка отказа базы данных может использоваться только в качестве последнего средства, когда сбой является катастрофическим.
- Приложение поддерживает режимы работы только для чтения и чтения-записи и может работать в режиме только для чтения в течение определенного периода времени.
В этом шаблоне приложение переключается в режим только для чтения, когда подключения для чтения и записи начинают получать ошибки времени ожидания. Веб-приложение развернуто в обоих регионах и содержит подключение к конечной точке прослушивателя чтения и записи и другое подключение к конечной точке прослушивателя с правами только для чтения (1). Профиль диспетчера трафика должен использовать маршрутизацию по приоритету. Мониторинг конечной точки необходимо включить для конечной точки приложения в каждом регионе (2).
На следующей схеме показана эта конфигурация до сбоя.
Когда диспетчер трафика обнаруживает сбой подключения в регионе А, он автоматически переключает пользовательский трафик на экземпляр приложения в регионе Б. При использовании этого шаблона важно установить достаточно высокое значение периода отсрочки до отработки отказа с потерей данных, например 24 часа. Это обеспечит предотвращение потери данных, если в течение этого времени сбой будет устранен. При активации веб-приложения в регионе Б операции чтения и записи будут завершаться сбоем. На этом этапе следует переключиться в режим только для чтения (1). В этом режиме запросы будут автоматически направляться в базу данных-получатель. Если причиной сбоя является разрушительный сбой, скорее всего? его нельзя устранить в течение льготного периода. При его истечении группа отработки отказа запускает процесс отработки отказа. После этого прослушиватель записи и чтения станет доступен и подключения к нему перестанут завершаться сбоем (2). На следующей схеме показаны два этапа процесса восстановления.
Примечание.
Если сбой в основном регионе устранить в течение периода отсрочки, диспетчер трафика определит восстановление связности в основном регионе и переключит трафик пользователей обратно на экземпляр приложения в регионе А. Этот экземпляр приложения возобновит работу и продолжит работать в режиме чтения и записи с использованием базы данных-источника в регионе А, как показано на предыдущей схеме.
В случае сбоя в регионе Б диспетчер трафика обнаруживает сбой конечной точки web-app-2 в регионе Б и отмечает ее деградировавшую (1). В то же время группа отработки отказа переключает прослушиватель только для чтения на регион А (2). Этот сбой не влияет на конечного пользователя, но база данных-источник будет скомпрометирована во время сбоя. На следующей схеме показан сбой в дополнительном регионе.
Как только сбой будет устранен, база данных-получатель немедленно синхронизируется с базой данных-источником и прослушиватель чтения и записи переключится обратно на базу данных-источник в регионе Б. Во время синхронизации производительность базы данных-получателя может незначительно ухудшиться в зависимости от объема данных для синхронизации.
Эта модель разработки имеет несколько преимуществ:
- Она позволяет избежать потери данных при временном сбое.
- Время простоя зависит от того, насколько быстро диспетчер трафика обнаружит сбой подключения. Этот параметр можно настроить.
Компромисс заключается в том, что приложение должно поддерживать работу в режиме только для чтения.
Планирование непрерывности бизнеса-процессов: выбор проекта приложения для аварийного восстановления облака
В зависимости от выбранной стратегии аварийного восстановления облака вы можете объединить или расширить эти шаблоны проектирования для наилучшего соответствия требованиям приложения. Как уже упоминалось, выбор стратегии зависит от соглашения об уровне обслуживания, предлагаемого клиентам, и топологии развертывания приложений. Чтобы помочь вам принять решение, в приведенной ниже таблице сравниваются варианты с учетом целевой точки восстановления (RPO) и оценки времени восстановления (ERT).
| Расписание | RPO | ERT |
|---|---|---|
| Активное — пассивное развертывание для аварийного восстановления с доступом к совмещенной базе данных | Доступ для чтения и записи < 5 с | Время обнаружения сбоя и срок жизни DNS |
| Активное — активное развертывание для балансировки нагрузки приложения | Доступ для чтения и записи < 5 с | Время обнаружения сбоя и срок жизни DNS |
| Активное — пассивное развертывание для сохранения данных | Доступ только для чтения < 5 с | Доступ только для чтения = 0 |
| Доступ только для чтения = 0 | Доступ только для чтения = время обнаружения сбоя + льготный период с потерей данных |
Следующие шаги
- Сведения об обеспечении непрерывности бизнес-процессов и возможные сценарии описаны в обзоре непрерывности бизнес-процессов
- Дополнительные сведения об активной георепликации см. здесь.
- Дополнительные сведения о группах отработки отказа см. в разделе "Отработка отказа".
- Сведения об использовании активной георепликации с пулами эластичных баз данных см. в статье Стратегии аварийного восстановления для приложений с использованием пула эластичных баз данных SQL.