संपूर्ण नेटवर्क ढूँढना: ओपनफ़्लो और ऑल-ऑल-ऑल

नमस्कार प्रिय पाठकों,

इस पोस्ट में हम क्लाउड इंफ्रास्ट्रक्चर के लिए सही नेटवर्क समाधान के लिए हमारी खोज के बारे में बात करेंगे और हमने ओपनफ्लो के साथ रहने का फैसला क्यों किया।

परिचय

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

• विरोधी स्पूफिंग,
• एक निजी नेटवर्क खंड का आवंटन,
• बाहरी प्रभावों को कम करने के लिए सार्वजनिक क्षेत्र को छानना।

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

ट्रैफ़िक अलगाव

• OpenVSwitch में iptables / ebtables या स्थिर नियमों के साथ एंटी-स्पूफिंग: सबसे सस्ता समाधान, लेकिन व्यवहार में असुविधाजनक - यदि लिक्विड में nwfilter तंत्र का उपयोग करके linux ब्रिज नियमों का निर्माण किया जाता है और जब वर्चुअल मशीन शुरू होती है, तो स्वचालित रूप से तंग हो जाता है, जब ovs के लिए आपको शुरुआती समय को ट्रैक करना होगा और जांच करनी होगी। या स्विच में संबंधित नियमों को अपडेट करें। किसी पते को जोड़ना या हटाना या वर्चुअल मशीन को स्थानांतरित करना, दोनों मामलों में एक गैर-तुच्छ कार्य में बदल जाता है, जिसे आर्केस्ट्रा के तर्क में स्थानांतरित कर दिया गया है। सार्वजनिक उपयोग के लिए हमारी सेवा शुरू करने के समय, हमने nwfilter [ 1 ] का उपयोग किया, लेकिन संपूर्ण रूप से समाधान के अपर्याप्त लचीलेपन के कारण OpenFlow 1.0 पर स्विच करने के लिए मजबूर किया गया। यह होस्ट नेटवर्क स्टैक (macvtap / vf) के आसपास काम करने वाली प्रौद्योगिकियों के लिए नेटलिंक का उपयोग करके आउटगोइंग ट्रैफ़िक को फ़िल्टर करने के बजाय एक अधिक विवादास्पद विधि का उल्लेख करने योग्य है, जो उच्च वाणिज्यिक मांग के बावजूद, कर्नेल में स्वीकार नहीं किया गया था।
  
• वर्चुअल मशीन पोर्ट को वर्चुअल मशीन इंटरफेस से सीधे ट्रैफिक टनलिंग मेकेनिज्म में से एक का उपयोग करके पोर्ट रैक-स्विच (TOR स्विच) में नियमों का उपयोग करते हुए एंटी-स्पूफिंग। इस तरह के समाधान के फायदे के रूप में, कोई स्विच == पर तर्क के ध्यान को ध्यान में रख सकता है और कंप्यूटिंग नोड्स के सॉफ्टवेयर स्विच पर इसके "प्रसार" की आवश्यकता का अभाव है। एक कंप्यूटिंग नोड की मशीनों के बीच यातायात मार्ग हमेशा स्विच के माध्यम से जाएगा, जो हमेशा सुविधाजनक नहीं हो सकता है।
  
  

  ToR फ़िल्टरिंग © networkheresy

  
  
• OpenFlow नेटवर्क में फ़ील्ड्स की जाँच करते समय एंटी-स्पूफिंग - जब सभी स्विच, भौतिक और आभासी, नियंत्रकों के एक समूह से जुड़े होते हैं जो हर जगह ट्रैफ़िक फ़ील्ड को पुनर्निर्देशित और परिवर्तित करने के अलावा, एक कंप्यूट नोड के सॉफ़्टवेयर स्विच के स्तर पर इसे साफ़ करते हैं। यह संभावित विकल्पों में से सबसे जटिल और सबसे अधिक लचीला है, क्योंकि बिल्कुल सभी तर्क, एक साधारण स्विच के अंदर डेटाग्राम भेजने से शुरू होकर, नियंत्रक को स्थानांतरित कर दिए जाएंगे। अपूर्ण या असंगत नियम या तो कनेक्टिविटी में एक टूटने या अलगाव में टूटने का कारण बन सकते हैं, इसलिए, बड़े प्रतिशत प्रतिक्रियाशील (स्विच से अनुरोध पर गतिशील रूप से सेट) नियमों को एनआईसीई [ 2 ] जैसी रूपरेखाओं का उपयोग करके परीक्षण किया जाना चाहिए।
  
