что такое load balancing

Балансировка нагрузки с помощью AWS ELB

Всем привет! Уже сегодня стартует курс «AWS для разработчиков», в связи с чем мы провели соответствующий тематический вебинар, посвященный обзору ELB. Мы рассмотрели виды балансировщиков и создали несколько инстансов EC2 с балансировщиком. А также изучили другие примеры использования.

Прослушав вебинар, вы будете:

Введение

Что такое Elastic Load Balancer, можно увидеть на диаграмме ниже, где представлен простейший пример:

Load Balancer принимает реквесты и распределяет их по инстансам. У нас есть один отдельный инстанс, есть Lambda-функции и есть AutoScaling-группа (группа серверов).

Типы AWS ELB

1. Рассмотрим основные типы:

Classic Load Balancer. Самый первый балансировщик от AWS, работает как на 4-м, так и на 7-м уровне OSI, поддерживаются HTTP, HTTPS, TCP и SSL. Он обеспечивает базовую балансировку нагрузки между несколькими инстансами Amazon EC2 и работает как на уровне запросов, так и на уровне соединения. Давайте его откроем (выделен серым):

Этот балансер считается устаревшим, поэтому рекомендуется к использованию лишь в отдельных случаях. Например, для приложений, которые были построены в сети EC2‑Classic. В принципе, нам никто не мешает его создать:

2. Network Load Balancer. Подходит для высокой нагрузки, работает на 4-м уровне OSI (можно использовать в EKS и ECS), поддерживаются TCP, UDP и TLS.

Network Load Balancer направляет трафик на целевые объекты в Amazon VPC и способен обрабатывать миллионы запросов в секунду при сверхнизких задержках. Кроме того, он оптимизирован для обработки моделей трафика с внезапной и изменяющейся нагрузкой.

3. Application Load Balancer. Работает на 7-м уровне, имеет поддержку Lambda, поддерживает правила на уровне заголовков и путей, поддерживаются HTTP и HTTPS.
Обеспечивает расширенную маршрутизацию запросов, ориентированную на доставку приложений, построенных на базе современных архитектур, в том числе микросервисы и контейнеры. Направляет трафик на целевые объекты в Amazon VPC, опираясь на содержимое запроса.

Для многих пользователей, Application Load Balancer первым делом заменил Classic Load Balancer, ведь TCP не так распространен в отличие от HTTP.

Создадим его тоже, в результате чего у нас уже будут два балансировщика нагрузки:

Компоненты Load Balance

Общие компоненты Load Balance (присущи всем балансировщикам):

Потом указываем S3Bucket — объектное хранилище Amazon:

Пример для Classic Load Balancer:

А вот в Application Load Balancer мы видим и немного другой интерфейс, и в целом другую логику:

Компоненты Load Balancer v2 (ALB и NLB)

Теперь подробнее рассмотрим балансировщики 2-й версии Application Load Balancer и Network Load Balancer. У этих балансировщиков есть свои компонентные особенности. Например, появилось такое понятие, как Target Groups — инстансы (и функции). Благодаря этому компоненту, у нас появилась возможность указывать, на какой из Target Groups мы хотим направлять трафик.

Говоря простым языком, в Target Groups мы указываем инстансы, куда будет приходить трафик. Если в том же Classic Load Balancer вы просто сразу подключаете интенсы к балансировщику, то в Application Load Balancer вы сначала:

Следующий компонент — Listener rules (правила для маршрутизации). Это уже касается только Application Load Balancer. Если в Network Load Balancer вы просто создаете Listener, и он шлет трафик на конкретную Target-группу, то в Application Load Balancer всё веселее и удобнее.

Теперь скажем пару слов про следующий компонент — Elastic IP (статические адреса для NLB). Если правила для маршрутизации Listener rules касались только Application Load Balancer, то Elastic IP касается только Network Load Balancer.

Создадим Network Load Balancer:

И как раз в процессе создания мы увидим, что нам дается возможность выбрать Elastic IP:

Elastic IP предоставляет единственный IP-адрес, который можно связать с разными экземплярами EC2 во времени. Если экземпляр EC2 имеет Elastic IP-адрес и этот экземпляр завершен или остановлен, можно немедленно связать новый экземпляр EC2 с адресом Elastic IP. При этом ваше текущее приложение не прекратит работу, так как приложения видят всё тот же IP-адрес, даже если реальный EC2 изменился.

Вот еще один юз-кейс на тему того, зачем нужен Elastic IP. Смотрите, мы видим 3 IP-адреса, но они не навсегда здесь останутся:

Amazon меняет их с течением времени, может делать это каждые 60 секунд (но на практике, конечно, реже). Значит, IP-адреса могут поменяться. А в случае с Network Load Balancer вы как раз можете привязать айпишник и указывать его в ваших правилах, политиках и т. п.

Делаем выводы

