Назад | Перейти на главную страницу

EC2 VPC Периодические таймауты исходящего соединения

Моя производственная веб-служба состоит из:

Эта конфигурация работала нормально до вчерашнего дня, когда на одном из экземпляров EC2 начались тайм-ауты RDS и ElastiCache. Другой экземпляр продолжает работать без проблем.

В ходе расследования заметил, что исходящие соединения вообще иногда имеют большие задержки:

[ec2-user@ip-10-0-5-9 logs]$ time curl -s www.google.com > /dev/null

real    0m7.147s -- 7 seconds
user    0m0.007s
sys     0m0.000s
[ec2-user@ip-10-0-5-9 logs]$ time curl -s www.google.com > /dev/null

real    0m3.114s
user    0m0.007s
sys     0m0.000s
[ec2-user@ip-10-0-5-9 logs]$ time curl -s www.google.com > /dev/null

real    0m0.051s
user    0m0.006s
sys     0m0.000s
[ec2-user@ip-10-0-5-9 logs]$ time curl -s www.google.com > /dev/null

real    1m6.309s -- over a minute!
user    0m0.009s
sys     0m0.000s

[ec2-user@ip-10-0-5-9 logs]$ traceroute -n -m 1 www.google.com
traceroute to www.google.com (172.217.7.196), 1 hops max, 60 byte packets
 1  * * *
[ec2-user@ip-10-0-5-9 logs]$ traceroute -n -m 1 www.google.com
traceroute to www.google.com (172.217.7.196), 1 hops max, 60 byte packets
 1  216.182.226.174  17.706 ms * *
[ec2-user@ip-10-0-5-9 logs]$ traceroute -n -m 1 www.google.com
traceroute to www.google.com (172.217.8.4), 1 hops max, 60 byte packets
 1  216.182.226.174  20.364 ms * *
[ec2-user@ip-10-0-5-9 logs]$ traceroute -n -m 1 www.google.com
traceroute to www.google.com (172.217.7.132), 1 hops max, 60 byte packets
 1  216.182.226.170  12.680 ms  12.671 ms *

Дальнейший анализ показывает, что если вручную отсоединить «плохой» экземпляр от группы автоматического масштабирования, удалив его как цель балансировщика нагрузки, проблема мгновенно исчезнет. Как только добавляю обратно, проблема возвращается.

Эти узлы имеют размер m5.xlarge и имеют избыточную емкость, поэтому я не считаю, что это проблема с ресурсами.

ОБНОВЛЕНИЕ: похоже, связано с нагрузкой на узел. Вчера вечером я снова включил нагрузку, и она казалась стабильной, но сегодня утром, когда нагрузка растет, исходящий трафик (БД и т. Д.) Начинает давать сбой. Я действительно застрял, не понимая, как вообще влияет этот исходящий трафик. Другой идентичный узел не имеет проблем даже со 100% трафика по сравнению с 50%.

traceroute to 54.14.xx.xx (54.14.xx.xx), 1 hops max, 60 byte packets
 1  216.182.226.174  18.691 ms 216.182.226.166  18.341 ms 216.182.226.174  18.660 ms
traceroute to 54.14.xx.xx (54.14.xx.xx), 1 hops max, 60 byte packets
 1  * * *

Что такое IP-адрес 216.182.226.166? Это связано с VPC IGW?

Статистика узла:

ОБНОВЛЕНИЕ: с 1 из 2 узлов, подключенных к балансировщику нагрузки, все работает стабильно - со всем трафиком на одном узле. После того, как я добавлю 2-й узел в балансировщик нагрузки, по прошествии некоторого периода времени (часы - дни) на одном из узлов начнут проявляться проблемы с исходящим подключением, описанные выше (тайм-аут подключения к базе данных, Google и т. Д.). В этом состоянии другой узел работает нормально. Замена «плохого» или восстановление его в балансировщике нагрузки позволяет некоторое время работать нормально. Эти образы используют Amazon Linux 2 (4.14.114-103.97.amzn2.x86_64).

Возможно, вы используете шлюз / экземпляр NAT для выхода в Интернет. Если нет, возможно, вам придется предоставить дополнительную информацию об архитектуре. вы можете использовать прямое подключение и, возможно, маршрутизацию Интернета через локальную сеть.

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

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-recommended-nacl-rules.html https://aws.amazon.com/premiumsupport/knowledge-center/resolve-connection-nat-instance/