• एक नेटवर्क सेगमेंट का चयन करना बड़ी सजातीय संरचनाओं में प्रचलित एक समाधान है, जबकि वर्चुअल मशीनों के एक समूह को या तो भौतिक मशीनों (और एक भौतिक स्विच के बंदरगाहों) या किसी प्रकार (vlan / vxlan / gre) के एन्कैप्सुलेशन टैग के लिए एक बंधन सौंपा जाता है। फ़िल्टरिंग सीमा L2 खंड के जंक्शन पर है, दूसरे शब्दों में, सबनेट के सबनेट या सेट को खंड में आवंटित किया गया है और उन्हें प्रतिस्थापित करने की असंभवता एक उच्च बुनियादी ढांचे में मार्ग द्वारा निर्धारित की जाती है, उदाहरण के लिए, नोवा हाइब्रिड ड्राइवर के बिना ओपनस्टैक न्यूट्रॉन [ 3 ]। यह दृष्टिकोण गहरे सैद्धांतिक हित का नहीं है, लेकिन पूर्व-वर्चुअलाइजेशन युग से विरासत में व्यापक व्यावहारिक प्रचलन है।
  

यातायात प्रबंधन

नेटवर्क लिंक का पूरा फायदा उठाने के लिए इस तरह से मार्गों को अनुकूलित करना (दूसरे शब्दों में, अंतः बिंदुओं के सभी जोड़े के लिए न्यूनतम-कट योग [ 4 ] का अधिकतम पता लगाना, उनके वजन को ध्यान में रखते हुए, अर्थात, QoS प्राथमिकताएं) वितरित नेटवर्क में सबसे कठिन कार्य माना जाता है। । इस समस्या को हल करने के लिए डिज़ाइन किए गए IGPs आमतौर पर पर्याप्त लचीले नहीं होते हैं - ट्रैफ़िक को पहले से आवंटित QoS लेबल के आधार पर क्रमबद्ध किया जा सकता है, और आपको ट्रैफ़िक के गतिशील विश्लेषण और पुनर्वितरण के बारे में सोचने की ज़रूरत नहीं है। OpenFlow के लिए, चूंकि व्यक्तिगत ट्रैफ़िक तत्वों के विश्लेषण के साधन प्रोटोकॉल का एक अभिन्न अंग हैं, इसलिए इस समस्या को हल करना काफी सरल है - यह व्यक्तिगत प्रवाह के सही ढंग से काम करने वाले क्लासिफायरियर बनाने के लिए पर्याप्त है [ 5 , 6 ]। इस मामले में OpenFlow का एक और स्पष्ट लाभ यह है कि अग्रेषण रणनीति की एक केंद्रीकृत गणना में कई अतिरिक्त मापदंडों को ध्यान में रखना संभव है जो कि IGP मानकों में से किसी में भी शामिल नहीं हैं।

विषम सामग्री के साथ एक छोटे से डेटा सेंटर के नेटवर्क को डिजाइन करना (कई खुदरा उपयोगकर्ताओं को एक ही समय में एक रैक के लिए मशीनों के एक समूह को भौतिक रूप से लिंक किए बिना) बनाए रखना, मौजूदा तंत्रों में से एक का उपयोग करते हुए वितरित L2-ओवर-एल 3 नेटवर्क (ओवरऑल नेटवर्क) [ 7 ] के निर्माण के कार्य की ओर जाता है। परंपरागत साधनों द्वारा तकनीकी रूप से एक प्रसारण खंड में हजारों आभासी मेजबान रखने की असंभवता के लिए। संकेतित प्रौद्योगिकियाँ "तर्क को" अनलोड करने की अनुमति देती हैं, क्योंकि उपकरण अब निजी नेटवर्क (और संभवतः सार्वजनिक) सेगमेंट में अलग-अलग पते के बजाय होस्ट समूहों के अनुरूप लेबल के साथ काम करता है। कार्यान्वयन की कम लागत और तुलनात्मक आसानी के पीछे, नेटवर्क उपकरण और अंतिम गैर-निर्धारणवाद के निर्माता के लिए कम से कम एक कड़ी है - अगर हम विवरणों को अनदेखा करते हैं, तो सभी ओवरले प्रोटोकॉल एक अलग लेबल के अंदर एक प्रशिक्षित स्विच प्रदान करते हैं, जो ओवरले सेगमेंट के अंदर यातायात का अनुकूलन करते समय "अनटाइटी" के कारण हो सकता है। तीसरे स्तर के रूटिंग प्रोटोकॉल और ओवरले तंत्र। OpenFlow चुनना, हम सभी यातायात प्रबंधन को निर्णय लेने के एक स्तर तक कम करते हैं - नेटवर्क नियंत्रक। ओवरले या उनके स्वयं के तंत्र ने उन्हें प्रतिस्थापित किया, निश्चित रूप से, स्विच एग्रीगेटर्स (नीचे दी गई तस्वीर में रीढ़) में नियमों की मात्रा को कम करने में एक ही भूमिका निभा सकते हैं, और ToR स्विच (पत्ती) पर यातायात दिशा अनुकूलन मैट्रिक्स के एक मनमाने सेट के आधार पर होगा, इसके विपरीत सरल संतुलन से (उदाहरण के लिए, ईसीएमपी में)।

