Amazon ELB в VPC

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

спасибо

4 65
amazon-web-services amazon-ec2 vpc amazon-elb amazon-vpc

4 ответа:

мой товарищ по команде и я только что реализовали ELB в VPC с 2 частными подсетями в разных зонах доступности. Причина, по которой вы получаете тайм-ауты, заключается в том, что для каждой подсети, добавляемой в балансировщик нагрузки, он получает один внешний IP-адрес. (попробуйте "dig elb-dns-name-here", и вы увидите несколько IP-адресов). Если один из этих IP-адресов частной подсети, это будет тайм-аут. IP-адрес, который сопоставляется с вашей общедоступной подсетью, будет работать. Поскольку DNS может дать вам любой из IP-адресов, иногда это работает, иногда тайм-аут.

после некоторого назад и вперед с amazon, мы обнаружили, что ELB должны быть размещены только в "публичных" подсетях, то есть подсетях, которые имеют маршрут к интернет-шлюзу. Мы хотели сохранить наши веб-серверы в наших частных подсетях, но позволить ELB разговаривать с ними. Чтобы решить эту проблему, мы должны были убедиться, что у нас есть соответствующая публичная подсеть для каждой зоны доступности, в которой у нас были частные подсети. Затем мы добавили в ELB, публичные подсети для каждого зона доступности.

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

здесь более или менее то, что мы сделали:

  1. WebServer-1 работает в PrivateSubnet-1 в зоне доступности us-east-1b с группой безопасности web-server.
  2. WebServer-2 работает в PrivateSubnet-2 in зона доступности us-east-1c с группой безопасности web-server.
  3. создал публичную подсеть в зоне us-east-1b, назовем ее PublicSubnet-1. Мы гарантировали, что мы связали таблицу маршрутизации, которая включает маршрут к интернет-шлюзу (ig-xxxxx) с этой новой подсетью. (Если вы использовали мастер для создания общедоступного / частного VPC, этот маршрут уже существует.)
  4. создал публичную подсеть в зоне us-east-1c, назовем ее PublicSubnet-2. Мы гарантировали, что мы ассоциировали таблица маршрутизации, которая включает маршрут к интернет-шлюзу (ig-xxxxx) с этой новой подсетью. (Если вы использовали мастер для создания общедоступного / частного VPC, этот маршрут уже существует.)
  5. создал новый ELB, добавив к нему PublicSubnet-1 и PublicSubnet-2 (не PrivateSubnet-X). Кроме того, выбрал экземпляры для запуска в ELB, в данном случае WebServer-1 и WebServer-2. Обязательно назначьте группу безопасности, которая разрешает входящий порт 80 и 443. Назовем эту группу elb-group.
  6. в группе веб-серверов разрешите трафик от порта 80 и 443 от elb-группы.

Я надеюсь, что помогает!

170

ключом здесь является понимание того, что вы не "добавляете подсети/зоны доступности" в ELB, а скорее указываете, в какие подсети помещать экземпляры ELB.

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

Итак, как уже было сказано выше, вы должны указать "общедоступные" сети для ELB, и эти сети должны быть из AZs, где работают ваши экземпляры EC2. В этом случае экземпляры ELB смогут достичь ваших экземпляров EC2 (если группы безопасности настроены правильно)

11

мы реализовали ELB в частной подсети, поэтому утверждение о том, что все ELB должны быть общедоступными, не совсем верно. Тебе действительно нужен Нат. Создайте частную подсеть для частных ELB, включите DNS VPC, а затем убедитесь, что частная таблица маршрутизации настроена для прохождения через NAT. Группы безопасности подсети также необходимо настроить, чтобы разрешить трафик между ELB и App, а также приложение для подсетей БД.

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

предложенное чтение для запуска архитектуры VPC: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/.

2

необходимо добавить следующие настройки.

  1. общественная зона подсети b = сервер NAT
  2. частная зона подсети c = сервер Web
  3. общественная зона подсети c = ELB

фокус в маршрутизации:

  1. маршрутизатор к NAT подключается с помощью шлюза A.
  2. маршрутизатор к веб-серверу подключается к NAT.
  3. маршрутизатор к публичной подсети подключается с помощью шлюза A.

ELB подробности:

1.Зона: общедоступная зона подсети c 2.Пример: Веб-Сервер 3.Группы безопасности: включить порты

http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html

2