PROXMOX (Proxmox Virtual Environment) — платформа виртуализации для запуска виртуальных машин и контейнеров. Платформа базируется на ОС Debian Linux, в качестве гипервизоров использует две технологии виртуализации — KVM (аппаратная виртуализация) и LXC (контейнерная виртуализация). Благодаря этому на Proxmox можно запускать как виртуальные машины, так и контейнеры (что-то типа Docker). Гипервизор позволяет запускать любые KVM машины (Windows, Linux, xBSD, …) с минимальными потерями производительности.
Основными преимуществом Proxmox — это бесплатность самого продукта, открытость + мной любимая базовая ОС Debian Linux. Хотя, если бы была задача по выбору системы виртуализации отдельно стоящего сервера (не в кластере), я бы предпочел VMware ESXi, даже принимая во внимание ограничение у бесплатной версии (8 vCPU на виртуальную машину) или Microsoft Hyper-V Server. Но если компания не хочет тратиться на лицензию по кластеризации систем виртуализации, то у Proxmox-а огромное преимущество. Нужно отметить, что сам Proxmox бесплатный, но подписка на поддержку и обновления платная — https://www.proxmox.com/en/proxmox-ve/pricing, но авторы дают возможность бесплатных обновлений через некоммерческий репозиторий. Также, хотелось отметить плюсом в пользу Proxmox прекрасную документацию, которая идет вместе c образом установщика.
Рассмотрим 2 варианта установки гипервизора Proxmox
- Самостоятельно на Linux Debian;
- С родного образа — https://www.proxmox.com/en/downloads.
Оба варианта приемлемы, поскольку Proxmox использует ядро Linux и базируется на дистрибутиве Debian. Опишу только первый вариант, поскольку установка с родного образа не требует описания.
Установка на Debian 10
Настройки Hostname:
nano /etc/hosts
127.0.0.1 localhost
192.168.1.205 proxmox.local proxmox
Добавим репозиторий в список debian:
nano /etc/apt/sources.list
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
или сразу из консоли
echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" >> /etc/apt/sources.list
Цифровая подпись репозитория proxmox:
wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
Обновим список пакетов и систему:
apt update && apt full-upgrade
Установим саму систему proxmox:
apt install proxmox-ve postfix open-iscsi
В процессе установки будет предложено настроить smb.conf (WINS сервер) — отказался
Почтовую систему Postfix — выбрал Local Only, поскольку не настраиваю почтовую систему отправки сообщений от Proxmox.
После установки перегружаем сервер.
Рекомендуется удалить пакет os-prober
Пакет os-prober сканирует все разделы хоста, в том числе гостевые виртуальные машины, для создания записей GRUB с двойной загрузкой.
Если нет необходимости загрузки на сервере другой ОС кроме Proxmox VE можно удалить пакет os-prober
apt remove os-prober
reboot
Официальная документация по установке — https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch
Сервер Proxmox готов.
Администрирование
Управление Proxmox происходит либо через веб-панель, либо через консоль.
Вход по адресу — https://youripaddress:8006
Аутентификация Linux PAM standard authentication:
root
rootpasswd
Сообщение!
You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.
Это предупреждение об отсутствии платной подписки Proxmox на обновления. Однако можно подключить другой репозиторий для получения обновлений.
nano /etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
deb http://download.proxmox.com/debian/pve stretch pve-no-subscription
Настройка сети
Создаем по сути коммутатор (в понимании гипервизоров VMware и Hyper-V) с привязкой к сетевой карте. У Proxmox это называется Linux Bridge.
System -> Network -> Create -> Linux Bridge
IPv4/CIDR - 192.168.1.211/24 (IP нашего сервера)
Gateway - 192.168.1.11 (IP шлюза)
Bridge ports - ens192 (имя интерфейса)
В настройках самого интерфейса ens192 удаляем галочку Autostart и значения IPv4/CIDR. Перегружаем сервер.
Этого достаточно, чтоб на гипервизоре можно было запускать контейнеры и виртуальные машины.
Сеть в Poroxmox может работать в трех режимах — Bridge, Routed и NAT.
Подробно о сетях Proxmox — https://pve.proxmox.com/wiki/Network_Configuration
Кластер Proxmox
Следующим шагом будет разворачивание кластера на базе серверов Proxmox в тестовой среде.
Я выбрал установку с родного образа и все настройки были произведены уже на этапе подготовки к установке, кроме подключения бесплатного репозитория обновлений.
О тестовой среде.
В качестве хостов (нод) будет использована тоже виртуальная среда на базе VMware ESXi 6.7. Кластер будет состоять из 4-х нод: из хранилища NFS (условно единая система хранения данных — СХД) и еще одной машины на Debian. На 4-х нодах будет развернуты Proxmox 6 — это наши сервера виртуализации в кластере. Можно конечно и 2, и 3 ноды, тут выбор за каждым.
О кластерах и кворуме
Кластер не существует без кворума. Кворум это по сути ноды (машины) включенные в кластер и у которых есть право голоса. Суть голосования в том, что, если происходит падение одной из нод по причине отказа или сбоя, остальные решают по принципу большинства продолжать работать кластеру или нет. Если у нас в кластере 3 машины и одна уходит в сбой, то остальные два имеют 2 голоса из 3-х и это большинство, кластер продолжает работать. А если в кластере четное количество машин, то при отказе половины кластер перестает работать. Т.е. для работоспособности кластера из n машин (нод) необходимо минимум n/2+1 доступных машин.
В ситуациях с четным количеством нод вводится понятие свидетеля. Свидетель по сути обычная машина, без наличия систем виртуализации, в нашем случае Proxmox-а. При четном количестве нод свидетель голосует, а при случае сбоя или вывода ноды из кластера, когда количество работоспособных нод становится нечетным, то голос свидетеля не учитывается и так по циклу пока не наступит минимум < n/2+1.
Я специально выбрал для тестовой среды четное количество нод (4) для демонстрации свидетеля. Свидетель будет 6-й машиной в тестовой среде на Debian.
Сетевые настройки тестовой среды
Хранилище дисков будет развернуто на OpenMediaVault — IP 192.168.1.210.
Для этих задач можно выбрать любое решение для совместного доступа — NAS, iSCSI.
Proxmox 6 в количестве 4-х штук — IP 192.168.1.211 — 192.168.1.214.
Свидетель на Debian 10 — IP 192.168.1.215.
Важно! В настройках виртуального коммутатора на VMware необходимо включить Promiscuous Mode, если используете Hyper-V, то в настройках сетевого адаптера включить MAC address spoofing, иначе виртуальный коммутатор будет воспринимать только сетевую карту гипервизора Proxmox, а виртуальные машины внутри самого Proxmox не смогут отправлять пакеты наружу.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-1.jpg)
Установка Proxmox
Из родного образа разворачиваем 4 экземпляра гипервизора PVE1, PVE2, PVE3 и PVE4 с заданными сетевыми настройками и включенным параметром Hardware virtualization — Expose hardware assisted virtualization to the guest OS в свойствах процессора виртуальных машин в VMware для каждой ноды. Этот параметр включает возможность процессору работать в режиме вложенной виртуализации.
Установка OpenMediaVault
OpenMediaVault — это решение NAS сервера на базе Debian Linux с включенными сервисами SSH, FTP, TFTP, NFS, SMB, RSync. Достаточно простой и легкий NAS сервер.
- Скачиваем образ — https://www.openmediavault.org/download.html;
- Устанавливаем. Разворачивание не вызовет никаких сложностей — это типичная установка Debian Linux;
- Переходим в веб панель управления сервером, по адресу, который видим при загрузке системы (логин — admin, пароль — openmediavault).
Настройки OpenMediaVault
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-2-1024x717.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-3-1024x604.jpg)
В VMware создаём еще один диск для хранения данных. Размер соразмерный требуемому объему для установки ОС (я взял тонкий диск объемом 100Гб).
Создаем диск для общего хранилища и задаем настройки прав для доступа:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-4-1024x655.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-5-1024x637.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-6-1024x607.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-7-1024x632.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-8-1024x649.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-9-1024x645.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-10-1024x592.jpg)
Подключим хранилище к первой ноде PVE1:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-11-1024x545.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-12-1024x548.jpg)
Для тестовой среды в качестве контента диска я выбрал все варианты, в реальной среде стоит разделять исходя из качества дисков (RAID, скорость и т.д.). Такие данные как iso образы или бэкапы можно хранить на других дисках, чем диски самих виртуальных машин или контейнеров.
Нужно заметить, что диск подключили к кластеру, а не к ноде и один и тот же общий диск не нужно подключать для каждой ноды.
Настроим репозиторий для обновлений Proxmox для каждой ноды.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-13-1024x548.jpg)
После обновим необходимые пакеты на всех нодах.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-14-1024x547.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-15-1024x558.jpg)
Создаем кластер
Для полноценной демонстрации кластера необходимо создать отдельную выделенную сеть для самого кластера. В VMware создаю новый Port Group с названием ClusterNetwork и подключаю вторые сетевые карты на данный коммутатор.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-16-1024x517.jpg)
Сетевые настройки для нод Proxmox – 172.16.1.211/28 – 172.16.1.214/28
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-17-1024x547.jpg)
Собираем ноды в кластер:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-18-1024x545.jpg)
Выбираем созданную сеть под кластер. Будет создан кластер с одной текущей включённой нодой.
Забираем информацию для подключения остальных нод в кластер:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-19-1024x544.jpg)
Переходим поочередно по всем нодам и вставляем скопированную информацию:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-20-1024x553.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-21-1024x555.jpg)
После нажатия и подключения к кластеру соединение с текущей нодой теряется потому что меняется сертификат https подключения, если нужно повторно подключиться к ноде нужно обновить страницу.
Наш кластер готов.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-22-1024x565.jpg)
Итого имеем кластер из 4-х нод, кластерный трафик управления проходит через изолированную сеть и можно создавать виртуальные машины. Как видно на всех нодах доступно общее хранилище.
Установка виртуальных машин
В качестве теста установим сервер на базе Linux Debian c Apache и одной простой страницей. На второй ноде создадим виртуальную машину и в качестве места хранения диска выберем общее хранилище.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-23-1024x542.jpg)
Установим наш виртуальный сервер:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-24-1024x540.jpg)
Виртуальный сервер готов, на нем работает наш сайт. Наша задача обеспечить доступность сервера при падении ноды на которой размещен сервер с сайтом.
У нас 4 ноды и задача при падении PVE2 сервер должен мигрировать на PVE3, если нет, то на PVE4, а на PVE1 не мигрировала.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-25-1024x539.jpg)
Создаем группу и выставляем приоритеты. Чем выше приоритет, тем предпочтительнее нода в группе.
- restricted – позволяет ВМ мигрировать обратно на свою ноду при восстановлении работоспособности.
- nofailback – запрещает возвращаться на свою ноду.
Создаем ресурс для высокой доступности и назначаем в группу:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-26-1024x511.jpg)
max_restart: количество перезагрузок сервиса или сервера для попытки восстановления работоспособности после чего начнется миграция на другую ноду.
max_relocate: количество переходов по нодам, если сразу не удалось восстановить работоспособность.
Работа кворума:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-27-1024x540.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-28-1024x542.jpg)
Отправим в shutdown ноду с веб-сервером. Посмотрим на состояние кворума:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-29-1024x537.jpg)
Сервер мигрировал на PVE3 (как мы и хотели), кворум– ОК, кластер жив.
Остановим PVE3:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-30-1024x537.jpg)
Все. Кластер перестал существовать. Наш сайт недоступен.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-31-1024x542.jpg)
Запустим PVE2:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-32-1024x541.jpg)
Кластер восстановил работу. 3 голоса из необходимых 3-х. Сервер вернулся на свою ноду.
Зачем может понадобиться иметь четное количество нод, если при падении половины кластер не работоспособен? Кроме обеспечения высокой доступности с миграцией серверов при сбое нод можно использовать другой инструмент сохранности сервисов – репликации. Репликации серверов происходят по заданному расписанию и на заданные ноды.
Для кластера высокой доступности с четным количеством нод обычно используют свидетеля. Введем в наш кластер сервер-свидетель.
Свидетель в кластере
В нашем случае это обычный Debian 10 сервер который в реальной среде может выполнять и другие функции (иметь работающие службы и сервисы). Нам нужно будет установить 2 пакета.
Настроим сеть согласно условиям тестовой среды:
Первая сетевая карта – 192.168.1.215
Вторая сетевая карта – 172.16.1.215
Установим пакеты на сервер свидетеля:
apt-get install corosync-qdevice
apt-get install corosync-qnetd
Установим пакет на всех нодах Proxmox:
apt-get install corosync-qdevice
В консоли PVE1 выполним команду:
corosync-qdevice-net-certutil -Q -n <cluster name> <ip address for witness> <ip address for proxmox> <ip address for proxmox-b>
в нашем случае
corosync-qdevice-net-certutil -Q -n Cluster1 172.16.1.215 172.16.1.211 172.16.1.212 172.16.1.213 172.16.1.214
На вопросы ответим – yes и далее введем необходимое количество раз пароль для соединения с нодами кластера.
Отредактируем файл /etc/corosync/corosync.conf на PVE1 и добавим следующее в секцию кворума:
nano /etc/corosync/corosync.conf
quorum {
provider: corosync_votequorum
device {
model: net
votes: 1
net {
tls: on
host: 172.16.1.215 #<ip address for witness>
algorithm: ffsplit
}
}
}
Перезагрузим сервисы service и corosync-qdevice:
service corosync restart
service corosync-qdevice start
Сделаем аналогичные действия на всех нодах: отредактируем файл /etc/corosync/corosync.conf и перезапустим service corosync restart, service corosync-qdevice start.
Подробнее — https://pve.proxmox.com/pipermail/pve-devel/2017-July/027732.html
Проверим свойства нашего кворума:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-34-1024x622.jpg)
Отключим ноды PVE2 и PVE3:
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-35-1024x621.jpg)
Кластер жив при 2-х отсутствующих нодах. Сервере мигрировал на PVE4 согласно правилам перемещения.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-36-1024x623.jpg)
Доступность сервисов через репликации
Рассмотрим вариант репликации с ноды на ноду на примере контейнера. Контейнер из шаблонов в котором развернута phpBB.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-37-1024x664.jpg)
В качестве диска выбрано хранилище ZFS. Это важно, поскольку репликации идут только с хранилищ zfs.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-38-1024x622.jpg)
Настройка репликации: на вторую ноду с zfs хранилищем и с расписанием каждые 30 мин.
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-39-1024x605.jpg)
![](https://blog.airmeno.ru/wp-content/uploads/2019/11/prox01-40-1024x530.jpg)
И тот и другой вариант приемлемы для обеспечения доступности сервисов: для критических сервисов режим высокой доступности, для менее важных сервисов, с возможным простоем можно использовать режим репликации с последующим ручным разворачиванием сервисов на другой ноде.
На этом пока все. Повторюсь, Proxmox достаточно взрослая система и ее можно использовать в производственных средах, однако при наличии бюджета у компании все же имеет смысл присмотреться к основным игрокам этого рынка – Vmware (когда достаточно денег) или Microsoft (когда можно чуть сэкономить). Но если у вас только Linux сервера и нет вопросов с лицензированием клиентских ОС на гипервизоре в кластере, то тут опять преимущество Proxmox.