P2V для linux с минимальным простоем

Mr. Aloof прислал статейку.

Вот и у меня выдалось свободное время для небольшой статейки. Хочу по просьбе Mister Nobody поделиться логами по решению одной извратной задачи…

В очередной раз возникла задача миграции сервера с железа в виртуальную среду. Нетривиальность задачи в том, что:

  1. Нет свободного железа. Мигрировать нужно на тот же сервер. =)
  2. Сервер очень важный, с базой данных 24/7. Допустимый простой, который получилось согласовать — 30 минут. При этом по 10 минут занимает остановка и запуск всех зависимых служб. Собственно на работу остается 10 минут максимум…
  3. Объем данных на дисках – чуть больше 220Gb на двух SCSI дисках по 147G.
  4. В базу постоянно пишется информация, терять которую нельзя. Так что клонирование диска не подходит – данные с начала запуска клонирования будут потеряны…

Хорошая новость в том, что на сервере операционная система CentOS 5, а значит между дисками и файловой системой есть замечательная штука – LVM.

Мигрировать будем конечно же на бесплатный ESXi… VMware Converter нам не подходит.

Задача непростая, но выполнимая =) После раздумий и репетиций, я сделал так:

Готовим заранее сам ESXi.

Тут есть варианты – ведь ESXi может и с флешки работать, и с PXE загрузиться. Можно конечно установить вместе со всеми работами, но зачем нам тратить 3 минуты?

Поскольку у меня был доступ к серверу с таким же SCSI-контроллером, я установил ESXi на 2 диска в RAID1 и предварительно настроил его. Контроллер, кстати, древний LSI, который может работать только с одним логическим томом. Но так как на целевом сервере никакого рейда не было (может когда-то не разобрались как его настроить?), то проблем с этим не должно быть. Подготовил VM для сервера. Если у вас хосты с разными процессорами, то обязательно настройте CPUID mask, чтобы потом не пришлось останавливать сервер для vmotion ;-). Также, очень рекомендую сразу установить vpxa (агент для vCenter) – вдруг потом памяти не хватит. Включаем доступ по SSH.

Мигрируем на ESXi

Вот и настало время «Ч». 3 часа ночи. Прочитав молитву, даем команду на остановку работы. Уложились в 6 минут – отлично! Останавливаем сервер. Вставляем подготовленные диски, стартуем сервер, убеждаемся что наш RAID1 нормально увиделся, выставляем в BIOS загрузку с него, попутно проверяем все настройки в BIOS. ESXi стартанул нормально. Проверяем, все ли правильно работает. Смотрим на часы – 3:10.

Теперь главная фишка – мы воспользуемся недокументированной возможностью сделать RDM для локальных дисков 😉

Идем на вкладку «Configuration» в раздел «Storage Adapters». Ищем по «Runtime Name» диски, на которых стоит сервер, и смотрим на их «Identifier».

hba_identifier

Подключаемся к хосту по SSH и с помощью утилиты vmkfstools создаем RDM диски:

vmkfstools -r /vmfs/devices/disks/t10.HITACHI_HUS103014FL3800_V5VHYDWA /vmfs/volumes/datastore1/disk1.vmdk

vmkfstools -r /vmfs/devices/disks/t10.HITACHI_HUS103014FL3800_V5VRRJ1A /vmfs/volumes/datastore1/disk2.vmdk

Теперь осталось только подключить в нужном порядке эти диски в созданную VM и запустить ее.

После старта сервера, спешно жмем «Install/Upgrade VMware Tools», логинимся как «root» и устанавливаем tools:

mount /dev/cdrom /media/

cp /media/VMwareTools-4.0.0-171294.tar.gz .

tar –zxvf VMwareTools-4.0.0-171294.tar.gz

./vmware-tools-distrib/vmware-install.pl

vmware-comfig-tools.pl

Ну все, tools установлены и настроены, да и сервер чувствует себя нормально. На часах 3:18. Отправляем сервер в последний ребут.

В 3:21 даем команду на старт служб и начало работы с системой… В 3:30 основные АРМ работают, остальные подключаются. Можно с гордостью сказать что уложились =)

