GlusterFS и удалённый доступ

Да, похоже, это не лечится:

https://bugzilla.redhat.com/show_bug.cgi?id=974624

Подскажите тогда хоть какой волшебной строчкой iptables я могу ограничить доступ к 24007..24011 портам только для списка разрешённых IP? А то я с iptables плохо дружу :)

Пока так сделал:

-A INPUT -s xx.xx.xx.xx/32 -p tcp -m tcp --dport 24007 -j ACCEPT
-A INPUT -s yy.yy.yy.yy/32 -p tcp -m tcp --dport 24007 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 24007 -j DROP

красивый монолог =) я аж зачитался =)

А что делать, если документация по GlusterFS просто никакая. И форумов нормальных по нему нет, только ужасающие по юзабилити рассылки :)

Хороший тред. Сам спросил, сам нагуглил, сам научился, сам ответил. В духе старого LOR.

А что делать, если документация по GlusterFS просто никакая.

вот вот, я тоже с ним недавно связался. ужс просто. логи у него это просто поток заклинаний из ада.

логи у него это просто поток заклинаний из ада.

Да, есть такое :)

Сейчас пытаюсь по NFS прицепиться, всё никак не хочет. Через fuse не сказать, что совсем тормозно, но не фонтан. Около 5Мб/с на запись (зеркало), 10Мб/с на чтение.

Блин. Кроме 24007..240xx, похоже, ещё надо закрывать, как минимум, 5 портов :-/ Кто ж так пишет, блин.

И форумов нормальных по нему нет

forge.gluster.org раньше был для этого, потом проект перебуровили, но участники должны где-то и теперь общаться

glusterfs
fuse

дядько, а это всё на продакшне ?

дядько, а это всё на продакшне ?

Угу. Планируется :) На стадии изучения. Ну, кроме fuse, я больше на nfs рассчитываю.

Ага, спасибо, оценю.

Ну, кроме fuse, я больше на nfs рассчитываю.

Что-то меня терзает смутное подозрение, что на fuse тебе и придётся остаться. Иначе смысл тебе от кластерной ФС? Твоя задача обеспечить работу множества клиентов с набором серверов без различных посредников.

а в чём будет заключаться продакшен? и что за странное отношение к fuse, которое на striped-replicated томе уделывает nfs?

Иначе смысл тебе от кластерной ФС?

Ты про автоматическое переключение при падении сервера? У меня основная задача не иметь сервису доступ к внешним данным, сервисы [почти] все стоят там же, где и glusterfs-сервер, так что если локальный gluster упадёт, сервисы, скорее всего, тоже :)

Задача — именно репликация ради репликации. Непрерывный бэкап + поддержание в рабочем состоянии резерва (при падении основного ресурса просто переключаем DNS и работаем с резервом). Ну и лёгкость переезда на другие сервера с минимальным даунтаймом.

А ещё георепликация, сука, глючит. Хоть на ceph смотри от такой фигни.

а в чём будет заключаться продакшен?

Да обычный LNMP с умеренной нагрузкой.

и что за странное отношение к fuse, которое на striped-replicated томе уделывает nfs?

Странно, народ многократно писал, что fuse заметно медленнее. Сам пока не сравнивал, у меня nfs к glusterfs пока только на одной из трёх машин коннектится (проблема явно с самой NFS) и как раз на той, на которой реплики нет, т.е. на чисто сетевом доступе. Так что скорость пока не оценить, она тут уткнётся в сеть :) Около 2Мб/с выходит (прокси-нода физически вообще в Амстердаме).

А ещё георепликация, сука, глючит.

Ну, это мне пока без надобности.

Хоть на ceph смотри от такой фигни.

Я смотрел, но он же с централизованным сервером метаданных. Хочу полностью децентрализованную систему, в которую на лету ноды добавлять/убирать можно.

я бы не стал юзать это сырое поделие в продакшене.
*комьюнити нет (ну есть рассылка gluster-users)
*документации нет
*историй успеха почти нет

Вопрос - если приложение пишет разные файлы, то , может, заюзать тупо двусторонний sync?

Вопрос - если приложение пишет разные файлы, то , может, заюзать тупо двусторонний sync?

Двусторонний rsync ляжет раком, когда ему подсунут каталог с 500 тыс. файлов в 200 тыс. каталогов :)

Имею богатый опыт подобных синхронизаций в меньших масштабах: Мысли вслух. Предостережение от наступления на грабли.

Что скажешь про
https://code.google.com/p/rsync-inotify/
https://code.google.com/p/lsyncd/

rsync-inotify
lsyncd

inotify на таких объёмах дохнет и глючит. Сам не щупал (хотя lsyncd для мелких задач начинаю использовать), но комментарии использовавших вполне исчерпывающи :)

Порты 24007:24011,38465:38485,49153

-A INPUT -s 192.168.0.0/16 -p tcp -m multiport --dports 24007:24011,38465:38485,49153 -j ACCEPT

остальные -j DROP

Еще есть засада в том, что если разрешить 24007 (порт демона glusterd), то клиент может у себя установить демон и сделать peer probe, и поудалять нафиг все тома. Вопрос в том, как разрешить клиенту монтировать том через FUSE, но не разрешить peer probe.

Да, с безопасностью там полная опа, я уже понял :) Хорошо, что у меня все ноды доверенные.

Не было ли у тебя такого, что при активном юзании glusterfs через NFS, на сервере (там, где bricks) возникает толпа rpc.statd, и каждый слушает какой-то рандомный порт на 0.0.0.0.
Вопрос - зачем их столько? Как их заставить биндиться хотя бы на localhost? Из-за обилия слушаемых портов приходится применять файрвол в виде «закрыто всё, открыто нужное».

Не было ли у тебя такого, что при активном юзании glusterfs через NFS

Я пока не начал активно использовать gluster. До сих пор решаю, то ли им пользоваться начать, то ли lsyncd, то ли оба сразу, в зависимости от задач.

Я пытался сделать похожим образом:

iptables -A INPUT -s xx.xx.xx.xx/32 -p tcp -m tcp --dport 24007:24047 -j ACCEPT
iptables -A INPUT -s yy.yy.yy.yy/32 -p tcp -m tcp --dport 24007:24047 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 24007:24047 -j DROP

Я ничего не смог добиться.. Буду рад, если подскажете решение..

Я делал в стиле GlusterFS и удалённый доступ (комментарий) (чтобы сразу множество IP разрешать и удалять/добавлять их без переписывания многих правил), только что порты шире открывал — и всё работало.

-A INPUT -p tcp -m set --match-set allow_gluster src -m multiport --dports 2049,24007:24011,38465:38485,49152:49154 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 2049,24007:24011,38465:38485,49152:49154 -j DROP

Реально, вроде, достаточно 24007:24011, на других машинах только они открыты — работает.

Хочу полностью децентрализованную систему, в которую на лету ноды добавлять/убирать можно.

хм, может тогда посмотреть на swift?

Это же не полноценная ФС, а объектное хранилище. В своих проектах задействовать можно, а какую-нибудь статику в nginx так не раздать.