Новая версия Ganeti 2.1.2

Используется в гугле далеко не повсеместно (только в одном из офисов вроде). Проект был актуален, когда libvirt еще не было, и не было кучи обвязок воруг libvirt, а сейчас Ganeti не нужен. Но то что продолжают его пилить - это хорошо.

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

>либвирт за собой пол гнома норовить втащить.

Советую вам немного покурить мануалы и разобраться в вопросе.

Либвирт — это библиотека и консольный демон. Опционально еще консольный клиент (virsh).

А полгнома тянет virt-manager — всего лишь один из фронтендов. Кстати, на серваках кластера он совершенно не нужен — это клиент, и его используют на десктопах, с которых производится управление.

>Проект был актуален, когда libvirt еще не было, и не было кучи обвязок воруг libvirt, а сейчас Ganeti не нужен. Но то что продолжают его пилить - это хорошо.

Во-во. Непонятно, на что они надеются в эпоху победившего либвирта.
Или это такой M$-way — принципиально плевать на стандарты?

libvirt уже умеет DRBD или LVM томами управлять?

LVM томами управлять точно умеет. Насчет DRBD не знаю.

Libvirt - кривое подделие. Сам RedHat его в своем Enterprise Virtualization не использует

Hober> Libvirt - кривое подделие. Сам RedHat его в своем Enterprise Virtualization не использует

Ja-ja. Сделай rpm -e libvirt и успехов тебе.

>libvirt уже умеет DRBD или LVM томами управлять?

Не надо пытаться сравнивать ganeti и libvirt, это некорректно.

libvirt — стандартный интерфейс управления виртуализацией.
ganeti — программное обеспечение, претендующее на управление виртуализацией, но не использующее стандартный интерфейс.

И да, libvirt умеет работать с пулами хранения, представленными в виде NFS-серверов, iSCSI-таргетов, групп томов LVM и блочных устройств. В последнем случае устройство может быть реплицировано по DRBD, но управление DRBD уже выходит за рамки управления виртуализацией. То же самое можно сказать и про обычный программный рейд.

А вот ganeti, емнип, не умеет отделять кластер хранения от кластера исполнения. Так что эту штуку целесообразно применять разве что когда нод не больше двух-трех.

Инетересно, каким таким образом libvirt создаёт идентичный логический том LVM хотя на двух нодах - под нужды DRBD-репликации? Пусть сам DRBD настраивать он не обязан, но предусмотреть необходимость кластерной LVM мог бы. Proxmox VE умеет это делать, а ваша убогая python'о-хреновина - нет. Не у всех ведь есть возможность NAS/SAN'ы покупать.

>Инетересно, каким таким образом libvirt создаёт идентичный логический том LVM хотя на двух нодах - под нужды DRBD-репликации?

Создание LV под DRBD-разделы уже никак к виртуализации не относится. К ней относится разве что результирующее устройство /dev/drbdX, с которым могут работать виртуальные машины и которое libvirt может использовать в качестве пула.

но предусмотреть необходимость кластерной LVM мог бы

А зачем вам распределенный менеджер блокировок в системе управления логическими томами? Вы туда уже GFS или OCFS засунули? Это к виртуализации тоже не относится, кстати.

а ваша убогая python'о-хреновина - нет

Да, вертолет не умеет копать траншеи. Только вот если из-за этого вы его считаете убогой хреновиной, то проблема скорее всего у вас в голове.

Угу-угу, а вы дико умный, как я погляжу! Давайте расскажите своей любимой libvirt, что блочное устройство /dev/drbd1 на двух нодах - это одно и то же, а ещё будет прикольно посмотреть, как вы с помощью libvirt сделаете live migration, если при этом нужно переключать состояние drbd-зеркала из Secondary/Primary сначала в состояние Primary/Primary, а потом Primary/Secondary. Или вы про DRBD вообще не слышали или просто не понимаете, как это работает, если говорите про какое-то результирующее устройство?
Так я вам поведаю страшную правду: это не все виртуалки сваливаются на одно устройство /dev/drbdX, а каждый виртуальный диск - это одно устройство /dev/drbdX.

>Давайте расскажите своей любимой libvirt, что блочное устройство /dev/drbd1 на двух нодах - это одно и то же

