Гуглил как сумасшедший, ответа не нашел. У нас есть три зоны доступности/подсети, так как мы находимся в Огайо. Но эта диаграмма достаточно близка, чтобы объяснить проблему.
Мы настроили прокси-серверы squid для фильтрации исходящего трафика от одного из наших сервисов.
- В каждой зоне доступности серверы приложений находятся в частной подсети.
- Тогда есть прокси в каждом публичный подсеть для этой AZ.
- Таблица маршрутов для частной подсети указывает 0.0.0.0 на ENI прокси-сервера в соответствующей общедоступной подсети.
Со временем исходящий трафик из каждой подсети умер. Нам потребовалось немного времени, чтобы понять, что пошло не так, поэтому, когда каждая подсеть умирала, мы удаляли экземпляры в этой подсети из ALB для службы и продолжали работать с заковылявшей службой, пока мы исследовали. Вчера умерла третья подсеть, и мы решили «направить» прокси-серверы непосредственно на шлюз NAT для каждой подсети. Когда мы добрались до таблицы маршрутизации, мы заметили, что ENI каждого прокси-сервера указан как черная дыра.
Мы проверили
- Журналы экземпляра прокси
- время распределения ENI и
- Журналы Cloudtrail
... в поисках каких-либо указаний на то, почему ENI стали недействительными, нарушив наши маршруты по умолчанию. Вообще ничего полезного.
- Экземпляры работают уже более трех недель
- Отметка времени выделения ENI совпадает со временем создания экземпляра.
- Журналы загрузки не показывают никаких перезагрузок
- Cloudtrail не показывает никаких изменений ENI/экземпляров.
Мы в тупике. Как наша таблица маршрутов может «внезапно» содержать несуществующий маршрут к ENI?
