एक नेटवर्क जे स्वतःला बरे करते: फ्लो लेबलची जादू आणि लिनक्स कर्नलभोवती गुप्तहेर. यांडेक्स अहवाल

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

- सुरुवातीला, ज्यांना आधुनिक DC ची रचना माहित नसेल त्यांच्यासाठी मी एक विस्तृत परिचय देईन.


अनेक नेटवर्क अभियंत्यांसाठी, डेटा सेंटर नेटवर्क अर्थातच, रॅकमधील स्विचसह, टीओआरसह सुरू होते. ToR मध्ये सहसा दोन प्रकारचे दुवे असतात. लहान सर्व्हरवर जातात, इतर - त्यापैकी N पट जास्त आहेत - पहिल्या स्तराच्या मणक्याकडे जातात, म्हणजेच त्याच्या अपलिंककडे जातात. अपलिंक सहसा समान मानले जातात, आणि अपलिंक्समधील रहदारी 5-ट्यूपलच्या हॅशच्या आधारे संतुलित केली जाते, ज्यामध्ये प्रोटो, src_ip, dst_ip, src_port, dst_port यांचा समावेश होतो. येथे आश्चर्य नाही.


पुढे, प्लॅन आर्किटेक्चर कसे दिसते? पहिल्या लेव्हलचे स्पाइन एकमेकांशी जोडलेले नसतात, परंतु सुपरस्पाइन्सद्वारे जोडलेले असतात. अक्षर X सुपरस्पाईन्ससाठी जबाबदार असेल; ते जवळजवळ क्रॉस-कनेक्टसारखे आहे.


आणि हे स्पष्ट आहे की, दुसरीकडे, टोरी पहिल्या स्तराच्या सर्व मणक्यांशी जोडलेले आहेत. या चित्रात काय महत्त्वाचे आहे? जर आमचा रॅकच्या आत परस्परसंवाद असेल, तर परस्परसंवाद, अर्थातच, टीओआर द्वारे जातो. जर मॉड्युलच्या आत परस्परसंवाद घडला, तर संवाद पहिल्या स्तरावरील मणक्यांद्वारे होतो. जर परस्परसंवाद इंटरमॉड्युलर असेल - जसे की येथे, ToR 1 आणि ToR 2 - तर परस्परसंवाद प्रथम आणि द्वितीय दोन्ही स्तरांच्या मणक्यांमधून जाईल.


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


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


आठ विमाने आहेत, प्रत्येक विमानात 32 सुपरस्पाइन आहेत. परिणामी, असे दिसून आले की मॉड्यूलमध्ये आठ मार्ग आहेत आणि इंटरमॉड्यूल परस्परसंवादासह त्यापैकी 256 आधीच आहेत.

म्हणजेच, जर आपण कूकबुक विकसित करत आहोत, दोष-सहिष्णु डेटा सेंटर कसे तयार करायचे ते शिकण्याचा प्रयत्न करत आहोत जे स्वतःला बरे करतात, तर प्लॅनर आर्किटेक्चर हा योग्य पर्याय आहे. हे स्केलिंग समस्येचे निराकरण करते आणि सिद्धांततः ते सोपे आहे. अनेक स्वतंत्र मार्ग आहेत. प्रश्न उरतो: अशी वास्तुकला अपयशातून कशी टिकते? विविध अपयश आहेत. आणि आम्ही आता यावर चर्चा करू.


आमच्या सुपरस्पाइन्सपैकी एकाला “आजारी” होऊ द्या. इथे मी टू-प्लेन आर्किटेक्चरमध्ये परतलो. आम्ही हे उदाहरण म्हणून चिकटून राहू कारण कमी हलणाऱ्या भागांसह काय चालले आहे हे पाहणे सोपे होईल. X11 आजारी होऊ द्या. डेटा सेंटरमध्ये राहणाऱ्या सेवांवर याचा कसा परिणाम होईल? अपयश प्रत्यक्षात कसे दिसते यावर बरेच काही अवलंबून असते.


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


जर आपले सतत नुकसान होत असेल आणि ऑटोमेशन समस्या लक्षात घेत नसेल तर एक वाईट परिस्थिती आहे. याचा अनुप्रयोगावर कसा परिणाम होतो हे समजून घेण्यासाठी, आम्हाला TCP कसे कार्य करते यावर चर्चा करण्यासाठी थोडा वेळ द्यावा लागेल.


मला आशा आहे की मी या माहितीने कोणालाही धक्का बसणार नाही: TCP हा ट्रान्समिशन पुष्टीकरण प्रोटोकॉल आहे. म्हणजेच, सर्वात सोप्या प्रकरणात, प्रेषक दोन पॅकेट पाठवतो आणि त्यावर एकत्रित ack प्राप्त करतो: "मला दोन पॅकेट मिळाले आहेत."