दो-स्तरीय रीढ़-पत्ती

OpenFlow

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

1.0 और 1.3 की तुलना © ब्रॉडकॉम कॉर्प

स्थिति से बाहर का एक आंशिक तरीका लर्निंग स्विच तंत्र का उपयोग करना है - अर्थात, ओपनफ्लो स्विच रिएक्टिव ऑपरेशन, जब हर बार नियमों का अनुरोध किया जाता है जब वे स्विच फ़ॉरवर्डिंग टेबल में पहले से रखे गए किसी एक से मेल नहीं खाते हैं, और एक निश्चित टीटीएल को स्विच से हटा दिया जाता है। विलोपन की रणनीति या तो "कठिन" हो सकती है - नियम को निर्धारित करने के बाद निर्दिष्ट अवधि के बाद हटाना, या "सॉफ्ट" - विलोपन केवल एक विशिष्ट स्ट्रीम "अंदर" के लिए दी गई अवधि के लिए गतिविधि की अनुपस्थिति में होता है। उस समय जब हमने OF का उपयोग करना शुरू किया था, तब किसी भी खुले सॉफ़्टवेयर कंट्रोलर ने नए संस्करणों का समर्थन नहीं किया था; नियंत्रण मानक के लचीलेपन की उपरोक्त खोज 1.0 मानक पर केंद्रित थी। लर्निंग स्विच मॉडल, वर्कलोड की एक महत्वपूर्ण मात्रा पर खुद को सही ठहराता है, केवल स्विच स्तर पर प्रति सेकंड सैकड़ों और हजारों अद्वितीय अनुरोधों को उत्पन्न करने वाले काउंटरों की तरह आवेदन एक विवादास्पद बाधा बन जाते हैं; यह एक त्वरित स्पूफिंग हमले के अधीन भी है - एक ग्राहक जो अद्वितीय आईपी / मैक पहचानकर्ताओं के साथ पैकेट उत्पन्न करता है; कम से कम, यह कम्प्यूटेशनल नोड स्तर निष्क्रिय के स्विच को प्रस्तुत करने में सक्षम है, और यदि आप PACKET_IN (नियंत्रक के लिए स्ट्रीम प्रसंस्करण के लिए संदेश) को सीमित करने से पहले ध्यान नहीं रखते हैं, तो पूरे खंड NT नेटवर्क।

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

वर्तमान के बारे में

सस्ती ToR व्हाइटबॉक्स नेटवर्क उपकरण [ 9 ] के निर्माताओं द्वारा आधुनिक ओपनफ्लो मानकों के लिए समर्थन वर्तमान में विंडिकावर (इंटेल), क्यूक्यूलस (डेल) और पाइका 8 में स्विच के आधार पर समाधान तक सीमित है, अन्य सभी विक्रेता या तो उच्च मूल्य श्रेणी के स्विच प्रदान करते हैं या दुरुपयोग करते हैं। स्वयं असंगत एक्सटेंशन / तंत्र। ऐतिहासिक कारणों से, हम Pica8 को ToR स्विच के रूप में उपयोग करते हैं, लेकिन निर्माता की नीति, जिसने GPL वितरण को सशुल्क सदस्यता में स्थानांतरित कर दिया, बहुत संभावित बातचीत के क्षेत्र को सीमित करता है। आज, खुले इंटेल ONS या डेल प्लेटफॉर्म ( ट्राइडेंट II पर आधारित), बहुत मामूली कीमत पर (<10K $ 4 * 40G + 48 * 10G के लिए), आपको 1-6 Tb के साथ एक औद्योगिक रैक के पैमाने पर कई हजार आभासी मशीनों के यातायात का प्रबंधन करने की अनुमति देता है। OpenFlow (1.3+) का उपयोग करके मेमोरी।

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

आपका ध्यान के लिए धन्यवाद!

संदर्भ

[1]। libvirt - nwfilter
[2]। अच्छा
[3]। ओपनस्टैक न्यूट्रॉन
[4]। अधिकतम-प्रवाह / मिनट-कट
[5]। बी 4 - ओपनफ्लो पर Google WAN नेटवर्क
[6]। क्यूओएस-उन्मुख टीई एल्गोरिदम में से एक का विस्तृत विश्लेषण
[7]। ओवरले नेटवर्क के बारे में अच्छा लेख
[8]। OF: 1.0 बनाम 1.3 टेबल मैच
[9]। क्यों व्हाइटबॉक्स स्विच आपके लिए अच्छे हैं