Как стать автором
Обновить

Мой опыт миграции с VMware Server на ESXi

Время на прочтение3 мин
Количество просмотров28K
Хочу поделиться опытом своей команды по миграции с древнего VMware Server 2.0 на ESXi 4.1. В ходе оптимизации расходов на обслуживание перед нами встала задача уйти с сильно подтормаживавшего VMware Server под виндой на бесплатный ESXi. Задача усложнялась территориальной распределённостью серверов (по всей России) и сжатыми сроками, в которые необходимо было это сделать.

Дано:
  1. Полтора десятка серверов в удалённых локациях. Возьмём за данность, что они имеют интерфейс удалённого управления (DRAC/ILO/IP KVM). Без этого миграция сильно усложняется большим количеством командировок.
  2. На серверах крутится по 3 виртуальных машины — контроллер домена, работающий также как DNS и DHCP-сервер (виртуальный диск 40 гигабайт), WSUS + хранилище дистрибутивов (150 гигабайт), и сервер, сканирующий сеть филиала на уязвимости (ещё 40 гигабайт).
  3. Промежуточных серверов, на которые можно было бы временно поставить ещё один ESXi и осуществить конвертацию на него «живых» машин у нас нет, но для хранения слитой информации у нас есть файлсервера, подключённые с нашими серверами в тот же свитч — в лучшем случае гигабитный, но чаще всего 100 мегабит.
  4. На все сервера у нас есть админские права через AD-группы (в большой компании это не всегда так, но в данном случае мы их получили). Паролей локального админа на эти сервера у нас нет.

Требуется:
Избавиться от связки Windows + VMware Server. Профит: высвобождаем лицензии на ОС, а также ускоряем работу виртуалок, ибо периодически хост-машина сжирала все процессорные ресурсы (причина — процесс tomcat всё того же реликтового гипервизора) — виртуалкам становилось очень неуютно.

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

Вопрос «как» после курения манов и чтения выдачи гугла был решён в пользу копирования всей директории виртуальной машины с гипервизор-сервера на файл-сервер с последующей её обратной заливкой на свежеустановленный ESXi при помощи VMware Converter. На пилотном сервере выяснилось, что скорость конвертации (а точнее, заливки конвертером vmdk-файла на хост-машину с ESXi) оставляет желать лучшего — всё-таки SCP. Но другие варианты (например, были идеи включить самбу на ESXi и залить образы напрямую в датастор) в итоге утыкались в неподдерживаемые VMware сценарии вроде правки vmdk и vmx-файлов, к которым прибегать не хотелось. Вариант с использованием VMware-vdiskmanager не понравился по причине того, что не хотелось пересоздавать конфигурацию виртуалки с нуля, да и не на всех дисках почему-то получилось безболезненно его прогнать.

Ответ на вопрос «сколько времени займёт» на пилотном сервере показал, что суммарное время занимает около трёх суток, включая время копирования виртуальных машин туда и обратно. Это много, нужно ускорять, а главное — не мешать работать бизнесу. Первая мысль — делать на выходных, а операции копирования производить ночью. Бизнес будет недоволен только при отсутствии DHCP/DNS, значит эта машина у нас приоритетнее, и ей надо уделить наибольшее внимание — даже на выходных есть желающие поработать.

Итак, что получилось в итоге, по шагам:

Подготовка
Проверяем удалённый доступ через DRAC/ILO, свободное место на файлсервере, на файлсервер же ставим VMware Standalone Converter и VSphere Client. На контроллер домена также устанавливаем Standalone Converter. Копируем на файлсервер ISO-дистрибутивы (в случае если у нас DRAC/ILO) или режем болванку. Очень желательно сделать бэкап System State контроллера домена. Записываем сетевые настройки всех виртуалок.

Пятница вечер
  1. Необходимо зайти под админским AD-логином на все виртуалки — это очень пригодится, если что-то случится с сетевыми настройками (а оно случится — сетевая карточка под ESXi увидится гостевой ОС как новое устройство), можно будет зайти с закешированным паролем.
  2. Гасим все машины, кроме контроллера домена. Ждём, пока VMware удалит временные рабочие файлы машин (минут 5), затем на ночь ставим копирование папок со второй и третьей виртуалками на файлсервер

Суббота
  1. Выключаем и копируем контроллер домена аналогично пятничным серверам.
  2. Устанавливаем ESXi и апдейты, конфигурируем сеть, датасторы итд.
  3. Запускаем Standalone Converter на файлсервере. Конвертируем контроллер домена. Это примерно 5 часов при 100-мегабитном линке. Восстанавливаем сетевые настройки контроллера.
  4. Теперь у нас есть гостевая винда, а с неё-то конвертер будет работать быстрее. Как показала практика, в несколько раз. С контроллера домена конвертируем наш WSUS, а на файлсервере в параллели — третий сервер. Закончится их конвертация примерно одновременно.

Теперь нам осталось только проверить в воскресенье, всё ли сконвертировалось, вернуть сетевые настройки и дотюнить настройки самого ESXi.

Итого, мы получили схему с крайне небольшим временем человеческого участия и распараллеливанием задач, что позволило одному человеку за выходные «окучить» 3 и более филиалов.

Если кто-то найдёт недочёты в том, что мы напридумали или знает, как ещё ускорить процесс — буду только рад, учиться всегда хорошо.
Теги:
Хабы:
+13
Комментарии28

Публикации

Изменить настройки темы

Истории

Работа

DevOps инженер
46 вакансий

Ближайшие события

Weekend Offer в AliExpress
Дата20 – 21 апреля
Время10:00 – 20:00
Место
Онлайн
Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн