डेटा सेंटर्स कसे मोजायचे. यांडेक्स अहवाल

आम्ही एक डेटा सेंटर नेटवर्क डिझाइन विकसित केले आहे जे 100 हजार सर्व्हरपेक्षा मोठ्या कॉम्प्युटिंग क्लस्टर्सच्या तैनातीची अनुमती देते ज्याची पीक बायसेक्शन बँडविड्थ प्रति सेकंद एक पेटाबाइटपेक्षा जास्त आहे.

दिमित्री अफानास्येव्हच्या अहवालावरून तुम्ही नवीन डिझाइनची मूलभूत तत्त्वे, स्केलिंग टोपोलॉजीज, यामुळे उद्भवणाऱ्या समस्या, त्या सोडवण्याचे पर्याय, आधुनिक नेटवर्क डिव्हाइसेसच्या "घनतेने जोडलेल्या" मध्ये फॉरवर्डिंग प्लेन फंक्शन्सचे रूटिंग आणि स्केलिंगची वैशिष्ट्ये जाणून घ्याल. मोठ्या संख्येने ECMP मार्गांसह टोपोलॉजीज. याव्यतिरिक्त, दिमाने बाह्य कनेक्टिव्हिटी, भौतिक स्तर, केबलिंग सिस्टम आणि क्षमता वाढवण्याच्या मार्गांबद्दल थोडक्यात सांगितले.

- शुभ दुपार सर्वांना! माझे नाव दिमित्री अफानासेव्ह आहे, मी यांडेक्स येथे नेटवर्क आर्किटेक्ट आहे आणि मुख्यतः डेटा सेंटर नेटवर्क डिझाइन करतो.



माझी कथा यांडेक्स डेटा सेंटर्सच्या अद्ययावत नेटवर्कबद्दल असेल. आमच्याकडे असलेल्या डिझाइनची ही उत्क्रांती आहे, परंतु त्याच वेळी काही नवीन घटक आहेत. हे एक विहंगावलोकन सादरीकरण आहे कारण थोड्या वेळात भरपूर माहिती भरायची होती. आम्ही लॉजिकल टोपोलॉजी निवडून सुरुवात करू. त्यानंतर कंट्रोल प्लेनचे विहंगावलोकन आणि डेटा प्लेन स्केलेबिलिटीसह समस्या असतील, भौतिक स्तरावर काय होईल याची निवड होईल आणि आम्ही डिव्हाइसेसची काही वैशिष्ट्ये पाहू. MPLS सह डेटा सेंटरमध्ये काय चालले आहे यावर थोडेसे स्पर्श करूया, ज्याबद्दल आम्ही काही काळापूर्वी बोललो होतो.

तर, भार आणि सेवांच्या बाबतीत यांडेक्स म्हणजे काय? यांडेक्स हा एक सामान्य हायपरस्केलर आहे. आम्ही वापरकर्त्यांकडे पाहिल्यास, आम्ही प्रामुख्याने वापरकर्त्यांच्या विनंतीवर प्रक्रिया करतो. तसेच विविध स्ट्रीमिंग सेवा आणि डेटा ट्रान्सफर, कारण आमच्याकडे स्टोरेज सेवा देखील आहेत. बॅकएंडच्या जवळ असल्यास, तेथे पायाभूत सुविधा लोड आणि सेवा दिसतात, जसे की वितरित ऑब्जेक्ट स्टोरेज, डेटा प्रतिकृती आणि अर्थातच, सतत रांगा. वर्कलोडच्या मुख्य प्रकारांपैकी एक म्हणजे MapReduce आणि तत्सम प्रणाली, प्रवाह प्रक्रिया, मशीन लर्निंग इ.

पायाभूत सुविधा कशा आहेत ज्याच्या वर हे सर्व घडते? पुन्हा, आम्ही एक सुंदर टिपिकल हायपरस्केलर आहोत, जरी आम्ही स्पेक्ट्रमच्या कमी हायपरस्केलर बाजूच्या थोडे जवळ आहोत. पण आपल्यात सर्व गुणधर्म आहेत. जिथे शक्य असेल तिथे आम्ही कमोडिटी हार्डवेअर आणि क्षैतिज स्केलिंग वापरतो. आमच्याकडे संपूर्ण संसाधने आहेत: आम्ही वैयक्तिक मशीन, वैयक्तिक रॅकसह कार्य करत नाही, परंतु त्यांना अदलाबदल करण्यायोग्य संसाधनांच्या मोठ्या पूलमध्ये एकत्र करतो जे नियोजन आणि वाटप हाताळतात आणि या संपूर्ण पूलसह कार्य करतात.

म्हणून आमच्याकडे पुढील स्तर आहे - संगणकीय क्लस्टर स्तरावरील ऑपरेटिंग सिस्टम. आम्ही वापरत असलेल्या तंत्रज्ञानाच्या स्टॅकवर आम्ही पूर्णपणे नियंत्रण ठेवणे अत्यंत महत्त्वाचे आहे. आम्ही एंडपॉइंट्स (होस्ट), नेटवर्क आणि सॉफ्टवेअर स्टॅक नियंत्रित करतो.

आमच्याकडे रशिया आणि परदेशात अनेक मोठी डेटा केंद्रे आहेत. ते MPLS तंत्रज्ञान वापरणाऱ्या पाठीच्या कणाद्वारे एकत्र आले आहेत. आमची अंतर्गत पायाभूत सुविधा जवळजवळ संपूर्णपणे IPv6 वर तयार केलेली आहे, परंतु आम्हाला बाह्य रहदारीची सेवा करायची आहे जी अजूनही मुख्यतः IPv4 वर येते, आम्ही कसे तरी IPv4 वर येणार्‍या विनंत्या फ्रंटएंड सर्व्हरवर वितरित केल्या पाहिजेत आणि थोडे अधिक बाह्य IPv4- इंटरनेटवर जावे. उदाहरणार्थ, अनुक्रमणिका साठी.

डेटा सेंटर नेटवर्क डिझाइन्सच्या शेवटच्या काही पुनरावृत्तीमध्ये मल्टी-लेयर क्लोस टोपोलॉजीज वापरल्या गेल्या आहेत आणि फक्त L3 आहेत. आम्ही काही वेळापूर्वी L2 सोडले आणि सुटकेचा नि:श्वास टाकला. शेवटी, आमच्या पायाभूत सुविधांमध्ये शेकडो हजारो गणना (सर्व्हर) उदाहरणे समाविष्ट आहेत. काही काळापूर्वी कमाल क्लस्टर आकार सुमारे 10 हजार सर्व्हर होता. हे मुख्यत्वे त्या समान क्लस्टर-स्तरीय ऑपरेटिंग सिस्टम, शेड्युलर, संसाधन वाटप इ. कसे कार्य करू शकतात या कारणास्तव आहे. पायाभूत सुविधा सॉफ्टवेअरच्या बाजूने प्रगती झाली असल्याने, लक्ष्य आकार आता एका संगणकीय क्लस्टरमध्ये सुमारे 100 हजार सर्व्हर आहे, आणि आमच्याकडे एक कार्य आहे - अशा क्लस्टरमध्ये कार्यक्षम संसाधन एकत्र करण्यास अनुमती देणारे नेटवर्क कारखाने तयार करण्यास सक्षम असणे.

डेटा सेंटर नेटवर्ककडून आम्हाला काय हवे आहे? सर्व प्रथम, भरपूर स्वस्त आणि एकसमान वितरित बँडविड्थ आहे. कारण नेटवर्क हा कणा आहे ज्याद्वारे आपण संसाधने एकत्र करू शकतो. नवीन लक्ष्य आकार एका क्लस्टरमध्ये सुमारे 100 हजार सर्व्हर आहे.

आम्हाला अर्थातच, एक स्केलेबल आणि स्थिर नियंत्रण विमान हवे आहे, कारण एवढ्या मोठ्या पायाभूत सुविधांवर केवळ यादृच्छिक घटनांमुळेही बरीच डोकेदुखी उद्भवते आणि आम्हाला नियंत्रण विमानाने देखील डोकेदुखी आणू इच्छित नाही. त्याच वेळी, आम्हाला त्यात राज्य कमी करायचे आहे. स्थिती जितकी लहान असेल तितके चांगले आणि अधिक स्थिर सर्वकाही कार्य करते आणि निदान करणे सोपे आहे.

