कुछ साल पहले, कुबेरनेट्स की चर्चा पहले ही आधिकारिक गीथहब ब्लॉग पर की गई थी। तब से, यह सेवाओं को तैनात करने के लिए मानक तकनीक बन गया है। कुबेरनेट्स अब आंतरिक और सार्वजनिक सेवाओं के एक महत्वपूर्ण हिस्से का प्रबंधन करता है। जैसे-जैसे हमारे क्लस्टर बढ़ते गए और प्रदर्शन की आवश्यकताएं और अधिक सख्त होती गईं, हमने ध्यान देना शुरू किया कि कुबेरनेट्स पर कुछ सेवाएं छिटपुट रूप से प्रदर्शित होती हैं, जो कि एप्लिकेशन के भार से नहीं बताई जा सकती हैं।

वास्तव में, अनुप्रयोगों में, 100 एमएस या अधिक तक का एक यादृच्छिक नेटवर्क विलंब होता है, जो टाइमआउट या रिट्रीट की ओर जाता है। यह उम्मीद की गई थी कि सेवाएं 100 एमएस से अधिक तेजी से अनुरोधों का जवाब देने में सक्षम होंगी। लेकिन यह संभव नहीं है यदि कनेक्शन खुद को इतना समय लेता है। अलग-अलग, हमने बहुत तेजी से MySQL प्रश्नों का अवलोकन किया, जो कि मिलीसेकंड लेने वाले थे, और MySQL वास्तव में मिलीसेकंड में कामयाब रहा, लेकिन अनुरोध करने वाले आवेदन के दृष्टिकोण से, प्रतिक्रिया में 100 एमएस या अधिक लिया गया।

यह तुरंत स्पष्ट हो गया कि समस्या केवल कुबेरनेट्स होस्ट से कनेक्ट होने पर होती है, भले ही कॉल कुबेरनेट्स के बाहर से आया हो। समस्या का पुनरुत्पादन करने का सबसे आसान तरीका है वेजा टेस्ट, जो किसी भी आंतरिक मेजबान से चलता है, एक विशिष्ट पोर्ट पर कुबेरनेट्स सेवा का परीक्षण करता है, और छिटपुट रूप से एक बड़ी देरी को पंजीकृत करता है। इस लेख में, हम देखेंगे कि हम इस समस्या के कारण को कैसे ट्रैक करने में कामयाब रहे।

विफलता श्रृंखला में अनावश्यक जटिलता को हटा दें

उसी उदाहरण को पुन: प्रस्तुत करते हुए, हम समस्या के फोकस को कम करना चाहते थे और जटिलता की अतिरिक्त परतों को हटाना चाहते थे। प्रारंभ में, कुबेरनेट्स पर सब्जियों और फली के बीच की धारा में बहुत सारे तत्व थे। एक गहरी नेटवर्क समस्या की पहचान करने के लिए, आपको उनमें से कुछ को बाहर करने की आवश्यकता है।



क्लाइंट (सब्जियों) क्लस्टर में किसी भी नोड के साथ एक टीसीपी कनेक्शन बनाता है। कुबेरनेट्स एक ओवरले नेटवर्क (मौजूदा डेटा सेंटर नेटवर्क के शीर्ष पर) के रूप में कार्य करता है जो आईपीआईपी का उपयोग करता है, अर्थात , डेटा केंद्र के आईपी पैकेट के अंदर ओवरले नेटवर्क के आईपी पैकेट को एन्क्रिप्ट करता है। जब पहले नोड से कनेक्ट किया जाता है, तो नेटवर्क एड्रेस ट्रांसलेशन (NAT) नेटवर्क एड्रेस ट्रांसलेशन को IP मॉनिटर और आईपी एड्रेस के पोर्ट को IP एड्रेस और पोर्ट को ओवरले नेटवर्क पर पोर्ट (विशेष रूप से, एप्लिकेशन के साथ पॉड) में बदलने के लिए स्टेट मॉनिटरिंग के साथ किया जाता है। प्राप्त पैकेटों के लिए, रिवर्स अनुक्रम किया जाता है। यह कई राज्यों और कई तत्वों के साथ एक जटिल प्रणाली है जिसे सेवाओं को तैनात और स्थानांतरित करने के रूप में लगातार अद्यतन और परिवर्तित किया जाता है।

सब्जियों के परीक्षण में tcpdump उपयोगिता टीसीपी हैंडशेक (SYN और SYN-ACK के बीच) के दौरान देरी करती है। इस अनावश्यक जटिलता को दूर करने के लिए, आप SYN संकुल के साथ सरल "पिंग्स" के लिए hping3 उपयोग कर सकते हैं। जांच करें कि क्या प्रतिक्रिया पैकेट में देरी है, और फिर कनेक्शन रीसेट करें। हम 100 एमबी से अधिक केवल पैकेट को शामिल करके डेटा को फ़िल्टर कर सकते हैं, और सब्जियों में पूर्ण नेटवर्क स्तर 7 परीक्षण की तुलना में समस्या को पुन: पेश करने का एक सरल विकल्प प्राप्त कर सकते हैं। सबसे धीमी प्रतिक्रियाओं द्वारा फ़िल्टर किए गए 10 एमएस के अंतराल के साथ सेवा (30927) के मेजबान "पोर्ट" पर टीसीपी SYN / SYN-ACK का उपयोग करते हुए कुबेरनेट्स मेजबान के "पिंग" हैं:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -S -p 30927 -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1485 win=29200 rtt=127.1 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1486 win=29200 rtt=117.0 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1487 win=29200 rtt=106.2 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1488 win=29200 rtt=104.1 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5024 win=29200 rtt=109.2 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5231 win=29200 rtt=109.2 ms

