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

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

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

  • Своп слова в VIM без использования сторонних плагинов
  • как я могу рекурсивно удалять пустые каталоги в моем домашнем каталоге?
  • Как обнаружить и остановить пользователя от удаления определенного файла в Linux?
  • Как завершить работу Linux в конкретном дате с терминала?
  • Linux: Текущее правильное / рекомендуемое использование игровой группы?
  • Как постоянно включить scl CentOS 6.4?
  • Исследования предлагают использовать lsyncd или другие решения, основанные на inotify , но при условии, что количество файлов, создающих часы inotify, занимает целую вечность. То же самое для rsync .

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

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

  • предварительная стратегия прервать приложение Linux, которое «повесило», и сделало X desktop безответным
  • Оптимизация сервера NFS для максимальной производительности
  • Неизвестная причина 20 и 30 NMI на виртуальной машине
  • Как увидеть параметры драйвера?
  • Как запустить сценарий оболочки из любого места
  • Какие сертификаты unix доступны? Есть ли самоучка?
  • 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 - лучшая ОС в мире.