DR для служб PaaS

Аварийное восстановление для служб IaaS (VM) обычно включает использование Azure Site Recovery для репликации всей OS и дисков с данными во вторичный регион. У служб PaaS модели DR отличаются, поскольку базовой инфраструктурой управляет Microsoft. Для PaaS DR обычно настраивается на уровне данных: данные реплицируются во вторичный регион, а сама платформа запускается автоматически.

Azure SQL Database обеспечивает встроенную высокую доступность на уровне зон в пределах одного региона. Для межрегионального DR служба предоставляет две ключевые возможности: активную георепликацию (доступные для чтения вторичные базы данных в четырех других регионах) и группы автоматического переключения (автоматическое переключение с одной конечной точкой прослушивателя). Они настраиваются на уровне базы данных или сервера без использования Azure Site Recovery.

Группы автоматического переключения добавляют автоматизацию и единую конечную точку подключения поверх георепликации. Вы настраиваете группу на первичном сервере, добавляете вторичный сервер и задаете период ожидания восстановления — время, в течение которого Azure ждет восстановления первичного сервера перед запуском автоматического переключения. Приложения подключаются к конечной точке прослушивателя (например, mygroup.database.windows.net) и после переключения автоматически перенаправляются без изменения строк подключения.

Георепликация Azure SQL Database выполняется асинхронно: транзакции фиксируются на первичном сервере, а затем реплицируются на вторичный. Это означает небольшую задержку репликации, обычно менее 5 секунд в нормальных условиях. Поэтому RPO для георепликации SQL в большинстве сценариев составляет примерно 5 секунд, что подходит для рабочих нагрузок уровня 1 и уровня 2, требующих минимальной потери данных.

Все уровни Azure SQL Database включают автоматические резервные копии: полные копии выполняются еженедельно, дифференциальные — каждые 12 часов, а копии журнала транзакций — каждые 5–12 минут. Это позволяет выполнять восстановление на момент времени (PITR) — восстанавливать базу данных на любую секунду в пределах периода хранения (7–35 дней для Standard/General Purpose, до 35 дней для Business Critical). PITR полезно для восстановления после случайного удаления или повреждения данных.

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

Azure App Service сам по себе не хранит состояние (код приложения развертывается из системы управления исходным кодом или ZIP-файла). Для DR основное внимание уделяется уровню данных (базе данных и хранилищу больших двоичных объектов). App Service можно быстро развернуть во вторичном регионе с помощью конвейера CI/CD. Однако необходимо убедиться, что ваш пользовательский домен, сертификаты TLS и параметры приложения реплицируются или задаются сценариями, чтобы их можно было быстро воссоздать во вторичном регионе.

Azure Blob Storage с геоизбыточным хранилищем (GRS) автоматически реплицирует данные во вторичный регион, расположенный в сотнях миль. Данные реплицируются асинхронно (RPO обычно составляет менее 15 минут). GRS с доступом для чтения (RA-GRS) позволяет читать данные из вторичной конечной точки еще до запуска переключения, что полезно для рабочих нагрузок аналитики и отчетности во время сбоя первичного региона.

Azure Functions не хранят состояние по своей архитектуре, поэтому их легко развернуть повторно. Для DR разверните то же приложение функций во вторичном регионе и используйте Traffic Manager для маршрутизации триггеров HTTP между регионами. Для триггеров, не использующих HTTP (Service Bus, Event Grid) настройте источник сообщений так, чтобы он направлял сообщения в оба региона, либо поручите вторичному региону опрашивать тот же источник. Состояние функций в Durable Functions хранится в Azure Storage — убедитесь, что для этого хранилища используется GRS.

Use active geo-replication, если Вам нужен детальный контроль — например, чтобы направлять трафик чтения на вторичную реплику для повышения производительности или независимо управлять несколькими вторичными репликами в разных регионах. Use auto-failover groups, если Вам нужна простота: единая конечная точка прослушивателя, автоматическое переключение по таймеру и встроенная оркестрация процесса переключения без ручного вмешательства.

DR в PaaS часто обходится дешевле, чем DR на основе виртуальных машин, по нескольким причинам. Георепликация SQL Database оплачивает только хранилище и вычислительные ресурсы вторичной реплики; Вам не нужно платить за полную лицензию на ОС виртуальной машины. Azure Cosmos DB взимает плату за подготовленные единицы запроса (RU) в каждом регионе. Azure Storage GRS увеличивает стоимость хранилища примерно в 2 раза. В отличие от этого, виртуальные машины, реплицируемые с помощью ASR, требуют полной оплаты вычислительных ресурсов, хранилища и лицензий во вторичном регионе.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

В этом уроке Вы узнали, что PaaS DR сосредоточен на уровне данных, а не на репликации виртуальных машин; Azure SQL auto-failover groups предоставляют единую конечную точку прослушивателя с автоматическим переключением; а Cosmos DB multi-region writes обеспечивают почти нулевые значения RTO и RPO для глобальных приложений. Далее мы рассмотрим нормативные стандарты Azure и модель разделения ответственности.