Балансировщик нагрузки (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 получает запрос и отправляет его к группе virtual appliances. Количество этих virtual appliances может меняться динамически. Обмен запросами происходит через туннель протокола Geneve.
Запрос проверяется и возвращается на GWLB, либо прекращается обработка – в негативном сценарии.
GWLB перенаправляет запрос дальше на обработку к целевому сервису (destination на схеме).
На обратном пути та же схема: 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.
После кнопки Create необходимо указать базовые настройки:
GWLB и TG должны находиться в одном VPC с зарегистрированными virtual appliances.
Осталось выбрать созданную ранее TG.
Итак, мы создали наш GWLB. Продолжим конфигурацию других компонентов – создадим Endpoint Service для нашего GWLB. Выбираем тип Gateway.
И указываем созданный раннее GWLB.
Осталось создать Endpoint категории Other endpoint services.
В поле service name указываем адрес ранее созданного endpoint service.
Endpoint создан. Возвращаемся в Endpoint Services и подтверждаем присоединение endpoint.
Вместо вывода:
В этой статье мы рассмотрели и создали пример рабочего Gateway Load Balancer – одного из видов балансировщиков нагрузки, которые предлагает нам AWS. Балансировщик имеет достаточно специфичное применение – масштабирование и управление virtual appliances, такими как межсетевые экраны (firewall), системы обнаружения и предотвращения вторжений (intrusion detection system / intrusion prevention system), а также системы глубокой проверки пакетов (deep packet inspection). Он объединяет прозрачный сетевой шлюз (то есть единую точку входа и выхода для всего трафика) и распределяет трафик, одновременно масштабируя ваши виртуальные устройства в соответствии с потребностями.
VladimirFarshatov
Спасибо, интересная статья и наличествует пример, хоть какой-то (не вникал просто) - уже здорово. Последнее время мне такие попадаются все реже.
Но, как обычно, полностью отсутствуют границы применимости балансировщика и особенно примененного в примере. Было бы неплохо расширить статью. В частности, для сравнения: простой MVC сайтик подгружающий 6(шесть) классов всего, способен отдаваться клиенту примерно 2000 (две тысячи) раз в секунду, если писан на чистом PHP для сервера на старом core2duo с парой гектар оперативы. Это, между прочим, около 50 миллионов(!!!) просмотров в сутки для 8 часовых суток.
Для каких нагрузок будет полезен этот балансировщик, и как часто такие нагрузки и у кого появляются? Вот этот вопрос стоит, кмк, дополнительно осветить в статье. А то уже видел магазинчик, ушедший в облако с посещаемостью около 1000 просмотров в сутки и вопрошающий "может нам балансировщик нужен? медленно как-то работает..". Не, Вам надо код отрефакторить.. ;)
0mogol0
эээ, мне кажется вы не внимательно прочли вводную часть статьи, где говорится о назначении данного балансировщика. Он не для балансировки нагрузки между сайтами, а для обеспечения "отвода" на всевозможные системы безопасности (Intrusion Prevention, DPI, firewall итп), и если они дали добро, дальше трафик идёт на основной сервер.
Другой вопрос, что я может не настолько хорошо знаю AWS, но из объяснения не понял, а чем такой балансировщик удобнее? @romansamko не могли бы вы прояснить, какие плюсы он добавляет? у меня пока единственное объяснение, что после открытия сессии (которая требовала проверки на VA), дальнейший трафик идёт через балансер не нагружая VA.