У меня есть 2 сервера (S1, S2) с IP-адресами 1.1.1.1 и 1.1.1.2, и я хотел бы распределить нагрузку трафика на www.example.com им. Я думаю о том, чтобы иметь машину на 1.1.1.3, которая будет балансировщиком нагрузки: DNS example.com будет указывать на 1.1.1.3, а LB перенаправит на 1.1.1.1 или 1.1.1.2.
Вопрос: Клиент веб-браузера отправляет файл размером 1 МБ в example.com. Проходит ли файл полностью через LB перед переходом на S1? Я имею в виду, все ли пакеты проходят от клиента к LB к S1? Или бывает так: браузер запрашивает example.com, DNS возвращает IP 1.1.1.3 (LB), затем для первого пакета LB сообщает клиенту «Эй, поговорите с 1.1.1.1 вместо этого», и поэтому веб-браузер отправляет все свои HTTP-пакеты на S1 1.1. 1.1 и так LB получает всего 0,001% от общего трафика?
Другая возможность заключается в том, что мы предполагаем, что запрос большой с точки зрения доступа к ЦП / базе данных и т. Д., И, поскольку балансировщик нагрузки не будет обрабатывать запрос (и просто передать его), он все равно будет полезен, даже если он поглощает все трафик
Я надеюсь, что все произойдет, как я говорю, но я недостаточно знаю о протоколе http, чтобы ответить; Я видел какое-то коммерческое оборудование, которое делает это, поэтому мне интересно, существует ли чистое программное решение.
Я не родной английский, мой вопрос очень простой, я думаю, поэтому, если он кажется сложным, не стесняйтесь попросить меня переформулировать :)
так LB получает только 0,001% от общего трафика?
Нет. Все трафик будет проходить через балансировщик нагрузки. Затем балансировщик нагрузки будет передавать трафик на фактический целевой сервер.
Да, балансировщик нагрузки - это единственная точка отказа (балансировка нагрузки - это не HA). Если вам нужна высокая доступность, приобретите два балансировщика нагрузки.
Балансировщик нагрузки обычно работает аналогично обратному прокси.
Клиент инициирует соединение с балансировщиком нагрузки и отправляет ему свой запрос.
Балансировщик нагрузки принимает запрос и передает его внутреннему узлу и ждет ответа.
Он получает ответ и пересылает его исходному клиенту.
Так что да, через него будет проходить полный трафик, как запрос, так и ответы.
Существуют разные виды балансировки нагрузки. У вас может быть несколько общедоступных IP-адресов, которые отображаются в записях DNS. Каждый из этих IP-адресов может указывать непосредственно на сервер. Затем клиент будет выбирать среди них, и клиент может переключаться между ними. Вы не должны слишком полагаться на переключение между серверами, если вы оставите это на усмотрение клиента.
Вы можете изменить приведенный выше сценарий, не передавая все свои общедоступные IP-адреса во всех DNS-запросах. Есть несколько причин, по которым не раздаются все ваши общедоступные IP-адреса:
Вышеупомянутые методы обычно известны как балансировка нагрузки на основе DNS.
На следующем уровне цепочки ваши общедоступные IP-адреса могут быть виртуальными IP-адресами, которые можно переносить между разными аппаратными устройствами. Каждый виртуальный IP-адрес может быть маршрутизирован только на одно оборудование за раз, поэтому не имеет смысла иметь на этом уровне намного больше блоков, чем у вас есть общедоступные IP-адреса.
Такие виртуальные IP-адреса чаще используются для обеспечения доступности, они не очень гибкие в качестве решения для балансировки нагрузки.
На следующем уровне у вас может быть обычный балансировщик нагрузки. Балансировщик нагрузки получает запросы от клиентов и перенаправляет их на пул серверов. Весь трафик от клиента к серверу должен проходить через балансировщик нагрузки, но обработка, которую необходимо выполнить балансировщику нагрузки, может быть чрезвычайно легкой.
Этот уровень балансировщика нагрузки может работать в двух разных режимах. Они могут работать либо в обычном прокси-режиме, в котором одно TCP-соединение используется между клиентом и балансировщиком нагрузки, а другое TCP-соединение используется между балансировщиком нагрузки и сервером, либо в режиме DSR, в котором TCP-соединения завершаются на серверах позади. балансировщик нагрузки.
В режиме прокси балансировщик нагрузки должен обрабатывать не только все пакеты от клиентов. Он также должен обрабатывать все пакеты от серверов обратно клиентам. А балансировщику нагрузки нужен полный стек TCP с буферизацией и повторными передачами.
В режиме DSR балансировщику нагрузки требуется только простое отслеживание каждого соединения от клиентов. Это значительно снижает использование памяти балансировщиком нагрузки. Это также означает, что пакеты от сервера к клиенту не проходят через балансировщик нагрузки, они отправляются непосредственно клиенту (очевидно, проходя через маршрутизаторы по пути). Это свойство является причиной того, что этот режим называется прямым возвратом с сервера.
Недостаток режима DSR в том, что конфигурация сети немного сложнее. Пакеты от балансировщика нагрузки на сервер не могут полагаться только на обычную маршрутизацию. Поскольку он не перезаписывает IP-адрес назначения пакетов от клиента к серверу, ему необходимо манипулировать адресом назначения на более низком уровне протокола, чтобы направить пакет на правильный сервер, или вставить уровень туннелирования, чтобы иметь уровень, на котором можно разместить такой адрес назначения.
Все вышеперечисленные методы можно накладывать друг на друга. Вот как вы можете создать сайт, рассчитанный на сотни миллионов пользователей.