एउटा नेटवर्क जसले आफैलाई निको पार्छ: फ्लो लेबलको जादू र लिनक्स कर्नेल वरिपरि जासूस। Yandex रिपोर्ट

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

- सुरुमा, म आधुनिक DC को संरचना बारे सचेत नहुन सक्नेहरूका लागि एकदम विस्तृत परिचय दिनेछु।


धेरै नेटवर्क इन्जिनियरहरूको लागि, डाटा सेन्टर नेटवर्क सुरु हुन्छ, अवश्य पनि, ToR को साथ, र्याकमा स्विचको साथ। ToR मा सामान्यतया दुई प्रकारका लिङ्कहरू हुन्छन्। सानाहरू सर्भरहरूमा जान्छन्, अरूहरू - त्यहाँ N गुणा बढी छन् - पहिलो स्तरको स्पाइनहरू तिर जानुहोस्, अर्थात्, यसको अपलिङ्कहरूमा। अपलिङ्कहरू सामान्यतया बराबर मानिन्छ, र अपलिङ्कहरू बीचको ट्राफिक 5-टुपलको ह्यासको आधारमा सन्तुलित हुन्छ, जसमा प्रोटो, src_ip, dst_ip, src_port, dst_port समावेश हुन्छ। यहाँ कुनै आश्चर्य छैन।


अर्को, योजना वास्तुकला कस्तो देखिन्छ? पहिलो स्तरका स्पाइनहरू एकअर्कासँग जोडिएका छैनन्, तर सुपरस्पाइनहरू मार्फत जोडिएका छन्। अक्षर X सुपरस्पाइन्सको लागि जिम्मेवार हुनेछ; यो लगभग क्रस-जडान जस्तै छ।


र यो स्पष्ट छ कि, अर्कोतर्फ, टोरी पहिलो स्तर को सबै स्पाइन संग जोडिएको छ। यो चित्रमा के महत्त्वपूर्ण छ? यदि हामीसँग र्याक भित्र अन्तरक्रिया छ भने, अन्तरक्रिया, अवश्य पनि, ToR मार्फत जान्छ। यदि अन्तरक्रिया मोड्युल भित्र हुन्छ भने, त्यसपछि अन्तरक्रिया पहिलो स्तर स्पाइन मार्फत हुन्छ। यदि अन्तरक्रिया इन्टरमोड्युलर हो - यहाँ जस्तै, ToR 1 र ToR 2 - त्यसपछि अन्तरक्रिया पहिलो र दोस्रो स्तरको स्पाइनहरू मार्फत जान्छ।


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


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


त्यहाँ आठ विमानहरू छन्, प्रत्येक विमानमा 32 सुपरस्पाइनहरू छन्। नतिजाको रूपमा, यो बाहिर जान्छ कि त्यहाँ मोड्युल भित्र आठ मार्गहरू छन्, र इन्टरमोड्युल अन्तरक्रियाको साथ त्यहाँ पहिले नै ती मध्ये 256 छन्।

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


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


यदि असफलता राम्रो छ भने, यो उही BFD को स्वचालन स्तरमा समातिएको छ, स्वचालनले खुशीसाथ समस्याग्रस्त जोडहरू राख्छ र समस्यालाई अलग गर्दछ, त्यसपछि सबै ठीक छ। हामीसँग धेरै मार्गहरू छन्, ट्राफिक तुरुन्तै वैकल्पिक मार्गहरूमा पुन: रुट हुन्छ, र सेवाहरूले केही पनि ध्यान दिँदैनन्। यो राम्रो स्क्रिप्ट हो।


एउटा खराब परिदृश्य हो यदि हामीसँग निरन्तर घाटा छ, र स्वचालनले समस्यालाई ध्यान दिँदैन। यसले एप्लिकेसनलाई कसरी असर गर्छ भनेर बुझ्नको लागि, हामीले TCP कसरी काम गर्छ भनेर छलफल गर्न थोरै समय खर्च गर्नुपर्नेछ।