तुरंत पहला अवलोकन कर सकते हैं। सीरियल नंबर और समय से पता चलता है कि ये एक बार की भीड़ नहीं हैं। देरी अक्सर जमा होती है, और अंततः संसाधित होती है।

अगला, हम यह पता लगाना चाहते हैं कि कौन से घटक भीड़ की उपस्थिति में शामिल हो सकते हैं। शायद ये NAT में सैकड़ों iptables नियमों में से कुछ हैं? या नेटवर्क पर आईपीआईपी टनलिंग के साथ कुछ समस्याएं? इसे सत्यापित करने का एक तरीका सिस्टम के प्रत्येक चरण को छोड़कर इसे सत्यापित करना है। यदि आप NAT और फ़ायरवॉल लॉजिक को हटाते हैं, तो IPIP का केवल एक भाग छोड़कर क्या होता है:



सौभाग्य से, यदि मशीन एक ही नेटवर्क पर है, तो लिनक्स सीधे आईपी ओवरले परत तक पहुंचना आसान बनाता है:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7346 win=0 rtt=127.3 ms

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7347 win=0 rtt=117.3 ms

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7348 win=0 rtt=107.2 ms

परिणामों को देखते हुए, समस्या अभी भी बनी हुई है! यह iptables और NAT को बाहर करता है। तो समस्या टीसीपी में है? आइए देखें कि ICMP पिंग कितना नियमित जाता है:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'

len=28 ip=10.125.20.64 ttl=64 id=42594 icmp_seq=104 rtt=110.0 ms

len=28 ip=10.125.20.64 ttl=64 id=49448 icmp_seq=4022 rtt=141.3 ms

len=28 ip=10.125.20.64 ttl=64 id=49449 icmp_seq=4023 rtt=131.3 ms

len=28 ip=10.125.20.64 ttl=64 id=49450 icmp_seq=4024 rtt=121.2 ms

len=28 ip=10.125.20.64 ttl=64 id=49451 icmp_seq=4025 rtt=111.2 ms

len=28 ip=10.125.20.64 ttl=64 id=49452 icmp_seq=4026 rtt=101.1 ms

len=28 ip=10.125.20.64 ttl=64 id=50023 icmp_seq=4343 rtt=126.8 ms

len=28 ip=10.125.20.64 ttl=64 id=50024 icmp_seq=4344 rtt=116.8 ms

len=28 ip=10.125.20.64 ttl=64 id=50025 icmp_seq=4345 rtt=106.8 ms

len=28 ip=10.125.20.64 ttl=64 id=59727 icmp_seq=9836 rtt=106.1 ms

परिणाम बताते हैं कि समस्या गायब नहीं हुई है। शायद यह एक आईपीआईपी सुरंग है? आइए परीक्षण को सरल बनाएं:



क्या सभी पैकेट इन दोनों मेजबानों के बीच भेजे जाते हैं?

theojulienne@kube-node-client ~ $ sudo hping3 172.16.47.27 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'

len=46 ip=172.16.47.27 ttl=61 id=41127 icmp_seq=12564 rtt=140.9 ms

len=46 ip=172.16.47.27 ttl=61 id=41128 icmp_seq=12565 rtt=130.9 ms

len=46 ip=172.16.47.27 ttl=61 id=41129 icmp_seq=12566 rtt=120.8 ms

len=46 ip=172.16.47.27 ttl=61 id=41130 icmp_seq=12567 rtt=110.8 ms

len=46 ip=172.16.47.27 ttl=61 id=41131 icmp_seq=12568 rtt=100.7 ms

len=46 ip=172.16.47.27 ttl=61 id=9062 icmp_seq=31443 rtt=134.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9063 icmp_seq=31444 rtt=124.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9064 icmp_seq=31445 rtt=114.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9065 icmp_seq=31446 rtt=104.2 ms

हमने दो कुबेरनेट मेजबानों को एक-दूसरे को पैकेट भेजने की स्थिति को सरल बनाया, यहां तक ​​कि आईसीएमपी पिंग भी। यदि लक्ष्य होस्ट "खराब" (दूसरों की तुलना में कुछ खराब) है, तो भी उन्हें देरी दिखाई देती है।

