एमपीएलएस हर जगह है। Yandex.Cloud नेटवर्क इन्फ्रास्ट्रक्चर कैसा है

^{पोस्ट द्वारा तैयार: अलेक्जेंडर विरलिन xscrew - लेखक, नेटवर्क इंफ्रास्ट्रक्चर सेवा के प्रमुख, लियोनिद क्लाईव - संपादक}

हम आपको Yandex.Cloud की आंतरिक संरचना से परिचित करना जारी रखते हैं । आज हम नेटवर्क के बारे में बात करेंगे - हम आपको बताएंगे कि नेटवर्क इन्फ्रास्ट्रक्चर कैसे काम करता है, यह डेटा केंद्रों के लिए एमपीएलएस प्रतिमान अलोकप्रिय का उपयोग क्यों करता है, क्लाउड नेटवर्क बनाने की प्रक्रिया में हमें कौन से अन्य जटिल निर्णय लेने थे, हम इसे कैसे देखते हैं और किस तरह की निगरानी करते हैं।

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



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

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

यहाँ क्षेत्रों का सबसे योजनाबद्ध प्रतिनिधित्व है:



वास्तविकता, बदले में, थोड़ा अलग है:


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

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

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

कोर नेटवर्क का उपयोग क्लाउड द्वारा एमपीएलएस परिवहन के रूप में किया जाता है।

MPLS

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



(वास्तव में, लीफ स्विच और स्पाइन के बीच बहुत सारे समानांतर लिंक हैं।)

MPLS क्यों?

सच है, एमपीएलएस डेटा सेंटर नेटवर्क में अक्सर नहीं पाया जाता है। अक्सर पूरी तरह से विभिन्न तकनीकों का उपयोग किया जाता है।

हम कई कारणों से MPLS का उपयोग करते हैं। सबसे पहले, हमने नियंत्रण विमान और डेटा विमान की प्रौद्योगिकियों को एकजुट करना सुविधाजनक पाया। डेटा सेंटर नेटवर्क में कुछ प्रोटोकॉल के बजाय, कोर नेटवर्क में अन्य प्रोटोकॉल और इन प्रोटोकॉल के जंक्शन - एक एकल एमपीएलएस। इस प्रकार, हमने तकनीकी ढेर को एकीकृत किया और नेटवर्क की जटिलता को कम किया।

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

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

संकेतन

क्लासिक एमपीएलएस प्रोटोकॉल स्टैक काफी जटिल है। यह, वैसे, डेटा सेंटर नेटवर्क में एमपीएलएस के अप्रसार के कारणों में से एक है।

हमने, बदले में, IGP (इंटीरियर गेटवे प्रोटोकॉल), या LDP (लेबल वितरण प्रोटोकॉल), या अन्य लेबल प्रोटोकॉल प्रोटोकॉल का उपयोग नहीं किया। केवल BGP (बॉर्डर गेटवे प्रोटोकॉल) लेबल-यूनिकस्ट का उपयोग किया जाता है। प्रत्येक उपकरण, जो चलता है, उदाहरण के लिए, एक आभासी मशीन के रूप में, रैक-माउंट लीफ स्विच से पहले एक बीजीपी सत्र का निर्माण करता है।



बीजीपी सत्र एक पूर्व-ज्ञात पते पर बनाया गया है। प्रत्येक उपकरण को चलाने के लिए स्विच को स्वचालित रूप से कॉन्फ़िगर करने की आवश्यकता नहीं है। सभी स्विच पूर्वनिर्मित और सुसंगत हैं।

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

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

अपना खुद का डॉगफूड खाएं

एक नेटवर्क बिंदु से, यह अवधारणा का अर्थ है कि हम उसी बुनियादी ढांचे में रहते हैं जो हम उपयोगकर्ता को प्रदान करते हैं। यहाँ पहुँच क्षेत्रों में रैक के आरेख हैं:



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

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

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

आईपी ​​/ एमपीएलएस फैक्ट्री

यहाँ उपलब्धता जोन में से एक का एक उदाहरण आरेख है:



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

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

सर्वर कनेक्शन

शक्तिशाली निवेशों के कारण, Yandex इस तरह से सेवाओं का निर्माण करता है कि एक सर्वर, सर्वर रैक, मॉड्यूल या यहां तक ​​कि एक संपूर्ण डेटा केंद्र की विफलता कभी भी सेवा को पूरी तरह से रोक नहीं पाती है। अगर हमें किसी प्रकार की नेटवर्क समस्या है - मान लें कि रैक-माउंट स्विच टूट गया है - बाहरी उपयोगकर्ता इसे कभी नहीं देखते हैं।

Yandex.Cloud एक विशेष मामला है। हम क्लाइंट को उसकी स्वयं की सेवाओं का निर्माण करने का तरीका नहीं बता सकते, और हमने विफलता के इस संभावित एकल बिंदु को समतल करने का निर्णय लिया। इसलिए, क्लाउड के सभी सर्वर दो रैक-माउंट स्विच से जुड़े हैं।

