6 पाठ gitlab.com में एक बड़ी समस्या का हल खोजने से सीखे। भाग 1

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



→ दूसरा भाग ।

समस्या

हमने क्लाइंट्स से संदेश प्राप्त करना शुरू कर दिया है कि, जब gitlab.com के साथ काम करते हैं, तो वे समय-समय पर त्रुटियों को मुठभेड़ अनुरोधों को निष्पादित करते समय सामना करते हैं। आमतौर पर CI कार्य करते समय या अन्य समान स्वचालित प्रणालियों के संचालन के दौरान त्रुटियां हुईं। त्रुटि संदेश कुछ इस तरह दिखे:

ssh_exchange_identification: connection closed by remote host fatal: Could not read from remote repository 

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

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

पहला सुराग

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

संकुल का विश्लेषण, हालांकि, विशेष रूप से मजेदार नहीं था। लगभग 6.5 घंटों में प्रतिबंध के बावजूद, लगभग 500 एमबी पैकेट एकत्र किए गए थे। हमें अल्पकालिक यौगिक मिले। टीसीपी कनेक्शन स्थापित किया गया था, क्लाइंट ने पहचानकर्ता को भेजा था, जिसके बाद हमारे एचएपीआरसीवाई सर्वर ने तुरंत सही टीसीपी फाइनल अनुक्रम का उपयोग करके डिस्कनेक्ट कर दिया। परिणामस्वरूप, हमारे पास पहले उत्कृष्ट सुराग था। उसने हमें यह निष्कर्ष निकालने की अनुमति दी कि कनेक्शन निश्चित रूप से gitlab.com की पहल पर बंद किया गया था, न कि हमारे और ग्राहक के बीच कुछ के कारण। इसका मतलब यह था कि हम एक ऐसी समस्या से जूझ रहे थे जिसकी हम जांच कर सकते हैं और सही कर सकते हैं।

पाठ संख्या १। विंडसर टूल के सांख्यिकी मेनू में एक टन उपयोगी उपकरण हैं, जिन्हें मैंने इस मामले से पहले ध्यान नहीं दिया है।

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

लॉग विसर्जन

क्लाइंट से डिस्कनेक्ट करने के लिए HAProxy का क्या कारण है? बेशक, सर्वर ने ऐसा अनियंत्रित तरीके से नहीं किया; जो हो रहा था, उसके कुछ गहरे कारण होने चाहिए थे; अगर आपको पसंद है - " कछुओं का एक और स्तर।" एक भावना थी कि अध्ययन का अगला उद्देश्य HAProxy लॉग होना चाहिए। हमारे लॉग GCP BigQuery में संग्रहीत किए गए थे। यह सुविधाजनक है, क्योंकि हमारे पास बहुत सारे लॉग हैं, और हमें उनका व्यापक विश्लेषण करने की आवश्यकता है। लेकिन पहले, हम उन घटनाओं में से एक के लिए लॉग प्रविष्टि की पहचान करने में सक्षम थे, जो कैप्चर किए गए पैकेटों में पाया गया था। हम समय पर और टीसीपी पोर्ट पर निर्भर थे, जो हमारे अध्ययन में एक बड़ी उपलब्धि थी। पाया रिकॉर्ड में सबसे दिलचस्प विस्तार t_state (समाप्ति राज्य) विशेषता थी, जिसका मूल्य SD । यहाँ HAProxy प्रलेखन से एक उद्धरण है:

     S:  ,     .    D:     DATA. 

D के अर्थ का अर्थ बहुत सरलता से बताया गया है। टीसीपी कनेक्शन सही ढंग से स्थापित किया गया था, डेटा भेजा गया था। यह पकड़े गए पैकेट से प्राप्त सबूतों से मेल खाता है। S एक मूल्य का मतलब है कि HAProxy को RST, या ICMP विफलता संदेश बैकएंड से मिला। लेकिन हम तुरंत कोई सुराग नहीं लगा सके कि ऐसा क्यों हो रहा था। इसका कारण कुछ भी हो सकता है - एक अस्थिर नेटवर्क से (उदाहरण के लिए, एक अनुप्रयोग स्तर की समस्या के लिए विफलता या भीड़)। Git बैकएंड पर डेटा एकत्र करने के लिए BigQuery का उपयोग करते हुए, हमने पाया कि समस्या किसी विशेष वर्चुअल मशीन से बंधी नहीं है। हमें और जानकारी चाहिए।