अब आखिरी सवाल: क्यूब-नोड सर्वर पर केवल देरी क्यों होती है? और क्या यह तब होता है जब क्यूब-नोड प्रेषक या रिसीवर है? सौभाग्य से, कुबेरनेट्स के बाहर एक मेजबान से एक पैकेट भेजकर यह पता लगाना बहुत आसान है, लेकिन उसी "ज्ञात खराब" प्राप्तकर्ता के साथ। जैसा कि आप देख सकते हैं, समस्या गायब नहीं हुई है:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=312 win=0 rtt=108.5 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=5903 win=0 rtt=119.4 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=6227 win=0 rtt=139.9 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=7929 win=0 rtt=131.2 ms

तब हम पिछले स्रोत के क्यूब-नोड से बाहरी होस्ट (जो मूल होस्ट को बाहर करता है, के बाद से एक ही अनुरोध करते हैं, क्योंकि पिंग में RX और TX दोनों घटक शामिल हैं):

theojulienne@kube-node-client ~ $ sudo hping3 172.16.33.44 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}\.'
^C
--- 172.16.33.44 hping statistic ---
22352 packets transmitted, 22350 packets received, 1% packet loss
round-trip min/avg/max = 0.2/7.6/1010.6 ms

विलंबित पैकेट कैप्चर की जांच करने के बाद, हमें कुछ अतिरिक्त जानकारी मिली। विशेष रूप से, कि प्रेषक (नीचे) इस टाइमआउट को देखता है, लेकिन रिसीवर (ऊपर) इसे नहीं देखता है - डेल्टा कॉलम (सेकंड में) देखें:



इसके अलावा, यदि आप प्राप्तकर्ता की ओर से टीसीपी और आईसीएमपी पैकेट (अनुक्रम संख्या द्वारा) के क्रम में अंतर को देखते हैं, तो आईसीएमपी पैकेट हमेशा उसी क्रम में आते हैं जिसमें उन्हें भेजा गया था, लेकिन अलग-अलग समय के साथ। इसी समय, टीसीपी पैकेट कभी-कभी वैकल्पिक होते हैं, और उनमें से कुछ अटक जाते हैं। विशेष रूप से, यदि हम SYN पैकेट के बंदरगाहों की जांच करते हैं, तो प्रेषक पक्ष पर वे क्रम में जाते हैं, लेकिन प्राप्तकर्ता पक्ष पर ऐसा नहीं होता है।

टीसीपी या आईसीएमपी वाले आधुनिक पैकेट (हमारे डेटा सेंटर में) प्रक्रिया पैकेट के नेटवर्क कार्ड कैसे होते हैं, इसमें एक सूक्ष्म अंतर है। जब एक पैकेट आता है, तो नेटवर्क अडैप्टर "इसे कनेक्शन पर हैश करता है", अर्थात यह मुड़ें में कनेक्शन को तोड़ने और प्रत्येक कतार को एक अलग प्रोसेसर कोर में भेजने की कोशिश करता है। टीसीपी के लिए, इस हैश में स्रोत और गंतव्य आईपी पता और पोर्ट दोनों शामिल हैं। दूसरे शब्दों में, प्रत्येक कनेक्शन अलग से हैश (संभावित) है। ICMP के लिए, केवल IP पते हीशेड हैं, क्योंकि कोई पोर्ट नहीं हैं।

एक और नया अवलोकन: इस अवधि के दौरान हम दो मेजबानों के बीच सभी संचारों पर आईसीएमपी देरी देखते हैं, लेकिन टीसीपी नहीं करता है। यह हमें बताता है कि इसका कारण संभवतः आरएक्स कतारों के हैशिंग के कारण है: यह लगभग निश्चित है कि प्रतिक्रियाएं भेजने के बजाय आरएक्स पैकेट के प्रसंस्करण में भीड़भाड़ होती है।

यह संभावित कारणों की सूची से पैकेट भेजने को बाहर करता है। अब हम जानते हैं कि पैकेट प्रसंस्करण के साथ समस्या कुछ क्यूब-नोड सर्वर पर प्राप्त करने की ओर है।

लिनक्स कर्नेल में पैकेज प्रोसेसिंग को समझना

यह समझने के लिए कि कुछ क्यूब-नोड सर्वर पर प्राप्तकर्ता के साथ समस्या क्यों होती है, आइए देखें कि लिनक्स कर्नेल संकुल को कैसे संभालता है।

सबसे सरल पारंपरिक कार्यान्वयन पर लौटने पर, नेटवर्क कार्ड पैकेट प्राप्त करता है और लिनक्स कर्नेल के लिए एक बाधा भेजता है, जो कि पैकेट है जिसे संसाधित करने की आवश्यकता है। कर्नेल एक अन्य ऑपरेशन को रोकता है, संदर्भ को हैंडलर में बदलता है, पैकेज को संसाधित करता है, और फिर वर्तमान कार्यों पर लौटता है।



यह संदर्भ स्विच धीमा है: 90 के दशक में 10-मेगाबाइट नेटवर्क कार्ड पर शायद देरी ध्यान देने योग्य नहीं थी, लेकिन आधुनिक 10G कार्ड पर प्रति सेकंड 15 मिलियन पैकेट की अधिकतम थ्रूपुट के साथ, एक छोटे आठ-कोर सर्वर के प्रत्येक कोर को प्रति सेकंड लाखों बार बाधित किया जा सकता है।

