Каков типичный метод масштабирования балансировки нагрузки программного обеспечения?

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

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

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

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

21 голос | спросил z8000 11 Maypm11 2011, 18:24:23

6 ответов


10

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

ответил Hyppy 11 Maypm11 2011, 18:45:37
18

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

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

ответил Jesper Mortensen 12 Maypm11 2011, 13:33:55
9

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

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

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

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

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

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

      + -------------- + + -------------- +
      | ISP-маршрутизатор A | | ISP-маршрутизатор B |
      + -------------- + + -------------- +
             | |
           == # ====================== ======================================================================================================
             | |
      + --------------- + + --------------- +
      | Ваш маршрутизатор A | | Ваш маршрутизатор B |
      + --------------- + + --------------- +
             | |
           == # ===== # ========== # ===== # == (частная сеть RFC 1918)
             | | | |
       + ------ + + ------ + + ------ + + ------ +
       | FW 1 | | FE 1 | | FE 2 | | FW 2 |
       + ------ + + ------ + + ------ + + ------ +

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

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

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

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

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

Gotchas:

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

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

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

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

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

Уточнения

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

Пример pfsync config

См. также 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" дайджест "(sha1sum of healthcheck.html)" интерфейс $ int_if
}
ответил tsuna 12 J000000Tuesday11 2011, 09:58:23
2

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

ответил Chopper3 11 Maypm11 2011, 18:32:41
1

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

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

ответил Mxx 8 J000000Friday11 2011, 22:41:48
0

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

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

ответил Martin 11 Maypm11 2011, 18:48:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132