अर्थात, आम्हाला ऑटोमेशनची गरज आहे, कारण अशा पायाभूत सुविधा मॅन्युअली व्यवस्थापित करणे अशक्य आहे आणि काही काळापासून ते अशक्य आहे. आम्हाला शक्य तितके ऑपरेशनल सपोर्ट आणि CI/CD सपोर्ट हवा आहे.

डेटा सेंटर्स आणि क्लस्टर्सच्या अशा आकारांसह, सेवा व्यत्ययाशिवाय वाढीव तैनाती आणि विस्तारास समर्थन देण्याचे कार्य खूपच तीव्र झाले आहे. जर हजार मशीन्सच्या आकाराच्या क्लस्टर्सवर, कदाचित दहा हजार मशीन्सच्या जवळपास, तरीही ते एक ऑपरेशन म्हणून आणले जाऊ शकतात - म्हणजे, आम्ही पायाभूत सुविधांच्या विस्ताराची योजना आखत आहोत, आणि एक ऑपरेशन म्हणून अनेक हजार मशीन जोडल्या गेल्या आहेत, मग एक लाख मशीनच्या आकाराचा क्लस्टर अशा प्रकारे लगेच उद्भवत नाही, तो ठराविक कालावधीत तयार केला जातो. आणि हे इष्ट आहे की या सर्व वेळेस जे आधीच बाहेर काढले गेले आहे, ज्या पायाभूत सुविधा तैनात केल्या आहेत, त्या उपलब्ध असणे आवश्यक आहे.

आणि एक आवश्यकता जी आमच्याकडे होती आणि राहिली आहे: मल्टीटेनन्सीसाठी समर्थन, म्हणजे व्हर्च्युअलायझेशन किंवा नेटवर्क सेगमेंटेशन. आता आम्हाला नेटवर्क फॅब्रिक स्तरावर हे करण्याची आवश्यकता नाही, कारण शार्डिंग होस्टकडे गेले आहे आणि यामुळे आमच्यासाठी स्केलिंग खूप सोपे झाले आहे. IPv6 आणि मोठ्या अॅड्रेस स्पेसबद्दल धन्यवाद, आम्हाला अंतर्गत इन्फ्रास्ट्रक्चरमध्ये डुप्लिकेट पत्ते वापरण्याची आवश्यकता नव्हती; सर्व पत्ते आधीच अद्वितीय होते. आणि आम्ही यजमानांना फिल्टरिंग आणि नेटवर्क सेगमेंटेशन घेतल्याबद्दल धन्यवाद, आम्हाला डेटा सेंटर नेटवर्कमध्ये कोणतीही आभासी नेटवर्क संस्था तयार करण्याची आवश्यकता नाही.

एक अतिशय महत्त्वाची गोष्ट म्हणजे आपल्याला ज्याची गरज नाही. जर नेटवर्कमधून काही फंक्शन्स काढली जाऊ शकतात, तर हे जीवन खूप सोपे करते आणि, नियम म्हणून, उपलब्ध उपकरणे आणि सॉफ्टवेअरची निवड विस्तृत करते, निदान अगदी सोपे करते.

तर, आपल्याला कशाची गरज नाही, आपण काय सोडू शकलो आहोत, जे घडले त्या वेळी आनंदाने नाही, परंतु प्रक्रिया पूर्ण झाल्यावर मोठ्या आरामाने?

सर्व प्रथम, L2 सोडणे. आम्हाला L2 ची गरज नाही, वास्तविक किंवा अनुकरणही नाही. आम्ही ऍप्लिकेशन स्टॅक नियंत्रित करतो या वस्तुस्थितीमुळे मोठ्या प्रमाणात न वापरलेले. आमचे अॅप्लिकेशन्स क्षैतिजरित्या स्केलेबल आहेत, ते L3 अॅड्रेसिंगसह कार्य करतात, काही वैयक्तिक उदाहरण बाहेर गेले आहेत याची त्यांना फारशी काळजी नसते, ते फक्त एक नवीन रोल आउट करतात, ते जुन्या पत्त्यावर आणण्याची आवश्यकता नाही, कारण तेथे एक आहे क्लस्टरमध्ये असलेल्या मशीन्सची सेवा शोध आणि निरीक्षणाची स्वतंत्र पातळी. आम्ही हे कार्य नेटवर्कला सोपवत नाही. नेटवर्कचे कार्य पॉइंट A ते पॉइंट B पर्यंत पॅकेट वितरित करणे आहे.

आमच्याकडे अशी परिस्थिती देखील नाही जिथे पत्ते नेटवर्कमध्ये फिरतात आणि याचे परीक्षण करणे आवश्यक आहे. बर्‍याच डिझाईन्समध्ये हे विशेषत: VM गतिशीलतेला समर्थन देण्यासाठी आवश्यक आहे. आम्ही मोठ्या Yandex च्या अंतर्गत पायाभूत सुविधांमध्ये व्हर्च्युअल मशीनची गतिशीलता वापरत नाही आणि त्याशिवाय, आम्ही विश्वास ठेवतो की जरी हे केले गेले असले तरी, नेटवर्क समर्थनासह ते होऊ नये. जर ते खरोखर करण्याची गरज असेल, तर ते होस्ट स्तरावर केले जाणे आवश्यक आहे, आणि आच्छादनांमध्ये स्थलांतरित होऊ शकणारे पत्ते पुश करणे आवश्यक आहे, जेणेकरून अंडरलेच्या स्वतःच्या राउटिंग सिस्टमला स्पर्श करू नये किंवा खूप डायनॅमिक बदल करू नये (वाहतूक नेटवर्क) .

आणखी एक तंत्रज्ञान जे आपण वापरत नाही ते म्हणजे मल्टीकास्ट. तुम्हाला हवे असल्यास, मी तुम्हाला सविस्तर कारण सांगू शकतो. हे जीवन खूप सोपे बनवते, कारण जर एखाद्याने हे हाताळले असेल आणि मल्टिकास्ट कंट्रोल प्लेन कसे दिसते ते पाहिले तर, अगदी सोप्या स्थापनेशिवाय, ही एक मोठी डोकेदुखी आहे. आणि इतकेच काय, उदाहरणार्थ, चांगल्या प्रकारे कार्य करणारे ओपन सोर्स अंमलबजावणी शोधणे कठीण आहे.

शेवटी, आम्ही आमचे नेटवर्क डिझाइन करतो जेणेकरून ते जास्त बदलू नयेत. आम्ही या वस्तुस्थितीवर विश्वास ठेवू शकतो की रूटिंग सिस्टममध्ये बाह्य घटनांचा प्रवाह लहान आहे.

जेव्हा आम्ही डेटा सेंटर नेटवर्क विकसित करतो तेव्हा कोणत्या समस्या उद्भवतात आणि कोणते निर्बंध विचारात घेतले पाहिजेत? खर्च, अर्थातच. स्केलेबिलिटी, ज्या पातळीपर्यंत आपण वाढू इच्छितो. सेवा न थांबवता विस्तार करण्याची गरज आहे. बँडविड्थ, उपलब्धता. मॉनिटरिंग सिस्टम, ऑपरेशनल टीमसाठी नेटवर्कवर काय घडत आहे याची दृश्यमानता. ऑटोमेशन समर्थन - पुन्हा, शक्य तितके, कारण अतिरिक्त स्तरांच्या परिचयासह भिन्न कार्ये वेगवेगळ्या स्तरांवर सोडविली जाऊ शकतात. बरं, [शक्यतो] विक्रेत्यांवर अवलंबून नाही. जरी वेगवेगळ्या ऐतिहासिक कालखंडात, आपण कोणत्या विभागात पहात आहात त्यानुसार हे स्वातंत्र्य मिळवणे सोपे किंवा अधिक कठीण होते. जर आम्ही नेटवर्क डिव्हाइस चिप्सचा क्रॉस-सेक्शन घेतला, तर अलीकडेपर्यंत आम्हाला उच्च थ्रूपुटसह चिप्स हव्या असल्यास विक्रेत्यांपासून स्वातंत्र्याबद्दल बोलणे अत्यंत सशर्त होते.

