एक नेटवर्क जो खुद को ठीक करता है: फ़्लो लेबल का जादू और लिनक्स कर्नेल के चारों ओर जासूस। यांडेक्स रिपोर्ट

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

- सबसे पहले, मैं उन लोगों के लिए काफी विस्तृत परिचय दूंगा जो आधुनिक डीसी की संरचना के बारे में नहीं जानते होंगे।


कई नेटवर्क इंजीनियरों के लिए, एक डेटा सेंटर नेटवर्क, निश्चित रूप से, टीओआर के साथ, रैक में एक स्विच के साथ शुरू होता है। ToR में आमतौर पर दो तरह के लिंक होते हैं. छोटे सर्वर पर जाते हैं, अन्य - उनमें से एन गुना अधिक होते हैं - पहले स्तर की रीढ़ की ओर जाते हैं, यानी इसके अपलिंक तक। अपलिंक को आमतौर पर समान माना जाता है, और अपलिंक के बीच ट्रैफ़िक को 5-टुपल के हैश के आधार पर संतुलित किया जाता है, जिसमें प्रोटो, src_ip, dst_ip, src_port, dst_port शामिल हैं। यहां कोई आश्चर्य नहीं है.


अगला, योजना वास्तुकला कैसी दिखती है? पहले स्तर की रीढ़ें एक-दूसरे से नहीं जुड़ी होती हैं, बल्कि सुपरस्पाइन्स के माध्यम से जुड़ी होती हैं। अक्षर X सुपरस्पाइन के लिए जिम्मेदार होगा; यह लगभग एक क्रॉस-कनेक्ट की तरह है।


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


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


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


आठ विमान हैं, प्रत्येक विमान में 32 सुपरस्पाइन हैं। नतीजतन, यह पता चलता है कि मॉड्यूल के अंदर आठ पथ हैं, और इंटरमॉड्यूल इंटरैक्शन के साथ उनमें से पहले से ही 256 हैं।

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


हमारी एक सुपरस्पाइन को "बीमार" होने दें। यहां मैं दो-प्लेन वास्तुकला पर लौट आया। हम इन्हें एक उदाहरण के रूप में रखेंगे क्योंकि इससे यह देखना आसान हो जाएगा कि कम गतिमान भागों के साथ क्या हो रहा है। X11 को बीमार होने दो। यह डेटा केंद्रों के अंदर रहने वाली सेवाओं को कैसे प्रभावित करेगा? बहुत कुछ इस पर निर्भर करता है कि विफलता वास्तव में कैसी दिखती है।


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


एक बुरा परिदृश्य तब होता है जब हमें लगातार नुकसान होता है, और स्वचालन समस्या पर ध्यान नहीं देता है। यह समझने के लिए कि यह किसी एप्लिकेशन को कैसे प्रभावित करता है, हमें टीसीपी कैसे काम करती है, इस पर चर्चा करने में थोड़ा समय बिताना होगा।


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


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


यदि हम पैकेट 3 खो दें तो क्या होगा? इस मामले में, प्राप्तकर्ता को पैकेट 1, 2 और 4 प्राप्त होंगे। और वह SACK विकल्प का उपयोग करके प्रेषक को स्पष्ट रूप से बताएगा: "आप जानते हैं, तीन आ गए, लेकिन बीच खो गया था।" वह कहते हैं, "एक 2, सैक 4।"


इस समय, प्रेषक बिना किसी समस्या के ठीक उसी पैकेट को दोहराता है जो खो गया था।


लेकिन अगर विंडो का आखिरी पैकेट खो जाए तो स्थिति बिल्कुल अलग दिखेगी।

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


आरटीओ टाइमआउट क्या है? यह टीसीपी स्टैक और कुछ स्थिरांक द्वारा गणना की गई आरटीटी की अधिकतम सीमा है। यह किस प्रकार का स्थिरांक है, अब हम चर्चा करेंगे।


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


अब देखते हैं कि यह आधार किसके बराबर होता है। डिफ़ॉल्ट रूप से, न्यूनतम आरटीओ 200 एमएस है। यह डेटा पैकेज के लिए न्यूनतम आरटीओ है। SYN पैकेट के लिए यह अलग है, 1 सेकंड। जैसा कि आप देख सकते हैं, पैकेट को दोबारा भेजने का पहला प्रयास भी डेटा सेंटर के अंदर आरटीटी की तुलना में 100 गुना अधिक समय लेगा।


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


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


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

