Am căutat pe Google ca un nebun și nu am găsit un răspuns. Avem trei AZ/subrețele de când suntem în Ohio. Dar această diagramă este suficient de apropiată pentru a explica problema.
Am configurat proxy squid pentru a filtra traficul de ieșire de la unul dintre serviciile noastre.
- Pentru fiecare AZ, serverele de aplicații sunt într-o subrețea privată.
- Apoi există un proxy în fiecare public subrețea pentru acel AZ.
- Tabelul de rute pentru subrețeaua privată indică 0.0.0.0 către ENI-ul proxy-ului în subrețeaua publică corespunzătoare.
De-a lungul timpului, traficul de ieșire din fiecare subrețea a murit. Ne-a luat puțin să ne dăm seama ce nu mergea bine, așa că, pe măsură ce fiecare subrețea a murit, am eliminat cazurile din acea subrețea din ALB pentru serviciu și am pornit cu un serviciu defect în timp ce ne-am cercetat. Ieri a treia subrețea a murit și am decis să „rutăm” proxy-urile direct către gateway-ul NAT pentru fiecare subrețea. Când am ajuns la tabelul de rute, am observat că ENI-ul fiecărui proxy era listat ca o gaură neagră.
Am inspectat
- Jurnalele instanțelor proxy
- timpii de alocare ENI, și
- Jurnalele Cloudtrail
...căutând orice indicație cu privire la motivul pentru care ENI-urile deveniseră invalide, rupând rutele noastre implicite. Nimic util deloc.
- Instanțele sunt în curs de peste trei săptămâni
- Timpul de alocare ENI se potrivește cu ora de creare a instanței
- Jurnalele de pornire nu arată nicio repornire
- Cloudtrail nu afișează nicio modificare la ENI/instanțele.
Suntem nedumeriți. Cum poate tabelul nostru de rute să conțină „deodată” o rută către un ENI care nu există?