Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения:
Управляемый экземпляр SQL Azure
В этой статье представлен обзор возможностей обеспечения непрерывности бизнес-процессов и аварийного восстановления управляемого экземпляра SQL Azure, описывающий параметры и рекомендации по восстановлению после разрушительных событий, которые могут привести к потере данных или вызвать недоступность экземпляра и приложения. Узнайте, что делать, когда ошибка пользователя или приложения влияет на целостность данных, в зоне доступности Azure или регионе происходит сбой, или ваше приложение требует обслуживания.
Обзор
Непрерывность бизнес-процессов в Azure SQL Управляемый экземпляр относится к механизмам, политикам и процедурам, которые позволяют бизнесу продолжать работать в условиях нарушения работы, обеспечивая доступность и высокий уровень надежности, а также аварийное восстановление.
В большинстве случаев Управляемый экземпляр SQL обрабатывает разрушительные события, которые могут произойти в облачной среде и сохраняет выполнение приложений и бизнес-процессов. Однако существуют некоторые разрушительные события, когда устранение рисков может занять некоторое время, например:
- Пользователь случайно удаляет или обновляет строку в таблице.
- Злоумышленник успешно удаляет данные или удаляет базу данных.
- Катастрофическое событие стихийных бедствий приведет к сбою центра обработки данных или зоны доступности или региона.
- Редкий центр обработки данных, зона доступности или сбой на уровне региона, вызванный изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования.
Рекомендации по повышению доступности и повышению непрерывности бизнес-процессов см. в следующей статье:
- Контрольный список для обеспечения доступности
- Контрольный список для обеспечения высокой доступности
- Контрольный список аварийного восстановления
Высокий уровень доступности
Управляемый экземпляр SQL Azure поставляется с основным обещанием устойчивости и надежности, которое защищает его от сбоев программного обеспечения или оборудования. Резервные копии базы данных автоматизированы для защиты данных от повреждения или случайного удаления. Как платформа как услуга (PaaS), служба Azure SQL Managed Instance обеспечивает доступность как встроенную функцию с передовым в отрасли Соглашением об уровне доступности (SLA) - 99,99%.
Чтобы обеспечить высокий уровень доступности в облачной среде Azure, включите избыточность зоны. При избыточности зоны экземпляр использует зоны доступности , чтобы обеспечить устойчивость к зональным сбоям.
- Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона с независимым питанием, охлаждением и сетевой инфраструктурой.
- Зоны доступности предназначены для обеспечения региональных услуг, мощностей и высокой доступности в оставшихся зонах, если одна зона испытывает сбой.
Включив зональную избыточность, экземпляр становится устойчивым к зональным сбоям оборудования и программного обеспечения, а восстановление проходит прозрачно для приложений. Если включена высокая доступность, служба Azure SQL Managed Instance может обеспечить более высокий уровень доступности SLA в 99,99 %.
Аварийное восстановление
Чтобы обеспечить более высокую доступность и резервирование ресурсов в различных регионах, можно включить функции аварийного восстановления для быстрого восстановления экземпляра после катастрофического сбоя в регионе. Варианты восстановления после катастроф с помощью экземпляра управляемой Azure SQL:
- Группы автоматического переключения обеспечивают непрерывную синхронизацию между первичной и вторичной инстанциями. Группы отработки отказа предоставляют конечные точки прослушивателя для чтения и записи и только для чтения, которые остаются неизменными, поэтому обновление строк подключения приложений после отработки отказа не требуется.
- Геовосстановление позволяет восстановиться после регионального сбоя путем восстановления из геореплицированных резервных копий, если вы не сможете получить доступ к базе данных в основном регионе, создав базу данных на любом существующем экземпляре в любом регионе Azure.
RTO и RPO
При разработке плана непрерывности бизнес-процессов определите максимально допустимое время, необходимое для полного восстановления приложения после нарушения. Ниже приведены два распространенных способа оценки бизнес-требований к аварийному восстановлению:
- Цель времени восстановления (RTO) — время, необходимое для полного восстановления приложения после незапланированного нарушения.
- Цель точки восстановления (RPO) — объём потерь данных во времени, который может быть приемлем в результате незапланированного аварийного события.
В следующей таблице сравнивается RPO и RTO каждого варианта непрерывности бизнес-процессов:
| Вариант непрерывности бизнес-процессов | RTO (целевая продолжительность простоя) | RPO (потеря данных) |
|---|---|---|
| Высокая доступность (использование избыточности зон) | Обычно менее 30 секунд | 0 |
| Аварийное восстановление (использование групп резервирования с политикой переключения, управляемой клиентом) |
Обычно менее 60 секунд | Равно или больше 0 (зависит от изменений данных перед событием, вызывающим сбой, которые ещё не были реплицированы). |
| Аварийное восстановление (использование геовосстановления) |
12 часов | 1 ч |
Функции, обеспечивающие непрерывность бизнес-процессов
Например, существует четыре основных возможных сценария нарушения. В следующей таблице перечислены функции непрерывности бизнес-процессов Управляемого экземпляра SQL, которые можно использовать для смягчения потенциального сценария нарушения бизнес-процессов.
| Сценарий нарушения бизнес-процессов | Функция обеспечения непрерывности бизнес-процессов |
|---|---|
| Локальные сбои оборудования или программного обеспечения, влияющие на узел базы данных. | Для снижения риска отказов оборудования и программного обеспечения, Управляемый экземпляр SQL включает архитектуру доступности, которая гарантирует автоматическое восстановление от этих сбоев с уровнем обслуживания до 99,99 %. |
| Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой. | Чтобы защитить бизнес от потери данных, Управляемый экземпляр SQL автоматически создает полные резервные копии базы данных еженедельно, разностные резервные копии баз данных каждые 12 или 24 часа, а резервные копии журналов транзакций создаются каждые 5 – 10 минут. По умолчанию резервные копии хранятся в геоизбыточном хранилище в течение семи дней и поддерживают настраиваемый период хранения резервных копий для восстановления до определенного момента времени с максимальным сроком до 35 дней. Вы можете восстановить удаленную базу данных до точки, в которой она была удалена, если экземпляр не был удален, или если вы настроили долгосрочное хранение. |
| Редкий сбой центра обработки данных или зоны доступности, возможно, вызванный событием стихийных бедствий, изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования. | Чтобы уменьшить риск сбоя на уровне центра обработки данных или зоны доступности, включите избыточность зоны для Управляемого экземпляра SQL, чтобы использовать Azure Зоны доступности и обеспечить избыточность через несколько физических зон в пределах одного региона Azure. Включение избыточности зоны гарантирует устойчивость управляемого экземпляра к зональным сбоям с уровнем доступности до 99,99 %. |
| Редкий сбой в регионе, влияющий на все зоны доступности и все центры обработки данных, входящие в их состав, возможно вызван катастрофическим стихийным бедствием. | Чтобы устранить сбой на уровне региона, включите аварийное восстановление с помощью одного из вариантов: — Обеспечение непрерывной синхронизации данных с группами переключения на резерв для реплик в дополнительном регионе, предназначенных для переключения в случае отказа. Настройка избыточности хранилища резервных копий на геоизбыточное хранилище для использования геовосстановления. |
Восстановление базы данных в том же регионе Azure
Для восстановления базы данных до точки во времени в прошлом можно использовать автоматическое резервное копирование базы данных. Таким образом можно выполнить восстановление после повреждения данных, вызванного ошибками человека. Восстановление на определенный момент времени (PITR) позволяет создать новую базу данных в том же экземпляре или в другом экземпляре, которая будет отражать состояние данных до повреждающего события. Операция восстановления — это размер операции с данными, которая также зависит от текущей рабочей нагрузки целевого экземпляра. Восстановление очень большой или очень активной базы данных может занять больше времени. Дополнительные сведения см. в разделе Время восстановления.
Если максимальный поддерживаемый период хранения резервных копий для восстановления на определенный момент времени (PITR) недостаточно для приложения, его можно расширить, настроив политику долгосрочного хранения (LTR) для баз данных. Дополнительные сведения см. в статье Storing Azure SQL Database Backups for up to 10 years (Хранение резервных копий баз данных SQL Azure до 10 лет).
Восстановление базы данных до существующего экземпляра
В редких случаях возможен сбой центра обработки данных Azure. Такой сбой вызывает нарушение работы компании, которое может длиться от считанных минут до нескольких часов.
- Одним из вариантов является подождать, пока ваш экземпляр снова заработает после окончания сбоя в центре обработки данных. Это работает для приложений, которые могут позволить себе автономный доступ к базе данных. Например, вам не нужно непрерывно работать с проектом по разработке или бесплатной пробной версией. Если в центре обработки данных возникает сбой, вы не знаете, сколько времени может длиться сбой, поэтому этот параметр работает только в том случае, если база данных не нужна в течение некоторого времени.
- Если вы используете геоизбыточное хранилище (GRS) или геозонально избыточное хранилище (GZRS), то другой вариант — восстановить базу данных в любом управляемом экземпляре SQL в любом регионе Azure с помощью геоизбыточных резервных копий баз данных (геовосстановление). Геовосстановление использует геоизбыточное резервное копирование в качестве источника и может использоваться для восстановления базы данных до последней доступной точки во времени, даже если база данных или центр обработки данных недоступна из-за сбоя. Доступную резервную копию можно найти в парном регионе.
- Наконец, вы можете быстро восстановиться после сбоя, если настроили георезервную реплику с помощью группы переключения для вашего экземпляра, используя пользовательское переключение (рекомендуется) или управляемое Майкрософт переключение. Хотя переключение занимает всего несколько секунд, служба требует по крайней мере 1 час для активации управляемого Майкрософт геоотказа, если настроено. Это необходимо, чтобы гарантировать, что переключение на резервный режим оправдано масштабом сбоя. Кроме того, отказоустойчивость может привести к потере недавно измененных данных из-за специфики асинхронной репликации между парными регионами.
При разработке плана обеспечения непрерывности бизнес-процессов нужно понимать, какое максимальное время до полного восстановления приложения после аварийного события допустимо. Время, необходимое для полного восстановления приложения, называется целевой задачей времени восстановления (RTO). Необходимо также понимать, потерю какого максимального периода последних обновлений данных (т. е. за какой интервал времени) может допустить приложение при восстановлении после незапланированного аварийного события. Потенциальная потеря данных называется целевой точкой восстановления (RPO).
Различные методы восстановления предлагают разные уровни RPO и RTO. Можно выбрать конкретный метод восстановления или использовать сочетание методов для полного восстановления приложения.
Используйте группы аварийного переключения, если ваше приложение соответствует одному из следующих критериев:
- оно является критически важным;
- Имеет соглашение об уровне обслуживания (SLA), которое не допускает простоя в течение 12 часов и более.
- Время простоя может привести к финансовым убыткам.
- Имеет высокий уровень изменения данных и 1 час потери данных не допускается.
- дополнительные затраты на активную георепликацию ниже, чем потенциальная финансовая ответственность и связанная с ней утрата деловых возможностей.
Вы можете использовать сочетание резервных копий баз данных и группы переключения на резервный ресурс в зависимости от требований приложения.
В следующих разделах представлен обзор шагов для восстановления с помощью резервных копий базы данных или групп переключения на резерв.
Подготовка к сбою
Независимо от выбранной функции обеспечения непрерывности бизнес-процессов необходимо выполнить следующее.
- Определите и подготовьте целевой экземпляр, включая правила брандмауэра сетевого IP, учетные записи и
masterразрешения на уровне базы данных. - Определить, как перенаправить клиентов и клиентские приложения на новый экземпляр
- Задокументируйте прочие зависимости, такие как параметры аудита и оповещения.
Если вы не готовитесь должным образом, введение ваших приложений в онлайн после отказоустойчивого переключения или восстановления работы базы данных занимает дополнительное время и, вероятно, также требует устранения неполадок в условиях стресса, что является нежелательным сочетанием.
Переключение на вторичную БД, обеспеченную георепликацией
Если вы используете группы аварийного переключения в качестве механизма восстановления, вы можете настроить политику автоматического аварийного переключения. После активации механизм переключения приводит к тому, что вторичный экземпляр становится новым основным, готовым записывать новые транзакции и отвечать на запросы с минимальной потерей еще не реплицированных данных.
Примечание.
Когда ЦОД становится снова доступным, старый основной автоматически подключается к новому основному экземпляру, чтобы стать вторичным экземпляром. Если вам необходимо переместить основной системный экземпляр обратно в исходный регион, вы можете вручную инициировать плановое переключение обратно (откат).
Выполните геовосстановление
Если вы используете автоматические резервные копии с геоизбыточным хранилищем (по умолчанию это параметр хранилища при создании экземпляра), вы можете восстановить базу данных, используя гео-восстановление. Обычно восстановление выполняется в пределах 12 часов с потерей данных за период до одного часа, что зависит от времени создания и репликации последней резервной копии журналов. До завершения восстановления база данных не может записывать какие-либо транзакции или отвечать на запросы. Обратите внимание, что функция геовосстановления восстанавливает базу данных до последней доступной точки во времени.
Примечание.
Если работа центра обработки данных возобновится до переключения приложения на восстановленную базу данных, то можно будет отменить восстановление.
Выполнение задач после переключения на резервный сервер и восстановления.
После восстановления с помощью любого из механизмов восстановления необходимо выполнить следующие дополнительные задачи, прежде чем пользователи и приложения смогут снова начать работу.
- Перенаправьте клиенты и клиентские приложения на новый экземпляр и восстановленную базу данных.
- Убедитесь, что установлены соответствующие правила брандмауэра для IP-адресов сети, чтобы пользователи могли подключаться.
- Убедитесь, что соответствующие разрешения на вход и на уровне базы данных установлены (или используйте содержащихся пользователей).
- Настройте аудит соответствующим образом.
- Настройте оповещения соответствующим образом.
Примечание.
Если вы используете группу резервирования и подключаетесь к экземпляру с помощью прослушивателя режима чтения и записи, перенаправление после отказа произойдет автоматически и будет незаметно для приложения.
Реплики безлицензионного резервного копирования
Вы можете сэкономить на затратах на лицензирование, настроив дополнительный Управляемый экземпляр Azure SQL только для аварийного восстановления. Это преимущество доступно, если вы используете группу переключения при отказе между двумя управляемыми экземплярами SQL или настроили гибридное соединение между SQL Server и управляемым экземпляром Azure SQL. До тех пор, пока дополнительный экземпляр не имеет рабочих нагрузок на чтение или запись и используется только как пассивный резерв аварийного восстановления, плата за лицензии на виртуальные ядра, используемые вторичным экземпляром, не взимается.
Если вы назначаете дополнительный экземпляр только для аварийного восстановления, и на экземпляре не выполняются рабочие нагрузки чтения или записи, корпорация Майкрософт предоставляет вам количество виртуальных ядер, лицензированных для основного экземпляра без дополнительной платы в рамках преимущества прав на переключение при отказе. Вы по-прежнему оплачиваете вычислительные ресурсы и хранилище, которые использует вторичный экземпляр. Точные условия преимущества прав гибридной отработки отказа см. в разделе "Условия лицензирования SQL Server — права на отработку отказа".
Имя преимущества зависит от вашего сценария:
- Права гибридного резервирования на пассивную реплику: При настройке связи между SQL Server и Управляемым экземпляром SQL Azure вы можете воспользоваться правами гибридного резервирования, чтобы сэкономить на лицензировании виртуальных ядер для пассивной вторичной реплики.
- Права на отказоустойчивость для резервной реплики: При настройке группы отказоустойчивости между двумя управляемыми экземплярами можно использовать преимущества прав на отказоустойчивость для экономии затрат на лицензии виртуальных ядер для резервной вторичной реплики.
На следующей схеме показано преимущество для каждого сценария:
