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

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

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

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

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

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

  • rsync --backup-dir создает пустые папки в резервном каталоге
  • Можете ли вы scp, sftp или rsync, трубу?
  • Может ли rsync фиксировать отметки времени без повторной загрузки?
  • Rsync «находит» файлы, которые неявно исключены
  • Не удается передать ssh-соединение с помощью rsync
  • rsync терпит неудачу / зависает при копировании из Linux ext4 в FreeBSD ZFS (через SSH)
  • Rsync копирует только измененные файлы; игнорировать отметки времени изменения файла
  • как фильтровать по звездочке или аналогичному выражению rsync в zsh
  • 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 грузовик с деньгами.

    Interesting Posts

    автоматическое удаление записей меню fluxbox

    SELinux: «chcon» не отображается в другой учетной записи пользователя

    Создание процесса для каждого перенаправленного stdout

    Tmux – Получить количество панелей в текущем окне в переменной bash?

    Как протоколировать вызовы с использованием сценария оболочки, когда в исполняемый файл имеется несколько символических ссылок

    Почему скобки не могут быть установлены на Debian?

    Какой вариант монтирования используется для файловой системы ext3 для минимизации потери или повреждения данных?

    количество файлов (на основе расширения файла) в нескольких папках

    Записать wget link-rewrite обо всех загруженных файлах

    Скопируйте файлы с удаленного сервера на локальный, игнорируя существующие файлы (rsync недоступен)

    Доступ к трассировке дерева каталогов

    Резервное копирование без переустановки сторонних программ?

    Предотвращение или обнаружение чтения демона в памяти

    OpenSSL конвертирует символы в UTF-8

    команда sed оставить два десятичных знака и удалить остальные после запятой

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