क्लोज नेटवर्क में ब्लैकबॉक्स निगरानी। यैंडेक्स रिपोर्ट

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



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



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

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

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

अंत में, अंतिम विकल्प, जो हर किसी को नेटवर्क के विकास के साथ पहुंचता है। यह एंड मेजबानों पर निगरानी रख रहा है। यैंडेक्स की ऐसी निगरानी है। इसे नेटमोन कहा जाता है।



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

नेटमोन ऐसे एजेंट हैं जो नेटवर्क पर लगभग हर होस्ट पर इंस्टॉल किए जाते हैं। यह कार्य एजेंटों के पास आता है: कुछ पैकेटों को कुछ नेटवर्क नोड में भेजने के लिए। वे पूरी तरह से अलग हो सकते हैं: यूडीपी, टीसीपी, आईसीएमपी। यह अलग-अलग पेंट्स के रूप में हो सकता है, अर्थात् डीएससीपी, और गंतव्य। स्रोत और गंतव्य पोर्ट भी भिन्न हो सकते हैं।

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



यहां क्या गलत हो सकता है? उन लोगों के लिए एक छोटा विषयांतर जो पिछले साल के अगले हॉप को नहीं देख पाए थे।

हमने प्रति TOR 400 गीगाबिट्स का उपयोग किया, और इस कारखाने के कार्यान्वयन के पहले क्षण में हमने केवल 200 को शामिल किया, क्योंकि इसमें और भी महत्वपूर्ण कार्य थे। कोई फर्क नहीं पड़ता क्यों। उन्होंने 200 को चालू किया, सेवाओं ने कहा: 200 क्यों? हमें 400 चाहिए! इसे चालू करना शुरू किया। और इसलिए यह हुआ कि कारखाने का दूसरा हिस्सा, जिसमें हम शामिल थे, कार्ड की याद में किसी तरह का विवाह हुआ। नतीजतन, हम कारखाने को चालू करते हैं और इस तस्वीर को देखते हैं:



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



हम उस कार्य पर आए हैं जिसे हमें पूरा करने की आवश्यकता है। क्या करने की जरूरत है? नेटवर्क पर किस डिवाइस के साथ कोई समस्या है यह निर्धारित करें और इसे सेवा से बाहर ले जाएं - या तो स्वचालित रूप से, या बलों द्वारा, उदाहरण के लिए, ऑन-ड्यूटी इंजीनियर।

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

हमने किन विकल्पों पर विचार किया है?



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

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



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

हम टीओआर में आते हैं, देखते हैं कि टीओआर ने बाएं या दाएं लिंक को चुना है। इस मामले में, बाएं लिंक बाएं S1 की ओर है।



हम इस एस 1 पर आए, देखा, सही एस 2, और इस तरह से एक तैयार रास्ता बन गया।



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



फिर हम फेसबुक द्वारा बनाई गई एक रोचक प्रस्तुति में आए। हमें वह विचार पसंद आया जिसे फेसबुक ने प्रस्तावित किया था, हमने कुछ ऐसा ही करने की कोशिश करने का फैसला किया।

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



हमने क्या किया है? बस के मामले में, मैं इंगित करता हूं कि टीसीपी रिट्रांसमिट टीसीपी संदेश हैं जो इस तथ्य के कारण कई बार दोहराए जाते हैं कि उनकी रसीद की पुष्टि नहीं की गई थी। हमारे पास होस्ट पर एक EBPF प्रोग्राम स्थापित है और यह देखता है कि क्या यह TCP संदेश रीट्रांसमिट है या नहीं। यह इसे कॉर्नी करता है - अनुक्रम संख्या द्वारा। यदि एक ही अनुक्रम संख्या एक टीसीपी सत्र में प्रेषित होती है, तो यह रिट्रांसमिट है।

हम ऐसे पैकेजों के साथ क्या करते हैं? हम पूरी चीज़ की गणना करने के लिए DSCP फ़ील्ड में अंतिम बिट सेट करते हैं।



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

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



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

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



यह साधारण कच्चे डेटा पर कैसे दिखता है? यहाँ दो रेखांकन हैं। वास्तव में, ये पहले स्तर की रीढ़ की ओर ToR के साथ रिट्रांसमिट्स चार्ट हैं। उदाहरण में, मॉड्यूल में दो रीढ़। ऊपरी ग्राफ पहली रीढ़ का एकत्रीकरण है, निचला ग्राफ दूसरी रीढ़ है। इस रूप में इसे देखना बहुत सुविधाजनक नहीं है, इसलिए हमने इस जानकारी को एकत्र किया है।



ऐसा दिखता है। एक मॉड्यूल है जिसमें तीन स्पाइन होते हैं, किसी कारण से, कोई फर्क नहीं पड़ता कि कौन सा है, और हम यहां देखते हैं कि रिट्रीन्सिट का कुल वितरण तीन स्पाइन के लिए है। यह सिद्धांत रूप में, काफी समान है।



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



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

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



