Дано:
Серверы, каждый с собственным ZFS хранилищем - 2 шт.
Задача:
Обеспечить минимальную отказоустойчивость в случае поломки одного из серверов.
Собственно, создан кластер, в него добавлены обе ноды.
Единственное, что я пока нашел - делать репликации работающих ВМ с ноды №1 на ноду №2 и в случае отказа ноды №1 - вручную создавать ВМ из репликаций на ноде №2.
Есть ли более удобный и "ленивый" способ?
Если нет, тогда второй вопрос.
Каким образом из образа диска (репликации) создать ВМ в Proxmox?
Мне в голову приходит только следующий вариант:
Создать новую виртуальную машину с подходящими характеристиками, и не запуская её заменить имеющийся диск на
репликацию вручную.
Это правильный путь? Есть ли способ удобнее?
Для кворума нужно минимум 3 хоста? Создайте на каждом Proxmox-е по простейшей машине, установите туда... не помню как оно называется, короче участника кворума. Вуаля, у вас 4 голосующих хоста. Интересно, сработает?
Пума Тайланд, стоп, мы же про кластер говорим? Про два отдельных Proxmox хоста, которые объединили в кластер, да? А кластер - это и репликация между нодами из коробки, и HA между ними же, и... и... и воооот сколько всего!
1- репликация силами zfs хранит "опасность" не будет консистентности данных, особенно критично для БД
2- да кластера надо минимум 3 ноды, 3я создаётся через арбитра, если нет физической машины
3- более удобного способа чем вы описали для переподнятия реплицированной машины нет(или я не знаю), при падении одного сервера просто идёте /etc/pve/nodes/ и переносите конфиг vm с упавшего сервера на тот куда реплицировалась vm, кстати репликация автоматически начнёт работать в обратную сторону при поднятии упавшего сервера
4- для совсем красивой реализации нужен HA и общее хранилище, но это совсем другая история
Андрей, в кластере ничего вручную переносить не надо, репликация и HA есть прямо в web-интерфейсе, вы чего? Настраиваете - и полетели, автомиграция на живые ноды - прямо из коробки. Ещё и реплицируйся хоть каждую минуту, никто не запрещает. И общее хранилище НЕ требуется, хватает rpool-а самой ноды, в него всё и реплицируется.
Вот репликация БД - это да, есть вероятность... Ну а какие альтернативы?
Андрей, что вы мне рассказываете? В кластере контейнеры реплицируются из rpool-a одной кластерной ноды прямо в rpool другой кластерной ноды. У VM-ов другой способ хранения, но принцип тот-же.
Потом в HA просто выставляешь список на какой из нод кластера можно запускать контейнер/VM в случае смерти работавшей ноды, и всё. Виртуалка прямо в этом же rpool-е и запустится.
AUser0, что могут? реплицировать vm, могут, только это не HA, я кстати не думал в рамках как вы сказали, что в HA добавить vm которая реплицируется силами zfs, проверил- ребутнул сервер где она была и........на другой машине она сама не переподнялась, это именно то, что я писал в первом посте, что конфиг нужно перенести руками, при полноценном HA, когда vm лежит на общем хранилище, прокс это делает сам.
Принципиальное отличие HA от репликации, это сохранение консистенции данных внутри vm, репликация в zfs НЕ идёт непрерывно, а стартует по крону и следовательно у вас может создаться ситуация, когда данные в исходную машину записаны и еще не среплицированны в её копию, в этот момент исходная падает и вы поднимаете реплику, где эти данные отсутствуют, во многих местах это может быть очень критично, при полноценном HA у вас такой ситуации возникнуть не может
Андрей, а, ну да, совсем-совсем канонического HA, с восстановлением содержимого памяти в новозапущенной виртуалке - угу, этого без общего хранилища нет.
Но часть сервисов запускать можно, пусть с небольшим перерывом на запуск, но они будут онлайн. И автозапуск контейнеров на работающей ноде - вполне доказанный факт, и используется.
Пока проверил такой вариант:
На ноде 1 работает VM100 и регулярно реплицируется на ноду 2.
На ноде 2 создана VM200 с параметрами "железа", аналогичным VM100.
В настройках ноды 2 /etc/pve/qemu-server/200.conf отредактирована строка, в которой образ указан образ диска VM100 (который каждые 15 минут реплицируется с ноды 1). VM200 выключена.
Если отваливается нода 1, то руками запускается VM200 с уже отредактированным конфигом.
Я проверил - работает, но после имитации сбоя VM100, VM200 запустилась с ошибками файловой системы. Исправил запустилось.
Но, если честно, не внушает уверенности эта схема.
Настроить регулярное штатное резервное копирование на соседние ноды (#1->#2; #2>#1) в случае падения восстановить из бекапа на оставшуюся ноду штатным механизмом.
Почитать и заморочиться с DRBD, Ceph, GlusterFS
В любом случае заранее почитать про команду "pvecm expected 1"