त्यानंतर, तो आणखी दोन पॅकेट पाठवेल आणि परिस्थिती पुन्हा होईल. काही सरलीकरणासाठी मी आगाऊ माफी मागतो. विंडो (फ्लाइटमधील पॅकेटची संख्या) दोन असल्यास ही परिस्थिती योग्य आहे. अर्थात, सर्वसाधारण बाबतीत असे होईलच असे नाही. परंतु विंडोचा आकार पॅकेट फॉरवर्डिंग संदर्भावर परिणाम करत नाही.


आम्ही पॅकेट 3 गमावल्यास काय होईल? या प्रकरणात, प्राप्तकर्त्याला 1, 2 आणि 4 पॅकेट प्राप्त होतील. आणि तो SACK पर्याय वापरून प्रेषकाला स्पष्टपणे सांगेल: "तुम्हाला माहिती आहे, तीन आले, परंतु मधले हरवले." तो म्हणतो, "Ack 2, SACK 4."


या क्षणी, प्रेषक कोणत्याही समस्येशिवाय हरवलेल्या पॅकेटची पुनरावृत्ती करतो.


परंतु जर खिडकीतील शेवटचे पॅकेट हरवले असेल तर परिस्थिती पूर्णपणे भिन्न दिसेल.

प्राप्तकर्त्याला पहिले तीन पॅकेट मिळतात आणि सर्व प्रथम प्रतीक्षा करणे सुरू होते. लिनक्स कर्नलच्या TCP स्टॅकमधील काही ऑप्टिमायझेशन्सबद्दल धन्यवाद, जोपर्यंत फ्लॅग स्पष्टपणे सूचित करत नाहीत की ते शेवटचे पॅकेट आहे किंवा तत्सम काहीतरी आहे तोपर्यंत ते जोडलेल्या पॅकेटची प्रतीक्षा करेल. विलंबित ACK कालबाह्य होईपर्यंत ते प्रतीक्षा करेल आणि नंतर पहिल्या तीन पॅकेट्सवर पोचपावती पाठवेल. पण आता प्रेषक वाट पाहतील. चौथे पॅकेज हरवले आहे की येणार आहे हे त्याला माहीत नाही. आणि नेटवर्क ओव्हरलोड होऊ नये म्हणून, ते पॅकेट हरवल्याचे स्पष्ट संकेत मिळण्याची किंवा RTO कालबाह्य होण्याची प्रतीक्षा करण्याचा प्रयत्न करेल.


आरटीओ कालबाह्य म्हणजे काय? ही TCP स्टॅक आणि काही स्थिरांकाद्वारे गणना केलेली RTT ची कमाल आहे. हे कोणत्या प्रकारचे स्थिर आहे, आपण आता चर्चा करू.


पण महत्त्वाची गोष्ट म्हणजे जर आपण पुन्हा अशुभ झालो आणि चौथे पॅकेट पुन्हा हरवले तर आरटीओ दुप्पट होते. म्हणजेच, प्रत्येक अयशस्वी प्रयत्न म्हणजे टाइमआउट दुप्पट करणे.


आता हा आधार काय समान आहे ते पाहू. डीफॉल्टनुसार, किमान RTO 200 ms आहे. डेटा पॅकेजेससाठी हे किमान आरटीओ आहे. SYN पॅकेटसाठी ते वेगळे आहे, 1 सेकंद. तुम्ही बघू शकता, पॅकेट्स पुन्हा पाठवण्याचा पहिला प्रयत्न देखील डेटा सेंटरमधील RTT पेक्षा 100 पट जास्त वेळ घेईल.


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


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


दोन क्लासिक उपाय आहेत जे एकमेकांना पूरक आहेत. पहिली सेवा आहे जी पेंढा घालण्याचा प्रयत्न करत आहेत आणि याप्रमाणे समस्या सोडवतात: “चला TCP स्टॅकमध्ये काहीतरी बदल करूया. अंतर्गत आरोग्य तपासणीसह अनुप्रयोग स्तरावर किंवा दीर्घकाळ टिकणारी TCP सत्रे कालबाह्य करूया.” समस्या अशी आहे की असे उपाय: अ) अजिबात मोजू नका; b) अतिशय खराब तपासले जातात. म्हणजेच, जरी सेवेने चुकून TCP स्टॅक अशा प्रकारे कॉन्फिगर केले की ते अधिक चांगले होईल, प्रथम, ते सर्व ऍप्लिकेशन्स आणि सर्व डेटा सेंटरसाठी लागू होण्याची शक्यता नाही आणि दुसरे म्हणजे, बहुधा, ते पूर्ण झाले आहे हे समजणार नाही. योग्यरित्या, आणि काय नाही. म्हणजेच, ते कार्य करते, परंतु ते खराब कार्य करते आणि स्केल करत नाही. आणि जर नेटवर्कची समस्या असेल तर त्याला जबाबदार कोण? अर्थात एनओसी. NOC काय करते?

