क्लाउड इंफ्रास्ट्रक्चर के नेटवर्क भाग का परिचय

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

आज हम क्लाउड इंफ्रास्ट्रक्चर की आंतरिक दुनिया के बारे में बात करेंगे, विशेष रूप से हम नेटवर्क भाग की मूल बातें देखेंगे।

बादल क्या है? वही वर्चुअलाइजेशन - प्रोफ़ाइल दृश्य?

एक तार्किक प्रश्न से भी अधिक. नहीं - यह वर्चुअलाइजेशन नहीं है, हालाँकि इसके बिना यह नहीं किया जा सकता था। आइए दो परिभाषाएँ देखें:

क्लाउड कंप्यूटिंग (इसके बाद क्लाउड के रूप में संदर्भित) वितरित कंप्यूटिंग संसाधनों तक उपयोगकर्ता के अनुकूल पहुंच प्रदान करने के लिए एक मॉडल है जिसे सेवा प्रदाता को न्यूनतम संभव विलंबता और न्यूनतम लागत के साथ मांग पर तैनात और लॉन्च किया जाना चाहिए।

वर्चुअलाइजेशन - यह एक भौतिक इकाई (उदाहरण के लिए, एक सर्वर) को कई आभासी इकाइयों में विभाजित करने की क्षमता है, जिससे संसाधनों का उपयोग बढ़ जाता है (उदाहरण के लिए, आपके पास 3-25 प्रतिशत पर 30 सर्वर लोड थे, वर्चुअलाइजेशन के बाद आपको 1 सर्वर लोड होता है) 80-90 प्रतिशत पर)। स्वाभाविक रूप से, वर्चुअलाइजेशन कुछ संसाधनों को खा जाता है - आपको हाइपरवाइज़र को खिलाने की ज़रूरत है, हालांकि, जैसा कि अभ्यास से पता चला है, गेम मोमबत्ती के लायक है। वर्चुअलाइजेशन का एक आदर्श उदाहरण VMWare है, जो पूरी तरह से वर्चुअल मशीन तैयार करता है, या उदाहरण के लिए KVM, जिसे मैं पसंद करता हूं, लेकिन यह स्वाद का मामला है।

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

वर्चुअलाइजेशन उन बिल्डिंग ब्लॉक्स में से एक है जिस पर क्लाउड बनाया गया है।

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

लेकिन मैं समझता हूं कि ऊपर प्रस्तुत परिभाषा से यह पूरी तरह स्पष्ट नहीं है कि वास्तव में बादल किसे कहा जा सकता है।

इसलिए, NIST (नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी) का एक दस्तावेज़ 5 मुख्य विशेषताएं प्रदान करता है जो एक क्लाउड इंफ्रास्ट्रक्चर में होनी चाहिए:

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

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

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

विभिन्न परिस्थितियों में त्वरित अनुकूलन। सेवाएँ लचीली होनी चाहिए - संसाधनों का त्वरित प्रावधान, उनका पुनर्वितरण, ग्राहक के अनुरोध पर संसाधनों को जोड़ना या कम करना, और ग्राहक की ओर से यह महसूस होना चाहिए कि क्लाउड संसाधन अंतहीन हैं। समझने में आसानी के लिए, उदाहरण के लिए, आपको यह चेतावनी नहीं दिखेगी कि Apple iCloud में आपके डिस्क स्थान का हिस्सा गायब हो गया है क्योंकि सर्वर पर हार्ड ड्राइव टूट गई है, और ड्राइव टूट जाती हैं। इसके अलावा, आपकी ओर से, इस सेवा की संभावनाएं लगभग असीमित हैं - आपको 2 टीबी की आवश्यकता है - कोई समस्या नहीं, आपने भुगतान किया और इसे प्राप्त किया। ऐसा ही एक उदाहरण Google.Drive या Yandex.Disk के साथ दिया जा सकता है।

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

इस तथ्य पर विचार करना उचित है कि ये आवश्यकताएं अधिकतर सार्वजनिक क्लाउड के लिए होती हैं, इसलिए निजी क्लाउड (यानी, कंपनी की आंतरिक जरूरतों के लिए लॉन्च किया गया क्लाउड) के लिए, इन आवश्यकताओं को थोड़ा समायोजित किया जा सकता है। हालाँकि, उन्हें अभी भी करना होगा, अन्यथा हमें क्लाउड कंप्यूटिंग के सभी लाभ नहीं मिलेंगे।

हमें बादल की आवश्यकता क्यों है?

हालाँकि, कोई भी नई या मौजूदा तकनीक, कोई भी नया प्रोटोकॉल किसी चीज़ के लिए बनाया जाता है (निश्चित रूप से, RIP-ng को छोड़कर)। किसी को प्रोटोकॉल के लिए प्रोटोकॉल की आवश्यकता नहीं है (निश्चित रूप से, RIP-ng को छोड़कर)। यह तर्कसंगत है कि क्लाउड उपयोगकर्ता/ग्राहक को किसी प्रकार की सेवा प्रदान करने के लिए बनाया गया है। हम सभी कम से कम कुछ क्लाउड सेवाओं से परिचित हैं, उदाहरण के लिए ड्रॉपबॉक्स या Google.Docs, और मेरा मानना ​​है कि अधिकांश लोग उनका सफलतापूर्वक उपयोग करते हैं - उदाहरण के लिए, यह लेख Google.Docs क्लाउड सेवा का उपयोग करके लिखा गया था। लेकिन जिन क्लाउड सेवाओं को हम जानते हैं वे केवल क्लाउड की क्षमताओं का हिस्सा हैं - अधिक सटीक रूप से, वे केवल SaaS-प्रकार की सेवा हैं। हम क्लाउड सेवा तीन तरीकों से प्रदान कर सकते हैं: SaaS, PaaS या IaaS के रूप में। आपको किस सेवा की आवश्यकता है यह आपकी इच्छाओं और क्षमताओं पर निर्भर करता है।

आइए प्रत्येक को क्रम से देखें:

एक सेवा के रूप में सॉफ्टवेयर (सास) क्लाइंट को पूर्ण सेवा प्रदान करने के लिए एक मॉडल है, उदाहरण के लिए, Yandex.Mail या Gmail जैसी ईमेल सेवा। इस सेवा वितरण मॉडल में, एक ग्राहक के रूप में, आप वास्तव में सेवाओं का उपयोग करने के अलावा कुछ नहीं करते हैं - यानी, आपको सेवा स्थापित करने, इसकी गलती सहनशीलता या अतिरेक के बारे में सोचने की ज़रूरत नहीं है। मुख्य बात यह है कि अपने पासवर्ड से समझौता न करें; इस सेवा का प्रदाता आपके लिए बाकी काम करेगा। सेवा प्रदाता के दृष्टिकोण से, वह संपूर्ण सेवा के लिए पूरी तरह से जिम्मेदार है - सर्वर हार्डवेयर और होस्ट ऑपरेटिंग सिस्टम से लेकर डेटाबेस और सॉफ्टवेयर सेटिंग्स तक।

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

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

ओपनस्टैक क्या है?

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

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

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

इस सामग्री को लिखने के समय, ओपनस्टैक संरचना इस तरह दिखती है:

से लिया गया चित्र openstack.org

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

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

सभी परियोजनाओं और उनके उद्देश्य की पूरी सूची देखी जा सकती है यहां.

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

हालाँकि, यदि आप इसे देखें, तो ओपनस्टैक में चलने वाली सभी सेवाएँ अंततः नेटवर्क से जुड़ी किसी प्रकार की वर्चुअल मशीन (या कंटेनर) हैं। प्रश्न उठता है - हमें इतने सारे तत्वों की आवश्यकता क्यों है?

आइए एक वर्चुअल मशीन बनाने और उसे नेटवर्क से जोड़ने और ओपनस्टैक में लगातार स्टोरेज के लिए एल्गोरिदम के बारे में जानें।

