Cкоростная синхронизация миллиарда файлов

[1nd1go]

файлов несколько миллиардов

да и масштабы не как у Фесбука или Яху

Хе-хе… скромничаете.

Вообще, здравое решение и грамотный подход к вопросу! Жду про XFS в этом же духе ;)

[anafor]

Файлы просто очень мелкие, а нод то мало.
Спасибо!

[Psih]

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

[alrond]

Только вот очень надо осторожно, а то при ребалансе можно запросто потерять 5ТБ данных и все файлы на одной ноде просто станут обнуленными. Или fuse-клиент намертво подвесится, а вместе с ним и программы что используют фс.

[mark_ablov]

Всегда думал что XFS хорошо работает с небольшим количеством крупных файлов, в остальном проигрывает другим ФС, разве не?

[bezumkin]

Тоже так думал.
Везде в статьях про торренты под Linux советуют именно XFS.

«Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.»

Надеюсь, автор не забьет, и раскроет нам эту тему.

[hg_04]

а если нужно получить все файлы с нодов на главный сервер, это нужно на каждом ноде lsyncd подымать или есть более элегантное решение?

[hg_04]

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

[Alukardd]

Вообще мне кажется, что тут все ноды равноценные backend'ы к чему-то. Поэтому понятия сервер и клиент здесь условное и применяется в рамках lsyncd для обозначения стороны.

[nc00x]

Мне пришлось решать аналогичную задачу, но с csync2 «на бэкэнде», на том же ec2-ebs с xfs (что очевидно для ebs). Примерно как описано тут, только еще пришлось дописывать конфиги на lua для новой версии lsyncd.

Автор той статьи написал, что его устроил только уровень производительности csync2, чему я поверил (времени не было на тесты). В результате при запуске csync2 кушает cpu на 100% на какое-то время, что меня несказанно печалит. Быть может это из-за моих кривых рук.

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

[alekciy]

>то нужно повышать лимит количества файлов
В смысле rlimit на open files?

>inotify ничего не делает бесплатно — на каждый файл расходуются ресурсы
На любую сущность в системе всегда расходуются какие то ресурсы. Но в данном случае мне хотелось бы уточнить, какого рода ресурсы и почему на каждый файл? Потому как inotify это подсистема ядра которая просто уведомляет приложение о происходящих изменения. Хранения очереди изменений для передачи в приложение в ней нет.

[Murz]

Ну inotify же не забесплатно будет уведомлять, для того чтобы уведомить об изменениях — нужно какому-то процессу (пусть даже в ядре) при каждой файловой операции записи производить сравнение со списком «я же слежу за этими файлами и папками», собственно если этот список будет содержать 10 тыщ записей, то это наверное печально скажется на каждой файловой операции. Ну и если вдруг резко поменялось 5 тыщ файлов, то накопить 5 тыщ событий в лог, и потом разослать эти события всем слушальщикам.

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

[alekciy]

Ну есть более продуманная подсистема в виде fanotify. Хотя и там есть свои проблемы. А тормозов добавляет просто неграмотное их использование, и тут в принципе уже не важно, что и как использовать.
К слову сказать современные антивирусники активно используют подобные подсистемы. Все на выходе зачастую это выходит дешевле, чем шуршать диском в поиске «а не изменилось ли чего у нас в этом куске фс».

[icCE]

>К сожалению на клиенте этот кластер монтируется через FUSE, и скорость записи оказалась ниже 3 МБ/сек.

Ну а кто запрещает клиентом? Fuse же известный тормоз.

[alekciy]

Вопрос автору. Знает ли он, что в случае с inotify и падением демона ядро после запуска демона не передаст ему произошедшие изменения за период простоя демона (к примеру, на период рестарта)? Т.е. ситуация, что файл изменится, но не будет синхронизирован на кластер очень вероятна.

[bondario]

В случае с lsyncd — при старте демона проводится проверка консистентности между нодами.

[sn00p]

Что происходит при такой проверке и как долго это происходит? Кластер ждет и неработоспособен? А если проверка затянется часов на шесть?

[alekciy]

Чудес не бывает. Какая тут может быть проверка кроме полного сканирования подконтрольного куска ФС?

В новых версиях ядра inotify сменён более прогрессивной подсистемой в которой в том числе в ядре копиться очередь до момента когда демон сможет принять данные. Собственно в том числе и делалось на случай временного падения/рестарта демона слежения. К большому сожалению прикладной софт пока не использует эту возможность и lsyncd не исключение.

[anafor]

Читал об этом, но не придал значения. В даном конкретном случае это не критично — одна из других нод рано или поздно сгенерирует свой такой файл и разнесет по всему кластеру.

[alekciy]

Если файл больше не измениться, и нет других механизмов контроля консистентности кластера (хотя бы тупой пробежкой по файлам), то ни как файл по кластеру с ноды не разойдется. Хотя если проект допускает возможность такой неконсистентности, то почему нет. Я просто хотел обратить на этот аспект внимание в том числе и тех, кто будет читать, возможно в их задачах это будет не приемлемо.

[amarao]

Про DRBD немножко не правда. Да, оно не скейлится (штатная конфигурация 2 узла, дальше шаманить), но зато очень быстрая синхронизация, которая срала на файловые системы и количество файлов.

[foxmuldercp]

а что навесить сверху drbd на нодах в режиме мастер-мастер чтобы мои каталоги /var/www/html/mycoolpowerdpress были консистентны?

[pupsor]

спасибо, выглядит неплохо, посмотрим на практике.

ps: для default.rsyncssh немного другой конфиг получается:

sync {
default.rsyncssh,
source="/raid",
host=«node01»,
targetdir="/raid",
delay=10
}

[Timosha]

я правильно понимаю что в данной конфигурации синхронизация одного файла с одной ноды на 2 другие порождает синхронизацию этого же файла с тех двух других нод на третью. и при фактическом добавлении всего одного файла мы имеем 6 запусков rsync?

[anafor]

Во-первых, синхронизируются толко изменения. А во-вторых, можно не замыкать цепочку.

[alekciy]

Судя по code.google.com/p/lsyncd/source/browse/trunk/fanotify-syscall.h?r=435 поддержка fanotify (упомянутая мною в комментарии новая подсистема) в lsyncd есть (с версии 2.1). Было бы любопытно узнать, использует ли автор топика по прежнему lsyncd и какой версии?

[alekciy]

Сам спросил, сам отвечу. Подсистема fanotify признана непригодной для использования из-за отсутствия поддержки события «перемещение».

Fanotify is btw. currently not usable for Lsyncd, as it misses move events.

github.com/axkibe/lsyncd/issues/39#issuecomment-2760451

[erthad]

ocfs2 поверх drbd мы ставили на амазоне года 4 назад.
Подробностей, впрочем, уже не помню, и в продакшне я его не застал.