आमचे नेटवर्क तयार करण्यासाठी आम्ही कोणत्या तार्किक टोपोलॉजीचा वापर करू? हे बहु-स्तरीय Clos असेल. खरं तर, याक्षणी कोणतेही वास्तविक पर्याय नाहीत. आणि क्लॉस टोपोलॉजी खूप चांगली आहे, जरी आमच्याकडे मोठे रेडिक्स स्विच असल्यास, आता शैक्षणिक स्वारस्य असलेल्या विविध प्रगत टोपोलॉजीजच्या तुलनेत.

बहु-स्तरीय Clos नेटवर्क साधारणपणे कसे तयार केले जाते आणि त्यात विविध घटकांना काय म्हणतात? सर्व प्रथम, वारा उगवला, स्वतःला उत्तर कोठे आहे, दक्षिण कोठे आहे, पूर्व कोठे आहे, कुठे पश्चिम आहे. या प्रकारचे नेटवर्क सहसा ज्यांच्याकडे पश्चिम-पूर्व रहदारी खूप जास्त असते त्यांच्याद्वारे तयार केली जाते. उर्वरित घटकांबद्दल, शीर्षस्थानी एक आभासी स्विच आहे जो लहान स्विचमधून एकत्र केला जातो. क्लोस नेटवर्कच्या पुनरावृत्ती बांधकामाची ही मुख्य कल्पना आहे. आम्ही काही प्रकारचे मूलांक असलेले घटक घेतो आणि त्यांना जोडतो जेणेकरून आम्हाला जे मिळते ते एका मोठ्या रेडिक्ससह स्विच मानले जाऊ शकते. आपल्याला आणखी आवश्यक असल्यास, प्रक्रिया पुन्हा केली जाऊ शकते.

प्रकरणांमध्ये, उदाहरणार्थ, दोन-स्तरीय Clos सह, जेव्हा माझ्या आकृतीमध्ये अनुलंब असलेले घटक स्पष्टपणे ओळखणे शक्य होते, तेव्हा त्यांना सामान्यतः विमान म्हणतात. जर आपण तीन स्तरांच्या स्पाइन स्विचेससह क्लॉस तयार केला (जे सर्व सीमा किंवा टीओआर स्विच नाहीत आणि जे फक्त ट्रांझिटसाठी वापरले जातात), तर विमाने अधिक जटिल दिसतील; दोन-स्तरीय तंतोतंत यासारखे दिसतात. आम्ही टीओआर किंवा लीफ स्विचेसच्या ब्लॉकला आणि त्यांच्याशी संबंधित पहिल्या स्तरावरील स्पाइन स्विचेसला पॉड म्हणतो. पॉडच्या शीर्षस्थानी स्पाइन -1 स्तराचे स्पाइन स्विच पॉडच्या शीर्षस्थानी, पॉडच्या शीर्षस्थानी असतात. संपूर्ण कारखान्याच्या शीर्षस्थानी असलेले स्विचेस फॅब्रिकच्या शीर्षस्थानी, फॅब्रिकच्या शीर्षस्थानी असतात.

अर्थात, प्रश्न उद्भवतो: क्लोस नेटवर्क काही काळासाठी तयार केले गेले आहेत; कल्पना स्वतःच सामान्यतः शास्त्रीय टेलिफोनी, टीडीएम नेटवर्कच्या काळापासून येते. कदाचित काहीतरी चांगले दिसले असेल, कदाचित काहीतरी चांगले केले जाऊ शकते? होय आणि नाही. सैद्धांतिकदृष्ट्या होय, सराव मध्ये नजीकच्या भविष्यात नक्कीच नाही. कारण अनेक मनोरंजक टोपोलॉजीज आहेत, त्यापैकी काही उत्पादनात देखील वापरल्या जातात, उदाहरणार्थ, ड्रॅगनफ्लाय एचपीसी अनुप्रयोगांमध्ये वापरला जातो; Xpander, FatClique, Jellyfish सारख्या मनोरंजक टोपोलॉजी देखील आहेत. तुम्ही अलीकडेच SIGCOMM किंवा NSDI सारख्या कॉन्फरन्समधील अहवाल पाहिल्यास, तुम्हाला पर्यायी टोपोलॉजीजवर बरीच कामे सापडतील ज्यात Clos पेक्षा चांगले गुणधर्म (एक किंवा दुसरे) आहेत.

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

सैद्धांतिकदृष्ट्या, समस्येचे निराकरण ज्ञात आहे. हे, उदाहरणार्थ, k-shortest पाथ वापरून लिंक स्टेटमधील बदल आहेत, परंतु, पुन्हा, असे कोणतेही प्रोटोकॉल नाहीत जे उत्पादनात लागू केले जातील आणि उपकरणांवर मोठ्या प्रमाणावर उपलब्ध असतील.

शिवाय, बहुतेक क्षमता सर्वात लहान मार्गांद्वारे प्रवेश करण्यायोग्य नसल्यामुळे, आम्हाला ते सर्व मार्ग निवडण्यासाठी फक्त कंट्रोल प्लेनपेक्षा अधिक सुधारणे आवश्यक आहे (आणि तसे, हे कंट्रोल प्लेनमध्ये लक्षणीयरीत्या अधिक स्थिती आहे). आम्हाला अद्याप फॉरवर्डिंग प्लेन सुधारित करणे आवश्यक आहे आणि, नियम म्हणून, किमान दोन अतिरिक्त वैशिष्ट्ये आवश्यक आहेत. पॅकेट फॉरवर्ड करण्याबाबतचे सर्व निर्णय एकवेळ घेण्याची ही क्षमता आहे, उदाहरणार्थ, होस्टवर. खरं तर, हे स्त्रोत राउटिंग आहे, कधीकधी इंटरकनेक्शन नेटवर्कवरील साहित्यात याला सर्व-एकदा फॉरवर्डिंग निर्णय म्हणतात. आणि अ‍ॅडॉप्टिव्ह राउटिंग हे एक फंक्शन आहे जे आम्हाला नेटवर्क घटकांवर आवश्यक आहे, जे उकळते, उदाहरणार्थ, आम्ही रांगेवरील कमीत कमी भार असलेल्या माहितीवर आधारित पुढील हॉप निवडतो. उदाहरणार्थ, इतर पर्याय शक्य आहेत.

अशा प्रकारे, दिशा मनोरंजक आहे, परंतु, अरेरे, आम्ही आत्ता ते लागू करू शकत नाही.

ठीक आहे, आम्ही Clos लॉजिकल टोपोलॉजी वर सेटल झालो. आम्ही ते कसे मोजणार? ते कसे कार्य करते आणि काय करता येईल ते पाहूया.

क्लॉस नेटवर्कमध्ये दोन मुख्य पॅरामीटर्स आहेत जे आम्ही कसे तरी बदलू शकतो आणि विशिष्ट परिणाम मिळवू शकतो: घटकांचे मूलांक आणि नेटवर्कमधील स्तरांची संख्या. दोन्हीचा आकार कसा प्रभावित होतो याचे माझ्याकडे एक योजनाबद्ध आकृती आहे. आदर्शपणे, आम्ही दोन्ही एकत्र करतो.

हे पाहिले जाऊ शकते की क्लॉस नेटवर्कची अंतिम रुंदी ही दक्षिणी रेडिक्सच्या स्पाइन स्विचच्या सर्व स्तरांचे उत्पादन आहे, आमच्याकडे किती दुवे आहेत, ते कसे शाखा आहेत. अशा प्रकारे आपण नेटवर्कचा आकार मोजतो.

क्षमतेबाबत, विशेषत: टीओआर स्विचेसवर, दोन स्केलिंग पर्याय आहेत. एकतर आम्ही सामान्य टोपोलॉजी राखून, जलद दुवे वापरू शकतो किंवा आम्ही आणखी विमाने जोडू शकतो.

तुम्ही Clos नेटवर्कची (खालच्या उजव्या कोपर्यात) विस्तारित आवृत्ती पाहिल्यास आणि खाली दिलेल्या Clos नेटवर्कसह या चित्रावर परत आल्यास...

