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 не смогут отправлять пакеты наружу.
Установка 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
В VMware создаём еще один диск для хранения данных. Размер соразмерный требуемому объему для установки ОС (я взял тонкий диск объемом 100Гб).
Создаем диск для общего хранилища и задаем настройки прав для доступа:
Подключим хранилище к первой ноде PVE1:
Для тестовой среды в качестве контента диска я выбрал все варианты, в реальной среде стоит разделять исходя из качества дисков (RAID, скорость и т.д.). Такие данные как iso образы или бэкапы можно хранить на других дисках, чем диски самих виртуальных машин или контейнеров.
Нужно заметить, что диск подключили к кластеру, а не к ноде и один и тот же общий диск не нужно подключать для каждой ноды.
Настроим репозиторий для обновлений Proxmox для каждой ноды.
После обновим необходимые пакеты на всех нодах.
Создаем кластер
Для полноценной демонстрации кластера необходимо создать отдельную выделенную сеть для самого кластера. В VMware создаю новый Port Group с названием ClusterNetwork и подключаю вторые сетевые карты на данный коммутатор.
Сетевые настройки для нод Proxmox – 172.16.1.211/28 – 172.16.1.214/28
Собираем ноды в кластер:
Выбираем созданную сеть под кластер. Будет создан кластер с одной текущей включённой нодой.
Забираем информацию для подключения остальных нод в кластер:
Переходим поочередно по всем нодам и вставляем скопированную информацию:
После нажатия и подключения к кластеру соединение с текущей нодой теряется потому что меняется сертификат https подключения, если нужно повторно подключиться к ноде нужно обновить страницу.
Наш кластер готов.
Итого имеем кластер из 4-х нод, кластерный трафик управления проходит через изолированную сеть и можно создавать виртуальные машины. Как видно на всех нодах доступно общее хранилище.
Установка виртуальных машин
В качестве теста установим сервер на базе Linux Debian c Apache и одной простой страницей. На второй ноде создадим виртуальную машину и в качестве места хранения диска выберем общее хранилище.
Установим наш виртуальный сервер:
Виртуальный сервер готов, на нем работает наш сайт. Наша задача обеспечить доступность сервера при падении ноды на которой размещен сервер с сайтом.
У нас 4 ноды и задача при падении PVE2 сервер должен мигрировать на PVE3, если нет, то на PVE4, а на PVE1 не мигрировала.
Создаем группу и выставляем приоритеты. Чем выше приоритет, тем предпочтительнее нода в группе.
- restricted – позволяет ВМ мигрировать обратно на свою ноду при восстановлении работоспособности.
- nofailback – запрещает возвращаться на свою ноду.
Создаем ресурс для высокой доступности и назначаем в группу:
max_restart: количество перезагрузок сервиса или сервера для попытки восстановления работоспособности после чего начнется миграция на другую ноду.
max_relocate: количество переходов по нодам, если сразу не удалось восстановить работоспособность.Работа кворума:
Отправим в shutdown ноду с веб-сервером. Посмотрим на состояние кворума:
Сервер мигрировал на PVE3 (как мы и хотели), кворум– ОК, кластер жив.
Остановим PVE3:
Все. Кластер перестал существовать. Наш сайт недоступен.
Запустим PVE2:
Кластер восстановил работу. 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
Проверим свойства нашего кворума:
Отключим ноды PVE2 и PVE3:
Кластер жив при 2-х отсутствующих нодах. Сервере мигрировал на PVE4 согласно правилам перемещения.
Доступность сервисов через репликации
Рассмотрим вариант репликации с ноды на ноду на примере контейнера. Контейнер из шаблонов в котором развернута phpBB.
В качестве диска выбрано хранилище ZFS. Это важно, поскольку репликации идут только с хранилищ zfs.
Настройка репликации: на вторую ноду с zfs хранилищем и с расписанием каждые 30 мин.
И тот и другой вариант приемлемы для обеспечения доступности сервисов: для критических сервисов режим высокой доступности, для менее важных сервисов, с возможным простоем можно использовать режим репликации с последующим ручным разворачиванием сервисов на другой ноде.
На этом пока все. Повторюсь, Proxmox достаточно взрослая система и ее можно использовать в производственных средах, однако при наличии бюджета у компании все же имеет смысл присмотреться к основным игрокам этого рынка – Vmware (когда достаточно денег) или Microsoft (когда можно чуть сэкономить). Но если у вас только Linux сервера и нет вопросов с лицензированием клиентских ОС на гипервизоре в кластере, то тут опять преимущество Proxmox.
