В компании, в которой я работаю, есть такая штука, которая называется «плейлисты», которые представляют собой небольшие файлы размером ~ 100–300 байт каждый. Их около миллиона. Каждый час меняют около 100000 из них. Эти плейлисты необходимо загружать на 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 для копирования файлов, как только произойдет изменение.
Еще несколько альтернатив:
Кажется, это идеальный вариант использования сборника рассказов для MongoDB и возможно GridFS. Поскольку файлы относительно малы, одного MongoDB должно быть достаточно, хотя может быть удобно использовать GridFS API.
MongoDB - это база данных nosql, а GridFS - это файловое хранилище, построенное на ней. MongoDB имеет множество встроенных опций для репликация и шардинг, поэтому он должен очень хорошо масштабироваться в вашем случае использования.
В вашем случае вы, вероятно, начнете с набора реплик, который состоит из главного устройства, расположенного в вашем основном центре обработки данных (возможно, второго, если вы хотите выполнить аварийное переключение в том же месте) и ваших десяти «подчиненных», распределенных по всему миру. Затем выполните нагрузочные тесты, чтобы проверить, достаточна ли производительность записи, и проверьте время репликации на ваши узлы. Если вам нужно больше производительности, вы можете превратить настройку в сегментированную (в основном для распределения нагрузки записи на большее количество серверов). MongoDB была разработана с возможностью масштабирования огромных установок с помощью «дешевого» оборудования, поэтому вы можете добавить несколько недорогих серверов для повышения производительности.
Я бы использовал бэкэнд S3, а затем просто смонтировал его на всех серверах, которые мне нужны - таким образом, все синхронизируются мгновенно
Вариант, который, похоже, еще не упоминался, - это архивирование всех файлов в один сжатый файл. Это должно значительно уменьшить общий размер и устранить все накладные расходы, возникающие при работе с миллионами отдельных файлов. Заменив весь набор файлов в одном большом обновлении, вы также можете быть уверены, что удаленные файлы будут удалены с реплик.
Обратной стороной является, конечно, то, что вы переносите много файлов без необходимости. Это может или не может быть уравновешено уменьшенным размером благодаря сжатию. Также я понятия не имею, сколько времени потребуется для сжатия такого количества файлов.