1. जब आप एक मशीन बनाने के लिए अनुरोध करते हैं, चाहे वह होराइजन (डैशबोर्ड) के माध्यम से एक अनुरोध हो या सीएलआई के माध्यम से एक अनुरोध हो, पहली चीज जो होती है वह कीस्टोन पर आपके अनुरोध का प्राधिकरण है - क्या आप एक मशीन बना सकते हैं, क्या इसमें यह है इस नेटवर्क का उपयोग करने का अधिकार, क्या आपका ड्राफ्ट कोटा, आदि।
2. कीस्टोन आपके अनुरोध को प्रमाणित करता है और प्रतिक्रिया संदेश में एक ऑथ टोकन उत्पन्न करता है, जिसका उपयोग आगे किया जाएगा। कीस्टोन से प्रतिक्रिया प्राप्त करने के बाद, अनुरोध नोवा (नोवा एपीआई) की ओर भेजा जाता है।
3. नोवा-एपीआई पहले से जेनरेट किए गए ऑथ टोकन का उपयोग करके कीस्टोन से संपर्क करके आपके अनुरोध की वैधता की जांच करता है
4. कीस्टोन प्रमाणीकरण करता है और इस प्रमाणीकरण टोकन के आधार पर अनुमतियों और प्रतिबंधों के बारे में जानकारी प्रदान करता है।
5. नोवा-एपीआई नोवा-डेटाबेस में नए वीएम के लिए एक प्रविष्टि बनाता है और मशीन बनाने का अनुरोध नोवा-शेड्यूलर को भेजता है।
6. नोवा-शेड्यूलर उस होस्ट (कंप्यूटर नोड) का चयन करता है जिस पर निर्दिष्ट मापदंडों, भार और क्षेत्रों के आधार पर वीएम तैनात किया जाएगा। इसका एक रिकॉर्ड और वीएम आईडी नोवा-डेटाबेस को लिखा जाता है।
7. इसके बाद, नोवा-शेड्यूलर एक इंस्टेंस तैनात करने के अनुरोध के साथ नोवा-कंप्यूट से संपर्क करता है। नोवा-कंप्यूट मशीन मापदंडों के बारे में जानकारी प्राप्त करने के लिए नोवा-कंडक्टर से संपर्क करता है (नोवा-कंडक्टर एक नोवा तत्व है जो नोवा-डेटाबेस और नोवा-कंप्यूट के बीच प्रॉक्सी सर्वर के रूप में कार्य करता है, डेटाबेस के साथ समस्याओं से बचने के लिए नोवा-डेटाबेस के अनुरोधों की संख्या को सीमित करता है। स्थिरता भार में कमी)।
8. नोवा-कंडक्टर नोवा-डेटाबेस से अनुरोधित जानकारी प्राप्त करता है और इसे नोवा-कंप्यूट को भेजता है।
9. इसके बाद, नोवा-कंप्यूट छवि आईडी प्राप्त करने के लिए ग्लान्स को कॉल करता है। ग्लास कीस्टोन में अनुरोध को सत्यापित करता है और मांगी गई जानकारी लौटाता है।
10. नोवा-कंप्यूट नेटवर्क मापदंडों के बारे में जानकारी प्राप्त करने के लिए न्यूट्रॉन से संपर्क करता है। ग्लांस के समान, न्यूट्रॉन कीस्टोन में अनुरोध को मान्य करता है, जिसके बाद यह डेटाबेस (पोर्ट पहचानकर्ता, आदि) में एक प्रविष्टि बनाता है, एक पोर्ट बनाने का अनुरोध करता है, और अनुरोधित जानकारी को नोवा-कंप्यूट पर लौटाता है।
11. वर्चुअल मशीन को वॉल्यूम आवंटित करने के अनुरोध के साथ नोवा-कंप्यूट संपर्क सिंडर। ग्लांस के समान, साइडर कीस्टोन में अनुरोध को मान्य करता है, वॉल्यूम निर्माण अनुरोध बनाता है, और अनुरोधित जानकारी लौटाता है।
12. नोवा-कंप्यूट निर्दिष्ट मापदंडों के साथ एक वर्चुअल मशीन को तैनात करने के अनुरोध के साथ libvirt से संपर्क करता है।

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

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

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

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

तो हमारे पास दो RED क्लाइंट VM और दो GREEN क्लाइंट VM हैं। आइए मान लें कि ये मशीनें दो हाइपरविजरों पर इस प्रकार स्थित हैं:

फिलहाल, यह केवल 4 सर्वरों का वर्चुअलाइजेशन है और इससे ज्यादा कुछ नहीं, क्योंकि अब तक हमने केवल 4 सर्वरों का वर्चुअलाइजेशन किया है, उन्हें दो भौतिक सर्वरों पर रखा है। और अभी तक ये नेटवर्क से भी नहीं जुड़े हैं.

क्लाउड बनाने के लिए हमें कई घटकों को जोड़ना होगा। सबसे पहले, हम नेटवर्क भाग को वर्चुअलाइज़ करते हैं - हमें इन 4 मशीनों को जोड़े में कनेक्ट करने की आवश्यकता है, और क्लाइंट L2 कनेक्शन चाहते हैं। आप एक स्विच का उपयोग कर सकते हैं और ट्रंक को उसकी दिशा में कॉन्फ़िगर कर सकते हैं और लिनक्स ब्रिज का उपयोग करके या, अधिक उन्नत उपयोगकर्ताओं के लिए, ओपनवीस्विच (हम इस पर बाद में लौटेंगे) का उपयोग करके सब कुछ हल कर सकते हैं। लेकिन बहुत सारे नेटवर्क हो सकते हैं, और एक स्विच के माध्यम से L2 को लगातार दबाना सबसे अच्छा विचार नहीं है - अलग-अलग विभाग हैं, एक सेवा डेस्क, एक आवेदन पूरा होने के लिए महीनों का इंतजार, समस्या निवारण के सप्ताह - आधुनिक दुनिया में यह दृष्टिकोण अब काम नहीं करता. और जितनी जल्दी कोई कंपनी इस बात को समझ लेगी, उसके लिए आगे बढ़ना उतना ही आसान हो जाएगा। इसलिए, हाइपरविजर्स के बीच हम एक L3 नेटवर्क का चयन करेंगे जिसके माध्यम से हमारी वर्चुअल मशीनें संचार करेंगी, और इस L3 नेटवर्क के शीर्ष पर हम वर्चुअल L2 ओवरले नेटवर्क का निर्माण करेंगे जहां हमारी वर्चुअल मशीनों का ट्रैफ़िक चलेगा। आप इनकैप्सुलेशन के रूप में GRE, Geneve या VxLAN का उपयोग कर सकते हैं। आइए अभी उत्तरार्द्ध पर ध्यान केंद्रित करें, हालांकि यह विशेष रूप से महत्वपूर्ण नहीं है।

हमें कहीं न कहीं VTEP का पता लगाने की आवश्यकता है (मुझे आशा है कि हर कोई VxLAN शब्दावली से परिचित है)। चूँकि हमारे पास सीधे सर्वर से आने वाला L3 नेटवर्क है, इसलिए हमें सर्वर पर VTEP लगाने से कोई नहीं रोकता है, और OVS (OpenvSwitch) ऐसा करने में उत्कृष्ट है। परिणामस्वरूप, हमें यह डिज़ाइन मिला:

चूंकि वीएम के बीच ट्रैफ़िक को विभाजित किया जाना चाहिए, वर्चुअल मशीनों की ओर पोर्ट के अलग-अलग वीएलएएन नंबर होंगे। टैग नंबर केवल एक वर्चुअल स्विच के भीतर एक भूमिका निभाता है, क्योंकि VxLAN में एनकैप्सुलेट होने पर हम इसे आसानी से हटा सकते हैं, क्योंकि हमारे पास एक वीएनआई होगा।

अब हम बिना किसी समस्या के उनके लिए अपनी मशीनें और वर्चुअल नेटवर्क बना सकते हैं।

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

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

अर्थात्, हमें निम्नलिखित चित्र मिलता है:

L2 सुरंगें सभी कंप्यूटिंग नोड्स से नियंत्रण नोड तक एकत्रित होती हैं। नोड जहां इन नेटवर्कों के लिए L3 इंटरफ़ेस स्थित है, प्रत्येक अलगाव के लिए एक समर्पित नामस्थान में है।

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

परिणामस्वरूप, हमें यह चित्र मिला:

एक वाजिब सवाल यह है कि कंप्यूट नोड्स पर स्वयं गेटवे क्यों नहीं बनाए जाते? यह कोई बड़ी समस्या नहीं है; इसके अलावा, यदि आप वितरित राउटर (डीवीआर) चालू करते हैं, तो यह काम करेगा। इस परिदृश्य में, हम एक केंद्रीकृत गेटवे के साथ सबसे सरल विकल्प पर विचार कर रहे हैं, जिसका उपयोग ओपनस्टैक में डिफ़ॉल्ट रूप से किया जाता है। उच्च-लोड कार्यों के लिए, वे वितरित राउटर और एसआर-आईओवी और पासथ्रू जैसी त्वरण प्रौद्योगिकियों दोनों का उपयोग करेंगे, लेकिन जैसा कि वे कहते हैं, यह एक पूरी तरह से अलग कहानी है। पहले, आइए मूल भाग से निपटें, और फिर हम विवरण में जाएंगे।

