Синхронизация миллионов файлов между двумя серверами Linux

У меня есть сервер, который экспортирует каталог, содержащий ~ 7 миллионов файлов (в основном изображений) со своего локального диска для сетевых клиентов через NFS .

Мне нужно добавить второй ради HA и синхронизировать его с первым с минимальной разницей между ними.

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

Другими возможными решениями, по-видимому, являются drdb или кластерные файловые системы, такие как ceph или glusterfs , но я не имею опыта работы с ними и не знаю, какой из них был бы более подходящим и справлялся бы с таким количеством файлов и все же обеспечивал бы приличную производительность.

Обратите внимание, что действие в основном читается с небольшой записью.

Я склонен предлагать репликацию, которая не зависит от данных, например, drbd. Большое количество файлов приведет к тому, что все, что выполняется на более высоком уровне, чем «блочное хранилище», будет тратить слишком много времени на обход дерева - как вы узнали, используя rsync или создавая часы inotify.

Краткая версия моей личной истории, подкрепляющая это: я не использовал Ceph, но я почти уверен, что это не является их основной целью на рынке из-за его сходства с Gluster. Однако в последние несколько лет я пытался реализовать такое решение с помощью Gluster. Он работал и работал большую часть того времени, хотя несколько основных обновлений версии, но у меня не было никаких проблем. Если ваша цель - больше избыточность, чем производительность, Gluster может оказаться не лучшим решением. В частности, если в вашем шаблоне использования много вызовов stat (), Gluster не очень хорошо справляется с репликацией. Это связано с тем, что вызовы stat для реплицированных томов направляются на все реплицированные узлы (на самом деле это «кирпичики», но вы, вероятно, просто будете иметь один блок на хост). Если у вас есть двусторонняя реплика, например, Каждый stat () от клиента ожидает ответа от обоих блоков, чтобы убедиться, что он использует текущие данные. Кроме того, у вас также есть накладные расходы FUSE и отсутствие кэширования, если вы используете собственную файловую систему Gluster для избыточности (вместо того, чтобы использовать Gluster в качестве бэкэнда с NFS в качестве протокола и автомонтировщик для избыточности, который все еще отстой по причине stat ()) , Gluster хорошо работает с большими файлами, где вы можете распределять данные между несколькими серверами; чередование и распределение данных работает хорошо, потому что это действительно то, для чего это нужно. И более новая репликация RAID10-типа работает лучше, чем старые тома с прямой репликацией. Но, исходя из того, что я предполагаю, является вашей моделью использования, я бы посоветовал против этого. Кроме того, у вас также есть накладные расходы FUSE и отсутствие кэширования, если вы используете собственную файловую систему Gluster для избыточности (вместо того, чтобы использовать Gluster в качестве бэкэнда с NFS в качестве протокола и автомонтировщик для избыточности, который все еще отстой по причине stat ()) , Gluster хорошо работает с большими файлами, где вы можете распределять данные между несколькими серверами; чередование и распределение данных работает хорошо, потому что это действительно то, для чего это нужно. И более новая репликация RAID10-типа работает лучше, чем старые тома с прямой репликацией. Но, исходя из того, что я предполагаю, является вашей моделью использования, я бы посоветовал против этого. Кроме того, у вас также есть накладные расходы FUSE и отсутствие кеширования, если вы используете собственную файловую систему Gluster для избыточности (вместо того, чтобы использовать Gluster в качестве бэкэнда с NFS в качестве протокола и автомонтировщик для избыточности, который все еще отстой по причине stat ()) , Gluster хорошо работает с большими файлами, где вы можете распределять данные между несколькими серверами; чередование и распределение данных работает хорошо, потому что это действительно то, для чего это нужно. И более новая репликация RAID10-типа работает лучше, чем старые тома с прямой репликацией. Но, исходя из того, что я предполагаю, является вашей моделью использования, я бы посоветовал против этого. который все еще отстой по причине stat (). Gluster хорошо работает с большими файлами, где вы можете распределять данные между несколькими серверами; чередование и распределение данных работает хорошо, потому что это действительно то, для чего это нужно. И более новая репликация RAID10-типа работает лучше, чем старые тома с прямой репликацией. Но, исходя из того, что я предполагаю, является вашей моделью использования, я бы посоветовал против этого. который все еще отстой по причине stat (). Gluster хорошо работает с большими файлами, где вы можете распределять данные между несколькими серверами; чередование и распределение данных работает хорошо, потому что это действительно то, для чего это нужно. И более новая репликация RAID10-типа работает лучше, чем старые тома с прямой репликацией. Но, исходя из того, что я предполагаю, является вашей моделью использования, я бы посоветовал против этого.

Имейте в виду, что вам, вероятно, придется найти способ провести главные выборы между машинами или реализовать распределенную блокировку. Решения для совместно используемых блочных устройств требуют файловую систему, поддерживающую работу с несколькими хозяевами (например, GFS), или требуют, чтобы только один узел монтировал файловую систему для чтения-записи. Файловым системам вообще не нравится, когда данные изменяются на уровне блочных устройств под ними. Это означает, что ваши клиенты должны будут иметь возможность определить, кто является мастером, и направить туда запросы на запись. Это может оказаться большой неприятностью. Если GFS и вся ее поддерживающая инфраструктура является опцией, drbd в режиме с несколькими хозяевами (они называют это «двойной основной») может работать хорошо. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode для получения дополнительной информации об этом.

Независимо от направления, в котором вы идете, вы склонны обнаруживать, что это все еще довольно большая боль в реальном времени, не просто давая компании SAN кучу денег.

Я перешел с rsync на ceph с помощью настройки Proxmox VE.

Теперь я управляю 14 ТБ в одном кластере с живой репликацией. Уже почти 4 года.