मलाई आशा छ कि म यस जानकारीको साथ कसैलाई स्तब्ध पार्ने छैन: TCP एक प्रसारण पुष्टिकरण प्रोटोकल हो। त्यो हो, सरल अवस्थामा, प्रेषकले दुई प्याकेटहरू पठाउँछ र तिनीहरूमा एक संचयी ack प्राप्त गर्दछ: "मैले दुई प्याकेटहरू प्राप्त गरें।"


त्यस पछि, उसले थप दुई प्याकेटहरू पठाउनेछ, र स्थिति दोहोर्याउनेछ। केही सरलीकरणको लागि म अग्रिम माफी चाहन्छु। यो परिदृश्य सही छ यदि विन्डो (उडानमा प्याकेटहरूको संख्या) दुई छ। निस्सन्देह, सामान्य अवस्थामा यो जरूरी मामला छैन। तर विन्डो साइजले प्याकेट फर्वार्डिङ सन्दर्भलाई असर गर्दैन।


हामीले प्याकेट ३ हराएमा के हुन्छ? यस अवस्थामा, प्राप्तकर्ताले 3, 1 र 2 प्याकेटहरू प्राप्त गर्नेछन्। र उसले SACK विकल्प प्रयोग गरेर प्रेषकलाई स्पष्ट रूपमा भन्नेछ: "तिमीलाई थाहा छ, तीन आइपुगे, तर बीचको हरायो।" उनी भन्छन्, "Ack 4, SACK 2।"


यस क्षणमा, प्रेषकले कुनै समस्या बिना नै हराएको प्याकेट दोहोर्याउँछ।


तर यदि सञ्झ्यालमा अन्तिम प्याकेट हराएको छ भने, स्थिति पूर्णतया फरक देखिनेछ।

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


RTO टाइमआउट के हो? यो TCP स्ट्याक र केहि स्थिर द्वारा गणना गरिएको RTT को अधिकतम हो। यो कस्तो प्रकारको स्थिरता हो, हामी अब छलफल गर्नेछौं।


तर महत्त्वपूर्ण कुरा यो हो कि यदि हामी फेरि अशुभ हुन्छौं र चौथो प्याकेट फेरि हरायो भने, RTO दोब्बर हुन्छ। त्यो हो, प्रत्येक असफल प्रयास भनेको टाइमआउट दोब्बर हुनु हो।


अब यो आधार के बराबर छ हेरौं। पूर्वनिर्धारित रूपमा, न्यूनतम RTO 200 ms हो। यो डाटा प्याकेजहरूको लागि न्यूनतम RTO हो। SYN प्याकेटहरूको लागि यो फरक छ, 1 सेकेन्ड। तपाईंले देख्न सक्नुहुने रूपमा, प्याकेटहरू पुन: पठाउने पहिलो प्रयासले पनि डाटा केन्द्र भित्रको RTT भन्दा १०० गुणा बढी समय लिनेछ।


अब हाम्रो परिदृश्यमा फर्कौं। सेवामा के भइरहेको छ ? सेवाले प्याकेटहरू हराउन थाल्छ। सेवालाई सुरुमा सशर्त रूपमा भाग्यशाली हुन दिनुहोस् र सञ्झ्यालको बीचमा केही हराउनुहोस्, त्यसपछि यसले SACK प्राप्त गर्छ र हराएको प्याकेटहरू पुन: पठाउँछ।


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


