Ключом для масштабирования уровня балансировки нагрузки HTTP является добавление еще одного уровня балансировки нагрузки более низкого уровня (IP или TCP). Этот уровень может быть полностью построен с помощью программного обеспечения с открытым исходным кодом, хотя вы получите лучшие результаты, если у вас есть современные маршрутизаторы.
Потоки (сеансы TCP) должны хэшироваться с использованием заголовков, таких как IP-адрес источника / назначения и TCP-порты, чтобы решить, к какому интерфейсу они идут. Вы также нуждаетесь в механизме, который гарантирует, что когда интерфейс умирает, он перестает привыкать.
Существуют различные стратегии, я собираюсь обрисовать пару, которые я использовал в работе на сайтах, обслуживающих миллионы пользователей, так что вы можете понять эту идею. Было бы слишком долго объяснять все в деталях, но я надеюсь, что этот ответ даст вам достаточно информации / указателей, чтобы начать. Для реализации этих решений вам понадобится кто-то, кто действительно разбирается в сетях.
По общему признанию, то, что я описываю здесь, реализовать намного сложнее, чем то, что описано в других ответах, но это действительно современный уровень, если у вас высокодоходный веб-сайт с большими проблемами масштабируемости и требованиями к доступности, превышающими 99,9%. , При условии, что у вас уже есть сетевой инженер, он стоит меньше для установки и запуска (как в капитальных, так и в операционных расходах), чем устройства балансировки нагрузки, и его можно масштабировать дальше практически без дополнительных затрат (по сравнению с покупкой нового, даже более дорогого). дорогой прибор, когда вы перерастаете свою текущую модель).
Первая стратегия: с брандмауэром
Предположительно у вас есть пара маршрутизаторов, к которым подключены ваши интернет-провайдеры. Ваш провайдер предоставляет 2 ссылки (активную / пассивную, с использованием VRRP). На ваших маршрутизаторах вы также используете VRRP и маршрутизируете трафик, идущий в вашу публичную сеть, на межсетевой экран. Брандмауэры ( FW 1и FW 2ниже) также активны / пассивны и будут фильтровать трафик и отправлять каждый поток на исправный сервер внешнего интерфейса (ваши балансировщики нагрузки HTTP FE 1и FE 2ниже).
+ -------------- + + -------------- +
| Интернет-провайдер маршрутизатор A | | Интернет-провайдер B |
+ -------------- + + -------------- +
| |
== # ====================== # == (общедоступная сеть)
| |
+ --------------- + + --------------- +
| Ваш роутер A | | Ваш роутер B |
+ --------------- + + --------------- +
| |
== # ===== # ========== # ===== # == (частная сеть RFC 1918)
| | | |
+ ------ + + ------ + + ------ + + ------ +
| FW 1 | | FE 1 | | FE 2 | | FW 2 |
+ ------ + + ------ + + ------ + + ------ +
Цель состоит в том, чтобы поток выглядел так:
- Интернет-провайдер направляет трафик, идущий на ваши IP-адреса, на ваш активный маршрутизатор.
- Маршрутизаторы маршрутизируют трафик к VIP, который использует адрес RFC 1918 . Этот VIP принадлежит активному файерволу, так же, как VRRP. Если вы используете OpenBSD для своих нужд брандмауэра, вы можете использовать CARP , не имеющую патентов альтернативу VRRP / HSRP.
- Ваш брандмауэр применяет фильтр (например, «разрешить только 80 / tcp и 443 / tcp переходить на этот конкретный IP-адрес»).
- Ваш брандмауэр также действует как маршрутизатор и перенаправляет пакеты на работоспособный интерфейс.
- Ваш веб-интерфейс завершает TCP-соединение.
Теперь волшебство происходит в шагах 4 и 5, поэтому давайте посмотрим более подробно, что они делают.
Ваш брандмауэр знает список внешних интерфейсов ( FE 1и FE 2), и он выберет один из них на основе определенного аспекта потока (например, путем хэширования исходного IP-адреса и порта, среди других заголовков). Но также необходимо убедиться, что он перенаправляет трафик на здоровый интерфейс, в противном случае вы станете черным дыром. Если вы используете OpenBSD, например, вы можете использовать relayd. какаяrelayddo прост: он проверяет работоспособность всех ваших веб-интерфейсов (например, отправляя им тестовый HTTP-запрос), и всякий раз, когда веб-интерфейс работает исправно, он добавляет его в таблицу, которую использует брандмауэр для выбора следующего перехода пакетов данного потока , Если веб-интерфейс не проходит проверку работоспособности, он удаляется из таблицы и пакеты ему больше не отправляются. При пересылке пакета во внешний интерфейс все, что делает брандмауэр, - это обменивает MAC-адрес назначения пакета на адрес выбранного веб-интерфейса.
На шаге 5 пакеты от пользователя принимаются вашим балансировщиком нагрузки (будь то Varnish, Nginx или что-то еще). На этом этапе пакет по-прежнему направляется на ваш общедоступный IP-адрес, поэтому вам необходимо присвоить псевдоним своим VIP-пользователям в интерфейсе обратной связи. Это называется DSR (Direct Server Return), потому что ваши интерфейсы завершают TCP-соединение, а межсетевой экран между ними видит только симплексный трафик (только входящие пакеты). Ваш маршрутизатор будет направлять исходящие пакеты прямо обратно на маршрутизаторы интернет-провайдера. Это особенно хорошо для HTTP-трафика, потому что запросы, как правило, меньше, чем ответы, иногда значительно. Просто чтобы прояснить: это не специфическая вещь для OpenBSD и широко используется на сайтах с высокой посещаемостью.
Gotchas:
- Конечные пользователи будут напрямую подключаться к вашим внешним серверам, потому что вы используете DSR. Возможно, это уже имело место, но если это не так, вам нужно убедиться, что они надежно защищены.
- Если вы используете OpenBSD, помните, что ядро является однопоточным, поэтому производительность одного ядра ЦП ограничит пропускную способность брандмауэра. Это может быть проблемой в зависимости от типа сетевого адаптера и скорости передачи пакетов, которую вы видите. Есть способы решить эту проблему (подробнее об этом ниже).
Вторая стратегия: без брандмауэра
Эта стратегия более эффективна, но сложнее в настройке, поскольку она больше зависит от специфики имеющихся у вас маршрутизаторов. Идея состоит в том, чтобы обойти вышеупомянутый межсетевой экран и заставить маршрутизаторы выполнять всю работу, которую выполнял межсетевой экран.
Вам понадобятся маршрутизаторы, которые поддерживают ACL L3 / L4 для каждого порта, BGP и ECMP , а также маршрутизацию на основе политик (PBR). Только высокопроизводительные маршрутизаторы поддерживают эти функции, и они часто имеют дополнительные лицензионные сборы для использования BGP. Как правило, это все еще дешевле, чем аппаратные балансировщики нагрузки, а также гораздо проще масштабировать. Хорошая вещь об этих высокопроизводительных маршрутизаторах состоит в том, что они имеют тенденцию быть линейной скоростью (например, они всегда могут максимизировать канал, даже на интерфейсах 10GbE, потому что все решения, которые они принимают, принимаются аппаратно ASIC).
На портах, на которых у вас есть восходящие соединения вашего провайдера, примените ACL, который раньше был на брандмауэре (например, «разрешить 80 / tcp и 443 / tcp переходить на этот конкретный IP-адрес»). Затем попросите каждого из ваших интерфейсов поддерживать сеанс BGP с вашим маршрутизатором. Вы можете использовать отличный OpenBGPD (если ваши интерфейсы на OpenBSD) или Quagga . Ваш маршрутизатор будет ECMP-трафик к работоспособным внешним интерфейсам (потому что они поддерживают свои сеансы BGP). Маршрутизатор также направит трафик соответствующим образом, используя PBR.
Уточнения
- С парным решением брандмауэра было бы хорошо, если бы вы могли синхронизировать состояния TCP через брандмауэры, чтобы при сбое одного брандмауэра все переходило на другой плавно. Вы можете достичь этого с
pfsync.
- Имейте в виду, что
pfsyncна брандмауэрах обычно удваивается скорость передачи пакетов.
- HTTP - это протокол без сохранения состояния, так что это не конец света, если вы сбрасываете все соединения во время аварийного переключения межсетевого экрана, потому что вы не используете
pfsync.
- Если вы переросли один брандмауэр, вы можете использовать ECMP на своем маршрутизаторе для маршрутизации трафика на более чем одну пару брандмауэров.
- Если вы используете более одной пары брандмауэров, вы также можете сделать их активными / активными. Этого можно добиться, если брандмауэры будут поддерживать сеанс BGP с маршрутизаторами, так же, как внешним интерфейсам необходимо поддерживать один из них во втором варианте без брандмауэров.
Пример relaydконфигурации
Смотрите также HOWTO на https://calomel.org/relayd.html.
vip = "1.2.3.4" # Ваш публичный IP-адрес
# (вы можете иметь более одного, но не обязательно)
fe1 = "10.1.2.101"
fe2 = "10.1.2.102"
Fe3 = "10.1.2.103"
fe4 = "10.1.2.104" # Вы можете иметь любое количество интерфейсов.
int_if = "em0"
таблица <fe> {$ fe1 retry 2, $ fe2 retry 2, $ fe3 retry 2, $ fe4 retry 2}
таблица <fallback> {127.0.0.1}
перенаправить webtraffic {
прослушивать порт $ vip 80
тайм-аут сеанса 60
путь к <fe> проверке http "/healthcheck.html" digest "(sha1sum of healthcheck.html)" interface $ int_if
}