Заведомо некорректный подход, так как live-миграция требует использования Primary-Primary, и ФС гостя при таких раскладах может запросто накрыться.

а ещё будет прикольно посмотреть, как вы с помощью libvirt сделаете live migration, если при этом нужно переключать состояние drbd-зеркала из Secondary/Primary сначала в состояние Primary/Primary, а потом Primary/Secondary.

Спасибо, посмеялся.
Когда нужно делать live-миграцию, я просто экспортирую DRBD-устройство через iSCSI, и миграция спокойно проходит без использования Primary-Primary. Этот режим какбэ для другого придуман. В частности, для использования с кластерными ФС. А тому гению, который придумал использовать его для живой миграции, нужно разбить нос.

Так я вам поведаю страшную правду: это не все виртуалки сваливаются на одно устройство /dev/drbdX, а каждый виртуальный диск - это одно устройство /dev/drbdX.

Открою страшную тайну: любое блочное устройство может быть пулом либвирта. На этом пуле можно создавать тома и выделять их различным машинам. В простейшем случае получится то, что вы описали: один пул — один том — одна машина.

>Сам RedHat его в своем Enterprise Virtualization не использует

А ещё, когда я в последний раз его смотрел, там web-интерфейс был под Microsoft IIS заточен. Так что отсутствие libvirt'а - далеко не самая большая проблема RHEV.

Почему всё так? Да просто потому, что RH купила продукт уже готовым, причём купила не так давно. Вот и продают «AS IS», параллельно допиливая будущие версии.

Всё хорошо, но экспортирование по iSCSI и в любом случае - переключение хотя бы Primary/Secondary, Secondary/Primary - вы вручную делаете? libvirt этого не умеет. И да, я понятия не миею, как это вы так лихо по iSCSI экспортируете блочное устройство, чтобы оно было доступно по тому же пути, что и на исходной системе. А насчёт Primary/Primary - да, это такое глюкалово невероятное, из-за переключения в которое слетает весь процесс lm «на раз»: split-brain в режиме Primary/Primary - дело обычное, а вменяемой процедуры воссатановления из него (как у glusterfs autohealing) нет.

>переключение хотя бы Primary/Secondary, Secondary/Primary - вы вручную делаете?

Строго говоря, не вручную. В простейшем случае через service heartbeat stop/start, в более сложных вариантах используется самописный кластерный софт. Само собой, виртуалками этот софт рулит через libvirt, но управление DRBD идет отдельно.

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

libvirt этого не умеет

Ему это и не надо. Он виртуалками рулит, а не стораджами.

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

