Self-hosted engine. За и против.

Я малость потыкал в вопрос, особенно ovirt, и у меня сложилось весьма стойкое впечатление, что ovirt использовать не стоит, это тупо как федора для редхата. - То есть все глюки отлавливаются там основные... + ovirt пишет свой велосипед полностью. Без libvirt. Всё же ПОКА я считаю libvirt - это мейнстрим в опенсорсе, на нём вроде и опенстек построен, и много чего другого.

А вот связка kvm+libvirt - мне нравится больше.

ovirt настойчиво хочет общего хранилища, а его покупать смысла не много. За эти деньги можно хоститься вечно в ДЦ. Но опять-же тут всё от задач зависит. По мне, так: kvm+libvirt+веб морда+zfs+ansible - то что надо для нищих. :)

И да: rpm based у меня вызывает рвоту...

плюс - не нужно лишних железяк. минус - занимает ресурсы на боевых гипервизорах и пока что ограничен только NFS (хотя как раз сейчас на fosdem показывали iscsi)

все зависит от проекта, если у меня мелкая установка с маленьким количеством железа, надо использовать SHE. если установка крупная, то можно поставить отдельный кластер только для engine. Опять же, размер установки еще и диктует требуемое кол-во ресурсов под engine, а там как-никак две бд и jboss. так что на несколько тысяч хостов я бы все таки поставил отдельные серверы только для engine, возможно даже с отдельным кластером под postgres.

Соображения, кстати, ничем не отличаются от аналогичных рассчетов при планировании vsphere

Я малость потыкал в вопрос, особенно ovirt

оно и видно что малость.

тупо как федора для редхата. - То есть все глюки отлавливаются там основные

чего? да, это апстрим, как и федора, но со стабильностью там намного лучше - хосты ведь el6-el7 а не обязательно федора.

ovirt пишет свой велосипед полностью. Без libvirt

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

ovirt настойчиво хочет общего хранилища, а его покупать смысла не много

ничего что там интегрирован gluster, и можно использовать локальные диски хостов?

что же касается смысла покупки, то вы это расскажите дуракам которые хранилища все таки покупают под vsphere, xen и да, openstack тоже.

За эти деньги можно хоститься вечно в ДЦ

овирт - это система виртуализации уровня датацентра. где еще его держать кроме как в датацентре?

По мне, так: kvm+libvirt+веб морда+zfs+ansible - то что надо для нищих. :)

ну так ovirt не рассчитан на нищих, для них самое то - windows sbs

И да: rpm based у меня вызывает рвоту...

бедняжко...

Приходишь и спрашиваешь: "Как лопатой пользоваться правильно?". Нет, блин, прибегает какой-нибудь далдон и советует пользоваться ложкой.

А что насчет использования SHE как резерва для отдельной машины?

не пойдет. SHE как VM, бежит с имиджа на центральном сторадже. а standalone сервер пользуется собственным стореджем. BFS тут тоже не проканает.

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

делаю бекап engine каждый час, сливаю в отдельную VM на полном автомате. Если основной engine сдохнет, я подниму его из уже развернутого бекапа на VM за несколько минут

Вот кстати о таком варианте я тоже думал. Можешь поподробнее рассказать?

все очень просто - есть утилита engine-backup, засунул ее в крон, и сбрасываю получающийся файл на готовую машинку на которой уже развернут но не активизирован голый engine

и все потому что лопату видел издалека и уверен что копать она не может

В таком виде и я знаю)
А виртуалку надо разворачивать также как и в случае использования SHE? Или это обычная VM? В каком виде нужно держать VM для бэкапа дабы максимально быстро развернуться?

нет, просто виртуалка. у меня она для надежности на отдельном хосте, но в принципе можно держать такую (или такие) и под овиртом. главное помнить что когда падает engine пропадает мониторинг и оркестрация а не уже работающие хосты и вм. в принципе вполне реально просто починить engine и/или восстановить бекап

То есть в данном случае нужно разворачивать не SHE, а standalone, но внутри VM?

ну да, просто машинка готовая принять бекап.

