Вопрос или проблема
У меня есть два ALB в AWS, и я хотел бы создать один NLB, который будет отслеживать, какой из них активен, и перенаправлять трафик только к нему. Я пытаюсь сделать это, создавая две группы целевых объектов с типом целевого объекта ‘ALB’ и добавляя по одному ALB в каждую из групп, а затем пытаюсь настроить прослушиватель на пересылку трафика в эти группы целевых объектов в зависимости от ответа проверки работоспособности.
Я создаю эти ресурсы с помощью кода Terraform и пока смог создать NLB, но вот что я выяснил:
- Прослушиватели NLB могут использовать только протоколы TCP/UDP/TLS.
- Прослушиватели не могут определять правила/условия (вес/приоритет и т. д.).
- К прослушивателю NLB можно привязать только одно действие по умолчанию, поэтому сборка terraform привязывает только одну определенную группу целевых объектов.
- Группы целевых объектов типа ALB, похоже, не поддерживают подключение нескольких ALB.
Итак, мои мысли/следующие действия:
- Создать второй прослушиватель с второй группой целевых объектов в качестве действия по умолчанию – однако проблема в том, что прослушиватель не может использовать тот же TCP-порт 80. Если я установлю второй на 81, нужно ли будет DNS-записи, указывающей на NLB, ссылаться на нестандартный порт?
- Использовать единственный прослушиватель по умолчанию для указания на одну группу целевых объектов с типом целевого объекта ‘IP’ и добавить таким образом оба ALB, однако у каждого ALB есть один IP-адрес на AZ, который он охватывает.
В обоих сценариях я думаю, что только один кластер/ALB будет активен в любой момент времени, и трафик не будет направлен на ALB, если он будет вне строя, хотя у вас будет период времени, когда будет создаваться второй ALB и оба будут активны одновременно.
Мне кажется, что должно быть более простое решение, потому что сейчас я пытаюсь собрать его, как будто на изоленту. Есть идеи или подсказки?
Ответ или решение
Обзор решения: Использование NLB для мониторинга и маршрутизации к ALB
Работа с архитектурой AWS, в частности с Application Load Balancers (ALB) и Network Load Balancers (NLB), требует особого подхода к мониторингу и распределению трафика. Ваша задача заключалась в создании одного NLB, который будет отслеживать состояние двух ALB и направлять трафик к активному. Давайте подробно рассмотрим текущую ситуацию и предложим более оптимальное решение.
Проблемные аспекты текущей реализации
-
Протоколы и правила NLB: Вы правы, что NLB поддерживает лишь TCP/UDP/TLS и не позволяет настраивать сложные правила маршрутизации, такие как использование весов или приоритетов. Это ограничивает вашу гибкость в маршрутизации запросов в зависимости от состояния ALB.
-
Ограничения по динамике целевых групп: Создание целевых групп с типом ALB не обеспечивает желаемой функциональности, так как они не могут одновременно включать несколько ALB.
-
Настройка слушателей: Установка нескольких слушателей на одном порту невозможна. Использование различных портов предполагает, что за ними должен следовать корректный DNS, что усложняет конфигурацию.
Альтернативные подходы
Вместо того чтобы пытаться «собрать» работу NLB с двумя ALB вместе, рассмотрим несколько более надежных способов.
1. Использование Route 53
AWS Route 53 позволяет реализовать маршрутизацию на основе состояния ресурсов через механизм Health Checks. Вы можете настроить Route 53 так, чтобы он проверял состояние ваших ALB и направлял трафик только к активному ALB. В этом случае можно использовать политики маршрутизации, которые обеспечивают высокую доступность и производительность:
- Health Check: настроить проверки состояния для обоих ALB.
- Политики маршрутизации: использовать алиасы Route 53 для указания зависимости от проверки состояния. Если один ALB выходит из строя, Route 53 автоматически перенаправляет трафик на работающий.
2. Внедрение AWS Lambda
Можно написать небольшой скрипт на AWS Lambda, который будет периодически проверять состояние ваших ALB и в случае необходимости изменять конфигурацию DNS в Route 53. Такой подход требует более сложной настройки, но обеспечивает большую гибкость.
3. Автоматизация с помощью Terraform
Если вы решите оставить текущую архитектуру с использованием NLB, можно рассмотреть возможность интеграции Terraform для автоматизации:
- Создайте один ALB как основной и используйте Auto Scaling Group для второго ALB. Это обеспечит автоматическое переключение при сбое.
- Настройте Terraform так, чтобы он автоматически обновлял настройки NLB в зависимости от состояния ALB. Хотя это может потребовать дополнительной логики, это тоже может быть благоприятным долгосрочным решением.
Заключение
К сожалению, использование NLB для мониторинга ALB в текущем виде приведет к ограничениям, которые могут повлиять на производительность вашей системы. Рекомендуется рассмотреть возможность использования Route 53 для обеспечения контроля за трафиком на основе состояния вашего приложения. Это создаст более надежную и гибкую архитектуру с меньшими затратами на поддержку и управление.
Если возникнут дополнительные вопросы или требуется более углубленная техническая консультация, пожалуйста, дайте знать.