Поделиться через

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

  • Статья

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

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

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

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

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

Введение в шаблон восстановления с использованием георепликации

Архитектура восстановления

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

    • Обратите внимание на регион, где развернуты серверы.

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

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

Внимание

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

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

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

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

  3. Нажмите клавишу F5 для запуска скрипта синхронизации. Будет открыт новый сеанс PowerShell для синхронизации конфигурации ресурсов клиента. Снимок экрана: открыт новый сеанс PowerShell для синхронизации конфигурации ресурсов клиента.

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

Примечание.

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

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

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

Примечание.

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

  1. В интегрированной среде сценариев PowerShell откройте скрипт ...\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-<пользователь>-recovery. Выберите пункт "Георепликация" в меню слева.

    Связь георепликации Contoso Concert

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

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

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

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

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

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

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

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

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

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

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

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

    Примечание.

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

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

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

Выполнение скрипта для отработки отказа в регион восстановления

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

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

    • $DemoScenario = 3. Восстановление приложения в регионе восстановления путем отработки отказа в реплики.

  2. Нажмите клавишу F5 для запуска скрипта.

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

Примечание.

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

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

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

  1. Когда база данных каталога будет восстановлена, обновите концентратор событий Wuetip Tickets в веб-браузере.

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

    • Обратите внимание, что клиенты, которые еще не восстановлены, отмечены как автономные и не могут быть выбраны.

      Примечание.

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

      Автономный режим концентратора событий

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

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

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

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

    • $DemoScenario = 4. Подготовка нового клиента в регионе восстановления.

  2. Нажмите клавишу F5 для запуска скрипта и подготовки нового клиента.

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

  4. В браузере обновите страницу концентратора событий Widtip Tickets, чтобы увидеть добавленную страницу Hawthorn Hall.

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

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

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

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

    Восстановленные и новые клиенты в концентраторе событий

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

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

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

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

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

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

      Ресурсы восстановления Azure

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

  5. Перейдите в группу ресурсов и щелкните базу данных Contoso Concert Hall на сервере tenants1-dpt-<пользователь>-recovery. Выберите пункт "Георепликация" в меню слева.

    База данных Contoso после отработки отказа

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

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

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

Репатриация приложения в исходный рабочий регион

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

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

Архитектура репатриации

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

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

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

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

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

  1. В интегрированной среде сценариев PowerShell откройте скрипт ...\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.<пользователь>.trafficmanager.net).

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

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

Разработка приложения для обеспечения совместного размещения приложения и базы данных

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

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

Следующие шаги

Из этого руководства вы узнали, как выполнять такие задачи:

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

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

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