Выравнивание нагрузки Nginx проксирует беспорядок
Я в настоящее время пытаюсь установить подсистему балансировки нагрузки для набора зеркал загрузки. При чтении в этот предмет я видел, что 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 (модель master / backup).
Если вы абсолютно хотите придерживаться nginx, есть нечто «подобное», которое называется модулем stream (появилось в nginx 1.9.0 , а не «стабильный» выпуск), но вам потребуется перекомпилировать его самостоятельно, и это не предотвратит обратный переход даже при работе на уровне 4 OSI.