Я часто вижу архитектуры веб-приложений с SLB / обратным прокси-сервером перед кучей серверов приложений.

Что происходит, когда для количества соединений с SLB требуется слишком много ресурсов для эффективной обработки одним SLB? Для конкретного, но все же чрезмерного примера рассмотрим 2 миллиона постоянных HTTP-соединений. Очевидно, что один SLB не может справиться с этим.

Какова рекомендуемая конфигурация для масштабирования из более SLB?

Типично ли создавать группу / кластер LB? Если да, то как распределяется нагрузка на клиента между группами LB?

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

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

• DNS Round Robin для публикации нескольких 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-запросов в секунду. Так что не делайте преждевременную оптимизацию, не занимайтесь этим раньше, чем нужно.

Ключом для масштабирования уровня балансировки нагрузки 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 |
       + ------ + + ------ + + ------ + + ------ +

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

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

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

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

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

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

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