Что возвращает балансировщик нагрузки?

Когда пользователь нажимает на балансировщик нагрузки, а балансировщик нагрузки определяет, какой веб-сервер следует пересылать, что происходит дальше? Направляет ли балансировщик нагрузки запрос и все его данные на веб-сервер, получает ответ веб-сервера и возвращает его обратно пользователю?

Или это больше похоже на перенаправление, когда балансировщик нагрузки буквально просто возвращает IP-адрес выбранного сервера обратно в браузер, и браузер должен открыть новое соединение с данным сервером?

Мой инстинкт говорит, что это не будет последним, потому что это будет означать, что все IP-адреса веб-сервера будут общедоступными, и я подумал, что из соображений безопасности лучше всего показывать только адреса балансировщиков нагрузки. Но опять же, я не совсем уверен, потому что, если вы включите SSL terminationбалансировщик нагрузки, не нужно ли будет повторно устанавливать SSL с перенаправленным сервером?

Конечный IP не опубликован. На самом деле этот процесс работает таким образом, что клиент (пользователь нажимает на балансировщик) считает, что он взаимодействует с балансировщиком, общаясь с реальным узлом.

В очень простом объяснении большинство транзакций работают так:

1. Пользователь делает запрос к балансировщику нагрузки.
2. Балансировщик решает, какой узел является наиболее подходящим (на основе стратегии, которую вы используете для балансировки), и выбирает (изменяет) IP-адрес назначения.
3. (Вот где происходит волшебство.) Узел получает запрос, принимает соединение и отвечает обратно на балансировщик.
4. Балансировщик меняет ответный IP-адрес обратно на виртуальный, балансирующий, и передает ответ пользователю.
5. Вуаля, пользователь получает ответ с 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