LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


2

1

Всем доброго времени суток. Появилась мысль о создании распределённого хранилища дисков для виртуалок. Наибольший интерес вызвал GlusterFS, на тестовой площадке показал себя весьма приятно. Возник вопрос: а возможно ли реализовать с его помощью хранилище, скажем из 2 страйпов + 2 реплики этих страйпов таким образом, чтобы при подключении рабочих нод к этому хранилищу на каждой ноде была доступна группа томов LVM?


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

post-factum ★★★★★ ()
Ответ на: комментарий от router

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

Hanuken ()
Ответ на: комментарий от post-factum

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

Hanuken ()
Ответ на: комментарий от post-factum

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

Nastishka ★★★★★ ()

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

Deleted ()
Ответ на: комментарий от Nastishka

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

post-factum ★★★★★ ()

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

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

Hanuken ()
Ответ на: комментарий от post-factum

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

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

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

С noout?

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

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

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

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

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

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

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

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

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

post-factum ★★★★★ ()
Последнее исправление: post-factum (всего исправлений: 1 )
Ответ на: комментарий от post-factum

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

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

Nastishka ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

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

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

post-factum ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.