Когда пользователь нажимает на балансировщик нагрузки, а балансировщик нагрузки определяет, какой веб-сервер следует пересылать, что происходит дальше? Направляет ли балансировщик нагрузки запрос и все его данные на веб-сервер, получает ответ веб-сервера и возвращает его обратно пользователю?
Или это больше похоже на перенаправление, когда балансировщик нагрузки буквально просто возвращает IP-адрес выбранного сервера обратно в браузер, и браузер должен открыть новое соединение с данным сервером?
Мой инстинкт говорит, что это не будет последним, потому что это будет означать, что все IP-адреса веб-сервера будут общедоступными, и я подумал, что из соображений безопасности лучше всего показывать только адреса балансировщиков нагрузки. Но опять же, я не совсем уверен, потому что, если вы включите SSL terminationбалансировщик нагрузки, не нужно ли будет повторно устанавливать SSL с перенаправленным сервером?
Ответы:
Конечный IP не опубликован. На самом деле этот процесс работает таким образом, что клиент (пользователь нажимает на балансировщик) считает, что он взаимодействует с балансировщиком, общаясь с реальным узлом.
В очень простом объяснении большинство транзакций работают так:
Имейте в виду, что перезапись пакетов (изменение IP-адреса на шаге 4) очень важна. Без этого клиент, получив пакет с IP-адреса, которому он не доверяет, просто отбросил бы ответ.
источник
Лад Балансер - это работа на уровне 4 OSI. Он декапсулирует пакет до номера порта, а затем направляет пакет в одном из трех режимов.
Балансировщик нагрузки может работать в 3 режимах: 1. Прямая маршрутизация. В этом режиме ваш реальный сервер использует IP public. Балансировщик получает пакет и декапсулирует до уровня 4. Если в соответствии с правилом балансировки нагрузки, он будет перенаправлять пакет (без изменения) на один из реальных серверов. Реальный сервер имеет адрес-псевдоним, совпадающий с адресом балансировки нагрузки, поэтому, когда реальный сервер получает пакет с адресом xxx.xxx.xxx.xxx, он определяет этот пакет прямо на его адрес (псевдоним). И тогда реальный сервер отвечает на запрос клиента напрямую (не через loadbalance).
2. NAT В этом режиме перенаправление пакетов на реальный сервер с изменением адреса назначения. Адрес назначения будет заменен адресом реального сервера (NAT). В этом режиме вашему реальному серверу не нужен публичный IP, он может использовать вашу локальную сеть. И тогда пакет будет доставлен без нового адреса назначения. Когда реальный сервер получит пакет, он будет отвечать на адрес запроса клиента через шлюз (баланс нагрузки). В этом режиме ваш баланс нагрузки используется в качестве маршрутизатора и шлюза вашего реального сервера.
3. Туннель В этом режиме пакет будет туннелирован с новым адресом src-dst (например, vpn) для доставки пакета на реальный сервер. Когда пакет получен в RealServer, RealServer будет отвечать через туннелированный канал для балансировки нагрузки. И тогда ответная нагрузка доставляет ответ на реальный адрес источника запроса.
Для HTTPS / SSL балансировка нагрузки не обрабатывается, процесс балансировки нагрузки до уровня 4 OSI. Слой 5 выше будет обрабатываться в реальном сервере. Так что по TCP 3 way hanshake, по SSL / HTTPS он протекал в реальном сервере. Loadbalance только директор пакета.
Я надеюсь, что мое маленькое объяснение будет чем-то помочь.
источник
Балансировщик нагрузки может быть маршрутизатором или обратным прокси-сервером:
LVS является отраслевым стандартом модуля балансировки нагрузки уровня 4 (на основе маршрутизации) для ядра Linux. Он используется в различных коммерческих балансировщиках нагрузки, включая Barracuda, Loadbalancer.org и Kemp Technologies. Barracuda и Loadbalancer.org также используют HAProxy для балансировки нагрузки на уровне 7 (на основе обратного прокси-сервера ).
Ps. Я забыл, это не показывает, откуда я, очевидно, Loadbalancer.org
источник