ELB не тратит трафик на здоровый экземпляр

Кажется, что это связано с зоной подсети/доступности, но я новичок в использовании VPC, и это ускользает от меня.

VPC: 10.80.0.0/16 подсеть: 10.80.1.0/24 (us-east-1b) подсеть: 10.80.2.0/24 (us-east-1a)

Все экземпляры Windows Server 2012.

У меня есть интернет-интерфейс, созданный в моем VPC (10.80.0.0/16). Один экземпляр добавлен из AZ us-east-1a, который находится в подсети 10.80.2.0/24. Экземпляр запускает IIS 7.5 с приложением, запущенным на порту 80, и /health.aspx, настроенным для использования в качестве проверки работоспособности ELB.

Внутренний трафик на VPC протекает нормально (неограниченно). Я могу запросить health.aspx из этого экземпляра из другого экземпляра в us-east-1b (10.80.1.0/24). Я также могу копировать файлы из одного экземпляра в другой.

Исходящий трафик неограничен. Я могу использовать RDP для экземпляра (при подключении к нашей VPN) и открывать браузер и запрашивать веб-страницу и получать ее.

ELB говорит, что экземпляр работоспособен, и я вижу запросы на health.aspx в журналах IIS. И ELB, и экземпляр настроены с группой безопасности, которая позволяет 80 и 443.

Но если я попробую просить {elb-url}/health.aspx через открытый интернет, запрос просто истекает. Аналогично, с эластичным IP, связанным с экземпляром, запрос на {elastic-ip}/health.aspx истекает.

2 ответа

@Chris, спасибо за ответ... как это бывает, я уже сработал с какой-то помощью от друга. Я опубликую свои результаты здесь для потомков (в случае, если кто-то еще был смущен тем, как работает ELB).

Это будет более понятно с помощью диаграммы. Но резюме состоит в том, что в каждой зоне доступности вам необходимо создать как общедоступную, так и частную подсеть. Когда вы добавляете зоны доступности в ваш ELB, вам нужно выбрать общедоступную подсеть для зоны. Это уже было сделано в us-east-1b, прежде чем я добрался до этой установки, и я просто пропустил этот нюанс конфигурации ELB. Поэтому для новой зоны доступности мне пришлось это сделать...

частная подсеть us-east-1c 10.1.3.0/24 (с использованием nat-экземпляра как маршрута по умолчанию) общедоступная подсеть 10.1.4.0/24 (с использованием интернет-шлюза в качестве маршрута по умолчанию)

Затем мой экземпляр отправляется в приватную подсеть, как и ожидалось. И линч-штифт всей этой вещи (барабанный ролл....)

Когда я добавляю us-east-1c в свой ELB, я должен выбрать общественную подсеть... 10.1.4.0. В противном случае экземпляры будут проходить проверку работоспособности (поскольку ELB может связываться с любым экземпляром в пределах всего моего VPC), но ответы с серверов не могут сделать это обратно в общедоступный Интернет.

Это то, что так запутанно. И я до сих пор этого не понимаю. Экземпляр может отправить запрос, например, на www.google.com. Я могу использовать RDP и открывать браузер и получать веб-страницу. Но запрос от хозяина (например, мой ноутбук у меня дома) умрет. странный.

PS: еще одно примечание... убедитесь, что вы используете достаточно экземпляра NAT для загрузки. Я думаю, мы столкнулись с проблемой, когда наш экземпляр NAT просто закончил работу с портами, потому что слишком много веб-серверов пытались маршрутизировать исходящие подключения к сторонним API через него. Честно говоря, я недостаточно хорош на этом уровне устранения неполадок в сети/ОС. Но моя теория заключается в том, что в наших 8 экземплярах IIS было слишком много соединений, открытых для экземпляра NAT. Мы также злоупотребляли сетевым адаптером на этом микроучастнике. Я поднял нас до двух больших экземпляров, по одному на AZ, и все сгладилось. Оба экземпляра NAT напевают, и мы больше не видим замеченные процессы в IIS.


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

  • Вы проверили как группы безопасности, так и сетевые списки управления доступом? Имейте в виду, что все сетевые ACL необходимо указывать в обоих направлениях, так как они не имеют состояния. Также имейте в виду, что ELB немного уникальны в этом отношении. Хотя они связаны с вашим VPC, им иногда необходимы дополнительные правила для обеспечения возможности подключения. В прошлом я отлаживал это, открывая все сетевые ACL на всех портах, затем удаляя эти правила, пока он не перестанет работать, чтобы определить, где был этот блок.
  • Необходимо также проверить группы безопасности. Они являются состояниями, но гарантируют, что ваш балансировщик имеет разрешения на попадание из Интернета.
  • Вы проверили это не проблема конфигурации приложения? Я не знаю, как IIS выходит из коробки, но я бы проверял, что он настроен для ответа на все имена хостов.
  • Проверьте, что ELB не является внутренним, поскольку это не будет публично адресуемым.
  • Вы говорите, что ELB настроен с проверкой работоспособности, но стоит ли проверить, что у вас также есть настройка прослушивателя для порта 80? Он находится в отдельной вкладке на приборной панели, и вам понадобится это в дополнение к проверке работоспособности для подключения через ELB.

Надеюсь, что один из этих советов вам полезен.

licensed under cc by-sa 3.0 with attribution.