लगातार व्यवधान से निपटने के लिए नहीं, कई साल पहले लिनक्स ने NAPI को जोड़ा: एक नेटवर्क एपीआई जिसका उपयोग सभी आधुनिक चालक उच्च गति पर प्रदर्शन बढ़ाने के लिए करते हैं। कम गति पर, कर्नेल अभी भी पुराने तरीके से नेटवर्क कार्ड से व्यवधान स्वीकार करता है। जैसे ही पर्याप्त संख्या में पैकेट आते हैं कि सीमा से अधिक हो जाता है, कर्नेल बाधित होता है और इसके बजाय नेटवर्क एडॉप्टर से मतदान करना शुरू कर देता है और पैकेट को बैचों में ले जाता है। सॉफ्टरिक में प्रसंस्करण किया जाता है, अर्थात्, सॉफ्टवेयर कॉल के संदर्भ में सिस्टम कॉल और हार्डवेयर बाधित होने के बाद जब कर्नेल पहले से ही चल रहा होता है।



यह बहुत तेज है, लेकिन एक अलग समस्या का कारण बनता है। यदि बहुत अधिक पैकेट हैं, तो हर समय नेटवर्क कार्ड से पैकेट को संसाधित करने में समय लगता है, और उपयोगकर्ता स्थान प्रक्रियाओं के पास वास्तव में इन कतारों (टीसीपी कनेक्शन आदि से पढ़ना) को खाली करने का समय नहीं है। अंत में, कतारें भर जाती हैं और हम पैकेट छोड़ना शुरू कर देते हैं। एक संतुलन खोजने की कोशिश करते हुए, कर्नेल सॉफ्टरिक संदर्भ में संसाधित अधिकतम पैकेट के लिए एक बजट निर्धारित करता है। एक बार जब यह बजट पार हो जाता है, तो एक अलग ksoftirqd थ्रेड ksoftirqd (आप प्रत्येक कोर के लिए ps में उनमें से एक देखेंगे), जो इन सॉफ्टरिक को सामान्य सीस्कॉल / इंटरप्ट पथ के बाहर संसाधित करता है। यह धागा एक मानक प्रक्रिया अनुसूचक का उपयोग करके योजनाबद्ध किया गया है जो संसाधनों को निष्पक्ष रूप से वितरित करने का प्रयास करता है।



यह जांचने के बाद कि कर्नेल पैकेट कैसे संसाधित करता है, आप देख सकते हैं कि भीड़भाड़ की एक निश्चित संभावना है। यदि सॉफ्टरैक कॉल कम बार प्राप्त होते हैं, तो नेटवर्क कार्ड पर आरएक्स कतार में प्रसंस्करण के लिए पैकेट को थोड़ी देर इंतजार करना होगा। शायद यह प्रोसेसर कोर को अवरुद्ध करने वाले कुछ कार्य के कारण है, या कुछ और कर्नेल को सॉफ्टरिक शुरू करने से रोकता है।

हम प्रसंस्करण को कर्नेल या विधि तक सीमित करते हैं

सॉफ्टरिक विलंब केवल एक धारणा है। लेकिन यह समझ में आता है, और हम जानते हैं कि हम कुछ समान देख रहे हैं। इसलिए, इस सिद्धांत की पुष्टि करने के लिए अगला कदम है। और अगर इसकी पुष्टि हो जाती है, तो देरी का कारण ढूंढें।

हमारे धीमे पैकेजों पर वापस:

len=46 ip=172.16.53.32 ttl=61 id=29573 icmp_seq=1953 rtt=99.3 ms

len=46 ip=172.16.53.32 ttl=61 id=29574 icmp_seq=1954 rtt=89.3 ms

len=46 ip=172.16.53.32 ttl=61 id=29575 icmp_seq=1955 rtt=79.2 ms

len=46 ip=172.16.53.32 ttl=61 id=29576 icmp_seq=1956 rtt=69.1 ms

len=46 ip=172.16.53.32 ttl=61 id=29577 icmp_seq=1957 rtt=59.1 ms

len=46 ip=172.16.53.32 ttl=61 id=29790 icmp_seq=2070 rtt=75.7 ms

len=46 ip=172.16.53.32 ttl=61 id=29791 icmp_seq=2071 rtt=65.6 ms

len=46 ip=172.16.53.32 ttl=61 id=29792 icmp_seq=2072 rtt=55.5 ms

जैसा कि पहले चर्चा की गई है, इन ICMP पैकेटों को एक एकल NIC RX कतार में हैश किया जाता है और एक एकल CPU कोर द्वारा संसाधित किया जाता है। यदि हम यह समझना चाहते हैं कि लिनक्स कैसे काम करता है, तो यह जानना उपयोगी है कि कहां (किस सीपीयू कोर पर) और कैसे (सॉफ्टरैक, क्सोफ्टिरकड) इन पैकेजों को प्रोसेस करने के लिए प्रोसेस किया जाता है।

