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