कई सर्विसेज का मानना ​​है कि एनओसी में काम कुछ इस तरह होता है. लेकिन ईमानदारी से कहूं तो सिर्फ इतना ही नहीं.


शास्त्रीय योजना में एनओसी कई निगरानी प्रणालियों के विकास में लगी हुई है। ये दोनों ब्लैक बॉक्स और व्हाइट बॉक्स मॉनिटरिंग हैं। ब्लैक बॉक्स स्पाइन मॉनिटरिंग के एक उदाहरण के बारे में मुझे बताया गया है आखिरी नेक्स्ट हॉप में अलेक्जेंडर क्लिमेंको। वैसे ये मॉनिटरिंग काम करती है. लेकिन आदर्श निगरानी में भी समय का अंतराल होगा। आमतौर पर यह कुछ मिनटों का होता है. इसके बंद होने के बाद, ड्यूटी पर तैनात इंजीनियरों को इसके संचालन की दोबारा जांच करने, समस्या का पता लगाने और फिर समस्या क्षेत्र को खत्म करने के लिए समय की आवश्यकता होती है। यानी, सबसे अच्छे मामले में, समस्या का इलाज करने में 5 मिनट लगते हैं, सबसे खराब मामले में, 20 मिनट, अगर यह तुरंत स्पष्ट नहीं है कि नुकसान कहां होता है। यह स्पष्ट है कि इस पूरे समय - 5 या 20 मिनट - हमारी सेवाएँ प्रभावित होती रहेंगी, जो संभवतः अच्छा नहीं है।


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

लेकिन यहां एक बारीकियां है. यह क्या है, इसे समझने के लिए हमें यह देखना होगा कि धागे कैसे स्थापित होते हैं।


धागे क्रमिक रूप से स्थापित किए जाते हैं। सबसे पहले पहला धागा स्थापित किया जाता है। उसके बाद के थ्रेड्स को उस कुकी का उपयोग करके सेट किया जाता है जिस पर उस थ्रेड के भीतर पहले ही सहमति हो चुकी है। और यहीं समस्या है.


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


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


मैं आपको एक छोटी सी जांच पर मेरे साथ चलने के लिए आमंत्रित करता हूं। आइए एक नज़र डालें कि पिछले कुछ वर्षों में लिनक्स कर्नेल में क्या हो रहा है।

साल 2014. एक बड़ी और प्रतिष्ठित कंपनी का एक इंजीनियर लिनक्स कर्नेल की कार्यक्षमता में सॉकेट हैश पर प्रवाह लेबल मान की निर्भरता जोड़ता है। वे यहाँ क्या ठीक करने का प्रयास कर रहे थे? यह RFC 6438 से संबंधित है, जिसमें निम्नलिखित मुद्दे पर चर्चा की गई है। डेटा सेंटर के अंदर, IPv4 को अक्सर IPv6 पैकेट में एनकैप्सुलेट किया जाता है, क्योंकि फ़ैक्टरी स्वयं IPv6 है, लेकिन IPv4 को किसी तरह बाहर दिया जाना चाहिए। लंबे समय से स्विच के साथ समस्याएँ थीं जो टीसीपी या यूडीपी तक पहुँचने और वहाँ src_ports, dst_ports खोजने के लिए दो आईपी हेडर के नीचे नहीं देख सकते थे। यह पता चला कि हैश, यदि आप पहले दो आईपी हेडर को देखते हैं, तो लगभग तय हो गया है। इससे बचने के लिए, ताकि इस एनकैप्सुलेटेड ट्रैफ़िक का संतुलन सही ढंग से काम कर सके, फ्लो लेबल फ़ील्ड के मूल्य में 5-टुपल एनकैप्सुलेटेड पैकेट के हैश को जोड़ने का प्रस्ताव किया गया था। लगभग यही बात अन्य एनकैप्सुलेशन योजनाओं के लिए भी की गई, यूडीपी के लिए, जीआरई के लिए, बाद वाले ने जीआरई कुंजी फ़ील्ड का उपयोग किया। किसी न किसी रूप में, यहां लक्ष्य स्पष्ट हैं। और कम से कम उस समय वे उपयोगी थे।

