Отказоустойчивый кластер с виртуализацией на KVM

[maroshka]

Добрый день, коллеги.
Возможно, тема не новая, но толкового ничего в поиске не нашел.
Пришло время переводить свой парк серверов на виртуализацию, деньги как всегда украли предшественники. Попробовал KVM на отдельной машинке, в целом все устраивает. Proxmox интересно, но хочется повозиться, построить интересную систему самому, поднять скилл. Изучаю мир, на предмет виртуализации, отказоустойчивого псевдокластера. Есть толковые реализации на centos/REHL, но т.к. мы легких путей не ищем и больше любим deb подобные системы, то есть желание собрать подобие на ubuntu.

Хочу построить схему из 3х нод с KVM в режиме active. Имеем - 3 однотипных сервера - кабанчика HP DL165G7, оборудование не новое, но вполне боевое под ноды кластера/гипервизора, хардварные raid, по 2x300GB диска в зеркале для установки каждого гипервизора, FC адатеры для подключения к дисковой полке. Через FC будут презентоваться луны под разделы, где будут лежать гостевые системы, снепшоты. 2х1Gbit адаптера в lacp для менеджмента и общения гипервизоров и 2Gbit адаптера в lacp для выхода гостевых систем в мир/локалку.
- По сетевой части, все понятно, взаимодействие через libvirt, все было ранее протестировано, к гостевым машинам на отдельный lacp подаются trunk с пачкой vlan, и там на вланы прикручиваем бридж интерфейсы, которые презентуются гипервизору под гостевые машинки.
- FC луны монтируем через multipath, менеджер томов кластерный cLVM. Далее выбор кластерной файловой системы - КОЛЛЕГИ ТУТ НУЖЕН ВАШ СОВЕТ, кластерные ФС пока не тестировал, больших требований с суперскорости записи - нет, по описаниям пока остановился на GFS2. Рад буду услышать Ваше мнение, если кто реально занимался таким вопросом.
- Для работы кластера в active-active планирую использовать связку pacemaker(stonith имеющимся железом поддерживается) + corosync2 - кластеризация, кворум и т.п., это из того что почитал, возможно есть более правильные связки, если кто в курсе - ткните носом.
Управление - тут у меня боьше вопросов, в принципе, я пробовал vmm и web virt-manager и cli. Думаю поднять гостевую систему на кластере с web virt-manager там большинство тулз для управления kvm есть, меня устраивает и управлялка будет жить пока жив хоть один из гипервизоров. Есть ли что-то вебковое для управления кластеризацией или лучше настраивать из консоли?
При падении ноды гипервизора, перевод гостевых систем с ребутом приемлем, главное, чтобы гостевые системы поднялись на одной из живых нод.
Если кто-то строил подобное, буду признателен за совет или банально на указание ошибки при выборе компонентов. Как всегда времени на все не хватает, потому прошу совета. Спасибо. Если все будет норм, поделюсь опытом.

[alexxnight]

Если у Вас нет требования для гипервизора работы 24/7, то можно не делать кластер из серверов.
proxmox может решить Ваши задумки.
рекомендую посмотреть в сторону решения на proxmox кластера + NFS сервер. Если нужно создать отказоустойчивый NFS, то у них есть технология Ceph

[maroshka]

Спасибо за совет, но хочется построить виртуализацию самому, потому не proxmox и не esxi. У меня есть возможность использовать fibrechannel, потому на nfs и ceph с смотрю как на будущий проект построения openstack решений, а пока начать с более простого проект​а.
Неужели никто из читателей больше не задавался таким вопросом и на поднимал подобное?

[maroshka]

Закрываю тему, за отсутствием рекомендаций и интерсующихся.

[alexxnight]

[maroshka]

В одной из 5 верхних ссылок гугла была ссылка на эту тему форума, хотя я на нее подзабил.
Как я и говорил ранее т.к. помощи почти не последовало от слова совсем, мне пришлось все ковырять самому.
Чтобы не оставлять эту тему сосвем недосказанной, я как топикстартер решил логически закончить эту тему.
--- Что имелось в наличии---:
3 bare-metal сервера на AMD процессорах с подержкой виртуализации. 
---Собрана такая структура---:
3 ноды KVM в режиме кластера на основе pacemaker/corosync + fencing(STONITH) реализован через ipmi серверов.
Достут к общему хранилищу данных для всех 3х нод был собран через fiber channel с помощью dm-multipath.
Кластерная файловая система gfs2 работала поверх clvm, для блокировки доступа к память использовался модуль dlm как для gfs2 так и для clvm.
---Что необходимо отметить---:
Не хочу разводить хай, но распределенный (не говорю о связке 2х нод в виде ha на drbd, такой вид кластера я просто не тестировал и сказть точно как он будет работать не могу) кластер KVM на ubuntu лучше не делать или готовьтесь отлавливать кучу багов, что для продуктива крайне сомнительно. Самые неприятные глюки были связаны с отработкой кластерной связки на pacemaker/corosync в области отработки dlm файловой системы gfs2 и/или clvm. Иногда ноды тушили друг друга совсем по непонятным причинам, хотя кворум присутствовал. Да, кстати с не совсем корректным поведением работы кластера столкнулся не только я. Читая большое к-во разных источников, которые пробовали делать подобное, я прочитал не самую свежую статью СЕРГЕЯ УРУШКИНА в журнале Ситемный Администратор еще 2014 года, он там тоже столкнулся с не всегда адекватной отработкой кластера на ubuntu, но я решил попробовать собрать кластер на версии ubuntu 16.04 и проверить, может за 2 года что-то изменилось. Но увы...     
---Результат---:
Кластер на KVM из 3х нод я таки поднял но после массы грабель я перешел на centos (что кстати сэкономило мне массу времени) и потестировал его в продуктиве около полугода, правда нагрузки были не экстремальные, можно сказать ближе к средним. Такой кластер легко расширяется, новые ноды добавить очень просто, но необходимо помнить, что для нормальной работы кластерной файловой системы необходим кворум(большинство нод) иначе будет беда, можно потерять много данных, потому лучше всегда иметь нечетное к-во нод в кластере.
Также необходимо понимать что такая файловая система как gfs2 не является самой шустрой, приносит дополнительные накладные расходы по производительности а также имеет ограничение по к-ву нод в к-ве 16, но этого достаточно для малой и средней виртуализации. Можно попробовать ocfs2, но я ее не тестировал.
---Что не понравилось и что может вызвать проблемы при работе с кластером:---
1. fencing - не до конца корректно настроенный механизм отработки тушения аварийной ноды может принести много головной боли.
2. Управление гостевыми VM происходит через pacemaker, а создание гостевой VM или через GUI VMM или через какой нибуль web gui и требует переноса созданного конфига на pacemaker для отработки live migration, что конечно не является удобным.
3. Делегировать часть управления кластером для создания виртуалмашинки можно, но не удобно.
4. Уровень специалиста для управления такой структурой не может быть начальным, в отличие например от той же ESXI или от Proxmox.
5. Кластер живет пока живет связь между нодими по сети, на Hyper-V например есть кворум диск, что помогает при сетевой проблеме.
В остальном вроде как все не плохо, сейчас хочу еще попробовать Ovirt и opennebula/openstack.
Всем успехов.

[firerat]

Спасибо за информацию. Было интересно узнать и ОГРОМНОЕ спасибо за то, что спустя время, вернулись и закрыли тему, описав свой опыт. (а не как большинство ТС, бросающих свои темы без ответов).