Использование Microsoft Azure в качестве резервного ЦОД-а
Высокую доступность виртуальных машин (ВМ) Hyper-V можно обеспечить разными способами. Один из таких способов, Hyper-V Replica, позволяет реплицировать критические для бизнеса компании ВМ в другое физическое расположение, например, в резервный ЦОД. В этом случае мы реализуем катастрофоустойчивое решение, и даже потеря всего ЦОД-а не приведет к потере ВМ. Но много ли компаний могут позволить себе иметь резервный ЦОД? А если его нет, но устойчивость к сбоям на уровне площадки все же необходима? Сервис Azure Site Recovery недавно был обновлен таким образом, что теперь вы можете настроить реплику ваших ВМ прямо в облако Microsoft, используя Microsoft Azure в качестве «резервного ЦОД-а». Здесьможно посмотреть, как это выглядит. Мы дальше рассмотрим возможные сценарии и реализацию одного из них.
Hyper-V Replica и катастрофоустойчивость?
Hyper-V Replica, впервые появившаяся в Windows Server 2012, представляет собой механизм асинхронной репликации ВМ. В минимальной конфигурации для работы Hyper-V Replica необходимы два хоста с поднятой ролью Hyper-V, связанные каким-либо каналом передачи данных. После настройкирепликации для выбранной ВМ на целевом хосте создается копия этой ВМ (в выключенном состоянии), и далее с исходного хоста с определенным интервалом передаются изменения, происходящие в оригинальной ВМ. В Windows Server 2012 интервал репликации составляет 5 мин., в Windows Server 2012 R2 – может быть выбран из трех допустимых значений: 30 сек., 5 мин., 15 мин.
В случае недоступности оригинальной ВМ вследствие падения хоста или любых других проблем, администратор инициирует переключение на реплику. На целевом хосте при этом запускается реплицированная ВМ, после чего остается переключить клиентов на эту ВМ, у которой может быть другой IP, другие настройки VLAN и пр. При подобном незапланированном сбое (unplanned failover) в силу асинхронной репликации возможны потери данных (с момента последней репликации до момента сбоя). Мы также можем использовать запланированное переключение на реплику (planned failover), например, для выполнения каких-либо задач сервисного обслуживания на исходном сервере или в основном сайте. В этом случае Hyper-V Replica гарантирует передачу всех изменений с момента последней репликации, прежде чем остановит оригинальную ВМ и запустит реплицированную.
Построение катастрофоустойчивых решений – одно из главных применений Hyper-V Replica. Действительно, никаких специальных требований к оборудованию хостов нет, все делается средствами Windows Server. Специальных требований к каналу связи тоже нет. Его толщина определяется количеством и объемом реплицируемых ВМ и частотой репликации. Оценку различных параметров для конкретной конфигурации можно сделать с помощью Capacity Planner for Hyper-V Replica. Но есть несколько принципиальных моментов, которые надо иметь в виду:
- Hyper-V обеспечивает переключение с оригинальной ВМ на реплику и, если необходимо, в обратную сторону. Но не содержит никаких инструментов для переключения клиентов (нагрузки) на ВМ.
- Hyper-V выполняет мониторинг участников репликации. Но в отличие от Failover Clustering он не содержит какой-то встроенной логики автоматической отработки сбоя, например, если связь с основной площадкой потеряна. Решение о переключении должен принимать администратор.
- Даже если мы подготовили скрипты для автоматического переключения, (командлеты PowerShell для управления Hyper-V Replica, конечно, имеются), эти скрипты необходимо где-то хранить и в час «Х» откуда-то запускать. По канонам надежности это «где-то» не должно быть ни основным сайтом, ни резервным. Нужна третья точка – наблюдатель или оркестратор.
Azure Site Recovery (ASR)
Набор облачных служб Azure Site Recovery (ранее Azure Hyper-V Recovery Manager) изначально как раз и задумывался как такой оркестратор процессов репликации и переключения в случае запланированных или незапланированных простоев.
Для обеспечения катастрофоустойчивости нам необходимо как минимум:
- Обеспечить связь Azure с основным и резервным сайтами, эти каналы связи и будут использоваться для мониторинга состояния защищаемых объектов
- Указать, какие ВМ необходимо защищать с помощью репликации, каковы параметры репликации
- Создать план восстановления (recovery plan), в котором отразить все необходимые шаги по переключению на резервный сайт, включая последовательность запуска ВМ в резервном ЦОД, возможные скрипты и последовательность их запуска и пр.
Архитектура такого решения выглядит следующим образом:
Обратите внимание, что каналы связи с Azure используются для настройки, мониторинга и управления при переключении между площадками. Трафик же репликации передается не через облако, а по тем каналам между ЦОД-ами, которые у вас используются.
Благодаря ASR, у нас есть третья точка наблюдения/оркестрации, высокую доступность которой обеспечивает Microsoft. Более того, вам не нужно сначала настраивать репликацию на хостах. После того как настроен канал связи Azure – ЦОД, прямо на портале управления Azure вы сможете увидеть информацию о ваших частных облаках, хостах и ВМ и отсюда же настроить репликацию. Канал Azure – ЦОД защищается с помощью сертификатов, поддерживается настройка подключения через proxy-серверы, причем применительно к вашей инфраструктуре эти подключения являются исходящими. Наконец, план восстановления позволяет описывать логику failover, включая запуск скриптов, которые могут выполнять самый широкий спектр задач – от открытия портов до изменения параметров виртуальной машины. Все составляющие плана восстановления, в том числе скрипты, также хранятся в Azure, чем обеспечивается их высокая доступность. Выражаясь образно, настроив Azure Site Recovery, мы получили «аварийную кнопку», нажать которую и тем самым запустить процесс восстановления можно из любой точки, где есть Интернет.
Описанная выше архитектура подразумевает наличие у организации минимум двух ЦОД-ов. Коль скоро речь идет об использовании Hyper-V Replica, предполагается, что средой виртуализации управляет System Center Virtual Machine Manager (VMM). Так вот в самой первой реализации Azure Site Recovery связь между Azure и ЦОД представляла собой связь между Azure и VMM, для чего на VMM устанавливался специальный провайдер. С помощью провайдера VMM сообщает Azure о конфигурации физической и виртуальной среды и получает от Azure запросы мониторинга и команды управления, например, с заданными администратором параметрами репликации, которые VMM применяет к необходимым хостам Hyper-V и ВМ.
Несколько площадок и обязательное использование VMM, очевидно, ограничивало сферу применения Azure Site Recovery. Недавние обновления этого сервиса позволяют теперь реализовать новые сценарии. Давайте посмотрим на них.
Сценарии использования Azure Site Recovery
На момент написания статьи доступны следующие варианты использования Azure Site Recovery для защиты ваших ВМ.
- On-premises Hyper-V site to Azure protection with Hyper-V replication. Репликация ВМ с одного или нескольких серверов Hyper-V в Azure. VMM не требуется.
- On-premises VMM site to on-premises VMM site protection with Hyper-V replication. Репликация ВМ между хостами или сайтами, управляемыми VMM. Это изначально реализованный вариант, который мы рассмотрели выше.
- On-premises VMM site to on-premises VMM site protection with SAN replication. Репликация ВМ между кластерами Hyper-V, управляемыми VMM. В отличие от предыдущих сценариев, здесь репликация выполняется не с помощью Hyper-V Replica, а с помощью механизмов, предоставляемых SAN. Этот сценарий предназначен, в первую очередь, для организаций, которые уже используют аппаратную репликацию СХД.
- On-premises VMM site to Azure protection. Репликация ВМ с одного или нескольких серверов Hyper-V, управляемых VMM, в Azure. Похож на первый сценарий, но применяется, если локально развернут VMM.
- On-premises VMware site to on-premises VMware site with InMage. Репликация между сайтами VMware с использованием компоненты InMage Scout.
Более детально эти варианты и соответствующие требования к локально инфраструктуре описаны здесь. Мы же далее посмотрим на простой пример реализации 4-го сценария – репликация ВМ, управляемой VMM, в облако Microsoft Azure.
Репликация ВМ между сайтом VMM и Microsoft Azure
Я не буду описывать процесс настройки репликации. Если инфраструктура VMM развернута, частные облака созданы, ВМ запущены, вы можете воспользоваться очень неплохим пошаговым руководством здесь. Отмечу лишь несколько важных моментов.
Во-первых, поддерживается только последняя версия VMM – System Center 2012 R2 Virtual Machine Manager, при этом на хостах, которыми он управляет, может использоваться как Windows Server 2012, так и Windows Server 2012 R2. Много полезной информации по миграции с более старых версий моно найти вот в этойподборке материалов.
Во-вторых, репликацию в Azure можно настроить только для ВМ первого поколения (Generation 1), причем не важно, используют они в качестве виртуальных жестких дисков файлы VHD или VHDX.
Настройка репликации начинается с создания на портале управления Azure так называемого recovery vault – хранилища, которое будет содержать все настройки Azure Site Recovery, включая планы восстановления, но не реплики ВМ. Последние, как и любые другие ВМ в Azure, создаются в учетных записях хранения (storage accounts). Для учетной записи хранения, которая будет использоваться под реплику, должна быть включена опция гео-репликации, и располагаться эта учетная запись должна в том же регионе (location), что и recovery vault.
После установки провайдера на VMM и агентов на хосты Hyper-V, на портале Azure вы увидите информацию обо всех созданных в VMM облаках. Защиту необходимо сначала включить для облака,
а затем для необходимых ВМ в этом облаке.
Иными словами, ВМ, которые вы хотите реплицировать в Azure, должныбыть ассоциированы с облаками VMM.
При настройке репликации конкретной ВМ мастер предложит шаблон ВМ в Azure (target size), наиболее подходящий для защищаемой машины. Хотя этот параметр вы можете изменить по своему усмотрению. В моем примере для двухъядерной машины с 4 ГБ ОЗУ был предложен шаблон D2. Замечу, защищаемая ВМ использует динамическую память, 4 ГБ – это максимальный объем в настройках динамической памяти. Именно на него ориентируется Azure при выборе шаблона.
В нижней части рисунка вы видите еще одну принципиальную настройку – network mapping. С помощью этого механизма вы фактически указываете, к какой виртуальной сети Azure подключит реплицированную ВМ, когда произойдет плановый или внеплановый failover. В параметрах этой виртуальной сети как минимум задается адресное пространство, в данном примере 10.2.1.0/24. Но кроме этого, можно настроить VPN-туннель между данной виртуальной сетью и вашей инфраструктурой. Тогда после failover ВМ в Azure сможет взаимодействовать через туннель с другими машинами вашей сети. Конечно за исключением ситуации, когда туннель связывал Azure с тем самым датацентром, который мы потеряли после сбоя.
Хотелось бы еще раз подчеркнуть, что после установки провайдера и агентов, все действия по настройке осуществляются на портале Azure. После того, как вы настроили репликацию, можно проверить, что на всех хостах Hyper-V защищаемого облака действительно включилась Hyper-V Replica (по умолчанию она выключена), и изменения регулярно реплицируются в Azure. Проверить это можно как на портале Azure по журналам в разделе JOBS, вот один из примеров:
Так и непосредственно в консоли Hyper-V на хосте, где запущена защищаемая ВМ:
Последний важный момент – это план восстановления. В моем самом простом демонстрационном сценарии это план выглядит вот так:
Есть всего одна группа ВМ – Group 1, которой принадлежит всего одна защищаемая ВМ – Web-App01. Если запустить это план на выполнение, то Azure попытается:
- Выключить все ВМ в группе (при незапланированном сбое этот шаг скорее всего выполнить не удастся, так как связь с ЦОД-ом наверняка потеряна)
- Выполнить failover, то есть указать, что реплика теперь становится основной машиной
- Запустить ВМ в группе.
В более сложном сценарии приложение, которое мы в конечном итоге защищаем с помощью репликации, может быть распределено по нескольким ВМ – front-end, back-end и т. д. Эти ВМ при failover требуется запускать в определенной последовательности, для чего их необходимо распределить по соответствующим группам в созданном плане восстановления. Может потребоваться выполнение дополнительных задач, например, открытие портов, по которым пользователи будут подключаться к ВМ. Для этого в нужное место плана восстановления можно добавить заготовленные скрипты.
Наконец, реальные ситуации могут быть сколь угодно сложные, и полностью автоматизировать процесс переключение на резервные ВМ не удастся. Какие-то шаги потребуют вмешательства ИТ-персонала. В план восстановления можно добавить такие «ручные» действия.
Тогда выполнение плана восстановления будет приостановлено на данном шаге до тех пор, пока администратор не выполнит необходимые действия и не нажмет кнопку, подтвердив завершение этого шага. После чего выполнение плана будет продолжено.
Предположим, план восстановления полностью готов, что дальше? Дальше крайне рекомендуется выполнить тестирование отработки сбоя. Большим плюсом Hyper-V Replica является то, что такое тестирование вы можете выполнить, не нарушая уже настроенный процесс репликации. Операция Test Failover фактически создает снимок реплицированной ВМ и на его основе создает и запускает копию реплицированной ВМ с именем Имя_ВМ- Test. Эту ВМ имеет смысл подключить к изолированному сегменту сети и проверить, как себя ведет приложение внутри, как к нему смогут подключиться тестовые клиенты и пр. При этом собственно репликация между оригинальной и реплицированной ВМ продолжается. Ровно такую же возможность предоставляет Azure Site Recovery при репликации ВМ в облако Microsoft. Мы можем создать в Azure некоторую тестовую виртуальную сеть, затем выбрать план восстановления, нажать внизу кнопку TEST FAILOVERи выбрать сеть, к которой будет подключена копия реплицированной ВМ.
Когда создание ВМ завершится, мы сможем выполнить все необходимые проверки и тесты. О завершении тестирования мы должны оповестить Azure, нажав The test failover is complete, после чего тестовая ВМ будет автоматически удалена.
Теперь, когда все готово, проверки выполнены, мы и получили ту самую «аварийную кнопку», которую можно использовать для планового или внепланового переключения.
И я всячески желаю, чтобы для последнего варианта нажимать на нее вам так и не потребовалось бы.
Дополнительная информация:
· Обеспечение катастрофоустойчивости и высокой доступности приложений и сервисов