, и т.д.

Для приложений без встроенных средств высокой доступности решением может стать виртуализация, обеспечивающая высокую доступность на уровне виртуальной машины. Этот подход позволяет автоматически перезапустить виртуальную машину на другом узле виртуализации в случае незапланированного переключения ресурсов. Также возможен перенос виртуальных машин между узлами без простоев в плановых ситуациях, например при техническом обслуживании. Эти решения обеспечивают переключение ресурсов на уровне узла (если один из узлов отказывает).

Однако в случае природных катаклизмов (например, недавнее полное отключение центра обработки данных) или аварий, вызванных деятельностью человека (таких как разрыв резервных каналов связи с Интернетом при проведении дорожных работ), центр обработки данных может оказаться отрезанным от остального мира. Компании должны составить планы работ даже на случай потери основного центра обработки данных.

Если у компании есть запасная площадка для центра обработки данных, то многие ранее упомянутые технологии уровня приложений могут охватывать несколько мест. Многие решения, такие как использование нескольких контроллеров домена, и приложения, рассчитанные на отказоустойчивый кластер, функционируют с учетом географической информации. Однако у традиционной отказоустойчивой кластеризации Windows, применяемой к удаленным площадкам, есть недостаток. Во многих приложениях, использующих кластеризацию, и во всех виртуальных кластерах общее хранилище должно быть доступно всем узлам кластера. В целом этот подход связан с более высокими затратами, так как требуются сети хранения данных (SAN) в обоих местах, хорошая связь между площадками и репликация хранилищ для синхронизации содержимого в обеих SAN.

Большинство решений репликации SAN-SAN синхронные: операция записи в основной SAN подтверждается для процесса записи, только если запись выполняется в реплике SAN. Таким образом обеспечивается непрерывная синхронизация хранилищ обеих SAN. Синхронная репликация дает самую надежную защиту, но обходится недешево.

Очень крупные компании располагают достаточными средствами для таких решений хранения данных и организации виртуальных кластеров на разных площадках для важнейших приложений и виртуальных сред, в которых размещаются критические службы. Но для многих других компаний и приложений не существовало способов аварийного восстановления. Положение изменилось с появлением компонента Hyper-V Replica в операционной системе Windows Server 2012.

Знакомство с Hyper-V Replica

Выпуск Windows Server 2012 стал колоссальным событием, и особенно важные изменения связаны с виртуализацией и «облачными» службами. Один из крупнейших новых компонентов — Hyper-V Replica, обеспечивающий асинхронную репликацию виртуальной машины на второй узел Hyper-V. Целевой сервер Hyper-V (то есть реплика) не обязательно должен быть частью кластера с основным узлом Hyper-V. В действительности реплика не может быть в одном кластере с основным узлом. Не требуется реплике и общего хранилища и даже выделенной сетевой инфраструктуры для репликации. Цель Hyper-V Replica — обеспечить восстановление после аварии для любой среды Hyper-V без сложных предварительных условий через асинхронную репликацию.

В некоторых SAN также предусмотрена асинхронная репликация данных с основного узла в реплику, но не в реальном времени. Действия записи выполняются на основном узле, подтверждаются для процесса записи, а затем реплицируются, когда возможно. Существует задержка между записью на основном узле и на реплике. В зависимости от задержки на сервере реплики может не оказаться определенного количества данных, которые будут потеряны в случае отказа основного узла. Возможный пропуск часто именуют целевой точкой восстановления recovery point objective (RPO). В сущности, он определяет максимальный размер потери данных, приемлемый при аварии. Например, значение RPO, равное 5 минутам, означает, что будут потеряны данные не более чем за 5 минут.

