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 удобно использовать стартовый набор server-pve. Он уже содержит все необходимые компоненты. Если же развёртывание PVE происходит в уже установленной системе на базе Восьмой платформы, достаточно любым штатным способом (apt-get, aptitude, synaptic) установить пакет pve-manager. Все необходимые компоненты при этом будут установлены автоматически. Также следует убедиться в том, что пакет systemd обновлён до версии, находящейся в репозитории P8.

Рассмотрим настройку кластера 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, следует указать в соответствии с реальной конфигурацией сервера.

При установленных пакетах alterator-net-eth и alterator-net-bridge вместо всего этого можно просто воспользоваться web-интерфейсом.

Основная часть разработки PVE ведётся под ОС Debian, и в связи с этим в свежих версиях PVE иногда возникают забавные нюансы. Так в текущей версии конфигурация Ethernet-мостов и информация о временны́х зонах считывается из специфичных для Debian и его производных конфигурационных файлов /etc/network/interfaces и /etc/timezone. Поэтому, пока ошибка не исправлена, настройки придётся продублировать:

# mkdir /etc/network
# 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

При этом имя машины НЕ должно присутствовать в файле /etc/hosts, разрешающимся в 127.0.0.1!

Настройка взаимодействия компонентов 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 nfs-client.target
# systemctl enable syslogd ntpd rrdcached ksmtuned crond lxcfs cgmanager nfs-client.target

Далее, на «головном» (см. выше) узле кластера выполняем команды собственно инициализации конкретного кластера PVE, в данном случае — «mypve»:

# systemctl start pve-cluster
# pvecm create mypve

На «подчинённых» (см. выше) узлах:

# pvecm add <головной_узел>
# systemctl start corosync pve-cluster

Далее, запускаем пользовательский интерфейс и добавляем его в список служб, запускаемых при старте узла:

# systemctl start pve-manager
# systemctl enable pve-manager

Дальнейшие настройки кластера удобно делать через веб интерфейс.

Применение PVE

В ходе работы с веб-интерфейсом PVE оператору приходится иметь дело со следующими основными объектами: физическими узлами, виртуальными окружениями, хранилищами данных и субъектами авторизации. Так как PVE является средством управления виртуальными окружениями, рассматривать взаимодействие компонентов мы будем относительно них. Виртуальные окружения под управлением PVE бывают двух типов: полностью виртуализированные, управляемые гипервизором kvm, и изолированные окружения выполняющиеся непосредственно на основном ядре ОС физического узла. Первые в терминах PVE называются VM (виртуальные машины), а вторые — CT (контейнеры, ConTainers). Начнём с VM.

VM: виртуальные машины kvm

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

Хранилища данных

В случае, когда PVE управляет не одним физическим узлом, а кластером физических узлов, должна обеспечиваться возможность миграции VM с одного физического узла на другой. Миграция представляет собой заморозку состояния VM на одном узле, перенос данных и конфигурации на другой узел, и разморозку состояния VM на новом месте. Так как виртуальные дисковые накопители VM могут занимать значительный объём, удобно в пределах среды виртуализации PVE оперировать не локальными файловыми системами физических узлов, а хранилищами данных, доступными со всех узлов кластера. Кроме того, очень удобно, когда образы загрузочных инсталляционных дисков ОС, которые мы развёртываем на виртуальных машинах, также были доступны сразу на всех узлах кластера. Чтобы не приходилось копировать сотни мегабайт файлов .iso с машины на машину, когда нам захочется развернуть несколько однотипных VM на разных физических узлах.

Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:

• сетевые файловые системы, в том числе распределённые: NFS, CEPH, GlusterFS;
• локальные системы управления дисковыми томами: LVM, ZFS;
• удалённые (iSCSI) и локальные дисковые тома;
• локальные дисковые каталоги.

Сетевые файловые системы подходят для организации распределённых хранилищ данных, доступных со всех узлов кластера. Остальные могут использоваться только в качестве локальных хранилищ, доступных в пределах одного узла.

При создании каждому хранилищу данных присваивается роль или набор ролей. Например, хранение контейнеров, образов виртуальных дисков, файлов .iso и так далее. Список возможных ролей зависит от бэкенда хранилища. Например, для NFS или каталога локальной файловой системы доступны любые роли или наборы ролей, а хранилища на базе CEPH можно использовать только для хранения ISO-образов или шаблонов контейнеров.

Сразу после инициализации кластера в пределах каждого из узлов нам доступно одно локальное хранилище данных. Этого ужу вполне достаточно для начала работы.

Создание виртуальной машины

Прежде чем создать в интерфейсе PVE виртуальную машину (VM), необходимо определиться со следующими моментами:

