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

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

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

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

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

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

  • Как вы сравниваете две папки и копируете разницу в третью папку?
  • Сохранить дату, измененную в каталогах / папках с помощью rsync
  • Обратный rysnc с несколькими источниками
  • Почему две директории отличаются после синхронизации с rsync?
  • Кэширование записывает изменения на SSD, чтобы избежать разгона HDD? ZFS, но (возможно) не L2ARC
  • rsync удаляет исключенный файл
  • Время и дата папок Rsync
  • Выполнение точного моментального снимка и инкрементного резервного копирования на удаленный сервер
  • One Solution collect form web for “Синхронизация миллионов файлов между двумя серверами Linux”

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

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

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

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

    Linux и Unix - лучшая ОС в мире.