Миграция центров обработки данных (далее ЦОД) задача нетривиальная и трудоемкая, хотя при наличии выстроенных и протестированных процессов достаточно легко исполнимая. Летом прошлого года мне довелось работать над миграцией двух ЦОД, а так как я занимаюсь в основном SAN, то и речь пойдет о том, как мигрировать их.

В source ЦОД у заказчика были СХД от компаний IBM и NetApp, а в destination — EMC VNX. Задачей было быстро и с минимальным downtime мигрировать все хосты как физические, так и виртуальные на новое место. Миграция данных и хостов должна была выполняться c минимизацией времени простоя — заказчиком выступала очень крупная компания, и каждая минута была критична. Оптимальным решением было использование технологий от компании EMC – VPLEX и RecoverPoint.

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

Encapsulation

1. Хост выключается;
2. Зонинг на свичах меняется с XIVах на VPLEX;
3. На VPLEX создаются необходимые Storage group;
4. На destinaion side делается то же самое;
5. Создается пара в RecoverPoint;
6. Запускается асинхронная репликация;
7. Хост включается.

Migration

1. Хост выключается;
2. Репликация останавливается, включается direct access на destination side;
3. Хост физически перевозится в новый ЦОД;
4. Хост включается.

В случае если все сделано правильно, хост даже не должен заметить, что его перевезли в другое место, останется только средствами ОС подключить необходимые луны.

Как мы можем видеть — план не особо сложен, однако во время его выполнения пришлось столкнуться со множеством подводных камней, как, например, неконсистентные данные в destination ЦОД. В рамках данной статьи я постараюсь дать подробную инструкцию по самой миграции, а также рабочую процедуру, которая поможет избежать наших ошибок. Итак, поехали!

Хочу заметить, что данную процедуру я пишу на примерах XIV и VNX, но она применима к любым системам.

Encapsulation

Презентуем volumes из XIV на VPLX. Мы должны подключится к XIV, найти все volumes, которые использует наш мигрируемый хост, и замапить их на VPLEX. Думаю, с этим сложностей не возникнет. Само собой, у вас должен быть настроен зонинг, чтобы XIV видел VPLEX.

Определяем volumes на VPLEX. Лучше всего для этого пользоваться CLI.

cd /clusters/cluster-1/storage-elements/storage-arrays/<IBM-XIV-SerialNumber1>

cd /clusters/cluster-1/storage-elements/storage-arrays/<IBM-XIV-SerialNumber2>

cd /clusters/cluster-1/storage-elements/storage-volumes/

claim --storage-volumes VPD83T2:<WWN_Volume> --name <Name_Volume>

Создаем virtual volumes на VPLEX source.

Заходим в Provision Storage -> Storage array:



Затем на вкладке «Storage Volumes» проверяем, что все наши луны презентованы (находятся в статусее Claimed)



Переходим в «Extents» и нажимаем «Create», выбираем все LUN от нашего хоста и добавляем их.



Переходим в «Devices”. Нам нужно будет создать устройство, ассоциированное с нашими Extents. Нажимаем „Create“, после чего нам нужно указать тип устройства, в нашем случае нам нужно 1:1 Mapping:



Добавляем все Extents, созданные на предыдущем этапе, отключаемавтоматическое создание virtual volumes:



Теперь нам нужно создать virtual volumes, для чего заходим в соответствующий пункт меню и нажимаем Create from Devices, выбираем все устройства, которые мы создали на предыдущем этапе.



После добавления обратите внимание, что наши новые virtual volumes пока находятся в статусе Unexported:



Ну а теперь займемся зонингом, как вы понимаете, в настоящий момент все наши луны презентованы не хосту, а VPLEX, и нам нужно перенастроить зонинг так, чтобы хост видел данные луны., Сделать это мы должны на обеих фабриках. Итак:

SAN01

alishow | grep <ServerName>
zonecreate "<ServerName>_VPLEX","<AliasServerName>;VPLEX_1E1_A0_FC00"
cfgadd "CFG_20160128_07h05FR_SCH","<ServerName>_VPLEX_1E1_A0_FC00"  
zonecreate "<ServerName>_VPLEX_1E1_B0_FC00","<AliasServerName>;VPLEX_1E1_B0_FC00"
cfgadd "CFG_20160128_07h05FR_SCH ","<ServerName>_VPLEX_1E1_B0_FC00" 
cfgsave
cfgenable CFG_20160128_07h05FR_SCH
cfgactvshow | grep <ServerName>

То же самое делаем для второй фабрики SAN02.

Теперь мы должны создать на VPLEX новый хост и презентовать ему луны. Возвращаемся в админку VPLEX и заходим в Initiators. Если зонинг настроен правильно, мы должны увидеть два незарегистрированных инициатора:



Еще раз проверяем WWN и смело нажимаем Register. На следующем шаге мы задаем имя нашего нового инциатора (я обычно задаю *имя хоcта_номер HBA*), тип хоста в нашем случае это default.



Такой же шаг выполняем для второго инициатора. Все, наш хост сейчас видит VPLEX, осталось только презентовать ему LUNы.

Заходим в пункт Storage View и нажимаем Create, задаем имя Storage View (обычно это имя хоста), добавляем инициаторы:



На следующем шаге мы должны ассоциировать инициаторы со свободными портами на стороне VPLEX. Для начала необходимо удостовериться, что все порты выбраны: A0-FC00, A0-FC01, B0-FC00, и B0-FC01. Если их нет, проверяем еще раз правильность настройки зонинга и выполняем рескан FC на хосте.



На следующем шаге выбираем все volumes, которые мы создали для нашего сервера, затем указываем номера LUNов. С этим шагом будьте особенно внимательны: номера LUN должны совпадать с номерами, которые у нас были на XIV. Выбираем Manually enter LUN numbers и назначем номера соответвенно.



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

Настройку на source стороне мы почти завершили, теперь займемся destination. Начнем мы с того, что еще раз зайдем на XIV и перепишем точный размер наших лунов, размер рекомендую брать в блоках.

Заходим на VNX, далее Storage -> LUNs -> Create LUN.

Проверяем настройки LUNа, в нашем случае Storage Pool должен быть Pool Open, LUN должен быть Thin, копируем и вставляем размер и задаем имя. Каких-либо требований к имени нет, потому руководствуемся принятыми в организации правилами.



Я предполагаю, что VPLEX у ваш уже подключен, зонинг настроен и Storage Group на VNX созданы. Поэтому после создания LUNов просто добавляем их в соответствующую VPLEX Storage Group.

Следующим шагом мы должны будем презентовать LUNы от VNXа к VPLEX. Можно, конечно, это делать вручную, но я для этих целей пользуюсь небольшим скриптом от EMC. Скачиваем полезную утилитку от EMC — NavisphereCLI и создаем простой BAT файл:

REM remplacer FR1 par le nom du premier VNX.

REM remplacer FR2 par le nom du deuxieme VNX.

REM remplacer 0.0.0.0 IP VNX.

REM remplacer 0.0.0.0 IP VNX.

REM user/user: service/password

rem naviseccli -AddUserSecurity -user sysadmin -password sysadmin -scope 0

del c:\R1.txt

del c:\R2.txt

"C:\EMC\NavisphereCLI\NaviSECCLI.exe" -h 0.0.0.0 getlun -uid -name > c:\R1.txt

"C:\EMC\NavisphereCLI\NaviSECCLI.exe" -h 0.0.0.0 getlun -uid -name > c:\R2.txt


Само собой, в скрипте нам нужно поправить пути. Результатом работы скрипта будут два файла R1 и R2 (так как в нашем случае локации две).

Возвращаемся на VPLEX и мапим наши LUNы. Идем в Provision Storage -> Array Management, выбираем наш VNX и нажимаем Rediscover Array:



После этой процедуры опять же выбираем наш VNX и нажимаем Claim Storage. Далее выбираем пункт Use a Name Mapping File:



Как, наверное, уже понятно, далее нам нужно будет указать файл, который мы сгенерировали с помощью скрипта. Далее мы должны увидеть все LUNы, которые были созданы на VNX. Даем им новое имя (я рекомендую дать имя по аналогии с source), и после всех этих процедур мы видим, что луны презентованы:



Теперь нам нужно создать Extents, Devices, Virtual Volumes и Storage Group. Все это делается по аналогии с source side и трудности не представляет. По аналогии же создаются зонинг и инициаторы. После всех этих действий distination side уже готова принять наш хост, нам осталось только настроить репликацию.

Для работы RecoverPoint нужен volume под журналы, так называемый JVOL, создаем его на обоих сторонах и добавляем к Storage Group, которую мы создали на предыдущих этапах.

Итак, репликация. Открываем RecoverPoint и смело идем в Protection — > Protect Volumes:



Ищем Consistency group нашего source VPLEX, в поле RPA cluster выбираем source site и выделям все LUNы, которые будут реплицироваться:



На следующем этапе выбираем наш JVOL. Далее нам нужно уже будет указать имя пары (любое в соответствии с принятыми правилами), RPA cluster уже выбираем Destination и выбираем Detination volumes:



Далее нам нужно указать destination JVOL. Нам покажут простенькую картинку с нашей репликацией, после появления которой нажимаем Add a copy.



Нажмем по названию нашей CG группы и увидим красивый интерактивный статус синхронизации:



Дожидаемся когда данные среплицируются. После этого мы будем наблюдать следующий статус:



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

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

Возвращаемся в RecoverPoint, проходим по Protection -> Manage Protection, находим нашу CG группу и жмем кнопку Pause Transfer:



Затем запускаем тестирование кнопкой Test Copy, выбираем нашу destination сторону и нажимаем Next select an image



В следующем окне оставляем все по умолчанию, на Warning смело отвечаем YES. Ждем, когда копия протестируется, и нажимаем Enable Direct Access.



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