त्यहाँ दुई क्लासिक समाधानहरू छन् जुन एकअर्काको पूरक हुन्। पहिलो सेवाहरू हो जसले स्ट्राहरू राख्ने प्रयास गरिरहेका छन् र यस प्रकारको समस्या समाधान गर्न खोजिरहेका छन्: “टीसीपी स्ट्याकमा केही ट्वीक गरौं। आन्तरिक स्वास्थ्य जाँचको साथ आवेदन स्तर वा लामो समयसम्म चल्ने TCP सत्रहरूमा टाइमआउटहरू बनाउनुहोस्।" समस्या यो हो कि त्यस्ता समाधानहरू: क) मापन नगर्नुहोस्; ख) धेरै खराब जाँच गरिएको छ। त्यो हो, यदि सेवाले गल्तिले TCP स्ट्याकलाई राम्रो बनाउने तरिकामा कन्फिगर गरे पनि, पहिले, यो सबै अनुप्रयोगहरू र सबै डेटा केन्द्रहरूमा लागू हुने सम्भावना छैन, र दोस्रो, सम्भवतः, यसले बुझ्दैन कि यो भयो। सही, र के छैन। त्यो हो, यसले काम गर्दछ, तर यसले खराब काम गर्दछ र मापन गर्दैन। र यदि नेटवर्क समस्या छ भने, को दोष? निस्सन्देह, NOC। NOC ले के गर्छ?

धेरै सेवाहरूले एनओसीमा यस्तो काम हुने विश्वास गर्छन्। तर इमानदार हुन, त्यति मात्र होइन।


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


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

तर यहाँ एक nuance छ। यो के हो बुझ्नको लागि, हामीले थ्रेडहरू कसरी स्थापित हुन्छन् भनेर हेर्नु पर्छ।


थ्रेडहरू क्रमिक रूपमा स्थापित छन्। पहिलो थ्रेड पहिले स्थापित छ। त्यसपछिका थ्रेडहरू त्यस थ्रेड भित्र पहिले नै सहमति भइसकेको कुकी प्रयोग गरेर सेट गरिन्छन्। र यहाँ समस्या छ।


समस्या यो हो कि यदि पहिलो थ्रेडले आफैलाई स्थापित गर्दैन भने, दोस्रो र तेस्रो थ्रेड कहिल्यै उठ्दैन। त्यो हो, मल्टिपाथ TCP ले पहिलो प्रवाहमा SYN प्याकेटको हानि समाधान गर्दैन। र यदि SYN हरायो भने, मल्टिपाथ TCP नियमित TCP मा परिणत हुन्छ। यसको मतलब यो हो कि डाटा सेन्टर वातावरणमा यसले हामीलाई कारखानामा घाटाको समस्या समाधान गर्न र असफलताको अवस्थामा धेरै मार्गहरू प्रयोग गर्न सिक्न मद्दत गर्दैन।


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


म तपाईलाई मसँग थोरै अनुसन्धानमा जान आमन्त्रित गर्दछु। विगत केही वर्षहरूमा लिनक्स कर्नेलमा के भइरहेको छ भनेर हेरौं।

वर्ष 2014। एउटा ठूलो र सम्मानित कम्पनीबाट इन्जिनियरले लिनक्स कर्नेलको कार्यक्षमतामा सकेट ह्यासमा प्रवाह लेबल मानको निर्भरता थप्छ। तिनीहरूले यहाँ के ठीक गर्न खोजिरहेका थिए? यो RFC 6438 सँग सम्बन्धित छ, जसले निम्न मुद्दामा छलफल गरेको छ। डाटा सेन्टर भित्र, IPv4 प्रायः IPv6 प्याकेटहरूमा इन्क्याप्सुलेटेड हुन्छ, किनभने कारखाना आफै IPv6 हो, तर IPv4 कुनै न कुनै रूपमा बाहिर दिनुपर्छ। TCP वा UDP मा पुग्न र त्यहाँ src_ports, dst_ports फेला पार्न दुई आईपी हेडरहरू मुनि हेर्न नसक्ने स्विचहरूमा लामो समयदेखि समस्याहरू थिए। यो बाहिर भयो कि ह्यास, यदि तपाइँ पहिलो दुई आईपी हेडरहरू हेर्नुहुन्छ, लगभग निश्चित भएको थियो। यसबाट बच्नको लागि, यस इनक्याप्सुलेटेड ट्राफिकको सन्तुलनले सही रूपमा काम गर्दछ, यसलाई प्रवाह लेबल फिल्डको मानमा 5-टपल इनक्याप्सुलेटेड प्याकेटको ह्यास थप्न प्रस्ताव गरिएको थियो। लगभग उही कुरा अन्य encapsulation योजनाहरु को लागी गरिएको थियो, UDP को लागी, GRE को लागी, पछिल्लो GRE कुञ्जी फिल्ड प्रयोग गर्यो। एक तरिका वा अर्को, यहाँ लक्ष्यहरू स्पष्ट छन्। र कम्तिमा त्यस समयमा तिनीहरू उपयोगी थिए।