ELB обеспечивает автоматическое распределение входящего трафика по нескольким целевым объектам (контейнеры, инстансы Amazon EC2, IP‑адреса и функции Lambda). ELB способен распределять трафик с меняющейся нагрузкой как в одной зоне доступности, так и между несколькими зонами доступности. Пользователь может выбрать из трёх типов балансировщиков, обеспечивающих и высокую доступность, и автомасштабирование, и неплохую защиту. Всё это важно для обеспечения отказоустойчивости ваших приложений.

Источник

Балансировка нагрузки

Время чтения : 7 минут

Что такое балансировка нагрузки?

Балансировка нагрузки (БН) — это метод, который гарантирует, что сервер организации не будет перегружен трафиком. Под этим определением понимается эффективное распределение входящего сетевого трафика между группой внутренних серверов, также известной как ферма серверов или пул серверов.

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

Для чего нужен балансировщик нагрузки?

Балансировщик нагрузки (Load Balancer) — сервис, помогающий серверам эффективно перемещать данные, оптимизирующий использование ресурсов доставки приложений и предотвращающий перегрузки. Он управляет потоком информации между локальным или облачным хранилищем и конечным устройством — ПК, ноутбук, планшет или смартфон. Этот сервис проводит непрерывные проверки работоспособности серверов, чтобы убедиться в их работоспособности. При необходимости подсистема балансировки удаляет неисправные серверы из пула. Входящие в состав балансировщика контроллеры доставки приложений (ADC) предлагают множество дополнительных функций — шифрование, аутентификацию и межсетевой экран веб-приложений, создавая тем самым единую точку контроля для защиты, управления и мониторинга веб-сервисов.

К таким дополнительным возможностям относятся:

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

Преимущества такого подхода:

Программные балансировщики обычно работают на менее дорогом стандартном оборудовании или в облаке и имеют ряд собственных преимуществ:

Уровни балансировки

Прежде всего, давайте разберемся с моделью взаимодействия открытых систем OSI (Open System Interconnection). Разработанная еще в 1984 году, она описывает способ передачи информации между приложениями (программами), работающими на сетевых устройствах, компьютерах, маршрутизаторах (открытых системах). На изображении ниже показаны семь уровней взаимодействия этой модели:

Балансировка нагрузки происходит непосредственно на уровнях 4 и 7.

На уровне 4 балансировщик нагрузки отслеживает сетевую информацию о портах приложений и протоколах (TCP / UDP). Он доставляет трафик, комбинируя эти ограниченные данные с алгоритмом балансировки нагрузки, таким как циклический перебор, вычисляя лучший целевой сервер, на основе наименьшего количества подключений или времени ответа. Одним из наиболее известных балансировщиков нагрузки уровня 4 является Microsoft Network Load Balancer или NLB, это программное обеспечение для балансировки нагрузки ядра сети, доступное пользователям критически важных приложений Microsoft.

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

Алгоритмы и методы балансировки

Существуют определенные алгоритмы балансировки нагрузки, определяющие оптимальные серверы для входящих клиентских запросов. Рассмотрим стандартные решения:

Преимущества облачного балансировщика

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

Аппаратные балансировщики при увеличении объема трафика, зачастую просто не справляются и поставщику приходится добавлять в пул дополнительные устройства. Это не продуктивно и поэтому на смену традиционным БН приходят облачные.

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

Резюме

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

Источник

Network Load Balancing

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

В этом разделе представлен обзор функции балансировки сетевой нагрузки (NLB) в Windows Server 2016. С помощью NLB можно управлять двумя или более серверами как одним виртуальным кластером. Балансировка сетевой нагрузки повышает доступность и масштабируемость приложений Интернет-сервера, например, используемых в Интернете, FTP, брандмауэре, прокси-сервере, виртуальной частной сети (VPN) и других критически важных серверах.

Windows Server 2016 включает новое Load Balancerное программное обеспечение Azure (SLB) в качестве компонента инфраструктуры программно-определяемой сети (SDN). используйте SLB вместо балансировки сетевой нагрузки, если вы используете SDN, используют неWindowsные рабочие нагрузки, требуется преобразование исходящего сетевого адреса (NAT) или уровень 3 (L3) или не TCP-сервер. вы можете продолжить использовать NLB с Windows Server 2016 для развертываний без SDN. Дополнительные сведения о SLB см. в разделе Программная балансировка нагрузки (SLB) для Sdn.

Компонент балансировки сетевой нагрузки (NLB) распределяет трафик по нескольким серверам с помощью сетевого протокола TCP/IP. Объединяя несколько компьютеров, на которых запущены приложения, в единый виртуальный кластер, NLB обеспечивает надежность и быстродействие веб-серверов и других ответственных серверов.

Серверы в NLB-кластере называются узлами, и на каждом узле выполняется отдельная копия серверных приложений. Балансировка сетевой нагрузки позволяет распределять входящие клиентские запросы между узлами в кластере. При этом можно настроить нагрузку для каждого узла. Если нужно обработать дополнительную нагрузку, узлы можно добавлять к кластеру динамически. Кроме того, технология балансировки сетевой нагрузки может направлять весь трафик на один предназначенный для этого узел, называемый узлом по умолчанию.

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

Практическое применение

Применение NLB целесообразно для обеспечения работы приложений, выполняемых без учета состояния, таких как веб-серверы, выполняющие службы Internet Information Services (IIS), в части их доступности с минимальной потерей машинного времени, а также масштабируемости (за счет добавления дополнительных серверов по мере увеличения нагрузки). В следующих разделах описывается применение NLB для поддержки высокой доступности, масштабируемости и управляемости кластерных серверов, выполняющих указанные приложения.

Высокий уровень доступности

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

Выявление в кластере самопроизвольно прекратившего работу или отключившегося от сети узла с последующим его восстановлением.

Балансировка нагрузки сети при добавлении и удалении узлов.

Восстановление и перераспределение рабочей нагрузки в течение 10 секунд.

Масштабируемость

Масштабируемость показывает, насколько можно расширить возможности компьютера, службы или приложения в соответствии с повышением требований к его производительности. Применительно к кластерам NLB масштабируемость — это возможность добавления одной или нескольких систем к существующему кластеру, когда общая нагрузка кластера превышает его текущую производительность. Поддержка масштабируемости реализуется в NLB следующим образом:

Балансировка запросов нагрузки в пределах NLB-кластера для отдельных служб TCP/IP.

Поддержка до 32 компьютеров в одном кластере.

Балансировка запросов нагрузки для нескольких серверов (от одного либо от нескольких клиентов) по нескольким узлам кластера.

Добавление узлов в NLB-кластер по мере увеличения нагрузки, не приводящее к сбоям в работе кластера.

Вывод узлов из состава кластера по мере уменьшения нагрузки.

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

Управляемость

Поддержка управляемости реализуется в NLB следующим образом:

Управляйте и настраивайте несколько кластеров балансировки сетевой нагрузки и узлов кластера с одного компьютера с помощью диспетчера NLB или командлетов балансировки сетевой нагрузки (NLB) в Windows PowerShell.

Используя правила управления портами, можно задавать режим балансировки для отдельного IP-порта или группы портов.

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

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

Имеется возможность блокировки доступа по сети к определенным IP-портам.

Обеспечивается поддержка протокола управления группами Интернета (IGMP) на узлах кластера для управления лавинной адресацией коммутирующего порта (в ходе которой входящие сетевые пакеты отправляются на все порты коммутатора) при работе в режиме многоадресной рассылки.

Запуск, остановка и управление действиями NLB могут производиться удаленно с использованием команд или сценариев Windows PowerShell.

События NLB можно просматривать в журнале событий Windows. В журнал событий записываются все действия NLB и изменения кластера.

Важные функции

NLB устанавливается в качестве стандартного компонента сетевого драйвера Windows Server. Его операции прозрачны для стека сетевых протоколов TCP/IP. На следующем рисунке показана связь между балансировкой сетевой нагрузки и другими компонентами программного обеспечения в типичной конфигурации.

Ниже приведены основные возможности балансировки сетевой нагрузки.

Не требует для запуска изменений аппаратной части.

Предоставляет средства балансировки сетевой нагрузки для управления несколькими кластерами и всеми узлами кластеров, а также их настройки с одного удаленного или локального компьютера.

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

При развертывании виртуальных машин в качестве виртуальных кластеров балансировка сетевой нагрузки не требует, чтобы серверы были подключены к нескольким виртуальным IP-адресам.

Средство балансировки сетевой нагрузки может быть привязано к нескольким сетевым адаптерам, что позволяет настроить несколько независимых кластеров на каждом узле. Поддержка нескольких сетевых адаптеров — это не то же самое, что виртуальные кластеры, в которых можно настраивать несколько кластеров на одном сетевом адаптере.

Не требует модификации серверных приложений, что обеспечивает их работу в любом кластере NLB.

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

Обеспечивает возможность отключения компьютеров от сети для проведения профилактического обслуживания, не затрагивая операции кластера на других узлах.

Требования к оборудованию

Ниже приведены требования к оборудованию для запуска кластера балансировки сетевой нагрузки.

Все узлы кластера должны располагаться в одной подсети.

Количество сетевых адаптеров на каждом узле не ограничено, при этом различные узлы могут иметь разное число адаптеров.

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

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

Требования к программному обеспечению

Ниже приведены требования к программному обеспечению для запуска кластера балансировки сетевой нагрузки.

Адаптер, на каждом узле которого включается NLB, может использовать только протокол TCP/IP. Не добавляйте для этого адаптера другие протоколы (например, IPX).

IP-адреса серверов в составе кластера должны быть статическими.

NLB не поддерживает протокол DHCP. NLB отключает протокол DHCP на каждом настраиваемом интерфейсе.

Сведения об установке

nlb можно установить с помощью диспетчер сервера или команд Windows PowerShell для балансировки сетевой нагрузки.

Дополнительно можно установить средства балансировки сетевой нагрузки для управления локальным или удаленным кластером NLB. к этим средствам относятся диспетчер балансировки сетевой нагрузки и команды Windows PowerShell NLB.

Установка с диспетчер сервера

Установка с Windows PowerShell

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

После завершения установки перезагрузка компьютера не требуется.

Дополнительные сведения см. в разделе Install-WindowsFeature.

Диспетчер балансировки сетевой нагрузки

Чтобы открыть диспетчер балансировки сетевой нагрузки в диспетчере сервера, в меню Сервис выберите пункт Диспетчер балансировки сетевой нагрузки.

Дополнительные ресурсы

В следующей таблице приведены ссылки на дополнительные сведения о функции балансировки сетевой нагрузки.

Источник

Введение в современную балансировку сетевой нагрузки и проксирование

Не так давно я услышал, что существует недостаток вступительных образовательных материалов о современной балансировке сетевой нагрузки и проксировании. И я подумал: как это возможно? Балансировка нагрузки — одна из основных концепций, необходимых для построения надежных распределенных систем. Разумеется, должна быть доступна качественная информация. К сожалению, это не так. Я искал и обнаружил, что материалы действительно поверхностны. В статье Википедии балансировка нагрузки и прокси-серверы содержатся обзоры некоторых понятий, но не полное разъяснение объекта, особенно в том, что касается современных микросервисных архитектур. Поиск в Google по запросу балансировки нагрузки также не предоставил мне хороших и понятных материалов.

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

Что такое балансировка сетевой нагрузки и проксирование?

Wikipedia определяет балансировку нагрузки как:

В компьютерах балансировка нагрузки распределяет нагрузку между несколькими вычислительными ресурсами, такими как компьютеры, компьютерные кластеры, сети, центральные процессоры или диски. Цель балансировки нагрузки — оптимизация использования ресурсов, максимизация пропускной способности, уменьшение времени отклика и предотвращение перегрузки какого-либо одного ресурса. Использование нескольких компонентов балансировки нагрузки вместо одного может повысить надежность и доступность за счет резервирования. Балансировка нагрузки предполагает обычно наличие специального программного обеспечения или аппаратных средств, таких как многоуровневый коммутатор или система доменных имен, как серверный процесс.

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

Обзор балансировки сетевой нагрузки

Рисунок показывает высокоуровневый обзор балансировки сетевой нагрузки. Некоторое количество клиентов запрашивает ресурсы из некоторого количества бэкендов. Балансировщик нагрузки находится между клиентами и внутренними компонентами и на высоком уровне выполняет несколько важных задач:

Правильное использование балансировки нагрузки в распределенной системе дает несколько преимуществ:

Балансировка нагрузки vs прокси-сервер

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

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

L4 (connection/session) балансировка нагрузки

В масштабах отрасли сегодня решения по балансировке нагрузки часто разделяются на две категории: L4 и L7. Они относятся к уровням 4 и 7 модели OSI. Модель OSI представляет очень плохое приближение к сложности решений балансировки нагрузки, которые включают традиционные протоколы уровня 4, такие как TCP и UDP, но часто заканчиваются включением битов и частей протоколов на разных уровнях OSI. Возникает вопрос: если балансировщик нагрузки L4 TCP также поддерживает терминирование TLS, является ли он теперь балансировщиком нагрузки L7?

Базовая балансировка нагрузки TCP L4

Рисунок показывает традиционный балансировщик нагрузки L4 TCP. В этом случае клиент устанавливает TCP-соединение с балансировщиком нагрузки. Балансировщик нагрузки завершает соединение (т.е. отвечает непосредственно на SYN), выбирает бэкенд и устанавливает новое TCP-соединение с бэкендом (т.е. отправляет новый SYN). Детали диаграммы не важны и будут подробно обсуждаться ниже — в разделе, посвященном балансировке нагрузки L4.

Основной вывод этого раздела: заключается в том, что балансировщик нагрузки L4 обычно работает только на уровне соединения/сеанса L4 TCP/UDP. Таким образом, балансировщик нагрузки грубо перетасовывает байты взад и вперед и гарантирует, что байты с того же сеанса завершаются на одном и том же бэкенде. Балансировщик L4 не знает о каких-либо деталях байтов приложения, которые перетасовывает. Байтами могут быть HTTP, Redis, MongoDB или любой другой протокол приложения.

L7 (приложение) балансировка нагрузки

Балансировка нагрузки L4 проста и по-прежнему широко используется. Каковы недостатки балансировки нагрузки L4, которые гарантируют инвестиции в балансировку нагрузки L7 (приложение)? В качестве примера возьмем следующий конкретный случай L4:

В предыдущем сценарии бэкенд, выбранный для обработки клиента A, будет обрабатывать нагрузку примерно в 3000x раз меньше, чем бэкенд, выбранный для обработки клиента B! Эта серьезная проблема, как правило, в первую очередь нарушает цель балансировки нагрузки. Также обратите внимание, что эта проблема возникает для любого протокола мультиплексирования. (Мультиплексирование означает отправку одновременных запросов приложений по одному соединению L4, а keep-alive означает команду не закрывать соединение, когда нет активных запросов). Все современные протоколы развиваются как для мультиплексирования, так и для поддержания жизнеспособности по соображениям эффективности (как правило, соединения, которые шифруются с использованием TLS, создавать дорого). Поэтому с течением времени сопротивление балансировки нагрузки L4 становится более выраженным. Эта проблема устраняется балансировщиком нагрузки L7.

HTTP/2 балансировка нагрузки L7

Рисунок показывает балансировщик нагрузки L7 HTTP/2. В этом случае клиент делает одно соединение HTTP/2 TCP с балансировщиком нагрузки. Затем балансировщик выполняет два внутренних подключения. Когда клиент отправляет два потока HTTP/2 в балансировщик нагрузки, поток 1 отправляется на бэкенд 1, в то время как поток 2 отправляется на бэкенд 2. Таким образом, даже мультиплексирование клиентов, которые имеют значительно разные нагрузки на запросы, будет эффективно балансироваться по внутренним компонентам. Вот почему балансировка нагрузки L7 так важна для современных протоколов. (Балансировка нагрузки L7 дает также множество дополнительных преимуществ из-за возможности проверки трафика приложений, но более подробно это будет рассмотрено ниже).

Балансировка нагрузки L7 и модель OSI

Как я сказал выше в разделе о балансировке нагрузки L4, использование модели OSI для описания функций балансировки нагрузки проблематично. Причина в том, что L7 уже включает несколько дискретных уровней абстракции балансировки нагрузки (по крайней мере, как описано в модели OSI). Например, для HTTP-трафика рассмотрим следующие подуровни:

Усовершенствованный балансировщик нагрузки L7 может предлагать функции, связанные с каждым из вышеперечисленных подслоев. Еще один балансировщик L7 может иметь только небольшой набор функций, которые помещают его в категорию L7. Короче говоря, ландшафт балансировки нагрузки L7 значительно сложнее с точки зрения сравнения функций, чем категория L4. (И, конечно, этот раздел только что затронул HTTP: Redis, Kafka, MongoDB и т.д. — всё это примеры протоколов приложений L7, которые выигрывают от балансировки нагрузки L7).

Функции балансировки нагрузки

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

Обнаружение службы

Обнаружение служб — это процесс, с помощью которого балансировщик нагрузки определяет набор доступных бэкендов. Методы довольно разнообразны, и некоторые примеры включают:

Проверка работоспособности

Проверка работоспособности — это процесс, с помощью которого балансировщик нагрузки определяет, доступен ли бэкенд для обслуживания трафика. Проверка работоспособности обычно подразделяется на две категории:

Балансировка нагрузки

