Сейчас я пытаюсь настроить балансировщик нагрузки для нескольких зеркал загрузки. Читая эту тему, я увидел, что Nginx отлично подходит для балансировки нагрузки, отлично! Но, глядя на разные конфигурации, я немного запутался.
Можно решить перенаправить или прокси к внутренним серверам. Перенаправление довольно понятно: вместо этого вы говорите клиенту перейти в другое место, и запрос передается и обрабатывается, балансировщик нагрузки не имеет значения.
Однако, если вы решите использовать прокси, разве это не повредит самой идее наличия нескольких запущенных зеркал загрузки? Учитывая, что nginx перенаправит запрос на бэкэнд-сервер, загрузит файл и передаст его клиенту?
Итак, чтобы визуализировать, как я думаю, это работает (поток пакетов):
Перенаправить: Клиент => Балансировщик нагрузки => Бэкэнд => Клиент
Прокси: Клиент => Балансировщик нагрузки => Бэкэнд => Балансировщик нагрузки => Клиент
Или прокси-сервер сотворит чудеса и скажет клиенту, что нужно подключиться к бэкэнду для загрузки файла?
В случае, если проксирование действительно приводит к поражению цели наличия нескольких зеркал загрузки для увеличения пропускной способности, является ли перенаправление единственной альтернативой?
РЕДАКТИРОВАТЬ: Или я путаю работу прокси с работой перезаписи? Действительно ли прокси-сервер передает запрос, как перенаправление, при этом используя тот же URL-адрес?
Если вы используете nginx в качестве балансировщика нагрузки поток будет:
Перенаправление:
Step 1 : Client => LB (HTTP request)
Step 2 : LB => Client (HTTP reply)
Step 3 : Client => Backend (HTTP request)
Step 4 : Backend => Client (HTTP reply)
Прокси:
Step 1 : Client => LB (HTTP request)
Step 2 : LB => Backend (HTTP request)
Step 3 : Backend => LB (HTTP reply)
Step 4 : LB => Client (HTTP reply)
Итак, в первом случае балансировщик нагрузки, как вы думаете, представляет собой простой HTTP-сервер, и бэкэнд отвечает напрямую клиенту. Во втором случае он полностью возвращается к клиенту через nginx. Поскольку nginx не обязательно будет ждать, пока будет доступно полное тело ответа, чтобы начать передачу данных клиенту, он использует буферы или временные файлы для потоковой передачи обратно в зависимости от конфигурации. Но вы столкнетесь с более высоким временем передачи пакетов туда и обратно, поскольку вы получите еще один переход во время фактической передачи данных.
Такова общая картина балансировки нагрузки уровня 7 OSI в случае использования HTTP. Теперь балансировка сетевой нагрузки не ограничивается уровнем 7 и HTTP. Есть и другие способы.
В частности, если вы ищете способ распространения трафика на бэкэнд-серверы, на которых размещается по существу статический контент, вы можете вместо этого использовать keepalived в качестве решения для балансировки нагрузки в режиме прямой маршрутизации, который заставит серверные серверы отвечать непосредственно клиенту, в то время как запросы проходят через балансировщик нагрузки (это уровень 4 OSI, поэтому он не знает, что вы делаете, вверх, он просто монтирует виртуальный IP-адрес и отправьте поток TCP на реальные серверы, где тот же виртуальный IP-адрес установлен на интерфейсе обратной связи). Keepalived также обрабатывает HA с помощью VRRP (основная / резервная модель).
Если вы абсолютно хотите придерживаться nginx, есть нечто «похожее», которое называется stream модуль (появился в nginx 1.9.0, а не в «стабильной» версии), но вам потребуется перекомпилировать его самостоятельно, и это не предотвратит обратный переход даже при работе на уровне 4 OSI.