LINUX.ORG.RU
ФорумAdmin

Proxmox cluster: storage

 ,


0

5

В раздумиях над тем, какой сторедж выбрать для небольшого кластера (3 ноды) на proxmox. DRBD не особо хочется, sheepdog - не уверен что пригоден к использованию в продакшне. GlusterFS - не радует тем, что юзерспейс + судя по вики - в proxmox поддержка запилена как proof of concept. Больше склоняюсь к Ceph.

В принципе - от стореджа нужно в первую очередь минимум гемора при восстановлении в нештатных ситуевинах и нормальное резервирование, и во вторую очередь уже скорость (БД будет держаться не в виртуалках, а на самих нодах).

Кто что подсоветует?

★★★★★

NFS :) Сторадж расположен где и на чем, или он на этих же нодах будет?

stave ★★★★★
()

Glusterfs c kvm работает через libgfapi. (нативно)

Хотя тормоз конечно слегка. Рассказывай что за ноды и диски на них, как я понимаю хранение будет на этих же нодах?

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

Glusterfs c kvm работает через libgfapi. (нативно)

а насколько proxmox с ним адекватно работает? потому как сильно смущает:

This storage plugin is a technology preview, available since Proxmox VE 3.1.

+ не все будет упихано в kvm, кой-чего и в lxc может крутиться

Рассказывай что за ноды и диски на них, как я понимаю хранение будет на этих же нодах?

Да, хранение будет здесь же. SAN/NAS - пока ни денег, ни смысла нет ставить + опять же резервирование.

Диски - десктопные сата в софтрэйде (хотя если сильно по iops прижмет можно будет ssd для dm_cache упихать). Ноды - лга1156 зионы (дешево по цене/потреблению и производительности с головой хватит).

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

В виртуалках будут преимущественно веб-сервисы/радиус/прочее (т.е. дисковое i/o будет небольшим), + возможно поселится оффтопик (если прижмет). Сервисы с активным i/o и нативной кластеризацией типа СУБД будут жить на самих нодах.

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

Кластер - в основном ради того, чтобы отказаться от стопки тазиков + обеспечить резервирование

Примерно тем же вопросом мучаюсь... Насмотрелся, начитался всякого, разного. И всё же пришёл к выводу, что без, аппаратного: SAN/NAS, смысла всё это имеет весьма мало. Но, конкретно в твоём случае, БЫТЬ МОЖЕТ, взять б/у серверов, и поднять: ovirt + GlusterFS + bonding. Поддержка там этого добра - нативная. Получишь кластер, отказоустойчивость.

Я, ПОКА, смотрю в сторону: ovirt + б/у сервера + локальное хранение + mdadm + резервирование с помощью bareos, теплый сервер для резерва + zabbix. Да, в случае с выходом из строя одного из серверов, придётся бежать на площадку, и подниматься на тёплом сервере (при такой конфигурации, время поднятия 20-40 минут, имея тёплый узел). Зато, будет локальный i/o, и не понадобится мучаться с bonding и дублированием сети.

DALDON ★★★★★
()
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

И всё же пришёл к выводу, что без, аппаратного: SAN/NAS, смысла всё это имеет весьма мало.

с аппаратным SAN/NAS проблема остается с резервированием того самого SAN/NAS.

ovirt + GlusterFS + bonding.

нормального управления всем этим я особо не нашел (хотя смотрел давненько) - потому и остановился на proxmox. ну чтобы при необходимости поднять новую виртуалку не иметь гемора.

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

с аппаратным SAN/NAS проблема остается с резервированием того самого SAN/NAS.

Как вариант, рассмотреть покупку двух б/у железок. Там ещё с сетью тоже надо думать с резервированием. Но в целом, б/у железки не особо дорогие.

нормального управления всем этим я особо не нашел (хотя смотрел давненько) - потому и остановился на proxmox.

Ты знаешь, я тоже не особо следил, а тут всё же посмотрел на ovirt, и он оказывается, весьма, весьма не плох! И в отличии от поделки под именем proxmox (а это всё же именно поделка, ибо они пишут всё своё там, ovirt хоть через libvirt пашет, и то не плохо...), ovirt смотрится более зрелым решением. И там уже сейчас есть все нужные запилы под кластер из GlusterFS! Так, что советую посмотреть. За просмотр, денег не берут же. :)

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

ovirt не совсем хорошо с glusterfs работает (юзает fuse mount).

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

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

юзает fuse mount

Оуч, не ведал, что glusterfs, уже вышел из пространства пользователя.

Ну в общем, я всё же не вижу в этом большого смысла, в бюджетном варианте. Ибо, одна нода будет писать, и будет убивать производительность другой ноды... + Начинаем упираться в сеть... В общем, если в бюджетном варианте, то только с не большой нагрузкой. Так, что да, почему бы не попробовать. Если попробуешь, буду рад прочитать твои результаты.

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

Оуч, не ведал, что glusterfs, уже вышел из пространства пользователя.

а он и не вышел. но KVM умеет с ним работать напрямую, а не через прокладку ФС.

В общем, если в бюджетном варианте, то только с не большой нагрузкой.

большой i/o нагрузки в виртуалках не будет, СУБД будет жить bare metal.

NiTr0 ★★★★★
() автор топика
Последнее исправление: NiTr0 (всего исправлений: 1)

Тебе чтобы образы виртуалок хранить? Только Ceph RBD, и для образов не забудь format 2 со всеми включенными его плюшками.

GlusterFS для хранения образов, к сожалению, не годится. Всё работает на ура даже в реплике, но только когда работает. А когда вылетает одна нода, а потом возвращается назад — во время heal'а всё становится раком (из-за особенностей heal'а, который двигает целые файлы, а не изменённые куски — обещают, правда, пофиксить в 3.8/4.0).

Поэтому, тройная реплика на три ноды в Ceph — как раз. CRUSH только раскури.

post-factum ★★★★★
()

Бери Ceph. Из вышеперечисленного у тебя он будет работать лучше всего.

sheepdog, кстати, к продакшену готов, но там надо понимать какие он даёт гарантии и подходят ли они твоему продакшену =). На маленьком количестве нод будет риск потерять данные.

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

Добавлю: в гластер нужно ноды попарно добавлять для отказоустойчивого хранилища (сетевой RAID-10). Из трёх нод выйдет только distributed volume (RAID0) или replicated volume (raid-1).

Имхо: Лучше взять два сервера по мощнее и между ними уже drbd,glusterfs, etc. Три сервера для ceph это маловато, мониторы на каждый сервер для кворума + osd на каждый диск(1gb ram на 1tb hdd). И работать будет вменяемо только если добавишь ssd для кэшпула или журналов.

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

два сервера - гарантированный гемор со split brain... да и drbd - тут только по блочному устройству на каждую виртуалку, иначе жить нормально не будет.

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

попарно

Не попарно, а в количестве, кратном значению реплики. А если используется страйпинг, то там ещё и количество страйпов учитывается. В целом, GlusterFS в этом плане, конечно, менее гибок, нежели Ceph.

Из трёх нод выйдет только distributed volume (RAID0) или replicated volume (raid-1)

Есть ещё disperse, например.

Три сервера для ceph это маловато

Норм, как раз для кворума мониторов и тройной реплики.

И работать будет вменяемо только если добавишь ssd для кэшпула или журналов.

А вот с этим у Ceph много вопросов.

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

Про sard и disperse не слышал, поставлю потестить последний гластер.

x129
()

Присмотрись к nutanix

СЕ версия бесплатна, лимит один - 4 ноды

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