दरअसल, हमारी योजना पहले से ही व्यावहारिक है, लेकिन इसमें कुछ बारीकियां हैं:

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

आइए मशीन सुरक्षा से शुरुआत करें। इसके लिए आप सामान्य iptables का उपयोग कर सकते हैं, क्यों नहीं।

यानी अब हमारी टोपोलॉजी थोड़ी और जटिल हो गई है:

पर चलते हैं। हमें एक डीएचसीपी सर्वर जोड़ने की जरूरत है। प्रत्येक क्लाइंट के लिए डीएचसीपी सर्वर का पता लगाने के लिए सबसे आदर्श स्थान ऊपर उल्लिखित नियंत्रण नोड होगा, जहां नामस्थान स्थित हैं:

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

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

और यहां NAT हमारी सहायता के लिए आता है - हम ग्राहकों के लिए NAT अनुवाद का उपयोग करके डिफ़ॉल्ट नामस्थान के माध्यम से बाहरी दुनिया तक पहुंच को संभव बनाएंगे। खैर, यहाँ एक छोटी सी समस्या है। यह अच्छा है यदि क्लाइंट सर्वर क्लाइंट के रूप में कार्य करता है न कि सर्वर के रूप में - अर्थात, यह कनेक्शन स्वीकार करने के बजाय आरंभ करता है। लेकिन हमारे लिए यह दूसरा तरीका होगा। इस मामले में, हमें गंतव्य NAT करने की आवश्यकता है ताकि ट्रैफ़िक प्राप्त करते समय, नियंत्रण नोड समझ सके कि यह ट्रैफ़िक क्लाइंट A की वर्चुअल मशीन A के लिए है, जिसका अर्थ है कि हमें बाहरी पते से NAT अनुवाद करने की आवश्यकता है, उदाहरण के लिए 100.1.1.1 .10.0.0.1, आंतरिक पते 100 तक। इस मामले में, हालांकि सभी ग्राहक एक ही नेटवर्क का उपयोग करेंगे, आंतरिक अलगाव पूरी तरह से संरक्षित है। यानी हमें कंट्रोल नोड पर dNAT और sNAT करने की जरूरत है। फ्लोटिंग एड्रेस या बाहरी नेटवर्क या दोनों के साथ एक ही नेटवर्क का उपयोग करना है या नहीं, यह इस पर निर्भर करता है कि आप क्लाउड में क्या लाना चाहते हैं। हम आरेख में फ़्लोटिंग पते नहीं जोड़ेंगे, लेकिन पहले से जोड़े गए बाहरी नेटवर्क को छोड़ देंगे - प्रत्येक क्लाइंट का अपना बाहरी नेटवर्क होता है (आरेख में उन्हें बाहरी इंटरफ़ेस पर वीएलएएन 200 और XNUMX के रूप में दर्शाया गया है)।

परिणामस्वरूप, हमें एक दिलचस्प और साथ ही सुविचारित समाधान प्राप्त हुआ, जिसमें एक निश्चित लचीलापन है लेकिन अभी तक दोष सहिष्णुता तंत्र नहीं है।

सबसे पहले, हमारे पास केवल एक नियंत्रण नोड है - इसकी विफलता से सभी सिस्टम ध्वस्त हो जाएंगे। इस समस्या को ठीक करने के लिए, आपको कम से कम 3 नोड्स का कोरम बनाना होगा। आइए इसे आरेख में जोड़ें:

स्वाभाविक रूप से, सभी नोड्स सिंक्रनाइज़ होते हैं और जब एक सक्रिय नोड निकल जाता है, तो दूसरा नोड अपनी ज़िम्मेदारियाँ संभाल लेगा।

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

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

सेफ़ बनाने के लिए आपको 3 और नोड्स की आवश्यकता है। ब्लॉक, ऑब्जेक्ट और फ़ाइल स्टोरेज सेवाओं का उपयोग करके स्टोरेज के साथ इंटरेक्शन भी नेटवर्क के माध्यम से किया जाएगा। आइए स्कीमा में संग्रहण जोड़ें:

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

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

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

न्यूट्रॉन वास्तुकला

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

उच्च स्तर पर, नेटवर्क सेवा (मूल भाग) के संचालन को निम्नानुसार वर्णित किया जा सकता है।

VM प्रारंभ करते समय, नेटवर्क सेवा:

1. किसी दिए गए वीएम (या पोर्ट) के लिए एक पोर्ट बनाता है और इसके बारे में डीएचसीपी सेवा को सूचित करता है;
2. एक नया वर्चुअल नेटवर्क डिवाइस बनाया गया है (libvirt के माध्यम से);
3. वीएम चरण 1 में बनाए गए पोर्ट से जुड़ता है;

अजीब बात है कि, न्यूट्रॉन का काम उन सभी के लिए परिचित मानक तंत्रों पर आधारित है जिन्होंने कभी लिनक्स में प्रवेश किया है - नेमस्पेस, आईपीटेबल्स, लिनक्स ब्रिज, ओपनवस्विच, कॉनट्रैक, आदि।

यह तुरंत स्पष्ट किया जाना चाहिए कि न्यूट्रॉन एसडीएन नियंत्रक नहीं है।

न्यूट्रॉन में कई परस्पर जुड़े हुए घटक होते हैं:

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

न्यूट्रॉन-सर्वर वास्तव में पायथन में लिखा गया एक एप्लिकेशन है, जिसमें दो भाग होते हैं:

• बाकी सेवा
• न्यूट्रॉन प्लगइन (कोर/सेवा)

REST सेवा को अन्य घटकों से API कॉल प्राप्त करने के लिए डिज़ाइन किया गया है (उदाहरण के लिए, कुछ जानकारी प्रदान करने का अनुरोध, आदि)

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

उदाहरण के लिए आज उपलब्ध प्लगइन्स की सूची देखी जा सकती है यहां

कई सर्विस प्लगइन हो सकते हैं, लेकिन केवल एक हॉर्स प्लगइन हो सकता है।

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

RPC सेवा (rabbitmq-सर्वर) - एक सेवा जो कतार प्रबंधन और अन्य ओपनस्टैक सेवाओं के साथ-साथ नेटवर्क सेवा एजेंटों के बीच बातचीत प्रदान करती है।

नेटवर्क एजेंट - एजेंट जो प्रत्येक नोड में स्थित होते हैं, जिनके माध्यम से नेटवर्क सेवाओं को कॉन्फ़िगर किया जाता है।

एजेंट कई प्रकार के होते हैं.

मुख्य एजेंट है एल2 एजेंट. ये एजेंट नियंत्रण नोड्स (अधिक सटीक रूप से, सभी नोड्स पर जो किरायेदारों के लिए कोई भी सेवा प्रदान करते हैं) सहित प्रत्येक हाइपरवाइजर पर चलते हैं और उनका मुख्य कार्य वर्चुअल मशीनों को एक सामान्य एल 2 नेटवर्क से कनेक्ट करना है, और कोई भी घटना होने पर अलर्ट भी उत्पन्न करना है ( उदाहरण के लिए पोर्ट को अक्षम/सक्षम करें)।

अगला, कोई कम महत्वपूर्ण एजेंट नहीं है एल3 एजेंट. डिफ़ॉल्ट रूप से, यह एजेंट विशेष रूप से एक नेटवर्क नोड पर चलता है (अक्सर नेटवर्क नोड को एक नियंत्रण नोड के साथ जोड़ा जाता है) और किरायेदार नेटवर्क (इसके नेटवर्क और अन्य किरायेदारों के नेटवर्क दोनों के बीच) के बीच रूटिंग प्रदान करता है, और बाहरी दुनिया के लिए पहुंच योग्य है, प्रदान करता है NAT, साथ ही DHCP सेवा)। हालाँकि, DVR (वितरित राउटर) का उपयोग करते समय, L3 प्लगइन की आवश्यकता भी कंप्यूट नोड्स पर दिखाई देती है।

