---
# System prepended metadata

title: Proxmox настройка отказоустойчивости.
tags: [Linux]

---

###### 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 до двух других машин по их именам. 

![](https://i.imgur.com/F6zZp52.png)

Проверить можем сделав ping по доменному имени. 
![](https://i.imgur.com/oCXOa6F.png)

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

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

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

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

![](https://i.imgur.com/Elo5CZq.png)

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

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

![](https://i.imgur.com/qe9OLqT.png)

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

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

![](https://i.imgur.com/EjV2UOG.png)

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

![](https://i.imgur.com/XoVvBTW.png)

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

![](https://i.imgur.com/cKKjxtf.png)

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

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

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

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

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

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

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

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

![](https://i.imgur.com/O0TGPPy.png)

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

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

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

![](https://i.imgur.com/u3EZPpO.png)

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

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

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

![](https://i.imgur.com/aDkg10g.png)


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

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

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

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

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

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

![](https://i.imgur.com/lNLujIW.png)

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

![](https://i.imgur.com/RsXG9gP.png)

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

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


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

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

```
systemctl poweroff
```

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

![](https://i.imgur.com/5oul9RD.png)

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

![](https://i.imgur.com/hbXJtVi.png)

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

![](https://i.imgur.com/5qwrKmG.png)


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

![](https://i.imgur.com/aDN8Gm4.png)

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

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

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

![](https://i.imgur.com/U95aukv.png)

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

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

И так, открываем 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
```

![](https://i.imgur.com/4A1rRVK.png)

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

```
zpool list
```

![](https://i.imgur.com/dewRQo7.png)

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

![](https://i.imgur.com/5dtti7z.png)

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


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

![](https://i.imgur.com/pYSNQ0S.png)

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

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

![](https://i.imgur.com/kD034n5.png)

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

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

![](https://i.imgur.com/9PDkgpk.png)

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


![](https://i.imgur.com/z6pvvGL.png)

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

![](https://i.imgur.com/Uufm3xJ.png)

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

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

![](https://i.imgur.com/ARDWj8x.png)

И на zfs2:

![](https://i.imgur.com/l5U2qtI.png)

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

Подключаемся по 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)