Мы используем Amazon EC2, и мы хотим поставить ELB (балансировщик нагрузки) на 2 экземпляра в частной подсети. Если мы просто добавим приватную подсеть в ELB, он не получит никаких подключений, если мы присоедините обе подсети к ELB, тогда он сможет получить доступ к экземплярам, но часто будет получать тайм-ауты. Кто-нибудь успешно реализовал ELB в частной подсети своего VPC? Если да, не могли бы вы объяснить мне эту процедуру?
Спасибо
Мой партнер по команде и я только что внедрили ELB в VPC с двумя частными подсетями в разных зонах доступности. Причина, по которой вы получаете тайм-ауты, заключается в том, что для каждой подсети, добавляемой в балансировщик нагрузки, он получает один внешний IP-адрес. (попробуйте "dig elb-dns-name-here", и вы увидите несколько IP-адресов). Если один из этих IP-адресов отображает приватную подсеть, он будет тайм-аут. IP-адрес, который отображается в вашей общей подсети, будет работать. Поскольку DNS может предоставить вам какой-либо один из IP-адресов, иногда он работает, иногда он истекает.
После нескольких месяцев назад с amazon мы обнаружили, что ELB следует размещать только в "общедоступных" подсетях, то есть подсетей, которые имеют маршрут к Интернет-шлюзу. Мы хотели сохранить наши веб-серверы в наших частных подсетях, но позволить ELB говорить с ними. Чтобы решить эту проблему, мы должны были убедиться, что у нас есть соответствующая публичная подсеть для каждой зоны доступности, в которой у нас есть частные подсети. Затем мы добавили в ELB, публичные подсети для каждой зоны доступности.
Сначала это работало не так, но, пробовав все, мы воссоздали ELB, и все сработало так, как должно было. Я думаю, что это ошибка, или ELB был просто в странном состоянии от стольких изменений.
Вот более или менее то, что мы сделали:
Я надеюсь, что это поможет!
Ключевым моментом здесь является понимание того, что вы не "добавляете подсетей/зоны доступности" в ELB, а скорее указываете, какие подсети должны помещать экземпляры ELB.
Да, ELB - это балансировка нагрузки программного обеспечения, и когда вы создаете объект ELB, пользовательский экземпляр EC2 с балансировкой нагрузки помещается во все указанные вами подсети. Поэтому для того, чтобы ELB (его экземпляры) были доступны, они должны быть помещены в подсети, которые настроены по умолчанию, настроенные через IGW (скорее всего, вы классифицировали эти подсети как общедоступные).
Итак, как уже было сказано выше, вы должны указать "общедоступные" сети для ELB, и эти сети должны быть из AZ, где запущены ваши экземпляры EC2. В этом случае экземпляры ELB смогут получить доступ к вашим экземплярам EC2 (если группы безопасности настроены правильно)
Мы реализовали 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/.
Вы должны добавить следующие настройки.
Трюк маршрутизации:
Подробности ELB:
1.Zone: Зона общественной подсети c 2.Instance: Server Web Группы 3.Security: включить порты
http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html