Настройка кластера Proxmox VE: различия между версиями

Материал из support.qbpro.ru
 
(не показано 25 промежуточных версий этого же участника)
Строка 85: Строка 85:
<br>
<br>
Задаем настройки для тома '''LVM''':<br>
Задаем настройки для тома '''LVM''':<br>
[[Файл:Hapve12.jpg]]<br>
[[Файл:Hapve13.jpg]]<br>
<br>
<br>
* где было настроено:<br>
* где было настроено:<br>
Строка 99: Строка 99:
==Настройка отказоустойчивости==
==Настройка отказоустойчивости==
* Создание группы<br>
* Создание группы<br>
Для начала, определяется с необходимостью групп. Они нужны в случае, если у нас в кластере много серверов,но мы хотим перемещать виртуальную машину между определенными нодами. Если нам нужны группы, переходим в '''Датацентр''' - '''HA'''<br>
Для начала, определяется с необходимостью групп. Они нужны в случае, если у нас в кластере много серверов,<br>
- '''Группы'''. Кликаем по кнопке Создать:<br>
но мы хотим перемещать виртуальную машину между определенными нодами. Если нам нужны группы,<br>
переходим в '''Датацентр''' - '''HA''' - '''Группы'''. Кликаем по кнопке '''Создать''':<br>
[[Файл:Hapve14.jpg]]<br>
<br>
Вносим настройки для группы и выбираем галочками участников группы:<br>
[[Файл:Hapve15.jpg]]<br>
<br>
* где:
'''ID''' — название для группы.
'''restricted''' — определяет жесткое требование перемещения виртуальной машины внутри группы.<br>
Если в составе группы не окажется рабочих серверов, то виртуальная машина будет выключена.<br>
'''nofailback''' — в случае восстановления ноды, виртуальная машина не будет на нее возвращена, если галочка установлена.<br>
Также мы можем задать приоритеты для серверов, если отдаем каким-то из них предпочтение.
<br>
Нажимаем '''OK''' — группа должна появиться в общем списке.<br>
* Настраиваем отказоустойчивость для виртуальной машины
Переходим в '''Датацентр''' - '''HA'''. Кликаем по кнопке '''Добавить''':<br>
[[Файл:Hapve16.jpg]]<br>
<br>
В открывшемся окне выбираем виртуальную машину и группу:<br>
[[Файл:Hapve17.jpg]]<br>
<br>
... и нажимаем '''Добавить'''.<br>


==Проверка==
==Проверка==
После выполнения всех действий, необходимо проверить, что наша отказоустойчивость работает.<br>
Для чистоты эксперимента, можно выключиться сервер, на котором создана виртуальная машина, добавленная в '''HA'''.<br>
Важно учесть, что перезагрузка ноды не приведет к перемещению виртуальной машины. В данном случае кластер отправляет сигнал, что он скоро будет доступен, а ресурсы, добавленные в '''HA''' останутся на своих местах.
* Для выключения ноды можно ввести команду:
systemctl poweroff
Виртуальная машина должна переместиться в течение 1 - 2 минут.


=Ручное перемещение виртуальной машины между узлами=
=Ручное перемещение виртуальной машины между узлами=
Представим ситуацию, что у нас произошел сбой одного из узлов кластера, но при этом виртуальная машина не переехала на рабочую ноду.<br>
Например, если сервер был отправлен в перезагрузку, но не смог корректно загрузиться. В консоли управления нет возможности мигрировать виртуалку с неработающего сервера. Поэтому нам понадобиться командная строка.<br>
И так, открываем '''SSH'''-консоль сервера, на любой работающем сервере '''Proxmox'''.<br>
Переходим в каталог '''qemu-server''' той ноды, которая не работает:<br>
cd /etc/pve/nodes/pve1/qemu-server
* мы предполагаем, что у нас вышел из строя сервер '''pve1'''.<br>
Смотрим содержимое каталога:
ls
Мы должны увидеть конфигурационные файлы запущенных виртуальных машин, например:
100.conf
* в нашем примере у нас запущена только одна виртуальная машина с идентификатором '''100'''.
mv 100.conf ../../pve2/qemu-server/
* где '''pve2''' — имя второй ноды, на которой мы запустим виртуальный сервер.<br>
Командой:
qm list
... проверяем, что виртуальная машина появилась в системе. В противном случае, перезапускаем службы:
systemctl restart pvestatd
systemctl restart pvedaemon
systemctl restart pve-cluster
Сбрасываем состояние для '''HA''':
ha-manager set vm:100 --state disabled
ha-manager set vm:100 --state started
* в данном примере мы сбросили состояние для виртуальной машины с идентификатором '''100'''.<br>
Если это не сделать, то при запуске виртуалки ничего не будет происходить.<br>
После виртуальную машину можно запустить:<br>
qm start 100
=Настройка репликации=
=Настройка репликации=
==ZFS==
Если у нас нет общего дискового хранилища, мы можем настроить репликацию виртуальных машин между нодами.<br>
==Настройка репликации==
В таком случае мы получим, относительно, отказоустойчивую среду — в случае сбоя, у нас будет второй сервер,<br>
на котором есть аналогичный набор виртуальных машин.
 
* Настройка '''ZFS'''
Репликация может выполняться только на тома '''ZFS'''. Подробная работа с данной файловой системой выходит за рамки данной<br>
инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимый том.
<br>
Работа с пулами '''ZFS''' выполняется из командной строки. Чтобы увидеть уже существующие пулы вводим:
zpool list -v
 
Для создания нового используем команду zpool create:
zpool create -f zpool1 /dev/sdc
 
* в данном примере мы создадим пул с названием '''zpool1''' из диска /dev/sdc.
Для создания пула из нескольких дисков (как RAID 0) перечисляем диски через пробел:
zpool create -f zpool1 /dev/sdc /dev/sdd
 
* из дисков '''sdc''' и '''sdd'''.
Для создания отказоустойчивого тома ('''RAID 1''') добавляем опцию '''mirror''':
zpool create -f zpool1 mirror /dev/sdc /dev/sdd
 
Теперь открываем панель управления Proxmox. Переходим в '''Датацентр''' - '''Хранилище''' - '''ZFS''':<br>
[[Файл:Hapve18.jpg]]<br>
<br>
Задаем настройки для создания хранилища из созданного ранее пула '''ZFS''':<br>
[[Файл:Hapve19.jpg]]<br>
<br>
* в данном примере мы создаем хранилище из пула '''zpool1''';<br>
название для хранилище задаем '''zfs-pool''', также ставим галочку Дисковое резервирование.<br>
Остальные настройки оставляем по умолчанию.<br>
<br>
После этого мы должны либо перенести виртуальную машину на хранилище '''ZFS''', либо создать в нем новую машину.
<br>
* Настройка репликации
Переходим к хосту, где находится виртуальная машина, для которой мы хотим настроить клонирование<br>
(она должна также находится на хранилище '''ZFS''') - '''Репликация''':<br>
[[Файл:Hapve20.jpg]]<br>
<br>
Задаем настройки для репликации виртуальной машины:<br>
[[Файл:Hapve21.jpg]]<br>
<br>
* в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором '''100'''.<br>
Репликация должна проводиться на сервер '''pve2'''.<br>
Нажимаем '''Создать''' — теперь ждем репликации по расписанию или форсируем событие, кликнув по '''Запустить сейчас''':<br>
[[Файл:Hapve22.jpg]]<br>
<br>
 
=Удаление нод=
=Удаление нод=
Удаление узла из рабочего кластера выполняется из командной строки. Список всех нод можно увидеть командой:<br>
pvecm nodes
Мы увидим, примерно, следующее:
Membership information
----------------------
    Nodeid      Votes Name
          1          1 pve1 (local)
          2          1 pve2
          3          1 pve3
* где '''pve1''', '''pve2''', '''pve3''' — узлы кластера; '''local''' указываем на ноду, с которой мы выполняем команду '''pvecm'''.
Для удаления узла, например, '''pve2''' вводим:<br>
pvecm delnode pve2
* Ждем немного времени, пока не пройдет репликация. В консоли управления Proxmox удаленный сервер должен пропасть
=Удаление кластера=
=Удаление кластера=
Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли<br>
Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли<br>

Текущая версия от 01:50, 22 февраля 2024

В данной инструкции мы сначала соберем кластер Proxmox для управления всеми хостами виртуализации из единой консоли, а затем — кластер высокой доступности (HA или отказоустойчивый). В нашем примере мы будем работать с 3 серверами — pve1, pve2 и pve3.

Подготовка узлов для настройки кластера

Серверы должны иметь возможность обращения друг к другу по их серверным именам. В продуктивной среде лучше всего для этого создать соответствующие записи в DNS. В тестовой можно отредактировать файлы hosts. В Proxmox это можно сделать в консоли управления — устанавливаем курсор на сервере - переходим в Система - Hosts - добавляем все серверы, которые будут включены в состав кластера:

Pre1.jpg

  • в данном примере у нас в hosts занесены наши два сервера Proxmox, из которых мы будем собирать кластер.

Работа с кластером

Построение кластерной системы выполняется в 2 этапа — сначала мы создаем кластер на любой из нод, затем присоединяем к данному кластеру остальные узлы.

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

Переходим в панель управления Proxmox на любой их нод кластера. Устанавливаем курсов на Датацентр - кликаем по Кластер - Создать кластер:

Pre2.jpg

Для создания кластера нам нужно задать его имя и, желательно, выбрать IP-адрес интерфейса, на котором узел кластера будет работать:

Pre3.jpg

  • ... кликаем Создать — процесс не должен занять много времени. В итоге, мы должны увидеть «TASK OK»:


Pre4.jpg

Присоединение нод

На первой ноде, где создали кластер, в том же окне станет активна кнопка Данные присоединения — кликаем по ней:

Pre5.jpg

В открывшемся окне копируем данные присоединения:

Pre6.jpg

Теперь переходим в панель управления нодой, которую хотим присоединить к кластеру. Переходим в Датацентр - Кластер - кликаем по Присоединить к кластеру:

Pre7.jpg

В поле «Данные» вставляем данные присоединения, которые мы скопировали с первой ноды — поля «Адрес сервера» и «Отпечаток заполняться автоматически». Заполняем пароль пользователя root первой ноды и кликаем Присоединение:

Pre8.jpg

Присоединение также не должно занять много времени. Ждем несколько минут для завершения репликации всех настроек.
Кластер готов к работе — при подключении к любой из нод мы будем подключаться к кластеру:

Pre9.jpg

Готово. Данный кластер можно использовать для централизованного управления хостами Proxmox.

  • Посмотреть статус работы кластера можно командой в SSH:
pvecm status

Настройка кластера

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

Для настройки отказоустойчивости (High Availability или HA) нам нужно:
Минимум 3 ноды в кластере. Сам кластер может состоять из двух нод и более, но для точного определения живых/не живых узлов нужно большинство голосов (кворумов), то есть на стороне рабочих нод должно быть больше одного голоса. Это необходимо для того, чтобы избежать ситуации 2-я активными узлами, когда связь между серверами прерывается и каждый из них считает себя единственным рабочим и начинает запускать у себя все виртуальные машины. Именно по этой причине HA требует 3 узла и выше.
Общее хранилище для виртуальных машин. Все ноды кластера должны быть подключены к общей системе хранения данных — это может быть СХД, подключенная по FC или iSCSI, NFS или распределенное хранилище Ceph или GlusterFS.

Подготовка

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

Настройка общего хранилища

Подробное описание процесса настройки самого хранилища выходит за рамки данной инструкции.
В данном примере мы разберем пример и использованием СХД, подключенное по iSCSI.
Если наша СХД настроена на проверку инициаторов, на каждой ноде смотрим командой:

cat /etc/iscsi/initiatorname.iscsi

... IQN инициаторов. Пример ответа:

...
InitiatorName=iqn.1993-08.org.debian:01:4640b8a1c6f
  • где iqn.1993-08.org.debian:01:4640b8a1c6f — IQN, который нужно добавить в настройках СХД.

После настройки СХД, в панели управления Proxmox переходим в Датацентр - Хранилище.
Кликаем Добавить и выбираем тип (в нашем случае, iSCSI):
Hapve10.jpg

В открывшемся окне указываем настройки для подключения к хранилке:
Hapve11.jpg

  • где ID — произвольный идентификатор для удобства;

Portal — адрес, по которому iSCSI отдает диски;
Target — идентификатор таргета, по которому СХД отдает нужный нам LUN.

Нажимаем добавить, немного ждем — на всех хостах кластера должно появиться хранилище с указанным идентификатором. Чтобы использовать его для хранения виртуальных машин, еще раз добавляем хранилище, только выбираем LVM:
Hapve12.jpg

Задаем настройки для тома LVM:
Hapve13.jpg

  • где было настроено:

ID — произвольный идентификатор. Будет служить как имя хранилища.
Основное хранилище — выбираем добавленное устройство iSCSI.
Основное том — выбираем LUN, который анонсируется таргетом.
Группа томов — указываем название для группы томов. В данном примере указано таким же, как ID.
Общедоступно — ставим галочку, чтобы устройство было доступно для всех нод нашего кластера.
Нажимаем Добавить — мы должны увидеть новое устройство для хранения виртуальных машин.

Для продолжения настройки отказоустойчивого кластера создаем виртуальную машину на общем хранилище.ID

Настройка отказоустойчивости

  • Создание группы

Для начала, определяется с необходимостью групп. Они нужны в случае, если у нас в кластере много серверов,
но мы хотим перемещать виртуальную машину между определенными нодами. Если нам нужны группы,
переходим в Датацентр - HA - Группы. Кликаем по кнопке Создать:
Hapve14.jpg

Вносим настройки для группы и выбираем галочками участников группы:
Hapve15.jpg

  • где:

ID — название для группы. restricted — определяет жесткое требование перемещения виртуальной машины внутри группы.
Если в составе группы не окажется рабочих серверов, то виртуальная машина будет выключена.
nofailback — в случае восстановления ноды, виртуальная машина не будет на нее возвращена, если галочка установлена.
Также мы можем задать приоритеты для серверов, если отдаем каким-то из них предпочтение.
Нажимаем OK — группа должна появиться в общем списке.

  • Настраиваем отказоустойчивость для виртуальной машины

Переходим в Датацентр - HA. Кликаем по кнопке Добавить:
Hapve16.jpg

В открывшемся окне выбираем виртуальную машину и группу:
Hapve17.jpg

... и нажимаем Добавить.

Проверка

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

  • Для выключения ноды можно ввести команду:
systemctl poweroff

Виртуальная машина должна переместиться в течение 1 - 2 минут.

Ручное перемещение виртуальной машины между узлами

Представим ситуацию, что у нас произошел сбой одного из узлов кластера, но при этом виртуальная машина не переехала на рабочую ноду.
Например, если сервер был отправлен в перезагрузку, но не смог корректно загрузиться. В консоли управления нет возможности мигрировать виртуалку с неработающего сервера. Поэтому нам понадобиться командная строка.
И так, открываем SSH-консоль сервера, на любой работающем сервере Proxmox.
Переходим в каталог qemu-server той ноды, которая не работает:

cd /etc/pve/nodes/pve1/qemu-server
  • мы предполагаем, что у нас вышел из строя сервер pve1.

Смотрим содержимое каталога:

ls

Мы должны увидеть конфигурационные файлы запущенных виртуальных машин, например:

100.conf
  • в нашем примере у нас запущена только одна виртуальная машина с идентификатором 100.
mv 100.conf ../../pve2/qemu-server/
  • где pve2 — имя второй ноды, на которой мы запустим виртуальный сервер.

Командой:

qm list

... проверяем, что виртуальная машина появилась в системе. В противном случае, перезапускаем службы:

systemctl restart pvestatd
systemctl restart pvedaemon
systemctl restart pve-cluster

Сбрасываем состояние для HA:

ha-manager set vm:100 --state disabled
ha-manager set vm:100 --state started
  • в данном примере мы сбросили состояние для виртуальной машины с идентификатором 100.

Если это не сделать, то при запуске виртуалки ничего не будет происходить.
После виртуальную машину можно запустить:

qm start 100

Настройка репликации

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

  • Настройка ZFS

Репликация может выполняться только на тома ZFS. Подробная работа с данной файловой системой выходит за рамки данной
инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимый том.
Работа с пулами ZFS выполняется из командной строки. Чтобы увидеть уже существующие пулы вводим:

zpool list -v

Для создания нового используем команду zpool create:

zpool create -f zpool1 /dev/sdc
  • в данном примере мы создадим пул с названием zpool1 из диска /dev/sdc.

Для создания пула из нескольких дисков (как RAID 0) перечисляем диски через пробел:

zpool create -f zpool1 /dev/sdc /dev/sdd
  • из дисков sdc и sdd.

Для создания отказоустойчивого тома (RAID 1) добавляем опцию mirror:

zpool create -f zpool1 mirror /dev/sdc /dev/sdd

Теперь открываем панель управления Proxmox. Переходим в Датацентр - Хранилище - ZFS:
Hapve18.jpg

Задаем настройки для создания хранилища из созданного ранее пула ZFS:
Hapve19.jpg

  • в данном примере мы создаем хранилище из пула zpool1;

название для хранилище задаем zfs-pool, также ставим галочку Дисковое резервирование.
Остальные настройки оставляем по умолчанию.

После этого мы должны либо перенести виртуальную машину на хранилище ZFS, либо создать в нем новую машину.

  • Настройка репликации

Переходим к хосту, где находится виртуальная машина, для которой мы хотим настроить клонирование
(она должна также находится на хранилище ZFS) - Репликация:
Hapve20.jpg

Задаем настройки для репликации виртуальной машины:
Hapve21.jpg

  • в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором 100.

Репликация должна проводиться на сервер pve2.
Нажимаем Создать — теперь ждем репликации по расписанию или форсируем событие, кликнув по Запустить сейчас:
Hapve22.jpg

Удаление нод

Удаление узла из рабочего кластера выполняется из командной строки. Список всех нод можно увидеть командой:

pvecm nodes

Мы увидим, примерно, следующее:

Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2
         3          1 pve3
  • где pve1, pve2, pve3 — узлы кластера; local указываем на ноду, с которой мы выполняем команду pvecm.

Для удаления узла, например, pve2 вводим:

pvecm delnode pve2
  • Ждем немного времени, пока не пройдет репликация. В консоли управления Proxmox удаленный сервер должен пропасть

Удаление кластера

Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли
— все операции делаем в командной строке.
Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:

pvecm nodes

Мы получим список нод — удалим все, кроме локальной, например:

pvecm delnode pve2
pvecm delnode pve3
  • в данном примере мы удалили ноды pve2 и pve3.

Необходимо подождать, минут 5, чтобы прошла репликация между нодами. После останавливаем следующие службы:

systemctl stop pvestatd pvedaemon pve-cluster corosync

Подключаемся к базе sqlite для кластера PVE:

sqlite3 /var/lib/pve-cluster/config.db

Удаляем из таблицы tree все записи, поле name в которых равно corosync.conf:

> DELETE FROM tree WHERE name = 'corosync.conf';

Отключаемся от базы:

> .quit

Удаляем файл блокировки:

rm -f /var/lib/pve-cluster/.pmxcfs.lockfile

Удаляем файлы, имеющие отношение к настройке кластера:

rm /etc/pve/corosync.conf
rm /etc/corosync/*
rm /var/lib/corosync/*

Запускаем ранее погашенные службы:

systemctl start pvestatd pvedaemon pve-cluster corosync

Кластер удален.