2015 मा, एक नयाँ प्याच उही सम्मानित इन्जिनियरबाट आउँछ। उहाँ धेरै रोचक हुनुहुन्छ। यसले निम्न भन्छ - हामी नकारात्मक राउटिंग घटनाको अवस्थामा ह्यासलाई अनियमित गर्नेछौं। नकारात्मक मार्ग घटना के हो? यो RTO हो जुन हामीले पहिले छलफल गरेका थियौं, त्यो हो, सञ्झ्यालको पुच्छर हराउनु एक घटना हो जुन वास्तवमै नकारात्मक हो। साँचो, यो यो हो कि अनुमान गर्न अपेक्षाकृत गाह्रो छ।

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

यद्यपि होइन, तपाईं सक्नुहुन्न, किनकि यस विषयमा एकल प्रकाशन भएको छैन। तर हामीलाई थाहा छ!

र यदि तपाइँ पूर्ण रूपमा बुझ्नुभएको छैन भने, म तपाइँलाई अहिले बताउनेछु।


के गरियो, लिनक्स कर्नेलमा कुन प्रकार्यता थपियो? txhash प्रत्येक RTO घटना पछि अनियमित मानमा परिवर्तन हुन्छ। यो रूटिङ को धेरै नकारात्मक परिणाम हो। ह्यास यो txhash मा निर्भर गर्दछ, र प्रवाह लेबल skb ह्यास मा निर्भर गर्दछ। यहाँ प्रकार्यहरूमा केही गणनाहरू छन्; सबै विवरणहरू एक स्लाइडमा राख्न सकिँदैन। यदि कोही जिज्ञासु हुनुहुन्छ भने, तपाइँ कर्नेल कोड मार्फत जान सक्नुहुन्छ र जाँच गर्न सक्नुहुन्छ।

यहाँ के महत्त्वपूर्ण छ? प्रत्येक RTO पछि फ्लो लेबल फिल्डको मान अनियमित संख्यामा परिवर्तन हुन्छ। यसले हाम्रो दुर्भाग्यपूर्ण TCP स्ट्रिमलाई कसरी असर गर्छ?


यदि SACK भयो भने, केहि परिवर्तन हुँदैन किनभने हामी ज्ञात हराएको प्याकेट पुन: पठाउने प्रयास गर्दैछौं। अहिलेसम्म धेरै राम्रो।


तर RTO को मामलामा, हामीले ToR मा ह्यास प्रकार्यमा फ्लो लेबल थपेका छौं, ट्राफिकले फरक मार्ग लिन सक्छ। र जति धेरै लेनहरू छन्, त्यति नै ठूलो मौका छ कि यसले एक विशेष उपकरणमा असफलताबाट प्रभावित नहुने बाटो फेला पार्नेछ।


एउटा समस्या बाँकी छ - RTO। निस्सन्देह, त्यहाँ अर्को मार्ग छ, तर यसमा धेरै समय बर्बाद हुन्छ। 200 ms धेरै हो। एक सेकेन्ड बिल्कुल जंगली छ। पहिले, मैले सेवाहरू कन्फिगर गरिएका टाइमआउटहरूको बारेमा कुरा गरें। त्यसोभए, सेकेन्ड एक टाइमआउट हो, जुन सामान्यतया अनुप्रयोग स्तरमा सेवा द्वारा कन्फिगर गरिएको छ, र यसमा सेवा पनि अपेक्षाकृत सही हुनेछ। यसबाहेक, म दोहोर्याउँछु, आधुनिक डाटा सेन्टर भित्र वास्तविक RTT लगभग 1 मिलिसेकेन्ड छ।