... मग हे अगदी समान टोपोलॉजी आहे, परंतु या स्लाइडवर ते अधिक संक्षिप्तपणे कोसळले आहे आणि कारखान्याची विमाने एकमेकांवर चिकटलेली आहेत. ती तशीच आहे.

क्लोस नेटवर्कचे स्केलिंग संख्यांमध्ये कसे दिसते? नेटवर्कची जास्तीत जास्त रुंदी किती मिळू शकते, किती रॅक, टीओआर स्विचेस किंवा लीफ स्विचेस, ते रॅकमध्ये नसल्यास, आपण स्पाइन-लेव्हल्ससाठी कोणत्या स्विचेसचा रेडिक्स वापरतो यावर अवलंबून असलेला डेटा मी येथे प्रदान करतो, आणि आपण किती स्तर वापरतो.

20 kW प्रति रॅकवर आधारित आमच्याकडे किती रॅक असू शकतात, किती सर्व्हर आणि अंदाजे हे सर्व किती वापरता येईल ते येथे आहे. थोड्या आधी मी नमूद केले की आम्ही सुमारे 100 हजार सर्व्हरच्या क्लस्टर आकाराचे लक्ष्य ठेवत आहोत.

या संपूर्ण डिझाइनमध्ये अडीच पर्याय स्वारस्य असल्याचे दिसून येते. मणक्याचे दोन स्तर आणि 64-पोर्ट स्विचसह एक पर्याय आहे, जो थोडासा कमी पडतो. त्यानंतर 128-पोर्ट (रेडिक्स 128 सह) स्पाइन स्विचेस दोन लेव्हल्ससह किंवा रेडिक्स 32 सह तीन लेव्हल्ससह स्विचेससाठी योग्य पर्याय आहेत. आणि सर्व प्रकरणांमध्ये, जेथे अधिक रेडिक्स आणि अधिक स्तर आहेत, आपण खूप मोठे नेटवर्क बनवू शकता, परंतु आपण अपेक्षित वापर पाहिल्यास, सामान्यत: गिगावॅट्स आहेत. केबल टाकणे शक्य आहे, परंतु आम्हाला एका ठिकाणी इतकी वीज मिळण्याची शक्यता नाही. तुम्ही डेटा सेंटर्सवरील आकडेवारी आणि सार्वजनिक डेटा पाहिल्यास, तुम्हाला 150 MW पेक्षा जास्त क्षमतेच्या अंदाजे डेटा सेंटर्स सापडतील. मोठे डेटा सेंटर कॅम्पस असतात, अनेक मोठे डेटा सेंटर एकमेकांच्या अगदी जवळ असतात.

आणखी एक महत्त्वाचा पॅरामीटर आहे. तुम्ही डाव्या स्तंभात पाहिल्यास, वापरण्यायोग्य बँडविड्थ तेथे सूचीबद्ध आहे. हे पाहणे सोपे आहे की क्लॉस नेटवर्कमध्ये पोर्टचा एक महत्त्वाचा भाग स्विचेस एकमेकांशी जोडण्यासाठी वापरला जातो. वापरण्यायोग्य बँडविड्थ, एक उपयुक्त पट्टी, अशी गोष्ट आहे जी सर्व्हरच्या दिशेने, बाहेर दिली जाऊ शकते. स्वाभाविकच, मी सशर्त पोर्टबद्दल आणि विशेषतः बँडबद्दल बोलत आहे. नियमानुसार, नेटवर्कमधील लिंक्स सर्व्हरच्या दुव्यांपेक्षा वेगवान असतात, परंतु बँडविड्थच्या प्रति युनिट, जेवढे आम्ही आमच्या सर्व्हर उपकरणांवर पाठवू शकतो, नेटवर्कमध्येच काही बँडविड्थ अजूनही आहे. आणि आम्ही जितके अधिक स्तर बनवू, तितकी ही पट्टी बाहेरून प्रदान करण्याची विशिष्ट किंमत जास्त असेल.

शिवाय, हा अतिरिक्त बँड देखील अगदी सारखा नाही. स्पॅन लहान असताना, आम्ही DAC (डायरेक्ट अटॅच कॉपर, म्हणजेच ट्विनॅक्स केबल्स), किंवा मल्टीमोड ऑप्टिक्स सारखे काहीतरी वापरू शकतो, ज्यासाठी कमी किंवा जास्त वाजवी पैसे खर्च होतात. जितक्या लवकर आपण लांब स्पॅन्सकडे जातो - नियम म्हणून, हे एकल मोड ऑप्टिक्स आहेत आणि या अतिरिक्त बँडविड्थची किंमत लक्षणीय वाढते.

आणि पुन्हा, मागील स्लाइडवर परत जाऊन, जर आपण ओव्हरसबस्क्रिप्शनशिवाय क्लॉस नेटवर्क तयार केले, तर आकृती पाहणे सोपे आहे, नेटवर्क कसे तयार केले आहे ते पहा - स्पाइन स्विचचे प्रत्येक स्तर जोडून, ​​आम्ही संपूर्ण पट्टीची पुनरावृत्ती करतो जी तळाशी प्लस लेव्हल - अधिक समान बँड, पूर्वीच्या स्तरावर जितके पोर्ट होते तितकेच स्विचेस आणि तितकेच ट्रान्ससीव्हर्स. म्हणून, स्पाइन स्विचेसच्या स्तरांची संख्या कमी करणे अत्यंत इष्ट आहे.

या चित्राच्या आधारे, हे स्पष्ट आहे की आम्हाला खरोखर 128 च्या रेडिक्ससह स्विचसारखे काहीतरी तयार करायचे आहे.

येथे, तत्त्वतः, सर्व काही मी आत्ताच म्हटल्याप्रमाणेच आहे; नंतर विचार करण्यासाठी ही एक स्लाइड आहे.

असे कोणते पर्याय आहेत जे आपण असे स्विच म्हणून निवडू शकतो? आमच्यासाठी ही खूप आनंददायी बातमी आहे की आता असे नेटवर्क शेवटी सिंगल-चिप स्विचवर तयार केले जाऊ शकतात. आणि हे खूप छान आहे, त्यांच्याकडे खूप छान वैशिष्ट्ये आहेत. उदाहरणार्थ, त्यांच्याकडे जवळजवळ कोणतीही अंतर्गत रचना नाही. याचा अर्थ ते अधिक सहजपणे तुटतात. ते सर्व प्रकारच्या मोडतात, परंतु सुदैवाने ते पूर्णपणे तुटतात. मॉड्यूलर उपकरणांमध्ये मोठ्या प्रमाणात दोष (अत्यंत अप्रिय) आहेत, जेव्हा शेजारी आणि नियंत्रण विमानाच्या दृष्टिकोनातून ते कार्य करत असल्याचे दिसते, परंतु, उदाहरणार्थ, फॅब्रिकचा काही भाग हरवला आहे आणि ते कार्य करत नाही. पूर्ण क्षमतेने. आणि त्यावरील रहदारी पूर्णपणे कार्यक्षम आहे या वस्तुस्थितीवर आधारित संतुलित आहे आणि आम्ही ओव्हरलोड होऊ शकतो.

किंवा, उदाहरणार्थ, बॅकप्लेनसह समस्या उद्भवतात, कारण मॉड्यूलर डिव्हाइसच्या आत हाय-स्पीड सेर्डेस देखील आहेत - ते आत खरोखर जटिल आहे. एकतर अग्रेषित घटकांमधील चिन्हे समक्रमित आहेत किंवा समक्रमित नाहीत. सर्वसाधारणपणे, कोणत्याही उत्पादक मॉड्यूलर डिव्हाइसमध्ये मोठ्या संख्येने घटक असतात, नियम म्हणून, स्वतःमध्ये समान क्लॉस नेटवर्क असते, परंतु त्याचे निदान करणे खूप कठीण असते. अनेकदा स्वतः विक्रेत्यालाही निदान करणे अवघड जाते.

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

सिंगल-चिप उपकरणांचे पुढील छान वैशिष्ट्य म्हणजे ते अधिक चांगले आणि जलद विकसित होतात. त्यांची क्षमताही चांगली असते. जर आपण वर्तुळावर असलेल्या मोठ्या असेंबल्ड स्ट्रक्चर्स घेतल्या, तर त्याच गतीच्या पोर्टसाठी प्रति रॅक युनिटची क्षमता मॉड्यूलर उपकरणांपेक्षा जवळजवळ दुप्पट आहे. एका चिपभोवती तयार केलेली उपकरणे मॉड्यूलरपेक्षा लक्षणीय स्वस्त आहेत आणि कमी ऊर्जा वापरतात.

