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