L3 एजेंट प्रत्येक किरायेदार को अपने स्वयं के पृथक नेटवर्क का एक सेट और वर्चुअल राउटर की कार्यक्षमता प्रदान करने के लिए लिनक्स नेमस्पेस का उपयोग करता है जो ट्रैफ़िक को रूट करता है और लेयर 2 नेटवर्क के लिए गेटवे सेवाएं प्रदान करता है।

डाटाबेस - नेटवर्क, सबनेट, पोर्ट, पूल आदि के पहचानकर्ताओं का एक डेटाबेस।

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

अब आइए परीक्षण स्थापना की ओर मुड़ें (इसे कैसे तैनात किया जाता है और इसमें क्या शामिल है, हम बाद में व्यावहारिक भाग में देखेंगे) और देखें कि प्रत्येक घटक कहाँ स्थित है:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

दरअसल, यही न्यूट्रॉन की पूरी संरचना है। अब ML2 प्लगइन पर कुछ समय बिताना उचित है।

मॉड्यूलर परत 2

जैसा कि ऊपर बताया गया है, प्लगइन एक मानक ओपनस्टैक रूट प्लगइन है और इसमें एक मॉड्यूलर आर्किटेक्चर है।

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

ML2 के दो घटक हैं - दो प्रकार के ड्राइवर: टाइप ड्राइवर और मैकेनिज्म ड्राइवर।

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

टाइप ड्राइवरों में निम्नलिखित नेटवर्क प्रकार शामिल हैं:

फ्लैट - टैगिंग के बिना नेटवर्क
VLAN - टैग किया गया नेटवर्क
स्थानीय - ऑल-इन-वन इंस्टॉलेशन के लिए एक विशेष प्रकार का नेटवर्क (ऐसे इंस्टॉलेशन या तो डेवलपर्स के लिए या प्रशिक्षण के लिए आवश्यक हैं)
जीआरई - जीआरई सुरंगों का उपयोग करके ओवरले नेटवर्क
वीएक्सएलएएन — VxLAN सुरंगों का उपयोग करके ओवरले नेटवर्क

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

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

उदाहरण: यदि हम OVS के साथ ML2 का उपयोग करते हैं, तो OVS को प्रबंधित करने वाले प्रत्येक कंप्यूटिंग नोड पर एक L2 एजेंट स्थापित होता है। हालाँकि, यदि हम, उदाहरण के लिए, OVN या OpenDayLight का उपयोग करते हैं, तो OVS का नियंत्रण उनके अधिकार क्षेत्र में आता है - न्यूट्रॉन, रूट प्लगइन के माध्यम से, नियंत्रक को आदेश देता है, और यह पहले से ही वही करता है जो उसे बताया गया था।

आइए ओपन वीस्विच पर ध्यान दें

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

ओवीएस एक ओपन सोर्स सॉफ़्टवेयर स्विच है जिसे वर्चुअल ट्रैफ़िक फ़ॉरवर्डर के रूप में वर्चुअलाइज्ड वातावरण में उपयोग के लिए डिज़ाइन किया गया है।

फिलहाल, OVS में बहुत अच्छी कार्यक्षमता है, जिसमें QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, आदि जैसी प्रौद्योगिकियां शामिल हैं।

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

ओवीएस के तीन महत्वपूर्ण घटक हैं जिनसे आपको अवगत होना आवश्यक है:

• कर्नेल मॉड्यूल - कर्नेल स्पेस में स्थित एक घटक जो नियंत्रण तत्व से प्राप्त नियमों के आधार पर ट्रैफ़िक को संसाधित करता है;
• vस्विच डेमॉन (ovs-vswitchd) उपयोगकर्ता स्थान में शुरू की गई एक प्रक्रिया है जो कर्नेल मॉड्यूल की प्रोग्रामिंग के लिए जिम्मेदार है - अर्थात, यह सीधे स्विच के संचालन के तर्क का प्रतिनिधित्व करता है
• डेटाबेस सर्वर - ओवीएस चलाने वाले प्रत्येक होस्ट पर स्थित एक स्थानीय डेटाबेस, जिसमें कॉन्फ़िगरेशन संग्रहीत होता है। SDN नियंत्रक OVSDB प्रोटोकॉल का उपयोग करके इस मॉड्यूल के माध्यम से संचार कर सकते हैं।

यह सब निदान और प्रबंधन उपयोगिताओं के एक सेट के साथ है, जैसे कि ओवीएस-वीएससीटीएल, ओवीएस-एपीसीटीएल, ओवीएस-ऑफसीटीएल, आदि।

वर्तमान में, टेलीकॉम ऑपरेटरों द्वारा ईपीसी, एसबीसी, एचएलआर इत्यादि जैसे नेटवर्क कार्यों को स्थानांतरित करने के लिए ओपनस्टैक का व्यापक रूप से उपयोग किया जाता है। कुछ फ़ंक्शन ओवीएस के साथ समस्याओं के बिना रह सकते हैं, लेकिन उदाहरण के लिए, ईपीसी सब्सक्राइबर ट्रैफ़िक को संसाधित करता है - फिर यह गुजरता है भारी मात्रा में ट्रैफ़िक (अब ट्रैफ़िक की मात्रा कई सौ गीगाबिट प्रति सेकंड तक पहुँच जाती है)। स्वाभाविक रूप से, ऐसे ट्रैफ़िक को कर्नेल स्पेस के माध्यम से चलाना (चूंकि फ़ॉरवर्डर डिफ़ॉल्ट रूप से वहां स्थित होता है) सबसे अच्छा विचार नहीं है। इसलिए, OVS को अक्सर कर्नेल को दरकिनार करते हुए NIC से उपयोगकर्ता स्थान पर ट्रैफ़िक अग्रेषित करने के लिए DPDK एक्सेलेरेशन तकनीक का उपयोग करके पूरी तरह से उपयोगकर्ता स्थान में तैनात किया जाता है।

ध्यान दें: दूरसंचार कार्यों के लिए तैनात किए गए क्लाउड के लिए, OVS को बायपास करके सीधे स्विचिंग उपकरण पर कंप्यूट नोड से ट्रैफ़िक आउटपुट करना संभव है। इस उद्देश्य के लिए SR-IOV और पासथ्रू तंत्र का उपयोग किया जाता है।

यह वास्तविक लेआउट पर कैसे काम करता है?

खैर, अब व्यावहारिक भाग पर चलते हैं और देखते हैं कि यह सब व्यवहार में कैसे काम करता है।

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

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

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

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

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

आप यह जांच सकते हैं कि नेस्टेड वर्चुअलाइजेशन सक्षम है या नहीं:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

हमें वर्चुअल मशीनों से निम्नलिखित सर्किट को असेंबल करने की आवश्यकता है:

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

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

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

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

अब हम हाइपरविजर पोर्ट कॉन्फ़िगरेशन को संपादित करते हैं:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

ध्यान दें: इस परिदृश्य में, पोर्ट ओवीएस-बीआर1 पर पता पहुंच योग्य नहीं होगा क्योंकि इसमें वीएलएएन टैग नहीं है। इसे ठीक करने के लिए, आपको sudo ovs-vsctl set port ovs-br1 tag=100 कमांड जारी करना होगा। हालाँकि, रीबूट के बाद, यह टैग गायब हो जाएगा (यदि कोई जानता है कि इसे अपनी जगह पर कैसे बनाए रखना है, तो मैं बहुत आभारी रहूंगा)। लेकिन यह इतना महत्वपूर्ण नहीं है, क्योंकि हमें केवल इंस्टॉलेशन के दौरान इस पते की आवश्यकता होगी और ओपनस्टैक पूरी तरह से तैनात होने पर इसकी आवश्यकता नहीं होगी।

इसके बाद, हम एक अंडरक्लाउड मशीन बनाते हैं:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

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

सफल इंस्टॉलेशन के बाद, आपके पास एक वर्चुअल मशीन होनी चाहिए जिस पर आप अंडरक्लाउड इंस्टॉल कर सकें

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

सबसे पहले, इंस्टॉलेशन प्रक्रिया के लिए आवश्यक उपकरण इंस्टॉल करें:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

अंडरक्लाउड स्थापना

हम एक स्टैक उपयोगकर्ता बनाते हैं, एक पासवर्ड सेट करते हैं, इसे sudoer में जोड़ते हैं और उसे पासवर्ड दर्ज किए बिना sudo के माध्यम से रूट कमांड निष्पादित करने की क्षमता देते हैं:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

