LINUX.ORG.RU
Форум — Admin  

ProxMox. Работа с кластером при умершей ноде.

 


0

3

Задача: В режиме «Репликация виртуальных машин» работают в кластере 2 ноды. На первой запущены виртуальные машины, на вторую по расписанию вносятся все изменения в заглушенные виртуальные машины. В случае гибели первой планировалось подключиться ко второй и запустить ВМ. Соответственно при гибели второй всё продолжало работать на первой.

Решение: Установил Proxmox Virtual Environment 7.2-4 на два компьютера, объединил в кластер в режиме «Репликация виртуальных машин». Делал по https://www.dmosk.ru/miniinstruktions.php?mini=proxmoxve-cluster#delete-node Сделал ZFS-pool, восстановил из бэкапа на первую ноду ВМ, дал команду репликации, по изменению занятого места увидел, что репликация действительно прошла. Т.е. всё работает при обеих включенных нодах.

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

Вставляю обратно сетевой провод и меня сразу пускает на веб-морду.

HELP!!!: Заложен ли такой функционал в кластере в режиме «Репликация виртуальных машин»? Если заложен, то в чём проблема, что не так я делаю? Если не заложен, то на кой нужна такая репликация?


2 ноды

не будет кворума при двух нодах и отказе одной из них. кластер при отвале одной погасит всё автоматически.

можно на «более надёжную» ноду веса добавить (по умолчанию у них равный), но лучше добавить третью ноду.

aol ★★★★★
()
Последнее исправление: aol (всего исправлений: 1)
Ответ на: комментарий от aol

Вы говорите о режиме «Отказоустойчивый кластер», но это иное, с отдельным общим хранилищем, с требованием минимум 3 нод и иным функционалом.

BDG
() автор топика
Ответ на: комментарий от aol

Кажется Вы правы. Видимо «Репликация виртуальных машин» подразумевается как дополнение к «Отказоустойчивый кластер». Жаль, счастье было так близко! Спасибо за помощь и пояснение про поведение при отключении ноды.

BDG
() автор топика
Ответ на: комментарий от BDG

Достаточно на второй ноде иметь Proxmox Backup Server, и него же делать инкрементальный бэкапы. При отказе одной ноды, увеличить Votes на живой ноде и запустить (или заранее сделать, чтобы кластер не умер при мертвой одной ноде)

ну либо: https://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster

mishki
()
Последнее исправление: mishki (всего исправлений: 2)

Кстати только сейчас пришло в голову решение подобных проблем.

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

AVL2 ★★★★★
()

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

Каким образом заведен пользователь? если через pam, то пускать должен в любом случае.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Нет, через веб-морду уже не залогиниться.

Как пишут разработчикик:

Аутентификация через графический интерфейс требует доступа к /etc/pve из-за ключей авторизации. Если им нужна ротация, необходим доступ. Это может работать в течение нескольких минут или даже часов после потери кворума, но нет гарантированного времени. Если вы используете TFA, ВСЕГДА требуется доступ к /etc/pve.

На практике, только через ssh и: 

pvecm expected 1

mishki
()
Ответ на: комментарий от AVL2

Пришло в голову решение подобных проблем. Ввести в кластер маленькую машинку чисто под кластерные цели.

Не, лучше без машинки. Это решение называется corosync-qdevice: QDevice daemon

corosync-qdevice is a daemon running on each node of a cluster. It provides a configured number of votes to the quorum subsystem based on a third-party arbitrator's decision. Its primary use is to allow a cluster to sustain more node failures than standard quorum rules allow. It is recommended for clusters with an even number of nodes and highly recommended for 2 node clusters.

mishki
()
Ответ на: комментарий от mishki

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

AVL2 ★★★★★
()
Admin