Асинхронная репликация на уровне SAN для многих компаний нежелательна, так как для основной площадки и реплики требуется один и тот же поставщик. Но Hyper-V Replica использует асинхронную репликацию очень эффективно. На верхнем уровне Hyper-V Replica функционирует следующим образом.

  1. Когда виртуальная машина подготовлена для репликации, создается новая виртуальная машина на узле реплики Hyper-V. Виртуальная машина-реплика имеет такую же конфигурацию, как основная виртуальная машина; она отключена.
  2. Хранилище основной виртуальной машины реплицируется в виртуальную машину-реплику на сервере реплики Hyper-V. На основном узле Hyper-V формируется журнал для сохранения записей на реплицированных виртуальных жестких дисках (VHD). Файл журнала хранится в том же месте, что и исходный VHD.
  3. После завершения начальной репликации хранилища файл журнала закрывается. Формируется новый файл журнала для отслеживания текущих изменений; закрытый файл журнала отсылается на узел реплики Hyper-V и объединяется с виртуальными жесткими дисками для реплики виртуальной машины. Реплика виртуальной машины остается отключенной.
  4. Через каждые пять минут файл журнала закрывается, создается новый, а закрытый файл объединяется с репликой.

Благодаря асинхронной репликации в Hyper-V Replica репликация становится возможной во многих компаниях и сценариях аварийного восстановления:

  • репликация между центрами обработки данных для приложений уровня 1 в компаниях без репликации на уровне SAN (малые и средние компании);
  • репликация между центрами обработки данных для приложений уровня 2 в компаниях с репликацией на уровне SAN, но не желающих использовать ее для приложений, отличных от уровня 1;
  • репликация филиал-главный офис для защиты приложений, размещенных в филиале;
  • репликация между поставщиками услуг хостинга;
  • репликация на поставщика услуг хостинга для аварийного восстановления в небольших компаниях, не имеющих второго центра обработки данных.

Существует и множество других возможных сценариев. Главное, что благодаря Hyper-V Replica репликация виртуальных машин доступна любой компании.

Использование Hyper-V Replica

Настроить Hyper-V Replica несложно. Самый простой способ понять принципы работы Hyper-V Replica — пройти по этапам настройки и включить репликацию для виртуальной машины.

Первый шаг — настроить сервер Hyper-V Replica для приема запросов на размещение реплики. В диспетчере Hyper-V выберите Hyper-V Settings (параметры Hyper-V) из списка действий сервера. В Hyper-V Settings выберите список Replication Configuration (параметры репликации), как показано на экране 1. Установите флажок Enable this computer as a Replica server («Использовать этот компьютер как сервер реплики»). Затем потребуется выполнить несколько настроек.

 

Настройка целевого сервера Hyper-V на прием реплик
Экран 1. Настройка целевого сервера Hyper-V на прием реплик

В первую очередь — задействовать Kerberos (использующий протокол HTTP) или проверку подлинности на основе сертификатов (протокол HTTP Secure — HTTPS). Kerberos настроить проще, но при этом требуется, чтобы как основной сервер Hyper-V, так и реплика использовали проверку подлинности Kerberos и потому входили в один лес Active Directory (AD) или доверенные домены. При использовании Kerberos данные, реплицируемые между основным сервером и репликой, не шифруются, а передаются как обычно через HTTP-порт 80. Но если требуется шифрование, то можно использовать реализацию IPsec для Windows.

Второй вариант — применить проверку подлинности на основе сертификатов. В этом случае основной сервер и реплика могут быть членами разных лесов AD или организаций, но при этом необходимо указать сертификат. Дополнительное преимущество HTTPS — шифрование всех пересылаемых данных. Если включить как Kerberos, так и проверку подлинности на основе сертификатов, то при создании нового отношения репликации администратор, настраивающий репликацию, может выбрать любой метод.

Единственный параметр — указать серверы, из которых реплика будет принимать запросы на репликацию, а также место хранения этих реплик. Один вариант — разрешить репликацию из любого сервера, прошедшего проверку подлинности. В этом случае выберите одно место для хранения всех реплик. Другой вариант — указать серверы, которые могут выполнять репликацию на сервер-реплику; каждому серверу можно назначить отдельное хранилище.

Назначая серверы, можно использовать один (!) универсальный символ в имени сервера. Таким образом можно охватить группу серверов; например, *.na.savilltech.net для всех серверов с полным именем FQDN, завершающимся на na.savilltech.net. С помощью тега Trust Group можно перемещать виртуальные машины между узлами Hyper-V с одинаковой группой доверия и продолжать репликацию. С помощью Shared Nothing Live Migration можно перемещать виртуальные машины между некластеризованными узлами Hyper-V без простоев. При использовании этого новшества в способах переноса необходимо, чтобы группы серверов имели одинаковый тег Trust Group, чтобы обеспечить безупречную репликацию после перемещения виртуальных машин между серверами в группе доверия.