परंतु, अर्थातच, हे सर्व एका कारणास्तव आहे, त्याचे तोटे देखील आहेत. प्रथम, रेडिक्स मॉड्यूलर उपकरणांपेक्षा जवळजवळ नेहमीच लहान असतो. जर आम्हाला 128 पोर्ट्ससह एका चिपच्या आसपास तयार केलेले डिव्हाइस मिळू शकले, तर आम्हाला आता कोणत्याही अडचणीशिवाय शंभर पोर्टसह मॉड्यूलर मिळू शकेल.

हे अग्रेषित सारण्यांचे लक्षणीय लहान आकार आहे आणि नियम म्हणून, डेटा प्लेन स्केलेबिलिटीशी संबंधित सर्व काही आहे. उथळ बफर. आणि, एक नियम म्हणून, ऐवजी मर्यादित कार्यक्षमता. परंतु असे दिसून आले की जर तुम्हाला हे निर्बंध माहित असतील आणि त्यांना बायपास करण्यासाठी वेळेत काळजी घेतली असेल किंवा त्यांना फक्त विचारात घेतले असेल तर हे इतके भयानक नाही. रॅडिक्स लहान आहे ही वस्तुस्थिती यापुढे 128 च्या रेडिक्स असलेल्या डिव्हाइसेसवर समस्या नाही जी शेवटी अलीकडेच दिसली; आपण मणक्याच्या दोन स्तरांमध्ये तयार करू शकतो. परंतु आमच्यासाठी मनोरंजक असलेल्या दोनपेक्षा लहान काहीही तयार करणे अद्याप अशक्य आहे. एका स्तरासह, खूप लहान क्लस्टर्स प्राप्त होतात. आमच्या पूर्वीच्या डिझाईन्स आणि आवश्यकता अजूनही त्यापेक्षा जास्त आहेत.

खरं तर, जर अचानक समाधान कुठेतरी काठावर असेल, तर मोजमाप करण्याचा मार्ग अजूनही आहे. शेवटचे (किंवा पहिले), सर्वात कमी स्तर जेथे सर्व्हर कनेक्ट केलेले आहेत ते ToR स्विचेस किंवा लीफ स्विचेस आहेत, आम्हाला त्यांच्याशी एक रॅक जोडण्याची आवश्यकता नाही. म्हणून, जर सोल्यूशन अर्ध्याने कमी पडले, तर तुम्ही फक्त खालच्या स्तरावर मोठ्या रेडिक्ससह स्विच वापरण्याचा आणि कनेक्ट करण्याचा विचार करू शकता, उदाहरणार्थ, दोन किंवा तीन रॅक एका स्विचमध्ये. हा देखील एक पर्याय आहे, त्याची किंमत आहे, परंतु ते चांगले कार्य करते आणि जेव्हा आपल्याला आकारापेक्षा दुप्पट पोहोचण्याची आवश्यकता असते तेव्हा एक चांगला उपाय असू शकतो.

थोडक्यात, आम्ही आठ फॅक्टरी लेयर्ससह, दोन स्तरांच्या स्पाइनसह टोपोलॉजी तयार करत आहोत.

भौतिकशास्त्राचे काय होईल? अगदी सोपी गणना. जर आमच्याकडे मणक्याचे दोन स्तर असतील, तर आमच्याकडे स्विचचे फक्त तीन स्तर आहेत आणि आम्ही अपेक्षा करतो की नेटवर्कमध्ये तीन केबल विभाग असतील: सर्व्हरपासून लीफ स्विचेस, स्पाइन 1, स्पाइन 2 पर्यंत. पर्याय जे आम्ही करू शकतो वापरा आहेत - हे ट्विनॅक्स, मल्टीमोड, सिंगल मोड आहेत. आणि येथे आपल्याला कोणती पट्टी उपलब्ध आहे, त्याची किंमत किती असेल, भौतिक परिमाणे काय आहेत, आपण कोणते स्पॅन कव्हर करू शकतो आणि आपण कसे अपग्रेड करू याचा विचार करणे आवश्यक आहे.

खर्चाच्या बाबतीत, सर्वकाही रांगेत केले जाऊ शकते. ट्विनॅक्स सक्रिय ऑप्टिक्सपेक्षा लक्षणीय स्वस्त आहेत, मल्टीमोड ट्रान्सीव्हर्सपेक्षा स्वस्त आहेत, जर तुम्ही ते शेवटपासून प्रति फ्लाइट घेतल्यास, 100-गीगाबिट स्विच पोर्टपेक्षा काहीसे स्वस्त आहेत. आणि, कृपया लक्षात घ्या, सिंगल मोड ऑप्टिक्सपेक्षा त्याची किंमत कमी आहे, कारण ज्या फ्लाइटमध्ये सिंगल मोड आवश्यक आहे, डेटा सेंटरमध्ये अनेक कारणांमुळे CWDM वापरणे अर्थपूर्ण आहे, तर पॅरलल सिंगल मोड (PSM) काम करणे फारसे सोयीचे नाही. यासह, खूप मोठे पॅक फायबर मिळवले जातात आणि जर आम्ही या तंत्रज्ञानावर लक्ष केंद्रित केले, तर आम्हाला अंदाजे खालील किंमत श्रेणीबद्धता मिळते.

आणखी एक टीप: दुर्दैवाने, 100 ते 4x25 मल्टीमोड पोर्ट वेगळे करणे शक्य नाही. SFP28 ट्रान्सीव्हर्सच्या डिझाइन वैशिष्ट्यांमुळे, ते 28 Gbit QSFP100 पेक्षा जास्त स्वस्त नाही. आणि मल्टीमोडसाठी हे वेगळे करणे फार चांगले कार्य करत नाही.

दुसरी मर्यादा अशी आहे की संगणकीय क्लस्टर्सचा आकार आणि सर्व्हरच्या संख्येमुळे आमची डेटा केंद्रे भौतिकदृष्ट्या मोठी आहेत. म्हणजे सिंगलमोडने किमान एक उड्डाण करावे लागेल. पुन्हा, पॉड्सच्या भौतिक आकारामुळे, ट्विनॅक्सचे दोन स्पॅन (तांबे केबल्स) चालवणे शक्य होणार नाही.

परिणामी, जर आम्ही किंमतीसाठी अनुकूल केले आणि या डिझाइनची भूमिती लक्षात घेतली, तर आम्हाला CWDM वापरून ट्विनॅक्सचा एक स्पॅन, मल्टीमोडचा एक स्पॅन आणि सिंगलमोडचा एक स्पॅन मिळेल. हे संभाव्य अपग्रेड मार्ग विचारात घेते.

हे असे दिसते आहे की अलीकडे, आपण कुठे जात आहोत आणि काय शक्य आहे. मल्टीमोड आणि सिंगलमोड दोन्हीसाठी 50-गिगाबिट SerDes कडे कसे जायचे हे किमान स्पष्ट आहे. शिवाय, 400G साठी आता आणि भविष्यात सिंगल-मोड ट्रान्सीव्हर्समध्ये काय आहे ते पाहिल्यास, अनेकदा 50G SerDes इलेक्ट्रिकल बाजूने आले तरीही, 100 Gbps प्रति लेन आधीच ऑप्टिक्सवर जाऊ शकतात. त्यामुळे, 50 वर जाण्याऐवजी, 100 Gigabit SerDes आणि 100 Gbps प्रति लेनमध्ये संक्रमण होण्याची शक्यता आहे, कारण अनेक विक्रेत्यांच्या आश्वासनानुसार, त्यांची उपलब्धता लवकरच अपेक्षित आहे. ज्या कालावधीत 50G SerDes सर्वात वेगवान होते, असे दिसते की, फार मोठा नसेल, कारण 100G SerDes च्या पहिल्या प्रती जवळजवळ पुढच्या वर्षी आणल्या जातील. आणि त्यानंतर काही काळानंतर ते कदाचित वाजवी पैसे असतील.

