Стратегии аварийного восстановления для приложений с использованием эластичных пулов Баз данных SQL Azure

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

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

В этой статье используется следующий шаблон канонического приложения независимого поставщика программного обеспечения SaaS:

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

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

Примечание.

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

Сценарий 1. Приложения с ограниченным бюджетом

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

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

На схеме ниже показаны шаги восстановления работоспособности приложения после сбоя в основном регионе.

• Группа отработки отказа инициирует автоматическую отработку отказа базы данных управления в регион аварийного восстановления. Приложение автоматически повторно подключается к новой базе данных-источнику. В регионе аварийного восстановления создаются учетные записи и базы данных клиента. Для имеющихся клиентов данные будут временно недоступными.
• Создание пула эластичных БД с такими же настройками, как и в исходном пуле БД (2).
• Использование геовосстановления для создания копий баз данных клиента (3). При необходимости можно запустить отдельные процессы восстановления на основе подключений пользователей или использовать другие схемы расстановки приоритетов приложения.

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

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

• Отмена всех ожидающих запросов на геовосстановление.
• Отработка отказа баз данных управления в основном регионе (5). После восстановления региона старые первичные элементы автоматически становятся вторичными. Теперь они снова поменяются ролями.
• Изменение строки подключения приложения для указания основного региона. В основном регионе создаются учетные записи и базы данных клиента. Для некоторых клиентов данные будут временно недоступными.
• Настройка доступа только для чтения для всех баз данных в пуле аварийного восстановления, чтобы предотвратить их изменение в регионе аварийного восстановления (6).
• Удаление или переименование баз данных основного пула, которые были изменены в пуле аварийного восстановления во время процесса восстановления (7).
• Копирование обновленных баз данных из пула аварийного восстановления в основной пул (8).
• Удаление пула аварийного восстановления (9).

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

Преимущества

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

Компромиссы

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

Сценарий 2. Отлаженное приложение с многоуровневой службой

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

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

Как и в первом сценарии, в качестве баз данных управления следует использовать геореплицируемые изолированные базы данных (1), так как они будут довольно активно использоваться. Это позволит обеспечить предсказуемую производительность новых клиентских подписок, операций обновления профиля и других операций управления. Регион, в котором содержатся базы данных-источники баз данных управления, используется в качестве основного, а регион, в котором находятся базы данных-получатели, — в качестве региона аварийного восстановления.

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

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

• Незамедлительная отработка отказа баз данных управления в регионе аварийного восстановления (3).
• Измените строка подключения приложения, чтобы указать регион аварийного восстановления. В регионе аварийного восстановления создаются учетные записи и базы данных клиента. Для имеющихся пользователей пробной версии данные будут временно недоступными.
• Отработка отказа платных баз данных в пул региона аварийного восстановления для немедленного восстановления их доступности (4). Так как отработка отказа сопровождается быстрым изменением уровня метаданных, этот процесс можно оптимизировать, запустив отдельные процессы восстановления по требованию на основе подключений пользователей.
• Если число eDTU или виртуальных ядер дополнительного пула было ниже, чем у основного, так как для дополнительных баз данных eDTU требуются только для обработки журналов изменений при пребывании в роли дополнительных, увеличьте объем пула с учетом рабочей нагрузки всех клиентов (5).
• Создание в регионе аварийного восстановления нового пула эластичных БД с теми же именем и конфигурацией для баз данных пользователей пробной версии (6).
• После создания пула пробных клиентов используйте геовосстановление для восстановления отдельных баз данных клиента пробной версии в новом пуле (7). При необходимости можно запустить отдельные процессы восстановления на основе подключений пользователей или использовать другие схемы расстановки приоритетов приложения.

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

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

• Отмена всех ожидающих запросов на геовосстановление.
• Отработка отказа баз данных управления (8). После восстановления региона старый первичный автоматически становится вторичным. Теперь она снова получит роль базы данных-источника.
• Отработка отказа для баз данных платных клиентов (9). Аналогичным образом, после восстановления региона старые праймериз автоматически становятся вторыми. Теперь они снова становятся базами данных-источниками.
• Настройка доступа только для чтения для всех восстановленных баз данных пользователей пробной версии в регионе аварийного восстановления (10).
• Удаление или переименование баз данных в основном пуле пользователей пробной версии, которые были изменены в пуле аварийного восстановления во время процесса восстановления (11).
• Копирование обновленных баз данных из пула аварийного восстановления в основной пул (12).
• Удаление пула аварийного восстановления (13).

Примечание.

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

Преимущества

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

Компромиссы

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

Сценарий 3. Географически распределенное приложение с многоуровневой службой

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

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

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

Как и в предыдущих сценариях, в качестве баз данных управления настройте геореплицируемые изолированные базы данных (1), так как они довольно активно используются. Это позволит обеспечить предсказуемую производительность новых клиентских подписок, операций обновления профиля и других операций управления. Регион А используется в качестве основного региона для баз данных управления, а регион Б — в качестве региона для их восстановления.

Базы данных клиента для оплаты клиентов также гео-реплика, но с первичными и вторичными файлами разделены между регионом A и регионом B (2). Таким образом, в случае сбоя для затронутых баз данных-источников можно выполнить отработку отказа в другой регион и обеспечить их доступность. На производительность другой половины баз данных сбой не повлияет.

