🔇 🗿 👱 Google क्लाउड से DNS क्लाउड सपोर्ट स्टोरी गुम ✌🏿 ♏️ 🚶🏽

Google ब्लॉग संपादक से: क्या आपने कभी सोचा है कि Google क्लाउड तकनीकी समाधान (TSE) इंजीनियर आपके तकनीकी समर्थन कॉल को कैसे संभालते हैं? TSE तकनीकी सहायता इंजीनियरों की जिम्मेदारी उपयोगकर्ताओं द्वारा पहचानी गई समस्याओं के स्रोतों का पता लगाना और उनका समाधान करना है। इनमें से कुछ समस्याएं काफी सरल हैं, लेकिन कभी-कभी आप एक अपील में आते हैं जो एक बार में कई इंजीनियरों का ध्यान आकर्षित करने की आवश्यकता होती है। इस लेख में, TSE का एक कर्मचारी हमें अपने हालिया अभ्यास से एक बहुत ही पेचीदा समस्या के बारे में बताएगा - लापता पैकेट के मामले में। इस कहानी के दौरान, हम देखेंगे कि इंजीनियर किस तरह से स्थिति को हल करने में कामयाब रहे, और त्रुटि को खत्म करने के दौरान उन्होंने कौन सी नई चीजें सीखीं। हमें उम्मीद है कि यह कहानी न केवल आपको एक गहरी जड़ वाले बग के बारे में बताएगी, बल्कि Google क्लाउड का समर्थन करने के लिए अनुरोध सबमिट करते समय होने वाली प्रक्रियाओं की समझ भी प्रदान करेगी।

समस्या निवारण विज्ञान और कला दोनों है। यह सब सिस्टम के गैर-मानक व्यवहार के कारण के बारे में एक परिकल्पना बनाने के साथ शुरू होता है, जिसके बाद इसे ताकत के लिए परीक्षण किया जाता है। हालांकि, एक परिकल्पना तैयार करने से पहले, हमें स्पष्ट रूप से पहचानना चाहिए और समस्या को सटीक रूप से तैयार करना चाहिए। यदि प्रश्न बहुत अस्पष्ट लगता है, तो आपको सब कुछ ठीक से विश्लेषण करना होगा; यह समस्या निवारण की "कला" है।

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

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

विचाराधीन मुद्दा

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

यह संदेश आपके लिए बहुत उपयोगी है:

निर्दिष्ट वी.एम.
समस्या को इंगित किया गया है - DNS काम नहीं करता है
यह इंगित किया जाता है कि समस्या स्वयं कहाँ प्रकट होती है - वीएम और कंटेनर
समस्या की पहचान करने के लिए उपयोगकर्ता ने जो कदम उठाए हैं वे संकेत दिए गए हैं।

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

ज़्यूरिख तक टिकट पहुंचने तक, हमारे पास पहले से ही निम्नलिखित जानकारी थी:

सामग्री /etc/hosts
सामग्री /etc/resolv.conf
निष्कर्ष iptables-save
कमांड द्वारा संकलित ngreppcap फ़ाइल

इस डेटा के साथ, हम "जांच" और समस्या निवारण चरण शुरू करने के लिए तैयार थे।

हमारा पहला कदम

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

यह कुछ अजीब समस्या थी: एनएपीपी परीक्षण ने यूडीपी पैकेट के नुकसान के बारे में हमारी मुख्य परिकल्पना का खंडन किया, इसलिए हमने मानसिक रूप से उन्हें जांचने के कई और विकल्प और तरीके दिए:

क्या पैकेट चुनिंदा रूप से गायब हो जाते हैं? => Iptables नियमों की जाँच करें
क्या MTU बहुत छोटा है ? => आउटपुट चेक करेंip a show
क्या समस्या केवल यूडीपी पैकेट या टीसीपी को प्रभावित करती है? => ड्राइव दूरdig +tcp
क्या खोदे गए पैकेट लौटे हैं? => ड्राइव दूरtcpdump
क्या कामेच्छा सही ढंग से काम करती है? => straceदोनों दिशाओं में पैकेट हस्तांतरण को सत्यापित करने के लिए ड्राइव करें

यहां हम उपयोगकर्ता को लाइव समस्या निवारण के लिए फोन करने का निर्णय लेते हैं।

कॉल के दौरान, हम कई चीजों को सत्यापित करने का प्रबंधन करते हैं:

कई जाँचों के बाद, हम iptables नियमों को कारणों की सूची से बाहर करते हैं।
हम नेटवर्क इंटरफेस और राउटिंग टेबल की जांच करते हैं, और एमटीयू की दोहरी जांच करते हैं
हम पाते हैं कि dig +tcp google.com(TCP) काम कर रहा है जैसा कि उसे करना चाहिए, लेकिन dig google.com(UDP) काम नहीं कर रहा है
tcpdumpकाम करते समय चलने के बाद dig, हम पाते हैं कि यूडीपी के पैकेट वापस किए जा रहे हैं
हम चलाते हैं strace dig google.comऔर देखते हैं कि सही ढंग से कॉल कैसे खुदाई करते हैं sendmsg()और recvms(), हालांकि, टाइमआउट से दूसरा बाधित होता है

