Автоматическая система синхронизация файлов между серверами 

Предположим вы делаете web проект, который в процессе работы создает новые файлы: будь то картинки залитые пользователем или кеш страниц.

В один прекрасный момент вы добавляете еще пару или еще больше серверов для отдачи статики. Перед ними ставите харварный лоадбалансер или распределяете нагрузку через round robin DNS

Возникает вопрос: как же сделать так чтобы все эти сервера отдавали одну и туже статику?

Вариантов несколько:

• Складывать общие файлы на NFS
• Складывать общие файлы на каком нибудь одном файловом сервере типа Amazon S3
• Складывать общие файлы на каждом из серверов и периодически синхронизировать их

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

S3 конечно очень заманчиво, но имхо, как то сложновато будет интегрировать кеш =) точнее я совсем не представляю как это сделать. Но как вариант для хранения пользовательских файлов — очень даже ничего.

Мне больше всего нравится последний вариант. На нем и остановимся. Синхронизировать файлы будем очевидно при помощи rsync — с этим проблем нет, запускаем раз в час и имеем одинаковые файлы на всех серверах.

Теперь представим пользовательскую сессию:

• Пришел пользователь A, load balancer кинул его на первый сервер
• Залил картинку на s1 — все замечательно, картинку видно
• Приходит пользователь Б через 5 минут после А, оказывается на втором сервере и замечательной картинки от А не видит, расстраивается, уходит, не платит нам своих денег, всем наступает несчастье

Ясно, что пример притянутый за уши. Между прочим, пример с кешем страниц аналогичный — новый кеш на первом сервере, на старом все еще старый… и тп…

Хочется синхронизировать файлы пусть не мгновенно после залития картинки, но хотя бы с минимальной задержкой.
Можно конечно из своих скриптов дергать rsync или написать какой нибудь свой мега синхронайзер.

Но зачем, если наш Linux (у вас же Linux?) сам может следить за указанный директорией и говорить что там изменилось?

Что мы имеем:

• Gamin — это интерфейс более высокого уровня к inotify, dnotify, kqueue и Hurd Mach Notify. Он как раз и работает через эти вызовы ядра, о которых ты говоришь, т.е. это просто универсальный интерфейс на все эти четыре разных API.
• dnotify — система встроенная в ядро, есть в 2.4
• inotify — наследница dnotify, в ядре начиная с 2.6.12

Разберем подробнее.

Gamin — всего лиш сервер, из клиентов, которые я смотрел и которые понравились — это fileschanged, нет ничего сложного написать что нибудь свое на php или на ruby.
Плюсы: можно легко написать своего клиента.
Минусы: один раз gamin почему то стал есть 100% cpu, выяснять причину не удалось, да и проявилась она только раз, но “осадочек остался”

dnotify — замечательно работает через dnotify
Плюсы: есть в ядре 2.4

inotify — так же замечательно работает через inotify-tools
Минусы: для Cents OS и RHEL придется пересобирать ядро
Еще есть заметка на kernel.org про плюсы inotify и минусы dnotify

Я решил остановится на dnotify, так как Gamin показался слишком тяжелым, а inotify не светит…
В итоге вроде как даже работает в тестовом режиме пока.

Но есть ряд проблем, пока с ходу нерешенные.

На пример, при удалении каталога с вложенной структурой все три тулзы последовательно нам будут говорить о том как происходило удаление, т.е. сначала самый глубокий каталог, потом выше и так далее. Дергать rsync на каждый этот event определенно не кошерно. Надо думать как вместе объединить event’ы и вызывать rsync только для последнего каталога.

Может быть стоит все таки написать своего клиента под Gamin, для обработки более сложных случаев?
Может быть стоит написать какой нибудь постобработчик для notify?