तपाईं RTO टाइमआउट संग के गर्न सक्नुहुन्छ? टाइमआउट, जुन डाटा प्याकेटहरू हराएमा RTO का लागि जिम्मेवार छ, प्रयोगकर्ता स्पेसबाट तुलनात्मक रूपमा सजिलै कन्फिगर गर्न सकिन्छ: त्यहाँ एक IP उपयोगिता छ, र यसको एक प्यारामिटरमा समान rto_min समावेश छ। RTO लाई ध्यानमा राख्दै, पक्कै पनि, विश्वव्यापी रूपमा समायोजन गर्न आवश्यक छैन, तर दिइएको उपसर्गहरूको लागि, यस्तो संयन्त्र एकदम कार्ययोग्य देखिन्छ।


साँचो, SYN_RTO सँग सबै कुरा अलि खराब छ। यो स्वाभाविक रूपमा किलिएको छ। कर्नेलको 1 सेकेन्डको निश्चित मान छ, र यो हो। तपाईं प्रयोगकर्ता स्पेसबाट त्यहाँ पुग्न सक्नुहुन्न। त्यहाँ एउटै बाटो छ।


eBPF उद्धारमा आउँछ। यसलाई सरल भाषामा भन्नुपर्दा, यी साना C प्रोग्रामहरू हुन्। तिनीहरू कर्नेल स्ट्याक र TCP स्ट्याकको कार्यान्वयनमा विभिन्न ठाउँहरूमा हुकहरूमा घुसाउन सकिन्छ, जसको साथ तपाईंले धेरै ठूलो संख्यामा सेटिङहरू परिवर्तन गर्न सक्नुहुन्छ। सामान्यतया, eBPF एक दीर्घकालीन प्रवृत्ति हो। दर्जनौं नयाँ sysctl प्यारामिटरहरू काट्नु र IP उपयोगिता विस्तार गर्नुको सट्टा, आन्दोलन eBPF तर्फ सर्दैछ र यसको कार्यक्षमता विस्तार गर्दैछ। eBPF प्रयोग गरेर, तपाइँ गतिशील रूपमा भीड नियन्त्रणहरू र अन्य विभिन्न TCP सेटिङहरू परिवर्तन गर्न सक्नुहुन्छ।


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

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


मानौं तपाईको नेटवर्कमा कुनै सेवा छ जुन कुनै पनि कास्टमा रहन्छ। दुर्भाग्यवश, मसँग कुनै पनि कास्ट भनेको के हो भन्ने बारे विस्तृत रूपमा जानको लागि समय छैन, तर यो एकै आईपी ठेगाना मार्फत पहुँचयोग्य विभिन्न भौतिक सर्भरहरूसँग वितरित सेवा हो। र यहाँ एक सम्भावित समस्या छ: RTO घटना तब मात्र हुन सक्छ जब ट्राफिक कपडा मार्फत जान्छ। यो ToR बफर स्तरमा पनि हुन सक्छ: जब इन्कास्ट घटना हुन्छ, यो होस्टमा पनि हुन सक्छ जब होस्टले केहि फैलाउँछ। जब कुनै RTO घटना हुन्छ र यसले प्रवाह लेबल परिवर्तन गर्छ। यस अवस्थामा, ट्राफिक अर्को कुनै कास्ट उदाहरणमा जान सक्छ। मानौं यो स्टेटफुल कुनै कास्ट हो, यसले जडान अवस्था समावेश गर्दछ - यो L3 ब्यालेन्सर वा अन्य सेवा हुन सक्छ। त्यसपछि समस्या उत्पन्न हुन्छ, किनभने RTO पछि TCP जडान सर्भरमा आउँछ, जसलाई यो TCP जडानको बारेमा केही थाहा हुँदैन। र यदि हामीसँग कुनै पनि कास्ट सर्भरहरू बीच राज्य साझेदारी छैन भने, त्यस्ता ट्राफिकहरू छोडिनेछ र TCP जडान तोडिनेछ।


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

