PVE
Что это такое
Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора KVM и системы контейнерной изоляции LXC. Строго говоря, PVE это не система виртуализации, а инструментарий управления средой, в которой выполняются виртуальные окружения KVM и LXC. Основными компонентами среды являются:
- физические сервера, на которых выполняются процессы гипервизора KVM и процессы, работающие в контейнерах LXC;
- хранилища данных, в которых хранятся образы инсталляционных дисков, образы дисков виртуальных машин KVM и файлы, доступные из контейнеров LXC;
- виртуальные сетевые коммутаторы, к которым подключаются сетевые интерфейсы виртуальных окружений.
Как это устроено
Собственно PVE состоит из веб-интерфейса, распределённого хранилища данных конфигурации виртуальных окружений, а также утилит конфигурирования, работающих в командной строке. Все эти инструменты предназначены только для управления средой выполнения виртуальных окружений. За формирование среды отвечают компоненты системы, не входящие непосредственно в состав PVE. В первую очередь это сетевая и дисковая подсистемы, а также механизмы аутентификации.
Веб-интерфейс
Веб-интерфейс пользователя PVE предназначен для решения следующих задач:
- создание, удаление, настройка виртуальных окружений;
- управление физическими серверами;
- мониторинг активности виртуальных окружений и использования ресурсов среды;
- фиксация состояний (snapshot-ы), создание резервных копий и шаблонов виртуальных окружений, восстановление виртуальных окружений из резервных копий.
Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать ещё и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.
Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM даёт возможность, например, интегрировать PVE в домен аутентификации.
Хранилище данных
В случае локальной установки PVE для размещения данных виртуальных окружений можно дополнительно ничего не настраивать и использовать локальную файловую систему сервера. Но в случае кластера из нескольких серверов имеет смысл настроить сетевую или распределённую сетевую файловую систему, обеспечивающую параллельный доступ к файлам со всех серверов, на которых выполняются процессы виртуальных окружений. В качестве таких файловых систем могут выступать, например, NFS или CEPH.
Сетевая подсистема
В отличие от хранилища данных, сетевая подсистема требует специальной настройки даже в случае локальной установки PVE. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному же устройству, обеспечивающему соединение с общей сетью передачи данных. Обычно в качестве такого устройства выступает Ethernet-мост.
Пример настройки и использования PVE
В качестве сервера для развёртывания PVE удобно использовать стартовый набор Сервер PVE. Он уже содержит все необходимые компоненты. Если же развёртывание PVE происходит в уже установленной системе на базе Восьмой платформы, достаточно любым штатным способом (apt-get, aptitude, synaptic) установить пакет pve-manager. Все необходимые компоненты при этом будут установлены автоматически.
Рассмотрим настройку кластера PVE. Локальную установку будем считать частным случаем кластера из одного узла.
Настройка сетевой подсистемы
Сначала на всех узлах кластера настроим Ethernet-мост в соответствии с руководством:
# mkdir /etc/net/ifaces/vmbr0 # mv /etc/net/ifaces/eth0/* /etc/net/ifaces/vmbr0/ # cp /etc/net/ifaces/vmbr0/options /etc/net/ifaces/eth0/ # cat <<EOF > /etc/net/ifaces/vmbr0/options BOOTPROTO=static CONFIG_WIRELESS=no CONFIG_IPV4=yes HOST='eth0' ONBOOT=yes TYPE=bri EOF # cat <<EOF > /etc/net/ifaces/vmbr0/brctl stp AUTO off setfd AUTO 0 EOF
Имя интерфейса, обозначенного здесь как eth0, следует указать в соответствии с реальной конфигурацией сервера.
Основная часть разработки PVE ведётся под ОС Debian, и в связи с этим в свежих версиях PVE иногда возникают забавные нюансы. Так в текущей версии конфигурация Ethernet-мостов и информация о временны́х зонах считывается из специфичных для Debian и его производных конфигурационных файлов /etc/network/interfaces и /etc/timezone. Поэтому, пока ошибка не исправлена, настройки придётся продублировать:
# printf "\nauto vmbr0\n\tiface vmbr0 inet static\n\taddress 10.0.0.251\n\tnetmask 255.255.255.0\n\tgateway 10.0.0.1\n\tbridge_ports eth0\n\tbridge_stp off\n\tbridge_fd 0\n" >> /etc/network/interfaces # . /etc/sysconfig/clock # echo $ZONE > /etc/timezone # ln -sf /usr/share/zoneinfo/$ZONE /etc/localtime
Далее необходимо обеспечить взаимно однозначное прямое и обратное преобразование имён для всех узлов кластера. Крайне желательно использовать DNS, но в крайнем случае можно обойтись соответствующими записями в локальных файлах /etc/hosts:
# echo "10.0.0.251 pve1.localdomain pve1" >> /etc/hosts # echo "10.0.0.252 pve2.localdomain pve2" >> /etc/hosts
Настройка взаимодействия компонентов PVE
В качестве транспорта для передачи команд между узлами кластера применяется протокол SSH. Если мы настраиваем локальную установку PVE, ничего специального делать не нужно, а если узлов в кластере будет несколько, необходимо на каждом узле разрешить передачу переменной окружения LC_PVE_TICKET:
# N=$(($(sed -n '/^AcceptEnv/{=}' /etc/openssh/sshd_config | tail -1) + 1)); sed -i "${N}i AcceptEnv LC_PVE_TICKET\n" /etc/openssh/sshd_config
# N=$(($(sed -n '/^[[:space:]]*SendEnv/{=}' /etc/openssh/ssh_config | tail -1) + 1)); sed -i "${N}i \ \ \ \ SendEnv LC_PVE_TICKET\n" /etc/openssh/ssh_config
# systemctl restart sshd
Кроме того, для передачи команд между узлами кластера необходимо обеспечить взаимную беспарольную аутентификацию пользователя root. Это можно сделать вручную, а можно при добавлении нового узла в кластер PVE разрешить на «ведущем» узле вход пользователя root по паролю и ввести пароль. После этого взаимная беспарольная аутентификация root будет настроена автоматически утилитами PVE, и вход root по паролю можно будет снова отключить.
Важно понимать, что в сконфигурированном кластере PVE все узлы равноправны. «Ведущим», «головным» и так далее один из узлов становится только в момент добавления в кластер нового узла. После добавления новый узел может стать таким же ведущим при проведении следующей процедуры добавления очередного узла в кластер.
Теперь осталось настроить ещё два компонента системы, которые утилиты PVE пока не могут полностью автоматически настроить при запуске кластера. Это демон rrdcached, отвечающий за хранение данных мониторинга активности подсистем кластера, и corosync — комплекс ПО, обеспечивающий в пределах кластера элементы высокой доступности.
# cp /usr/share/doc/pve-manager/rrdcached.sysconfig /etc/sysconfig/rrdcached
# mkdir -p /var/lib/rrdcached/{db,journal}
# rm -f /etc/corosync/corosync.conf
Конфигурационный файл corosync после этого будет создан автоматически при инициализации кластера PVE.
Запуск служб кластера
Запускаем службы кластера и настраиваем их автоматический запуск при старте узла:
# systemctl start syslogd ntpd rrdcached ksmtuned crond lxcfs cgmanager nfslock rpcbind pve-cluster # systemctl enable syslogd ntpd rrdcached ksmtuned crond lxcfs cgmanager nfslock rpcbind pve-cluster
Далее, на «головном» (см. выше) узле кластера выполняем команды собственно инициализации конкретного кластера PVE, в данном случае — «mypve»:
# pvecm create mypve # systemctl start corosync
На «подчинённых» (см. выше) узлах:
# pvecm add <головной_узел> # systemctl start corosync
Далее, запускаем интерфейс управления и добавляем его в список служб, запускаемых при старте узла:
# systemctl start pve-manager # systemctl enable pve-manager
Дальнейшие настройки кластера удобно делать через веб интерфейс.
Ссылки
Автор рекомендаций по развёртыванию -- shrek@.