मैं यह नोट करना चाहता हूं कि SD मूल्य के साथ लॉग प्रविष्टियां कुछ विशेष नहीं थीं, केवल हमारी समस्या के लिए विशेषता। वैकल्पिक- ssh पोर्ट पर, हमें HTTPS के लिए स्कैनिंग के बारे में कई अनुरोध प्राप्त हुए। यह इस तथ्य के कारण है कि एसएसएच सर्वर TLS ClientHello संदेश को देखने के दौरान SD मूल्य लॉग में गिर गया जबकि एसएसएच ग्रीटिंग प्राप्त करने की उम्मीद है। इसने हमारी जांच को गोलमोल तरीके से आगे बढ़ाया।

HAProxy और Git सर्वर के बीच कुछ ट्रैफ़िक को कैप्चर करने और फिर से Wireshark टूल का उपयोग करने के बाद, हमें तुरंत पता चला कि GIT सर्वर पर SSHD TCP फिन-ACK से तुरंत टीसीपी के तीन-तरफ़ा हैंडशेक के बाद डिस्कनेक्ट करता है। HAProxy ने अभी भी पहला डेटा पैकेट नहीं भेजा था, लेकिन ऐसा करने वाला था। जब उसने पैकेट भेजा, तो Git सर्वर ने उसे TCP RST के साथ उत्तर दिया। परिणामस्वरूप - अब हमने उस कारण को खोज लिया है, जिसके कारण HAProxy ने SD मान के साथ कनेक्शन विफलता के बारे में लॉग को लिखा था। एसएसएच ने कनेक्शन को बंद कर दिया, यह जानबूझकर और सही ढंग से कर रहा था, और आरएसटी केवल इस तथ्य की एक कलाकृति थी कि एसएसएच सर्वर ने फिन-एसीके के बाद पैकेट प्राप्त किया। इसका मतलब और कुछ नहीं था।

वाक्पटु कार्यक्रम

BigQuery में SD मूल्यों के साथ लॉग को देखने और विश्लेषण करने पर, हमने महसूस किया कि त्रुटियों का समय के साथ स्पष्ट संबंध है। अर्थात्, हमें हर मिनट के पहले 10 सेकंड के भीतर विफल कनेक्शन की संख्या में चोटियां मिलीं। उन्हें 5-6 सेकंड के लिए मनाया गया।


मिनट से सेकंड के भीतर कनेक्शन की त्रुटियां समूहीकृत होती हैं

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

क्रोन या इसी तरह के शेड्यूलिंग सिस्टम अक्सर निकटतम सेकंड में कार्यों के निष्पादन को अनुकूलित करने की क्षमता में भिन्न नहीं होते हैं। यदि ऐसी प्रणालियों में ऐसी क्षमताएं हैं, तो वे इस तथ्य के कारण बहुत बार उपयोग नहीं की जाती हैं कि लोग समय पर विचार करना पसंद करते हैं, अंतराल में विभाजित, सुंदर गोल संख्याओं द्वारा व्यक्त किया गया। नतीजतन, कार्य एक मिनट या घंटे की शुरुआत में, या अन्य समान क्षणों पर शुरू होते हैं। अगर gitlab.com से सामग्री डाउनलोड करने के लिए git fetch कमांड को तैयार करने के लिए कार्यों को कुछ सेकंड की आवश्यकता होती है, तो यह उस पैटर्न की व्याख्या कर सकता है जब हमने पाया कि सिस्टम पर लोड हर मिनट में कई सेकंड के लिए तेजी से बढ़ता है। ऐसे क्षणों में, त्रुटियों की संख्या बढ़ जाती है।

पाठ संख्या २। बहुत से लोग, जाहिरा तौर पर, सही ढंग से कॉन्फ़िगर समय सिंक्रनाइज़ेशन (एनटीपी के माध्यम से या अन्य तंत्रों का उपयोग करके) का उपयोग करते हैं।

यदि किसी ने समय को सिंक्रनाइज़ नहीं किया है, तो हमारी समस्या इतनी स्पष्ट रूप से प्रकट नहीं होगी। शुभ दोपहर, एनटीपी!

लेकिन एसएसएच के कारण क्या होता है?

समस्या के मूल के करीब

SSHD दस्तावेज़ीकरण का अध्ययन करते हुए, हमने MaxStartups पैरामीटर की खोज की। यह बिना कनेक्शन के अधिकतम संख्या को नियंत्रित करता है। यह प्रशंसनीय लगता है कि कनेक्शन सीमा तब समाप्त हो जाती है जब मिनट की शुरुआत में सिस्टम को इंटरनेट पर अनुसूचित कार्यों की कॉल की हड़बड़ाहट के कारण लोड के अधीन किया जाता है। MaxStartups पैरामीटर में तीन नंबर होते हैं। पहला निम्न बाउंड है (कनेक्शन तक पहुंचने पर कनेक्शन की संख्या शुरू होती है)। दूसरा यौगिकों का प्रतिशत है जो उन यौगिकों की निचली सीमा से अधिक है जिन्हें यादृच्छिक रूप से तोड़ने की आवश्यकता है। तीसरा मान कनेक्शन की पूर्ण अधिकतम संख्या है, जिसके बाद सभी नए कनेक्शन खारिज कर दिए जाते हैं। मैक्सस्टार्टअप का डिफ़ॉल्ट मान 10: 30: 100 जैसा दिखता है, हमारी सेटिंग तब 100: 30: 200 जैसी दिखती थी। यह इंगित करता है कि अतीत में हमने मानक कनेक्शन सीमाएं बढ़ाई हैं। शायद - यह उन्हें फिर से बढ़ाने का समय है।

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

यह पता चला है कि ओपनएसएसएच 7.6 (यह संस्करण उबंटू 18.04 के साथ आता है) ने MaxStartups से संबंधित लॉगिंग के लिए अधिक सुविधाजनक दृष्टिकोण का आयोजन किया। यहां आपको केवल Verbose लॉगिंग मोड पर स्विच करना होगा। हालांकि आदर्श नहीं है, फिर भी यह Debug स्तर पर स्विच करने से बेहतर है।

पाठ संख्या 3। मानक लॉगिंग स्तरों पर लॉग्स के लिए दिलचस्प जानकारी लिखने के लिए यह अच्छा रूप माना जाता है, और किसी भी कारण से जानबूझकर वियोग के बारे में जानकारी निश्चित रूप से सिस्टम प्रशासक के लिए दिलचस्प है।

अब जब हमने समस्या के कारण का पता लगा लिया है, तो सवाल यह है कि इसे कैसे हल किया जाए। हम MaxStartups पैरामीटर में मूल्यों को बढ़ा सकते हैं, लेकिन इससे हमें क्या मिलेगा? निश्चित रूप से, इसके लिए थोड़ी अतिरिक्त मेमोरी की आवश्यकता होगी, लेकिन क्या इससे सिस्टम के उन हिस्सों में कोई प्रतिकूल परिणाम होगा, जहां अनुरोध संसाधित होते हैं? हम केवल इसके बारे में सोच सकते थे, इसलिए हमने नए MaxStartups सेटिंग्स लेने और बस लेने का फैसला किया। अर्थात्, हमने उन्हें निम्नलिखित के लिए आदान-प्रदान किया: 150: 30: 300। पहले, वे 100: 30: 200 की तरह दिखते थे, अर्थात् - हमने कनेक्शनों की संख्या में 50% की वृद्धि की। इस प्रणाली पर एक मजबूत सकारात्मक प्रभाव पड़ा है। इसी समय, कुछ नकारात्मक प्रभाव, जैसे कि प्रोसेसर पर भार बढ़ाना, मनाया नहीं गया।


MaxStartups को 50% तक बढ़ाने से पहले और बाद में त्रुटियों की संख्या

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

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

जारी रखने के लिए ...

प्रिय पाठकों! ट्रैफ़िक और लॉग का विश्लेषण करने के लिए आप किन उपकरणों का उपयोग करते हैं?