हम एल 2 स्तर पर किसी भी अतिरेक प्रोटोकॉल का उपयोग नहीं करते हैं, लेकिन तुरंत प्रोटोकॉल एकीकरण के कारणों के लिए - बीजीपी के साथ केवल एल 3 का उपयोग करना शुरू कर दिया। यह कनेक्शन IPv4 और IPv6 कनेक्टिविटी के साथ प्रत्येक सेवा प्रदान करता है: कुछ सेवाएँ IPv4 पर काम करती हैं, और IPv6 पर कुछ सेवाएँ।

शारीरिक रूप से, प्रत्येक सर्वर दो 25-गिगाबिट इंटरफेस से जुड़ा होता है। यहाँ डेटा सेंटर से एक तस्वीर है:



यहां आपको 100-गीगाबिट पोर्ट के साथ दो रैक-माउंट स्विच दिखाई देते हैं। डायवर्जेंट ब्रेकआउट केबल दिखाई देते हैं, स्विच के 100-गीगाबिट पोर्ट को प्रति सर्वर 25 गीगाबिट्स के 4 पोर्ट में विभाजित करते हैं। हम इन केबलों को "हाइड्रा" कहते हैं।

इन्फ्रास्ट्रक्चर प्रबंधन

क्लाउड नेटवर्क के बुनियादी ढांचे में कोई मालिकाना प्रबंधन समाधान शामिल नहीं है: सभी सिस्टम क्लाउड के लिए अनुकूलन के साथ या तो खुले स्रोत हैं, या पूरी तरह से स्व-लिखित हैं।



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

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

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

यह सुनिश्चित करने के बाद कि सब कुछ ठीक है, हम पूरे उत्पादन में परिवर्तन लागू करते हैं। किसी भी समय, आप नेटवर्क की पिछली स्थिति में वापस जा सकते हैं और वापस आ सकते हैं, जल्दी से समस्या को ट्रैक और ठीक कर सकते हैं।

निगरानी

हमें अलग निगरानी की जरूरत है। सबसे अधिक मांग में से एक एंड-टू-एंड कनेक्टिविटी की निगरानी कर रहा है। किसी भी समय, प्रत्येक सर्वर को किसी अन्य सर्वर के साथ संवाद करने में सक्षम होना चाहिए। तथ्य यह है कि अगर कहीं पर कोई समस्या है, तो हम यह पता लगाना चाहते हैं कि वास्तव में जहां तक ​​संभव हो (यानी, कौन से सर्वर को एक दूसरे तक पहुंचने में समस्या है)। एंड-टू-एंड कनेक्टिविटी सुनिश्चित करना हमारी प्राथमिक चिंता है।

प्रत्येक सर्वर सभी सर्वरों के एक सेट को सूचीबद्ध करता है जिसके साथ यह किसी भी समय संवाद करने में सक्षम होना चाहिए। सर्वर इस सेट का एक यादृच्छिक सबसेट लेता है और सभी चयनित मशीनों को ICMP, TCP और UDP पैकेट भेजता है। यह जाँच करता है कि नेटवर्क पर क्या नुकसान हैं, क्या देरी बढ़ गई है, आदि पूरे नेटवर्क को एक्सेस जोन में से एक के भीतर और उनके बीच "कहा जाता है"। परिणाम एक केंद्रीकृत प्रणाली को भेजे जाते हैं जो उन्हें हमारे लिए कल्पना करता है।

जब सब कुछ बहुत अच्छा नहीं है तो परिणाम क्या दिखते हैं:


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

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

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

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

आगे क्या है?

हमारी कई योजनाएं हैं। आईपी ​​/ एमपीएलएस कारखानों और बहुत अधिक नियंत्रण प्रणालियों, निगरानी, ​​स्विचिंग में सुधार करना आवश्यक है।

हम सक्रिय रूप से सफेद बॉक्स स्विच की ओर भी देख रहे हैं। यह एक तैयार-निर्मित "लोहा" उपकरण है, एक स्विच जिस पर आप अपने सॉफ़्टवेयर को रोल कर सकते हैं। सबसे पहले, अगर सब कुछ सही ढंग से किया जाता है, तो सर्वर के समान स्विच को "इलाज" करना संभव होगा, वास्तव में सुविधाजनक CI / CD प्रक्रिया का निर्माण करें, वृद्धिशील रूप से रोल आउट कॉन्फ़िगर करें, आदि।

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

सब कुछ करने के लिए, दो दिशाओं में काम चल रहा है:

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

यह वह सब है जो हम अपने नेटवर्क के बुनियादी ढांचे के बारे में बात करना चाहते थे। यहां समाचार और युक्तियों के साथ क्लाउड टेलीग्राम चैनल का लिंक दिया गया है।