Настройка кластера серверов с использованием UNISON для синхронизации файлов bi -направленно линия / звезда / полное соединение?
Я понимаю, что задаю несколько вопросов по одной и той же теме, но все они связаны с одной и той же целью.
Настройка кластера с горизонтальным масштабированием и попытка настроить unison для синхронизации "var / www / html" для HA.
Синхронизировать между 2 серверами легко и работает как шарм, однако через vLAN будет подключено более 10 серверов. .
После долгих поисков я вижу, что большинство людей, и даже в унисонных документах рекомендуют установку «звездообразной топологии»:
Однако, возможно, я просто неправильно понял установку, или мои опасения верны (вы мне скажете).
Звездообразная топология:
В настройке «звездообразная топология» сервер-концентратор передает изменения на остальные серверы.
Например, у нас есть серверы: A (концентратор), B, C, D, E , F. Если мы добавим / изменим что-то на сервере A, он синхронизирует это с серверами B, C, D, E, F.
Однако, поскольку я буду размещать веб-сайты в "/ var / www / html", что происходит в сценарии, где:
- Балансировщик нагрузки i s используется перед всеми серверами
- Веб-сайт wordpress размещается на серверах
- Автор добавляет сообщение в блог с изображениями, но он делает это, скажем, на сервере D, поскольку балансировщик нагрузки «приземлит» его на любой из серверы
Я хотел бы получить объяснение по этому поводу, это случай, когда вам нужно протолкнуть с каждого сервера на 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 пытается получить обновление из двух источников сразу ... и это могло бы как минимум расстроить Юнисон. Тогда не дай бог получить конфликтующие изменения на двух серверах,например, пользователь загружает свой файл в D , но до того, как все синхронизируется, другой пользователь загружает файл с тем же именем в E в дополнение к этой первой головной боли.