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

Задача по идее тривиальная

Это смотря с какой стороны смотреть. С точки зрения реализации - очень не тривиальная.

В какую сторону копать?

ЕМНИП такая тема тут уже поднималась, а то и не раз. Опять же ЕМНИП, остановились на том, что открытых Ънтерпрайзных решений пока нет. В той же теме упоминался Kemari Project.

Задумался не то написал: распорстраненная.

На кемари уже наткнулся, читаю.

Спасибо.

>This software is experimental and developing software.

Это немного не радует.

Во-первых, нужно независимое хранилище. Это может быть такая красивая коробочка с тремя буквами, либо еще один линуксовый кластер на базе DRBD или GlusterFS, например. Рекомендую, во избежание наращивания уровней абстракции, юзать блочное устройство с синхронизацией через DRBD и экспортом через iSCSI (это гораздо эффективнее, чем городить там файловую систему и держать на ней образы дисков).

Во-вторых, определись сразу: либо ты миришься с тем, что при падении ноды кластера у всех исполнявшихся на ней инстансов возникает эффект холодной перезагрузки (нажатия резета), либо используешь remus и терпишь жуткие тормоза, обусловленные непрерывной синхронизацией оперативки инстансов между нодами.
Кстати, kemari — это идеологический предок и бывший конкурент remus'а, не доживший до наших дней. А поддержка remus уже интегрирована в Xen 4.0.

Во остальном, если ты освоил хоть один нормальный кластер-манагер, задача действительно тривиальна.
// Рекомендую heartbeat + pacemaker, на их базе я такую задачу успешно решал.

ganeti - при падении одной из нод гости перезапускаются на второй ноде. Репликация выполняется по drbd.

Прежде всего, что за сервис?
Если он не fault-tolerance, то надо определить механизмы его поднятия на другой ноде, и вообще подумать, нужен ли кластер при таком раскладе

«Отказоустойчивый» пишется слитно. Вопрос не понятен.

ключевые слова: global fs, scalable services, shared addresses.

Всем спасибо, ушел гуглить по новым словам поиска.