अब हम होस्ट्स फ़ाइल में पूरा अंडरक्लाउड नाम निर्दिष्ट करते हैं:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

इसके बाद, हम रिपॉजिटरी जोड़ते हैं और वह सॉफ़्टवेयर इंस्टॉल करते हैं जिसकी हमें आवश्यकता होती है:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

इसके बाद, अंडरक्लाउड कॉन्फ़िगरेशन फ़ाइल को उपयोगकर्ता के होम डायरेक्टरी स्टैक पर कॉपी करें:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

अब हमें इस फ़ाइल को अपनी स्थापना में समायोजित करके इसे ठीक करने की आवश्यकता है।

आपको इन पंक्तियों को फ़ाइल की शुरुआत में जोड़ना होगा:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

तो, चलिए सेटिंग्स पर चलते हैं:

अंडरक्लाउड_होस्टनाम - अंडरक्लाउड सर्वर का पूरा नाम, DNS सर्वर पर प्रविष्टि से मेल खाना चाहिए

local_ip - नेटवर्क प्रावधान की ओर स्थानीय अंडरक्लाउड पता

नेटवर्क_गेटवे - वही स्थानीय पता, जो ओवरक्लाउड नोड्स की स्थापना के दौरान बाहरी दुनिया तक पहुंच के लिए प्रवेश द्वार के रूप में कार्य करेगा, स्थानीय आईपी के साथ भी मेल खाता है

अंडरक्लाउड_पब्लिक_होस्ट - बाहरी एपीआई पता, प्रोविजनिंग नेटवर्क से कोई भी मुफ्त पता सौंपा गया है

अंडरक्लाउड_एडमिन_होस्ट आंतरिक एपीआई पता, प्रोविजनिंग नेटवर्क से कोई भी मुफ्त पता सौंपा गया है

अंडरक्लाउड_नेमसर्वर - डीएनएस सर्वर

generate_service_certificate - यह पंक्ति वर्तमान उदाहरण में बहुत महत्वपूर्ण है, क्योंकि यदि आप इसे गलत पर सेट नहीं करते हैं तो आपको इंस्टॉलेशन के दौरान एक त्रुटि प्राप्त होगी, समस्या Red Hat बग ट्रैकर पर वर्णित है

local_interface नेटवर्क प्रावधान में इंटरफ़ेस। इस इंटरफ़ेस को अंडरक्लाउड परिनियोजन के दौरान पुन: कॉन्फ़िगर किया जाएगा, इसलिए आपको अंडरक्लाउड पर दो इंटरफ़ेस की आवश्यकता होगी - एक इसे एक्सेस करने के लिए, दूसरा प्रोविज़निंग के लिए

local_mtu - एमटीयू। चूँकि हमारे पास एक परीक्षण प्रयोगशाला है और मेरे पास ओवीएस स्विच पोर्ट पर 1500 का एमटीयू है, इसलिए इसे 1450 पर सेट करना आवश्यक है ताकि वीएक्सएलएएन में समाहित पैकेट गुजर सकें।

नेटवर्क_सिडर - प्रावधान नेटवर्क

बहाना - बाहरी नेटवर्क तक पहुँचने के लिए NAT का उपयोग करना

बहाना_नेटवर्क - नेटवर्क जो NATed होगा

dhcp_start - पता पूल का प्रारंभिक पता जिससे ओवरक्लाउड परिनियोजन के दौरान नोड्स को पते आवंटित किए जाएंगे

dhcp_end - पता पूल का अंतिम पता जिससे ओवरक्लाउड परिनियोजन के दौरान नोड्स को पते आवंटित किए जाएंगे

निरीक्षण_आईरेंज - आत्मनिरीक्षण के लिए आवश्यक पतों का एक पूल (उपरोक्त पूल के साथ ओवरलैप नहीं होना चाहिए)

शेड्यूलर_मैक्स_प्रयास - ओवरक्लाउड स्थापित करने के प्रयासों की अधिकतम संख्या (नोड्स की संख्या से अधिक या उसके बराबर होनी चाहिए)

फ़ाइल का वर्णन करने के बाद, आप अंडरक्लाउड को तैनात करने का आदेश दे सकते हैं:

openstack undercloud install

आपके आयरन के आधार पर प्रक्रिया में 10 से 30 मिनट का समय लगता है। अंततः आपको इस तरह आउटपुट देखना चाहिए:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

यह आउटपुट कहता है कि आपने सफलतापूर्वक अंडरक्लाउड स्थापित कर लिया है और अब आप अंडरक्लाउड की स्थिति की जांच कर सकते हैं और ओवरक्लाउड स्थापित करने के लिए आगे बढ़ सकते हैं।

यदि आप ifconfig आउटपुट को देखते हैं, तो आप देखेंगे कि एक नया ब्रिज इंटरफ़ेस सामने आया है

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

अब इस इंटरफ़ेस के माध्यम से ओवरक्लाउड परिनियोजन किया जाएगा।

नीचे दिए गए आउटपुट से आप देख सकते हैं कि हमारी सभी सेवाएँ एक नोड पर हैं:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

नीचे अंडरक्लाउड नेटवर्क भाग का कॉन्फ़िगरेशन दिया गया है:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

ओवरक्लाउड स्थापना

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

आइए अपनी वर्चुअल मशीनों के डिस्क वाले फ़ोल्डर में जाएं और आवश्यक आकार की डिस्क बनाएं:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

चूंकि हम रूट के रूप में काम कर रहे हैं, इसलिए हमें इन डिस्क के मालिक को बदलने की जरूरत है ताकि अधिकारों के साथ कोई समस्या न हो:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

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

बढ़िया, अब हमें इन सभी मशीनों को परिभाषित करने की आवश्यकता है:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

अंत में एक कमांड -प्रिंट-xml > /tmp/storage-1.xml है, जो /tmp/ फ़ोल्डर में प्रत्येक मशीन के विवरण के साथ एक xml फ़ाइल बनाता है; यदि आप इसे नहीं जोड़ते हैं, तो आप नहीं होंगे आभासी मशीनों की पहचान करने में सक्षम।

अब हमें इन सभी मशीनों को virsh में परिभाषित करने की आवश्यकता है:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

अब एक छोटी सी बारीकियां - ट्रिपलओ इंस्टॉलेशन और आत्मनिरीक्षण के दौरान सर्वर को प्रबंधित करने के लिए आईपीएमआई का उपयोग करता है।

आत्मनिरीक्षण नोड्स के आगे प्रावधान के लिए आवश्यक पैरामीटर प्राप्त करने के लिए हार्डवेयर का निरीक्षण करने की प्रक्रिया है। आत्मनिरीक्षण आयरनिक का उपयोग करके किया जाता है, यह सेवा नंगे धातु सर्वर के साथ काम करने के लिए डिज़ाइन की गई है।

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

वीबीएमसी स्थापित करें:

yum install yum install python2-virtualbmc

यदि आपका OS पैकेज नहीं ढूंढ पाता है, तो रिपॉजिटरी जोड़ें:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

अब हम उपयोगिता स्थापित करते हैं। यहाँ सब कुछ अपमान की हद तक सामान्य है। अब यह तर्कसंगत है कि vbmc सूची में कोई सर्वर नहीं हैं

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

उन्हें प्रदर्शित करने के लिए, उन्हें मैन्युअल रूप से इस तरह घोषित किया जाना चाहिए:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

मुझे लगता है कि कमांड सिंटैक्स स्पष्टीकरण के बिना स्पष्ट है। हालाँकि, अभी हमारे सभी सत्र डाउन स्थिति में हैं। उन्हें यूपी स्थिति में ले जाने के लिए, आपको उन्हें सक्षम करना होगा:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

और अंतिम स्पर्श - आपको फ़ायरवॉल नियमों को सही करने की आवश्यकता है (या इसे पूरी तरह से अक्षम करें):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

अब आइए अंडरक्लाउड पर जाएं और जांचें कि सब कुछ काम कर रहा है। होस्ट मशीन का पता 192.168.255.200 है, अंडरक्लाउड पर हमने तैनाती की तैयारी के दौरान आवश्यक ipmitool पैकेज जोड़ा:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

जैसा कि आप देख सकते हैं, हमने vbmc के माध्यम से नियंत्रण नोड को सफलतापूर्वक लॉन्च किया है। अब इसे बंद करें और आगे बढ़ें:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

ध्यान दें: नियंत्रण नोड में दो इंटरफेस हैं, लेकिन इस मामले में यह महत्वपूर्ण नहीं है, इस इंस्टॉलेशन में एक हमारे लिए पर्याप्त होगा।

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

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

