मुझे आज आपके लिए एक रहस्य मिल गया है। हम Azure पर CoreOS (2023.5.0 / Linux 4.19.25-coreos) पर आधारित एक छोटा, तीन नोड इलास्टिक्स खोज समूह चलाते हैं। Elasticsearch होस्ट नेटवर्क मोड में एक डॉक कंटेनर के अंदर चलाया जाता है। एक वर्ष से अधिक के लिए लगभग पूरी तरह से रखरखाव मुफ्त चलाने के बाद हम मशीनों को एक बहुत ही दिलचस्प स्थिति में प्रवेश करते हुए देख रहे हैं।
अपडेट करें
यह समस्या लिनक्स कर्नेल में एक ड्राइवर को फिक्स करके हल की गई थी । नीचे उत्तर देखें।
लक्षण
मूल रूप से, प्रभावित मशीन और अन्य दो नोड्स के बीच नेटवर्किंग मर जाती है। सभी एक ही वर्चुअल नेटवर्क और एक ही सबनेट में होते हैं और दूसरे के साथ ususally संचार कर सकते हैं। प्रभावित नोड अभी भी अन्य सबनेट (मैं इसे में ssh कर सकते हैं) और एक अलग peered आभासी नेटवर्क से पहुँचा जा सकता है। मशीन में इंटरनेट के लिए (बहुत धब्बेदार) कनेक्शन भी है, लेकिन ज्यादातर अनुरोध समय से बाहर हो जाते हैं।
हमने देखा है कि एक प्रभावित नोड पर, रिपोर्ट की गई "सॉकेट्स" की संख्या /proc/net/sockstatबहुत अधिक है (एक स्वस्थ नोड पर ~ 300 के बजाय 4.5k)। मॉनिटरिंग से पता चलता है कि यह संख्या तेजी से बढ़ रही है कि नोड अनुपलब्ध हो गया है।
मज़े की बात यह है कि हम इन प्रयुक्त सॉकेट्स के स्रोत की पहचान नहीं कर सकते हैं:
# 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
इसके अलावा मशीन ठीक लगती है। कोई संदिग्ध प्रक्रिया नहीं चल रही है, सीपीयू का उपयोग कम से कम है और उपलब्ध मेमोरी की पैलेट है।
एक ही सबनेट में "अगम्य" वीएम को पिंग EAGAINकरने से कुछ प्रतिक्रियाएं होती हैं recvmsgऔर फिर ENOBUFSसे वापस आने के लिए पार हो जाती है sendmsg। स्ट्रेस पिंग आउटपुट यहाँ
मैंने कुछ अतिरिक्त आउटपुट एकत्र किए हैं (सिस्टम में कोई भी संशोधन करने से पहले) और इसे इस gist में पोस्ट किया है: https://gist.github.com/privatwolke/e7e2e7eb0272787765f5d3726437107c
विश्लेषण
हमने वह सब कुछ बंद करने की कोशिश की है जो हम सर्वर पर सोच सकते हैं, जिसमें इलास्टिक्सर्च पहला संदिग्ध है। लेकिन इलास्टिसर्च कंटेनर को बंद करने से उपयोग किए गए सॉकेट को खाली नहीं किया जाता है। सभी कोरओएस-संबंधित प्रक्रियाओं (अपडेट-इंजन, लॉकस्मिथ, ...) या यहां तक कि पूरे डॉकर रनटाइम या एज़्योर-विशिष्ट सामान के लिए एक ही बात। मदद के लिए कुछ भी नहीं लग रहा था।
लेकिन अब यह भी अजीब हो जाता है: हमने tcpdumpमशीन पर चलने का प्रयास किया कि क्या चल रहा है। और निहारना: समस्या खुद हल हो गई, कनेक्टिविटी बहाल हो गई। हमारा सिद्धांत था कि tcpdump किसी प्रकार का syscall करता है जो इसे हल करता है। हमने gdb के साथ tcpdump चलाया और सभी syscalls पर ब्रेकपॉइंट सेट किए। Breakpoints का भार के माध्यम से कदम के बाद, हम अंत में पाया गया कि कैप्चरिंग सॉकेट (विशेष रूप से पर अनेक मोड सेट का कार्य libpcap में इस लाइन ) बात यह है कि फिर सेट करता है सॉकेट एक सामान्य अवस्था में काउंटर और हमें रिटर्न इस्तेमाल किया है।
अतिरिक्त खोज
- हमने सत्यापित किया है कि झंडे के
tcpdumpसाथ चलने से-p/--no-promiscuous-modeउपयोग किए गए सॉकेट्स काउंटर को साफ नहीं करते हैं और मशीन को एक उपयोगी स्थिति में वापस कर देते हैं। - रनिंग उपयोग किए
ifconfig eth0 txqueuelen 1001गए सॉकेट को काउंटर पर रीसेट करता है लेकिन कनेक्टिविटी बहाल नहीं होती है। - साथ
ip link set eth0 promisc onही मैन्युअल मोड को सेट करना भी कनेक्टिविटी को बहाल नहीं करता है।net.ipv4.xfrm4_gc_thresh32768 पर सेट है और इसे थोड़ा बढ़ाने से समस्या का समाधान नहीं होता है।
हम एज़्योर के संपर्क में रहे हैं जो इस तरह से चकित हैं जैसे हम हैं। मैं समझता हूं कि यह समस्या नहीं है, बल्कि सिर्फ एक लक्षण है। लेकिन यह एकमात्र मूर्त चीज है जो मुझे अब तक मिली है। मेरी आशा है कि लक्षण को समझकर मैं मूल कारण के करीब पहुँच सकता हूँ। Azure पर नेटवर्क इंटरफ़ेस इस नेटवर्क ड्राइवर के साथ चलाया जाता है ।
शायद कोरोस / कर्नेल को दोष देना है?
समयावधि के दृष्टिकोण से, समस्याएं 2019-03-11 को शुरू हुईं, जिस दिन कोरओएस ऑटो-अपडेट से नवीनतम संस्करण में बदल गया। रिलीज नोट्स के अनुसार , इस अपडेट में 4.15.23 से 4.19.25 तक कर्नेल अपडेट था । मैं अभी भी चैंज के माध्यम से जा रहा हूं यह देखने के लिए कि क्या कुछ भी वहां एक मुद्दा हो सकता है। अब तक मैंने केवल यह पाया है कि हाइपर नेटवर्क ड्राइवर को हाल के महीनों में कुछ अपडेट मिले हैं , जो सभी 4.19.25 का हिस्सा नहीं लगते हैं। 4.19.25 को जो पैचसेट लागू हुआ वह प्रभावशाली नहीं है , लेकिन एक नकली nf_conntrack_ipv4 मॉड्यूल का परिचय देने वाला पैच नया है।
मदद!
अब तक, हमारे पास निम्नलिखित प्रश्न हैं:
इस "सॉकेट्स" मेट्रिक को आसमान छूने के लिए क्या कारण हो सकता है? मैंने इस मीट्रिक के लिए कर्नेल स्रोतों के माध्यम से पढ़ा है और यह सिर्फ एक काउंटर के रूप में प्रतीत होता है कि वे वास्तव में किस तरह के सॉकेट हैं या किस तरह से बनाए गए हैं।
लगभग ४.५ k पर फ्लैटलाइन क्यों है? यह किस सीमा के कारण होगा?
क्या कर्नेल 4.14.96 और 4.19.25 के बीच कुछ महत्वपूर्ण परिवर्तन हुआ?
setsockopt()Libpcap में कॉल राज्य को रीसेट क्यों करता है ?
संबंधित कोरओएस बग: https://github.com/coreos/bugs/issues/2572