Самую ответственную работу сделали, можно ехать спать. Но до финиша еще далеко.

Мигрируем диски

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

Подключаем наш хост к хранилищу данных (или добавляем локальные диски). Создаем vmdk диски нужного размера (у меня 2 по 150G) и подключаем первый диск к нашей VM на горячую на свободный канал (у меня «SCSI (0:2)»). Для того чтобы он увиделся в системе, нужно сделать следующее:

echo “- — -“>/sys/class/scsi_host/host0/scan #просканировать scsi диски

echo “scsi add-single-device 0 0 2 0”>/proc/scsi/scsi #добавляем в систему новый диск

Он у нас добавляется как /dev/sdc. С помощью fdisk /dev/sdc создадим на нем раздел.

Теперь нам нужно его добавить в наш VolumGroup:

lvm

>pvcreate /dev/sdc1 #форматируем раздел для LVM

>vgextend VolGroup00 /dev/sdc1 #добавляем раздел в VolumGroup.

>pvchange –xn /dev/sda2 #запрещаем раздавать место на /dev/sda2

>pvmove –i 10 /dev/sda2 #убираем все что у нас на /dev/sdb и

показываем проценты каждые 10 секунд

После окончания этой операции (на следующий день) смотрим на ситуацию с дисками:­­

pvdisplay /dev/sda2 # смотрим информацию о PV

Нужно убедиться что «Allocated PE» равно 0, а «Free PE»= «Total PE».

Теперь можно удалить этот диск из LVM:

vgreduce VolGroup00 /dev/sda2

На первом разделе этого диска лежит загрузчик и его настройки – не забываем про него =)

cp –r /boot/ ./boot

umount /boot

Можем убирать диск:

echo “scsi remove-single-device 0 0 0 0”>/proc/scsi/scsi

Теперь его можно удалить и «физически» из виртуалки. Не забывайте, что с этого момента сервер не сможет запуститься – мы у него снесли загрузчик. На место первого диска подключаем следующий vmdk:

echo “- — -“>/sys/class/scsi_host/host0/scan #просканировать scsi диски

echo “scsi add-single-device 0 0 0 0”>/proc/scsi/scsi #добавляем в систему новый диск

Он у нас добавляется как /dev/sda. С помощью fdisk /dev/sda создадим на нем раздел для загрузчика (100M) и второй для LVM. Возвращаем загрузчик на место:

mkfs.ext3 /dev/sda1 #форматируем в ext3

mount /boot #монитруем раздел. Он у нас, естественно, прописан в fstab

cp –r ./boot/ /boot/ #копируем содержимое обратно

/sbin/grub-install /dev/sda #создаем MBR на диске

Что ж,  сервер снова в рабочем состоянии.

Далее, вновь проделываем миграцию экстентов LVM:

lvm

>pvcreate /dev/sda2 #форматируем раздел для LVM

>vgextend VolGroup00 /dev/sda2 #добавляем раздел в VolumGroup.

>pvchange –xn /dev/sdb1 #запрещаем раздавать место

>pvmove –i 10 /dev/sdb1

pvdisplay /dev/sdb1

Убедились что раздел свободен, теперь можно удалить этот диск:

vgreduce VolGroup00 /dev/sdb1

echo “scsi remove-single-device 0 0 1 0”>/proc/scsi/scsi

Удаляем диск из виртуальной машины. Вот и все – сервер мигрировал за 3 дня (не считая выходных) и с простоем службы 30 минут! Это конечно была афера, но кто не рискует – то не пьет и не ест.

PS: Из решения этой задачи, кстати, отлично просматривается направленность Linux и ESX на сервисы с высокой доступностью. И где после этого Hyper-V и Windows? 😉

И еще прошу не допытывать меня зачем это все надо – причины были.

Запись опубликована в рубрике VMware с метками . Добавьте в закладки постоянную ссылку.

