Mr. Aloof прислал статейку.
Вот и у меня выдалось свободное время для небольшой статейки. Хочу по просьбе Mister Nobody поделиться логами по решению одной извратной задачи…
В очередной раз возникла задача миграции сервера с железа в виртуальную среду. Нетривиальность задачи в том, что:
- Нет свободного железа. Мигрировать нужно на тот же сервер. =)
- Сервер очень важный, с базой данных 24/7. Допустимый простой, который получилось согласовать – 30 минут. При этом по 10 минут занимает остановка и запуск всех зависимых служб. Собственно на работу остается 10 минут максимум…
- Объем данных на дисках – чуть больше 220Gb на двух SCSI дисках по 147G.
- В базу постоянно пишется информация, терять которую нельзя. Так что клонирование диска не подходит – данные с начала запуска клонирования будут потеряны…
Хорошая новость в том, что на сервере операционная система 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».
Подключаемся к хосту по 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? 😉
И еще прошу не допытывать меня зачем это все надо – причины были.
Aloof, снимаю шляпу. Ты просто мегакрут!
Браво!!! Высший пилотаж.
В 30 мин. мигрироваться. Это круто, реально!
Без vCenter, без возможности на ошибку.
По-моему, это достойный ответ “гипервидвастым”.
У меня 2-3 часа с конвертером, зачисткой и т.д.
Mr. Nobody рассказывал мне про примерно похожий трюк только с vmotion, когда также монитруются RDM и делается storage vimotion, RDM скорее всего делается virtual. Я хотел так попробовать но не на чем, пока.
Ну 30 минут – это вместе с остановкой и запуском отдела и филиалов. Простой самого сервера 15 минут получился.
К сожалению Storage vMotion с такими RDM дисками не умеет работать, поэтому миграция дисков налету только средствами самой ОС. Возможность ошибки была – в любой момент можно было откатиться. Тоесть убрать ESX и вернуть все назад (загрузиться со старых дисков)
>Mr. Nobody рассказывал мне про примерно похожий трюк
Это я просто неправильно Mr.Aloof понял, думал он снаружи сторадж мигрирует, а оказалось внутри средствами LVM.
А что сценарий с vimotion не пройдет?
Как то плохо соответствуют друг другу пункты 1) и 2). Если свободного железа нет, а сервер такой важный 24/7. То получается что при выходе его из строя, например, простой будет явно больше 30-и минут. Либо у конторы сильно урезан бюджет IT, либо администратор не предусмотрел возможные проблемы, либо заявка доступности сервера 24/7 – это сильно завышенные требования руководства.
2Dmiter
Это минздрав, точнее служба 03 (скорая помощь). В минздраве серьёзные проблемы с ИТ бюджетом. Зато максимальные требования по доступности.
Слова Голиковой и Путина о пермской медицине приводить не буду.
Выход из строя – редкий случай. По статистике за пол года показатель доступности этого сервера (включая плановые) – 99,3. Естественно, при серьезном выходе из строя простой будет больше 30 минут. Но это не является поводом для увеличении времени запланированного простоя =)
Как раз лучшее обеспечение 24/7 и была одной из причин виртуализации. Надеемся в следующем году довести этот показатель до 99,999 =)
можно было второй сервер (если конечно на нем было 300Гб) опубликовать в качестве iscsi хоста, и мигрировать данные на него и потом обратно на VM. Времени бы это заняло дольше, но
1) время простоя было бы меньше
2) работы в основном можно было бы провести в рабочее время, а не ночью.
Ответ Дмитрию:
К сожалению как-то пропустил этот коммент и отвечаю с большим опозданием…
1. Даже если мы выделим еще один комп под iSCSI хранилище как нам это поможет?
Ну мигрировали бы мы данные на него (при этом база стала бы лагать и все были бы оч.недовольны) – что дальше делаем? Получили физический сервер с данными на iSCSI. Чем это сокращает время простоя?
2. Почему вы так решили? Вы как-то сможете после шага 1 превратить сервер в виртуальный без его выключения???
Очень советую Вам хорошо думать прежде чем писать что-то…
Из текста не понятно одно. В самом начале на сервере было 3 диска? Один с системой и два с данными? Или что? Иначе я не понимаю зачем все эти игры с lmv, если vmdk диски были подготовлены в самом сразу после загрузки в esxi
Даже не знаю как вам ответить. Вы не разобрались в сути описанного процесса.
Напишите своё видение переноса системы из физической среды в виртуальную.
Сколько дисков не имеет значения. Игры с lvm нужны для переноса данных с первоначальных дисков (физических) на виртуальные диски (vmdk)
Спасибо, занятное чтиво, ничего не понял, но все равно впечатляет. Хотелось бы когда-нибудь такие же штуки вытворять))
Афтар лошара и ничаво в виртуализация не педрит.