अब हमें विडंबना के लिए चित्र तैयार करने की जरूरत है। ऐसा करने के लिए, उन्हें wget के माध्यम से डाउनलोड करें और इंस्टॉल करें:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

अंडरक्लाउड पर छवियाँ अपलोड करना:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

जाँच कर रहा हूँ कि सभी छवियाँ लोड हो गई हैं

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

एक और बात - आपको एक DNS सर्वर जोड़ना होगा:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

अब हम आत्मनिरीक्षण के लिए आदेश दे सकते हैं:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

इसके बाद, हमें यह इंगित करने की आवश्यकता है कि कौन सा नोड कौन सा कार्य करेगा - अर्थात, उस प्रोफ़ाइल को इंगित करें जिसके साथ नोड तैनात होगा:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

प्रत्येक नोड के लिए प्रोफ़ाइल निर्दिष्ट करें:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

आइए जाँचें कि हमने सब कुछ सही ढंग से किया है:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

यदि सब कुछ सही है, तो हम ओवरक्लाउड तैनात करने का आदेश देते हैं:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

ध्यान दें: इस मामले में --libvirt-type qemu वैरिएबल आवश्यक है, क्योंकि हम नेस्टेड वर्चुअलाइजेशन का उपयोग करेंगे। अन्यथा, आप वर्चुअल मशीन नहीं चला पाएंगे.

अब आपके पास लगभग एक घंटा है, या शायद अधिक (हार्डवेयर की क्षमताओं के आधार पर) और आप केवल आशा कर सकते हैं कि इस समय के बाद आपको निम्नलिखित संदेश दिखाई देगा:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

अब आपके पास ओपनस्टैक का लगभग पूर्ण संस्करण है, जिस पर आप अध्ययन, प्रयोग आदि कर सकते हैं।

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

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

मेरी स्थापना के लिए अभी भी एक छोटे से स्पर्श की आवश्यकता है - नियंत्रक पर एक मार्ग जोड़ना, क्योंकि जिस मशीन के साथ मैं काम कर रहा हूं वह एक अलग नेटवर्क पर है। ऐसा करने के लिए, हीट-एडमिन खाते के अंतर्गत कंट्रोल-1 पर जाएं और रूट पंजीकृत करें

