Chúng tôi có một sự cố mạng có vẻ phức tạp mà tôi đã phải vật lộn với nó một thời gian và tự hỏi liệu có ai có ý kiến gì không
Chúng tôi có một số máy chủ đặt tại AWS London và một bộ máy chủ khác đặt tại CoLos ở London và Frankfurt
Chúng tôi kết nối từ AWS với các CoLo này bằng AWS DirectConnect
Các máy chủ AWS chủ yếu kết nối với các máy chủ CoLo bằng PGSSQL, với các máy chủ CoLo lưu trữ cơ sở dữ liệu. Các truy vấn được thực hiện qua lại cả ngày.
Các máy chủ CoLo cũng đẩy một khối lượng lớn dữ liệu trở lại AWS ở dạng Rsync và Elastic. Chúng tôi chưa bao giờ thấy bất kỳ vấn đề nào với việc đẩy Rsync hoặc Logstash vào Đàn hồi.
Nhìn chung, mọi thứ đều hoạt động tốt, ngoại trừ việc một loại truy vấn PGSQL cụ thể thường xuyên bị treo giữa AWS và CoLo.
Đi qua các tệp PCAP, chúng tôi thấy như sau:
- Trong phần lớn thời gian của phiên, máy chủ (CoLo) gửi 1460 Byte dữ liệu và máy khách (AWS) ACK dữ liệu đó. Điều này thực hiện qua lại mà không có vấn đề gì
- Sau đó, chúng tôi thấy máy chủ thường gửi từ 5-20 phân đoạn không đến được máy khách.Sự sụt giảm này có thể ở bất cứ đâu khi đường dẫn mạng đi qua 2-3 nhà mạng khác nhau và DirectConnect
- Sau đó, máy khách bắt đầu ACK chính xác cho đến phân đoạn cuối cùng mà nó nhận được
- Vào thời điểm máy chủ nhận được ACK cho biết mất gói, nó đã gửi thêm 10-20 phân đoạn
- Cuối cùng, máy chủ bắt đầu gửi lại phân đoạn bị bỏ lỡ đầu tiên được nhận và ACK ngay lập tức.
- Sau đó, máy chủ sẽ gửi hai trong số các phân đoạn "hiện tại" qua lại, nhưng một lần nữa máy khách ACK để nói rằng nó vẫn chưa bắt kịp
- Tại thời điểm này, máy chủ bắt đầu dự phòng theo cấp số nhân giữa việc gửi phân đoạn "hiện tại" và phân đoạn cũ cho đến khi đạt đến khoảng cách 120 giây
- Quá trình lặp lại như sau:
- Máy chủ gửi phân đoạn bị thiếu gần đây nhất
- Khách hàng ACK phân đoạn này ngay lập tức
- Máy chủ gửi liên tiếp hai phân đoạn "hiện tại"
- Khách hàng ACK những thứ này với cùng ACK như bước 2
- Máy chủ lùi lại theo cấp số nhân và quay lại bước 1 (khoảng cách tăng lên cho đến khi đạt 120 giây)
- Cuối cùng, sau một khoảng thời gian đủ dài (đôi khi lên đến một giờ), máy chủ có thể gửi lại tất cả các phân đoạn bị mất và tiếp tục như bình thường.
Cần lưu ý những điều sau:
- Không có điểm nào trong quá trình chụp được đặt kích thước Cửa sổ bằng 0, trên thực tế, trong quá trình khôi phục, máy khách đang tăng Cửa sổ của nó lên ~ 6byte mỗi ACK
- Đang chạy netstat cho thấy không có hàng đợi nhận hoặc truyền trong sự cố
- Chạy lệnh "ss" dường như cho thấy việc kích hoạt thuật toán tránh tắc nghẽn khối
Rõ ràng bất kỳ mất gói nào cũng không lý tưởng, nhưng câu hỏi của tôi chắc chắn đây không phải là hành vi đúng, trong đó 10-20 phân đoạn bị mất mất đến mấy giờ để khôi phục?
Điều này trông rất giống vấn đề của chúng tôi: https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/ Tôi có thể nói chuyện với các máy chủ máy chủ CoLo của chúng tôi và xem về việc nâng cấp kernel
