Amazon ELB в VPC

Ответ 1

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

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

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

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

• WebServer-1 работает в PrivateSubnet-1 в зоне доступности us-east-1b с группой безопасности, называемой веб-сервером.
• WebServer-2 работает в PrivateSubnet-2 в зоне доступности us-east-1c с группой безопасности, называемой веб-сервером.
• Созданный публичный подсеть в зоне us-east-1b, мы будем называть его PublicSubnet-1. Мы гарантировали, что мы связали таблицу маршрутизации, которая включает в себя маршрут к Интернет-шлюзу (ig-xxxxx) с этой новой подсети. (Если вы использовали мастер для создания публичного/частного VPC, этот маршрут уже существует.)
• Созданная общественная подсеть в зоне us-east-1c, мы будем называть ее PublicSubnet-2. Мы гарантировали, что мы связали таблицу маршрутизации, которая включает в себя маршрут к Интернет-шлюзу (ig-xxxxx) с этой новой подсети. (Если вы использовали мастер для создания публичного/частного VPC, этот маршрут уже существует.)
• Создал новый ELB, добавив к нему PublicSubnet-1 и PublicSubnet-2 (а не PrivateSubnet-X). Также выбрали экземпляры для запуска в ELB, в данном случае WebServer-1 и WebServer-2. Обязательно назначить группу безопасности, которая позволяет входящим портам 80 и 443. Позволяет называть эту группу elb-group.
• В группе веб-сервер разрешить трафик с портов 80 и 443 из группы elb.

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

Вы должны добавить следующие настройки.

• Зона общественной подсети b = Сервер NAT
• Частная зона подсети c = Сервер Web
• Общественная зона подсети c = ELB

Трюк маршрутизации:

• Маршрутизатор NAT подключается шлюзом A.
• Маршрутизатор к серверу Web подключается к NAT.
• Маршрутизатор к публичной подсети подключается со шлюзом А.

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

1.Zone: Зона общественной подсети c 2.Instance: Server Web Группы 3.Security: включить порты

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