Виртуализация Proxmox VE 3.X (KVM, OpenVZ) в составе кластера с внешним хранилищем + HA

ProxmoxVE

Поговорим сегодня о Proxmox! Промышленное решение для организации ИТ-инфраструктуры компании под свободной лицензией (платна только подписка на обновления и поддержку). Proxmox VE 3.X являет собою дистрибутив на основе Debian, со специально пропатченным ядром на базе 2.6 для OpenVZ. После настройки нодов в составе кластера, все управление производится через веб-интерфейс. Proxmox — промышленное решения уровня VMware.

*запись дополнена 3.04.2015

Когда дело доходит до промышленного решения, то необходимо выбирать максимально простое, понятное и монолитное решение… которое проверенно временем. Тут уже нет места экспериментальным технологиям. И, что особенно важно, всегда играет не малую роль и человеческий фактор — т.е. систему нужно поставить и научить людей ею правильно пользоваться (в нашем случае, админов). И здесь очень важно, чтобы был нормальный интерфейс для управления этими делами, т.к. многие работать с «голой» командной строкой просто откажутся или не смогут. Также важны очень многие встроенные функции, такие как: отсутствие централизованного узла (состояние кворума), объединение серверов в кластер и все сопутствующие этому фишки.

В моем случае, использоваться будут в основном контейнеры OpenVZ, но обычно виртуалки KVM являются более востребованной функцией, нежели контейнеры (для них мы и будем стараться по ходу статьи). Но и про контейнеры хотелось бы замолвить словечко… Я бы с удовольствием использовал LXC, вместо OpenVZ (которые является ему, по сути — отцом), но для LXC до сих пор отсутствует внятный веб-интерфейс (форкам LXC Web Panel на github я бы дал статус — experimental), а про объединение в кластер и речи не идет… а когда нам нужно автоматизировать целый дата-центр, как быть без этого? В чем же разница между OpenVZ и LXC? Хм, да по большому счету это одно и тоже, если не вдаваться в код. По сути, разница лишь в том, что OpenVZ использует свое пропатченное ядро 2.6 (со включенными всеми патчами по безопасности, свежим KVM и дровами), а LXC включен в апстрип, т.е. в ванильное ядро начиная с 3.8. И как бы со временем, очевидно что он будет еще сильнее допилен, и «выдавит» OpenVZ. Но на данный момент, OpenVZ в составе Proxmox выглядит более готовым и завершенным решением (разработчики Proxmox обещают в будущих релизах заменить OpenVZ на LXC.. когда они будут равносильны по функциональности).

Кстати… удивительно, но насчет Proxmox в рунете я практически не нашел никакой документации на русском языке. Все только на буружуйских офф.доках и форумах. Так что, этот мануал должен быть довольно полезен для общественности :)

Ладно, хватит демагогии.. поехали устанавливать и настраивать наш дистр на ноды!

 

1) Установка

Система устанавливается очень просто. Одно требование — железный рейд (софтверные и гибридные не поддерживаются). Драйвера определяются автоматически (все вшито в ядро). Про установке, вас попросят указать IP, пароль и имя машины. Затруднений тут возникнуть не должно. Один момент, на который стоит обратить внимание — это FQDN-имя. Я рекомендую указывать в таком формате: имя.local, например: node1.local и ничего тут не мудрить с доменами. После завершения установки, можно заходить на веб-интерфейс по адресу: https://SERVER-IP:8006

Практика показывает: разные кластера должны быть в разных подсетях, чтобы не мешать друг другу (пример: один кластер в 1.1.1.X, второй в 1.1.2.X, маска и шлюз везде одинаковы).

 

2) Настройка нод

После установки, дайте на этот адрес интернет и обновите систему. При обновлении, система будет ругаться на ошибки при доступе к репозиториям Proxmox. Это нормально, доступ к обновлениям платный. Но это не страшно, нам же нужно обновить только дебиановские свободные пакеты.

apt-get update
apt-get upgrade

 

После обновления, проверьте дату и время на соответствие с реальным положением дел.

date

 

Если время не соответствует, поправьте его (опционально):

date --set hh:mm

 