अनेक सेवांचा असा विश्वास आहे की एनओसीच्या कामात असे काहीतरी घडते. पण खरे सांगायचे तर एवढेच नाही.


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


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

पण येथे एक सूक्ष्मता आहे. ते काय आहे हे समजून घेण्यासाठी आपल्याला थ्रेड्स कसे स्थापित केले जातात ते पहावे लागेल.


थ्रेड्स अनुक्रमे स्थापित केले जातात. प्रथम थ्रेड प्रथम स्थापित केला आहे. त्यानंतरचे थ्रेड त्या थ्रेडमध्ये आधीच मान्य केलेल्या कुकीचा वापर करून सेट केले जातात. आणि येथे समस्या आहे.


समस्या अशी आहे की जर पहिला धागा स्वतःला स्थापित करत नसेल तर दुसरा आणि तिसरा धागा कधीच उद्भवणार नाही. म्हणजेच, मल्टीपाथ 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 मध्ये, त्याच आदरणीय अभियंत्याकडून नवीन पॅच येतो. तो खूप मनोरंजक आहे. हे खालील सांगते - नकारात्मक राउटिंग इव्हेंटच्या बाबतीत आम्ही हॅश यादृच्छिक करू. नकारात्मक राउटिंग इव्हेंट म्हणजे काय? हा आरटीओ आहे ज्याची आपण आधी चर्चा केली आहे, म्हणजे खिडकीची शेपटी हरवणे ही एक घटना आहे जी खरोखर नकारात्मक आहे. हे खरे आहे, असा अंदाज लावणे तुलनेने कठीण आहे.

2016, आणखी एक प्रतिष्ठित कंपनी, देखील मोठी. हे शेवटचे क्रॅचेस वेगळे करते आणि असे बनवते की हॅश, जे आम्ही पूर्वी यादृच्छिक केले होते, आता प्रत्येक SYN रीट्रांसमिशनसाठी आणि प्रत्येक RTO कालबाह्य झाल्यानंतर बदलते. आणि या पत्रात, प्रथम आणि शेवटच्या वेळी, अंतिम उद्दिष्ट सांगितले आहे - तोटा किंवा चॅनेलची गर्दी झाल्यास रहदारीमध्ये हळूवारपणे पुन्हा मार्ग काढण्याची आणि एकाधिक मार्ग वापरण्याची क्षमता आहे याची खात्री करणे. अर्थात, यानंतर बरीच प्रकाशने होती, आपण ती सहजपणे शोधू शकता.

नाही तरी, तुम्ही करू शकत नाही, कारण या विषयावर एकही प्रकाशन झालेले नाही. पण आम्हाला माहित आहे!

आणि काय केले गेले हे तुम्हाला पूर्णपणे समजत नसल्यास, मी तुम्हाला आता सांगेन.


लिनक्स कर्नलमध्ये काय केले गेले, कोणती कार्यक्षमता जोडली गेली? प्रत्येक RTO इव्हेंटनंतर txhash यादृच्छिक मूल्यात बदलते. हा रूटिंगचा अत्यंत नकारात्मक परिणाम आहे. हॅश या txhash वर अवलंबून असते आणि फ्लो लेबल skb हॅशवर अवलंबून असते. येथे फंक्शन्सवर काही गणना आहेत; सर्व तपशील एका स्लाइडवर ठेवता येत नाहीत. जर कोणाला उत्सुकता असेल, तर तुम्ही कर्नल कोडमध्ये जाऊन तपासू शकता.

येथे काय महत्वाचे आहे? प्रत्येक RTO नंतर फ्लो लेबल फील्डचे मूल्य यादृच्छिक संख्येमध्ये बदलते. याचा आमच्या दुर्दैवी TCP प्रवाहावर कसा परिणाम होतो?


SACK आढळल्यास, काहीही बदलत नाही कारण आम्ही ज्ञात हरवलेले पॅकेट पुन्हा पाठवण्याचा प्रयत्न करत आहोत. अजून तरी छान आहे.


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


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


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


खरे आहे, SYN_RTO सह सर्वकाही काहीसे वाईट आहे. हे नैसर्गिकरित्या खाली खिळले आहे. कर्नलचे निश्चित मूल्य 1 सेकंद आहे, आणि तेच आहे. तुम्ही वापरकर्त्याच्या जागेवरून तिथे पोहोचू शकत नाही. एकच मार्ग आहे.


