Моя производственная веб-служба состоит из:
Эта конфигурация работала нормально до вчерашнего дня, когда на одном из экземпляров 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/