Tôi đã có một bí ẩn cho bạn ngày hôm nay. Chúng tôi chạy một cụm Elaticsearch nhỏ, ba nút dựa trên CoreOS (2023.5.0 / Linux 4.19.25-coreos) trên Azure. Elaticsearch được chạy bên trong một container docker ở chế độ mạng máy chủ. Sau khi chạy gần như hoàn toàn bảo trì miễn phí trong hơn một năm, chúng tôi đã thấy máy móc rơi vào trạng thái rất thú vị.
Cập nhật
Vấn đề này đã được giải quyết bằng cách sửa lỗi trình điều khiển trong nhân Linux . Xem câu trả lời dưới đây.
Triệu chứng
Về cơ bản, mạng giữa máy bị ảnh hưởng và hai nút còn lại sẽ chết. Tất cả đều nằm trong cùng một mạng ảo và cùng một mạng con và có thể giao tiếp với nhau một cách hữu ích. Nút bị ảnh hưởng vẫn có thể được truy cập từ các mạng con khác (tôi có thể ssh vào nó) và từ một mạng ảo ngang hàng khác. Máy cũng có kết nối (rất đốm) với Internet, nhưng hầu hết các yêu cầu chỉ hết thời gian.
Chúng tôi đã quan sát thấy rằng trên một nút bị ảnh hưởng, số lượng "socket được sử dụng" được báo cáo /proc/net/sockstatlà rất cao (~ 4,5k thay vì ~ 300 trên một nút khỏe mạnh). Theo dõi cho thấy con số này tăng lên nhanh chóng kể từ thời điểm nút không khả dụng.
Điều thú vị là dường như chúng ta không thể xác định được nguồn gốc của các ổ cắm được sử dụng này:
# cat /proc/net/sockstat
sockets: used 4566
TCP: inuse 2 orphan 0 tw 2 alloc 98 mem 4
UDP: inuse 1 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
# cat /proc/net/sockstat6
TCP6: inuse 98
UDP6: inuse 1
UDPLITE6: inuse 0
RAW6: inuse 1
FRAG6: inuse 0 memory 0
Khác hơn là máy có vẻ tốt. Không có quá trình đáng ngờ nào đang chạy, việc sử dụng CPU là tối thiểu và có rất nhiều bộ nhớ khả dụng.
Ping một VM "không thể truy cập" trong cùng một mạng con dẫn đến một vài EAGAINphản hồi recvmsgvà sau đó chuyển qua để lấy ENOBUFSlại từ đó sendmsg. đầu ra ping ở đây
Tôi đã thu thập một số đầu ra bổ sung (trước khi bất kỳ sửa đổi nào đối với hệ thống được thực hiện) và đăng nó trong ý chính này: https://gist.github.com/privatwolke/e7e2e7eb0272787765f5d3726f37107c
Phân tích
Chúng tôi đã cố gắng tắt tất cả mọi thứ chúng tôi có thể nghĩ trên máy chủ, với elaticsearch là nghi phạm đầu tiên. Nhưng việc tắt các thùng chứa elaticsearch không giải phóng các ổ cắm đã sử dụng. Điều tương tự cho tất cả các quy trình liên quan đến CoreOS (update-engine, lockmithd, ...) hoặc thậm chí toàn bộ thời gian chạy Docker hoặc công cụ dành riêng cho Azure. Dường như không có gì để giúp đỡ.
Nhưng bây giờ nó thậm chí còn kỳ lạ hơn: Chúng tôi đã cố gắng chạy tcpdumptrên máy để xem những gì đang xảy ra. Và kìa: Vấn đề tự giải quyết, kết nối đã được khôi phục. Lý thuyết của chúng tôi là tcpdump thực hiện một số kiểu nhà chọc trời giải quyết nó. Chúng tôi đã chạy tcpdump với gdb và đặt các điểm dừng trên tất cả các tòa nhà. Sau khi bước qua vô số điểm dừng, cuối cùng chúng tôi thấy rằng hành động thiết lập chế độ lăng nhăng trên ổ cắm (cụ thể là dòng này trong libpcap ) là điều đặt lại ổ cắm được sử dụng và đưa chúng tôi trở lại trạng thái bình thường.
Kết quả bổ sung
- Chúng tôi đã xác minh rằng việc chạy
tcpdumpvới-p/--no-promiscuous-modecờ không xóa các ổ cắm được sử dụng và đưa máy về trạng thái có thể sử dụng được. - Chạy
ifconfig eth0 txqueuelen 1001đặt lại các ổ cắm được sử dụng bộ đếm nhưng kết nối không được khôi phục. - Cài đặt chế độ lăng kính bằng tay
ip link set eth0 promisc oncũng không khôi phục kết nối.net.ipv4.xfrm4_gc_threshđược đặt thành 32768 và tăng lên một chút không giải quyết được vấn đề.
Chúng tôi đã liên hệ với Azure, những người gặp khó khăn như chúng tôi. Tôi hiểu rằng đây có thể không phải là vấn đề mà chỉ là một triệu chứng. Nhưng nó là thứ hữu hình duy nhất mà tôi tìm thấy cho đến nay. Hy vọng của tôi là bằng cách hiểu các triệu chứng tôi có thể đến gần hơn với nguyên nhân gốc rễ. Các giao diện mạng trên Azure được chạy với trình điều khiển mạng này .
Có lẽ CoreOS / Kernel là đáng trách?
Từ quan điểm dòng thời gian, các vấn đề bắt đầu vào 2019-03-11, đó là ngày mà CoreOS tự động cập nhật lên phiên bản mới nhất. Theo ghi chú phát hành , bản cập nhật này chứa bản cập nhật kernel từ 4.15.23 đến 4.19.25 . Tôi vẫn đang đi qua các thay đổi để xem liệu có bất cứ điều gì có thể là một vấn đề ở đó không. Cho đến nay tôi chỉ phát hiện ra rằng trình điều khiển mạng hyperv đã nhận được khá nhiều cập nhật trong những tháng gần đây , không phải tất cả trong số đó dường như là một phần của 4.19.25. Bản vá mà CoreOS áp dụng cho 4.19.25 không ấn tượng lắm , nhưng bản vá giới thiệu mô-đun nf_conntrack_ipv4 giả là mới.
Cập nhật: Có thể liên quan đến bản vá kernel đến?
Cứu giúp!
Cho đến nay, các câu hỏi chúng tôi có như sau:
Điều gì có thể khiến số liệu "ổ cắm được sử dụng" này tăng vọt? Tôi đã đọc qua các nguồn nhân cho số liệu này và dường như nó chỉ là một bộ đếm không có tham chiếu đến loại ổ cắm nào thực sự là gì hoặc cái gì đã tạo ra chúng.
Tại sao số căn hộ ở khoảng 4,5k? Giới hạn nào sẽ gây ra điều này?
Có điều gì đó thay đổi đáng kể giữa kernel 4.14.96 và 4.19.25 không?
Tại sao
setsockopt()cuộc gọi trong libpcap đặt lại trạng thái?
Lỗi CoreOS liên quan: https://github.com/coreos/bugs/issues/2572