भौतिकशास्त्राच्या निवडीबद्दल आणखी एक बारकावे. तत्वतः, आम्ही आधीच 400G SerDes वापरून 200 किंवा 50 गिगाबिट पोर्ट वापरू शकतो. परंतु असे दिसून आले की याला फारसा अर्थ नाही, कारण, मी आधी म्हटल्याप्रमाणे, आम्हाला स्विचवर एक मोठा रेडिक्स हवा आहे, कारणास्तव. आम्हाला 128 हवे आहे. आणि जर आमच्याकडे चिपची क्षमता मर्यादित असेल आणि आम्ही लिंकचा वेग वाढवला, तर मूलांक नैसर्गिकरित्या कमी होतो, कोणतेही चमत्कार नाहीत.

आणि आम्ही विमाने वापरून एकूण क्षमता वाढवू शकतो आणि त्यासाठी कोणतेही विशेष खर्च नाहीत; आम्ही विमानांची संख्या जोडू शकतो. आणि जर आम्ही मूलांक गमावला, तर आम्हाला अतिरिक्त स्तर सादर करावा लागेल, म्हणून सध्याच्या परिस्थितीत, प्रति चिप वर्तमान कमाल उपलब्ध क्षमतेसह, असे दिसून आले की 100-गीगाबिट पोर्ट वापरणे अधिक कार्यक्षम आहे, कारण ते आपल्याला परवानगी देतात. मोठा रेडिक्स मिळविण्यासाठी.

पुढील प्रश्न म्हणजे भौतिकशास्त्र कसे आयोजित केले जाते, परंतु केबल पायाभूत सुविधांच्या दृष्टिकोनातून. हे एक मजेदार मार्गाने आयोजित केले आहे की बाहेर वळते. लीफ-स्विच आणि प्रथम-स्तरीय मणक्यांमधील केबलिंग - तेथे बरेच दुवे नाहीत, सर्व काही तुलनेने सोपे आहे. परंतु जर आपण एक विमान घेतले तर आत काय होते की आपल्याला पहिल्या स्तराच्या सर्व मणक्याला दुसऱ्या स्तराच्या सर्व मणक्यांशी जोडणे आवश्यक आहे.

तसेच, नियमानुसार, डेटा सेंटरच्या आत ते कसे दिसावे यासाठी काही इच्छा आहेत. उदाहरणार्थ, आम्हाला केबल्स एका बंडलमध्ये एकत्र करून त्यांना खेचायचे होते जेणेकरून एक उच्च-घनता पॅच पॅनेल संपूर्णपणे एका पॅच पॅनेलमध्ये जाईल, जेणेकरून लांबीच्या बाबतीत प्राणीसंग्रहालय नसेल. आम्ही या समस्येचे निराकरण करण्यात व्यवस्थापित केले. तुम्ही सुरुवातीला तार्किक टोपोलॉजी पाहिल्यास, तुम्ही पाहू शकता की विमाने स्वतंत्र आहेत, प्रत्येक विमान स्वतः तयार केले जाऊ शकते. परंतु जेव्हा आपण असे बंडलिंग जोडतो आणि पॅच पॅनेलमध्ये संपूर्ण पॅच पॅनेल ड्रॅग करू इच्छितो, तेव्हा आपल्याला एका बंडलमध्ये वेगवेगळी विमाने मिसळावी लागतात आणि ते कसे एकत्र केले गेले होते ते पुन्हा पॅक करण्यासाठी ऑप्टिकल क्रॉस-कनेक्शनच्या स्वरूपात मध्यवर्ती रचना सादर करावी लागते. एका सेगमेंटवर, ते दुसऱ्या सेगमेंटवर कसे गोळा केले जातील. याबद्दल धन्यवाद, आम्हाला एक छान वैशिष्ट्य मिळते: सर्व जटिल स्विचिंग रॅकच्या पलीकडे जात नाही. जेव्हा तुम्हाला एखादी गोष्ट खूप मजबूतपणे गुंफायची असते, तेव्हा “प्लेन्स उलगडून दाखवा”, ज्याला कधीकधी क्लोस नेटवर्कमध्ये म्हणतात, ते सर्व एका रॅकमध्ये केंद्रित असते. आमच्याकडे वैयक्तिक दुव्यांपर्यंत, रॅक दरम्यान स्विचिंग, खूप वेगळे केलेले नाही.

केबल इन्फ्रास्ट्रक्चरच्या तार्किक संस्थेच्या दृष्टिकोनातून हे असे दिसते. डावीकडील चित्रात, बहु-रंगीत ब्लॉक्स प्रथम-स्तरीय स्पाइन स्विचचे ब्लॉक्स, प्रत्येकी आठ तुकडे आणि त्यांच्याकडून येणार्‍या केबल्सचे चार बंडल दर्शवितात, जे स्पाइन-2 स्विचेसच्या ब्लॉकमधून येणार्‍या बंडलला जाऊन छेदतात. .

लहान चौकोन छेदनबिंदू दर्शवतात. शीर्षस्थानी डावीकडे अशा प्रत्येक छेदनबिंदूचे ब्रेकडाउन आहे, हे प्रत्यक्षात 512 बाय 512 पोर्ट क्रॉस-कनेक्ट मॉड्यूल आहे जे केबल्स पुन्हा पॅक करते जेणेकरून ते पूर्णपणे एका रॅकमध्ये येतात, जिथे फक्त एक स्पाइन -2 प्लेन आहे. आणि उजवीकडे, या चित्राचे स्कॅन स्पाइन -1 स्तरावरील अनेक पॉड्सच्या संबंधात थोडे अधिक तपशीलवार आहे आणि ते क्रॉस-कनेक्टमध्ये कसे पॅकेज केले जाते, ते स्पाइन -2 स्तरावर कसे येते.

हे असे दिसते. स्पाइन -2 स्टँड (डावीकडे) आणि क्रॉस-कनेक्ट स्टँड अद्याप पूर्णपणे एकत्रित न केलेले. दुर्दैवाने, तेथे पाहण्यासारखे बरेच काही नाही. ही संपूर्ण रचना आत्ता आमच्या एका मोठ्या डेटा सेंटरमध्ये तैनात केली जात आहे ज्याचा विस्तार केला जात आहे. हे काम प्रगतीपथावर आहे, ते अधिक छान दिसेल, ते अधिक चांगले भरले जाईल.

एक महत्त्वाचा प्रश्न: आम्ही तार्किक टोपोलॉजी निवडले आणि भौतिकशास्त्र तयार केले. नियंत्रण विमानाचे काय होईल? ऑपरेटिंग अनुभवावरून हे सर्वज्ञात आहे, असे अनेक अहवाल आहेत की लिंक स्टेट प्रोटोकॉल चांगले आहेत, त्यांच्याबरोबर काम करणे आनंददायक आहे, परंतु, दुर्दैवाने, ते घनतेने जोडलेल्या टोपोलॉजीवर चांगले मोजत नाहीत. आणि यास प्रतिबंध करणारा एक मुख्य घटक आहे - लिंक स्टेट प्रोटोकॉलमध्ये फ्लडिंग कसे कार्य करते. जर तुम्ही फक्त फ्लडिंग अल्गोरिदम घेतला आणि आमचे नेटवर्क कसे संरचित केले आहे ते पाहिल्यास, तुम्ही पाहू शकता की प्रत्येक पायरीवर खूप मोठा फॅनआउट असेल आणि ते फक्त अद्यतनांसह नियंत्रण विमानात भरेल. विशेषत:, अशा टोपोलॉजीज लिंक स्टेट प्रोटोकॉलमधील पारंपारिक फ्लडिंग अल्गोरिदममध्ये फारच खराब मिसळतात.