एक तरिका वा अर्को, यो मलाई लाग्छ कि हामी प्रयोग गर्न को लागी तयार छौं।


जब हामीले ToR मा प्रवाह लेबल सक्षम पार्यौं, eBPF एजेन्ट तयार गर्‍यौं, जुन अहिले होस्टहरूमा बस्छ, हामीले अर्को ठूलो विफलताको लागि पर्खने होइन, तर नियन्त्रित विस्फोटहरू सञ्चालन गर्ने निर्णय गर्यौं। हामीले ToR लियौं, जसमा चारवटा अपलिङ्कहरू छन्, र ती मध्ये एउटामा ड्रपहरू सेट अप गर्यौं। तिनीहरूले एउटा नियम बनाए र भने- अब तपाईंले सबै प्याकेटहरू हराउँदै हुनुहुन्छ। तपाईंले बाँयामा देख्न सक्नुहुन्छ, हामीसँग प्रति-प्याकेट निगरानी छ, जुन 75% मा झरेको छ, अर्थात्, 25% प्याकेटहरू हराएका छन्। दायाँपट्टि यस ToR पछि बस्ने सेवाहरूको ग्राफहरू छन्। अनिवार्य रूपमा, यी र्याक भित्र सर्भरहरूसँग इन्टरफेसहरूको ट्राफिक ग्राफहरू हुन्। तपाईले देख्न सक्नुहुन्छ, तिनीहरू अझ तल डुबे। तिनीहरू किन कम भए - 25% द्वारा होइन, तर केहि अवस्थामा 3-4 पटक? यदि TCP जडान अशुभ छ भने, यो भाँचिएको जंक्शन मार्फत पुग्न प्रयास जारी राख्छ। यो DC भित्रको सेवाको सामान्य व्यवहारले बढेको छ - एक प्रयोगकर्ताको अनुरोधको लागि, आन्तरिक सेवाहरूमा N अनुरोधहरू उत्पन्न हुन्छन्, र प्रतिक्रिया प्रयोगकर्तालाई जान्छ जब कि सबै डेटा स्रोतहरूले प्रतिक्रिया दिन्छन्, वा जब अनुप्रयोगमा टाइमआउट हुन्छ। स्तर, जुन अझै कन्फिगर गर्न आवश्यक छ। अर्थात्, सबै धेरै, धेरै खराब छ।


अब उही प्रयोग, तर प्रवाह लेबल मान सक्षम पारिएको छ। तपाईले देख्न सक्नुहुन्छ, बायाँमा हाम्रो ब्याच निगरानी उही 25% ले घट्यो। यो बिल्कुल सही छ, किनभने यो retransmits को बारे मा केहि थाहा छैन, यो प्याकेट पठाउँछ र केवल डेलिभर र हराएको प्याकेट संख्या को अनुपात गणना गर्दछ।

र दायाँ मा सेवा तालिका छ। तपाईंले यहाँ समस्याग्रस्त संयुक्तको प्रभाव फेला पार्नुहुने छैन। उही मिलिसेकेन्डमा, ट्राफिक समस्या क्षेत्रबाट तीन बाँकी अपलिङ्कहरूमा प्रवाह भयो जुन समस्याबाट प्रभावित थिएन। हामीसँग एउटा नेटवर्क छ जसले आफैलाई निको पार्छ।

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

नेटवर्क इन्जिनियरहरूले एक अवधारणात्मक परिवर्तनबाट गुज्रनुपर्छ: नेटवर्क ToR बाट सुरु हुँदैन, नेटवर्क उपकरणसँग होइन, तर होस्टसँग। हामीले कसरी आरटीओ परिवर्तन गर्न र कुनै पनि कास्ट सेवाहरूमा प्रवाह लेबल फिक्स गर्न दुवै eBPF प्रयोग गर्छौं भन्ने एउटा राम्रो उदाहरण हो।

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

स्रोत: www.habr.com