दुर्भाग्य से, पारी समाप्त होने वाली है और हम समस्या को अगली बार क्षेत्र में स्थानांतरित करने के लिए मजबूर हैं। हालाँकि, इस अपील से हमारी टीम में दिलचस्पी पैदा हुई, और एक सहयोगी ने पायथन मॉड्यूल के साथ स्रोत DNS पैकेट बनाने का सुझाव दिया।

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

यह टुकड़ा DNS पैकेट बनाता है और मेटाडेटा सर्वर को अनुरोध भेजता है।

उपयोगकर्ता कोड चलाता है, डीएनएस प्रतिक्रिया लौटा दी जाती है, और एप्लिकेशन इसे प्राप्त करता है, जो नेटवर्क स्तर पर समस्या की अनुपस्थिति की पुष्टि करता है।

अगले "राउंड-द-वर्ल्ड ट्रिप" के बाद, अपील हमारी टीम में लौटती है, और मैं पूरी तरह से खुद पर अनुवाद करता हूं, यह विश्वास करते हुए कि यह उपयोगकर्ता के लिए अधिक सुविधाजनक होगा यदि अपील जगह से सर्कल तक समाप्त हो जाती है।

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

सहकर्मी मुझसे थोड़ा ईर्ष्या करने लगे हैं। दोपहर के भोजन पर, हम अपील पर चर्चा करते हैं, लेकिन किसी को भी पता नहीं है कि क्या चल रहा है। सौभाग्य से, उपयोगकर्ता स्वयं पहले ही शमन उपाय कर चुका है और जल्दी में नहीं है, इसलिए हमारे पास समस्या तैयार करने का समय है। और चूंकि हमारे पास एक छवि है, इसलिए हम कोई भी परीक्षण कर सकते हैं जो हमारी रुचि है। ठीक!

एक कदम पीछे जा रहे हैं

एक सिस्टम इंजीनियर के लिए एक साक्षात्कार में सबसे लोकप्रिय प्रश्नों में से एक है: "क्या होता है जब आप www.google.com ?" प्रश्न पॉश है, क्योंकि उम्मीदवार को शेल से उपयोगकर्ता स्थान तक, सिस्टम के कोर और आगे नेटवर्क में वर्णित किया जाना चाहिए। मैं मुस्कुराता हूं: कभी-कभी साक्षात्कार के प्रश्न वास्तविक जीवन में भी उपयोगी होते हैं ...

मैं इस ईशर प्रश्न को वर्तमान समस्या पर लागू करने का निर्णय लेता हूं। मोटे तौर पर, जब आप DNS नाम को निर्धारित करने की कोशिश करते हैं, तो निम्न होता है:

एप्लिकेशन सिस्टम लाइब्रेरी को कॉल करता है, उदाहरण के लिए libdns
libdns सिस्टम कॉन्फ़िगरेशन की जाँच करता है कि DNS सर्वर को किसका उपयोग करना चाहिए (चित्र में यह 169.254.169.254, मेटाडेटा सर्वर है)
libdns एक यूडीपी सॉकेट (SOKET_DGRAM) बनाने के लिए सिस्टम कॉल का उपयोग करता है और दोनों दिशाओं में DNS अनुरोध के साथ UDP पैकेट भेजता है
Sysctl इंटरफ़ेस का उपयोग करके, आप कर्नेल-स्तरीय UDP स्टैक को कॉन्फ़िगर कर सकते हैं
कर्नेल एक नेटवर्क इंटरफेस के माध्यम से नेटवर्क पर पैकेट प्रसारित करने के लिए हार्डवेयर के साथ इंटरैक्ट करता है
हाइपरवाइजर पैकेट और मेटाडेटा सर्वर से गुजरता है जब वह इसके संपर्क में आता है
मेटाडेटा सर्वर अपने जादू टोना द्वारा DNS नाम निर्धारित करता है और उसी तरह से उत्तर देता है

मुझे याद दिलाएं कि हम पहले से ही किन परिकल्पनाओं पर विचार करने में कामयाब रहे हैं:

परिकल्पना: टूटी हुई लाइब्रेरी

