Под большим деревом файлов я подразумеваю около 200 тыс. Файлов, и они все время растут. Однако относительно небольшое количество файлов изменяется в каждый конкретный час.
Под двунаправленным я подразумеваю, что изменения могут происходить на любом сервере и должны быть переданы на другой, поэтому rsync не подходит.
Под удаленными я подразумеваю, что оба сервера находятся в центрах обработки данных, но географически удалены друг от друга. В настоящее время есть только 2 сервера, но со временем они могут расшириться.
В режиме реального времени допускается небольшая задержка между синхронизацией, но запуск cron каждые 1-2 минуты кажется неправильным, поскольку очень небольшая часть файлов может измениться в любой конкретный час, не говоря уже о минуте.
РЕДАКТИРОВАТЬ: Это работает на VPS, поэтому я могу быть ограничен в том, что я могу делать на уровне ядра. Кроме того, VPS не богаты ресурсами, поэтому я бы избегал решений, требующих большого количества оперативной памяти (например, Gluster?).
Каков наилучший / наиболее «принятый» подход к этому? Похоже, это будет обычная потребность, но я пока не смог найти общепринятого подхода, что было удивительно. (Я ищу безопасности масс. :)
Я наткнулся на lsyncd для запуска синхронизации на уровне изменения файловой системы. Это кажется умным, хотя и не очень распространенным, и меня немного смущают различные подходы lsyncd. Там просто используется lsyncd с rsync, но кажется, что это может быть хрупким для двунаправленности, поскольку rsync не имеет понятия памяти (например, чтобы знать, должен ли удаленный файл на A быть удален на B или это новый файл на B который следует скопировать в A). губы кажется, это всего лишь реализация lsyncd + rsync, верно?
Тогда есть использование lsyncd с csync2, как это: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Я склоняюсь к этому подходу, но csync2 немного необычный, хотя я провел его успешную проверку. Меня больше всего беспокоит то, что мне не удалось найти множество подтверждений этого метода сообществом.
Людям здесь, кажется, очень нравится Unison, но кажется, что он больше не в активной разработке и неясно, есть ли у него автоматический триггер, такой как lsyncd.
я видел Gluster упомянул, но, может быть, перебор для того, что мне нужно?
ОБНОВИТЬ: fyi- Я остановился на упомянутом мной исходном решении: lsyncd + csync2. Кажется, это работает довольно хорошо, и мне нравится архитектурный подход, когда серверы очень слабо связаны, так что каждый сервер может работать бесконечно самостоятельно, независимо от качества связи между ними.
DRBD в Двойной первичный режим с Прокси это вариант.
В вашем случае я бы рекомендовал комбинацию DRBD в двойном первичном режиме и gfs или ocfs.
Недостатком DRBD с двумя первичными устройствами является то, что он будет работать в синхронном режиме. Но скорость записи здесь, кажется, не важна, верно?
Альтернативой DRBD может быть Soft-Raid1, использующий множество (2+) iSCSI-Targets, но я бы предпочел DRBD с двумя узлами.
Возможно, лучше реализовать распределенную файловую систему, чем взламывать ее вместе с инструментами и скриптами, особенно если кластер серверов будет расти. Вы также сможете лучше справиться с отключенным узлом.
Я не думаю, что Gluster (или AFS) вообще перебор.
Почему бы вместо синхронизации не использовать одну и ту же файловую систему через NFS?
Как показано выше, доступно множество решений, каждое из которых имеет свои преимущества и недостатки.
Думаю, я бы рассмотрел возможность помещения всего дерева под контроль версий (Subversion, например) и периодически проверять / обновлять с обоих серверов в заданиях cron.
Только что завершив что-то вроде квеста, посвященного тому же самому, я перехожу к gluster. Однако я не проводил и не нашел никаких тестов производительности.