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

Область применения:База данных SQL Azure

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

Геовосстановление — это наименее затратное решение для аварийного восстановления в Базе данных SQL Azure. Но восстановление из геоизбыточных резервных копий может приводить к потере данных за период длительностью до одного часа. Также оно может занимать много времени в зависимости от размера баз данных.

Примечание.

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

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

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

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

• Разверните приложение SaaS Wingtip Tickets с однотенантной базой данных. Изучите инструкции из руководства по быстрому развертыванию приложения SaaS Wingtip Tickets, использующего однотенантную базу данных.
• Установите Azure PowerShell. Дополнительные сведения см. в статье Начало работы с Azure PowerShell.

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

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

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

Примечание.

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

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

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

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

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

Важно!

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

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

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

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

   Прокрутите страницу вниз и обратите внимание на имя и расположение сервера каталогов в нижнем колонтитуле. Расположение — это регион, в котором вы развернули приложение.

   Совет

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

   

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

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

   

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

   Обратите внимание на ресурсы и регион развертывания компонентов службы приложений и Базы данных SQL.

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

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

Важно!

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

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

2. В интегрированной среде сценариев PowerShell откройте скрипт ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

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

3. Задайте следующие параметры:

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

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

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

   

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

Примечание.

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

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

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

Процесс восстановления выполняет следующие задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запустите скрипт восстановления

Важно!

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

Смоделируйте ситуацию сбоя в регионе, где развернуто приложение, выполнив скрипт восстановления:

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

   $DemoScenario = 2. Восстановление приложения в регионе восстановления из геоизбыточных резервных копий.

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

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

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

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

   

Примечание.

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

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

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

• После восстановления базы данных каталогов, но до возобновления работы клиентов, обновите концентратор событий Wingtip Tickets в веб-браузере.

  • В нижнем колонтитуле вы увидите, что имя сервера каталогов имеет суффикс -recovery и этот сервер размещен в регионе восстановления.

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

    

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

    

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

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

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

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

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

3. По завершении подготовки в браузере откроется страница событий для Hawthorn Hall.

   Обратите внимание, что база данных Hawthorn Hall расположена в регионе восстановления.

   

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

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

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

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

1. Как только в окне консоли PowerShell будет указано, что все клиенты восстановлены, обновите страницу концентратора событий.

   Все клиенты, включая Hawthorn Hall, будут обозначены как подключенные.

   

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

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

   

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

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

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

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

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

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

     

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

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

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

1. Найдите в браузере список событий для Contoso Concert Hall и прокрутите до последнего события Seriously Strauss.

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

   $DemoScenario = 4. Удаление события из клиента в регионе восстановления.

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

4. Обновите страницу событий Contoso Concert Hall (http://events.wingtip-dpt.<пользователь>.trafficmanager.net/contosoconcerthall) и обратите внимание, что событие Seriously Strauss исчезло.

На этом этапе в руководстве уже восстановлено приложение, которое выполняется в регионе восстановления. Новый клиент подготовлен в регионе восстановления, а также подготовлены измененные данные одного из восстановленных клиентов.

Примечание.

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

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

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

Процесс:

1. Останавливает любые текущие процессы восстановления и отменяет все необработанные или активные запросы на восстановление баз данных.

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

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

4. С помощью георепликации каталог перемещается из региона восстановления в исходный регион.

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

6. Создает необходимые серверы и пулы для размещения новых баз данных, созданных за время сбоя.

7. Применяет георепликацию для возврата баз данных клиентов, которые были обновлены после восстановления и подготовлены для новых клиентов за время сбоя.

8. Очищает ресурсы, созданные в регионе восстановления во время восстановления.

Чтобы сократить количество возвращаемых клиентских баз данных, шаги 1–3 выполняются в кратчайшие сроки.

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

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

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

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

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

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

На шаге 8 ресурсы в регионе восстановления, включая серверы и пулы восстановления, будут удалены.

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

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

Если вы точно следовали руководству, этот скрипт немедленно активирует клиентов Fabrikam Jazz Club и Dogwood Dojo в исходном регионе, так как данные для них не изменялись. Затем выполняется репатриация нового клиента, Hawthorn Hall и Contoso Concert Hall, так как были внесены изменения. Скрипт также репатриирует каталог, который был обновлен во время подготовки Hawthorn Hall.

1. В интегрированной среде сценариев PowerShell откройте скрипт ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 и убедитесь, что процесс Catalog Sync еще выполняется в соответствующем экземпляре PowerShell. При необходимости перезапустите его, задав:

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

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

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

   $DemoScenario = 5. Возвращение приложения в исходный регион.

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

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

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

4. Выберите Jazz Fabrikam Club, чтобы открыть сведения о клиенте. Если вы не изменяли его данные, в нижнем колонтитуле в качестве расположения уже будет указан исходный сервер.

5. Откройте или обновите страницу событий для Contoso Concert Hall. В нижнем колонтитуле еще некоторое время будет указываться, что база данных находится на сервере восстановления (-recovery).

6. Когда завершится возвращение, обновите страницу событий для Contoso Concert Hall. Теперь база данных снова расположена в исходном регионе.

7. Еще раз обновите страницу концентратора событий и откройте Hawthorn Hall. Здесь также указано, что база данных находится в исходном регионе.

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

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

Важно!

Удалите эти ресурсы незамедлительно, чтобы остановить все выставления счетов за них.

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

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

   $DemoScenario = 6. Удаление устаревших ресурсов из региона восстановления.

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

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

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

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

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

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

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

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

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

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

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