टेस्ट 1: सिस्टम में स्ट्रेस चलाएं, जांच लें कि खुदाई सही सिस्टम कॉल का कारण बनती है
परिणाम: सही सिस्टम कॉल कहा जाता है
परीक्षण 2: यह जाँचने के लिए कि क्या हम सिस्टम पुस्तकालयों को दरकिनार करके नाम निर्धारित कर सकते हैं
परिणाम: हम कर सकते हैं
टेस्ट 3: libdns पैकेज और md5sum लाइब्रेरी फ़ाइलों पर rpm –V चलाएँ
परिणाम: लाइब्रेरी कोड पूरी तरह से काम कर रहे ऑपरेटिंग सिस्टम में कोड के समान है
परीक्षण 4: इस व्यवहार के बिना वीएम पर उपयोगकर्ता के रूट सिस्टम की छवि को माउंट करें, चुरोट चलाएं, देखें कि क्या डीएनएस काम करता है
परिणाम: DNS सही तरीके से काम कर रहा है

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

परिकल्पना: DNS सेटिंग्स में एक त्रुटि है

परीक्षण 1: tcpdump की जाँच करें और देखें कि DNS पैकेट भेजे जाते हैं और खुदाई के बाद सही तरीके से वापस आते हैं या नहीं
परिणाम: पैकेट सही तरीके से प्रसारित किए जाते हैं
टेस्ट 2: सर्वर पर पुनः जाँच करें /etc/nsswitch.confऔर/etc/resolv.conf
परिणाम: सब कुछ सही है

परीक्षण-आधारित निष्कर्ष: समस्या डीएनएस विन्यास में नहीं है

परिकल्पना: कर्नेल क्षतिग्रस्त

परीक्षण: एक नया कर्नेल स्थापित करें, हस्ताक्षर सत्यापित करें, पुनरारंभ करें
परिणाम: समान व्यवहार

परीक्षणों के आधार पर निष्कर्ष: कर्नेल क्षतिग्रस्त नहीं है

परिकल्पना: उपयोगकर्ता नेटवर्क का गलत व्यवहार (या हाइपरविजर का नेटवर्क इंटरफ़ेस)

परीक्षण 1: फ़ायरवॉल सेटिंग्स की जाँच करें
परिणाम: फ़ायरवॉल होस्ट और GCP दोनों पर DNS पैकेट को पास करता है
परीक्षण 2: ट्रैफ़िक को रोकें और DNS प्रश्नों के हस्तांतरण और वापसी की शुद्धता को ट्रैक करें
परिणाम: tcpdump मेजबान द्वारा रिटर्न पैकेट की रसीद स्वीकार करता है

परीक्षण-आधारित निष्कर्ष: समस्या नेटवर्क में नहीं है

परिकल्पना: मेटाडेटा सर्वर काम नहीं करता है

परीक्षण 1: विसंगतियों के लिए मेटाडेटा सर्वर लॉग की जाँच करें
परिणाम: लॉग में कोई विसंगतियाँ नहीं हैं
टेस्ट 2: मेटाडेटा सर्वर को बायपास करें dig @8.8.8.8
परिणाम: मेटाडेटा सर्वर का उपयोग किए बिना भी अनुमति का उल्लंघन किया जाता है

परीक्षण-आधारित निष्कर्ष: समस्या मेटाडेटा सर्वर में नहीं है

नीचे पंक्ति: हमने रनटाइम सेटिंग्स को छोड़कर सभी उपप्रणालियों का परीक्षण किया !

कर्नेल रनटाइम सेटिंग्स में डाइविंग

कर्नेल रनटाइम को कॉन्फ़िगर करने के लिए, आप कमांड लाइन विकल्प (ग्रब) या sysctl इंटरफ़ेस का उपयोग कर सकते हैं। मैंने देखा /etc/sysctl.confऔर केवल सोचने के लिए, मुझे कुछ कस्टम सेटिंग्स मिलीं। यह महसूस करते हुए कि मैंने किसी चीज को पकड़ लिया है, मैंने सभी गैर-नेटवर्क या गैर-टीसीपी सेटिंग्स को खारिज कर दिया, जो कि पहाड़ी सेटिंग्स से शेष हैं net.core। फिर मैंने उस जगह का रुख किया, जहां वीएम के पास मेजबान अनुमति है और एक के बाद एक, एक टूटी हुई वीएम के साथ एक और सेटिंग्स के बाद एक आवेदन करना शुरू किया, जब तक कि मैं अपराधी तक नहीं पहुंच गया:

net.core.rmem_default = 2147483647

यहाँ यह है, एक डीएनएस-ब्रेकिंग कॉन्फ़िगरेशन! मुझे अपराध का एक साधन मिला। लेकिन ऐसा क्यों हो रहा है? मुझे अभी भी एक मकसद की जरूरत थी।

DNS पैकेट बफ़र का आधार आकार सेट करना होता है net.core.rmem_default। एक विशिष्ट मान 200KiB के भीतर कहीं भिन्न होता है, हालांकि यदि आपका सर्वर बहुत सारे DNS पैकेट प्राप्त करता है, तो आप बफर का आकार बढ़ा सकते हैं। यदि पल में एक नया पैकेज आता है, उदाहरण के लिए, बफ़र भरा हुआ है, क्योंकि अनुप्रयोग इसे पर्याप्त तेजी से संसाधित नहीं करता है, तो आप पैकेट खोना शुरू कर देंगे। हमारे ग्राहक ने सही तरीके से बफर आकार में वृद्धि की क्योंकि वह डेटा हानि से डरता था, क्योंकि उसने डीएनएस पैकेट के माध्यम से मैट्रिक्स इकट्ठा करने के लिए एप्लिकेशन का उपयोग किया था। वह मान जो उसने सेट किया था वह अधिकतम संभव था: 2 ³¹ -1 (यदि आप 2 ³¹ सेट करते हैं, तो कर्नेल "INVALID ARGUMENT" लौटाएगा)।

अचानक, मुझे एहसास हुआ कि नैम्प और स्केपी ने सही तरीके से काम क्यों किया: उन्होंने कच्चे सॉकेट का इस्तेमाल किया! कच्चे सॉकेट्स नियमित सॉकेट्स से अलग होते हैं: वे iptables को दरकिनार कर काम करते हैं, और वे बफर नहीं होते हैं!

लेकिन "बहुत बड़ा बफर" समस्याओं का कारण क्यों है? यह स्पष्ट रूप से इरादा के अनुसार काम नहीं करता है।

इस बिंदु पर, मैं कई कोर और कई वितरण पर समस्या को पुन: उत्पन्न कर सकता हूं। समस्या पहले ही 3.x कर्नेल में प्रकट हो चुकी है और अब स्वयं भी 5.x कर्नेल में प्रकट हुई है।

दरअसल, स्टार्टअप पर

sysctl -w net.core.rmem_default=$((2**31-1))

डीएनएस ने काम करना बंद कर दिया है।

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

मैंने ड्रॉपवॉच स्थापित किया , एक उपकरण जो मुझे पहले इस्तेमाल करना चाहिए था: यह दिखाता है कि वास्तव में पैकेज कर्नेल में कहां मिलता है। समारोह दोषी था udp_queue_rcv_skb। मैंने कर्नेल स्रोतों को डाउनलोड किया और पैकेज को विशेष रूप से ट्रैक करने के लिए कई फ़ंक्शन जोड़े printk। मुझे जल्दी ही सही स्थिति का पता चलाif, और कुछ समय के लिए बस उसे देखा, क्योंकि यह तब था कि सब कुछ आखिरकार एक पूरी तस्वीर में एक साथ आया: 2 ³¹ -1, एक व्यर्थ संख्या, एक निष्क्रिय डोमेन ... यह कोड का एक टुकड़ा था __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

ध्यान दें:

rmem int है
size प्रकार u16 (अहस्ताक्षरित सोलह बिट int) का है और पैकेट का आकार संग्रहीत करता है
sk->sk_rcybuf प्रकार का है और बफर के आकार को संग्रहीत करता है, जो कि परिभाषा में मूल्य के बराबर है net.core.rmem_default

जब sk_rcvbuf2 के करीब पहुंच ³¹ , पैकेट आकार संक्षेप को जन्म दे सकता पूर्णांक अतिप्रवाह । और चूंकि यह एक इंट है, इसलिए इसका मूल्य नकारात्मक हो जाता है, इसलिए यह स्थिति सच हो जाती है जब इसे गलत होना चाहिए (इसके बारे में अधिक संदर्भ द्वारा पाया जा सकता है )।

त्रुटि को एक तुच्छ तरीके से ठीक किया जाता है: कास्टिंग द्वारा unsigned int। मैंने पैच लागू किया और सिस्टम को पुनरारंभ किया, जिसके बाद DNS ने फिर से काम करना शुरू कर दिया।

जीत का स्वाद

मैंने अपने निष्कर्ष क्लाइंट को भेजे और एलकेएमएल कर्नेल पैच भेजा । मैं संतुष्ट हूं: पहेली का हर एक टुकड़ा एक पूरे में एक साथ आया, मैं ठीक से समझा सकता हूं कि हमने जो मनाया, उसका अवलोकन क्यों किया और सबसे महत्वपूर्ण बात, हम एक साथ काम करने के माध्यम से समस्या का समाधान खोजने में सक्षम थे!

यह पहचानने योग्य है कि मामला दुर्लभ हो गया है, और सौभाग्य से, इस तरह के जटिल कॉल हमें से उपयोगकर्ताओं से शायद ही कभी प्राप्त होते हैं।

Google क्लाउड से DNS क्लाउड सपोर्ट स्टोरी गुम

विचाराधीन मुद्दा

हमारा पहला कदम

एक कदम पीछे जा रहे हैं

कर्नेल रनटाइम सेटिंग्स में डाइविंग

जीत का स्वाद

More articles: