В связке Heartbeat+DRBD+iSCSI+KVM какая роль у iSCSI?

Функция искази — обеспечение гибкости. Тот метод, который я тебе рассказал и который приведен в топике, используется на промышленных системах, где кластер хранения и кластер исполнения виртуалок сделаны на отдельных группах машин. Функция искази (или просто скази, или фибры) в этом случае состоит в обеспечении связи таких кластеров.

В poor man's case (всего две-три машины) она дает не очень существенные преимущества, но все же. Та же гибкость. Можно перекидывать виртуалку и drbd primary + target независимо друг от друга (иногда бывает полезно). Плюс, существенно упрощается миграция — при непосредственном использовании drbd нужно успеть очень быстро переключить primary в момент окончания миграции, иначе гость словит кучу i/o errors.

Хотя, конечно, мне следовало сразу вспомнить простую вещь — ganeti. Самое то для организации кластера на двух машинах, именно так, как ты описал, без искази. За переключением primary следит сама. Правда, используя ее, ты почти ничему не научишься, но это уже зависит от задачи (иногда бывает задача научиться, а иногда нужно просто сделать, чтобы работало).

// P.S. По поводу промышленного метода, забыл сказать — еще на кластере хранения нужно сконфигурировать shared ip address, и на инициаторах прописывать именно его. Демоны искази обычно на адреса не биндятся, а слушают 0.0.0.0, так что с конфигами танцевать не надо.

Научиться и сделать. Естественно хочется самому сделать что бы понять как это изнутри функционирует без прослоек.

Как я понимаю, в моем случае iSCSI не даст ни большой выгоды?

Плюс, существенно упрощается миграция — при непосредственном использовании drbd нужно успеть очень быстро переключить primary в момент окончания миграции, иначе гость словит кучу i/o errors.

А разве в случае с искази не нужно такое переключение. Я наверное алгоритм твой не до понял.

Хотя, конечно, мне следовало сразу вспомнить простую вещь — ganeti. Самое то для организации кластера на двух машинах, именно так, как ты описал, без искази. За переключением primary следит сама.

Раз она следит, то и скрипт на bash тоже справиться, я так думаю. И действительно не хочется использовать что-то, у меня задача понять как это функционирует и построить простую рабочую систему. По моему мнению чем меньше элементов в системе тем она надежнее (ИМХО)

>Как я понимаю, в моем случае iSCSI не даст ни большой выгоды?

Если миграцию гонять не собираешься — тогда можно спокойно забить.

А разве в случае с искази не нужно такое переключение. Я наверное алгоритм твой не до понял.

Там можно переключать drbd независимо от того, где виртуальная машина. Если виртуалка не на primary хосте, данные просто будут ходить зигзагом — сначала по исказе на primary, потом в drbd-реплике на secondary. Никаких i/o errors, разве что проседание скорости. Но так как после окончания миграции можно и primary вместе с tgtd перекинуть, это ненадолго.

Вот без искази это время уже критично, так как вместо проседания производительности у гостя (а возможно, и у хоста) будут ошибки i/o (аналог отвалившегося шлейфа), что чревато паникой ядра и другими развлекательными мероприятиями.

Раз она следит, то и скрипт на bash тоже справиться, я так думаю.

Возможно. Советую поковырять потроха ganeti, вроде оно на скриптах.

http://te.to/~ts1/xen_cluster.html вот здесь статья из которой можно умозаключить что живая миграция primary/secondary вполне возможна.

Только не понятно назначение третьего диска DRBD?

И зачем vgchange -a y $LVM используется?

>http://te.to/~ts1/xen_cluster.html вот здесь статья из которой можно умозаключить что живая миграция primary/secondary вполне возможна.

Она там делается через multi-master mode. DRVTiny пытался так сделать — говорит, практически сразу после начала миграции все дохнет.
Возможно, у него просто был старый бажный drbd, или еще какая-нибудь фигня.

Только не понятно назначение третьего диска DRBD?

Я так понял, «шоб было». Просто дополнительный диск, никакого сакрального смысла.

И зачем vgchange -a y $LVM используется?

Автор почему-то юзает lvm поверх drbd-устройств, а не наоборот. Перед использованием lvm нужно активировать группы томов (сабжевая команда). Но до переключения в primary этого сделать нельзя, т.к. доступ к secondary drbd блокирует (и правильно).

Но вообще приемы работы с heartbeat, изложенные в этой статье, порядком устарели. Вместо конфигурирования через haresources (r1-style) сейчас обычно используется pacemaker, который, кстати, нормально поддерживает миграцию кластерных ресурсов (в r1-style это делалось только через костыли, вроде того, что был изложен в статье).

Я совсем в тупике. Мне сложно оценить полезность той или иной технологии пока я их не увидел в работе. Реализовывать каждый принцип я наверное физически не смогу ))). Помогите пожалуйста, определиться с тем каким образом строить кластер, вот требования к нему и характ-ки узлов:

Оба компьютера идентичны I7, RAID 0 SAS 15000, Ethernet Gb, 12Gb DDR3

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

Поначалу я использовал DRBD+OCFS2 но по объективным соображениям производительность такой системы будет ниже. Какой подход использовать. Учитывая что это мой первый опыт. И если можно какой нибудь пример (статью).

http://xgu.ru/wiki/xen/drbd/%D0%BC%D1%8B%D1%81%D0%BB%D0%B8#LVM_.D0.BF.D0.BE.D...

Вот еще вариант с миграцией DRBD P/S. Здесь тоже используют LVM поверх DRBD (vgcreate vg00 /dev/drbdX так наверное(только метаданные уже не похранить в этой VG)) , но тут объяснено зачем (пока правда трудно понять зачем ))))). По моему если разрешить allow-two-primaries в DRBD, при условии что диск принадлежит целиком одному только домену. То в момент миграции состояние primary/primary не должно вызвать какие либо ошибки даже если файловая система не кластерная. И, я конечно не уверен но миграция должна пройти гладко без i/o ошибок. Еще раз это мои догадки.

Из статей в сети об pacemaker подозреваю что он использует тот же самый механизм что и два предыдущих варианта. Иначе как бы он мигрировал, он же не использует кластерную фс. ИМХО

http://xgu.ru/wiki/xen-drbd Xen и KVM очень близки, я проанализировал код http://xgu.ru/download/xen-drbd-v0.1.tar.gz по управлению миграцией и увидел уже знакомый подход. Правда здесь не используется LVM.

На самом деле, вариантов куча. И все они, в общем, сводятся к одному и тому же. Принципиальный момент только один: используется ли дополнительная прослойка-crm (pacemaker, например), или нет. Фактически, на нижнем уровне все равно будет работать самописный скрипт, обеспечивающий запуск/остановку/миграцию виртуалок. Но crm сам следит (точнее, через кластерную шину, например, heartbeat) за работой кластера и поднимает виртуалку на резервной машине, если рабочая упадет. Без кластерного софта это нужно реализовывать самому.

В общем, могу рекомендовать два пути: либо просто взять ganeti, либо написать свой ocf-агент для pacemaker'а (например, взяв за основу http://hg.linux-ha.org/agents/file/a0679b7966e9/heartbeat/VirtualDomain и добавив туда управление drbd-дисками).