Варианты для эффективной синхронизации 1 миллиона файлов с удаленными серверами?

В компании, в которой я работаю, есть такая вещь, как «плейлисты», которые представляют собой небольшие файлы ~ 100-300 байт каждый. Там около миллиона из них. Около 100 000 из них меняются каждый час. Эти списки воспроизведения необходимо загружать на 10 других удаленных серверов на разных континентах каждый час, и в идеале это должно происходить быстрее, менее чем за 2 минуты. Очень важно, чтобы файлы, которые удаляются на главном устройстве, также удалялись на всех репликах. В настоящее время мы используем Linux для нашей инфраструктуры.

Я думал о попытке rsync с опцией -W копировать целые файлы без сравнения содержимого. Я еще не пробовал, но, может быть, люди, которые имеют больше опыта работы с rsync, могут сказать мне, если это приемлемый вариант?

Какие еще варианты стоит рассмотреть?

Обновление: я выбрал опцию lsyncd в качестве ответа, но только потому, что он был самым популярным. Другие предложенные альтернативы также действительны по-своему.

Поскольку мгновенные обновления также приемлемы, вы можете использовать lsyncd .
Он наблюдает за каталогами (inotify) и rsyncпревращается в рабов.
При запуске он будет заполнен полностью rsync, так что это займет некоторое время, но после этого передаются только изменения.
Рекурсивный просмотр каталогов возможен, если подчиненный сервер не работает, синхронизация будет повторяться до его возвращения.

Если это все в одном каталоге (или статическом списке каталогов), вы также можете использовать incron .
Недостаток заключается в том, что он не позволяет рекурсивно просматривать папки, и вам необходимо самостоятельно реализовать функцию синхронизации.

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

Для этого конкретного варианта использования можно создать том GlusterFS с 10 серверами из 10 реплик (т. Е. 1 реплика / кирпич на сервер), чтобы каждая реплика была точным зеркалом каждой другой реплики в томе. GlusterFS будет автоматически распространять обновления файловой системы на все реплики.

Клиенты в каждом месте будут связываться со своим локальным сервером, поэтому доступ к файлам для чтения будет быстрым. Ключевой вопрос заключается в том, можно ли поддерживать задержку записи на приемлемо низком уровне. Единственный способ ответить на этот вопрос - это попробовать.

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

Редактировать: немного поработав, вы можете даже использовать этот подход inotify / log watch для копирования файлов сразу после того, как произойдет изменение.

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

• Вставьте задание в RabbitMQ или Gearman, чтобы асинхронно завершить работу и удалить (или добавить) один и тот же файл на всех удаленных серверах всякий раз, когда вы удаляете или добавляете файл на основном сервере.
• Сохраните файлы в базе данных и используйте репликацию для синхронизации удаленных серверов.
• Если у вас есть ZFS, вы можете использовать репликацию ZFS .
• Некоторые SAN имеют репликацию файлов. Я понятия не имею, если это можно использовать через Интернет.

Кажется, это идеальный вариант использования сборника рассказов для MongoDB и, возможно, GridFS . Поскольку файлы относительно малы, одного MongoDB должно быть достаточно, хотя может быть удобно использовать GridFS API.

MongoDB - это база данных nosql, а GridFS - это система хранения файлов поверх нее. MongoDB имеет множество встроенных опций для репликации и шардинга , поэтому он должен очень хорошо масштабироваться в вашем случае использования.

В вашем случае вы, вероятно, начнете с набора реплик, который состоит из мастера, расположенного в вашем основном центре обработки данных (может быть, второго, на случай, если вы хотите выполнить отработку отказа в том же месте) и ваших десяти «рабов», распределенных по всему миру. Затем выполните загрузочные тесты, чтобы проверить, достаточна ли производительность записи, и проверьте время репликации на ваши узлы. Если вам нужно больше производительности, вы можете превратить установку в сегментированную (в основном, чтобы распределить нагрузку записи на большее количество серверов). MongoDB был разработан для расширения огромных настроек с помощью «дешевого» оборудования, поэтому вы можете добавить пакет недорогих серверов для повышения производительности.

Я бы использовал S3 Backend, а затем просто смонтировал его на всех нужных мне серверах - таким образом, все в любом случае мгновенно синхронизируются

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

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