Лехко :) В /dev/disk/by-path/ iSCSI-девайсы обозначены именами, которые зависят только от айпишника и порта таргета, и остаются неизменными на всех инициаторах. Либвирт это знает и использует. Ему достаточно указать только адрес и порт, он сам запустит инициатора и создаст пул, тома (LUN'ы) которого можно раздавать виртуалкам в качестве дисков.

libvirt это все-таки надстройка над KVM. лучша гибкость запуск КВМ напрямую из shell или из скрипов.

Счас только закочил установку кластера (pacemaker+corosync+drbd+kvm ) все работает на ура.

пробовал ocf virtualdomain ( требует liibvrt ) но очень не понравилось - то одно то другое. в результате взял KVM ocf прикрутил к своим нуждам и все теперь работает как часы.

>libvirt это все-таки надстройка над KVM.

libvirt — это API управления виртуализацией, и она поддерживает не только KVM, но и Xen, QEMU, OpenVZ, Linux Containers, User-mode Linux, VirtualBox и VMWare ESXi/GSX. И все это — через единый интерфейс, унифицирующий все операции.

лучша гибкость запуск КВМ напрямую из shell или из скрипов.

Позвольте полюбопытствовать, а как вы из shell или из скриптов запускаете миграцию, подключаете и отключаете устройства? Это делается через консоль QEMU, а она, емнип, слабо дружит с шеллом и скриптами.

Вообще такие наколеночные решения, как ваше, или ganeti, могут быть вполне неплохими для своего класса задач — объединить в режиме HA пару десктопных железок. Но при попытке применить такой подход для более-менее масштабируемых систем вылезает феерический гемор.

пробовал ocf virtualdomain ( требует liibvrt ) но очень не понравилось - то одно то другое.

Боюсь, проблема там была совсем не в либвирте.

я просто экспортирую DRBD-устройство через iSCSI, и миграция спокойно проходит без использования Primary-Primary

А всё-таки, как это так? То есть вы /dev/drbdX с исходной ноды мапите на целевую (куда мигрируем) и пишите на устройство... /dev/sdX? Ведь имена устройств должны же совпадать на исходной и целевой системах, насколько я знаю.

Я ещё получается, что вы два раза гоняете данные - сначала с целевой ноды на исходную по iSCSI, а затем получаете их же обратно репликой DRBD?

>А зачем вам распределенный менеджер блокировок в системе управления логическими томами?

Чтобы при создании тома на одной ноде точно такое же создавался на второй. Нужно, чтобы логический том сделать /dev/drbdX'ом и его уже использовать как диск виртуальной машины.

>А всё-таки, как это так? То есть вы /dev/drbdX с исходной ноды мапите на целевую (куда мигрируем) и пишите на устройство... /dev/sdX? Ведь имена устройств должны же совпадать на исходной и целевой системах, насколько я знаю.

Достаточно везде использовать /dev/disk/by-path/...

Я ещё получается, что вы два раза гоняете данные - сначала с целевой ноды на исходную по iSCSI, а затем получаете их же обратно репликой DRBD?

Только в том случае, если мастером является не та нода, на которой крутится виртуалка. Ситуация не вполне штатная, но допустимая.

Но с точки зрения надежности и распределения нагрузки кластера хранения и исполнения лучше разделять.

Чтобы при создании тома на одной ноде точно такое же создавался на второй. Нужно, чтобы логический том сделать /dev/drbdX'ом и его уже использовать как диск виртуальной машины.

Это вопрос конфигурирования drbd и LVM. DLM такими вещами не занимается.

>Достаточно везде использовать /dev/disk/by-path/...
Всё равно не понимаю :( Пожалуйста, можно конкретный пример?
В смысле, как называется устройство на исходной ноде и на целевой, и почему пути к ним просто обязаны совпасть?
У меня конфигурация такая, что кроме двух серверов нету больше ничего, к сожалению.

Пример:
/dev/disk/by-path/ip-10.128.0.67:3260-iscsi-iqn.2008-02.su.kangran.gallium:rdisk0205-lun-1

Этот путь будет работать на всех нодах, где инициатор сконфигурирован для данного таргета (10.128.0.67:3260 IQN iqn.2008-02.su.kangran.gallium:rdisk0205, LUN 1).

Читал отзывы использующего его админа.
Судя по его отзывам - гораздо лучше чем libvirt.

>Читал отзывы использующего его админа.

Судя по его отзывам - гораздо лучше чем libvirt.

Наверное, этот админ никогда не видел либвирта, иначе он бы не стал сравнивать ежа с ужом. «Emacs лучше, чем glibc» и все такое.

Интересно, а может быть таргет с инициатором на одной ноде? Я как-то пробовал, получил таймаут соединения, но там есть какие-то хитрые особенности в iscsid с привязками к интерфейсу. Хотя на localhost-то это не должно влиять, я полагаю...

Мне libvirt не нравится преимущественно своей питоновостью. Питновые приложения мало того, что медленные, так они ещё и нормально работают до первого экспешна, а дальше - почему-то у программистов на питон не принято писать в логи и хоть как-то обрабатывать ошибки, - получается длинный тошнотворного вида стек-трейс вызова функций, что с точки зрения конечного пользователя иначе как откровенным издевательством не назовёшь. Сравните с тем, как падает, например, X.org, написанный на C (запись в логи+ вывод подробных сообщений о конкретной ошибке)

>Интересно, а может быть таргет с инициатором на одной ноде?

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

почему-то у программистов на питон не принято писать в логи и хоть как-то обрабатывать ошибки

У кого как. Я обычно в своих скриптах все возможные исключения перехватываю и соответствующие маты на stderr направляю :)

получается длинный тошнотворного вида стек-трейс вызова функций, что с точки зрения конечного пользователя

... позволяет легко найти нужную функцию и вставить в нее отладочные вызовы ;)

>... позволяет легко найти нужную функцию и вставить в нее отладочные вызовы ;)

Угу, я бы с удвольствием понавставлял их в yum, который как-то у меня сам себя неправильно обновил :)