Назад | Перейти на главную страницу

Настройка кластера серверов с использованием UNISON для двунаправленной синхронизации файлов: линия / звезда / полное соединение?

Я понимаю, что задаю несколько вопросов по одной и той же теме, но все они связаны с одной и той же целью.

Работаем с настройкой кластера с горизонтальным масштабированием и пытаемся настроить unison для синхронизации «var / www / html» для HA.

Синхронизировать между 2 серверами легко и работает как шарм, однако через vLAN будет подключено более 10 серверов.

После долгих поисков я вижу, что большинство людей, и даже в унисонных документах рекомендуют установку «звездообразной топологии»:

Однако, возможно, я просто неправильно понял настройку, или мои опасения верны (вы мне скажете).

Звездная топология:

При установке «звездообразной топологии» «узловой» сервер передает изменения остальным серверам.

Например, у нас есть серверы: A (хаб), B, C, D, E, F. Если мы добавим / изменим что-то на сервере A, он синхронизирует это с серверами B, C, D, E, F.

Однако, поскольку я буду размещать веб-сайты в «/ var / www / html», что произойдет в сценарии, где:

Я хотел бы получить объяснение, это тот случай, когда вам нужно нажимать с каждого сервера на A?

Был бы очень признателен некоторый пример сценария установки.

Полностью подключенная топология:

Большое спасибо всем, кто оставит отзыв!

Поскольку вы стремитесь синхронизировать веб-сайт между этими серверами, вам нужно убедиться, что серверы все время синхронизированы; что между изменением файлов на одном сервере и получением от Unison обновления этих изменений на другом сервере задержка небольшая или отсутствует. Это легко сделать с помощью опции Unison. repeat=watch и, возможно, используя inotifytools.

Tldr: Топология «звезда» позволяет избежать головной боли, связанной с топологией с полным подключением.

Настройка звездообразной топологии может синхронизировать изменения довольно мгновенно, но для этого требуется, чтобы Unison был запущен пару раз. Предположим, что балансировщик нагрузки вызывает пользователя на сервере D и пользователь загружает изображение. Тогда, если Unison работает с repeat=watch вариант, в основном как демон, наблюдающий за вашими файлами на предмет изменений, затем он начнет синхронизацию с узловым узлом A как только изображение будет загружено. Теперь вам нужно запустить Unison для запуска между A и другие распределенные серверы в вашей настройке. В идеале вам нужно разделить эту работу между лучевыми узлами, а не запускать несколько экземпляров Unison на A прижать к спицам. Так что я бы использовал inotifytools на A следить за изменениями, и всякий раз, когда они происходят, A отправить команду каждому луче, чтобы запустить Unison, чтобы получить изменения на A.

Напротив, существует сложность, связанная с полностью подключенной настройкой, особенно если вы просто используете repeat=watch для мгновенной синхронизации. Предположим, пользователь загружает файл на сервер D. Затем в вашей полностью подключенной настройке вы бы запустили Unison по одному, один раз для каждого другого сервера для синхронизации этого файла. Итак, сначала D синхронизируется с A, затем D начинает синхронизироваться с B, но потому что A изменилось и теперь не синхронизируется с B, он также запустит Unison и попытается синхронизироваться с B, и сейчас B пытается получить обновления сразу из двух источников ... и это может как минимум расстроить Unison. Тогда не дай бог, вы получите конфликтующие изменения на двух серверах, например, скажем, пользователь загружает свой файл на D но прежде чем все синхронизируется, другой пользователь загружает файл с таким же именем в E, в дополнение к этой первой головной боли.