Упал standalone. Развернули бэкап внутри VM. А что там относительно мелких вещей типа прописанного на гипервизовах FQDN для engine? Меняем в DNS? Еще подводные камни в таком решении есть?

на гипервизорах ничего не прописано, все прописано в engine. главное ключи не потерять, хотя можно ssl вообще отключить

вообще, связь всегда идет от engine к хостам

Ага, спасибо.

Engine резервируется на VM, готовую принять бэкап, ноды резервируются другими нодами. А что есть для резервирования стораджа? Ну или хотя бы для быстрого развертывания из бэкапа?

gluster, мне кажется ещё более страшнее пользовать, чем zfs. :) Не..?

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

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

А так, в целом, я понял, что нифига не понял вопроса... Я думал, что кернелпаник спрашивает про выбор системы виртуализации, а он спрашивает про бекап главной ноды в ovirt. Так что я не прав. Да.

Сори. Я не понял твой вопрос. Я решил, что под: self-hosted engine ты понимаешь систему управления виртуализацией. Так что, да. Признаюсь. Затупил.

Кстати, а серьёзно, бывают в природе большие инсталяции ovirt? Там новые версии выходят столь часто, что... Ух...

Я в целом конечно думаю, что выбрать, из виртуализации, на 30-50 машин, каждая от 3 до 20 гб. озу. С отдельными железками, в разных помещениях (то есть быстрой сети не будет). Живая миграция - будет большим плюсом. HA не нужно. - Посмотрел на Ovirt, посмотрел что там часто обновления весьма выходят, понял, что RHEL на нём строит платное решение. И подумал, что ставить: gluster (на медленной сети!), CentOS, oVirt - наверное не самое лучшее решение... Я так понимаю, что ты более плотно его используешь. Что бы ты сказал мне в этом плане?

это зависит от стореджа. у вас какой запланирован?

gluster, мне кажется ещё более страшнее пользовать, чем zfs. :) Не..?

на линуксе? не.

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

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

А так, в целом, я понял, что нифига не понял вопроса... Я думал, что кернелпаник спрашивает про выбор системы виртуализации, а он спрашивает про бекап главной ноды в ovirt. Так что я не прав. Да.

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

Кстати, а серьёзно, бывают в природе большие инсталяции ovirt? Там новые версии выходят столь часто, что... Ух...

именно овирт а не RHEV я видел на 380 хостов, дело было два года назад, с тех пор могло стать больше

Я в целом конечно думаю, что выбрать, из виртуализации, на 30-50 машин, каждая от 3 до 20 гб. озу. С отдельными железками, в разных помещениях (то есть быстрой сети не будет). Живая миграция - будет большим плюсом. HA не нужно. - Посмотрел на Ovirt, посмотрел что там часто обновления весьма выходят, понял, что RHEL на нём строит платное решение. И подумал, что ставить: gluster (на медленной сети!), CentOS, oVirt - наверное не самое лучшее решение... Я так понимаю, что ты более плотно его используешь. Что бы ты сказал мне в этом плане?

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

Согласен. Толково в целом ты отписал мне. Про libvirt - где-то на оф. документации написано, что оно использует свой демон, и этот демон напрямую работает с kvm, без libvirtd. - Так что... Всё же, тут я могу быть прав, но в целом, это конечно может и не играть решающую роль.

Извините меня все. - Уматываю из треда. :)

Про libvirt - где-то на оф. документации написано, что оно использует свой демон, и этот демон напрямую работает с kvm, без libvirtd.

в документации oVirt такого не было. в старых доках по RHEV 2.x это было, но ситуация устарела уже 4 года как

демон там все еще есть (vdsmd) но он управляет libvirtd на каждом из хостов. заодно благодаря этой прослойке между libvirt и vdsm есть возможность имплементировать vdsm-hooks, что позволяет делать очень прикольные штуки

Дисковая полка с FC.

Raid на самой полке и репликация на ещё одну.

И еще один вопрос) Я правильно понимаю, что oVirt нынче умеет живую миграцию между стораджами? Могу я, например, без простоя мигрировать с NFS-стораджа с qcow2-имеджами на блочное хранилище и наоборот?

демон там все еще есть (vdsmd) но он управляет libvirtd на каждом из хостов. заодно благодаря этой прослойке между libvirt и vdsm есть возможность имплементировать vdsm-hooks, что позволяет делать очень прикольные штуки

Спасибо! Я был полностью не прав. :)

позволяет делать очень прикольные штуки

Какие например?

Могу я, например, без простоя мигрировать с NFS-стораджа с qcow2-имеджами на блочное хранилище и наоборот?

Миграция с NFS в Gluster и обратно работает без проблем на работающей вируталке. iSCSI не пробовал.

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

Можешь ткнуть в доки по этой теме?

http://www.ovirt.org/VDSM-Hooks

алгоритм такой:

1. бд содержит информацию о ВМ, при запуске, engine собирает эту информацию, выбирает хост и передает задачу запустить ВМ туда

2. хост принимает инфу, получает доступ к нужным стореджам, формирует из инфы domxml и передает его в libvirt

на этом этапе идет обработка vdsm-hook который называется before_vm_start. Тут я моу просто выполнить любой код, например скинуть в отдельный мониторинг сообщение о том что запускаю VM, или изменить domxml до того как он попадет в libvirt. Таким образом можно использовать фичеры libvirt которые еще не реализованы в ovirt.

другие хуки вставлены в другие места - before_vm_migrate, after_vm_migrate, after_vm_stop и т.д. более серьезные хуки требуют применения в нескольких местах, в каталоге можно найти примеры. механизм на самом деле очень мощный

http://www.ovirt.org/Features/Design/StorageLiveMigration

Развернул на домашнем сервере 3.5.1 в режиме All In One. Всплыла пара вопросов:

1. Можно ли создать сеть, не привязанную к физическим сетевым устройствам?

2. Можно ли смонтировать каталог с локальной ФС хоста внутрь VM?

Понятно, что это отменяет миграцию, но мигрировать мне и не надо - все равно некуда.

1. Можно ли создать сеть, не привязанную к физическим сетевым устройствам?

libvirt NAT? можно, но через хуки. штатные logical networks это фактически мосты с тем же названием на хостах

2. Можно ли смонтировать каталог с локальной ФС хоста внутрь VM?

поднять NFS или самбу можно. честно говоря не знаю поддерживает ли это libvirt, если да то опять же можно намалевать хук

вообще all in one это жуткий костыль, ovirt не для такого был сделан

libvirt NAT? можно, но через хуки. штатные logical networks это фактически мосты с тем же названием на хостах

Не обязательно NAT, больше routed-сети интересуют. А то, что логические сети - это мосты ясно и так, потому и спрашиваю.

поднять NFS или самбу можно. честно говоря не знаю поддерживает ли это libvirt

Я в virt-manager видел возможность монтирования файловой системы внутрь VM, но она не поддерживается. Интересно, что это такое.

вообще all in one это жуткий костыль, ovirt не для такого был сделан

Ну я бы так не сказал. Есть конечно мелкие косяки, но на домашнем сервере вполне неплохо. А в продакшене, если есть задача отмасштабироваться от одного хоста с десятью виртуалками сегодня до десятка хостов с десятками виртуалок в будущем, то имхо all in one вполне можно использовать как отправную точку.

больше routed-сети интересуют

routed сети могут и через мосты работать. или ты про overlay?

Я в virt-manager видел возможность монтирования файловой системы внутрь VM, но она не поддерживается. Интересно, что это такое.

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

Ну я бы так не сказал. Есть конечно мелкие косяки, но на домашнем сервере вполне неплохо. А в продакшене, если есть задача отмасштабироваться от одного хоста с десятью виртуалками сегодня до десятка хостов с десятками виртуалок в будущем, то имхо all in one вполне можно использовать как отправную точку.

с масштабированием там несомненно все отлично, но если есть планы, я бы изначально начинал с SHE а не с AIO.

SHE на одном хосте - это как-то очень больно. Или я не до конца разобрался с этим.

не так больно если планируется расширение. если не планируется, то оно конечно не особо нужно