Если используется отказоустойчивая кластеризация, то существует дополнительное требование. Отказоустойчивый кластер состоит из нескольких узлов Hyper-V. Поэтому если отказоустойчивый кластер является целью для Hyper-V Replica, важно, чтобы весь кластер — а не только один узел — был доступен для размещения реплицированной виртуальной машины. Поэтому хранилище реплики должно располагаться на общем ресурсе SMB или общем томе кластера (CSV). Поддержка Hyper-V Replica в отказоустойчивом кластере достигается добавлением роли брокера реплики Hyper-V Replica Broker к отказоустойчивому кластеру. Посреднику необходимы имя и IP-адрес; он служит клиентской точкой доступа для Hyper-V Replica, а имя будет использоваться при выборе кластера в качестве цели репликации. Включая репликацию в кластере, вы выполняете настройку репликации в инструменте Failover Cluster Manager после того, как добавлена роль Hyper-V Replica Broker. После завершения настройки репликации (такой же, как для отдельного узла Hyper-V), все узлы в кластере настраиваются автоматически, если только не выбрана проверка подлинности на основе сертификатов. В последнем случае каждому узлу требуется собственный настроенный сертификат.

Последний шаг — назначить необходимые исключения брандмауэра для используемого порта: 80 для HTTP и 443 для HTTPS. Исключения брандмауэра встроены в Windows Server, но не включены, даже после завершения настройки репликации. Необходимо запустить брандмауэр Windows с помощью административного средства Advanced Security, выбрать Inbound Rules («Правила для входящих подключений») и включить прослушиватель Hyper-V Replica HTTP Listener (TCP-In) и/или прослушиватель Hyper-V Replica HTTPS Listener (TCP-In), в зависимости от метода проверки подлинности.

Когда сервер реплики готов к репликации, важно также включить основной сервер Hyper-V как реплику. Это позволит выполнить обратную репликацию, если виртуальная машина активирована на сервере реплики и должна начать репликацию на прежний основной сервер (который в этом случае считается репликой).

Указывать сеть для передачи трафика репликации не требуется. Предполагается, что технология используется для передачи данных между центрами обработки данных. Между ними есть только один допустимый путь, поэтому Hyper-V Replica автоматически выбирает нужную сеть для трафика репликации. Подозреваю, что некоторым хотелось бы большей свободы в выборе сети для Hyper-V Replica; если для вас это важно, отправьте свой отклик в компанию Microsoft.

Репликация виртуальной машины

Следующий шаг после того, как узлы и кластеры Hyper-V настроены на работу с компонентом Hyper-V Replica, — подготовить виртуальные машины к репликации. Используйте Hyper-V Manager или Windows PowerShell (особенно при автоматизированной групповой настройке). Укажите виртуальную машину, для которой нужно включить репликацию, а затем выберите действие Enable Replication («Включить репликацию»). В результате запустится мастер настройки репликации, состоящий из нескольких шагов.

Указав целевой сервер Hyper-V, выберите тип проверки подлинности. Он определяется типом репликации, выполняемой сервером. Также укажите, нужно ли сжимать данные, передаваемые по сети; при сжатии сокращается время передачи по сети, но возрастает нагрузка на процессор как на основном сервере Hyper-V, так и на реплике. Если у виртуальной машины несколько виртуальных жестких дисков, то можно выбрать жесткие диски для репликации. Таким образом можно добиться, чтобы реплицировались только нужные жесткие диски (то есть содержащие более одного файла подкачки). Реплицируются только виртуальные жесткие диски; с помощью Hyper-V Replica нельзя реплицировать физические диски, к которым виртуальная машина обращается напрямую (еще одна из причин, по которым следует избегать непосредственного обращения к физическим дискам).

Следующий шаг — настройка журнала восстановления. По умолчанию существует единственная точка восстановления реплики: самое последнее состояние репликации. Однако можно подготовить расширенный журнал восстановления с дополнительными почасовыми точками восстановления, как показано на экране 2.

 

Настройка журнала восстановления для реплики виртуальной машины
Экран 2. Настройка журнала восстановления для реплики виртуальной машины

Дополнительные точки представляют собой моментальные снимки виртуальной машины, созданные на сервере реплики. Затем можно указать определенную точку восстановления, выбрав соответствующий моментальный снимок. Кроме того, можно создать добавочную копию Microsoft Volume Shadow Copy Service (VSS) для заданного количества часов. Это дает дополнительные гарантии целостности реплики в заданной точке времени. Самое новое содержимое хранилища хранится в обычных файлах журнала, передаваемых через каждые 5 минут. Однако диск исходной виртуальной машины мог находиться в противоречивом состоянии. Нельзя гарантировать, что VHD реплики будет в согласованном состоянии, когда начнется репликация. При включенном режиме добавочной копии VSS перед циклом репликации выполняется моментальный снимок VSS на исходном компьютере. В результате исходная виртуальная машина обеспечивает согласованность содержимого диска для приложений. Точно так же, как при резервном копировании, когда файл журнала закрывается и передается в реплику, это состояние сохраняется как точка восстановления согласованного состояния приложений на целевом сервере, как показано на экране 3.

 

Просмотр реплики
Экран 3. Просмотр реплики

Если виртуальная машина содержит приложения с модулями записи VSS, рекомендуется использовать этот режим для создания точки восстановления согласованного состояния приложений. Принимаемое по умолчанию значение обеспечивает баланс между целостностью и дополнительными усилиями для создания точки восстановления на исходной виртуальной машине.

После завершения настройки точки восстановления необходимо выбрать метод начальной репликации хранилища:

  • передать содержимое VHD через сеть;
  • передать содержимое VHD с использованием внешнего носителя; указать местонахождение для экспорта содержимого.
  • использовать существующую виртуальную машину на сервере реплики в качестве начальной копии. Этот вариант можно задействовать, если вы уже восстановили виртуальную машину на целевом сервере Hyper-V или ранее включили репликацию и получили реплику, а теперь хотите вновь активировать ее. Чтобы обеспечить согласование, будет выполнено очень полезное побитовое сравнение между основной копией и репликой.

Можно настроить немедленный или отложенный запуск начальной репликации в указанное время; например, в нерабочие часы, когда потребность в сетевых ресурсах снижается. В зависимости от выбора администратора, виртуальная машина создается на сервере реплики Hyper-V в отключенном состоянии, и начальная репликация стартует. Через каждые пять минут файл журнала Hyper-V Replica (.hrl) закрывается, пересылается в реплику и объединяется с VHD реплики. В течение всего этого времени реплика виртуальной машины отключена. Только содержимое диска, но не состояние памяти, процессора или устройств, копируется в реплику виртуальной машины. Если реплика активируется, она будет включена и загружена в состоянии, соответствующем аварии, как будто она запущена без предварительного чистого закрытия. Это одна из причин, по которым для целостности диска полезно периодически формировать точки восстановления и использовать моментальный снимок VSS.

Созданная реплика виртуальной машины существует отдельно от основной виртуальной машины. Любые изменения в настройках основной виртуальной машины не отражаются в реплике виртуальной машины. Это позволяет вносить изменения в любую виртуальную машину, а репликация содержимого VHD продолжится.

Использование Hyper-V Replica

Помните, что Hyper-V Replica — решения для восстановления после аварии. Компонент не предназначен для применения вместо отказоустойчивых кластеров или других технологий высокой доступности. Обычно в случае аварии приходится выполнять множество действий и процессов, чтобы активировать сайт восстановления. Hyper-V Replica — не автоматизированное решение. Оно не обнаруживает отсутствие виртуальной машины на основном узле и запускает виртуальную машину на сервере реплики, так как неверное определение сбоя сайта может создать проблемы. Компонент необходимо инициировать вручную, однако нет никаких причин, мешающих автоматизировать его с помощью PowerShell в рамках других процессов. Возможно, в дальнейшем компонент будет автоматизирован через какое-либо решение управления от Microsoft, например System Center Virtual Machine Manager, чтобы обеспечить переключение нескольких виртуальных машин в рамках более крупного процесса восстановления сайтов.

Существует три типа отработки отказа Hyper-V Replica — один для тестирования и два для практических целей.

* Тестовая отработка отказа. Запускается на реплике виртуальной машины. Затем реплика виртуальной машины может быть запущена на узле реплики Hyper-V. Для этого нужно подготовить временную виртуальную машину на основе выбранной точки восстановления, а затем в процессе тестирования убедиться, что репликация работает, как запланировано. В хоте тестирования отработки отказа основная виртуальная машина продолжает посылать обновления журнала реплике виртуальной машины. Эти обновления объединяются с виртуальными жесткими дисками реплики, что позволяет продолжать репликацию. По окончании тестирования временная виртуальная машина удаляется.

* Плановая отработка отказа. Запускается на основной виртуальной машине и является предпочтительным типом отработки отказа. При этом основная виртуальная машина отключается, и реплицируются любые изменения, чтобы не было потерь данных, а также выполняется переключение на реплику виртуальной машины. Ход репликации меняется на противоположный, чтобы изменения пересылались в обратном направлении, а затем запускается реплика виртуальной машины. Эта виртуальная машина становится основной, а прежняя основная виртуальная машина становится репликой.

* Внеплановая отработка отказа. Запускается на реплике виртуальной машины. Предполагается, что при внеплановой отработке отказа основная виртуальная машина недоступна из-за аварии. При переключении такого типа репликация ожидающих изменений невозможна, а обратную репликацию необходимо включить вручную с повторной синхронизацией, поскольку невозможно определить, в какой точке репликация остановилась. Запуская обратную репликацию, установите флажок Do not copy the initial replication («Не копировать начальную репликацию») на странице Initial Replication («Начальная репликация»). Можно задействовать первоначальную основную виртуальную машину, а поблочное сравнение выполняется для синхронизации между репликой виртуальной машины и первоначальной основной виртуальной машины. Только различия в содержимом пересылаются через сеть.

У отработки отказа с использованием сайта восстановления в другом местоположении есть недостаток: конфигурация TCP/IP виртуальной машины вряд ли пригодна для работы в другом местоположении, которое почти наверняка находится в другой подсети. Hyper-V Replica располагает дополнительной конфигурацией TCP/IP в виртуальной машине при включенной репликации. Эта конфигурация (под конфигурацией сетевого адаптера виртуальной машины) позволяет указать альтернативные параметры IPv4 или IPv6 для реплики виртуальной машины. Сетевая конфигурация вводится в виртуальную машину в процессе отработки отказа, как показано на экране 4.

 

Задание альтернативной конфигурации IPv4 для виртуальной машины
Экран 4. Задание альтернативной конфигурации IPv4 для виртуальной машины

Во время этого процесса Hyper-V обновляет виртуальную машину через службы интеграции Windows Server 2012 Hyper-V, выполняемые внутри виртуальной машины. Процесс работает только с синтетическим сетевым адаптером, но не со старыми сетевыми адаптерами, а для его работы внутри виртуальной машины Windows XP Service Pack 2 (SP2), Windows Server 2003 SP2 или более новыми версиями. Во время подготовки статьи данный процесс не работал с виртуальными машинами Linux, но специалисты занимаются этой проблемой, так что в скором времени она будет решена. Хороший метод — выполнить настройку параметров TCP/IP для отработки отказа на основной виртуальной машине с обычной IP-конфигурацией. Таким образом, если реплика активируется, направление репликации меняется на обратное, а виртуальной машины переключается на первоначальную основную виртуальную машину, то можно автоматически восстановить верный IP-адрес для основного местоположения.

Репликация для восстановления

Hyper-V Replica — мощный компонент. Он полезен даже для организаций без второго центра обработки данных; помните, что проверка подлинности на основе сертификатов возможна с репликацией через HTTPS. Если имеется поставщик услуг размещения, совместимый с Windows Server 2012 Hyper-V (или, надеемся, с инфраструктурой как услуга Windows Azure — IaaS), можно выполнять репликацию из центра обработки данных в публичное «облако» для восстановления после аварии. Hyper-V Replica — отличный способ включить отработку отказа для отдельных виртуальных машин, но эта функциональность может использоваться и другими процессами и компонентами оркестрации для быстрой организации эффективного механизма восстановления после аварии, который будет полезен большинству компаний.