2015 में, उसी सम्मानित इंजीनियर का एक नया पैच आता है। वह बहुत दिलचस्प है. यह निम्नलिखित कहता है - नकारात्मक रूटिंग घटना के मामले में हम हैश को यादृच्छिक बना देंगे। नकारात्मक रूटिंग घटना क्या है? यह वह आरटीओ है जिसके बारे में हमने पहले चर्चा की थी, यानी विंडो की टेल का खो जाना एक ऐसी घटना है जो वास्तव में नकारात्मक है। सच है, यह अनुमान लगाना अपेक्षाकृत कठिन है कि यही है।

2016, एक और प्रतिष्ठित कंपनी, बड़ी भी। यह अंतिम बैसाखी को अलग करता है और ऐसा बनाता है कि हैश, जिसे हमने पहले यादृच्छिक बनाया था, अब प्रत्येक SYN रिट्रांसमिशन के लिए और प्रत्येक RTO टाइमआउट के बाद बदल जाता है। और इस पत्र में, पहली और आखिरी बार, अंतिम लक्ष्य बताया गया है - यह सुनिश्चित करना कि नुकसान या चैनल की भीड़ की स्थिति में ट्रैफ़िक को धीरे-धीरे फिर से रूट करने और कई पथों का उपयोग करने की क्षमता हो। बेशक, इसके बाद बहुत सारे प्रकाशन हुए, आप उन्हें आसानी से पा सकते हैं।

हालाँकि नहीं, आप नहीं कर सकते, क्योंकि इस विषय पर एक भी प्रकाशन नहीं हुआ है। लेकिन हम जानते हैं!

और यदि आप पूरी तरह से नहीं समझ पाए कि क्या किया गया था, तो मैं आपको अभी बताता हूँ।


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

यहाँ क्या महत्वपूर्ण है? प्रत्येक आरटीओ के बाद प्रवाह लेबल फ़ील्ड का मान एक यादृच्छिक संख्या में बदल जाता है। यह हमारी दुर्भाग्यपूर्ण टीसीपी स्ट्रीम को कैसे प्रभावित करता है?


यदि कोई SACK होता है, तो कुछ भी नहीं बदलता क्योंकि हम एक ज्ञात खोए हुए पैकेट को फिर से भेजने का प्रयास कर रहे हैं। अब तक तो सब ठीक है।


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


एक समस्या बाकी है - आरटीओ। बेशक, दूसरा रास्ता भी है, लेकिन इस पर काफी समय बर्बाद होता है। 200 एमएस बहुत है. एक सेकंड बिल्कुल जंगली है. पहले, मैंने टाइमआउट के बारे में बात की थी कि सेवाएँ कॉन्फ़िगर की गई हैं। तो, एक सेकंड एक टाइमआउट है, जिसे आमतौर पर एप्लिकेशन स्तर पर सेवा द्वारा कॉन्फ़िगर किया जाता है, और इसमें सेवा अपेक्षाकृत सही भी होगी। इसके अलावा, मैं दोहराता हूं, आधुनिक डेटा सेंटर के अंदर वास्तविक आरटीटी लगभग 1 मिलीसेकंड है।


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


सच है, SYN_RTO के साथ सब कुछ कुछ हद तक खराब है। यह स्वाभाविक रूप से कीलों से जड़ा हुआ है। कर्नेल का एक निश्चित मान 1 सेकंड है, और बस इतना ही। आप उपयोगकर्ता स्थान से वहां तक ​​नहीं पहुंच सकते. केवल एक ही रास्ता है.


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


लेकिन हमारे लिए यह महत्वपूर्ण है कि इसका उपयोग SYN_RTO मानों को बदलने के लिए किया जा सकता है। इसके अलावा, सार्वजनिक रूप से पोस्ट किया गया एक उदाहरण है: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. यहाँ क्या किया गया है? उदाहरण काम कर रहा है, लेकिन अपने आप में बहुत कठिन है। यहां यह माना जाता है कि डेटा सेंटर के अंदर हम पहले 44 बिट्स की तुलना करते हैं; यदि वे मेल खाते हैं, तो हम डेटा सेंटर के अंदर हैं। और इस मामले में हम SYN_RTO टाइमआउट मान को 4ms में बदलते हैं। वही कार्य अधिक सुन्दर ढंग से किया जा सकता है। लेकिन यह सरल उदाहरण दिखाता है कि यह a) संभव है; बी) अपेक्षाकृत सरल।

