Можно ли создать список исключений для типов файлов (возможно, даже для определенных файлов), чтобы они не пытались синхронизироваться с вторичными узлами? Я просмотрел файл конфигурации DRBD и ничего не нашел. Если нет, существует ли другая система синхронизации главный-> подчиненный, которая допускает исключения?
Почему я спрашиваю:
Попытка перейти с одного сервера на кластер за инфраструктурой балансировки нагрузки. Я хочу, чтобы рабочие / конфигурационные файлы серверов синхронизировались. Существуют файлы журналов, которые записываются в те же каталоги, что и соответствующие операционные / конфигурационные файлы.
Оптимальная цель:
Когда на главном (первичном) сервере обновлены соответствующие файлы, синхронизируются файлы подчиненного (вторичного) сервера.
Я знаю, что могу реструктурировать код, но мне бы очень хотелось этого избежать.
Возможно релевантная информация:
Серверы AWS ec2. AWS Load Balancer. AWS NFS (EFS) был опробован, но падение производительности было слишком большим. Не удалось заставить Дженкинса отпить цель. Подумайте о настройке репозитория Git для ведущего, клонировании репо на ведомых устройствах и последующем добавлении триггеров при каждой фиксации. Нет лучшего решения? Не изучили полностью Puppet, может ли это быть вариантом? Может, Corosync? Если вы можете указать мне на полезную документацию по использованию, это было бы здорово.
Нет, DRBD - это инструмент синхронизации на уровне блоков, и поэтому он не может (и не должен) заботиться о том, какие файлы хранятся на зеркальном блочном устройстве.
Для проверки файла конфигурации между несколькими серверами вы можете взглянуть на csync2 (который является другим продуктом производителей DRBD) или lsyncd (который работает только для однонаправленной передачи, то есть: от основного узла к ведомому).
Наконец, вы можете просто использовать собственный сценарий на основе rsync (который, опять же, будет хорошо работать только для однонаправленных первичных-> вторичных передач).