अब उन उपकरणों का उपयोग करने का समय है जो लिनक्स कर्नेल की वास्तविक समय की निगरानी की अनुमति देते हैं। यहां हमने बीसीसी का इस्तेमाल किया। यह टूलकिट आपको छोटे सी प्रोग्राम लिखने की अनुमति देता है जो कर्नेल और बफर ईवेंट्स में मनमाने कार्यों को एक यूजर-स्पेस पायथन प्रोग्राम में इंटरसेप्ट करता है जो उन्हें प्रोसेस कर सकता है और आपको परिणाम लौटा सकता है। कर्नेल में मनमाने कार्यों के लिए हुक जटिल हैं, लेकिन उपयोगिता को अधिकतम सुरक्षा के लिए डिज़ाइन किया गया है और यह सटीक रूप से ऐसी उत्पादन समस्याओं को ट्रैक करने के लिए डिज़ाइन किया गया है जो परीक्षण या विकास वातावरण में पुन: पेश करना आसान नहीं है।

यहां योजना सरल है: हम जानते हैं कि कर्नेल इन ICMP पिंग को प्रोसेस करता है, इसलिए हम icmp_echo कर्नेल फ़ंक्शन पर एक हुक लगाते हैं , जो आने वाले ICMP पैकेट "इको रिक्वेस्ट" को प्राप्त करता है और ICCC प्रतिक्रिया "इको रिस्पांस" भेजने की पहल करता है। हम icmp_seq संख्या को बढ़ाकर पैकेज की पहचान कर सकते हैं, जो ऊपर hping3 दिखाता है।

Bcc स्क्रिप्ट कोड जटिल लगता है, लेकिन यह उतना डरावना नहीं है जितना लगता है। icmp_echo फ़ंक्शन struct sk_buff *skb पास करता है: यह "इको रिक्वेस्ट" अनुरोध के साथ पैकेट है। हम इसे ट्रैक कर सकते हैं, echo.sequence अनुक्रम (जो icmp_seq से icmp_seq के लिए icmp_seq करते ) को खींच सकते हैं, और इसे उपयोगकर्ता स्थान पर भेज सकते हैं। वर्तमान प्रक्रिया नाम / पहचानकर्ता को कैप्चर करना भी सुविधाजनक है। नीचे वे परिणाम हैं जो हम सीधे कर्नेल द्वारा संकुल के प्रसंस्करण के दौरान देखते हैं:

  TGID PID प्रक्रिया का नाम ICMP_SEQ है
 0 0 स्वैपर / 11,770
 0 0 स्वैपर / 11,771
 0 0 स्वैपर / 11 772
 0 0 स्वैपर / 11 773
 0 0 स्वैपर / 11,774
 20041 20086 प्रोमेथियस 775
 0 0 स्वैपर / 11,776
 0 0 स्वैपर / 11,777
 0 0 स्वैपर / 11 778
 4512 4542 प्रवक्ता-रिपोर्ट-एस 779 

यहां यह ध्यान दिया जाना चाहिए कि softirq के संदर्भ में softirq सिस्टम कॉल करने वाली प्रक्रियाएं "प्रक्रियाएं" के रूप में दिखाई देती हैं, हालांकि वास्तव में यह कर्नेल कर्नेल के संदर्भ में पैकेट को सुरक्षित रूप से संसाधित करता है।

इस उपकरण के साथ हम विशिष्ट पैकेजों के साथ विशिष्ट प्रक्रियाओं का कनेक्शन स्थापित कर सकते हैं जो hping3 में देरी hping3 । हम विशिष्ट icmp_seq मूल्यों के लिए इस कैप्चर पर एक साधारण grep icmp_seq हैं। उपरोक्त icmp_seq मूल्यों के अनुरूप पैकेट को उनके RTT के साथ चिह्नित किया गया था, जिसे हमने ऊपर देखा (कोष्ठक में पैकेट के लिए अपेक्षित RTT मान जो हमने RTT मानों को 50 ms से कम होने के कारण फ़िल्टर किया है):

  TGID PID प्रक्रिया का नाम ICMP_SEQ ** RTT है
 -
 10137 10436 कैडवाइजर 1951
 10137 10436 कैडवाइजर 1952
 76 76 ksoftirqd / 11 1953 ** 99ms
 76 76 ksoftirqd / 11 1954 ** 89ms
 76 76 ksoftirqd / 11 1955 ** 79ms
 76 76 ksoftirqd / 11 1956 ** 69ms
 76 76 ksoftirqd / 11 1957 ** 59ms
 76 76 ksoftirqd / 11 1958 ** (49ms)
 76 76 ksoftirqd / 11 1959 ** (39ms)
 76 76 ksoftirqd / 11 1960 ** (29 सेमी)
 76 76 ksoftirqd / 11 1961 ** (19ms)
 76 76 ksoftirqd / 11 1962 ** (9ms)
 -
 10137 10436 कैडवाइजर 2068
 10137 10436 कैडवाइजर 2069
 76 76 ksoftirqd / 11 2070 ** 75ms
 76 76 ksoftirqd / 11 2071 ** 65ms
 76 76 ksoftirqd / 11 2072 ** 55ms
 76 76 ksoftirqd / 11 2073 ** (45 सेमी)
 76 76 ksoftirqd / 11 2074 ** (35 सेमी)
 76 76 ksoftirqd / 11 2075 ** (25ms)
 76 76 ksoftirqd / 11 2076 ** (15ms)
 76 76 ksoftirqd / 11 2077 ** (5ms) 

