###### 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)
Sign in with Wallet
Connect another wallet