ОК, принятый ответ уже есть, но есть что добавить .. Наиболее распространенные "классические" способы масштабирования уровня балансировщика нагрузки: (в произвольном порядке):

• Циклический перебор DNS для публикации нескольких IP-адресов для домена. Для каждого IP-адреса реализуйте пару серверов с высокой доступностью (2 сервера, взаимодействующие друг с другом для обеспечения постоянной работы одного IP-адреса). Каждый IP-адрес соответствует одному кластеру балансировки нагрузки, используя устройства или серверы с программным обеспечением для балансировки нагрузки. Масштабируйте по горизонтали, добавляя при необходимости больше пар балансировщиков нагрузки.

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

• Слой Балансировщики нагрузки на уровне IP перед слоем балансировщиков нагрузки уровня HTTP. Балансировка нагрузки на уровне IP может быть реализована в микросхемах ASIC / микросхемах и может быть очень быстрой для некоторых вещей. Таким образом, одна пара балансировщиков IP-нагрузки часто может «не отставать» от нескольких балансировщиков нагрузки уровня HTTP / HTTPS и обеспечивать уровни производительности в несколько гигабит, сохраняя при этом красивую и простую архитектуру.

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

Неважно, выберете ли вы форм-фактор устройства (F5, Cisco, A10) или обычный сервер (Windows / Linux + программное обеспечение). Основные соображения при масштабировании уровня балансировщика нагрузки:

• С полным или без гражданства. Вам абсолютно необходимы липкие сеансы или вы можете жить без них? Несоблюдение состояния делает все проще.
• «Аппаратное обеспечение» (ASIC) против «программного обеспечения» (серверы общего назначения) для балансировки нагрузки. У каждого есть свои плюсы и минусы, см. Обзорную документацию HAProxy по ссылке выше.
• Балансировка нагрузки L3 / 4 (IP / TCP / IP) по сравнению с L7 (HTTP) балансировки нагрузки. Опять же, плюсы и минусы, документ HAProxy дает хороший обзор.
• Завершение SSL, где: на веб-узлах или в балансировщике нагрузки.

Как правило, вам не нужно беспокоиться об этом, прежде чем ваш сайт получит очень большой - один современный сервер с fx nginx будет обрабатывать десятки тысяч простых HTTP-запросов в секунду. Так что не проводите преждевременную оптимизацию, не занимайтесь этим до того, как это понадобится.

Балансировщики нагрузки не могут быть легко масштабированы другими балансировщиками нагрузки, так как по сути будет один балансировщик нагрузки в цепочке где-то, поддерживающий соединения. Тем не менее, балансировщики, такие как LVS или HAProxy, имеют абсурдную пропускную способность в диапазоне Гбит / с. Как только вы выйдете за пределы возможностей одного балансировщика нагрузки (программного, аппаратного и т. Д.), Вам нужно будет перейти к другим методам, таким как циклический DNS.

Ключ к масштабированию уровня балансировки нагрузки HTTP - это сначала добавить еще один уровень балансировки нагрузки нижнего уровня (IP или TCP). Этот уровень может быть полностью построен с помощью программного обеспечения с открытым исходным кодом, хотя вы получите лучшие результаты, если у вас есть современные маршрутизаторы.

Потоки (сеансы TCP) должны быть хешированный используя заголовки, такие как IP-адрес источника / назначения и TCP-порты, чтобы решить, к какому интерфейсу они переходят. Вам также нужен механизм, чтобы гарантировать, что когда фронтенд умирает, он перестает использоваться.

Существуют различные стратегии, я собираюсь описать пару, которые я использовал в продакшене на сайтах, обслуживающих миллионы пользователей, чтобы вы могли понять идею. Было бы слишком долго объяснять все подробно, но я надеюсь, что этот ответ даст вам достаточно информации / указателей, чтобы начать работу. Для реализации этих решений вам понадобится кто-то, действительно хорошо разбирающийся в сетевых технологиях.

По общему признанию, то, что я описываю здесь, намного сложнее реализовать, чем то, что описано в других ответах, но это действительно современное состояние, если у вас есть веб-сайт с высокой посещаемостью, с большими проблемами масштабируемости и требованиями к доступности более 99,9% . Если у вас уже есть какой-то специалист по сетевым технологиям, его установка и запуск обходятся дешевле (как в капитальных, так и в операционных), чем устройства балансировки нагрузки, и его можно масштабировать дальше почти без дополнительных затрат (по сравнению с покупкой нового, даже больше). дорогой прибор, когда вы перерастете свою текущую модель).

Первая стратегия: с брандмауэром

Предположительно у вас есть пара маршрутизаторов, к которым подключены восходящие каналы вашего интернет-провайдера. Ваш интернет-провайдер предоставляет 2 ссылки (активный / пассивный, с использованием VRRP). На своих маршрутизаторах вы также используете VRRP и маршрутизируете трафик, идущий в вашу общедоступную сеть, на брандмауэр. Межсетевые экраны (FW 1 и FW 2 ниже) также являются активными / пассивными и будут фильтровать трафик и отправлять каждый поток на исправный интерфейсный сервер (ваши балансировщики нагрузки HTTP, FE 1 и FE 2 ниже).

      +--------------+       +--------------+
      | ISP router A |       | ISP router B |
      +--------------+       +--------------+
             |                      |
           ==#======================#==   (public network)
             |                      |
      +---------------+     +---------------+
      | Your router A |     | Your router B |
      +---------------+     +---------------+
             |                      |
           ==#=====#==========#=====#==   (RFC 1918 private network)
             |     |          |     |
       +------+ +------+  +------+ +------+
       | FW 1 | | FE 1 |  | FE 2 | | FW 2 |
       +------+ +------+  +------+ +------+

Цель состоит в том, чтобы поток выглядел так:

1. Интернет-провайдер направляет трафик, идущий с ваших IP-адресов, на ваш активный маршрутизатор.
2. Ваши маршрутизаторы направляют трафик на VIP, который использует RFC 1918 адрес. Этот VIP принадлежит активному межсетевому экрану, как и VRRP. Если вы используете OpenBSD для своего брандмауэра, вы можете использовать Карп, беспатентная альтернатива VRRP / HSRP.
3. Ваш брандмауэр применяет фильтр (например, «разрешить доступ только 80 / tcp и 443 / tcp к этому конкретному IP-адресу»).
4. Ваш брандмауэр также действует как маршрутизатор и пересылает пакеты исправному интерфейсу.
5. Ваш интерфейс разрывает TCP-соединение.

Теперь волшебство происходит на шагах 4 и 5, поэтому давайте подробнее рассмотрим, что они делают.

Ваш брандмауэр знает список интерфейсов (FE 1 и FE 2), и он выберет один из них на основе определенного аспекта потока (например, путем хеширования исходного IP-адреса и порта, среди других заголовков). Но он также должен убедиться, что он перенаправляет трафик на работоспособный интерфейс, иначе вы получите черный трафик. Если вы, например, используете OpenBSD, вы можете использовать relayd. какой relayd делает это просто: он проверяет работоспособность всех ваших интерфейсов (например, отправляя им пробный HTTP-запрос), и всякий раз, когда интерфейс исправен, он добавляет его в таблицу, которую межсетевой экран использует для выбора следующего перехода пакетов заданного потока . Если интерфейс не проходит проверку работоспособности, он удаляется из таблицы, и пакеты ему больше не отправляются. При пересылке пакета во внешний интерфейс все, что делает брандмауэр, - это подменяет MAC-адрес назначения пакета на MAC-адрес выбранного внешнего интерфейса.

На шаге 5 пакеты от пользователя принимаются вашим балансировщиком нагрузки (будь то Varnish, nginx или что-то еще). На этом этапе пакет по-прежнему направлен на ваш общедоступный IP-адрес, поэтому вам необходимо назначить псевдонимы своим VIP-адресам на интерфейсе обратной связи. Это называется DSR (Прямой возврат сервера), потому что ваши интерфейсы завершают TCP-соединение, а межсетевой экран между ними видит только симплексный трафик (только входящие пакеты). Ваш маршрутизатор будет направлять исходящие пакеты прямо обратно на маршрутизаторы интернет-провайдера. Это особенно хорошо для HTTP-трафика, потому что запросы обычно меньше ответов, а иногда и значительно. Чтобы быть ясным: это не специфическая вещь OpenBSD и широко используется на веб-сайтах с высокой посещаемостью.

Попытки:

• Конечные пользователи будут напрямую подключаться к вашим интерфейсным серверам, потому что вы используете DSR. Возможно, это уже было так, но если это не так, вам нужно убедиться, что они надежно защищены.
• Если вы используете OpenBSD, помните, что ядро ​​является однопоточным, поэтому производительность одного ядра ЦП ограничит пропускную способность межсетевого экрана. Это может быть проблема в зависимости от вашего типа сетевой карты и скорости передачи пакетов, которую вы видите. Есть способы решить эту проблему (подробнее об этом ниже).