На следующей схеме показаны шаги восстановления в случая сбоя в регионе А.

• Незамедлительная отработка отказа баз данных управления в регион Б (3).
• Измените строка подключения приложения, чтобы указать на базы данных управления в регионе B. Измените базы данных управления, чтобы убедиться, что новые учетные записи и базы данных клиента созданы в регионе B, а существующие базы данных клиента находятся там. Для имеющихся пользователей пробной версии данные будут временно недоступными.
• Отработка отказа баз данных платных пользователей в пул 2 региона Б для немедленного восстановления их доступности (4). Так как отработка отказа сопровождается быстрым изменением уровня метаданных, этот процесс можно оптимизировать, запустив отдельные процессы восстановления по требованию на основе подключений пользователей.
• Так как теперь в пуле 2 содержатся только базы данных-источники, рабочая нагрузка в нем увеличится и может незамедлительно увеличить число eDTU (5) или виртуальных ядер.
• Создание в регионе Б нового пула эластичных БД с теми же именем и конфигурацией для баз данных пользователей пробной версии (6).
• После создания пула используйте геовосстановление, чтобы выполнить восстановление отдельной базы данных клиента пробной версии (7). При необходимости можно запустить отдельные процессы восстановления на основе подключений пользователей или использовать другие схемы расстановки приоритетов приложения.

Примечание.

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

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

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

• Отмена всех ожидающих запросов на геовосстановление в пуле аварийного восстановления для пользователей пробной версии.
• Отработка отказа базы данных управления (8). После восстановления региона старый первичный автоматически стал вторичным. Теперь она снова получит роль базы данных-источника.
• Выбор баз данных пользователей платной версии, для которых необходимо выполнить восстановление размещения в пул 1, и запуск отработки отказа для их баз данных-получателей (9). После восстановления региона все базы данных в пуле 1 автоматически стали вторичными. Теперь половина баз данных снова становятся базами данных-источниками.
• Уменьшение размера пула 2 до исходного числа eDTU (10) или виртуальных ядер.
• Настройка доступа только для чтения для всех восстановленных баз данных пользователей пробных версий в регионе Б (11).
• Удаление или переименование баз данных основного пула пользователей пробной версии, которые были изменены в аналогичном пуле аварийного восстановления во время процесса восстановления (12).
• Копирование обновленных баз данных из пула аварийного восстановления в основной пул (13).
• Удаление пула аварийного восстановления (14).

Преимущества

Преимущества этой стратегии перечислены ниже.

• Обеспечивает поддержку соглашения об уровне обслуживания с наивысшим уровнем услуг для пользователей платной версии приложения. Это позволяет сохранить работоспособность 50 % баз данных клиентов после сбоя.
• Эта стратегия гарантирует, что новые пробные версии будут доступны сразу же после создания пула аварийного восстановления для пользователей пробной версии.
• Позволяет более эффективно использовать емкость пула, так как в 50 % баз данных-получателей в пуле 1 и 2 снижена активность по сравнению с базами данных-источниками.

Компромиссы

Недостатки этой стратегии перечислены ниже.

• Операции CRUD в базах данных управления имеют меньшую задержку для пользователей в регионе А, чем для пользователей в регионе Б, так как они выполняются с базами данных-источниками баз данных управления.
• Она требует более сложной структуры базы данных управления. Например, каждая запись клиента включает в себя тег расположения, который необходимо изменить во время отработки отказа и восстановления размещения.
• У пользователей платной версии приложения до завершения обновления пула в регионе Б будут возникать проблемы с производительностью.

Итоги

В этой статье рассматриваются стратегии аварийного восстановления для уровня базы данных, используемого мультитенантным приложением SaaS ISV. Выбор стратегии определяется потребностями (бизнес-моделью) приложения, требованиями к соглашению об уровне обслуживания для клиентов, бюджетными ограничениями и т. п. Для каждой из предложенных стратегий представлены сведения о преимуществах и компромиссах, которые помогут вам принять взвешенное решение. Вероятно, ваше приложение включает другие компоненты Azure. Изучите руководство по обеспечению непрерывности бизнес-процессов для этих компонентов и выполните восстановление на уровне базы данных. Дополнительные сведения об управлении восстановлением приложений базы данных в Azure см. в статье Разработка службы высокой доступности с помощью базы данных SQL Azure.

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

• Чтобы узнать об автоматически создаваемых резервных копиях базы данных SQL Azure, ознакомьтесь с разделом Автоматическое резервное копирование в Базе данных SQL Azure.
• Сведения об обеспечении непрерывности бизнес-процессов и возможные сценарии описаны в обзоре непрерывности бизнес-процессов.
• Чтобы узнать об использовании автоматически создаваемых резервных копий для восстановления, ознакомьтесь с восстановлением базы данных из резервных копий, инициируемых службой.
• Сведения о более быстрых вариантах восстановления см. в разделе "Активные гео-реплика tion" и "Группы отработки отказа".
• Чтобы узнать об использовании автоматически создаваемых резервных копий для архивации, ознакомьтесь с копированием базы данных.