और यहां, शायद, इतना स्पष्ट रूप से नहीं, लेकिन समस्या दिखाई दे रही है। मॉड्यूल में दो स्पाइन, 46 पेंटेड पैकेट एक में उड़ते हैं, और दूसरे पर थोड़ा सा। हम समझते हैं कि हमें नेटवर्क पर किसी प्रकार की रीढ़ की समस्या है, हमें इसके बारे में कुछ करना होगा।

मैंने पहली बार दर्द और पीड़ा के बारे में बात क्यों की? क्योंकि इस तरह के समाधान के साथ बहुत सारी समस्याएं हैं। मुख्य समस्या, ज़ाहिर है, किसी भी निगरानी की समस्या है, यह गलत सकारात्मक है। झूठी सकारात्मक काफी थी। मुख्य रूप से इस तथ्य के कारण कि हम डीएससीपी का उपयोग करते हैं और आमतौर पर क्यूओएस से बंधे होते हैं।



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

कुछ निर्माताओं ने ऐसे पैकेटों की आउटगोइंग दिशा में काउंटरों के रूप में आश्चर्य प्रस्तुत किया, और चिप इस तरह से काम करती है, वास्तव में, आउटगोइंग एक्सेस सूची को संसाधित करने के लिए यह फिर से ट्रैफिक को लपेटता है, चिप बैंडविड्थ के आधे हिस्से को काटता है। । यह प्रति चिप 900 गीगाबिट था, यह आधा हो गया।

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

सबसे पहले, हमने हर टीसीपी रिट्रांसमिट को पेंट करने का विचार त्याग दिया। हमें एहसास हुआ कि, सिद्धांत रूप में, हमें यह समझने के लिए कि समस्या कहाँ है, हर रिट्रांसमीटर की आवश्यकता नहीं है। हमने केवल SYN-retransmit पेंट करना शुरू किया। SYN सत्र का पहला पैकेट है, यह हमारे लिए संकेत प्राप्त करने के लिए पर्याप्त है। हम SYN-ACL को भी पेंट करते हैं।

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

कुल मिलाकर, नेटमोन है, मेजबानों पर ऐसे एजेंट हैं जो सत्र में पहले SYN-retransmit को रंगते हैं, और हम अपने नेटवर्क में लगभग हर लिंक पर, प्रत्येक डिवाइस पर इन रिट्रांसमिट की गणना करते हैं।



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

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

यहां अलर्ट करने में क्या मुश्किल है? तथ्य यह है कि हम थ्रेसहोल्ड को स्थिर नहीं बना सकते हैं, हम यह नहीं कह सकते हैं: यदि एक डिवाइस पर दस रिट्रांसमिट आते हैं और दूसरे पर नौ, तो कोई समस्या नहीं है। और अगर दस और पांच, तो एक समस्या है। क्योंकि अगर हम इसे एक हजार पीपीएस में बदल देते हैं, तो ऐसा डेटा प्रासंगिक नहीं रह जाएगा। विभिन्न उपकरणों के बीच 1000 पीपीएस और 800 पीपीएस निश्चित रूप से एक समस्या है।

हम PPS या बाइट्स में स्थिर थ्रेशोल्ड सेट नहीं कर सकते हैं, हम उन्हें प्रतिशत के रूप में सेट नहीं कर सकते हैं - उनके साथ समान समस्या। इसलिए, हमें एक समाधान की आवश्यकता है जो पैकेट की संख्या के आधार पर इस सीमा को अधिक या कम गतिशील बनाता है।

और द्विपद वितरण का आकर्षण यह है कि PPS में वृद्धि करने पर यह सामान्य हो जाता है, और एक सामान्य वितरण के लिए हम पहले से ही अपेक्षा, विचरण की गणना और विश्वास अंतराल की गणना कर सकते हैं, जो हमने किया था। हमारे लिए विश्वास अंतराल 3NPQ है, अर्थात, यह डिवाइस के माध्यम से पैकेट की संख्या पर निर्भर करता है। नतीजतन, हमारे पास एक गतिशील स्थानांतरण सीमा है।

इस तरह से हमारा सिग्नल तस्वीर में दिखता है। यदि कुछ डिवाइस को वितरण से बाहर खटखटाया जाता है, तो हम उस पर एक झंडा उठाते हैं - इसके साथ कुछ गलत है।



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

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

उदाहरण के लिए, अब हम सत्र में केवल पहले SYN-retransmit पेंटिंग कर रहे हैं। और हम दूसरे बिट को रंग सकते हैं, उदाहरण के लिए, अगर पैकेट किसी बाहरी नेटवर्क पर जाता है। और हम फिर से प्रयास कर सकते हैं, अर्थात्, एक और संकेत पर प्रकाश डाला, जिसे हम अलग से विचार करेंगे।

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

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