Как стать автором
Обновить

Объединение узлов Proxmox в кластер при помощи OpenVPN

Время на прочтение 5 мин
Количество просмотров 33K
Использование среды виртуализации 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, т.к. статей написано много. В том числе и на хабре. Опишу только основные особенности и настройки:

  1. Устанавливаем:

    apt-get install openvpn

  2. Создаем файл с настройками /etc/openvpn/node1.conf и разрешаем запуск для него в /etc/default/openvpn

  3. В файле настроек нужно вписать следующие параметры:

    # Для работы мульткаста используем 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
    

  4. В каталоге /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
    

  5. Запускаем vpn:

    service openvpn restart

  6. Переходим на подключаемый узел «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>
    

  7. Запускаем vpn:

    service openvpn restart


2.2 Настройки хостов и сервиса для кластера

  1. На каждом узле нужно отредактировать файл /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-allhosts

    xxxx:xxx:xxx:xxxx::2 ipv6.node1.example.com ipv6.node1

    #
    # VPN

    10.0.0.1 node1 master cluster
    10.0.0.2 node2

    # и так для каждого нового узла…

    Указывая отдельно IP-адреса из подсети VPN для узлов, мы форсируем их использование, т.к. сервисы Proxmox пользуются короткими доменными именами.

  2. На «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
    

  3. Проверяем статус «master»:

    pvecm status
    

    В итоге должно быть видно следующее:

    Node ID: 1
    Multicast addresses: 224.0.2.1
    Node addresses: 10.0.0.1

3. Добавляем узел в кластер

Этих настроек уже должно быть достаточно, чтобы кластер заработал. Добавляем узел в кластер по инструкции из wiki:

  1. Переходим на узел «node2»
  2. Вводим:

    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
Теги:
Хабы:
+12
Комментарии 29
Комментарии Комментарии 29

Публикации

Истории

Работа

DevOps инженер
39 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн