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

Применимо к: База данных SQL Azure

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

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

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

Перед началом работы с этим руководством убедитесь, что выполнены следующие предварительные требования:

• База данных SaaS Wingtip Tickets развернута как приложение для каждого арендатора. Сведения о развертывании менее чем за пять минут см. в статье "Развертывание и изучение базы данных SaaS Wingtip Tickets на каждое приложение клиента"
• Azure PowerShell устанавливается. Дополнительные сведения см. в статье "Начало работы с Azure PowerShell"

Общие сведения о шаблоне восстановления георепликации

Аварийное восстановление является важным аспектом для многих приложений с точки зрения соответствия требованиям или непрерывности бизнес-процессов. Если будет длительный сбой службы, хорошо подготовленный план аварийного восстановления может свести к минимуму бизнес-нарушения. Использование георепликации обеспечивает наименьший уровень RPO и RTO путем поддержания реплик базы данных в регионе восстановления, на который можно выполнить отработку отказа в короткий момент времени.

План аварийного восстановления на основе георепликации состоит из трех отдельных частей:

• Настройка — создание и обслуживание среды восстановления
• Восстановление — переключение приложений и баз данных в среду восстановления в случае сбоя.
• Репатриация — переключение приложения и баз данных обратно в исходный регион после стабилизации приложения

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

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

В этом руководстве эти проблемы рассматриваются с помощью функций Базы данных SQL Azure и платформы Azure:

• Шаблоны Azure Resource Manager для максимально быстрого резервирования необходимой емкости. Шаблоны Azure Resource Manager используются для подготовки зеркального изображения рабочих серверов и эластичных пулов в регионе восстановления.
• Георепликация для создания асинхронно реплицированных вторичных файлов только для чтения для всех баз данных. При сбое происходит переключение на реплики в области восстановления. После устранения сбоя вы вернитесь в базы данных в исходном регионе без потери данных.
• Асинхронные операции переключения на резерв, отправленные в порядке приоритета арендатора, чтобы свести к минимуму время переключения на резерв для большого количества баз данных.
• Функции управления шардами для восстановления, для изменения записей базы данных в каталоге при восстановлении и репатриации. Эти функции позволяют приложению подключаться к базам данных клиента независимо от расположения без перенастройки приложения.
• Псевдонимы DNS SQL Server позволяют бесшовно обеспечивать новых клиентов независимо от региона, в котором работает приложение. Псевдонимы DNS также используются для разрешения процесса синхронизации каталога подключаться к активному каталогу независимо от его расположения.

Получение скриптов аварийного восстановления

Это важно

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

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

Обзор учебников

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

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

Замечание

Приложение восстанавливается в парном регионе региона, в котором развертывается приложение. Дополнительные сведения см. в статье Парные регионы Azure.

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

Перед тем как начать процесс восстановления, проверьте состояние работоспособности приложения.