• откуда будет загружен инсталлятор ОС, которую мы будем устанавливать внутрь виртуальной машины;
• на каком физическом узле будет выполняться процесс гипервизора kvm;
• на каком хранилище данных будут располагаться образы дисков виртуальной машины.

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

Так как хранилища данных у нас пока только локальные, определимся с физическим узлом на котором будет создано виртуальное окружение. Чтобы установить ОС на виртуальную машину, расположенную на этом узле, нужно обеспечить возможность загрузки инсталлятора на этой виртуальной машине. Для этого загрузим ISO-образ инсталлятора в хранилище данных выбранного физического узла. Это также удобно делать через веб-интерфейс.

Теперь, когда все предварительные действия выполнены, нажимаем в веб-интерфейсе PVE кнопку «Создать VM» в правом верхнем углу.

Процесс создания VM оформлен в виде «мастера», привычного для пользователей систем управления виртуальными машинами. Проходя по очереди по вкладкам, выбираем, соответственно, уникальное имя VM, шаблон настроек ОС, файл .iso, с которого будет загружаться инсталлятор ОС, тип дискового контроллера, формат и размер образа виртуального жёсткого диска, хранилище данных, на котором он будет располагаться, количество ядер процессора и размер оперативной памяти и так далее. Отдельное внимание обратим на настройки типа подключения дисковых накопителей настройки доступа к сети.

Настройка сетевых подключений

Существует два основных способа подключения VM к сети:

• через трансляцию сетевых адресов;
• через ethernet-мост.

Первый способ рекомендуется к использованию в ситуациях, когда мы не планируем использовать виртуальную машину в качестве сервера каких-нибудь сетевых протоколов. Например, когда мы просто хотим протестировать процесс инсталляции ОС. Механизм NAT будет настроен автоматически, без дополнительных действий оператора, достаточно будет просто в процессе создания виртуальной машины поставить радиокнопку на вкладке «Сеть» в положение «NAT mode».

В процессе настройки гостевой ОС нужно будет выбрать автоматический вариант настройки сетевых адресов по протоколу DHCP. Со стороны гипервизора kvm будет поднят сервер DHCP, который выдаст гостевой системе сетевой адрес и маршруты. Также, со стороны гипервизора будет автоматически настроена трансляция всех адресов выданных встроенным сервером DHCP. Таким образом приложения, работающие в гостевой ОС, получат доступ ко всем сетям, к которым имеет доступ ОС физического узла, причём со стороны этих сетей они будут маскироваться под адресом самого физического узла.

Второй способ подключения рекомендуется во всех остальных ситуациях. В этом случае, учитывая настройки, сделанные нами при установке PVE, сетевой интерфейс виртуальной машины будет подключён к тому же самому виртуальному коммутатору, что и сетевой интерфейс физического узла. То есть, настройки сетевой подсистемы виртуальной машины зависят от конфигурации той самой сети, в которой находится физический узел. Например, если в этой сети работает сервер DHCP, который сможет выдать нужный адрес виртуальной машине, можно указать автоматический вариант конфигурации. Если нет — придётся настраивать вручную. В отличие от первого способа, где ручной вариант настроек не предполагается (хотя, и возможен).

VirtIO

Настраивая сетевое подключение, обращаем внимание также и на то, что в списке сетевых карт, которые может эмулировать гипервизор kvm, есть пункт «VirtIO (paravirtualized)». Это специальный интерфейс, задачей которого является снижение накладных расходов на эмуляцию физической сетевой карты и реализацию драйвера для работы с ней. Между производителями современных операционных систем и произоводителями современных гипервизоров существует договорённость о поддержке единого интерфейса VirtIO, который со стороны гостевой ОС выглядит как очень простая и производительная сетевая карта, а со стороны гипервизора — как прямой интерфейс к сетевому драйверу гостевой ОС. Таким образом, производительность существенно вырастает за счёт того, что не нужно больше эмулировать несуществующее железо. Если про гостевую ОС точно известно, что она поддерживает VirtIO, имеет смысл использовать именно эту «сетевую карту».

Кстати, реализация VirtIO существует также и для другого интерфейса между виртуальной ОС и гипервизором, критичного к скорости передачи данных — для дисковых накопителей. Там рекомендации точно такие же — если уверенность в поддержке со стороны гостевой ОС есть, включаем.

Удалённый доступ к виртуальной машине

После того, как выбор параметров виртуальной машины закончен и нажата кнопка «Завершить», виртуальная машина создана. Теперь нужно получить удалённый доступ к её консоли. В PVE для удалённый доступ к «физической» консоли виртуальной машины используется протокол VNC. В качестве клиента выступает приложение на Javascript, интегрированное в окно браузера.

Контейнеры (CT)

