Gluster 2x2 = LVM. Возможно ли?

ИМХО. Зачем колхозить block device поверх FS, если есть DRBD?

А Stonith обязателен для DRBD ?

Если тебе нужно распределённое блочное устройство, возьми Ceph и не парься. С Gluster'ом можно отгрести проблем.

В теории штука очень понравилась, вдогонку вопрос, ибо гугл внятного ответа не дал. А как в нём реализуется масштабируемость? Возможно ли просто подцепить ещё одну (две) ноды к кластеру и расширить хранилище?

Спасибо, опробуем. Был запланирован для тестов на эту неделю.

ceph на двух нодах? Нууу, с OSD, положим, вполне терпимо получится если исходить из дефотного CRUSH, а вот с с двумя мониторами получается засада. Нужна третья нода.

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

Для монитора много не нужно, всегда можно найти третью ноду.

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

Насколько я понял, Ceph в отказоустойчивом варианте выйдет несколько затратнее, но масштабируемость будет лучше. В то же время c DRBD возникнут проблемы при масштабировании. Верно?

Ceph в отказоустойчивом варианте выйдет несколько затратнее

Опиши, как ты пришёл к такому выводу.

Скорее всего, он посмотрел на «умолчательный» размер пула в три реплики. Но у сефа есть другие подводные камни - например, проседание I/O после временного отключения ноды. Мы научились с этим бороться, но там всё очень и очень больно, особенно если нагрузка на запись хоть сколь нибудь серьезная. На HDD вы получите просадку примерно в 30-50 раз для случая когда у вас временно отключался один узел из четырех.

проседание I/O после временного отключения ноды

С noout?

На HDD вы получите просадку примерно в 30-50 раз для случая когда у вас временно отключался один узел из четырех.

Вы что-то явно делали не так. Я такого не наблюдал.

Плохо наблюдали.

1. Размер объекта в образе «по умолчанию»

2. Нагрузка на запись равномерная примерно 500 writes/sec, блоками по 4K

3. время оффлайна узла - 10 минут (down_out по умолчанию 900 секунд)

4. размер образа примерно 2.5 терабайта

IOPS'ы можете снимать например fio.

3. время оффлайна узла - 10 минут (down_out по умолчанию 900 секунд)

Я в таких случаях noout ставил.

IOPS'ы можете снимать например fio.

Этот, как и любой другой бенчмарк для традиционных ФС, — неадекватен.

Именно как сказал Nastishka - по предложенным дефолтным решениям.

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

Этот, как и любой другой бенчмарк для традиционных ФС, — неадекватен.

Смелое утверждение. А производительность на запись <= 30 writes/sec «per host» по гигабитной сети при интенсивном recovery вас не смущает?

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

Если бы. Для rbd в ceph «дефолтные значения» - это такая штука, когда оно как бы «вроде бы даже вроде бы нормально работает», а отступления от дефолтных значений даже в самых вроде бы безобидных параметрах обычно караются жестокими багами в самый неожиданный момент. Сегфолтящиеся все вместе мониторы, улетание половины OSD'шек в down - или наоборот, неулетание оных в down когда это вроде бы ожидалось, возникновение misplace при включении nodown. Ух, это весело и всегда держит в тонусе.

P.S.: это не значит что ceph плохой. Он хорошо работает, пока ваш профиль использования близок к тому, на который ориентировались инктанковцы и редхатовцы. Но если нет... Если нет, то админ ceph'овского кластера вынужден будет очень, очень сильно прокачаться в траблшутинге.

по гигабитной сети

Кто ж так в здравом уме делает.