Đã googling như điên và không thể tìm thấy một câu trả lời. Chúng tôi có ba AZ/mạng con kể từ khi chúng tôi ở Ohio. Nhưng sơ đồ này đủ gần để giải thích vấn đề.
Chúng tôi đã thiết lập các proxy mực để lọc lưu lượng truy cập ra khỏi một trong các dịch vụ của chúng tôi.
- Đối với mỗi AZ, các máy chủ ứng dụng nằm trong một mạng con riêng.
- Sau đó, có một proxy trong mỗi công cộng mạng con cho AZ đó.
- Bảng định tuyến cho các điểm mạng con riêng 0.0.0.0 tới ENI của proxy trong mạng con công cộng tương ứng.
Theo thời gian, lưu lượng truy cập ra từ mỗi mạng con đã chết. Chúng tôi đã mất một chút thời gian để tìm ra điều gì đang xảy ra nên khi mỗi mạng con bị chết, chúng tôi đã xóa các phiên bản trong mạng con đó khỏi ALB cho dịch vụ và tiếp tục với một dịch vụ bị lỗi trong khi chúng tôi nghiên cứu. Hôm qua, mạng con thứ ba đã chết và chúng tôi quyết định "định tuyến xung quanh" các proxy trực tiếp đến cổng NAT cho mỗi mạng con. Khi chúng tôi đến bảng định tuyến, chúng tôi nhận thấy ENI của mỗi proxy được liệt kê dưới dạng lỗ đen.
Chúng tôi đã kiểm tra
- Nhật ký phiên bản proxy
- thời gian phân bổ ENI, và
- Nhật ký đường mòn trên đám mây
...tìm kiếm bất kỳ dấu hiệu nào về lý do tại sao ENI trở nên không hợp lệ khi phá vỡ các tuyến đường mặc định của chúng tôi. Không có gì hữu ích cả.
- Các trường hợp đã tăng hơn ba tuần
- Dấu thời gian phân bổ ENI khớp với thời gian tạo phiên bản
- Nhật ký khởi động không hiển thị bất kỳ lần khởi động lại nào
- Cloudtrail không hiển thị bất kỳ sửa đổi nào đối với ENI/phiên bản.
Chúng tôi bối rối. Làm cách nào mà bảng lộ trình của chúng ta có thể "đột nhiên" chứa một lộ trình đến một ENI không tồn tại?