eBPF बचावासाठी येतो. सोप्या भाषेत सांगायचे तर, हे छोटे सी प्रोग्राम आहेत. ते कर्नल स्टॅक आणि टीसीपी स्टॅकच्या अंमलबजावणीमध्ये वेगवेगळ्या ठिकाणी हुकमध्ये घातले जाऊ शकतात, ज्याद्वारे तुम्ही खूप मोठ्या प्रमाणात सेटिंग्ज बदलू शकता. सर्वसाधारणपणे, 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 मध्ये बदलतो. तेच काम अधिक शोभिवंतपणे करता येते. पण हे साधे उदाहरण दाखवते की हे अ) शक्य आहे; ब) तुलनेने सोपे.

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


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


तुम्ही इथे काय करू शकता? तुमच्या नियंत्रित वातावरणात, जेथे तुम्ही फ्लो लेबल बॅलन्सिंग सक्षम करता, तुम्हाला कोणत्याही कास्ट सर्व्हरमध्ये प्रवेश करताना फ्लो लेबलचे मूल्य रेकॉर्ड करणे आवश्यक आहे. समान eBPF प्रोग्रामद्वारे हे करणे हा सर्वात सोपा मार्ग आहे. परंतु येथे एक अतिशय महत्त्वाचा मुद्दा आहे - जर तुम्ही डेटा सेंटर नेटवर्क चालवत नाही, परंतु टेलिकॉम ऑपरेटर असाल तर काय करावे? ही तुमचीही समस्या आहे: जुनिपर आणि अरिस्ताच्या काही आवृत्त्यांपासून सुरुवात करून, ते त्यांच्या हॅश फंक्शन्समध्ये डीफॉल्टनुसार फ्लो लेबल समाविष्ट करतात - स्पष्टपणे, माझ्यासाठी अस्पष्ट कारणास्तव. यामुळे तुम्ही तुमच्या नेटवर्कमधून जाणार्‍या वापरकर्त्यांकडून TCP कनेक्शन्स सोडू शकता. म्हणून मी येथे आपल्या राउटर सेटिंग्ज तपासण्याची शिफारस करतो.

एक ना एक मार्ग, मला असे वाटते की आपण प्रयोगांकडे जाण्यास तयार आहोत.


जेव्हा आम्ही ToR वर फ्लो लेबल सक्षम केले, eBPF एजंट तयार केला, जो आता यजमानांवर राहतो, तेव्हा आम्ही पुढील मोठ्या अपयशाची वाट न पाहता नियंत्रित स्फोट घडवण्याचा निर्णय घेतला. आम्ही ToR घेतले, ज्यात चार अपलिंक्स आहेत आणि त्यापैकी एकावर ड्रॉप्स सेट केले. त्यांनी एक नियम काढला आणि म्हणाले - आता तुम्ही सर्व पॅकेट गमावत आहात. जसे आपण डावीकडे पाहू शकता, आमच्याकडे प्रति-पॅकेट निरीक्षण आहे, जे 75% पर्यंत घसरले आहे, म्हणजेच 25% पॅकेट हरवले आहेत. उजवीकडे या ToR च्या मागे राहणाऱ्या सेवांचे आलेख आहेत. मूलत:, हे रॅकमधील सर्व्हरसह इंटरफेसचे रहदारी आलेख आहेत. जसे आपण पाहू शकता, ते आणखी कमी बुडले. ते कमी का झाले - 25% ने नाही, परंतु काही प्रकरणांमध्ये 3-4 वेळा? TCP कनेक्शन अशुभ असल्यास, ते तुटलेल्या जंक्शनमधून पोहोचण्याचा प्रयत्न करत राहते. DC मधील सेवेच्या वैशिष्ट्यपूर्ण वर्तनामुळे हे वाढले आहे - एका वापरकर्त्याच्या विनंतीसाठी, अंतर्गत सेवांसाठी N विनंत्या व्युत्पन्न केल्या जातात आणि प्रतिसाद वापरकर्त्याकडे जाईल जेव्हा सर्व डेटा स्रोत प्रतिसाद देतात किंवा जेव्हा अनुप्रयोगात कालबाह्य होते. स्तर, जे अद्याप कॉन्फिगर करणे आवश्यक आहे. म्हणजेच, सर्वकाही खूप, खूप वाईट आहे.


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

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

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

नेटवर्क अभियंत्यांनी संकल्पनात्मक बदल घडवून आणणे आवश्यक आहे: नेटवर्कची सुरुवात ToR ने होत नाही, नेटवर्क उपकरणाने नाही तर होस्टने होते. आरटीओ बदलण्यासाठी आणि कोणत्याही कास्ट सेवांसाठी फ्लो लेबल फिक्स करण्यासाठी आम्ही eBPF कसे वापरतो हे एक अतिशय उल्लेखनीय उदाहरण आहे.

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

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