1. В веб-браузере откройте Центр событий Wingtip Tickets Events Hub (http://events.wingtip-dpt.<user>.trafficmanager.net - замените <user> на имя пользователя вашего развертывания).

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

2. Щелкните на арендаторе Contoso Concert Hall и откройте его страницу событий.

   • В нижнем колонтитуле обратите внимание на имя сервера клиента. Расположение будет совпадать с расположением сервера каталога.

3. На портале Azure откройте группу ресурсов, в которой развернуто приложение.

   • Обратите внимание на регион, в котором развертываются серверы.

Синхронизация конфигурации клиента с каталогом

В этой задаче вы запускаете процесс, который синхронизирует конфигурацию серверов, эластичных пулов и баз данных в каталог клиента. Этот процесс сохраняет эту информацию up-to-date в каталоге. Процесс работает с активным каталогом, будь то в исходном регионе или в регионе восстановления. Сведения о конфигурации используются в рамках процесса восстановления, чтобы обеспечить соответствие среды восстановления исходной среде, а затем во время репатриации, чтобы обеспечить согласованность исходных регионов с любыми изменениями, внесенными в среду восстановления. Каталог также используется для отслеживания состояния восстановления ресурсов клиента.

Это важно

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

1. В PowerShell ISE откройте файл ...\Learning Modules\UserConfig.psm1. Замените <resourcegroup> и <user> в строках 10 и 11 значениями, которые вы указали при развертывании приложения. Сохраните файл!

2. В PowerShell ISE откройте скрипт ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 и установите:

   • $DemoScenario = 1, запуск фонового задания, которое синхронизирует сервер клиента и сведения о конфигурации пула в каталоге

3. Нажмите клавишу F5 , чтобы запустить скрипт синхронизации. Откроется новый сеанс PowerShell для синхронизации конфигурации ресурсов клиента.

Оставьте окно PowerShell в фоновом режиме и продолжайте работу с остальным руководством.

Замечание

Процесс синхронизации подключается к каталогу с помощью псевдонима DNS. Этот псевдоним изменяется во время восстановления и репатриации, чтобы указать на активный каталог. Процесс синхронизации сохраняет каталог up-to-date с любыми изменениями конфигурации базы данных или пула, внесенными в регион восстановления. Во время репатриации эти изменения применяются к эквивалентным ресурсам в исходном регионе.

Создайте вторичные реплики базы данных в регионе восстановления

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

Замечание

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

1. В PowerShell ISE откройте скрипт ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 и задайте следующие значения:

   • $DemoScenario = 2, создание среды восстановления зеркального изображения и репликация каталогов и баз данных клиента

2. Нажмите клавишу F5 , чтобы запустить скрипт. Откроется новый сеанс PowerShell для создания реплик.

Просмотр нормального состояния приложения

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

1. На портале Azure просмотрите группы ресурсов и обратите внимание на то, что группа ресурсов была создана с -recovery суффиксом в регионе восстановления.

2. Изучите ресурсы в группе ресурсов восстановления.

3. Щелкните на базе данных Contoso Concert Hall на сервере tenants1-dpt-<user>-recovery. Щелкните на Geo-Replication слева.

   

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

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

Обзор процесса восстановления георепликации

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

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

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

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

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

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

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

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

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

   Замечание

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

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

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

Запустите скрипт, чтобы переключиться на восстановительный регион.

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

1. В PowerShell ISE откройте скрипт ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 и задайте следующие значения:

   • $DemoScenario = 3, восстановите приложение в зону восстановления, переходом на реплики

2. Нажмите клавишу F5 , чтобы запустить скрипт.

   • Скрипт открывается в новом окне PowerShell, а затем запускает ряд заданий PowerShell, которые выполняются параллельно. Эти задания переключают базы данных клиента в регион восстановления.
   • Регион восстановления — это парный регион , связанный с регионом Azure, в котором развернуто приложение. Дополнительные сведения см. в статье Парные регионы Azure.

3. Отслеживайте состояние процесса восстановления в окне PowerShell.

Замечание

Чтобы изучить код заданий восстановления, просмотрите скрипты PowerShell в папке ...\Learning Modules\Business Continuity и Аварийное восстановление\DR-FailoverToReplica\RecoveryJobs.

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

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

1. Быстро после восстановления базы данных каталога обновите Центр событий Wingtip Tickets в веб-браузере.

   • В нижнем колонтитуле обратите внимание, что имя сервера каталога теперь имеет суффикс -recovery и находится в регионе восстановления.

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

     Замечание

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

     

   • Если открыть страницу событий офлайн-арендатора напрямую, отобразится уведомление "арендатор офлайн". Например, если Концертный зал Contoso находится в автономном режиме, попробуйте открыть http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall

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

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

1. В PowerShell ISE откройте сценарий ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 и задайте следующее свойство:

   • $DemoScenario = 4, создание нового арендатора в регионе восстановления

2. Нажмите F5, чтобы запустить скрипт и подготовить нового арендатора.

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

4. В браузере обновите страницу Центра мероприятий Wingtip Tickets, чтобы увидеть включенный зал Хоторн.

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

Проверка восстановленного состояния приложения

После завершения процесса восстановления приложение и все клиенты полностью работают в регионе восстановления.

1. После отображения в окне консоли PowerShell все клиенты будут восстановлены, обновите Концентратор событий. Все арендаторы будут представлены онлайн, в том числе новый арендатор, Hawthorn Hall.

   

2. На портале Azure перейдите к списку групп ресурсов.

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

3. Откройте группу ресурсов восстановления и обратите внимание на следующие элементы:

   • Версии восстановления серверов каталога и тенантов1 с суффиксом -recovery. Восстановленные базы данных каталога и клиентов на этих серверах имеют имена, используемые в исходном регионе.

   • Арендаторы2-dpt-user-recovery<> SQL Server. Этот сервер используется для подготовки новых клиентов во время сбоя.

   • Служба приложений с именем events-wingtip-dpt-<recoveryregion>-<user>, являющаяся восстановительным экземпляром приложения Events.

     

4. Откройте SQL сервер tenants2-dpt-<user>-recovery. Обратите внимание, что он содержит базу данных hawthornhall и эластичный пул Pool1. База данных hawthornhall настроена как эластичная база данных в эластичном пуле Pool1.

5. Вернитесь к группе ресурсов и нажмите на базу данных Contoso Concert Hall на сервере tenants1-dpt-<user>-recovery. Щелкните на Geo-Replication слева.

   

Изменение данных клиента

В этой задаче вы обновляете одну из баз данных клиента.

1. В браузере найдите список мероприятий для Концертного зала Contoso и запишите название последнего события.
2. В редакторе PowerShell ISE в скрипте ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 задайте следующее значение:
   • $DemoScenario = 5 Удаление события из клиента в регионе восстановления
3. Нажмите клавишу F5 , чтобы выполнить скрипт
4. Обновите страницу событий Contoso Concert Hall (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall — замените <user> значением пользователя вашего развертывания) и заметьте, что последнее событие было удалено.

Вернуть приложение в исходный производственный регион.

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

Обзор процесса репатриации

Процесс репатриации:

1. Отменяет все незавершённые или находящиеся в процессе запросы на восстановление базы данных.
2. Обновляет псевдоним newtenant, указывающий на сервер арендаторов в исходном регионе. Изменение этого псевдонима гарантирует, что базы данных для новых клиентов теперь будут подготовлены в исходном регионе.
3. Заполняет все изменённые данные арендатора в исходном регионе.
4. Переключение арендаторских баз данных по приоритету.

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

Запуск скрипта репатриации

Теперь давайте представим, что сбой разрешён, и запустим сценарий репатриации.

1. В среде сценариев PowerShell ISE в скрипте\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1.

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

   • $DemoScenario = 1, начать синхронизацию данных о сервере клиента, пуле и конфигурации базы данных в каталоге
   • Нажмите клавишу F5 , чтобы запустить скрипт.

3. Затем, чтобы начать процесс репатриации, установите:

   • $DemoScenario = 6, повторно запустите приложение в исходный регион.
   • Нажмите клавишу F5 , чтобы запустить скрипт восстановления в новом окне PowerShell. Репатриация займет несколько минут и может отслеживаться в окне PowerShell.

4. Пока скрипт запущен, обновите страницу Концентратора событий (http://events.wingtip-dpt.<user.trafficmanager.net>)

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

5. После завершения процесса репатриации обновите центр мероприятий и откройте страницу событий для Hawthorn Hall. Обратите внимание, что эта база данных была возвращена в исходный регион.

Проектирование приложения для обеспечения колокации приложения и базы данных.

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

Базы данных арендаторов могут распределяться между регионами восстановления и изначальными регионами в течение некоторого времени во время репатриации. Для каждой базы данных приложение ищет регион, в котором размещена база данных, выполняя поиск DNS по имени сервера клиента. В базе данных SQL имя сервера — это псевдоним. Псевдоним имени сервера содержит имя региона. Если приложение не находится в том же регионе, что и база данных, оно перенаправляется к экземпляру в том же регионе, где находится сервер. Перенаправление на экземпляр в том же регионе, что и база данных, сокращает задержку между приложением и базой данных.

Дальнейшие шаги

В этом руководстве вы узнали, как:

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

Дополнительные сведения о технологиях базы данных SQL Azure можно получить для обеспечения непрерывности бизнес-процессов в документации по непрерывности бизнес-процессов .

Дополнительные ресурсы

• Дополнительные руководства по работе с приложением SaaS Wingtip