Я пытаюсь найти лучшее решение для моего случая использования.
Скажем, у меня есть 10 веб-сайтов для размещения в моем VPC. Каждый из этих веб-сайтов должен находиться за балансировщиком эластичной нагрузки. Насколько я понимаю, каждому ELB должен быть назначен эластичный IP-адрес (EIP). Я также создаю экземпляры NAT в нескольких зонах доступности, чтобы разрешить обмен данными между моими экземплярами за пределами VPC (для них также нужны связанные с ними EIP). Вдобавок у меня также есть несколько небольших веб-сайтов, которые мне нужно создать (блоги, внутренние инструменты и т. Д.), Которым я уже назначил некоторые EIP.
Должен ли я назначать каждому из них EIP, как я хочу (мне придется запросить больше EIP из-за ограничений EIP региона) или мне следует настроить эти сайты лучше?
Я мог бы настроить их, используя виртуальные хосты на основе имени apache, и иметь один трафик маршрутизации ELB и выбрать правильный корень документа на основе имени домена.
Могу ли я рассмотреть какое-либо другое решение? Как какое-то решение Route53, которое отправляет трафик на правильный балансировщик нагрузки на основе домена?
Как упоминалось в комментариях, ELB не используют эластичные IP-адреса (EIP). Кроме того, экземплярам, стоящим за ELB, обычно не требуются общедоступные IP-адреса - входящие, доступ к ним осуществляется через ELB (который также получает их ответный трафик, пересылающий ответы запрашивающей стороне) и исходящие - для запросов внутренних служб экземпляры могут использовать экземпляр NAT для доступа в Интернет.
Когда вы создаете ELB, балансировщику нагрузки назначается имя хоста. Это имя хоста отображается (внутренне) на один или больше IP-адреса, динамически назначаемые из общедоступного пула, по крайней мере, один IP-адрес для каждой зоны доступности, где ELB связан с подсетью. Поскольку ELB автоматически масштабируется с нагрузкой, а эти адреса являются динамическими, вы не можете напрямую направлять трафик на эти IP-адреса.
«Эластичный» балансировщик нагрузки на самом деле представляет собой кластер из одного или нескольких экземпляров балансировщика нагрузки, каждый из которых имеет общедоступный и частный IP-адрес, и все они имеют одинаковую подготовку и поведение. Эти экземпляры в значительной степени невидимы для вас, управляются AWS, и они включены в стоимость ELB, независимо от того, сколько из них вам понадобится в инфраструктуре для обслуживания нагрузки, которую вы ей предлагаете. (Ваша плата зависит только от пропускной способности).
Из-за динамического характера ELB вам необходимо направить трафик на конечную точку ELB через конфигурацию DNS, чтобы попасть по имени хоста, которое было назначено для ELB (оно не настроено на вашем веб-сервере, оно используется только в DNS). Если веб-сайт является именем хоста в вашем домене, например www в www.example.com, то вы можете использовать CNAME в DNS, а DNS может быть размещен где угодно ... но если веб-сайт находится на вершине зоны (верхний уровень вашего домена, например example.com), то вам нужно использовать Route 53 для размещения вашего DNS, чтобы вы могли использовать псевдоним A запись для маршрутизации трафика сайта на ваш ELB. (Все имена хостов жестяная банка используйте записи псевдонимов, но они требуются только на вершине зоны, где записи CNAME недействительны). При наличии псевдонима маршрут 53 будет возвращать один действительный IP-адрес для вашего ELB с коротким TTL в ответ на каждый запрос.
Экземпляры EC2 могут быть связаны с любым количеством ELB, но один ELB может отправлять запросы только одной группе экземпляров - ELB не выбирает экземпляры на основе каких-либо критериев, кроме балансировки нагрузки между всеми работоспособными экземплярами, связанными с ним.
Если ваши сайты не используют SSL, вы можете размещать сайты с одним ELB на одном или нескольких экземплярах, используя конфигурацию виртуального хостинга для обслуживания правильного контента ... но все экземпляры, подключенные к одному ELB, должны быть подготовлены для обслуживания содержания всех сайтов.
Если ваши сайты используют SSL, вам понадобится один ELB для каждого сертификата SSL. Если сертификат SSL является подстановочным знаком или мультидоменным сертификатом «UCC», тогда вам все равно может понадобиться только один ELB ... но если вам нужно несколько сертификатов, вам понадобится один ELB на сертификат, хотя ELB все еще могут интерфейс для общей группы экземпляров EC2, если все эти экземпляры готовы обслуживать все сайты.
(Существуют альтернативные конфигурации, включающие ELB в прозрачном режиме TCP и веб-сервер, который понимает PROXY протокол и SNI, но я бы предположил, что это сложные темы, выходящие за рамки вопроса).
В любом случае вы узнаете больше всего, делать. Настройте ELB, и из наблюдения должно быть более очевидно, как он работает.
Также обратите внимание на то, что, как это ни парадоксально, при инициализации ELB часто неправильно чтобы разместить ELB в той же подсети, что и экземпляры. ELB наверняка должен находиться в "общедоступной" подсети, где маршрут по умолчанию указывает на igw-xxxxxxxx Объект Internet Gateway в таблице маршрутов VPC, но ваши экземпляры, поскольку они должны быть доступны только из ELB, а не из Интернета, могут работать в «частной» подсети. В отличие от традиционной сети, где маршрутизатор может быть узким местом, «маршрутизатор» в VPC фактически используется для всего трафика, даже в одной и той же подсети, поэтому устройства в разных подсетях не снижают производительность.
Я также создаю экземпляры NAT в нескольких зонах доступности, чтобы разрешить обмен данными с моих экземпляров за пределами VPC.
Это не требуется для работы веб-серверов за ELB. Что касается веб-серверов, и ваши журналы доступа будут это отражать, все обращения будут поступать с внутренних частных IP-адресов в подсетях, которые вы настраиваете для занятия ELB. По сути, он покажет адреса ELB. Этот трафик никак не проходит через шлюзы NAT.
Им потребуется исходящий доступ для любых внешних служб, на которые полагаются сами серверы, и для получения пакетов для исправления. Такой доступ может не требовать настройки высокой доступности NAT для нескольких зон доступности.