Балансировщик нагрузки (Elastic Load Balancer, далее ELB) – часто используемый элемент при проектировании архитектуры в AWS. Цель – эффективное распределение запросов между имеющимися инстансами, а также создание/удаление новых в рамках Auto Scaling Group.

В этой статье я бы хотел рассмотреть самый новый вид балансировщика из представленных в AWS – Gateway Load Balancer (далее GWLB).

На данный момент AWS предлагает 3 варианта ELB (v2*):

*4й вариант Classic Load balancer(v1) считается устаревшим и не рекомендуется для новых проектов.

Application Load Balancer (ALB). Для приложений, использующих HTTP/HTTPS – Level 7

Network Load Balancer (NLB). Для приложений, использующих TCP, UDP – Level 4.

Первые два достаточно давно известны и подробно разобраны, чего не скажешь о GWLB.

GWLB – Gateway Load balancer. Был представлен AWS в 2020 году и предназначен для достаточно специфичных задач – управление и масштабирование virtual appliance. Речь идет о системах контроля трафика, межсетевых экранах и т.д. 

Общая схема работы GWLB ниже:

Схема работы GWLB
Схема работы GWLB
  1. Клиент выполняет запрос к приложению.

  2. GWLB получает запрос и отправляет его к группе virtual appliances. Количество этих virtual appliances может меняться динамически. Обмен запросами происходит через туннель протокола Geneve.

  3. Запрос проверяется и возвращается на GWLB, либо прекращается обработка – в негативном сценарии.

  4. GWLB перенаправляет запрос дальше на обработку к целевому сервису (destination на схеме).

  5. На обратном пути та же схема: GWLB обработает трафик и вернет клиенту.

Cоздание GWLB помощью AWS Management Console

Предполагаемая архитектура: используется два Virtual Private Cloud (далее VPC). 

VPC-1: в нем находится GWLB Endpoint и бизнес-логика нашей системы – application servers.
VPC-2: в нем расположен GWLB и target group(далее TG) с апплайнсами, которые выполняют некую логику обработки трафика.

Схема предполагаемой системы
Схема предполагаемой системы

Для начала создадим тестовую TG, куда могут быть добавлены virtual appliances.
Для этого переходим в EC2 > Target groups > Create target group.

Необходимо выбрать протокол Geneve и порт 6081 – другие протоколы и порты не подойдут.

Теперь создадим наш первый GWLB. Для этого переходим в EC2 > Load balancers >Select load balancer type и выбираем Gateway Load Balancer.

GWLB
GWLB


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

Basic GWLB
Basic GWLB

GWLB и TG должны находиться в одном VPC с зарегистрированными virtual appliances.

Network mapping GWLB
Network mapping GWLB

Осталось выбрать созданную ранее TG.

TG
TG

Итак, мы создали наш GWLB. Продолжим конфигурацию других компонентов – создадим Endpoint Service для нашего GWLB. Выбираем тип Gateway.

Create endpoint service
Create endpoint service

И указываем созданный раннее GWLB.

Available load balancers
Available load balancers

Осталось создать Endpoint категории Other endpoint services.

Create endpoint
Create endpoint

В поле service name указываем адрес ранее созданного endpoint service.

Service settings
Service settings

Endpoint создан. Возвращаемся в Endpoint Services и подтверждаем присоединение endpoint.

Endpoint services
Endpoint services


Вместо вывода:

В этой статье мы рассмотрели и создали пример рабочего Gateway Load Balancer – одного из видов балансировщиков нагрузки, которые предлагает нам AWS. Балансировщик имеет достаточно специфичное применение – масштабирование и управление virtual appliances, такими как межсетевые экраны (firewall), системы обнаружения и предотвращения вторжений (intrusion detection system / intrusion prevention system), а также системы глубокой проверки пакетов (deep packet inspection). Он объединяет прозрачный сетевой шлюз (то есть единую точку входа и выхода для всего трафика) и распределяет трафик, одновременно масштабируя ваши виртуальные устройства в соответствии с потребностями.

Комментарии (2)


  1. VladimirFarshatov
    06.10.2023 10:28

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

    Но, как обычно, полностью отсутствуют границы применимости балансировщика и особенно примененного в примере. Было бы неплохо расширить статью. В частности, для сравнения: простой MVC сайтик подгружающий 6(шесть) классов всего, способен отдаваться клиенту примерно 2000 (две тысячи) раз в секунду, если писан на чистом PHP для сервера на старом core2duo с парой гектар оперативы. Это, между прочим, около 50 миллионов(!!!) просмотров в сутки для 8 часовых суток.

    Для каких нагрузок будет полезен этот балансировщик, и как часто такие нагрузки и у кого появляются? Вот этот вопрос стоит, кмк, дополнительно осветить в статье. А то уже видел магазинчик, ушедший в облако с посещаемостью около 1000 просмотров в сутки и вопрошающий "может нам балансировщик нужен? медленно как-то работает..". Не, Вам надо код отрефакторить.. ;)


    1. 0mogol0
      06.10.2023 10:28
      +1

      эээ, мне кажется вы не внимательно прочли вводную часть статьи, где говорится о назначении данного балансировщика. Он не для балансировки нагрузки между сайтами, а для обеспечения "отвода" на всевозможные системы безопасности (Intrusion Prevention, DPI, firewall итп), и если они дали добро, дальше трафик идёт на основной сервер.

      Другой вопрос, что я может не настолько хорошо знаю AWS, но из объяснения не понял, а чем такой балансировщик удобнее? @romansamko не могли бы вы прояснить, какие плюсы он добавляет? у меня пока единственное объяснение, что после открытия сессии (которая требовала проверки на VA), дальнейший трафик идёт через балансер не нагружая VA.