У меня есть сервер, который экспортирует каталог, содержащий около 7 миллионов файлов (в основном изображений) со своего локального диска на сетевые клиенты черезНФС.
Мне нужно добавить второй ради HA и синхронизировать его с первым с минимально возможной разницей между ними.
Исследования предлагают использоватьlsyncdили другойinotify-решения для этого, но учитывая количество файлов, создающихinotifyчасы занимают вечность. То же самое и дляrsync.
Другие возможные решения, по-видимому,drdb, или кластерфайловые системытакой какцефилиglusterfs, но у меня нет опыта работы с ними, и я не знаю, какой из них будет более подходящим и будет хорошо справляться с таким количеством файлов, обеспечивая при этом приличную производительность.
Обратите внимание, что активность в основном заключается в чтении и незначительной записи.
решение1
Я склонен предложить репликацию, которая не зависит от данных, как drbd. Большое количество файлов приведет к тому, что все, что работает на более высоком уровне, чем "блочное хранилище", будет тратить чрезмерно много времени на обход дерева - как вы обнаружили, используя rsync или создавая наблюдения inotify.
Короткая версия моей личной истории, подтверждающая это: я не использовал Ceph, но я почти уверен, что это не их главная целевая аудитория на рынке, исходя из его сходства с Gluster. Однако я пытался реализовать такое решение с Gluster в течение последних нескольких лет. Он работал большую часть этого времени, хотя и имел несколько крупных обновлений версии, но у меня не было конца проблемам. Если ваша цель — больше избыточность, чем производительность, Gluster может быть не лучшим решением. Особенно если ваш шаблон использования имеет много вызовов stat(), Gluster не очень хорошо справляется с репликацией. Это потому, что вызовы stat к реплицированным томам идут на все реплицированные узлы (на самом деле «кирпичи», но у вас, вероятно, будет просто один кирпич на хост). Например, если у вас есть двусторонняя реплика, каждый stat() от клиента ждет ответа от обоих кирпичей, чтобы убедиться, что он использует текущие данные. Затем у вас также есть накладные расходы FUSE и отсутствие кэширования, если вы используете собственную файловую систему Gluster для избыточности (вместо того, чтобы использовать Gluster в качестве бэкэнда с NFS в качестве протокола и автомонтирования для избыточности, что все еще отстой по причине stat()). Gluster действительно хорошо справляется с большими файлами, когда вы можете распределить данные по нескольким серверам; чередование и распределение данных работают хорошо, поскольку это действительно то, для чего он предназначен. И более новая репликация типа RAID10 работает лучше, чем старые прямые реплицированные тома. Но, основываясь на том, что я предполагаю, является вашей моделью использования, я бы не советовал этого.
Имейте в виду, что вам, вероятно, придется найти способ провести выборы мастера между машинами или реализовать распределенную блокировку. Решения с общими блочными устройствами требуют файловой системы, которая поддерживает многомастерность (например, GFS), или требуют, чтобы только один узел монтировал файловую систему для чтения и записи. Файловые системы в целом не любят, когда данные изменяются на уровне блочных устройств под ними. Это означает, что ваши клиенты должны будут иметь возможность определить, какой из них является мастером, и направлять туда запросы на запись. Это может оказаться большой неприятностью. Если GFS и вся его поддерживающая инфраструктура являются вариантом, drbd в многомастерном режиме (они называют это «двойной основной») может хорошо работать. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-modeдля получения более подробной информации по этому вопросу.
Независимо от того, в каком направлении вы пойдете, вы, скорее всего, обнаружите, что это все равно довольно сложно сделать в режиме реального времени, не выделив компании SAN кучу денег.
решение2
Я перешел с rsync на ceph с помощью настройки Proxmox VE.
Сейчас я управляю 14 ТБ в одном кластере с живой репликацией. Уже почти 4 года.