परिणाम हमें कुछ चीजें बताते हैं। सबसे पहले, ksoftirqd/11 संदर्भ इन सभी पैकेजों को संभालता है। इसका मतलब यह है कि मशीनों की इस विशेष जोड़ी के लिए, ICMP पैकेट को 11 कोर पर प्राप्त अंत में हैशेड किया गया था। हम यह भी देखते हैं कि प्रत्येक ट्रैफ़िक जाम में ऐसे पैकेट होते हैं जिन्हें cadvisor सिस्टम कॉल के संदर्भ में संसाधित किया जाता है। तब ksoftirqd कार्य को पूरा करता है और संचित कतार को पूरा करता है: ठीक उसी प्रकार के पैकेट जो cadvisor बाद संचित cadvisor ।

तथ्य यह है कि एक cadvisor हमेशा काम करता है इससे पहले कि यह समस्या में उसकी भागीदारी का मतलब है। विडंबना यह है कि कैडवाइजर का उद्देश्य इस प्रदर्शन की समस्या के कारण "संसाधन उपयोग और चलने वाले कंटेनरों की प्रदर्शन विशेषताओं का विश्लेषण करना" है।

कंटेनर हैंडलिंग के अन्य पहलुओं के साथ, ये सभी बेहद उन्नत उपकरण हैं जिनसे कुछ अप्रत्याशित परिस्थितियों में प्रदर्शन की समस्याओं की उम्मीद की जा सकती है।

कैडविसर क्या करता है जो पैकेट की कतार को धीमा कर देता है?

अब हमें बहुत अच्छी समझ है कि विफलता कैसे होती है, कौन सी प्रक्रिया इसका कारण बनती है, और किस सीपीयू पर। हम देखते हैं कि हार्ड लॉकिंग के कारण, लिनक्स कर्नेल के पास समय ksoftirqd को शेड्यूल करने का समय नहीं है। और हम देखते हैं कि पैकेज cadvisor के संदर्भ में संसाधित किए जाते हैं। यह मानना ​​तर्कसंगत है कि cadvisor एक धीमी गति से cadvisor शुरू करता है, जिसके बाद इस समय जमा किए गए सभी पैकेट संसाधित होते हैं:



यह एक सिद्धांत है, लेकिन इसका परीक्षण कैसे किया जाए? हम इस प्रक्रिया के दौरान सीपीयू कोर के संचालन को ट्रैक करने के लिए क्या कर सकते हैं, वह बिंदु ढूंढें जहां बजट पैकेट और ksoftirqd की संख्या से अधिक है, और फिर थोड़ा पहले देखें - उस पल से पहले सीपीयू कोर पर वास्तव में क्या काम किया। यह हर कुछ मिलीसेकंड के सीपीयू के एक्स-रे की तरह है। यह कुछ इस तरह दिखेगा:



आसानी से, यह सब मौजूदा उपकरणों के साथ किया जा सकता है। उदाहरण के लिए, पूर्ण रिकॉर्ड निर्दिष्ट आवृत्ति के साथ निर्दिष्ट सीपीयू कोर की जांच करता है और उपयोगकर्ता के अंतरिक्ष और लिनक्स कर्नेल दोनों सहित एक चल रहे सिस्टम पर कॉल की एक अनुसूची उत्पन्न कर सकता है। आप इस रिकॉर्ड को ले सकते हैं और ब्रेंडन ग्रेग से फ्लेमग्राफ कार्यक्रम के एक छोटे से कांटे का उपयोग करके इसे संसाधित कर सकते हैं, जो स्टैक ट्रेस ऑर्डर को संरक्षित करता है। हम हर 1 ms में एक-पंक्ति स्टैक के निशान बचा सकते हैं, और फिर ksoftirqd ट्रेस में जाने से पहले 100 मिलीसेकेंड के लिए नमूने का चयन करें और सहेजें:

# record 999 times a second, or every 1ms with some offset so not to align exactly with timers
sudo perf record -C 11 -g -F 999
# take that recording and make a simpler stack trace.
sudo perf script 2>/dev/null | ./FlameGraph/stackcollapse-perf-ordered.pl | grep ksoftir -B 100

यहाँ परिणाम हैं:

( , )

cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_iter cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;ixgbe_poll;ixgbe_clean_rx_irq;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;bond_handle_frame;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;ipip_tunnel_xmit;ip_tunnel_xmit;iptunnel_xmit;ip_local_out;dst_output;__ip_local_out;nf_hook_slow;nf_iterate;nf_conntrack_in;generic_packet;ipt_do_table;set_match_v4;ip_set_test;hash_net4_kadt;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;hash_net4_test ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;gro_cell_poll;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;dev_queue_xmit_nit;packet_rcv;tpacket_rcv;sch_direct_xmit;validate_xmit_skb_list;validate_xmit_skb;netif_skb_features;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;__dev_queue_xmit;dev_hard_start_xmit;__bpf_prog_run;__bpf_prog_run

यहां बहुत सी चीजें हैं, लेकिन मुख्य बात यह है कि हम "कैडफोर्स से पहले ksoftirqd" टेम्पलेट पाते हैं जो हमने पहले ICMP ट्रेसर में देखा था। इसका क्या मतलब है?

प्रत्येक पंक्ति समय में एक विशेष बिंदु पर सीपीयू का एक निशान है। एक पंक्ति में स्टैक के नीचे प्रत्येक कॉल को अर्धविराम द्वारा अलग किया जाता है। रेखाओं के बीच में हम syscall कहते हैं: read(): .... ;do_syscall_64;sys_read; ... read(): .... ;do_syscall_64;sys_read; ... । इस प्रकार, कैडवाइजर read() सिस्टम कॉल पर बहुत समय बिताता है, mem_cgroup_* फ़ंक्शंस (कॉल स्टैक / पंक्ति के अंत के ऊपर) से संबंधित है।

कॉल ट्रेस में, यह देखने के लिए असुविधाजनक है कि वास्तव में क्या पढ़ा जा रहा है, इसलिए स्ट्रेस चलाएं और देखें कि कैडविसर क्या करता है, और सिस्टम कॉल 100 एमएस से अधिक समय तक ढूंढें:

theojulienne@kube-node-bad ~ $ sudo strace -p 10137 -T -ff 2>&1 | egrep '<0\.[1-9]'
[pid 10436] <... futex resumed> ) = 0 <0.156784>
[pid 10432] <... futex resumed> ) = 0 <0.258285>
[pid 10137] <... futex resumed> ) = 0 <0.678382>
[pid 10384] <... futex resumed> ) = 0 <0.762328>
[pid 10436] <... read resumed> "cache 154234880\nrss 507904\nrss_h"..., 4096) = 658 <0.179438>
[pid 10384] <... futex resumed> ) = 0 <0.104614>
[pid 10436] <... futex resumed> ) = 0 <0.175936>
[pid 10436] <... read resumed> "cache 0\nrss 0\nrss_huge 0\nmapped_"..., 4096) = 577 <0.228091>
[pid 10427] <... read resumed> "cache 0\nrss 0\nrss_huge 0\nmapped_"..., 4096) = 577 <0.207334>
[pid 10411] <... epoll_ctl resumed> ) = 0 <0.118113>
[pid 10382] <... pselect6 resumed> ) = 0 (Timeout) <0.117717>
[pid 10436] <... read resumed> "cache 154234880\nrss 507904\nrss_h"..., 4096) = 660 <0.159891>
[pid 10417] <... futex resumed> ) = 0 <0.917495>
[pid 10436] <... futex resumed> ) = 0 <0.208172>
[pid 10417] <... futex resumed> ) = 0 <0.190763>
[pid 10417] <... read resumed> "cache 0\nrss 0\nrss_huge 0\nmapped_"..., 4096) = 576 <0.154442>

जैसा कि आप उम्मीद कर सकते हैं, यहाँ हम धीमी गति से read() कॉल देखते हैं। रीड ऑपरेशन और mem_cgroup संदर्भ की सामग्री से, mem_cgroup देखा जा सकता है कि ये read() कॉल memory.stat फ़ाइल को संदर्भित memory.stat हैं, जो मेमोरी उपयोग और सीग्रुप सीमाओं (डॉकर संसाधन अलगाव प्रौद्योगिकी) को दिखाती है। कैडवाइजर टूल कंटेनरों के लिए संसाधन उपयोग की जानकारी के लिए इस फाइल को पोल करता है। आइए देखें कि क्या यह कोर या कैडवाइजर कुछ अप्रत्याशित करता है:

theojulienne@kube-node-bad ~ $ time cat /sys/fs/cgroup/memory/memory.stat >/dev/null

real 0m0.153s
user 0m0.000s
sys 0m0.152s
theojulienne@kube-node-bad ~ $

अब हम बग को पुन: पेश कर सकते हैं और समझ सकते हैं कि लिनक्स कर्नेल पैथोलॉजी का सामना कर रहा है।

इतना धीमा पढ़ने से क्या होता है?

इस बिंदु पर, समान मुद्दों के बारे में अन्य उपयोगकर्ताओं से संदेश प्राप्त करना बहुत आसान है। जैसा कि यह पता चला है, कैडवाइजर ट्रैकर में इस बग को अत्यधिक सीपीयू उपयोग की समस्या के रूप में बताया गया था, बस किसी ने ध्यान नहीं दिया कि देरी भी नेटवर्क स्टैक में बेतरतीब ढंग से परिलक्षित हुई थी। वास्तव में, यह देखा गया कि कैडविसर उम्मीद से अधिक प्रोसेसर समय का उपभोग करता है, लेकिन इसे बहुत महत्व नहीं दिया गया था, क्योंकि हमारे सर्वर में बहुत सारे प्रोसेसर संसाधन हैं, इसलिए हमने समस्या का सावधानीपूर्वक अध्ययन नहीं किया।

समस्या यह है कि नियंत्रण समूह (cgroups) नेमस्पेस (कंटेनर) के अंदर मेमोरी उपयोग को ध्यान में रखते हैं। जब इस cgroup में सभी प्रक्रियाएँ समाप्त हो जाती हैं, तो Docker मेमोरी के एक नियंत्रण समूह को मुक्त कर देता है। हालाँकि, "मेमोरी" केवल एक प्रोसेस मेमोरी नहीं है। हालाँकि प्रक्रिया मेमोरी स्वयं उपयोग नहीं की जाती है, फिर भी यह पता चलता है कि कर्नेल कैश्ड सामग्री, जैसे डेंट्री और इनोडेस (निर्देशिका और फ़ाइल मेटाडेटा) भी प्रदान करता है, जो कि मेमोरी कॉग्रुप में कैश्ड होते हैं। समस्या के वर्णन से:

cgroups लाश: उन समूहों को नियंत्रित करता है जिनमें कोई प्रक्रिया नहीं होती है और उन्हें हटा दिया जाता है, लेकिन जिसके लिए मेमोरी अभी भी आबंटित है (मेरे मामले में, डेंट्री कैश से, लेकिन इसे पेज कैश या tmpfs से भी आवंटित किया जा सकता है)।

कैश में सभी पेजों की जाँच करते समय जब cgroup को मुक्त किया जाता है, तो यह बहुत धीमा हो सकता है, इसलिए आलसी प्रक्रिया को चुना जाता है: इन पेजों के दोबारा अनुरोध किए जाने तक प्रतीक्षा करें, और जब मेमोरी की वास्तव में आवश्यकता हो, तब भी अंत में cgroup को साफ़ करें। अब तक, आँकड़े एकत्र करते समय cgroup को अभी भी ध्यान में रखा जाता है।

प्रदर्शन के संदर्भ में, उन्होंने प्रदर्शन के लिए स्मृति का बलिदान किया: इस तथ्य के कारण प्रारंभिक सफाई में तेजी आई कि थोड़ी सी स्मृति बनी हुई है। यह सामान्य है। जब कर्नेल कैश्ड मेमोरी के अंतिम भाग का उपयोग करता है, तो cgroup अंततः साफ़ हो जाता है, इसलिए इसे "लीक" नहीं कहा जा सकता। दुर्भाग्य से, इस कर्नेल संस्करण (4.9) में memory.stat खोज तंत्र का विशिष्ट कार्यान्वयन, हमारे सर्वर पर बड़ी मात्रा में मेमोरी के साथ होता है, इस तथ्य की ओर जाता है कि नवीनतम कैश्ड डेटा और स्पष्ट cgroup लाश को पुनर्स्थापित करने में अधिक समय लगता है।

यह पता चला है कि हमारे कुछ नोड्स पर इतने सारे cgroup लाश थे कि पढ़ना और विलंबता एक सेकंड से अधिक हो गई।

कैडविसर समस्या के लिए एक समाधान है कि पूरे सिस्टम में डेंट्री / इनोडेस कैश को तुरंत साफ़ करें, जो होस्ट पर नेटवर्क विलंबता के साथ-साथ रीड लेटेंसी को तुरंत समाप्त कर देता है, क्योंकि कैश को हटाने से cgroup ज़ोंबी कैश्ड पेज शामिल हैं, और वे भी मुक्त हो जाते हैं। यह एक समाधान नहीं है, लेकिन समस्या के कारण की पुष्टि करता है।

यह पता चला कि कर्नेल के नए संस्करणों (4.19+) ने memory.stat कॉल के प्रदर्शन में सुधार किया है, इसलिए इस कर्नेल पर स्विच करने से समस्या ठीक हो गई। उसी समय, हमारे पास कुबेरनेट्स समूहों में समस्या नोड्स का पता लगाने के लिए उपकरण थे, जो उन्हें अच्छी तरह से सूखा और रिबूट कर रहे थे। हमने सभी समूहों के माध्यम से कंघी की, नोड्स को पर्याप्त उच्च विलंब के साथ पाया और उन्हें रिबूट किया। इससे हमें बाकी सर्वरों पर OS अपडेट करने का समय मिल गया।

संक्षेप में देना

चूंकि इस बग ने सैकड़ों मिलीसेकंड के लिए एनआईसी आरएक्स कतारों के प्रसंस्करण को रोक दिया, इसलिए इसने छोटे कनेक्शन पर एक बड़ी देरी और कनेक्शन के बीच में देरी, उदाहरण के लिए, MySQL प्रश्नों और प्रतिक्रिया पैकेट के बीच।

, Kubernetes, . Kubernetes .