(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

खैर, अब आप क्षितिज में जा सकते हैं। सभी जानकारी - पते, लॉगिन और पासवर्ड - फ़ाइल /home/stack/overcloudrc में हैं। अंतिम आरेख इस प्रकार दिखता है:

वैसे, हमारी स्थापना में, मशीन पते डीएचसीपी के माध्यम से जारी किए गए थे और, जैसा कि आप देख सकते हैं, वे "यादृच्छिक रूप से" जारी किए गए हैं। यदि आपको आवश्यकता हो तो आप टेम्पलेट में सख्ती से परिभाषित कर सकते हैं कि परिनियोजन के दौरान किस मशीन से कौन सा पता संलग्न किया जाना चाहिए।

वर्चुअल मशीनों के बीच ट्रैफ़िक कैसे प्रवाहित होता है?

इस लेख में हम ट्रैफिक पास करने के तीन विकल्पों पर गौर करेंगे

• एक L2 नेटवर्क पर एक हाइपरवाइजर पर दो मशीनें
• एक ही L2 नेटवर्क पर विभिन्न हाइपरवाइज़र पर दो मशीनें
• विभिन्न नेटवर्क पर दो मशीनें (क्रॉस-नेटवर्क रूटिंग)

बाहरी नेटवर्क के माध्यम से बाहरी दुनिया तक पहुंच, फ़्लोटिंग पते के साथ-साथ वितरित रूटिंग के मामलों पर हम अगली बार विचार करेंगे, अभी के लिए हम आंतरिक ट्रैफ़िक पर ध्यान केंद्रित करेंगे।

जाँच करने के लिए, आइए निम्नलिखित आरेख को एक साथ रखें:

हमने 4 वर्चुअल मशीनें बनाई हैं - 3 एक एल2 नेटवर्क पर - नेट-1, और नेट-1 नेटवर्क पर 2 और

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

आइए देखें कि बनाई गई मशीनें किन हाइपरविजर्स पर स्थित हैं:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(ओवरक्लाउड) [स्टैक@अंडरक्लाउड ~]$
मशीनें vm-1 और vm-3 कंप्यूट-0 पर स्थित हैं, मशीनें vm-2 और vm-4 नोड कंप्यूट-1 पर स्थित हैं।

इसके अलावा, निर्दिष्ट नेटवर्क के बीच रूटिंग को सक्षम करने के लिए एक वर्चुअल राउटर बनाया गया है:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

राउटर में दो वर्चुअल पोर्ट होते हैं, जो नेटवर्क के लिए गेटवे के रूप में कार्य करते हैं:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

फिलहाल, नोड में तीन ओवीएस ब्रिज हैं - br-int, br-tun, br-ex। उनके बीच, जैसा कि हम देखते हैं, इंटरफेस का एक सेट है। समझने में आसानी के लिए, आइए इन सभी इंटरफेस को आरेख पर प्लॉट करें और देखें कि क्या होता है।

जिन पतों पर VxLAN सुरंगें बनाई गई हैं, उन्हें देखते हुए, यह देखा जा सकता है कि एक सुरंग को गणना-1 (192.168.255.26) के लिए ऊपर उठाया गया है, दूसरी सुरंग नियंत्रण-1 (192.168.255.15) की ओर उठाई गई है। लेकिन सबसे दिलचस्प बात यह है कि br-ex में कोई भौतिक इंटरफ़ेस नहीं है, और यदि आप देखें कि कौन से प्रवाह कॉन्फ़िगर किए गए हैं, तो आप देख सकते हैं कि यह पुल फिलहाल केवल ट्रैफ़िक को गिरा सकता है।

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

जैसा कि आप आउटपुट से देख सकते हैं, पता सीधे भौतिक पोर्ट पर स्क्रू किया जाता है, न कि वर्चुअल ब्रिज इंटरफ़ेस पर।

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

पहले नियम के अनुसार, फ़ाइ-ब्र-एक्स पोर्ट से आने वाली हर चीज़ को त्याग दिया जाना चाहिए।
दरअसल, वर्तमान में इस इंटरफ़ेस (br-int के साथ इंटरफ़ेस) के अलावा इस पुल में ट्रैफ़िक आने के लिए कहीं और नहीं है, और बूंदों को देखते हुए, BUM ट्रैफ़िक पहले ही पुल में प्रवाहित हो चुका है।

अर्थात्, ट्रैफ़िक इस नोड को केवल VxLAN सुरंग के माध्यम से छोड़ सकता है और कुछ नहीं। हालाँकि, यदि आप डीवीआर चालू करते हैं, तो स्थिति बदल जाएगी, लेकिन हम उससे अगली बार निपटेंगे। नेटवर्क आइसोलेशन का उपयोग करते समय, उदाहरण के लिए vlans का उपयोग करते समय, आपके पास vlan 3 में एक L0 इंटरफ़ेस नहीं होगा, बल्कि कई इंटरफ़ेस होंगे। हालाँकि, VxLAN ट्रैफ़िक उसी तरह से नोड को छोड़ देगा, लेकिन कुछ प्रकार के समर्पित वीएलएएन में भी समाहित हो जाएगा।

हमने कंप्यूट नोड को सुलझा लिया है, आइए नियंत्रण नोड पर चलते हैं।

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

वास्तव में, हम कह सकते हैं कि सब कुछ समान है, लेकिन आईपी एड्रेस अब भौतिक इंटरफ़ेस पर नहीं बल्कि वर्चुअल ब्रिज पर है। ऐसा इसलिए किया जाता है क्योंकि यह बंदरगाह वह बंदरगाह है जिसके माध्यम से यातायात बाहरी दुनिया से बाहर निकलेगा।

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

यह पोर्ट br-ex ब्रिज से बंधा हुआ है और चूंकि इस पर कोई vlan टैग नहीं हैं, यह पोर्ट एक ट्रंक पोर्ट है जिस पर सभी vlan की अनुमति है, अब ट्रैफ़िक टैग के बिना बाहर जाता है, जैसा कि vlan-id 0 में दर्शाया गया है उपरोक्त आउटपुट.

इस समय बाकी सब कुछ कंप्यूट नोड के समान है - वही पुल, वही सुरंगें जो दो कंप्यूट नोड्स तक जाती हैं।

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

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

अब तक हमारा नेटवर्क इस तरह दिखता है:

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

मशीन में केवल एक वर्चुअल इंटरफ़ेस है - Tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

यह इंटरफ़ेस लिनक्स ब्रिज में दिखता है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

जैसा कि आप आउटपुट से देख सकते हैं, ब्रिज में केवल दो इंटरफेस हैं - Tap95d96a75-a0 और qvb95d96a75-a0।

यहां ओपनस्टैक में वर्चुअल नेटवर्क उपकरणों के प्रकारों पर थोड़ा ध्यान देना उचित है:
वीटैप - एक इंस्टेंस से जुड़ा वर्चुअल इंटरफ़ेस (वीएम)
क्यूबीआर - लिनक्स ब्रिज
qvb और qvo - vEth जोड़ी Linux ब्रिज और ओपन vSwitch ब्रिज से जुड़ी है
br-int, br-tun, br-vlan - vSwitch ब्रिज खोलें
पैच-, int-br-, phy-br- - पुलों को जोड़ने वाले vSwitch पैच इंटरफेस खोलें
क्यूजी, क्यूआर, हा, एफजी, एसजी - ओवीएस से कनेक्ट करने के लिए वर्चुअल डिवाइस द्वारा उपयोग किए जाने वाले वीस्विच पोर्ट खोलें

जैसा कि आप समझते हैं, यदि हमारे पास ब्रिज में qvb95d96a75-a0 पोर्ट है, जो एक vEth जोड़ी है, तो कहीं न कहीं इसका समकक्ष है, जिसे तार्किक रूप से qvo95d96a75-a0 कहा जाना चाहिए। आइए देखें कि OVS पर कौन से पोर्ट हैं।

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

जैसा कि हम देख सकते हैं, पोर्ट br-int में है। Br-int एक स्विच के रूप में कार्य करता है जो वर्चुअल मशीन पोर्ट को समाप्त करता है। आउटपुट में qvo95d96a75-a0 के अलावा, पोर्ट qvo5bd37136-47 दिखाई देता है। यह दूसरी वर्चुअल मशीन का पोर्ट है। परिणामस्वरूप, हमारा आरेख अब इस तरह दिखता है:

एक प्रश्न जो चौकस पाठक को तुरंत रुचिकर लगेगा - वर्चुअल मशीन पोर्ट और ओवीएस पोर्ट के बीच लिनक्स ब्रिज क्या है? तथ्य यह है कि मशीन की सुरक्षा के लिए सुरक्षा समूहों का उपयोग किया जाता है, जो आईपीटेबल्स से ज्यादा कुछ नहीं हैं। OVS iptables के साथ काम नहीं करता है, इसलिए इस "बैसाखी" का आविष्कार किया गया था। हालाँकि, यह अप्रचलित होता जा रहा है - नई रिलीज़ में इसे कॉनट्रैक द्वारा प्रतिस्थापित किया जा रहा है।

अर्थात्, अंततः योजना इस प्रकार दिखती है:

एक L2 नेटवर्क पर एक हाइपरवाइजर पर दो मशीनें

चूँकि ये दोनों VM एक ही L2 नेटवर्क और एक ही हाइपरवाइज़र पर स्थित हैं, इसलिए उनके बीच ट्रैफ़िक तार्किक रूप से br-int के माध्यम से स्थानीय रूप से प्रवाहित होगा, क्योंकि दोनों मशीनें एक ही VLAN पर होंगी:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

एक ही L2 नेटवर्क पर विभिन्न हाइपरवाइज़र पर दो मशीनें

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

वर्चुअल मशीनों के पते जिनके बीच हम ट्रैफ़िक देखेंगे:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

हम कंप्यूट-0 पर br-int में अग्रेषण तालिका को देखते हैं:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ट्रैफ़िक को पोर्ट 2 पर जाना चाहिए - आइए देखें कि यह किस प्रकार का पोर्ट है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

यह पैच-ट्यून है - अर्थात, br-tun में इंटरफ़ेस। आइए देखें कि br-tun पर पैकेज का क्या होता है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

पैकेट को VxLAN में पैक किया जाता है और पोर्ट 2 पर भेजा जाता है। आइए देखें कि पोर्ट 2 कहाँ जाता है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

यह कंप्यूट-1 पर एक vxlan सुरंग है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

आइए गणना-1 पर जाएं और देखें कि पैकेज के साथ आगे क्या होता है:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

मैक कंप्यूट-1 पर br-int फ़ॉरवर्डिंग टेबल में है, और जैसा कि ऊपर दिए गए आउटपुट से देखा जा सकता है, यह पोर्ट 2 के माध्यम से दिखाई देता है, जो कि br-tun की ओर का पोर्ट है:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

खैर, फिर हम देखते हैं कि कंप्यूट-1 पर br-int में एक गंतव्य पोस्ता है:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

यानी, प्राप्त पैकेट पोर्ट 3 पर उड़ान भरेगा, जिसके पीछे पहले से ही एक वर्चुअल मशीन इंस्टेंस-00000003 है।

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

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

पहली पंक्ति से पता चलता है कि पटेक पते 10.0.1.85 से पता 10.0.1.88 (आईसीएमपी ट्रैफिक) पर जाता है, और इसे वीएनआई 22 के साथ वीएक्सएलएएन पैकेट में लपेटा जाता है और पैकेट होस्ट 192.168.255.19 (कंप्यूट-0) से होस्ट 192.168.255.26 तक जाता है। .1 ( गणना-XNUMX). हम जांच सकते हैं कि वीएनआई ओवीएस में निर्दिष्ट वीएनआई से मेल खाता है।

चलिए इस लाइन पर वापस आते हैं Actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. हेक्साडेसिमल संख्या प्रणाली में 0x16 वीएनआई है। आइए इस संख्या को 16वीं प्रणाली में बदलें:

16 = 6*16^0+1*16^1 = 6+16 = 22

अर्थात्, vni वास्तविकता से मेल खाता है।

दूसरी पंक्ति रिटर्न ट्रैफ़िक दिखाती है, खैर, इसे समझाने का कोई मतलब नहीं है, वहां सब कुछ स्पष्ट है।

विभिन्न नेटवर्क पर दो मशीनें (इंटर-नेटवर्क रूटिंग)

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

सबसे पहले, आइए देखें कि रूटिंग कार्य करती है:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

चूंकि इस मामले में पैकेट को गेटवे पर जाना होगा और वहां रूट किया जाना चाहिए, हमें गेटवे का पोस्ता पता पता लगाना होगा, जिसके लिए हम उदाहरण में एआरपी तालिका को देखते हैं:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

अब आइए देखें कि गंतव्य (10.0.1.254) fa:16:3e:c4:64:70 वाला ट्रैफ़िक कहाँ भेजा जाना चाहिए:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

आइए देखें कि पोर्ट 2 कहाँ जाता है:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

सब कुछ तार्किक है, ट्रैफ़िक br-tun पर जाता है। आइए देखें कि इसे किस vxlan सुरंग में लपेटा जाएगा:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

तीसरा बंदरगाह एक vxlan सुरंग है:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

जो नियंत्रण नोड को देखता है:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ट्रैफ़िक नियंत्रण नोड तक पहुँच गया है, इसलिए हमें उस पर जाकर देखना होगा कि रूटिंग कैसे होगी।

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

तो, यह स्पष्ट है कि गेटवे मैक पता नियंत्रण नोड पर br-int अग्रेषण तालिका में होना चाहिए। आइए देखें कि यह वहां है या नहीं और कहां दिख रहा है:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

मैक पोर्ट qr-0c52b15f-8f से दिखाई देता है। यदि हम ओपनस्टैक में वर्चुअल पोर्ट की सूची पर वापस जाते हैं, तो इस प्रकार के पोर्ट का उपयोग विभिन्न वर्चुअल डिवाइसों को ओवीएस से जोड़ने के लिए किया जाता है। अधिक सटीक होने के लिए, क्यूआर वर्चुअल राउटर का एक पोर्ट है, जिसे नेमस्पेस के रूप में दर्शाया गया है।

आइए देखें कि सर्वर पर कौन से नेमस्पेस हैं:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

लगभग तीन प्रतियाँ। लेकिन नामों को देखकर आप उनमें से प्रत्येक के उद्देश्य का अनुमान लगा सकते हैं। हम बाद में आईडी 0 और 1 वाले उदाहरणों पर लौटेंगे, अब हम नेमस्पेस qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe में रुचि रखते हैं:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

इस नेमस्पेस में दो आंतरिक नेमस्पेस हैं जिन्हें हमने पहले बनाया था। दोनों वर्चुअल पोर्ट को br-int में जोड़ा गया है। आइए पोर्ट qr-0c52b15f-8f के मैक पते की जांच करें, क्योंकि गंतव्य मैक पते को देखते हुए, ट्रैफ़िक इस इंटरफ़ेस पर गया था।

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

यानी इस मामले में सब कुछ मानक रूटिंग के नियमों के अनुसार काम करता है। चूँकि ट्रैफ़िक होस्ट 10.0.2.8 के लिए नियत है, इसे दूसरे इंटरफ़ेस qr-92fa49b5-54 से बाहर निकलना होगा और vxlan सुरंग से होकर कंप्यूट नोड तक जाना होगा:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

सब कुछ तार्किक है, कोई आश्चर्य नहीं। आइए देखें कि होस्ट 10.0.2.8 का पोस्ता पता br-int में कहाँ दिखाई देता है:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

जैसा कि अपेक्षित था, ट्रैफ़िक ब्र-टुन की ओर जाता है, आइए देखें कि ट्रैफ़िक अगली किस सुरंग तक जाता है:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

गणना-1 के लिए यातायात सुरंग में जाता है। खैर, कंप्यूट-1 पर सब कुछ सरल है - br-tun से पैकेज br-int पर जाता है और वहां से वर्चुअल मशीन इंटरफ़ेस पर जाता है:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

आइए जांचें कि क्या यह वास्तव में सही इंटरफ़ेस है:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

दरअसल, हम पूरे पैकेज में गए। मुझे लगता है कि आपने देखा होगा कि ट्रैफ़िक अलग-अलग वीएक्सएलएएन सुरंगों से गुज़रता है और अलग-अलग वीएनआई से बाहर निकलता है। आइए देखें कि ये किस प्रकार के वीएनआई हैं, जिसके बाद हम नोड के नियंत्रण पोर्ट पर एक डंप एकत्र करेंगे और सुनिश्चित करेंगे कि ट्रैफ़िक ठीक उसी तरह बहता है जैसा ऊपर वर्णित है।
तो, गणना-0 की सुरंग में निम्नलिखित क्रियाएं हैं = लोड: 0-> NXM_OF_VLAN_TCI [], लोड: 0x16-> NXM_NX_TUN_ID [], आउटपुट: 3। आइए 0x16 को दशमलव संख्या प्रणाली में बदलें:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

गणना-1 की सुरंग में निम्नलिखित VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],आउटपुट:2 है। आइए 0x63 को दशमलव संख्या प्रणाली में बदलें:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

