Samba, cluster, блокировки

GlusterFS работает напрямую с NFS, блокировки в NFS есть, зачем здесь самба?

Если сетевая ФС распределенная (DFS), то насколько я знаю, на репликах никак не запретить конфликтующие изменения. О них станет известно уже после (неудачной) репликации.
Если пользователи часто редактируют одни и те же файлы, то возможно им нужен какой-то инструмент совместной работы с документами (a-la GoogleDocs) или VCS (типа subversion).

Nextcloud + Collabora Online

Я просто видел решение на уровне samba, но там был не GlusterFS, а другое решение, с блочными устройствами.

Для синхронизации доступа серверов к общему хранилищу используется DLM (распределенный менеджер блокировок). В качестве кластерной файловой системы будем использовать GFS2, но она не работает напрямую с блочными устройствами, поэтому нам придется использовать кластерную реализацию LVM. Для механизма блокировок Samba использует TBD (trivial data base), нам понадобится его кластерная реализация CTDB. CTDB будет управлять переносом IP-адреса и запуском сервиса Samba. Pacemaker будет управлять следующими ресурсами: DLM, CLVM, GFS2, CTDB.

https://www.altlinux.org/Samba/Cluster

ИМХО, сильно заморочено. Нельзя ли взять что-то, добавить к хранилкам на GlusterFS и всё?

Потому что мигрируем с M$, на нём был DFS с отказоустойчивостью (распределение по датацентрам). Сказали реализовать - сделали.
Но нет предела совершенству ;-) И запросам юзеров.

А если блочное подсунуть? (какое лучше). Но с размазыванием по датацентрам, отказоустойчивостью и вот это всё. А если ещё load-balance, а не только failover будет - вообще красота.
Просто дисковые полки дорогие + санкции. Приходится выкручиваться софтово.
P.S. heartbeat не прокинуть, сетевики не объединят подсети.

DLM - это синхронизация доступа серверов к одному общему блочному хранилищу(например SAN). У тебя же DFS - то есть файлы хранятся отдельно на каждом сервере и надо как-то решать возможные конфликты между ними - это абсолютно другое, вот вообще. И это решается через DFS-R, который Samba не поддерживает

Дай уточню: тебе нужна опенсорсная кластерная ФС с репликацией между датацентрами без классического heartbeat(потому что в классическом heartbeat задержки должны быть единицы, максимум десятки миллисекунд) с разрешением конфликтов(если таковые возникнут) и вменяемой производительностью(а блокировки будут по производительности бить - это факт, CephFS не даст соврать). Ну что тут скажешь - маякни как найдешь, сам хочу на такую посмотреть.

Если у вас нет клиентов с виндой, переезжайте на NFS, сам протокол NFS уже поддерживает репликацию, но если хочется, можно и на GlusterFS жить, и на Ceph.

Если есть винда, всё становится сложнее, там NFS клиент есть, но поддерживает ли он блокировки…

Можно попробовать сделать блокировки на уровне блочного устройства, а само устройство параллелить через Ceph. Но мне кажется, это тоже сильно заморочено.

сам протокол NFS уже поддерживает репликацию

О, где про это почитать кстати, а то я когда давно читал про NFS и pNFS - оно там всё было на уровне «ну мы стандарт написали, а там как реализация будет - так будет...»

Ну это было, наверное, в 15-м году, сейчас-то уже написали.

Почитать тут, например: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/nfs-pnfs

Это и я видел, там не слова о том, как это настраивается на серверах. А по ссылке на pnfs.com вообще открывается какая-то vdura, прости господи

Update: нагуглил что поддержка есть в NFS-Ganesha, уже что-то, спасибо за наводку в любом случае

Я поспрашивал у своих админов, они делали через NFS-ganesha, и я так понял, что собственно синхронизацией данных при этом занимается всё тот же GlusterFS. Но блокировки на там точно есть.

Еще и за бесплатно нужно похоже.

Спасибо ;-)
Пока используем
ln -s msdfs:server1\share,server2\share dfs-fc и glusterFS

а блокировки будут по производительности бить

Астра-вцы со своей Tantor («postgre украли и продают»))) используют CephFS. И вроде продают стойки на Петабайты (хвастаются по крайней мере). Чем она лучше Gluster-a? Насколько велики задержки, если был опыт эксплуатации, при работе с мелкими файлами пары тысяч человек (железо можем докинуть)?

Можно попробовать сделать блокировки на уровне блочного устройства, а само устройство параллелить через Ceph. Но мне кажется, это тоже сильно заморочено.

А можно статью или как гуглить?
Полный переход с M$ не завершён, и всегда есть вероятность, что кто-то наверху в дорогом костюме притащит ноут с виндой, зайдёт по привычному пути, а там не открывается. Позвонит в ТП, а там не знают. И прилетит к нам - сделайте, чтоб работало. Пара-пара-пам… Фиу.

Платно не сильно отличается в лучшую сторону. Поддержка РФ-ОС отмораживается. Поддержка Базис-а (РФ-VDI) кивает на ТП Альта.
В ТГ-чате Альта scull (чтоб ему икалось) всех троллит и хамит, даже как-то тролльнул представительницу Газпрома, потом 3 дня не писал ничего.
В итоге имейтесь сами. Хотя денег за это всё отгружено чемоданами. И если РФ-мессенджеры (платные) можно хотя бы поменять, то РФ-ОС-и уже нет.
Так что платно / бесплатно - поддерживать придётся своими силами и компетенциями.

Я сам использовал NFS-Ganesha поверх CephFS(клиенты просто по DNS имени round-robin-ом берут адрес одного из NFS-серверов), просто не знал о дополнительных опциях монтирования, поэтому pNFS не использовал. Но у меня там служебная шара для portage была, из нее читаю многие сервера, а пишет обычно только тот, что обновления по cron-у выкачивает.

С переделкой одной из наших систем виртуализации(уехал от самосборного лет 12 назад кластера на Proxmox) я вернулся к старой схеме с всего одним NFS-сервером - ее достаточно для portage, а NFS-Ganesha когда настраивал больше тыкал для самообразования чем от реальной нужды.

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

Есть у меня еще домашний кластер, где CephFS используется как общая ФС для данных контейнеров Docker Swarm, но там тоже нагрузка достаточно жиденькая, поэтому - не показатель.

Есть опасения, на случай необходимости восстановления данных, что с Ceph ввиду нарезания на блоки по 5 МБ не вытянуть ничего.
Файловые, которые не шинкуют (тот же Gluster с настройками по-умолчанию) имеют больший шанс если не на восстановление метаданных, то хотя бы на поиск по сигнатурам. Документы мелкие, вряд ли будут фрагментированы. А на всякие дистры софта и видео - пофиг.
Да, у кластерных ФС избыточность, которую можно регулировать. И резервное копирование тоже делается. Но вспоминая github - даже 5 видов резервного копирования не залог успеха )))
Также, как ни странно - важна простота первоначальной настройки. Потому что в итоге это всё будет отдано на администрирование файловым админам - бывшим виндузятникам. Поэтому на данный момент gluster побеждает.
Нужно ещё сравнить её с DRBD.

Так Ceph/Gluster - это НЕ бэкап. Это избыточность а-ля RAID на уровне сети. RAID никогда не был заменой бэкапа.

Нужно ещё сравнить её с DRBD

Оооо, Active-Active DRBD - это прямой путь к потере данных, я бы такое никому не посоветовал. А плясать с переключением Active-Passive на случай отказа одного из серверов имеет смысл только если серверов всего два.