Вторая стратегия: без межсетевого экрана

Эта стратегия более эффективна, но ее сложнее настроить, потому что она больше зависит от специфики маршрутизаторов, которые у вас есть. Идея состоит в том, чтобы обойти указанный выше брандмауэр и заставить маршрутизаторы выполнять всю работу, которую выполняли брандмауэры.

Вам понадобятся маршрутизаторы, поддерживающие списки ACL L3 / L4 для каждого порта, BGP и ECMP, и Маршрутизация на основе политик (PBR). Только высокопроизводительные маршрутизаторы поддерживают эти функции, и они часто требуют дополнительных лицензионных сборов для использования BGP. Обычно это дешевле, чем аппаратные балансировщики нагрузки, а также гораздо проще масштабировать. Преимущество этих высокопроизводительных маршрутизаторов заключается в том, что они, как правило, имеют линейную скорость (например, они всегда могут максимизировать канал, даже на интерфейсах 10GbE, потому что все решения, которые они принимают, выполняются аппаратно с помощью ASIC).

На портах, на которых у вас есть восходящие каналы ISP, примените ACL, который раньше был на брандмауэре (например, «разрешить только 80 / tcp и 443 / tcp переходить на этот конкретный IP-адрес»). Затем пусть каждый из ваших интерфейсов поддерживает сеанс BGP с вашим маршрутизатором. Вы можете использовать отличный OpenBGPD (если ваши интерфейсы на OpenBSD) или Quagga. Ваш маршрутизатор будет ECMP передавать трафик работающим интерфейсам (поскольку они поддерживают свои сеансы BGP). Маршрутизатор также будет направлять трафик соответствующим образом, используя PBR.

Уточнения

• При использовании пары брандмауэров хорошо, если вы можете синхронизировать состояния TCP между брандмауэрами, чтобы при выходе из строя одного брандмауэра все плавно переключалось на другой. Вы можете добиться этого с помощью pfsync.
  • Помните, что pfsync обычно удваивает скорость передачи пакетов на ваших брандмауэрах.
  • HTTP - это протокол без сохранения состояния, так что это не конец света, если вы сбросите все соединения во время переключения брандмауэра, потому что вы не используете pfsync.
• Если вы перерастете один брандмауэр, вы можете использовать ECMP на своем маршрутизаторе для маршрутизации трафика на более чем одну пару брандмауэров.
• Если вы используете более одной пары брандмауэров, вы можете сделать их все активными / активными. Этого можно добиться, если межсетевые экраны поддерживают сеанс BGP с маршрутизаторами, во многом так же, как внешние интерфейсы должны поддерживать сеанс во втором варианте без межсетевых экранов.

Образец relayd config

См. Также HOWTO на https://calomel.org/relayd.html

vip="1.2.3.4"  # Your public IP address
               # (you can have more than one, but don't need to)
fe1="10.1.2.101"
fe2="10.1.2.102"
fe3="10.1.2.103"
fe4="10.1.2.104"  # You can have any number of frontends.
int_if="em0"
table <fe> { $fe1 retry 2, $fe2 retry 2, $fe3 retry 2, $fe4 retry 2 }
table <fallback> { 127.0.0.1 }

redirect webtraffic {
        listen on $vip port 80
        session timeout 60
        route to <fe> check http "/healthcheck.html" digest "(the sha1sum of healthcheck.html)" interface $int_if
}

Лично я использую более простые, менее настраиваемые аппаратные балансировщики нагрузки - такие как Cisco ACE / ASA, Foundry ServerIrons, возможно, даже Zeus ZXTM (SW LB, предназначенный для очень больших нагрузок).

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

Действительно ли все, что вы делаете, требует ответа именно в эту миллисекунду, или клиент может подождать 15/20 секунд до следующего периода опроса?

Типичный подход - создать кластер, достаточно большой для обработки требуемой нагрузки, и использовать SLB, который может выполнять детерминированную балансировку нагрузки (для случая постоянных соединений).

Что-то вроде CARP использует хэш запрашивающего IP-адреса, чтобы определить, какой внутренний веб-сервер будет обрабатывать запрос, это должно быть детерминированным, но не очень полезным, если перед вашим балансировщиком нагрузки есть брандмауэр или NAT.
Вы также можете найти что-то вроде IPVS полезно, если вы работаете в Linux.