В отличие от виртуальной машины, которая с точки зрения ОС, запущенной на физическом узле, представляет собой один процесс гипервизора, процессы контейнера выполняются на том же самом ядре, что и остальные процессы ОС. То есть, если мы запустим VM и CT на одном и том же физическом узле PVE, процессы CT будут выполняться «рядом» с процессами гипервизора. Разница будет только в применении к процессам контейнеров механизмов изоляции — пространств имён (Namespaces) и групп управления (CGroups) — работающих на уровне ядра Linux.

Существует несколько реализаций изолированных контейнеров, базирующихся на этих механизмах. Например OpenVZ и LXC, которые отличаются развитостью и проработанностью механизмов управления. В PVE используется реализация LXC, обёрнутая дополнительным собственным пользовательским интерфейсом, делающим процесс создания и обслуживания контейнеров ещё более удобным.

Процесс создания контейнера во многом схож с процессом создания виртуальной машины. Разница в том, что создание контейнера соответствует созданию VM и одновременно установке туда операционной системы. Эквивалентом инсталляционному диску является шаблон, из которого разворачивается контейнер. Это архив, содержащий корневую файловую систему будущего контейнера. Примеры шаблонов контейнеров можно найти на сайте разработчиков PVE и в коллекции шаблонов OpenVZ.

Важно помнить, что шаблоны, пригодные для развёртывания CT в PVE, имеют собственную нотацию имён, отличающуюся от таковых, например, в OpenVZ. Поэтому перед загрузкой очередного шаблона в хранилище PVE не забываем переименовать его соответствующим образом.

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

Уникальность контейнера обеспечивается на двух уровнях: первый уровень это уникальный идентификатор контейнера в пределах ОС физического узла, в которой разворачиваются контейнеры. Это число, как правило больше ста. PVE автоматизированным образом ведёт учёт идентификаторов и при создании контейнера не позволит выбрать уже занятый. Кстати, в пределах кластера PVE идентификаторы VM и СТ составляют единое пространство идентификаторов.

Второй уровень уникальности контейнера — строго говоря, не обязательный — это сетевые настройки: IP-адрес и имя узла. Обеспечивать уникальность на этом уровне не обязательно, так как у нас может быть несколько контейнеров с одинаковым именем узла, адресом IP, и даже MAC-адресом. Просто они будут запускаться в разное время. Но следить за этим будет уже не PVE, а оператор. PVE только обеспечивает возможность задания сетевых настроек контейнера при его создании.

Основная задача CT, в отличие от VM — не запуск полноценной ОС в виртуальной машине, а запуск отдельного приложения или сетевой службы в изолированном окружении. Поэтому доступ для обслуживания CT, как правило, удобнее осуществлять через обычный терминал — то есть, уже без участия интерфейса PVE. Для этого внутри контейнера настраивают серверную часть SSH, VNC или наоборот — клиентскую часть X-протокола. Впрочем, веб-интерфейс предоставляет для CT, так же, кстати, как и для физических узлов консоль. Обычную текстовую консоль UNIX.

Обслуживание виртуальных окружений

Кроме создания, удаления и получения доступа к консоли существует ещё ряд важных задач по работе с виртуальными окружениями, которые веб-интерфейс PVE позволяет успешно решать. Это в первую очередь сбор статистики по расходованию ресурсов кластера PVE, управление доступом к объектам виртуальной инфраструктуры, и обеспечение бесперебойной работы в случае сбоев.

Статистика

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

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

Управление доступом

Как уже упоминалось в руководстве по установке, PVE может использовать любые базы данных пользовательских учётных записей, доступные через механизм PAM. Например, базы локальных пользователей физических узлов кластера. Кроме того, у PVE есть ещё и своя база данных учётных записей пользователей и групп. Все эти пользователи и группы являются полноправными субъектами доступа к объектам кластера. Объектами доступа являются физические узлы и хранилища данных. Полномочия субъектов доступа настраиваются через механизм ролей.

Для упрощения разграничения доступа в PVE существует ещё один уровень объектов доступа, функционально аналогичный группам — пулы. В состав пула могут входить виртуальные окружения и некоторые виды хранилищ данных. Доступ к пулам регулируется так же через механизм назначения ролей.

Резервное копирование

На радость системным администраторам PVE имеет встроенную систему резервного копирования. Добавить очередной пункт в расписание снятия резервных копий состояния виртуальных окружений и хранилищ данных можно буквально «в несколько кликов».

Важно не забыть предварительно добавить хранилище, у которого будет роль хранилища для резервных копий.

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

Снапшоты

Кроме снятия резервных копий, снапшоты используются и просто для фиксации состояния виртуального окружения. Для фиксации снапшотов есть специальный пункт в меню виртуального окружения в интерфейсе PVE.

Ссылки

• Официальный сайт
• Proxmox VE