Балансировщик нагрузки приложений AWS с ECS

У меня следующая настройка AWS:

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

Настройка AWS

Теперь представьте следующий сценарий: Служба 1 хочет связаться со Службой 2, которая работает на другом экземпляре EC2 в другой зоне доступности. В качестве URL-адреса службы 2 я использую DNS-имя балансировщика нагрузки с портом: internal-load-balancer:8082/path. Это необходимо, поскольку я использую скользящее развертывание, поэтому микросервисы перемещаются между двумя экземплярами EC2 после каждого развертывания.

Теперь, если я выполню host internal-load-balancer, я верну 2 IP-адреса, один для балансировщика нагрузки, работающего в подсети 1, и один, работающий в подсети 2:

  • 10.0.0.11
  • 10.0.32.11

Если я сейчас выполню следующие команды curl на Сервисе 1:

  • curl 10.0.0.11:8082/ Я возвращаю тайм-аут шлюза
  • curl 10.0.32.11:8082/ работает, как ожидалось, и я получаю 200
  • curl 10.0.32.10:8082/ Также работает

Так почему, черт возьми, это работает, если я использую балансировщик нагрузки в той же подсети, но не в другой? Это также работает, если я напрямую связываюсь с экземплярами EC2 в другой зоне доступности. Проблема в том, что запись DNS разрешается как для IP-адресов, так и микросервис просто случайным образом использует один из них, поэтому половина моих запросов работает, а другая половина тайм-аута.

Так что я здесь делаю не так ??? Заранее благодарим за вашу поддержку :)


amazon-web-services amazon-ec2 amazon-ecs aws-application-load-balancer
person tzwickl    schedule 10.08.2019    source источник
comment
FWIW Я создал базовый параллельный пример в AWS, и мой работает, поэтому я не думаю, что есть какие-то теоретические проблемы. Единственное, что я могу придумать, - можно ли настроить группу безопасности на ваших экземплярах EC2, чтобы разрешить доступ из других экземпляров EC2 на основе их членства в группе sec, а не IP-адреса? Если 10.0.0.10 разрешен доступ к 10.0.32.10 из-за членства в группе sec, а 10.0.32.0/19 разрешен, а 10.0.0.0/19 - нет - теоретически это может (я думаю).   -  person jefftrotman    schedule 10.08.2019
comment
Спасибо за попытку :) Я только что столкнулся с этим вопросом в StackOverflow (stackoverflow.com/questions/9257514/ amazon-elb-in-vpc), и это, похоже, решило мою проблему: D, поэтому все, что я сделал, это то, что я переместил LB из частной подсети в общедоступную, и теперь он работает, не понимая, в чем разница или почему это необходимо ... Может быть, какая-то ошибка на стороне AWS или это должно работать таким образом   -  person tzwickl    schedule 10.08.2019

Ответы (1)


arrow_upward
0
arrow_downward

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

Кто-нибудь из присутствующих может объяснить мне, почему ALB должен находиться в публичной подсети?

person tzwickl    schedule 10.08.2019