Какие есть альтернативы glusterFS

NTFS

Норкоман штоле?

Забей на него, он пукает в лужу в каждом технотреде. Нечто вроде местного бота, ищущего в посте ключевые слова и отдающего предусмотренный заранее ответ.

Я пошутил :-) Посмотри на OCFS.

Lustre, cephfs (но там производительность еще хреновее, чем в гластере)

Если не в разы хуже, то можно попробовать, т.к. отдавать будет nginx. А скорость записи не критична.

Тебе что нужно? HA? Репликацию? Опиши юзкейс детальнее.

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

Непонятно. Ты хочешь контент раздавать с самих серверов стореджа, коих 25, и держать 25 синхронизированных копий, что ли?

Да

Подход говно, кончено. Если нужна синхронная репликация — это будет звиздец.

Я бы так не делал.

В чем звиздец то? И какие альтернативы есть? Я с радостью услышал бы.

посмотри в сторону ipfs правда кучу костылей надо будет перекрутить

Смех смехом, но поверх NTFS есть DFS, которая в принципе может относиться к сабжу )

Ну вот, взял и рассказал.

В кластере разумно держать не больше 3-х копий при синхронной репликации, ибо каждая операция на запись, которая по определению состоит из нескольких подопераций, троектратно умножается по задержкам из-за задержки сети. Вот в этом первый звиздец.

Второй звиздец в том, что держать 25 копий — это неэффективное использование дискового ресурса.