или

date MMDDhhmmYYYY.ss

где:
MM — месяц
DD — день
hh — час
mm — минуты
YYYY — год
ss — секунды

После этого, настройка ноды считается законченной. Настройте все остальные ноды и только потом объединяйте их в кластер.

 

3) Создание кластера, добавление нод в кластер

Сначала, на первой ноде нужно создать кластер. Это делается единоразово.

 

3.1) Создание кластера

Здесь же можно задать имя кластера (в дальнейшем изменить его будет нельзя):

pvecm create YOUR-CLUSTER-NAME

 

Проверить статус кластера:

pvecm status

Все! Дальше нужно только добавлять в него уже настроенные ноды.

 

3.2) Добавление нод в кластер

Чтобы добавить ноды в кластер, выполните команду (выполнять команды нужно на самой добавляемой ноде):

pvecm add IP-ADDRESS-CLUSTER

где IP-ADDRESS-CLUSTER — адрес уже добавленной ноды (рекомендую указывать самую первую).

При добавлении вас попросят принять RSA-ключ (нужно будет ввести «yes» когда спросят) и ввести пароль от рута той ноды, с которой мы соединяемся.

 

Проверить статус кластера:

pvecm status
pvecm nodes

 

Все! Офф. доки на эту тему: https://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster#Create_the_Cluster

Практика показывает: все ноды кластера лучше прописать всем серверам кластера в /etc/hosts для надежности.

 

3.3) Удаление ноды из кластера

Этот пункт требует особого внимания, если тут накосячить — можно сломать весь кластер. Значит так, сначала нужно убрать все ВМ с удаляемой ноды (перенести их на другой сервера или удалить вовсе). После, нужно выключить эту ноду и физически отключить ее из сети (важно: убедитесь, что в текущем ее состоянии она больше никогда не появится в сети!)

 

Проверить количество нод:

pvecm nodes

 

Удалить ноду:

pvecm delnode IP-ADDRESS-NODE

Что удалит ноду из кластера. Все, больше доп. действий не требуется.

 

Проверить количество нод еще раз:

pvecm nodes

Если потом эту ноду нужно будет вернуть в кластер, то на ней нужно полностью под чистую переустановить Proxmox + дать ей новое имя и новый IP = ввести ее в кластер как новую (см. пункт 3.2).

 

4) Подключение хранилища

Ноды настроены и готовы, объединены в кластер…. самое время подключить хранилище. Здесь мы рассмотрим типичный пример используемый нами, подключения хранилища к серверам напрямую через Fibre Channel. Основная настройка, конечно же, происходит с самим хранилищем. В нашем случае это будет IBM Chassis C4A (на 24 SAS диска IBM, 22 из которых объединены в RAID6). Его нужно настроить «как обычно» (это тема для отдельной статьи). После подключить его к уже готовым нодам. Особенность работы с хранилищем, подключенного через LVM: на нем можно разместить только диски виртуалок KVM (и только в формате raw), но никак не файлы контейнеров OpenVZ.

 

Проверить устройства:

ls -l /dev/sd*

 

Ответ должен быть приблизительно таким:

root@node1:~# ls -l /dev/sd*
brw-rw---T 1 root disk 8,  0 Feb  3 21:26 /dev/sda
brw-rw---T 1 root disk 8,  1 Feb  3 21:26 /dev/sda1
brw-rw---T 1 root disk 8,  2 Feb  3 21:26 /dev/sda2
brw-rw---T 1 root disk 8,  3 Feb  3 21:26 /dev/sda3

 

В условиях с одним родным рейдом, должны быть только диска sda1,2,3… Перезагружаем наши сервера по очереди. Когда на всех серверах объявится новое устройство sdb, можно приступать к диагностике.. либо сразу к подключению хранилища. Внешнее хранилище, подключенное через LVM может использовать только raw формат дисков для VM.

 

4.1) Диагностика (опционально)

Опишем, как стоит проводить диагностику того, что хранилище «зацепилось» и система его видит. Это действие не является обязательным, а в случае выполнения — его достаточно проделать только на одной ноде.

 

Проверить устройства:

ls -l /dev/sd*

 

Ответ должен быть приблизительно таким:

root@node2:~# ls -l /dev/sd*
brw-rw---T 1 root disk 8,  0 Feb  3 21:22 /dev/sda
brw-rw---T 1 root disk 8,  1 Feb  3 21:22 /dev/sda1
brw-rw---T 1 root disk 8,  2 Feb  3 21:22 /dev/sda2
brw-rw---T 1 root disk 8,  3 Feb  3 21:22 /dev/sda3
brw-rw---T 1 root disk 8, 16 Feb  4 10:56 /dev/sdb

 

После перезагрузки, там должно появится это самое устройство sdb. Это и есть наше хранилище. Хотите убедится в этом на 100%? Ок, поехали!

 

Проверям, что система видит контроллер Fibre Channel и дрова на него встали.

lspci -vmm | grep Fibre

 

Ответ должен быть приблизительно таким:

root@node1:~# lspci -vmm | grep Fibre
Class:    Fibre Channel
Device:    Saturn: LightPulse Fibre Channel Host Adapter
SDevice:    Saturn: LightPulse Fibre Channel Host Adapter

 

Это хорошо. Далее, установим необходимые нам тулзы для диагностики:

apt-get install scsitools lsscsi

 

Сканируем на поиск новых устройств:

rescan-scsi-bus

 

Ответ должен быть приблизительно таким:

root@node1:~# rescan-scsi-bus
...
Scanning for device 2 0 0 0 ...
OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: IBM      Model: 1746      FAStT  Rev: 1070
Type:   Direct-Access                    ANSI SCSI revision: 05
Scanning for device 2 0 0 31 ...
OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 31
Vendor: IBM      Model: Universal Xport  Rev: 1070
Type:   Direct-Access                    ANSI SCSI revision: 05
...

 

А теперь мы убеждаемся, что наше хранилище соответствует именно букве sdb:

lsscsi

 

Ответ должен быть приблизительно таким:

root@node1:~# lsscsi
[0:2:0:0]    disk    LSI      RAID SAS 6G 0/1  2.13  /dev/sda
[1:0:0:0]    cd/dvd  HL-DT-ST DVDRAM GT80N     SF03  /dev/sr0
[2:0:0:0]    disk    IBM      1746      FAStT  1070  /dev/sdb
[2:0:0:31]   disk    IBM      Universal Xport  1070  -

 

Проверяем еще раз и убеждаемся, что все на месте.

ls -l /dev/sd*

На этом диагностика завершена. Можно приступать к созданию LVM и подключению его к Proxmox VE.

 

4.2) Создание LVM

LVM — особая технология хранения в Linux, благодаря которой мы сможем обеспечить живую миграцию машин с ноды на ноду. Итого, все это работает подобно VMware vMotion. Ее настройка очень проста :)  Все пункты делаются только один раз, при первичном подключении хранилища в кластеру.

 

Обозначаем том sdb как устройство LVM (особое внимание: опасность потери данных на sdb! Вы должны четко понимать, что делаете…):

pvcreate /dev/sdb

 

Создаем на устройстве sdb группу, под названием «ibm»:

vgcreate ibm /dev/sdb

 

Все! Все настройки автоматически синхронизируются со всем кластером. Далее, просто заходим в веб-интерфейс и «пристегиваем» наш LVM.

Datacenter >>> Storage >>> Add >> LVM в графе «Volume Group» выбираем ibm.

add_lvmВсе! Хранилище успешно добавлено и актуализировалось на всех обозначенных вами нодах.

ibm_storageОфф. доки на эту тему: http://pve.proxmox.com/wiki/Storage_Model

 

5) Multipath

Multipath — технология подключения узлов сети хранения данных с использованием нескольких маршрутов. В нашей конфигурации используется 2 FC контроллера со стороны сервера + 2 FC контроллера со стороны сервера хранилища + SAN-свитч. Итого выходит, что хранилище видно по 4-м каналам. Подключение хранилища через multipath обеспечивает агрегацию каналов и их резервирование, на уровне ядра системы. Это увеличивает скорость, а в случае отказов — незаметно для пользователя использует доп. каналы. Чтобы вы понимали, сама технология является частью ядра Linux, и в большинстве случаев (на нормальном железе) вся конфигурация определяется автоматически. Итак, установим тулзы:

