high availability, oVirt

Ну судя по этому и первым мыслям, необходимо саму систему управления дублировать. Но уже не используя oVitr, а с использованием pacemaker, к примеру. Ну это как-то... городить еще один HA на других технологиях, для системы, которая так же управляет HA.

upd.: Я не знаком с обсуждаемым софтом, возможно если дождаться пользователей oVirt можно будет услышать дельные советы. А за темой послежу...

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

42. «Новая версия системы управления инфраструктурой виртуализаци...»

Ну так-то да, НА поверх НА :-)

Ну так-то да, НА поверх НА :-)

not production

Коллеги, не работал с oVirt, но я бы решил проблему методом установки самого oVirt в виртуалке. Т.к. сторадж один - то при падении физического node01, на котором крутится виртуалка с oVirt - заходим на node02 и руками запускаем машинку с oVirt. Не? Можно и скрипт для перезапуска прибамбахать, но это отдельная тема.

пока те кто не знают, но мнение имеют, брызжут слюнями, люди работают: http://www.ovirt.org/Features/Self_Hosted_Engine

более простой подход, без автоматизации - держать еще одну шару NFS или LUN на котором сидит VM с engine, и запускать руками при падении хоста. либвирт на хостах ovirt можно и руками гонять.

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

ну и еще насчет «not production»: ovirt - разрабатывается как офигенно масштабируемая система, на данный момент официально заявлена поддежка до 200 хостов в одном кластере, и это просто потому что больше хостов не нашлось, у тестировщиков. при таком раскладе, две простеньких машинке в кластере - фигня. напомню - кластер это только часть ДЦ, и их может быть не одна сотня.

короче те кто говорит not production скорее всего просто никогда не видели ничего крупнее, и вряд ли увидят. А те кто понимает, спокойно используют ovirt/rhev уже не один год

А те кто понимает, спокойно используют ovirt/rhev уже не один год

Я так понял, вы используете oVirt в продакшене - скажите, а насколько там реализованы НА (имею ввиду не живую миграцию, а автоперезапуск при падении физ хоста), DRS?

P.S. подбираю замену vmware sphere для дальнейшего развития ДЦ ...

в продакшене я использую RHEV. но не суть, HA реализован с первых версий - если хост падает, он получает фенс, и ВМ перезапускаются на других хостах. DRS там нет, его вообще нигде нет кроме vmware. в овирт есть load balancing и квоты, которые можно настраивать. если хост загружен сильнее чем выставлено в политике балансировки кластера, самая «легкая» ВМ на нем переносится на другой хост, и так пока процент нагрузки не упадет ниже заданной границы.

Пасиба, пошел курить маны, поднимать тестовый oVirt.

RHEV, кроме стабильности, сильно отличается от oVirt? И смогу ли я без особых плясок с бубном в дальнейшем перейти на RHEV?

Желаю дальнейших успехов

Тебе такой продакшн и не снился даже. Сходи, почитай про гео-кластер что-ли.

Благодарю за заботу!

В RHEV 3.3 обещают http://rhsummit.files.wordpress.com/2013/06/cathrow_thu_450_rhev.pdf

'Hosted Engine' – self hosting RHEV-M as highly available VM

отличия обычно в фичерах - RHEV всегда немного позади, туда не попадают необкатанные, сырые фичи.

Кроме того, так как RHEV ставится в подконтрольный разработчикам дистр, установка и рутинная работа обычно очень просты и сюрприсов не приносят. с установкой овирт зачастую приходится помучиться потому что федора и даже центос - не RHEL и конфликты с другим софтом могут иметь место

переход, насколько я знаю, не запланирован в штатном порядке. То есть можно экспортировать все ВМ на NFS хранилку, и импортировать в RHEV, но это долго и даунтайм будет изрядный, в зависимости от размеров ВМ

молодцы, не бросили мой проект, продолжают толкать :)

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

С кем честь имею?

Тему придумал: на нодах поднять glusterfs, вынести на неё базу postgresql. Так же на нодах поставить engine-ovirt и выполнить первоначальную инициализацию (engine-setup). Ну и все storage для Datacenter'а вынести на полку.

--- Что скажете?

--- Что скажете?

Как то сложно это, что мешает engine-ovirt с постгре поставить прямо на виртуалке?

Если дисковая полка умрет, то будет не очень хорошо :-)

если она умрёт - то по-любому будет плохо и ничего работать не будет.

Ну тада надо еще городить либо clasterfs, либо HA сторадж.

а с чего ей умирать если на ней рейд, два контроллера и несколько б/п?

если она умрёт - то по-любому будет плохо и ничего работать не будет.

Есть вторая. Полное зеркало.

Ну тада надо еще городить либо clasterfs, либо HA сторадж.

Glusterfs. На ней БД postgresql. Как доделаю, отпишу что как :-)

а с чего ей умирать если на ней рейд, два контроллера и несколько б/п?

Всякое бывает...

Тут резерв на «сгорело здания»

Если есть вторая, и уровень паранойи на отметке «а если упадет бомба» то это немного другой сценарий, называется DR. в овирте это делается очень просто - реплицируем СХД, держим engine в виртуалке, которую точно так же реплицируем (обычно отдельный LUN на той же СХД), и при падении сервисов, все поднимаем в другом месте. Что, кстати, не отменяет надобности в бекапах, так как если какая то хрень накосячится, то косяк будет реплицирован

Решили остановиться на Glusterfs. На тестах (выключение одной железки во время записи) показало удовлетворительный результат :-) После включения железки файл появился.

Так что, всем спасибо :-)

казалось бы, при чем здесь «полки»