Живая миграция виртуальных машин в ProxMox VE 2.x

Недавно был поднят вопрос об использовании VmWare vMotion в небольшом кластере гипервизоров, однако цена данной возможности заставила немного пошевелиться в поисках альтернатив.

Так родился небольшой тестовый дайджест по настройке и эксплуатации возможности Live Migration виртуальных машин на основе QEMU в ProxMox VE 2.1 с использованием iSCSI NAS.

Нужно сказать что во второй версии ProxMox VE, девелоперы избавились от центральной ноды менеджмента кластера. Теперь ее роль может исполнять любая нода кластера, «был бы кворум» (с)

Подготовка

Итак, железо:

• 3 гипервизора. Сюда главное побольше процессоров и памяти
• 1 сторедж. Сюда главное побольше SAS винтов, процессор тоже не забывать, TCP/IP все таки. Я использовал аппаратный RAID5 из 5 дисков + 1 запасной диск
• На машинах лучше использовать сетевые карты с поддержкой Jumbo frames в количестве от 2 штук
• Желательно хороший свитч с поддержкой Jumbo frames и IEEE 802.3ad (аггрегация каналов)

Свитч конфигурируем с поддержкой Jumbo frames и Link aggregation, на каждом сервере по два порта — поскольку работать будем с iSCSI, хороший канал и фреймы нам не помешают.

ProxMox'ы (Debian) и CentOS конфигуриуем в режиме interface bonding (balance-rr mode) для пущей надежности и хорошей пропускной полосы. Так же на интерфейсах ставим MTU 9000 (если позволяет свитч и сетевухи, если хотя бы одна не позволяет — нет особого смысла).

Софт:

• На гипервизоры ставим Proxmox VE 2.x
• На сторедж ставим CentOS 6.x или FreeNAS

Адресация

Для пущего понимания происходящего, укажу что
10.0.0.1 10.0.0.2 10.0.0.3 — адреса гипервизоров
10.0.0.100 — адрес стореджа

Конфигурация ProxMox Cluster

Необходимо убедиться что все ноды имеют одинаковую временную зону и корректно работает демон ntpd.

Заходим в терминал 1 ноды и создаем кластер:

pvecm create mycluster

Заходим по очереди рутом на ноды 2 и 3 и добавляем их в кластер:

pvecm add 10.0.0.1

Где 10.0.0.1 — IP уже добавленной ноды (везде одинаковый)

При этом, в веб-интерфейсе управления (любой ноды) красиво зарисуется картинка нашего кластера

Конфигурация iSCSI target

Теперь нужно сконфигурировать наш сторедж дабы он предоставлял свое хранилище по протоколу iSCSI.

Для не больших поклонников терминальной возни можно воспользоваться дистрибутивом FreeNAS ^[1]. Однако мне, как сисадмину, его настройка показалась более упоротой, чем просто поднять tgtd на CentOS. Чем и займемся.

Дано:

• Совершенно голый Centos 6.3 x86_64 minimal
• Система ставится либо на рабочий RAID через LVM, либо на системные диски
• В любом случае, место на железячном RAID из SAS дисков оставляем не размеченным при установке

В chkconfig убираем автостарт всех сервисов, кроме необходимых.

Понадобился всего лишь один пакет:

# yum -y install scsi-target-utils

Создаем девайс для экспорта:

# vgcreate vgstor /dev/sdb
# lvcreate -n lvtgt -L2T vgstor

Далее просто редактируем /etc/tgt/targets.conf:

default-driver iscsi
<target iqn.2012-07.com.company:target0>
    backing-store /dev/vgstor/lvtgt
    write-cache off
    initiator-address 10.0.0.1
    initiator-address 10.0.0.2
    initiator-address 10.0.0.3
</target>

Стартуем tgtd

# service tgtd start
# chkconfig tgtd on

Таргет iqn.2012-07.com.company:target0 на шлюзе 10.0.0.100 готов к работе.

Да, и надо бы на процесс tgtd натравить monit ^[2], так сказать, во избежание…

Добавление таргета в ProxMox

В веб-интерфейсе ProxMox заходим в «Datacenter -> Storage -> Add -> iSCSI target» и добавляем наш iSCSI таргет

Лучше убрать галочку «Use LUNs directly», т.к. для кластерного управления, на этом LUN нужно будет создать LVM группу. Что и делаем «Datacenter -> Storage -> Add -> LVM Group»:

В «Base storage» выбираем наш таргет, в «Volume Group» называем как то нашу группу. Ставим галочку «Shared» и «Enable». Если не выбрано «Nodes», то LVM группа будет добавлена на все ноды.

Создаем виртуальную машину на iSCSI сторедже

В принципе, обычная процедура добавления виртуалки (qemu!), только на вкладке «Hard Disk» в поле «Storage» выбираем нашу заветную группу LVM:

Далее совершенно штатная процедура установки виртуальной машины. Нужно сказать что шаблоны (gzip'нутые dd-дампы диска) я храню заранее, а для разворота виртуалки я просто делаю в терминале гипервизора что то вроде

# zcat CentOS-6-x86_64-WWW.tpl.gz | dd of=/dev/vgiscsi/vm-101-disk-1

Однако кластерные фишки внесли сюрпризы в эту процедуру. Ибо в потушенном состоянии LV диск виртуалки «inactive» и dd на него просто так не сделаешь. Надо предварительно его активизировать:

# lvchange -aey /dev/vgiscsi/vm-101-disk-1

Далее прогнать dd, ну а потом:

# lvchange -an /dev/vgiscsi/vm-101-disk-1

И уж потом запускать виртуалку. Костыли всегда нас преследуют…

Тестируем миграцию

А теперь самое интересное. Миграция виртуалки с одного гипервизора на другой без прекращения ее работы (а-ля VmWare vMotion за 7к баксов).

Кликаем по виртуалке правой кнопкой выбираем «Migrate», выбираем нужную ноду, жмем галку «Online»:

В результате виртуалка смигрировала на соседнюю ноду за 8 секунд без прекращения работы.

Разве что ядро самой VM ругнулось на смещение времени:

High Availability

Все вышенаписанное открывает прямую дорогу к крайне загадочной и манящей вкладке "HA" на странице «Datacenter» в веб-интерфейсе.

Якобы, Proxmox использует RedHat'овские кластерные штучки для наблюдения за состоянием виртуалок и нод и в случае чего предпринимает некоторые меры.

Однако, спешу огорчить. Пока что у меня все это дело (HA) довольно крепко глючило. Даю слово Пионера разобраться в этой пучине и в скором времени написать сиквел данного обзора на тему «High Availability», ибо самого жутко интересует.

Ну а пока материала я думаю хватает. Виртуалки исправно работают и мигрируют. И это хорошо! (с)

Автор: pentarh