apt-get install multipath-tools

 

Проведите диагностику, как это показано в п.4.1. Проверить id каждого диска можно командой:

/lib/udev/scsi_id -g -u -d /dev/sdc

 

В нашем случае конфиг определился автоматически. Общая картина у нас такая (при подключении только одного хранилища к SAN-свичу):

root@node3:~# ls -l /dev/sd*
brw-rw---T 1 root disk 8,   0 Mar 25 14:50 /dev/sda
brw-rw---T 1 root disk 8,   1 Mar 25 14:50 /dev/sda1
brw-rw---T 1 root disk 8,   2 Mar 25 14:50 /dev/sda2
brw-rw---T 1 root disk 8,   3 Mar 25 14:50 /dev/sda3
brw-rw---T 1 root disk 8,  16 Mar 25 14:50 /dev/sdb
brw-rw---T 1 root disk 8,  32 Mar 25 14:50 /dev/sdc
brw-rw---T 1 root disk 8,  48 Mar 25 14:50 /dev/sdd
brw-rw---T 1 root disk 8,  64 Mar 25 14:50 /dev/sde

sdb, sdc, sdd, sde — наше хранилище и его 4-ре канала.

 

Проверяем, автоопределился ли multipath:

multipath -ll
root@node3:~# multipath -ll
360080e50003e2c4c000003b555000a25 dm-2 IBM,1746 FAStT
size=11T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 7:0:1:0 sdc 8:32 active ready running
|- 7:0:2:0 sdd 8:48 active ready running
|- 8:0:0:0 sdf 8:80 active ready running
`- 8:0:1:0 sdg 8:96 active ready running

 

Более полная информация выводится командой:

multipath -v3

 

Как мы видим, хранилище подключено 4-мя каналами. Но ключевым параметром тут является id: 360080e50003e2c4c000003b555000a25, а дополнительным: dm-2 (это временное имя хранилища). Так вот, монтируется в систему оно потом в любом случае по id автоматически, а имя нам потребуется для создания LVM в п.4.2.

 

На это имя мы и создаем LVM:

pvcreate /dev/dm-2
vgcreate ibm /dev/dm-2

Все! Дальше, хранилище осталось активировать через веб-интерфейс, как уже было показано выше.

Офф. доки на эту тему: http://pve.proxmox.com/wiki/ISCSI_Multipath

 

6) High Availability service (HA)

Это, пожалуй, самая сложная часть. По-умолчанию VM работают в классическом режиме: размещены на сервере, но если сервер становится недоступен, то все VM становятся недоступны вместе с ним. В режиме же HA, происходит следующее: в случае отказа сервера, все его VM автоматически переезжают на другой сервер(а) кластера. HA настраивается просто, через веб-GUI. Однако, одним из требований работы HA (в добавок к high-end оборудованию и совместному хранилищу) является наличие аппаратного Fencing-устройства для каждого сервера (чтобы избежать одновременного ошибочного доступа к данным VM с нескольких серверов, это называется «split-brain condition» и может привезти к «data corruption»). Именно этим и важен Fencing, он выполняет роль вышибалы — физически блокирует доступ сервера к данным VM (закрывает SAN порты, отключает от сети или от питания, либо просто перезагружает сервер). Аппаратный Fencing — является наиболее эффективным и стабильным решением. Примеры таких устройств: APC реки, SAN свитчи.. и сервисы на подобии HP iLO. В нашем случае, мы будем использовать утилиту HP ILO, которая вшита в наши сервера HP DL360 Gen9. Она идеально подходит для данной роли. Подключите и настройте iLO на сервере, задайте ему пароль и настройте доступ. После, продолжаем:

 

6.1) Fencing

Настройка происходит полностью через консоль и конфиги. Морально приготовьтесь. Более того, под каждое Fencing-оборудование будут свои, особые конфиги. Перво-наперво, надо активировать программный Fencing-домен и объединить в него все сервера кластера (данные операции выполнить на всех серверах). Для это нужно раскоментить строку (FENCE_JOIN=»yes») в этом конфиге:

nano /etc/default/redhat-cluster-pve

 

Перезапустим сервис:

/etc/init.d/cman restart

 

Проверяем и добавляем сервер в Fencing-домен:

fence_tool join
fence_tool ls

 

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

service pve-cluster restart

 

Далее, устанавливаем тулзы для связи с HP iLO из ОС с помощью интерфейса IPMI:

apt-get install ipmitool openipmi

 

Запуск и перезапуск сервиса:

invoke-rc.d ipmievd start
invoke-rc.d ipmievd restart

 

Очевидно, что он будет ругатся… для работы IPMI необходимо активировать доп.модули ядра системы:

modprobe ipmi_devintf
modprobe ipmi_si

 

Сделаем так, чтобы они активировались автоматически после ребута ОС (поправить конфиг и вставить туда след.значения):

nano /etc/modules
ipmi_devintf
ipmi_si

 

Проверяем теперь:

cat /proc/devices
ipmitool -I open chassis status

 

В 1-м случае должен появится девайс ipmidev, а во втором выхлоп будет похож на это:

root@node1:~# ipmitool -I open chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : false
Power Control Fault  : false
Power Restore Policy : always-on
Last Power Event     :
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false
Front Panel Control  : none

 

Проверяем Fencing. Эти команды делают приблизительно одно и тоже (1-2 проверяют статус, 3 — отправляет в ребут… логин и пароль от iLO):

ipmitool -I lanplus -H 172.16.1.211 -U Administrator -P Password power status
fence_ilo4 -P -C 1 -a 172.16.1.211 -l Administrator -p Password -o status
fence_ilo4 -P -C 1 -a 172.16.1.211 -l Administrator -p Password -o reboot

 

Чтобы не палить пароль в конфиге напрямую (в т.ч. веб-GUI), напишем простейший скрипт:

nano /root/ilo
#!/bin/bash
echo "Password"
chmod +x /root/ilo

 

Все, после того, как указанные операции будут выполнены на всех серверах кластера — мы переходим к самой важной и ответственной вещи… правке основного конфига кластера. Нужно действовать очень аккуратно и внимательно. Запомните, после каждой правки конфига — необходимо там же и увеличивать его версию на 1 (параметр config_version=..). Создаем новый временный конфиг:

cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new

 

Правим его:

nano /etc/pve/cluster.conf.new

 

Активируем его:

ccs_config_validate -v -f /etc/pve/cluster.conf.new

 

Вот полностью рабочий конфиг кластера ‘cluster’, который был написан мною вручную: cluster_test1_ilo4

В нем: обозначено 2-а fencing устройства HP iLO, по каждому на сервер (каждый сервер имеет свой HP iLO с отдельным IP адресом), и 3-и ноды (3-я нода, так называемая временная «dummy node», служит для стабилизации работы кластера в случае аварии на одном из серверов.. на ней нет ВМ и fencing-устройств). Действие — перезагрузка. Последний момент, конфиг нужно активировать через веб-GUI. заходим в: Datacenter >>> HA >>> Activate (нажимаем кнопку, она будет активна).

Выглядит это так:

HA_activate

А теперь проверяем работу Fencing-устройства (с любого сервера кластера) и отправляем эту ноду в ребут:

fence_node node1

 

Все! Больше редактировать конфиги не придется, все дальнейшие действия проводятся через веб-GUI.

 

6.2) HA

Сервис HA нужно включать для каждой отдельной VM. Внимание: перед включением HA убедитесь, что данная VM выключена.

 

Так выглядит статус VM без HA:

HA_no

 

Добавляем VM в HA:

HA_addVM3

 

Активируем:

HA_activate

 

Новый статус VM с HA:

HA_yes

 

Все! Не забывайте подключать новые VM в HA.

Офф. доки на эту тему: http://pve.proxmox.com/wiki/Fencing

 

7) Если хранилища нет

Если хранилища нет, то сервера по прежнему могут быть частью кластера — только при этом они будут использовать только свою дисковую подсистему. Их достоинством является то, что такие сервера могут использовать как контейнеры OpenVZ, так и виртуальные машины KVM. Диски виртуальных машин могут быть в нескольких форматах. Особенности форматов дисков:

raw

  • наилучшая производительность
  • резервирует место под виртуалку полностью (фиксированный диск)

qcow2

  • возможность делать snapshot (в т.ч. «живые»)
  • резервирует место под виртуалку НЕ полностью (динамический диск)

vmdk

  • полная совместимость с VMware
  • резервирует место под виртуалку НЕ полностью (динамический диск)

Файлы контейнеров OpenVZ хранятся на самой ноде здесь: /var/lib/vz/private/ID (где ID — айди конейнера в веб-интерфейсе)

 

8) Работа с OpenVZ

Кратко: контейнеры рекомендуются к использованию, если речь идет о ноде без подключенного к ней хранилища и гостевой linux системе. Колоссальная экономия ресурсов + расширение диска/памяти «на лету».

При работе с Linux-контейнерами OpenVZ, вместо стандартных виртуалок KVM — есть некоторые особенности. Во-первых, файлы контейнеров нельзя разместить в хранилище, подключенном через LVM (только локально). Во-вторых, контейнеры нельзя «клонировать» (но можно создавать из заранее подготовленного шаблона). Если подобный список неудобств вас не смущает и вы готовы использовать контейнеры (за что и будете вознаграждены экономией ресурсов сервера), то можно приступать. Стандартные шаблоны OpenVZ можно закачать прямо через веб-интерфейс Proxmox (во вкладке storage). Но там все шаблоны представлены в архитектуре x86, если нужен х64 — то его можно прямо скачать с сайта OpenVZ: http://openvz.org/Download/templates/precreated и закачать их в той же вкладке веб-интерфейса через функцию Upload. Закачанный шаблон появится в веб-интерфейсе.

Чтобы зайти в контейнер, нужно с ноды выполнить команду (где 109 — ID виртуалки):

vzctl enter 109

Внутри контейнера настраиваем сеть, в зависимости от дистрибутива контейнера. Чтобы заработал вывод через Console в веб-интерфейсе Proxmox (если это нужно), в контейнере необходимо чуть поправить конфиг (в зависимости от дистрибутива контейнера): https://pve.proxmox.com/wiki/OpenVZ_Console

Все, потом настраивайте ОС как вам надо, устанавливаете весь софт (все как на обычной виртуалке). Когда вы полностью настроите контейнер, давайте сделаем из него шаблон… потом уже из этого шаблона можно расплодить целую кучу контейнеров. Прежде чем приступить, нажмите Shutdown в веб-интерфейсе и полностью погасите нужный вам контейнер. Потом, через веб-интерфейс полностью удалите сетевой интерфейс контейнера:

network_removeПосле этого, зайдите в папку с ID вашего контейнера и выполните команду (где 109 — ID контейнера, а your-template — имя вашего шаблона):

cd /var/lib/vz/private/109
tar -cvzpf /var/lib/vz/template/cache/your-temptate.tar.gz .

Точка в конце строки важна, не трогайте ее!

Все, новый шаблон для контейнеров готов к работе. Он появится в веб-интерфейсе Proxmox.

 

Эксплуатация

Эксплуатация системы реализована полностью через веб-интерфейс, так что никакие доп. требования и доп. ПО не потребуется. Разве что для функции «Console» (просмотра рабочего стола VM) рекомендую установить вам локально Java. Т.к. просмотр рабочего стола возможен в двух режимах: c VNC и без VNC. Режим с VNC — полнофункционален и он работает через Java.

В процессе эксплуатации никаких вопросов возникнуть не должно, все очень логично и интуитивно понятно. При логине в систему, можно даже включить русский язык в интерфейсе. Системой поддерживается живая миграция и живые бекапы, так что виртуальные машины можно свободно перемещать между нодами во включенном состоянии + делать их бекапы. Можно загрузить в локальные хранилища нодов дистрибутивы систем в .iso — что потом делает более комфортным создание новых виртуальных машин.

Пользуйтесь с удовольствием!)

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