Миграция Hyper-V FailOver Cluster 2008 R2 SP1 на Hyper-V FailOver Cluster 2012 R2: как сделать и подводные камни процесса.

Добрый день, коллеги.
Наконец-то появилось время написать интересную статью,  содержание которой, выстраданно на собственном опыте. Не секрет, что некоторые из нас использовали в своих инфраструктурах отказоустойчивые кластера Hyper-V Windows Server 2008 R2, многие не успели произвести промежуточную миграцию на Windows Server 2012, а тут уже вышел Windows Server 2012 R2.
Как быть и что делать? Можно ли произвести прямую миграцию? 

Ответ - можно.

В Windows Server 2012  был представлен новый функционал, которые позволял выполнять подобные операции при некоторых условиях. В частности, вот неплохая статья "How to Move Highly Available (Clustered) VMs to Windows Server 2012 with the Cluster Migration Wizard", которая объясняет этот процесс. 

В Windows Server 2012 R2 был заменён на Copy Cluster Role с возможностью миграции ролей  Migrate Cluster Roles to Windows Server 2012 R2


Однако, процесс миграции содержит некоторые ключевые моменты, которые надо понимать, чтобы не проводить долгие вечера исправляя ошибки виртуальных машин.
При планировании миграции надо учесть следующее:

• Поддержку вашим аппаратным обеспечением Windows Server 2012 R2, проверить это можно в windowsservercatalog.com
• Подготовку аппаратного и программного обеспечения;
• Необходимо оценить ваше текущее решение с точки зрения сетевой архитектуры, особенно, если у вас применяется некое ПО, которое нарезает VLAN на ваших физических серверах (к примеру: HP Network Configuration Utility) - об этом аспекте поговорим позже;
• Чётко спланироват Check-List выполнения миграции и выполнить все необходимые предварительные требования;
• Используется ли у Вас System Center Virtual Machine Manager и другие продукты System Center - у  меня уже был развёрнут SCVMM 2012 R2, поэтому миграция не требовалось;

Итак, миграция происходила для инфраструктуры на  основе 2-х узлового кластера, основанного на платформе: HP Proliant DL360 G7 - 2 шт. и СХД NetApp FAS 2040, соединённого с кластером по iSCSI. На узлах была развёрнута ОС WS 2008 R2 SP1 с ролями Hyper-V и Failover Cluster.

Данная аппаратная платформа полностью поддерживает WS 2012 R2, посему проблем не ожидалось - с учётом того, что драйвера доступны на сайте производителя HP.COM. 


ВНИМАНИЕ! Описанный ниже способ предполагает полную остановку обслуживания пользователей и может быть полностью не применим в продуктивной среде. Для продуктивной среды рекомендуется построение отдельного полноценного кластера для обеспечения необходимой производительности после миграции и минимизации окна обслуживания.


Для начала я вывел один из узлов из кластера.  
Обновил на нём ОС до Windows Server 2012 R2, обновил все необходимые прошивки аппаратной части, драйверы.
Затем, я ввёл его в домен и установил необходимые роли Hyper-V и Failover Clustering, а так же MPIO.
Настроил отказоустойчивое iSCSI подключение к LUN на полке для всех задействованных интерфейсах.
Однако, всплыл неприятный момент: HP Network Configuration Utility не поддерживается для операционных систем выше WS 2008 R2 SP1 и даже не запускается.  Это была серьёзная проблема, т.к. кластер, ранее состоящий из 5 узлов, выполнял нагрузки для изолированных подсетей на уровне VLAN внутри облака и продуктивной среды. В том, числе и коммутатор CISCO, лежащий в основе сети, был сконфигурирован соответсвующим образом. Пришлось повозится и менять концепцию решения с точки зрения организации сети.
К счастью, я набрёл на эту статью Hyper-V 2012 : VLAN Trunking -  это  решило многие проблемы.


Очень важно - ознакомьтесь с поддерживаемыми ролями к миграции Migration Paths for Migrating to a Failover Cluster Running Windows Server 2012 R2