Да, балансировщики нагрузки должны фактически балансировать нагрузку! Учитывая набор здоровых бэкендов, как выбирается бэкенд, который будет обслуживать соединение или запрос? Алгоритмы балансировки нагрузки являются активной областью исследований и варьируются от упрощенных, таких как случайный выбор и циклический алгоритм, до более сложных алгоритмов, учитывающих переменную задержку и нагрузку на бэкенд. Один из самых популярных (учитывая его производительность и простоту) алгоритмов балансировки нагрузки известен как [power of 2 least request] (https://brooker.co.za/blog/2012/01/17/two-random.html).

Sticky sessions

В некоторых приложениях важно, чтобы запросы на один и тот же сеанс достигли одного и того же бэкенда. Это может быть связано с кешированием, временным сложным состоянием и т.д. Определение сеанса варьируется и может включать HTTP-файлы cookie, свойства клиентского соединения или какой-либо другой атрибут. У многих балансировщиков нагрузки L7 есть определенная поддержка липких сеансов. Отмечу, что липкость сеанса по своей сути является хрупкой (бэкенд-хостинг сеанса может умереть), поэтому будьте осторожны при разработке системы, которая опирается на них.

TLS-терминирование

Тема TLS и ее роль достойны отдельного поста. С учетом сказанного многие балансировочные устройства L7 выполняют обработку TLS, которая включает в себя терминирование, проверку сертификатов, фиксацию и т.д.

Возможность наблюдения

Как мне нравится говорить: «Наблюдение, наблюдение, наблюдение». Сети по своей сути ненадежны, и балансировщик нагрузки часто несет ответственность за экспорт статистики, следов и журналов, которые помогают операторам выяснить, что не так, чтобы они могли решить проблему. Балансировщики нагрузки сильно различаются по показателям наблюдаемости. Самые продвинутые балансировщики предлагают богатые возможности, которые включают числовые характеристики, распределенную трассировку и настраиваемое логирование. Я укажу, что усиленная наблюдаемость не является бесплатной; балансировщик нагрузки должен выполнить для этого дополнительную работу. Однако преимущества данных значительно перевешивают незначительные последствия для производительности сети.

Безопасность и предотвращение DoS

В частности, в топологии развертывания краев (см. ниже) балансировочные устройства часто реализуют различные функции безопасности, включая ограничение скорости, аутентификацию и смягчение DoS (например, маркирование и идентификацию IP-адреса, tarpitting и т.д.).

Конфигурация и плоскость управления

Балансировщики нагрузки нуждаются в настройке. В крупных развертываниях это может стать существенной задачей. Система, которая настраивает балансировщики нагрузки, известна как «плоскость управления» и широко варьируется в реализации. Для получения дополнительной информации по этой теме, пожалуйста, см. мое [сообщение о плоскости данных сетки обслуживания и плоскости управления] (https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc).

И еще многое другое

Этот раздел просто поцарапал поверхность типов функциональных возможностей, которые обеспечивают балансировщики нагрузки. Дополнительную информацию можно найти в разделе о балансировщиках L7 ниже.

Типы топологий балансировки нагрузки

Теперь, когда я предоставил высокоуровневое описание балансировки нагрузки, разницу между балансировщиками нагрузки L4 и L7 и краткое описание функций балансировки нагрузки, перейду к различным топологиям распределенных систем, в которых развернуты балансировщики нагрузки. (Каждая из следующих топологий применима как для балансировщиков нагрузки L4, так и для L7).

Прокси по середине

Топология балансировки нагрузки прокси по середине

Топология прокси по середине, показанная на рисунке выше, вероятно, является наиболее известным способом получения балансировки нагрузки для большинства читателей. Эта категория включает аппаратные устройства от Cisco, Juniper, F5 и т.д.; облачные программные решения, такие как Amazon ALB и NLB и Сloud Load Balancer; и чистые программные решения, такие как HAProxy, NGINX и Envoy. Достоинства подобной топологии — простота применения для пользователей. В общем случае пользователи подключаются к балансировщику нагрузки через DNS и не должны беспокоиться ни о чем другом. Соглашением решения прокси по середине является тот факт, что прокси (даже в случае кластеризации) является единственной точкой отказа, а также узким местом масштабирования. Прокси по середине также часто является черным ящиком, что затрудняет работу. Является ли наблюдаемая проблема у клиента? В физической сети? В прокси по середине? В бэкенде? Ответить на эти вопросы может быть очень сложно.

Краевой прокси

Топология балансировки нагрузки краевого прокси

Топология краевого прокси, показанная на рисунке, на самом деле является лишь вариантом топологии прокси по середине, в которой балансировщик нагрузки доступен через Интернет. В этом случае балансировщик нагрузки обычно должен предоставлять дополнительные функции «шлюза API», такие как терминирование TLS, ограничение скорости, аутентификация и сложная маршрутизация трафика. Все плюсы и минусы краевого прокси-сервера такие же, как и прокси по середине. Клиентам обычно требуется доступ к системе через DNS с использованием произвольных сетевых библиотек, которые владелец сервиса не контролирует (создание встроенной клиентской библиотеки или топологий прокси-сервера sidecar, описанных в следующих разделах, нецелесообразно запускать непосредственно на клиенте). Кроме того, по соображениям безопасности желательно иметь один шлюз, через который весь интернет-трафик проходит через систему.

Встроенная клиентская библиотека

Балансировка нагрузки через встроенную клиентскую библиотеку

Чтобы избежать присущих топологии сервера прокси по середине проблем отказа и масштабирования, более сложные инфраструктуры переключились на то, чтобы встроить балансировщик нагрузки непосредственно в службы через библиотеку, как показано на рисунке. Библиотеки сильно различаются по поддерживаемым функциям, но некоторые из наиболее известных и многофункциональных в этой категории — Finagle, [Eureka/Ribbon/Hystrix](https: //netflix.github.io/) и gRPC (на основе внутренней системы Google, называемой Stubby). Основным достоинством решения на базе библиотеки является то, что он полностью распределяет всю функциональность балансировщика нагрузки каждому клиенту, тем самым устраняя описанные ранее проблемы отказа и масштабирования. Первичным решением библиотечного решения является то, что библиотека должна быть реализована на всех языках, которые использует организация. Распределенные архитектуры становятся все более «полиглотными» (многоязычными). В этой среде стоимость переоснащения чрезвычайно сложной сетевой библиотеки на разных языках может стать непомерно высокой. Наконец, развертывание обновлений библиотек в большой архитектуре обслуживания может быть чрезвычайно болезненным.

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

Прокси-сервер Sidecar

Балансировка нагрузки через прокси-сервер sidecar

Вариантом топологии балансировки нагрузки встроенной клиентской библиотеки является топология прокси-сервера sidecar, показанная на рисунке. В последние годы она была популяризирована как «служебная сетка». Идея прокси-сервера sidecar заключается в том, что ценой незначительного штрафа за латентность переходом на другой процесс все преимущества встроенного библиотечного подхода могут быть получены без программирования. Наиболее популярными балансировщиками нагрузки прокси-сервера sidecar на данный момент являются Envoy, NGINX, [HAProxy](https: //www.haproxy.com/) и Linkerd. Для более детального изучения подхода прокси-сервера sidecar см. мой пост в блоге о Envoy, а также мой пост [the service mesh data plane vs. control plane] (https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc).

Резюме и плюсы/минусы различных топологий балансировки нагрузки

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

Современное состояние в балансировке нагрузки L4

Балансировщики нагрузки L4 по-прежнему актуальны?

В этом сообщении уже обсуждалось, насколько значимы балансировщики L7 для современных протоколов. Теперь более подробно перейдем к функциям балансировки нагрузки L7. Означает ли это, что балансировщики нагрузки L4 больше не актуальны? Нет! Хотя, на мой взгляд, балансировщики нагрузки L7 в конечном счете полностью заменяют балансировщики нагрузки L4 для связи между сервисами, балансировщики нагрузки L4 по-прежнему крайне важны, потому что почти все современные крупные распределенные архитектуры используют двухуровневую архитектуру балансировки нагрузки L4 / L7 для интернет-трафика. Преимущества размещения выделенных балансировщиков нагрузки L4 до балансировщика нагрузки L7 при развертывании на краю:

В следующих разделах я опишу несколько различных конструкций для балансировщика нагрузки L4 для прокси по середине и краевого прокси. Следующие проекты, как правило, неприменимы к клиентской библиотеке и топологиям прокси-сервера sidecar.

TCP/UDP балансировщик нагрузки

L4 балансировщик нагрузки

Первым типом балансировщика нагрузки L4, который все еще используется, является балансировка нагрузки на выключение, показанная на рисунке. Это тот же самый балансировщик нагрузки, который мы видели в введении к балансировке нагрузки L4 выше. В этом типе используются два дискретных TCP-соединения: один между клиентом и балансировщиком нагрузки и один между балансировщиком нагрузки и бэкендом.

Балансировщики нагрузки L4 по-прежнему используются по двум причинам:

Отказоустойчивость через пары высокой доступности

L4-отказоустойчивость через пары HA и отслеживание соединений

До сих пор мы рассматривали дизайн балансировщика нагрузки L4 изолированно. Для балансировки нагрузки Passthrough и DSR требуется некоторое отслеживание соединения и состояния в самом балансировщике нагрузки. Что делать, если балансировщик нагрузки умирает? Если один экземпляр балансировщика умирает, все проходящие через него соединения будут разорваны. В зависимости от приложения это может существенно повлиять на производительность.

Исторически балансировщики нагрузки L4 были аппаратными устройствами, приобретенными у типичных поставщиков (Cisco, Juniper, F5 и т.д.). Эти устройства чрезвычайно дороги и обрабатывают большой объем трафика. Чтобы избежать отказа одного балансировщика нагрузки, разрушающего все соединения и приводящего к существенному отключению приложений, балансировщики обычно развертывались в парах с высокой доступностью, как показано на рисунке. Типичная установка балансировки нагрузки HA имеет следующий дизайн:

Вышеприведенная настройка показывает, насколько много трафика по-прежнему обслуживается. Однако у такого подхода есть существенные недостатки:

Отказоустойчивость и масштабирование с помощью кластеров с распределенным консистентным хешированием

L4-отказоустойчивость и масштабирование с помощью кластерных балансировщиков нагрузки и консистентного хеширования

В предыдущем разделе была представлена ошибка отказоустойчивости балансировки нагрузки L4 через пары HA, а также указаны присущие этой конструкции проблемы. Начиная с середины 2000-х годов крупные интернет-инфраструктуры начали разрабатывать и развертывать новые массивно-параллельные системы балансировки нагрузки L4, как показано на рисунке. Целями этих систем являются:

Этот дизайн балансировки нагрузки L4 чаще всего называют отказоустойчивостью и масштабированием посредством кластеризации и распределенного согласованного хеширования. Он работает следующим образом:

Давайте посмотрим, как приведенный выше пример смягчает все недостатки подхода пары HA:

Вопросы, которые обычно задают об этой конструкции: — «почему пограничные маршрутизаторы не разговаривают напрямую с серверами через ECMP?», «зачем нам нужен балансировщик нагрузки?». Причины в первую очередь связаны с уменьшением эффективности DoS и операционной системой. Без балансировки нагрузки каждый бэкенд должен был бы участвовать в BGP и потребовалось бы значительно большее время для развертывания.

Все современные системы балансировки нагрузки L4 двигаются к этой конструкции (или к ее варианту). Двумя наиболее известными примерами являются Maglev из Google и [Балансировщик сетевой нагрузки (NLB)](http: //docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) от Amazon. В настоящее время нет балансировщика нагрузки OSS, который реализует этот проект, однако есть компания, которая планирует выпуск OSS в 2018 году. Я очень взволнован этим выпуском, поскольку современный балансировщик нагрузки L4 является решающим элементом отсутствия OSS в сетевом пространстве.

Текущее состояние балансировки нагрузки L7

The proxy wars in tech currently is *quite literally* the proxy wars.

Or the “war of the proxies”.

Nginx plus, HAProxy, linkerd, Envoy all quite literally killing it.

And proxy-as-a-service/routing-as-a-service SaaS vendors raising the bar as well. Very interesting times!
— Cindy Sridharan (@copyconstruct) November 28, 2017

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

Поддержка протокола

Современные балансировщики нагрузки L7 добавляют явную поддержку для многих разных протоколов. Чем большее отношение балансировщик нагрузки имеет к трафику приложения, тем более сложные вещи он может делать в отношении вывода наблюдаемости, расширенной балансировки нагрузки, маршрутизации и т.д. Например, на момент написания этой статьи Envoy явно поддерживает парсинг и маршрутизацию протокола L7 для HTTP/1, HTTP/2, gRPC, Redis, MongoDB и DynamoDB. В будущем, вероятно, появятся новые протоколы, включая MySQL и Kafka.

Динамическая конфигурация

Как описано выше, все более динамичный характер распределенных систем требует параллельных инвестиций в создание динамических и реактивных систем управления. Istio — один из примеров такой системы. Для получения дополнительной информации по этой теме см. мой пост service mesh data plane vs. control plane.

Расширенная балансировка нагрузки

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

Наблюдаемость

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

Расширяемость

Пользователи современных балансировщиков L7 часто хотят легко расширять их, чтобы добавить пользовательские функции. Это можно сделать путем записи подключаемых фильтров, которые загружаются в балансировщик нагрузки. Многие балансировки нагрузки также поддерживают сценарии, как правило, через Lua.

Отказоустойчивость

Немного выше я написал о L4-отказоустойчивости балансировки нагрузки. А что насчет отказоустойчивости балансировки нагрузки L7? Мы рассматриваем балансировщики нагрузки L7 как расходный материал и stateless. Использование программного обеспечения для балансировки позволяет L7 легко масштабироваться горизонтально. Кроме того, обработка и отслеживание состояния, которые выполняют балансировщики нагрузки L7, существенно сложнее, чем L4. Попытка построить HA-пару балансировщика нагрузки L7 технически возможна, но это будет тяжело реализовать.

Как в доменах балансировки нагрузки L4 и L7, отрасль в целом отходит от HA-пар к горизонтально масштабируемым системам, которые взаимодействуют через консистентное хеширование.

И еще

Балансировщики нагрузки L7 развиваются ошеломляющими темпами. Пример того, что предлагает Envoy, см. в разделе Обзор архитектуры.

Глобальная балансировка нагрузки и централизованная плоскость управления

Глобальная балансировка нагрузки

Будущее балансировки нагрузки будет все чаще рассматривать отдельные балансировщики как товар. На мой взгляд, настоящие инновационные и коммерческие возможности лежат в плоскости управления. Рисунок показывает пример глобальной системы балансировки нагрузки. В этом примере происходит несколько разных вещей:

Глобальный балансировщик нагрузки будет в состоянии делать сложные вещи, которые ни один балансировщик нагрузки не может сделать самостоятельно. Например:

Чтобы сделать глобальную балансировку нагрузки возможной, балансировщик нагрузки, используемый в качестве data plane, должен обладать сложными возможностями динамической конфигурации. Для получения дополнительной информации по этой теме, пожалуйста, см. мой пост Envoy’s universal data plane API, а также service mesh data plane vs. control plane..

Эволюция от аппаратного до программного обеспечения

До сих пор этот пост только кратко упоминал аппаратное и программное обеспечение, прежде всего в контексте исторической пары балансировки нагрузки L4. Каковы отраслевые тенденции в этой области?

I’ve seen the new OSI stack of eight layers of software.
I think it’s more like this: pic.twitter.com/6K84IJYGAi
— Brian Glas (@infosecdad) July 21, 2017

Заключение и будущее балансировки нагрузки

Подводя итог, приведем ключевые выводы этой публикации:

Я думаю, что это захватывающее время в компьютерных сетях! Переход к OSS и программному обеспечению для большинства систем увеличивает темпы итерации на порядок. Кроме того, поскольку распределенные системы продолжают свой путь к динамизму с помощью «бессерверных» парадигм, сложность базовой сети и систем балансировки нагрузки должна быть соразмерно увеличена.

Источник