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

Применимо к:Управляемый экземпляр SQL Azure

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

Обзор

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

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

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

Доступность

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

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

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

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

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

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

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

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

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

RTO и RPO

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

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

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

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

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

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

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

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

• Одним из вариантов является ожидание возвращения экземпляра в режим "в сети", когда сбой центра обработки данных закончится. Это работает для приложений, которые могут позволить себе автономный доступ к базе данных. Например, вам не нужно непрерывно работать с проектом по разработке или бесплатной пробной версией. Если в центре обработки данных возникает сбой, вы не знаете, сколько времени может длиться сбой, поэтому этот параметр работает только в том случае, если база данных не нужна в течение некоторого времени.
• Если вы используете геоизбыточное хранилище (GRS) или геоизбыточное хранилище (GZRS), то другой вариант — восстановить базу данных в любом управляемом экземпляре SQL в любом регионе Azure с помощью геоизбыточного резервного копирования базы данных (геовосстановление ). Геовосстановление использует геоизбыточное резервное копирование в качестве источника и может использоваться для восстановления базы данных до последней доступной точки во времени, даже если база данных или центр обработки данных недоступна из-за сбоя. Доступное резервное копирование можно найти в парном регионе.
• Наконец, вы можете быстро восстановиться после сбоя, если вы настроили геоторию с помощью группы отработки отказа для вашего экземпляра, используя клиент (рекомендуется) или управляемую корпорацией Майкрософт отработку отказа. Хотя отработка отказа занимает всего несколько секунд, служба занимает по крайней мере 1 час для активации геоработки отказа, управляемой корпорацией Майкрософт, при настройке. Это необходимо, чтобы гарантировать, что отработка отказа оправдана масштабом сбоя. Кроме того, отработка отказа может привести к потере недавно измененных данных из-за характера асинхронного реплика отработки отказа между парными регионами.

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

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

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

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

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

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

Подготовка к сбою

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

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

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

Отработка отказа в геоизбыточное реплика вторичного экземпляра

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

Примечание.

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

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

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

Примечание.

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

Выполнение задач после восстановления размещения и восстановления

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

• Перенаправьте клиенты и клиентские приложения на новый экземпляр и восстановленную базу данных.
• Убедитесь, что для подключения пользователей установлены соответствующие правила брандмауэра IP-адресов сети.
• Убедитесь, что существуют соответствующие разрешения для входа и master уровня базы данных (или использование содержащихся пользователей).
• Настройте аудит соответствующим образом.
• Настройте оповещения соответствующим образом.

Примечание.

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

Бесплатные реплика аварийного восстановления

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

Если вы назначаете дополнительный экземпляр только для аварийного восстановления, и на экземпляре не выполняются рабочие нагрузки чтения или записи, корпорация Майкрософт предоставляет вам количество виртуальных ядер, лицензированных для основного экземпляра без дополнительной платы в рамках преимущества прав отработки отказа. Плата за вычислительные ресурсы и хранилище, которые использует вторичный экземпляр, по-прежнему взимается. Точные условия преимущества прав гибридной отработки отказа см. в разделе "Условия лицензирования SQL Server — права на отработку отказа".

Имя преимущества зависит от вашего сценария:

• Права гибридной отработки отказа для пассивного реплика. При настройке связи между SQL Server и Управляемый экземпляр SQL Azure вы можете использовать преимущество гибридных прав отработки отказа для экономии затрат на лицензирование виртуальных ядер для пассивного вторичного реплика.
• Права отработки отказа для резервной реплика. При настройке группы отработки отказа между двумя управляемыми экземплярами можно использовать преимущество прав отработки отказа для экономии затрат на лицензирование виртуальных ядер для резервного дополнительного реплика.

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

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

Дополнительные сведения о функциях непрерывности бизнес-процессов см. в статье "Автоматические резервные копии" и группы отработки отказа. В случае аварии см . статью "Восстановление базы данных".