Использование среды виртуализации Proxmox, а именно контейнеров OpenVZ, для создания виртуального ни для кого не станет новостью. Сервер, арендованный на площадке Hetzner, достаточно долго успешно справлялся со своими обязанностями.
Но время шло, количество данных увеличивалось, клиенты множились, рос LA…Арендован новый сервер, установлен и настроен Proxmox, администратор рвется в бой настроить кластер, чтобы мигрировать нагруженные контейнеры на новый сервер. В google найдены залежи инструкций, да и на wiki самого проекта Proxmox есть необходимая информация.
Сервера находятся в разных подсетях. Proxmox использует для синхронизации настроек узлов кластера corosync. При добавлении узла в кластер — ошибка:
Waiting for quorum… Timed-out waiting for cluster [FAILED]
Администратор в панике
Задача:
Настроить синхронизацию узлов Proxmox, расположенных в любом датацентре, и имеющих внешний IP-адрес. Организовать «кластер» в понимании Proxmox.
Дано:
Итак, что у нас есть:
- Proxmox 3.3, «бесплатный» репозиторий,
- Сервер-узел №1:
- dns: node1.example.com
- name: node1
- внешний ip: 144.76.a.b
- Сервер-узел №2:
- dns: node2.example.com
- name: node2
- внешний ip: 144.76.c.d
- Кластер:
- name: cluster
- Все контейнеры для работают во внутренних подсетях узлов. Дешево, сердито, без комментариев.
Выясняем, что синхронизация не работает из-за того, что мультикаст-запросы хоть и отправляются, но режутся оборудованием. Узлы просто не видят друг друга. Также для синхронизации пытаются использоваться IP-адреса доступных сетевых интерфейсов. Т.е. или внешний IP, или IP подсети для ВМ.
Решение:
Мы заставим мультикаст-запросы, которые отправляет corosync, ходить внутри одной сети для всех узлов кластера. Поднимем свою частную подсеть с OpenVPN и маршрутизацией.
0. Очищение
Для начала нужно откатить все изменения, внесенные неудачной попыткой добавить узел в кластер. Предполагается, что на «node2» не было настроено еще ничего, и не было ВМ.
- на node1:
pvecm nodes service pve-cluster restart pvecm expected 1 pvecm delnode node2 pvecm cman restart - на node2:
service pve-cluster stop service cman stop rm /etc/cluster/cluster.conf rm -rf /var/lib/pve-cluster rm -rf /var/lib/corosync service pve-cluster start service cman start
1. Настройки сети внутри кластера
Для некоторой унификации настроек согласуем следующие параметры для сетей внутри нашего будущего кластера:
- Подсеть OpenVPN: будет 10.0.0.0/24.
- Узел, на котором будет работать сервер OpenVPN мы назовем «master».
- Подсеть для контейнеров на узлах будет вида: 10.[1-254].0.0/16, где второй октет — номер узла.
- Предположим, что у нас будут ВМ с системными сервисами, например, серверы БД.
Я заранее предполагаю, что на «master» настроен name-сервер, с зоной, например, «.hosting.lan».
Это облегчит перенос ВМ между узлами. Просто меняем внутренний IP после переноса. - Настраиваем соответствующим образом сетевые интерфейсы на узлах Proxmox. Исправляем, если необходимо, настройки у ВМ.
2. Настраиваем «master»-узел
2.1 OpenVPN
Я не буду сильно вдаваться в настройку OpenVPN, т.к. статей написано много. В том числе и на хабре. Опишу только основные особенности и настройки:
- Устанавливаем:
apt-get install openvpn - Создаем файл с настройками /etc/openvpn/node1.conf и разрешаем запуск для него в /etc/default/openvpn
- В файле настроек нужно вписать следующие параметры:
# Для работы мульткаста используем tap dev tap proto udp # Сделаем буфер UDP побольше sndbuf 393216 rcvbuf 393216 # Подсеть сервера server 10.0.0.0 255.255.255.0 # Пробросим мультакаст-запросы на подсеть этого узла # corosync иногда любит использовать адрес vmbr0 route 224.0.0.0 240.0.0.0 10.1.0.1 # Пробросим трафик до подсетей узлов через VPN route 10.2.0.0 255.255.255.0 10.0.0.2 route 10.3.0.0 255.255.255.0 10.0.0.3 # и так для каждого нового узла... # Настройки для клиентов-узлов client-config-dir clients client-to-client - В каталоге /etc/openvpn/clients создаём файлы для настроек клиентов-узлов:
/etc/openvpn/clients/node2: # На узле 1 — обычные ВМ push "route 10.1.0.0 255.255.0.0" # А, например, на узле 3 — системные ВМ # push "route 10.3.0.0 255.255.0.0" # multicast — через VPN на master-узел push "route 224.0.0.0 240.0.0.0" push "dhcp-option DNS 10.0.0.1" push "dhcp-option DOMAIN hosting.lan" push "sndbuf 393216" push "rcvbuf 393216" # Для tap-устройства — IP + NetMask ifconfig-push 10.0.0.2 255.255.0.0 - Запускаем vpn:
service openvpn restart - Переходим на подключаемый узел «node2», тоже устанавливаем openvpn, прописываем файл «master» в /etc/default/openvpn.
Еще нужно будет поставить пакет resolvconf. В отличие от master-узла. Иначе магия с доменами для внутренней сети может не сработать. Мне так же пришлось скопировать файлик original в tail внутри каталога /etc/resolvconf/resolv.conf.d/. Иначе name-сервера от hetzher терялись.
В зависимости от настроек сервера, создаем файл настроек для клиента, в котором должны быть следующие параметры:
/etc/openvpn/master.conf: client dev tap proto udp remote <внешний IP или домен master> - Запускаем vpn:
service openvpn restart
2.2 Настройки хостов и сервиса для кластера
- На каждом узле нужно отредактировать файл /etc/hosts и привести к следующему виду:
# IPv4
127.0.0.1 localhost.localdomain localhost
# внешний адрес и домен узла
144.76.a.b node1.example.com
#
# IPv6
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhostsxxxx:xxx:xxx:xxxx::2 ipv6.node1.example.com ipv6.node1
#
# VPN10.0.0.1 node1 master cluster
10.0.0.2 node2
# и так для каждого нового узла…Указывая отдельно IP-адреса из подсети VPN для узлов, мы форсируем их использование, т.к. сервисы Proxmox пользуются короткими доменными именами.
- На «master» редактируем файл /etc/pve/cluster.conf, добавляем строчку multicast:
<cman keyfile="/var/lib/pve-cluster/corosync.authkey"> <multicast addr="224.0.2.1"/> </cman>Если файл не может сохраниться, то пробуем перезапустить сервис:
cd /etc service pve-cluster restartи снова пытаемся редактировать.
После редактирования:cd /etc service pve-cluster restart service cman restart - Проверяем статус «master»:
pvecm statusВ итоге должно быть видно следующее:
…
Node ID: 1
Multicast addresses: 224.0.2.1
Node addresses: 10.0.0.1
3. Добавляем узел в кластер
Этих настроек уже должно быть достаточно, чтобы кластер заработал. Добавляем узел в кластер по инструкции из wiki:
- Переходим на узел «node2»
- Вводим:
pvecm add masterОтвечаем на вопросы, ждем. Видим, что кворум достигнут.
pvecm status…
Node ID: 2
Multicast addresses: 224.0.2.1
Node addresses: 10.0.0.2
Результат
Положительный
- Proxmox видит узлы в кластере. В теории можно организовать кластер из узлов, расположенных где угодно. Нужно чтобы master-узел имел «внешний, белый» IP-адрес.
- Настройки синхронизируются.
- ВМ мигрируют между узлами.
- Скорость между узлами и «master» может превышать 400Mbit, если включить сжатие в OpenVPN. Зависит от данных и настроек внешней сети, конечно.
Отрицательный
Увы, не всё так хорошо, как хотелось бы.
- Иногда кворум нарушается, настройки перестают сохраняться. Помогает перезапуск сервисов кластера — pve-cluster, cman. Пока не понятно, это проблемы corosync или openvpn. В эти моменты очень весело проводить миграции ВМ.
- Кластер не совсем кластер, не так ли? Что будет, если узел «master» отключится? Сюда же отнесём жеcтко прописанные IP-адреса узлов в настройках VPN, hosts.
- Трафик виртуальных машин между node2 и node3 будет ходить через master по VPN. Такая схема будет удобной только для случая, когда на master основные ВМ, а на дополнительных узлах — системные ВМ.
Ссылки
habrahabr.ru/post/233971/ — Руководство по установке и настройке OpenVPN
pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster
pve.proxmox.com/wiki/Multicast_notes
www.nedproductions.biz/wiki/configuring-a-proxmox-ve-2.x-cluster-running-over-an-openvpn-intranet
Автор: SergeyD