निवड म्हणजे BGP वापरणे. मोठ्या डेटा सेंटर्समध्ये बीजीपीच्या वापराबद्दल RFC 7938 मध्ये ते योग्यरित्या कसे तयार करावे याचे वर्णन केले आहे. मूलभूत कल्पना सोप्या आहेत: प्रत्येक होस्टसाठी किमान उपसर्गांची संख्या आणि नेटवर्कवर साधारणपणे किमान उपसर्गांची संख्या, शक्य असल्यास एकत्रीकरण वापरा आणि पथ शिकार दडपून टाका. आम्हाला अद्यतनांचे अत्यंत काळजीपूर्वक, अतिशय नियंत्रित वितरण हवे आहे, ज्याला व्हॅली फ्री म्हणतात. अपडेट्स नेटवर्कमधून जात असताना ते एकदाच तैनात केले जावेत अशी आमची इच्छा आहे. जर ते तळाशी उद्भवले तर ते वर जातात, एकापेक्षा जास्त वेळा उलगडत नाहीत. झिगझॅग नसावेत. Zigzags खूप वाईट आहेत.

हे करण्यासाठी, आम्ही अंतर्निहित BGP यंत्रणा वापरण्यासाठी पुरेसे सोपे डिझाइन वापरतो. म्हणजेच, आम्ही लिंक लोकलवर चालणारे eBGP वापरतो आणि स्वायत्त प्रणाली खालीलप्रमाणे नियुक्त केल्या आहेत: ToR वर एक स्वायत्त प्रणाली, एका पॉडच्या स्पाइन -1 स्विचच्या संपूर्ण ब्लॉकवर एक स्वायत्त प्रणाली आणि संपूर्ण शीर्षस्थानी एक सामान्य स्वायत्त प्रणाली फॅब्रिक च्या. हे पाहणे आणि पाहणे कठीण नाही की BGP चे सामान्य वर्तन देखील आम्हाला पाहिजे असलेल्या अद्यतनांचे वितरण देते.

साहजिकच, अॅड्रेसिंग आणि अॅड्रेस एग्रीगेशन डिझाइन केले पाहिजे जेणेकरून ते राउटिंग तयार करण्याच्या पद्धतीशी सुसंगत असेल, जेणेकरून ते कंट्रोल प्लेनची स्थिरता सुनिश्चित करेल. ट्रान्सपोर्टमधील एल 3 अॅड्रेसिंग टोपोलॉजीशी जोडलेले आहे, कारण त्याशिवाय एकत्रीकरण साध्य करणे अशक्य आहे; त्याशिवाय, वैयक्तिक पत्ते रूटिंग सिस्टममध्ये रेंगाळतील. आणि आणखी एक गोष्ट अशी आहे की एकत्रीकरण, दुर्दैवाने, मल्टी-पथमध्ये फार चांगले मिसळत नाही, कारण जेव्हा आपल्याकडे मल्टी-पथ असतो आणि आपल्याकडे एकत्रीकरण असते तेव्हा सर्व काही ठीक असते, जेव्हा संपूर्ण नेटवर्क निरोगी असते, तेव्हा त्यात कोणतेही अपयश नसतात. दुर्दैवाने, नेटवर्कमध्ये अपयश दिसू लागताच आणि टोपोलॉजीची सममिती गमावली की, आम्ही त्या बिंदूवर येऊ शकतो जिथून युनिटची घोषणा केली गेली होती, जिथून पुढे जायचे आहे तिथून आम्ही पुढे जाऊ शकत नाही. म्हणून, जेथे पुढील मल्टी-पाथ नाही तेथे एकत्रित करणे सर्वोत्तम आहे, आमच्या बाबतीत हे ToR स्विच आहेत.

खरं तर, एकत्रित करणे शक्य आहे, परंतु काळजीपूर्वक. नेटवर्क बिघाड झाल्यावर आम्ही नियंत्रित डिसॅग्रिगेशन करू शकलो तर. परंतु हे खूप कठीण काम आहे, आम्हाला हे करणे शक्य आहे का, अतिरिक्त ऑटोमेशन जोडणे शक्य आहे का, आणि इच्छित वर्तन मिळविण्यासाठी BGP ला योग्यरित्या किक करणार्‍या मर्यादित राज्य मशीन्स जोडणे शक्य आहे की नाही याबद्दल आम्हाला आश्चर्य वाटले. दुर्दैवाने, कॉर्नर केसेसवर प्रक्रिया करणे अत्यंत गैर-स्पष्ट आणि गुंतागुंतीचे आहे, आणि हे कार्य BGP ला बाह्य संलग्नक जोडून चांगले सोडवले जात नाही.

या संदर्भात अतिशय मनोरंजक कार्य RIFT प्रोटोकॉलच्या चौकटीत केले गेले आहे, ज्याची पुढील अहवालात चर्चा केली जाईल.

दुसरी महत्त्वाची गोष्ट म्हणजे डेटा प्लेन दाट टोपोलॉजीजमध्ये कसे मोजतात, जिथे आपल्याकडे मोठ्या संख्येने पर्यायी मार्ग आहेत. या प्रकरणात, अनेक अतिरिक्त डेटा संरचना वापरल्या जातात: ECMP गट, जे यामधून नेक्स्ट हॉप गटांचे वर्णन करतात.

सामान्यपणे कार्यरत नेटवर्कमध्ये, अपयशाशिवाय, जेव्हा आपण Clos टोपोलॉजी वर जातो, तेव्हा फक्त एक गट वापरणे पुरेसे असते, कारण स्थानिक नसलेली प्रत्येक गोष्ट डीफॉल्टनुसार वर्णन केली जाते, आपण वर जाऊ शकतो. जेव्हा आपण वरपासून खालपर्यंत दक्षिणेकडे जातो, तेव्हा सर्व मार्ग ECMP नसतात, ते एकेरी मार्ग आहेत. सर्व काही ठीक आहे. अडचण अशी आहे, आणि क्लासिक क्लोस टोपोलॉजीचे वैशिष्ठ्य हे आहे की आपण फॅब्रिकच्या शीर्षस्थानी, कोणत्याही घटकाकडे पाहिल्यास, खाली असलेल्या कोणत्याही घटकाकडे एकच मार्ग आहे. या मार्गावर अपयश आल्यास, कारखान्याच्या शीर्षस्थानी हा विशिष्ट घटक तुटलेल्या मार्गाच्या मागे असलेल्या उपसर्गांसाठी तंतोतंत अवैध ठरतो. परंतु बाकीच्यांसाठी ते वैध आहे आणि आम्हाला ECMP गटांचे विश्लेषण करावे लागेल आणि नवीन राज्य सादर करावे लागेल.

आधुनिक उपकरणांवर डेटा प्लेन स्केलेबिलिटी कशी दिसते? आम्ही LPM (सर्वात लांब उपसर्ग जुळणी) केल्यास, सर्वकाही चांगले आहे, 100k उपसर्ग. जर आपण नेक्स्ट हॉप गटांबद्दल बोलत आहोत, तर सर्वकाही वाईट आहे, 2-4 हजार. जर आपण एखाद्या टेबलबद्दल बोलत आहोत ज्यामध्ये नेक्स्ट हॉप्स (किंवा संलग्नता) चे वर्णन आहे, तर हे 16k ते 64k पर्यंत आहे. आणि ही समस्या बनू शकते. आणि येथे आम्ही एका मनोरंजक विषयाकडे आलो: डेटा सेंटरमध्ये एमपीएलएसचे काय झाले? तत्वतः, आम्हाला ते करायचे होते.

दोन गोष्टी घडल्या. आम्ही होस्टवर मायक्रो-सेगमेंटेशन केले; आम्हाला यापुढे नेटवर्कवर ते करण्याची आवश्यकता नाही. वेगवेगळ्या विक्रेत्यांच्या समर्थनासह आणि त्याहूनही अधिक MPLS सह पांढर्‍या बॉक्सवर खुल्या अंमलबजावणीसह हे फार चांगले नव्हते. आणि MPLS, किमान त्याची पारंपारिक अंमलबजावणी, दुर्दैवाने, ECMP सह खूप खराबपणे एकत्र करते. आणि म्हणूनच.

IP साठी ECMP फॉरवर्डिंग स्ट्रक्चर असे दिसते. मोठ्या संख्येने उपसर्ग समान गट आणि समान नेक्स्ट हॉप्स ब्लॉक वापरू शकतात (किंवा समीप, वेगवेगळ्या उपकरणांसाठी वेगवेगळ्या दस्तऐवजीकरणात याला वेगळ्या प्रकारे म्हटले जाऊ शकते). मुद्दा असा आहे की हे आउटगोइंग पोर्ट म्हणून वर्णन केले आहे आणि योग्य नेक्स्ट हॉपवर जाण्यासाठी MAC पत्ता काय पुन्हा लिहावा. IP साठी सर्वकाही सोपे दिसते, आपण समान गटासाठी, समान नेक्स्ट हॉप्स ब्लॉकसाठी खूप मोठ्या संख्येने उपसर्ग वापरू शकता.

