Кластеризация в Proxmox VE

Kate

Administrator
Команда форума
В прошлых статьях мы начали рассказывать о том, что такое Proxmox VE и как он работает. Сегодня мы расскажем о том, как можно использовать возможность кластеризации и покажем какие преимущества это дает.
Что же такое кластер и зачем он нужен? Кластер (от англ. cluster) — это группа серверов, объединенных скоростными каналами связи, работающая и представляющаяся пользователю как единое целое. Существует несколько основных сценариев использования кластера:

  • Обеспечение отказоустойчивости (High-availability).
  • Балансировка нагрузки (Load Balancing).
  • Увеличение производительности (High Performance).
  • Выполнение распределенных вычислений (Distributed computing).

Каждый сценарий предъявляет свои собственные требования к составляющим кластера. Например, для кластера, выполняющего распределенные вычисления, основным требованием является высокая скорость выполнения операций с плавающей запятой и низкая латентность сети. Подобные кластеры часто используются в научно-исследовательских целях.

Раз уж мы коснулись темы распределенных вычислений, то хочется отметить, что существует еще такое понятие как грид-система (от англ. grid — решетка, сеть). Несмотря на общую схожесть, не стоит путать грид-систему и кластер. Грид не является кластером в привычном понимании. В отличие от кластера, входящие в грид узлы чаще всего разнородны и отличаются низкой доступностью. Такой подход упрощает решение задач распределенных вычислений, однако не позволяет создать из узлов единое целое.
Яркий пример грид-системы — популярная вычислительная платформа BOINC (Berkeley Open Infrastructure for Network Computing). Эта платформа изначально создавалась для проекта SETI@home (Search for Extra-Terrestrial Intelligence at Home), занимающегося проблемой поиска внеземного разума путем анализа радиосигналов.
Как это работает
Огромный массив данных, полученных с радиотелескопов, разбивается на множество небольших кусочков, и они отправляются на узлы грид-системы (в проекте SETI@home роль подобных узлов играют компьютеры добровольцев). Данные обрабатываются на узлах и после завершения обработки отправляются на центральный сервер проекта SETI. Таким образом проект решает сложнейшую глобальную задачу, не имея в своем распоряжении требуемых вычислительных мощностей.

Теперь, когда у нас есть четкое понимание того, что такое кластер, предлагаем рассмотреть каким образом его можно создать и задействовать. Будем использовать систему виртуализации с открытым исходным кодом Proxmox VE.

Особенно важно перед тем, как приступать к созданию кластера четко понимать ограничения и системные требования Proxmox, а именно:

  • максимальное количество нод в кластере — 32;
  • все ноды должны иметь одинаковую версию Proxmox (есть исключения, но для production они не рекомендуются);
  • если в дальнейшем планируется задействовать функционал High Availability, то в кластере должно быть как минимум 3 ноды;
  • для взаимодействия нод друг с другом должны быть открыты порты UDP/5404, UDP/5405 для corosync и TCP/22 для SSH;
  • задержка в сети между нодами не должна превышать 2 мс.

Создание кластера​


Важно! Нижеприведенная конфигурация является тестовой. Не забудьте свериться с официальной документацией Proxmox VE.

Для того, чтобы запустить тестовый кластер, мы взяли три сервера с установленным гипервизором Proxmox одинаковой конфигурации (2 ядра, 2 Гб оперативной памяти).
Если вы хотите узнать каким образом можно установить Proxmox, то рекомендуем прочитать нашу предыдущую статью — Магия виртуализации: вводный курс в Proxmox VE.
Изначально, после установки ОС, единичный сервер работает в Standalone-mode.

2lb91xdrokvieydn63rr9fb7ndo.png


Создадим кластер, нажав кнопку Create Cluster в соответствующем разделе.

4ksrmekzntmzfig-2ymdwx7oahs.png


Задаем имя будущему кластеру и выбираем активное сетевое соединение.

cywwbtaea7ogttm77ebrwtwo7f8.png


Нажимаем кнопку Create. Сервер сгенерирует 2048-битный ключ и запишет его вместе с параметрами нового кластера в конфигурационные файлы.

qvr3wyzqfxrgscstbwz0mzxztv0.png


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

cvzl17xrzcnv4tbjlgcgutbd6vc.png


Присоединение к кластеру​


Прежде чем подключаться к созданному кластеру нам необходимо получить информацию для выполнения подключения. Для этого заходим в раздел Cluster и нажимаем кнопку Join Information.

7gsemira1cy79g3f9yxopfxc_mo.png


В открывшемся окне нас интересует содержимое одноименного поля. Его необходимо будет скопировать.

rw-i7hhyo_yqrqy-o9oh2jxmi9g.png


Здесь закодированы все необходимые параметры подключения: адрес сервера для подключения и цифровой отпечаток. Переходим на сервер, который необходимо включить в кластер. Нажимаем кнопку Join Cluster и в открывшемся окне вставляем скопированное содержимое.

btfh0vp9foxegb2lcca-d-kww1c.png


Поля Peer Address и Fingerprint будут заполнены автоматически. Вводим пароль root от ноды номер 1, выбираем сетевое подключение и нажимаем кнопку Join.

v-umi3rqffairr3yhnn2tz2uafi.png


В процессе присоединения к кластеру веб-страница GUI может перестать обновляться. Это нормально, просто перезагружаем страницу. Точно таким же образом добавляем еще одну ноду и в итоге получаем полноценный кластер из 3-х работающих узлов.

tcwbmxrp1umdagapsce7tv4qfie.png


Теперь мы можем контролировать все узлы кластера из одного GUI.

e4atcbt-_ihvdai9jjjmiamgrds.png


Организация High Availability​


Proxmox «из коробки» поддерживает функционал организации HA как для виртуальных машин, так и для LXC-контейнеров. Утилита ha-manager обнаруживает и отрабатывает ошибки и отказы, выполняя аварийное переключение с отказавшей ноды на рабочую. Чтобы механизм работал корректно необходимо, чтобы виртуальные машины и контейнеры имели общее файловое хранилище.

После активации функционала High Availability, программный стек ha-manager начнет непрерывно отслеживать состояние работы виртуальной машины или контейнера и асинхронно взаимодействовать с другими нодами кластера.

Присоединяем общее хранилище​


Для примера мы развернули небольшое файловое хранилище NFS по адресу 192.168.88.18. Чтобы все ноды кластера могли его использовать нужно проделать следующие манипуляции.

Выбираем в меню веб-интерфейса Datacenter — Storage — Add — NFS.

vrpd3uedlwasqpg0m19g8pvtb2o.png


Заполняем поля ID и Server. В выпадающем списке Export выбираем нужную директорию из доступных и в списке Content — необходимые типы данных. После нажатия кнопки Add хранилище будет подключено ко всем нодам кластера.

6dmufyavxpq4dcxaqxarozuughm.png


При создании виртуальных машин и контейнеров на любом из узлов указываем наш storage в качестве хранилища.

Настраиваем HA​


Для примера создадим контейнер с Ubuntu 18.04 и настроим для него High Availability. После создания и запуска контейнера заходим в раздел Datacenter — HA — Add. В открывшемся поле указываем ID виртуальной машины/контейнера и максимальное количество попыток рестарта и перемещения между нодами.
Если это количество будет превышено, гипервизор пометит VM как сбойную и переведет в состояние Error, после чего прекратит выполнять с ней какие-либо действия.
p4h9nglzk5gtsojtebmvlny9cvq.png


После нажатия кнопки Add утилита ha-manager оповестит все ноды кластера о том, что теперь VM с указанным ID контролируется и в случае падения ее необходимо перезапустить на другой ноде.

ni6xq5soctxwt3-abx9bs0gvo8o.png


Устроим сбой​


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

dfwcve9i2iplppnbexfsomn0w40.png

Работа механизма HA не означает непрерывность работы VM. Как только нода «упала», работа VM временно останавливается до момента автоматического перезапуска на другой ноде.
И вот тут начинается «магия» — кластер автоматически переназначил ноду для выполнения нашей VM и в течение 120 секунд работа была автоматически восстановлена.

slepj6ytjfwkdkfx--i7kvrxega.png


Гасим node2 по питанию. Посмотрим, выдержит ли кластер и вернется ли VM в рабочее состояние автоматически.

7cgek6uuanswhta3osmoshozk10.png


Увы, как видим, у нас возникла проблема с тем, что на единственной, оставшейся в живых, ноде больше нет кворума, что автоматически отключает работу HA. Даем в консоли команду принудительной установки кворума.

pvecm expected 1

qkn6jwdgtovfx9ns7kt2veahb0w.png


Спустя 2 минуты механизм HA отработал корректно и не найдя node2 запустил нашу VM на node3.

6sz2xmx1djx-_rm6k_y3uz6xcpu.png


Как только мы включили обратно node1 и node2, работа кластера была полностью восстановлена. Обратите внимание, что обратно на node1 VM самостоятельно не мигрирует, но это можно сделать вручную.

Подводим итоги​


Мы рассказали вам про то, как устроен механизм кластеризации в Proxmox, а также показали, как настраивается HA для виртуальных машин и контейнеров. Грамотное использование кластеризации и HA значительно повышает надежность инфраструктуры, а также обеспечивает восстановление после сбоев.

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

 
Сверху