हम पहले से क्या जानते हैं? तथ्य यह है कि समतल वास्तुकला स्केलिंग की अनुमति देती है, यह हमारे लिए बेहद उपयोगी साबित होती है जब हम टीओआर पर प्रवाह लेबल को सक्षम करते हैं और समस्या क्षेत्रों के आसपास प्रवाह करने की क्षमता प्राप्त करते हैं। RTO और SYN-RTO मानों को कम करने का सबसे अच्छा तरीका eBPF प्रोग्राम का उपयोग करना है। प्रश्न बना हुआ है: क्या संतुलन के लिए फ्लो लेबल का उपयोग करना सुरक्षित है? और यहां एक बारीकियां है.


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


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

किसी भी तरह, मुझे ऐसा लगता है कि हम प्रयोगों की ओर बढ़ने के लिए तैयार हैं।


जब हमने टीओआर पर प्रवाह लेबल को सक्षम किया, ईबीपीएफ एजेंट तैयार किया, जो अब मेजबानों पर रहता है, तो हमने अगली बड़ी विफलता की प्रतीक्षा नहीं करने, बल्कि नियंत्रित विस्फोट करने का फैसला किया। हमने टीओआर लिया, जिसमें चार अपलिंक हैं, और उनमें से एक पर ड्रॉप सेट अप किया। उन्होंने एक नियम बनाया और कहा- अब आप सभी पैकेट खो रहे हैं। जैसा कि आप बाईं ओर देख सकते हैं, हमारे पास प्रति-पैकेट निगरानी है, जो गिरकर 75% हो गई है, यानी 25% पैकेट खो गए हैं। दाईं ओर इस टीओआर के पीछे रहने वाली सेवाओं के ग्राफ़ हैं। अनिवार्य रूप से, ये रैक के अंदर सर्वर के साथ इंटरफेस के ट्रैफ़िक ग्राफ़ हैं। जैसा कि आप देख सकते हैं, वे और भी नीचे डूब गये। वे नीचे क्यों गिरे - 25% तक नहीं, बल्कि कुछ मामलों में 3-4 गुना तक? यदि टीसीपी कनेक्शन अशुभ है, तो यह टूटे हुए जंक्शन तक पहुंचने का प्रयास करता रहता है। यह डीसी के अंदर सेवा के विशिष्ट व्यवहार से बढ़ गया है - एक उपयोगकर्ता अनुरोध के लिए, आंतरिक सेवाओं के लिए एन अनुरोध उत्पन्न होते हैं, और प्रतिक्रिया उपयोगकर्ता के पास तब जाएगी जब सभी डेटा स्रोत प्रतिक्रिया देंगे, या जब एप्लिकेशन पर टाइमआउट होता है स्तर, जिसे अभी भी कॉन्फ़िगर करने की आवश्यकता है। यानी सबकुछ बहुत-बहुत बुरा है.


अब वही प्रयोग, लेकिन प्रवाह लेबल मान सक्षम होने के साथ। जैसा कि आप देख सकते हैं, बाईं ओर हमारे बैच की निगरानी में समान 25% की गिरावट आई है। यह बिल्कुल सही है, क्योंकि यह पुनः प्रेषण के बारे में कुछ भी नहीं जानता है, यह पैकेट भेजता है और केवल वितरित और खोए हुए पैकेटों की संख्या के अनुपात की गणना करता है।

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

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

नेटवर्क इंजीनियरों को एक वैचारिक बदलाव से गुजरना होगा: नेटवर्क की शुरुआत टीओआर से नहीं, नेटवर्क डिवाइस से नहीं, बल्कि होस्ट से होती है। एक उल्लेखनीय उदाहरण यह है कि हम आरटीओ को बदलने और एनीकास्ट सेवाओं की ओर प्रवाह लेबल को ठीक करने के लिए ईबीपीएफ का उपयोग कैसे करते हैं।

प्रवाह लेबल यांत्रिकी निश्चित रूप से नियंत्रित प्रशासनिक खंड के भीतर अन्य अनुप्रयोगों के लिए उपयुक्त है। यह डेटा केंद्रों के बीच ट्रैफ़िक हो सकता है, या आप आउटगोइंग ट्रैफ़िक को प्रबंधित करने के लिए ऐसे मैकेनिकों का विशेष तरीके से उपयोग कर सकते हैं। लेकिन मुझे उम्मीद है कि मैं आपको इसके बारे में अगली बार बताऊंगा। आपके ध्यान के लिए बहुत - बहुत धन्यवाद।

स्रोत: www.habr.com