क्लासिक एमपीएलएस आर्किटेक्चर सूचित करते की, आउटगोइंग इंटरफेसवर अवलंबून, लेबल वेगवेगळ्या मूल्यांवर पुन्हा लिहिले जाऊ शकते. म्हणून, प्रत्येक इनपुट लेबलसाठी आम्हाला एक गट आणि नेक्स्ट हॉप्स ब्लॉक ठेवणे आवश्यक आहे. आणि हे, अरेरे, प्रमाण नाही.

हे पाहणे सोपे आहे की आमच्या डिझाइनमध्ये आम्हाला सुमारे 4000 ToR स्विचेसची आवश्यकता आहे, जर आपण स्पाइन-64 पासून स्पाइन-1 कडे गेलो तर जास्तीत जास्त रुंदी 2 ECMP पथ होती. आम्ही केवळ ECMP गटांच्या एका टेबलमध्ये प्रवेश करतो, जर ToR सह फक्त एक उपसर्ग निघून गेला आणि आम्ही नेक्स्ट हॉप्स टेबलमध्ये अजिबात प्रवेश करत नाही.

हे सर्व निराशाजनक नाही, कारण सेगमेंट राउटिंग सारख्या आर्किटेक्चरमध्ये जागतिक लेबले असतात. औपचारिकपणे, हे सर्व नेक्स्ट हॉप्स ब्लॉक पुन्हा कोसळणे शक्य होईल. हे करण्यासाठी, तुम्हाला वाइल्ड कार्ड प्रकारच्या ऑपरेशनची आवश्यकता आहे: एक लेबल घ्या आणि विशिष्ट मूल्याशिवाय ते त्याच कार्डावर पुन्हा लिहा. परंतु दुर्दैवाने, उपलब्ध अंमलबजावणीमध्ये हे फारसे उपस्थित नाही.

आणि शेवटी, आम्हाला डेटा सेंटरवर बाह्य रहदारी आणण्याची आवश्यकता आहे. ते कसे करायचे? पूर्वी, वरून क्लोस नेटवर्कमध्ये रहदारी आणली गेली होती. म्हणजेच, फॅब्रिकच्या शीर्षस्थानी सर्व उपकरणांशी कनेक्ट केलेले एज राउटर होते. हे द्रावण लहान ते मध्यम आकारात चांगले कार्य करते. दुर्दैवाने, अशा प्रकारे संपूर्ण नेटवर्कवर रहदारी सममितीयपणे पाठवण्यासाठी, आम्हाला एकाच वेळी सर्व फॅब्रिक घटकांच्या शीर्षस्थानी पोहोचणे आवश्यक आहे आणि जेव्हा त्यापैकी शंभराहून अधिक असतील, तेव्हा असे दिसून आले की आम्हाला मोठ्या रेडिक्सची देखील आवश्यकता आहे. किनारी राउटर. सर्वसाधारणपणे, यासाठी पैसे खर्च होतात, कारण एज राउटर अधिक कार्यक्षम आहेत, त्यांच्यावरील पोर्ट अधिक महाग असतील आणि डिझाइन फार सुंदर नाही.

दुसरा पर्याय म्हणजे अशी वाहतूक खालून सुरू करणे. हे सत्यापित करणे सोपे आहे की Clos टोपोलॉजी अशा प्रकारे तयार केली गेली आहे की खालून येणारी रहदारी, म्हणजेच ToR बाजूने, संपूर्ण नेटवर्क लोड करून, संपूर्ण टॉप ऑफ फॅब्रिकमध्ये दोन पुनरावृत्तींमध्ये समान रीतीने वितरीत केली जाते. म्हणून, आम्ही एक विशेष प्रकारचा पॉड, एज पॉड सादर करतो, जो बाह्य कनेक्टिव्हिटी प्रदान करतो.

अजून एक पर्याय आहे. उदाहरणार्थ, फेसबुक हेच करते. ते त्याला फॅब्रिक एग्रीगेटर किंवा एचजीआरआयडी म्हणतात. एकाधिक डेटा केंद्रांना जोडण्यासाठी अतिरिक्त स्पाइन लेव्हल सुरू करण्यात येत आहे. आमच्याकडे इंटरफेसमध्ये अतिरिक्त कार्ये किंवा एन्कॅप्सुलेशन बदल नसल्यास हे डिझाइन शक्य आहे. ते अतिरिक्त स्पर्श बिंदू असल्यास, ते कठीण आहे. सामान्यतः, डेटा सेंटरच्या विविध भागांना वेगळे करणारी अधिक कार्ये आणि एक प्रकारचा पडदा असतो. अशी पडदा मोठी करण्यात काही अर्थ नाही, परंतु जर काही कारणास्तव त्याची खरोखर गरज असेल, तर ते काढून टाकण्याची शक्यता विचारात घेणे, ते शक्य तितके रुंद करणे आणि ते यजमानांकडे हस्तांतरित करणे अर्थपूर्ण आहे. हे अनेक क्लाउड ऑपरेटरद्वारे केले जाते, उदाहरणार्थ. त्यांच्याकडे आच्छादन आहेत, ते यजमानांपासून सुरू होतात.

आपण कोणत्या विकासाच्या संधी पाहतो? सर्व प्रथम, CI/CD पाइपलाइनसाठी समर्थन सुधारणे. आम्ही ज्या प्रकारे चाचणी घेतो आणि ज्या पद्धतीने उड्डाण करतो त्याची चाचणी घ्यायची आहे. हे फार चांगले कार्य करत नाही, कारण पायाभूत सुविधा मोठ्या आहेत आणि चाचण्यांसाठी ते डुप्लिकेट करणे अशक्य आहे. उत्पादन पायाभूत सुविधांमध्ये चाचणी घटक न टाकता ते कसे सादर करावे हे तुम्हाला समजून घेणे आवश्यक आहे.

उत्तम इन्स्ट्रुमेंटेशन आणि चांगले निरीक्षण जवळजवळ कधीही अनावश्यक नसते. संपूर्ण प्रश्न प्रयत्न आणि परतावा यांचा समतोल आहे. जर तुम्ही ते वाजवी प्रयत्नाने जोडू शकलात तर खूप चांगले.

नेटवर्क उपकरणांसाठी ऑपरेटिंग सिस्टम उघडा. उत्तम प्रोटोकॉल आणि उत्तम राउटिंग प्रणाली, जसे की RIFT. चांगल्या कंजेशन कंट्रोल स्कीम्सचा वापर करण्यासाठी आणि क्लस्टरमध्ये RDMA समर्थनाचा परिचय, किमान काही ठिकाणी, संशोधन देखील आवश्यक आहे.

भविष्याकडे पाहताना, आम्हाला प्रगत टोपोलॉजीज आणि शक्यतो कमी ओव्हरहेड वापरणाऱ्या नेटवर्कची आवश्यकता आहे. ताज्या गोष्टींपैकी, एचपीसी क्रे स्लिंगशॉटसाठी फॅब्रिक तंत्रज्ञानाबद्दल अलीकडेच प्रकाशने आली आहेत, जी कमोडिटी इथरनेटवर आधारित आहे, परंतु बरेच लहान शीर्षलेख वापरण्याच्या पर्यायासह. परिणामी, ओव्हरहेड कमी होते.

सर्व काही शक्य तितके सोपे ठेवले पाहिजे, परंतु सोपे नाही. जटिलता स्केलेबिलिटीचा शत्रू आहे. साधेपणा आणि नियमित रचना हे आमचे मित्र आहेत. आपण कुठेतरी स्केल आउट करू शकत असल्यास, ते करा. आणि सर्वसाधारणपणे, आता नेटवर्क तंत्रज्ञानामध्ये सामील होणे चांगले आहे. खूप मनोरंजक गोष्टी चालू आहेत. धन्यवाद.

स्त्रोत: www.habr.com