Перед выполнением миграции необходимо:

• выключить все виртуальные машины
• выключить все конфигурации виртуальных машин
• все CSV тома, виртуальные машины которые мигрируются должны быть переведены в off-line режим
• желательно обеспечить максимальное соотвествие сетевой конфигурации (виртуальных сетей и виртуальных свичей) исходного и целевого кластеров для обеспечения простоты миграции, и во избежание отказа запуска виртуальных машин
• Оба кластера должны быть доступны по сети, имена и IP адреса кластерных ресурсов должны разрешаться
• На целевом кластере должны быть подключены CSV тома, на которых находятся VM, планируемые к миграции

1. Приступим к миграции: переводим все диски в Off-line режим, предварительно погасив виртуальные машины, а так же конфигурации виртуальных машин

2. На целевом кластере 

3. Читаем написаное и нажимаем Далее

4.  Указываем исходный кластер, нажимаем OK и Далее

5. Выбираем том CSV

ВНИМАНИЕ! Мастер Copy Cluster Role копирует ВСЁ СОДЕРЖИМОЕ, указанного ему тома CSV. У вас не получится выбрать отдельные машины, как только вы выберите одну - автоматом выделятся все.

6. Изучаем отчёт на тему выявления проблем

7. Сопоставляем сети исходные с целевыми

8. Наши виртуальные машины переехали

ПРИМЕЧАНИЕ! В сценарии с сохранением прежнего хранилища, если вы хотите, чтобы название CSV тома осталось прежним не добавляйте явно его в оснастке Failover Clustering целевого кластера - оно добавится автоматически при выполнении операции копирования.

9. Переводим CSV тома в On-Line режим на целевом кластере

10. стартуем наши VMs, предварительно включив конфигурацию VM

ВНИМАНИЕ!

Важно понимать следующее:

• если вы после мигруации уже запустили виртуальные машины на целевом кластере - не перезапускайте узлы исходного кластера. Если у Вас там выставлен автозапуск виртуальных машины - они запустятся автоматически при загрузке Hyper-V узла: это может  привести к критическим последствиям для виртуальных машин или для виртуализованных служб ADDS, Exchange  и т. д. Узлы необходимо вывести из эксплуатации в VMM, затем выключить.
• Не удаляйте конфигурацию и виртуальные машины на исходном кластере - это может привести к повреждении машины на  CSV, а аккуратно удалите роль failover cluster и hyper-v на исходном сервере.
• После миграции виртуальная машина может отказываться запуститься из-за ошибки конфигурации. Внимательно проверьте, все ли необходимые сущности конфигурации в исходной и целевой средах соотвествуют друг другу, если что-то потерялось - доведите конфигурацию до рабочего состояния.
• В случае неудачной миграции и желании её повторить - потребуется подготовка к повторной миграции, для всех машин того LUN (CSV), который мы пытались смигрировать:
• перевод всех VM и их конфигураций в целевой среде в состояние выключено;
• перевод всех кластерных дисков целевого кластера в офф-лайн режим и удаление их из оснастки кластера;
• удаление всех ранее смигрированных машин в оснастке целевого кластера - т.к. CSV том уже недоступен на целевом кластере - машины на CSV  не пострадают в процессе удаления;

ВНИМАНИЕ! Если после первой попытки миграции вы УЖЕ ЗАПУСТИЛИ виртуальные машины на целевой среде, с критическими сервисами: служба каталогов, сервер почтовых ящиков Exchange или что-то в этом духе, и эти сервисы прошли процесс синхронизации с партнёрами по репликации, выше описанная операция ПРОТИВОПОКАЗАНА!!!!! Необходимо искать другой способ переноса.

• Если по какой то причине конфигурацию виртуальной машины не удалось запустить, можно воспользоваться Import VM Wizard для реставрации конфигурации путём выполнения импорта - вызывается данная ошибка потерей некоторых компонентов в конфигурации виртуальной машины.

 В целом всё :) Добро пожаловать на Windows Server 2012 R2!