खैर, अब डंप पर नजर डालते हैं:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

पहला पैकेट होस्ट 192.168.255.19 (कंप्यूट-0) से होस्ट 192.168.255.15 (कंट्रोल-1) के लिए vni 22 के साथ एक vxlan पैकेट है, जिसके अंदर होस्ट 10.0.1.85 से होस्ट 10.0.2.8 तक एक ICMP पैकेट पैक किया गया है। जैसा कि हमने ऊपर गणना की, वीएनआई आउटपुट में हमने जो देखा उससे मेल खाता है।

दूसरा पैकेट होस्ट 192.168.255.15 (कंट्रोल-1) से होस्ट 192.168.255.26 (कंप्यूट-1) के लिए vni 99 के साथ एक vxlan पैकेट है, जिसके अंदर होस्ट 10.0.1.85 से होस्ट 10.0.2.8 तक एक ICMP पैकेट पैक किया गया है। जैसा कि हमने ऊपर गणना की, वीएनआई आउटपुट में हमने जो देखा उससे मेल खाता है।

अगले दो पैकेट 10.0.2.8 से रिटर्न ट्रैफ़िक हैं न कि 10.0.1.85 से।

अर्थात्, अंत में हमें निम्नलिखित नियंत्रण नोड योजना प्राप्त हुई:

देखो ऐसा ही है? हम दो नामस्थानों के बारे में भूल गए:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

जैसा कि हमने क्लाउड प्लेटफ़ॉर्म के आर्किटेक्चर के बारे में बात की, यह अच्छा होगा यदि मशीनों को डीएचसीपी सर्वर से स्वचालित रूप से पते प्राप्त हों। ये हमारे दो नेटवर्क 10.0.1.0/24 और 10.0.2.0/24 के लिए दो डीएचसीपी सर्वर हैं।

आइए जांचें कि यह सच है या नहीं। इस नेमस्पेस में केवल एक ही पता है - 10.0.1.1 - स्वयं डीएचसीपी सर्वर का पता, और यह br-int में भी शामिल है:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

आइए देखें कि नियंत्रण नोड पर उनके नाम में qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 वाली प्रक्रियाएं हैं या नहीं:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

ऐसी एक प्रक्रिया है और उपरोक्त आउटपुट में प्रस्तुत जानकारी के आधार पर, उदाहरण के लिए, हम देख सकते हैं कि वर्तमान में हमारे पास किराए के लिए क्या है:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

परिणामस्वरूप, हमें नियंत्रण नोड पर सेवाओं का निम्नलिखित सेट मिलता है:

ठीक है, ध्यान रखें - यह केवल 4 मशीनें, 2 आंतरिक नेटवर्क और एक वर्चुअल राउटर है... हमारे पास अब कोई बाहरी नेटवर्क नहीं है, विभिन्न परियोजनाओं का एक समूह है, प्रत्येक का अपना नेटवर्क (ओवरलैपिंग) है, और हमारे पास है एक वितरित राउटर बंद हो गया, और अंत में, परीक्षण बेंच में केवल एक नियंत्रण नोड था (गलती सहनशीलता के लिए तीन नोड्स का कोरम होना चाहिए)। यह तर्कसंगत है कि वाणिज्य में सब कुछ "थोड़ा" अधिक जटिल है, लेकिन इस सरल उदाहरण में हम समझते हैं कि इसे कैसे काम करना चाहिए - चाहे आपके पास 3 या 300 नामस्थान हों, यह निश्चित रूप से महत्वपूर्ण है, लेकिन संचालन के दृष्टिकोण से संपूर्ण संरचना, कुछ भी अधिक नहीं बदलेगा... हालाँकि आप कुछ विक्रेता SDN को प्लग इन नहीं करेंगे। लेकिन यह बिल्कुल अलग कहानी है.

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

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

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

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

मेरी राय में, VMWare का सबसे बड़ा नुकसान इसका पूर्ण रूप से बंद होना है - कंपनी आपको इस बारे में कोई जानकारी नहीं देगी कि यह कैसे काम करता है, उदाहरण के लिए, vSAN या हाइपरविजर कर्नेल में क्या है - यह बस इसके लिए लाभदायक नहीं है - अर्थात, आप करेंगे कभी भी VMWare में विशेषज्ञ न बनें - विक्रेता के समर्थन के बिना, आप बर्बाद हो जाएंगे (अक्सर मैं VMWare विशेषज्ञों से मिलता हूं जो तुच्छ प्रश्नों से भ्रमित हो जाते हैं)। मेरे लिए, VMWare हुड लॉक वाली कार खरीद रहा है - हाँ, आपके पास ऐसे विशेषज्ञ हो सकते हैं जो टाइमिंग बेल्ट बदल सकते हैं, लेकिन हुड को केवल वही खोल सकता है जिसने आपको यह समाधान बेचा है। व्यक्तिगत रूप से, मुझे ऐसे समाधान पसंद नहीं हैं जिनमें मैं फिट नहीं हो सकता। आप कहेंगे कहीं हुड के नीचे न जाना पड़े. हां, यह संभव है, लेकिन जब आपको 20-30 वर्चुअल मशीनों, 40-50 नेटवर्कों से क्लाउड में एक बड़े फ़ंक्शन को इकट्ठा करने की आवश्यकता होगी, तो मैं आपकी ओर देखूंगा, जिनमें से आधे बाहर जाना चाहते हैं, और दूसरा आधा इसके लिए पूछता है। SR-IOV त्वरण, अन्यथा आपको इनमें से कुछ दर्जन से अधिक कारों की आवश्यकता होगी - अन्यथा प्रदर्शन पर्याप्त नहीं होगा।

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

स्रोत: www.habr.com