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

Статья
01/05/2024

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

Обзор

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

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

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

Доступность

База данных SQL Azure поставляется с основным обещанием устойчивости и надежности, которое защищает его от сбоев программного обеспечения или оборудования. Резервные копии базы данных автоматизированы для защиты данных от повреждения или случайного удаления. Как услуга "Платформа как услуга" (PaaS), служба База данных SQL Azure обеспечивает доступность в качестве автономной функции с соглашением об уровне обслуживания от 99,99%.

Высокий уровень доступности

Чтобы обеспечить высокий уровень доступности в облачной среде Azure, включите избыточность зоны, чтобы база данных или эластичные пулы использовала зоны доступности для обеспечения устойчивости базы данных или эластичного пула к зональным сбоям. Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона с независимым питанием, охлаждением и сетевой инфраструктурой. Зоны доступности предназначены для предоставления региональных служб, емкости и высокой доступности в оставшихся зонах, если одна зона испытывает сбой. Благодаря обеспечению избыточности зоны база данных или эластичного пула устойчива к зональным сбоям оборудования и программного обеспечения, а восстановление прозрачно для приложений. Если включена высокая доступность, служба База данных SQL Azure может обеспечить более высокую доступность 99,995 %.

Аварийное восстановление

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

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

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

	Активное гео реплика	Группы отработки отказа
Непрерывная синхронизация данных между первичной и вторичной	Да	Да
Одновременная отработка отказа нескольких баз данных	No	Да
строка Подключение ion остается неизменной после отработки отказа	No	Да
Поддержка масштабирования для чтения	Да	Да
Несколько реплик	Да	Нет
Может быть в том же регионе, что и основной	Да	Нет

Функции, обеспечивающие непрерывность бизнес-процессов

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

Сценарий нарушения бизнес-процессов	Функция обеспечения непрерывности бизнес-процессов
Локальные сбои оборудования или программного обеспечения, влияющие на узел базы данных.	Чтобы устранить локальные сбои оборудования и программного обеспечения, База данных SQL включает архитектуру доступности, которая гарантирует автоматическое восстановление от этих сбоев с уровнем обслуживания до 99,99 %.
Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой базы данных.	Чтобы защитить бизнес от потери данных, База данных SQL автоматически создает полные резервные копии базы данных еженедельно, разностные резервные копии баз данных каждые 12 или 24 часа, а резервные копии журналов транзакций создаются каждые 5 – 10 минут. По умолчанию резервные копии хранятся в геоизбыточное хранилище в течение семи дней для всех уровней служб. Все уровни служб, кроме базовых, поддерживают настраиваемый период хранения резервных копий для восстановления на определенный момент времени (PITR) до 35 дней. Вы можете восстановить удаленную базу данных до точки, в которой она была удалена, если сервер не был удален, или если вы настроили долгосрочное хранение (LTR).
Редкий сбой центра обработки данных или зоны доступности, возможно, вызванный событием стихийных бедствий, изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования.	Чтобы устранить сбой в центре обработки данных или уровне доступности, включите избыточность зоны для базы данных или эластичного пула для использования Azure Зоны доступности и обеспечения избыточности в нескольких физических зонах в регионе Azure. Включение избыточности зоны гарантирует устойчивость базы данных или эластичного пула к зональным сбоям до 99,995 % уровня обслуживания.
Редкий региональный сбой , влияющий на все зоны доступности и центры обработки данных, состоящие из них, возможно, вызваны катастрофическим событием стихийных бедствий.	Чтобы устранить сбой на уровне региона, включите аварийное восстановление с помощью одного из вариантов: — параметры непрерывной синхронизации данных, такие как группы отработки отказа (рекомендуемые) или активные гео-реплика tion, позволяющие создавать реплика в дополнительном регионе для отработки отказа. — установка избыточности хранилища резервных копий в геоизбыточное хранилище резервных копий для использования геовосстановление.

RTO и RPO

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

В следующей таблице сравнивается RPO и RTO каждого варианта непрерывности бизнес-процессов:

Вариант непрерывности бизнес-процессов	RTO (простой)	RPO (потеря данных)
Высокий уровень доступности (включение избыточности зоны)	Обычно менее 30 секунд	0
Аварийное восстановление (включение групп отработки отказа или активное гео-реплика tion)	Обычно менее 60 секунд	Равно или больше 0 (зависит от изменений данных до события нарушения, которое не было реплика)
Аварийное восстановление (использование геовосстановление)	Обычно это минуты или часы	Обычно это минуты или часы

Списки проверка непрерывности бизнес-процессов

Рекомендации по повышению доступности и повышению непрерывности бизнес-процессов см. в следующих статье:

Подготовка к сбою региона

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

Восстановление базы данных в одном регионе Azure

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

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

Обновление приложения с минимальным простоем

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

Экономия на затратах с помощью резервного реплика

Если вторичная реплика используется только для аварийного восстановления (АВАРИЙНОго восстановления) и не имеет рабочих нагрузок чтения или записи, вы можете сэкономить на затратах на лицензирование, указав базу данных для ожидания при настройке новой активной связи гео-реплика.

Просмотрите бесплатные резервные реплика лицензий, чтобы узнать больше.

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

Рекомендации по проектированию приложений см. в статье "Разработка приложения для аварийного восстановления облака" и стратегий аварийного восстановления эластичного пула.

Просмотрите рекомендации по аварийному восстановлению База данных SQL Azure и База данных SQL Azure высокий уровень доступности и список проверка аварийного восстановления.