Если у тебя 25 серверов с дисками в каждом — берёшь и создаёшь на всех них Ceph OSD, на трёх серваках поднимаешь Ceph MON, на одном — active MDS, на двух — standby-replay MDS. Потом на каких-то серваках делаешь nginx-бекенды (с Ceph-mountpoint'ами), на каких-то — nginx-фронтэнды для балансировки. Балансировку на фронтэнды можно по DNS сделать, например.

И всё это на серваках желательно поизолировать виртуалками или контейнерами.

Короче, видишь, как оно.

В кластере разумно держать не больше 3-х копий при синхронной репликации, ибо каждая операция на запись, которая по определению состоит из нескольких подопераций, троектратно умножается по задержкам из-за задержки сети. Вот в этом первый звиздец.

Так как мне на 25 серверах сделать синхронные копии? Т.к. отдавать мне нужно со всех.

Не, норм все работает. Скорость записи меня устраивает.

держать 25 копий — это неэффективное использование дискового ресурса.

Чего? Я 25 копий держу, потому что каждый сервер забивает канал в 500мбит на отдачу. С меньшего количества серверов отдавать не получится.

Потом на каких-то серваках делаешь nginx-бекенды (с Ceph-mountpoint'ами)

Производительность просядет. Я напрямую из стандартной ФС отдаю.

Ну тогда тебе ни Ceph, ни GlusterFS не подходят. С остальным не работал, иду мимо.

Может, тебе нужно что-то типа clsync.

Гластерфс отлично подходит, но он глючит периодически

что-то типа clsync

Вот это может сработать.

Гластер на 25 реплик не рассчитан (он вообще на твою схему не рассчитан). Он-то будет, конечно, как-то работать, но медленно. Плюс, тебе при гластере в продакшне нужно будет не вылезать из багзиллы, gdb и IRC-чата с разрабами.

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

Lustre на стареньком железе (4 года) с двумя OSS

> dd if=/dev/zero of=test.bin bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 0,897393 c, 1,2 GB/c

> dd if=test.bin of=/dev/null  bs=64k
16000+0 записей получено
16000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 0,184839 c, 5,7 GB/c

Но это по Inifiniband. И есть ещё такое:

> dd if=test.bin of=/dev/null  bs=1k
1024000+0 записей получено
1024000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 1,11088 c, 944 MB/c

На другом узле (не на том, на котором создавался файл)

> dd if=test.bin of=/dev/null  bs=64k
16000+0 записей получено
16000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 0,672084 c, 1,6 GB/c
> dd if=test.bin of=/dev/null  bs=64k
16000+0 записей получено
16000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 0,204653 c, 5,1 GB/c

чтобы раздавать файлы с конкретных физических хостов, а не тянуть из кластера.

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

Почитал тред. С учётом потребностей - rsync?

Не, я серьёзно. rsync + некий список залитого полностью файла по нодам.

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

выше вообще нигде нет работы с диском, а только в память и из памяти

Гластер на 25 реплик не рассчитан

Я не эксперт по гластеру, но если паттерн работы с файлом «1 раз записал, 100000000 раз прочитал», то похоже это технически очень простой юзкейс. Пишешь сколько угодно медленно, ждешь сохранения заданого пользователем количества реплик чтобы признать запись успешной, остальное асинхронно реплицируется. При чтении достаточно прочитать блок со случайной (близкой, ненагруженой, что-то в этом духе) машины и отправить, лишь сверив контрольную сумму метаданных блока. Плюс там чуть повозиться с тем, что блок большой, а файлы - маленькие, но это решается и может быть упакование групп горячих файлов в блок с последующим кешированием например на SSD или в памяти. Если такое кеширование реализовать, то может и 25 реплик на изначальной распреледенной ФС не нужно.

Это принцип работы системы здорового человека, может в GlusterFS там все как у курильщика, я не знаю

выше вообще нигде нет работы с диском, а только в память и из памяти

Смотреть надо внимательнее

Повторю без чтения из кеша клиента:

На первом узле создадим файлик в 100+ ГБ

[alexv@pudu-cn01 ~]$ dd if=/dev/zero of=test.bin bs=1M count=100000
100000+0 записей получено
100000+0 записей отправлено
 скопировано 104857600000 байт (105 GB), 102,637 c, 1,0 GB/c

Идём на второй:

[alexv@pudu-cn02 ~]$ dd if=test.bin of=/dev/null bs=1M
100000+0 записей получено
100000+0 записей отправлено
 скопировано 104857600000 байт (105 GB), 61,4143 c, 1,7 GB/c

Идём на третий:

[alexv@pudu-cn03 ~]$ dd if=test.bin of=/dev/null bs=1M
100000+0 записей получено
100000+0 записей отправлено
 скопировано 104857600000 байт (105 GB), 53,8616 c, 1,9 GB/c

Очевидно, что часть файлов лежит в кеше, как клиентов, так и серверов. Но в данном случае на серваках 80 дисков (8*RAID6(8+2)), которые дают профит по скорости чтения/записи.

Для большего профита, Люстру теперь можно поднять и поверх ZFS с её плюшками, ака ARC и L2ARC.

Не, я серьёзно. rsync + некий список залитого полностью файла по нодам.

Да я уже как раз к этому решению и пришел, сейчас колхозю. Лучше пускай мое приложение все контролирует, плюс rsync простой и надежный.

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

GPFS

Про GPFS, GFS2, OCFS... Я так понял, у автора треда вариант shared-nothing, плюс r/o delivery с первичной записью из любой, но одной локации. Всё же перечисленное - для shared LUN и синхронного доступа. GPFS в варианте shared LUN выглядит ничего так себе, но только при условии, что все серверы в одной локации, а автор говорит про CDN. Поэтому имхо лучше чем-то синкать ноды, и не запариваться на реальный синхронный кластер.

Могу ещё про GFS2 рассказать (OCFS - скорее всего те же боллзы в профиль). Сначала вы заколебётесь конфигурить corosync/pacemaker. Потом при наличии распределения по локациям однозначно поимеете проблем с арбитражом. По личному опыту - при latency выше 3-4 мс или высокой загрузке CPU с corosync'ом начинаются жесточайшие грабли, которые до конца не лечатся даже выкручиванием таймеров, там все механизмы - баланс между двумя огнями, который при лейтенси выше 3-4 мс или пиках на CPU теряется полностью. Плюс обязателен аппаратный STONITH с отдельным включением (что при геораспределении затруднительно), о программном можно даже не думать - любые проблемы с отстреливанием любой ноды приводят к останову (не падению, а именно останову операций) кластера. Оставшаяся в живых «вроде как» отстреленная кластером нода - 99% шанс повреждения метаданных. И это ещё не не полный список.

В ocfs2, НЯЗ, corosync/pacemaker не нужен.

Нужен. Там либо heartbeat/pacemaker, либо corosync/pacemaker.

https://docs.oracle.com/cd/E37670_01/E37355/html/ol_instcfg_ocfs2.html

Не вижу того, о чём ты пишешь.

Ох ты ж, у них свой o2cb, в котором и LM есть. Тогда да, посыпаю голову пеплом - к OCFS написанное про GFS2 выше неприменимо, там может быть всё кучерявее, плюс могут быть свои тараканы.