14 комментариев: P2V для linux с минимальным простоем

  1. A.Vakhitov говорит:

    Aloof, снимаю шляпу. Ты просто мегакрут!

  2. philzy говорит:

    Браво!!! Высший пилотаж.
    В 30 мин. мигрироваться. Это круто, реально!
    Без vCenter, без возможности на ошибку.
    По-моему, это достойный ответ «гипервидвастым».

    У меня 2-3 часа с конвертером, зачисткой и т.д.

    Mr. Nobody рассказывал мне про примерно похожий трюк только с vmotion, когда также монитруются RDM и делается storage vimotion, RDM скорее всего делается virtual. Я хотел так попробовать но не на чем, пока.

  3. Mr.Aloof говорит:

    Ну 30 минут — это вместе с остановкой и запуском отдела и филиалов. Простой самого сервера 15 минут получился.
    К сожалению Storage vMotion с такими RDM дисками не умеет работать, поэтому миграция дисков налету только средствами самой ОС. Возможность ошибки была — в любой момент можно было откатиться. Тоесть убрать ESX и вернуть все назад (загрузиться со старых дисков)

  4. Mister Nobody говорит:

    >Mr. Nobody рассказывал мне про примерно похожий трюк
    Это я просто неправильно Mr.Aloof понял, думал он снаружи сторадж мигрирует, а оказалось внутри средствами LVM.

  5. phily говорит:

    А что сценарий с vimotion не пройдет?

  6. Dmiter говорит:

    Как то плохо соответствуют друг другу пункты 1) и 2). Если свободного железа нет, а сервер такой важный 24/7. То получается что при выходе его из строя, например, простой будет явно больше 30-и минут. Либо у конторы сильно урезан бюджет IT, либо администратор не предусмотрел возможные проблемы, либо заявка доступности сервера 24/7 — это сильно завышенные требования руководства.

  7. Mister Nobody говорит:

    2Dmiter
    Это минздрав, точнее служба 03 (скорая помощь). В минздраве серьёзные проблемы с ИТ бюджетом. Зато максимальные требования по доступности.

  8. Mister Nobody говорит:

    Слова Голиковой и Путина о пермской медицине приводить не буду.

  9. Mr.Aloof говорит:

    Выход из строя — редкий случай. По статистике за пол года показатель доступности этого сервера (включая плановые) — 99,3. Естественно, при серьезном выходе из строя простой будет больше 30 минут. Но это не является поводом для увеличении времени запланированного простоя =)
    Как раз лучшее обеспечение 24/7 и была одной из причин виртуализации. Надеемся в следующем году довести этот показатель до 99,999 =)

  10. Дмитрий говорит:

    можно было второй сервер (если конечно на нем было 300Гб) опубликовать в качестве iscsi хоста, и мигрировать данные на него и потом обратно на VM. Времени бы это заняло дольше, но
    1) время простоя было бы меньше
    2) работы в основном можно было бы провести в рабочее время, а не ночью.

  11. Mr.Aloof говорит:

    Ответ Дмитрию:
    К сожалению как-то пропустил этот коммент и отвечаю с большим опозданием…

    1. Даже если мы выделим еще один комп под iSCSI хранилище как нам это поможет?
    Ну мигрировали бы мы данные на него (при этом база стала бы лагать и все были бы оч.недовольны) — что дальше делаем? Получили физический сервер с данными на iSCSI. Чем это сокращает время простоя?
    2. Почему вы так решили? Вы как-то сможете после шага 1 превратить сервер в виртуальный без его выключения???

    Очень советую Вам хорошо думать прежде чем писать что-то…

  12. Miko говорит:

    Из текста не понятно одно. В самом начале на сервере было 3 диска? Один с системой и два с данными? Или что? Иначе я не понимаю зачем все эти игры с lmv, если vmdk диски были подготовлены в самом сразу после загрузки в esxi

  13. Mr.Aloof говорит:

    Даже не знаю как вам ответить. Вы не разобрались в сути описанного процесса.
    Напишите своё видение переноса системы из физической среды в виртуальную.

  14. Mr.Aloof говорит:

    Сколько дисков не имеет значения. Игры с lvm нужны для переноса данных с первоначальных дисков (физических) на виртуальные диски (vmdk)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *