###### tags: Proxmox, Linux.
# Proxmox настройка отказоустойчивости.
В этой заметки: Сначала соберем кластер Proxmox для управления всеми хостами виртуализации из единой консоли, а затем — кластер высокой доступности (отказоустойчивый).

Предыдущая статья: [Установка и настройка KVM + Proxmox](https:////hackmd.io/@erikguru/H1tIL8ZXi ).

## Подготовка нод кластера.

Как вы помните мы создавали виртуальную машину с Proxmox на VMware. В этой работе нам понадобиться 3 таких ноды. Поэтому создайте еще 2 виртуалки с установленным Proxmox и настроенным сетевым мостом. Рекомендуемые параметры (4gb оперативки, 2 и более ядра). При создании VM не забудьте поставить галочку, чтобы эта машина была гипервизором, при создание этой ноды в VMware.

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

Изменяем файл hosts подобным образом. Нужно сделать так чтобы все машины были доступны по доменному имени. Тоесть с машины созданной рание с hostname server мы должны суметь сделать ping до двух других машин по их именам.


Проверить можем сделав ping по доменному имени.

На 2 и 3 ноде запись для 1 сервера в файле hosts выглядит так: `10.143.0.101 pve1.local server`

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

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

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


Задайте имя кластеру.

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


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

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


Вводим пароль администратора(от root). И добавляем вторую машину в кластер. Обновляем страницу на первом сервере.


В консоли мы можем посмотреть статус кластера.


Как можете заметить добавление гипервизоров KVM в кластер через веб интерфейс Proxmox очень простое.

## Отказоустойчивый кластер.

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

Для настройки отказоустойчивости (High Availability или HA) нам нужно:

Минимум 3 ноды в кластере. Сам кластер может состоять из двух нод и более, но для точного определения живых/не живых узлов нужно большинство голосов (кворумов), то есть на стороне рабочих нод должно быть больше одного голоса. Это необходимо для того, чтобы избежать ситуации 2-я активными узлами, когда связь между серверами прерывается и каждый из них считает себя единственным рабочим и начинает запускать у себя все виртуальные машины. Именно по этой причине HA требует 3 узла и выше.

Общее хранилище для виртуальных машин. Все ноды кластера должны быть подключены к общей системе хранения данных — это может быть СХД, подключенная по FC или iSCSI, NFS или распределенное хранилище Ceph или GlusterFS.

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

У вас должно быть 3 ноды.


### Подготовка хранилища.

Для создания хранилища нам понадобиться 4-тая виртуальная машина. Вполне хватит 512mb оперативки. Инструкция: [Создание общей папки NFS](https://hackmd.io/@erikguru/rkncH98Xj).

Добавляем NFS расположение в датацентр. Для этого переходим в Датацентр -> Хранилище -> Добавить.В списке выбираем NFS.


ID это название хранилища, в поле сервер указываем адресс NFS директории, в поле Export указываем расположение директории на сервере nfs. В содержимое указываем какая информация будет храниться (выбираем все что есть).

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

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


**ID** — название для группы.

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

**nofailback** — в случае восстановления ноды, виртуальная машина не будет на нее возвращена, если галочка установлен

Также мы можем задать приоритеты для серверов, если отдаем каким-то из них предпочтение.

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

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


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


#### Проверка отказоустойчивости

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

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

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

systemctl poweroff

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


Первая ошибка с которой вы можете столкнуться.


Собственно исходя из теста ошибки не найден файл образа ubuntu. Что бы ее исправить перейдите в параметры и удалите CD Диск.


Вторая ошибка скоторой можно столкнуться. Ошибка запуска.


Это ошибка исходит из первой, после того как cdroom удалите ошибка с cdroom пропадает, однако информация об ошибки, запуска остаетсья в ha-manafer поэтому стопаем процесс на ноде на которую перенеслась машина и запускаем заного:

ha-manager set vm:100 --state disabled
ha-manager set vm:100 --state started

Для того чтобы убедиться что дальше ошибок не будет, стопаем 2-рую и запускаем 1-ю ноду. И наблюдаем как машина переместилась на 3-ю ноду без ошибок.


### Ручное перемещение виртуальной машины.

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

И так, открываем SSH-консоль сервера, на любой работающем сервере Proxmox. Переходим в каталог qemu-server той ноды, которая не работает:

cd /etc/pve/nodes/server/qemu-server

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

ls

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

100.conf

В нашем примере у нас запущена только одна виртуальная машина с идентификатором 100. Где pvenode2 — имя второй ноды, на которой мы запустим виртуальный сервер.

mv 100.conf ../../pvenode2/qemu-server/

Командой: `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 пулы и подключаем в Proxmox.
Репликация может выполняться только на тома ZFS. Добавьте новый диск для каждой из виртуальных машин server и pve_node2 на 20gb.
Смотрим название добавленного диска и создаем из него zfs раздел

lsblk
zpool create -f zpool1 /dev/sdb


Проверяем что пул создан:

zpool list


Таким же методом добавляем и на 2 виртуалке пул zfs.


Название дисков обязательно проверяем, что бы не было подобных ошибок как на скриншоте выше. В моем случа на одной виртуалке название диска нового было sdb, а на второй sda. Будьте внимательны. Название пула zfs должно быть одинаковым на обоих машинах.

Добавляем хранилище в proxmox. Обязательно нужно перейте в браузере по IP адрессу того сервера на котором хотите добавить хранилище.


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

Добавляем на 2-ю ноду.


### Настраиваем репликацию.

Давайте создадим контейнер CT на основе ubuntu 18.04. Делаем все также как и в 1 части только меняем расположение контейнера на zfs пул.


Настроим репликацию. **Важно!** Виртуальная машина или контейнер должны находиться на zfs пуле и резервироваться будут тоже в zfs пул.


Выбирете виртуалку или контейнер где включили репликацию и нажмите "Запустить сейчас"


Проверьте статус должен быть "ОК".

Как можно заметить диск контейнера есть на обоих VM. На zfs1:


И на zfs2:


## Удаление нод кластера.
Рассмотрим процесс удаления нод из кластера и самого кластера. **Данные действия не могут быть выполнены из веб-консоли** — все операции делаем в командной строке.

Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:

pvecm nodes

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

pvecm delnode pvenode2
pvecm delnode pvenode3

Необходимо подождать, минут 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';

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

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

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

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

Удалите названия нод из директории `/etc/pve/nodes`.
Удалите ключи авторизации `/etc/pve/priv/authorized_keys`

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

systemctl start pvestatd pvedaemon pve-cluster corosync

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

Источники:
1. [Proxmox репликация виртуальной машины](https:////auto-instructors.ru/articles/proxmox-replikatsiya-virtualnoy-mashiny/)
2. [Файловая система zfs](https://losst.pro/fajlovaya-sistema-zfs)