Обзор Azure Site Recovery
Azure Site Recovery — это не просто средство, помогающее выполнить восстановление после сбоя системы. Azure Site Recovery реплицирует рабочие нагрузки между основным и вторичным сайтами. Site Recovery можно также использовать для переноса виртуальных машин из локальной инфраструктуры в Azure.
Ваша первая задача по защите рабочих нагрузок, например от землетрясений, заключается в рассмотрении текущего плана непрерывности бизнес-процессов и аварийного восстановления (BCDR) компании. Необходимо определить различные цели и область восстановления для систем, которым требуется защита.
В этом уроке вы узнаете, как Azure Site Recovery может помочь достичь этих целей, и сделать отработку отказа и восстановление ресурсов возможными в случае аварии.
Непрерывность бизнес-процессов и аварийное восстановление
Прекращение обслуживания может привести к сбою в работе сотрудников и пользователей. Каждую секунду, когда системы недоступны, компания может терять прибыль. Кроме того, могут накапливаться штрафы за нарушение соглашений, гарантирующих доступность предоставляемых вами услуг.
Планы BCDR — это официальные документы, которые компании создают для покрытия область и действий, которые должны приниматься при аварии или крупномасштабном сбое. Каждый сбой оценивается отдельно. Например, план BCDR вступает в действие, когда весь центр обработки данных отключается от источника электропитания.
В этом примере сценария из-за землетрясения оказались повреждены линии связи, и центр обработки данных стал бесполезен до тех пор, пока они не будут восстановлены. Аварии такого размера могут привести к простою служб в течение нескольких дней, а не часов, поэтому для восстановления службы необходимо использовать полноценный план BCDR.
В рамках плана BCDR укажите целевое время восстановления (RTO) и целевую точку восстановления (RPO) для ваших приложений. Вместе эти две цели помогают определить максимальное количество часов, которые бизнес может быть без указанных служб, и то, что должен быть процесс восстановления данных. Давайте рассмотрим каждый показатель подробнее.
Целевое время восстановления
RTO — это значение максимального времени, в течение которого ваш бизнес может продержаться после аварии до тех пор, пока не будет восстановлено нормальное обслуживание, чтобы избежать недопустимых последствий, связанных с прерыванием бизнес-процессов. Предположим, что RTO составляет 12 часов, то есть работа может продолжаться в течение 12 часов, если основные службы не функционируют. Если время простоя будет больше, вашему бизнесу будет нанесен серьезный ущерб.
Целевая точка восстановления
Целевая точка восстановления (RPO) — это мера максимального объема потерь данных, который приемлем после аварии. Как правило, предприятие выполняет резервное копирование каждые 24 часа, 12 часов или даже в режиме реального времени. В случае аварии часть данных все равно будет утеряна.
Например, если резервное копирование выполнялось каждые 24 часа, в полночь, а авария произошла в 9:00, будут потеряны данные за девять часов. Если целевая точка восстановления компании составляла 12 часов, ничего страшного, ведь прошло всего девять часов. Однако если целевая точка восстановления составляла четыре часа, это может стать проблемой и нанести ущерб.
Что такое Azure Site Recovery?
Служба Azure Site Recovery может расширить план BCDR, так как позволяет реплицировать рабочие нагрузки с первичного сайта на вторичный. При возникновении проблемы на первичном сайте можно автоматически вызвать Site Recovery, чтобы реплицировать защищенные виртуальные машины в другое расположение. Отработка отказа может происходить из локальной среды в Azure или из одного региона Azure в другой.
Важные возможности Azure Site Recovery:
- Централизованное управление: на портале Azure можно настроить репликацию и управлять ей, а также инициировать отработку отказа и восстановление размещения.
- Локальная виртуальная машина реплика tion. При необходимости локальные виртуальные машины можно реплика в Azure или в дополнительный локальный центр обработки данных.
- Виртуальная машина Azure реплика tion: виртуальные машины Azure можно реплика из одного региона в другой.
- Согласованность приложений во время отработки отказа. Использование точек восстановления и моментальных снимков, согласованных с приложениями, виртуальные машины всегда хранятся в согласованном состоянии во время реплика.
- Гибкая отработка отказа: отработка отказа может выполняться по запросу как тест или активируется во время фактической аварии. Тесты можно запускать для моделирования сценария аварийного восстановления без перерыва в работе активных служб.
- Интеграция сети: Site Recovery может управлять сетью во время сценария реплика и аварийного восстановления. Чтобы виртуальные машины работали в новом расположении, включаются зарезервированные IP-адреса и подсистемы балансировки нагрузки.
Настройка Azure Site Recovery
Для включения Azure Site Recovery необходимо настроить несколько компонентов.
- Сеть. Для использования реплика виртуальных машин требуется допустимая виртуальная сеть Azure.
- Хранилище служб восстановления: хранилище в подписке Azure сохраняет перенесенные виртуальные машины при выполнении отработки отказа. Кроме того, хранилище содержит политику репликации, а также исходное и целевое расположения для репликации и отработки отказа.
- Учетные данные. Учетные данные, используемые для Azure, должны иметь роли участника виртуальной машины и участника Site Recovery, чтобы разрешить разрешение на изменение виртуальной машины и хранилища, к которому подключен Site Recovery.
- Сервер конфигурации: локальный сервер VMware выполняет несколько ролей во время отработки отказа и процесса реплика tion. Он получается на портале Azure в качестве открытого устройства виртуальной машины (OVA) для простоты развертывания. Сервер конфигурации включает следующее:
- Сервер обработки: этот сервер выступает в качестве шлюза для трафика реплика tion. Он кэширует, сжимает и шифрует трафик перед его отправкой через глобальную сеть в Azure. Сервер обработки также устанавливает службу мобильности данных на все физические компьютеры и виртуальные машины, предназначенные для отработки отказа и репликации.
- Главный целевой сервер: этот компьютер обрабатывает процесс реплика tion во время восстановления размещения из Azure.
Важно!
Для восстановления размещения из Azure в локальную среду должен быть доступен VMware vCenter с сервером конфигурации, даже если вы реплицируете только физические компьютеры в Azure. Восстанавливать размещение на физические серверы нельзя.
Процесс репликации
После настройки необходимых задач можно начать репликацию компьютеров. Они реплицируются в соответствии с заданной политикой репликации. На начальных этапах первого копирования данные сервера реплицируются в службу хранилища Azure. После завершения начальной репликации производится вторая репликация. На этот раз в Azure реплицируются разностные изменения в виртуальной машине.
Тестирование и мониторинг отработки отказа
После настройки среды для аварийного восстановления протестируйте ее, чтобы убедиться в том, что она настроена правильно и все работает должным образом. Проверьте конфигурацию, выполнив отработку аварийного восстановления в изолированной виртуальной машине. Для тестирования рекомендуется использовать изолированную сеть, чтобы не нарушать работу активных служб.
Первая задача при попытке выполнить отработку восстановления — проверить свойства тестовой виртуальной машины в разделе Защищенные элементы на портале Azure. Последние точки восстановления отображаются в области Реплицированные элементы. В разделе Вычисления и сеть можно при необходимости изменить имя виртуальной машины, группу ресурсов, целевой размер, группу доступности и параметры диска.
Отработку восстановления можно начать из раздела Параметры>Реплицированные элементы на портале Azure. Выберите целевую виртуальную машину, а затем пункт меню Тестовая отработка отказа для последней обработанной точки восстановления. Выберите сеть Azure в том же меню. Чтобы запустить задание восстановления, нажмите кнопку ОК на экране выбора сети.
Доступ к состоянию задания восстановления и реплицированной виртуальной машины осуществляется через раздел Обзор хранилища Служб восстановления. Реплицированные элементы могут иметь следующие состояния:
- Работоспособно: репликация работает нормально.
- Предупреждение. Существует проблема, которая может повлиять на реплика tion.
- Критическое: обнаружена критическая ошибка реплика tion.
Если все идет хорошо, реплицированная виртуальная машина имеет состояние Выполнено. Если тест еще не выполнен, указывается состояние Рекомендуется тестирование. Кроме того, виртуальная машина имеет состояние Рекомендуется тестирование, если прошло более шести месяцев с момента последнего теста.