Обзор обеспечения непрерывности бизнес-процессов с помощью Базы данных SQL Azure
Применимо к:
База данных SQL Azure
В этой статье представлен обзор возможностей непрерывности бизнес-процессов и аварийного восстановления База данных SQL Azure, описывающих параметры и рекомендации по восстановлению после разрушительных событий, которые могут привести к потере данных или привести к недоступности базы данных и приложения. Узнайте, что делать, когда ошибка пользователя или приложения влияет на целостность данных, зону доступности Azure или регион сбоем, или приложение требует обслуживания.
Обзор
Непрерывность бизнес-процессов в База данных SQL Azure относится к механизмам, политикам и процедурам, которые позволяют бизнесу продолжать работать в условиях нарушения, обеспечивая доступность, высокий уровень доступности и аварийное восстановление.
В большинстве случаев База данных SQL обрабатывает разрушительные события, которые могут произойти в облачной среде и сохраняет выполнение приложений и бизнес-процессов. Однако существуют некоторые разрушительные события, когда устранение рисков может занять некоторое время, например:
- Пользователь случайно удаляет или обновляет строку в таблице.
- Злоумышленник успешно удаляет данные или удаляет базу данных.
- Катастрофическое событие стихийных бедствий приведет к сбою центра обработки данных или зоны доступности или региона.
- Редкий центр обработки данных, зона доступности или сбой на уровне региона, вызванный изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования.
Availability
База данных SQL Azure поставляется с основным обещанием устойчивости и надежности, которое защищает его от сбоев программного обеспечения или оборудования. Резервные копии базы данных автоматизированы для защиты данных от повреждения или случайного удаления. Как услуга "Платформа как услуга" (PaaS), служба База данных SQL Azure обеспечивает доступность в качестве автономной функции с соглашением об уровне обслуживания от 99,99%.
Высокий уровень доступности
Чтобы обеспечить высокий уровень доступности в облачной среде Azure, включите избыточность зоны, чтобы база данных или эластичные пулы использовала зоны доступности для обеспечения устойчивости базы данных или эластичного пула к зональным сбоям. Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона с независимым питанием, охлаждением и сетевой инфраструктурой. Зоны доступности предназначены для предоставления региональных служб, емкости и высокой доступности в оставшихся зонах, если одна зона испытывает сбой. Благодаря обеспечению избыточности зоны база данных или эластичного пула устойчива к зональным сбоям оборудования и программного обеспечения, а восстановление прозрачно для приложений. Если включена высокая доступность, служба База данных SQL Azure может обеспечить более высокую доступность 99,995 %.
Аварийное восстановление
Чтобы обеспечить более высокую доступность и избыточность в разных регионах, можно включить возможности аварийного восстановления для быстрого восстановления базы данных из катастрофического регионального сбоя. Варианты аварийного восстановления с помощью База данных SQL Azure:
- Активная георепликация позволяет создавать непрерывно синхронизированную читаемую базу данных-получатель в любом регионе для базы данных-источника.
- Группы отработки отказа, помимо непрерывной синхронизации между базой данных-источником и базой данных-получателем, также позволяют управлять репликацией и отработкой отказа некоторых баз данных на логическом сервере на дополнительный логический сервер в другом регионе. Группы отработки отказа предоставляют конечные точки прослушивателя только для чтения и чтения, которые остаются неизменными, поэтому обновление приложений строка подключения после отработки отказа не требуется.
- Геовосстановление позволяет восстановиться после регионального сбоя путем восстановления из геореплицированных резервных копий, когда вы не сможете получить доступ к базе данных в основном регионе, создав базу данных на любом существующем сервере в любом регионе Azure.
В следующей таблице сравниваются активные георепликации и группы отработки отказа, два варианта аварийного восстановления для База данных SQL Azure:
| Активная георепликация | Группы отработки отказа | |
|---|---|---|
| Непрерывная синхронизация данных между первичной и вторичной | Да | Да |
| Одновременная отработка отказа нескольких баз данных | No | Да |
| Строка подключения остается неизменной после отработки отказа | No | Да |
| Поддержка масштабирования для чтения | Да | Да |
| Несколько реплик | Да | Нет |
| Может быть в том же регионе, что и основной | Да | Нет |
Функции, обеспечивающие непрерывность бизнес-процессов
С точки зрения базы данных существует четыре основных возможных сценария нарушения. В следующей таблице перечислены База данных SQL функции непрерывности бизнес-процессов, которые можно использовать для устранения потенциального сценария нарушения бизнес-процессов:
| Сценарий нарушения бизнес-процессов | Функция обеспечения непрерывности бизнес-процессов |
|---|---|
| Локальные сбои оборудования или программного обеспечения, влияющие на узел базы данных. | Чтобы устранить локальные сбои оборудования и программного обеспечения, База данных SQL включает архитектуру доступности, которая гарантирует автоматическое восстановление от этих сбоев с уровнем обслуживания до 99,99 %. |
| Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой базы данных. | Чтобы защитить бизнес от потери данных, База данных SQL автоматически создает полные резервные копии базы данных еженедельно, разностные резервные копии баз данных каждые 12 или 24 часа, а резервные копии журналов транзакций создаются каждые 5 – 10 минут. По умолчанию резервные копии хранятся в геоизбыточное хранилище в течение семи дней для всех уровней служб. Все уровни служб, кроме базовых, поддерживают настраиваемый период хранения резервных копий для восстановления на определенный момент времени (PITR) до 35 дней. Вы можете восстановить удаленную базу данных до точки, в которой она была удалена, если сервер не был удален, или если вы настроили долгосрочное хранение (LTR). |
| Редкий сбой центра обработки данных или зоны доступности, возможно, вызванный событием стихийных бедствий, изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования. | Чтобы устранить сбой в центре обработки данных или уровне доступности, включите избыточность зоны для базы данных или эластичного пула для использования Azure Зоны доступности и обеспечения избыточности в нескольких физических зонах в регионе Azure. Включение избыточности зоны гарантирует устойчивость базы данных или эластичного пула к зональным сбоям до 99,995 % уровня обслуживания. |
| Редкий региональный сбой , влияющий на все зоны доступности и центры обработки данных, состоящие из них, возможно, вызваны катастрофическим событием стихийных бедствий. | Чтобы устранить сбой на уровне региона, включите аварийное восстановление с помощью одного из вариантов: — параметры непрерывной синхронизации данных, такие как группы отработки отказа (рекомендуется) или активная георепликация, позволяющие создавать реплики в дополнительном регионе для отработки отказа. — установка избыточности хранилища резервных копий в геоизбыточное хранилище резервных копий для использования геовосстановление. |
RTO и RPO
При разработке плана непрерывности бизнес-процессов понять максимально допустимое время до полного восстановления приложения после нарушения. Время, необходимое для полного восстановления приложения, называется целевой задачей времени восстановления (RTO). Кроме того, понять максимальный период последних обновлений данных (интервал времени) приложение может терпеть потерю при восстановлении после незапланированного нарушения события. Потенциальная потеря данных называется целевой точкой восстановления (RPO).
В следующей таблице сравнивается RPO и RTO каждого варианта непрерывности бизнес-процессов:
| Вариант непрерывности бизнес-процессов | RTO (простой) | RPO (потеря данных) |
|---|---|---|
| Высокий уровень доступности (использование избыточности зоны) |
Обычно менее 30 секунд | 0 |
| Аварийное восстановление (использование групп отработки отказа с политикой отработки отказа клиента или активной георепликацией) |
Обычно менее 60 секунд | Равно или больше 0 (зависит от изменений данных перед нарушением события, которое не было реплицировано). |
| Аварийное восстановление (использование геовосстановление) |
Обычно это минуты или часы | Обычно это минуты или часы |
Контрольные списки непрерывности бизнес-процессов
Рекомендации по повышению доступности и повышению непрерывности бизнес-процессов см. в следующих статье:
- Контрольный список для обеспечения доступности
- Контрольный список для обеспечения высокой доступности
- Контрольный список аварийного восстановления
Подготовка к сбою региона
Независимо от того, какие функции непрерывности бизнес-процессов используются, необходимо подготовить базу данных-получатель в другом регионе. Если вы не готовитесь должным образом, перенос приложений в сети после отработки отказа или восстановления занимает дополнительное время, и, скорее всего, требует устранения неполадок, что может отложить RTO. Следуйте контрольным списку для подготовки дополнительных к сбоям региона.
Восстановление базы данных в одном регионе Azure
Для восстановления базы данных до точки во времени в прошлом можно использовать автоматическое резервное копирование базы данных. Таким образом можно выполнить восстановление после повреждения данных, вызванного ошибками человека. Восстановление на определенный момент времени (PITR) позволяет создать новую базу данных на том же сервере, который представляет состояние данных до повреждения события. Для большинства баз данных операции восстановления занимают менее 12 часов. Восстановление очень большой или очень активной базы данных может занять больше времени. Дополнительные сведения см. в статье о времени восстановления базы данных.
Если максимальное поддерживаемое время хранения резервных копий для восстановления на определенный момент времени недостаточно для приложения, его можно расширить, настроив политику долгосрочного хранения (LTR) для баз данных. Дополнительные сведения см. в разделе Долгосрочное хранение резервных копий.
Обновление приложения с минимальным простоем
Иногда приложение должно быть отключено из-за обслуживания, например обновления приложения. В статье Управление последовательными обновлениями для облачных приложений с помощью активной георепликации базы данных SQL описывается, как с помощью активной георепликации обеспечить последовательное обновление облачного приложения, чтобы свести к минимуму простой при обновлениях и обеспечить путь восстановления, если случится сбой.
Экономия на затратах с помощью резервной реплики
Если вторичная реплика используется только для аварийного восстановления (АВАРИЙНОго восстановления) и не имеет рабочих нагрузок чтения или записи, вы можете сэкономить на затратах на лицензирование, назначив базу данных для ожидания при настройке новой активной связи георепликации.
Ознакомьтесь с бесплатной резервной репликой , чтобы узнать больше.
Следующие шаги
Рекомендации по проектированию приложений см. в статье "Разработка приложения для аварийного восстановления облака" и стратегий аварийного восстановления эластичного пула.
Ознакомьтесь с руководством по аварийному восстановлению База данных SQL Azure и База данных SQL Azure контрольным списком высокого уровня доступности и аварийного восстановления.