क्लाउड पूर्वाधारको नेटवर्क भागको परिचय

क्लाउड कम्प्युटिङले हाम्रो जीवनमा गहिरो र गहिरो प्रवेश गरिरहेको छ र सम्भवतः त्यहाँ एक व्यक्ति पनि छैन जसले कम्तिमा एक पटक कुनै क्लाउड सेवाहरू प्रयोग नगरेको छ। यद्यपि, वास्तवमा क्लाउड के हो र यसले कसरी काम गर्दछ, थोरै मानिसहरूलाई थाहा छ, विचारको स्तरमा पनि। 5G पहिले नै वास्तविकता बन्न थालेको छ र दूरसंचार पूर्वाधार स्तम्भ समाधानबाट क्लाउड समाधानहरूमा सार्न थालेको छ, जसरी यो पूर्ण रूपमा हार्डवेयर समाधानबाट भर्चुअलाइज्ड "पिलरहरू" मा सारियो।

आज हामी क्लाउड पूर्वाधारको भित्री संसारको बारेमा कुरा गर्नेछौं, विशेष गरी हामी नेटवर्क भागको आधारभूत कुराहरू हेर्नेछौं।

बादल के हो? एउटै भर्चुअलाइजेशन - प्रोफाइल दृश्य?

तार्किक प्रश्न भन्दा बढी। होइन - यो भर्चुअलाइजेशन होइन, यद्यपि यो बिना गर्न सकिँदैन। दुई परिभाषाहरू हेरौं:

क्लाउड कम्प्युटिङ (यसपछि क्लाउड भनिन्छ) वितरण गरिएको कम्प्युटिङ स्रोतहरूमा प्रयोगकर्ता-मैत्री पहुँच प्रदान गर्ने मोडेल हो जुन सेवा प्रदायकलाई न्यूनतम सम्भावित विलम्बता र न्यूनतम लागतको साथ मागमा प्रयोग र लन्च गर्नुपर्दछ।

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

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

भर्चुअलाइजेशन क्लाउड बनाइएको भवन ब्लकहरू मध्ये एक हो।

केवल एक L2 डोमेनमा धेरै हाइपरभाइजरहरू सङ्कलन गरेर क्लाउड बनाउनु, स्वचालित रूपमा भर्चुअल मेसिनहरू सिर्जना गर्नका लागि कुनै प्रकारको जवाफदेहिता मार्फत स्वचालित रूपमा भल्यानहरू दर्ता गर्न र यसमा अर्केस्ट्रेसन प्रणाली जस्ता केही जाम गर्नका लागि केही yaml प्लेबुकहरू थपेर काम गर्दैन। यो अधिक सटीक हुनेछ, तर फलस्वरूप फ्रैंकनस्टाइन हामीलाई चाहिने क्लाउड होइन, यद्यपि यो अरूको लागि अन्तिम सपना हुन सक्छ। यसबाहेक, यदि तपाईंले उही ओपनस्ट्याक लिनुभयो भने, यो अनिवार्य रूपमा अझै पनि फ्रान्कनस्टाइन हो, तर ओह, अहिलेको लागि यसको बारेमा कुरा नगरौं।

तर म बुझ्छु कि माथि प्रस्तुत परिभाषाबाट यो पूरै स्पष्ट छैन कि वास्तवमा के क्लाउड भनिन्छ।

तसर्थ, NIST (National Institute of Standards and Technology) को कागजातले 5 मुख्य विशेषताहरू प्रदान गर्दछ जुन क्लाउड पूर्वाधारमा हुनुपर्छ:

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

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

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

विभिन्न अवस्थाहरूमा द्रुत अनुकूलन। सेवाहरू लचिलो हुनुपर्छ - स्रोतहरूको द्रुत प्रावधान, तिनीहरूको पुन: वितरण, ग्राहकको अनुरोधमा स्रोतहरू थप्ने वा घटाउने, र क्लाउड स्रोतहरू अनन्त छन् भन्ने भावना क्लाइन्टको पक्षमा हुनुपर्छ। बुझ्न सजिलोको लागि, उदाहरणका लागि, तपाईले चेतावनी देख्नुभएन कि Apple iCloud मा तपाईको डिस्क स्पेसको भाग गायब भएको छ किनभने सर्भरमा हार्ड ड्राइभ बिग्रिएको छ, र ड्राइभहरू बिग्रन्छ। थप रूपमा, तपाईंको तर्फबाट, यस सेवाको सम्भावनाहरू लगभग असीमित छन् - तपाईंलाई २ TB चाहिन्छ - कुनै समस्या छैन, तपाईंले भुक्तान गर्नुभयो र प्राप्त गर्नुभयो। यस्तै उदाहरण Google.Drive वा Yandex.Disk को साथ दिन सकिन्छ।

प्रदान गरिएको सेवा मापन गर्ने सम्भावना। क्लाउड प्रणालीहरूले उपभोग गरिएका स्रोतहरूलाई स्वचालित रूपमा नियन्त्रण र अनुकूलन गर्नुपर्दछ, र यी संयन्त्रहरू प्रयोगकर्ता र सेवा प्रदायक दुवैका लागि पारदर्शी हुनुपर्छ। त्यो हो, तपाइँ जहिले पनि तपाइँ र तपाइँका ग्राहकहरूले कति स्रोतहरू खपत गर्दै हुनुहुन्छ भनेर जाँच गर्न सक्नुहुन्छ।

यो तथ्यलाई विचार गर्न लायक छ कि यी आवश्यकताहरू प्रायः सार्वजनिक क्लाउडका लागि आवश्यकताहरू हुन्, त्यसैले निजी क्लाउडको लागि (अर्थात, कम्पनीको आन्तरिक आवश्यकताहरूको लागि क्लाउड सुरु गरिएको हो), यी आवश्यकताहरू थोरै समायोजन गर्न सकिन्छ। यद्यपि, तिनीहरू अझै पनि गर्नैपर्छ, अन्यथा हामीले क्लाउड कम्प्युटिङका ​​सबै फाइदाहरू पाउने छैनौं।

हामीलाई किन बादल चाहिन्छ?

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

क्रम मा प्रत्येक हेरौं:

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

सेवा को रूप मा प्लेटफार्म (PaaS) - यो मोडेल प्रयोग गर्दा, सेवा प्रदायकले ग्राहकलाई सेवाको लागि workpiece प्रदान गर्दछ, उदाहरणका लागि, वेब सर्भर लिनुहोस्। सेवा प्रदायकले ग्राहकलाई भर्चुअल सर्भर (वास्तवमा, स्रोतहरूको सेट, जस्तै RAM/CPU/Storage/Nets, आदि) उपलब्ध गराएको छ, र यस सर्भरमा OS र आवश्यक सफ्टवेयर पनि स्थापना गरेको छ, यद्यपि, कन्फिगरेसन यो सबै सामान ग्राहक आफैले गर्छ र सेवाको प्रदर्शनको लागि ग्राहकले जवाफ दिन्छ। सेवा प्रदायक, अघिल्लो अवस्थामा जस्तै, भौतिक उपकरणहरू, हाइपरभाइजरहरू, भर्चुअल मेसिन आफैं, यसको नेटवर्क उपलब्धता, इत्यादिको कार्यसम्पादनको लागि जिम्मेवार छ, तर सेवा आफैं अब आफ्नो जिम्मेवारीको क्षेत्रमा छैन।

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

OpenStack के हो?

सबै तीन विकल्पहरूमा, सेवा प्रदायकलाई एक ओएस चाहिन्छ जसले क्लाउड पूर्वाधार निर्माण गर्न सक्षम गर्दछ। वास्तवमा, SaaS संग, एक भन्दा बढी डिभिजन टेक्नोलोजीहरूको सम्पूर्ण स्ट्याकको लागि जिम्मेवार छ - त्यहाँ एक डिभिजन छ जुन पूर्वाधारको लागि जिम्मेवार छ - त्यो हो, यसले अर्को डिभिजनलाई IaaS प्रदान गर्दछ, यो डिभिजनले ग्राहकलाई SaaS प्रदान गर्दछ। OpenStack क्लाउड अपरेटिङ सिस्टमहरू मध्ये एक हो जसले तपाईंलाई स्विचहरू, सर्भरहरू र भण्डारण प्रणालीहरू एकल स्रोत पूलमा सङ्कलन गर्न, यो साझा पूललाई ​​उपपूलहरू (भाडामा लिनेहरू) मा विभाजन गर्न र नेटवर्कमा ग्राहकहरूलाई यी स्रोतहरू प्रदान गर्न अनुमति दिन्छ।

OpenStack एक क्लाउड अपरेटिङ सिस्टम हो जसले तपाईंलाई कम्प्युटिङ स्रोतहरू, डाटा भण्डारण र नेटवर्क स्रोतहरूको ठूला पोखरीहरू नियन्त्रण गर्न अनुमति दिन्छ, एपीआई मार्फत मानक प्रमाणीकरण संयन्त्रहरू प्रयोग गरेर प्रावधान र व्यवस्थित।

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

यो सामग्री लेख्ने समयमा, OpenStack संरचना यस्तो देखिन्छ:

बाट लिइएको तस्बिर openstack.org

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

• ड्यासबोर्ड — OpenStack सेवाहरू प्रबन्ध गर्नका लागि वेब-आधारित GUI
• keystone एक केन्द्रीकृत पहिचान सेवा हो जसले अन्य सेवाहरूको लागि प्रमाणीकरण र प्राधिकरण कार्यक्षमता प्रदान गर्दछ, साथै प्रयोगकर्ता प्रमाणहरू र तिनीहरूको भूमिकाहरू व्यवस्थापन गर्दछ।
• Neutron - एक नेटवर्क सेवा जसले विभिन्न ओपनस्ट्याक सेवाहरूको इन्टरफेसहरू (VMs बीचको जडान र बाहिरी संसारमा तिनीहरूको पहुँच सहित) बीच जडान प्रदान गर्दछ।
• सिन्डर - भर्चुअल मेसिनहरूको लागि ब्लक भण्डारणमा पहुँच प्रदान गर्दछ
• नोभा - भर्चुअल मेसिनहरूको जीवन चक्र व्यवस्थापन
• झलक - भर्चुअल मेसिन छविहरू र स्न्यापसटहरूको भण्डार
• तेज - भण्डारण वस्तुमा पहुँच प्रदान गर्दछ
• सिलोमीटर — टेलिमेट्री सङ्कलन गर्ने र उपलब्ध र उपभोग गरिएका स्रोतहरू मापन गर्ने क्षमता प्रदान गर्ने सेवा
• गर्मी - स्वचालित सिर्जना र स्रोतहरूको प्रावधानको लागि टेम्प्लेटहरूमा आधारित अर्केस्ट्रेशन

सबै परियोजनाहरूको पूर्ण सूची र तिनीहरूको उद्देश्य हेर्न सकिन्छ यहाँ.

प्रत्येक ओपनस्ट्याक कम्पोनेन्ट एक सेवा हो जसले एक विशेष प्रकार्य प्रदर्शन गर्दछ र त्यो कार्य व्यवस्थापन गर्न र एकीकृत पूर्वाधार सिर्जना गर्न अन्य क्लाउड अपरेटिङ सिस्टम सेवाहरूसँग अन्तरक्रिया गर्न API प्रदान गर्दछ। उदाहरणका लागि, नोभाले कम्प्युटिङ स्रोत व्यवस्थापन र यी स्रोतहरू कन्फिगर गर्न पहुँचको लागि API प्रदान गर्दछ, Glance ले छवि व्यवस्थापन र तिनीहरूलाई व्यवस्थापनको लागि API प्रदान गर्दछ, Cinder ले ब्लक भण्डारण र यसलाई व्यवस्थापन गर्न API प्रदान गर्दछ। सबै प्रकार्यहरू धेरै नजिकको तरिकामा एक अर्कासँग जोडिएका छन्।

यद्यपि, यदि तपाइँ यसलाई हेर्नुहुन्छ भने, OpenStack मा चलिरहेको सबै सेवाहरू अन्ततः केहि प्रकारको भर्चुअल मेसिन (वा कन्टेनर) नेटवर्कमा जडान हुन्छन्। प्रश्न उठ्छ - किन हामीलाई यति धेरै तत्वहरू चाहिन्छ?

भर्चुअल मेसिन सिर्जना गर्न र यसलाई नेटवर्कमा जडान गर्न र ओपनस्ट्याकमा निरन्तर भण्डारणको लागि एल्गोरिदम मार्फत जाऔं।

1. जब तपाइँ मेसिन सिर्जना गर्न अनुरोध सिर्जना गर्नुहुन्छ, होराइजन (ड्यासबोर्ड) मार्फत अनुरोध वा CLI मार्फत अनुरोध गर्नुहोस्, पहिलो कुरा के हुन्छ किस्टोनमा तपाइँको अनुरोधको प्राधिकरण - के तपाइँ मेसिन बनाउन सक्नुहुन्छ, के यसमा छ? यो नेटवर्क प्रयोग गर्ने अधिकार, तपाईंको ड्राफ्ट कोटा, आदि।
2. कीस्टोनले तपाइँको अनुरोधलाई प्रमाणीकरण गर्दछ र प्रतिक्रिया सन्देशमा प्रमाणीकरण टोकन उत्पन्न गर्दछ, जुन थप प्रयोग गरिनेछ। Keystone बाट प्रतिक्रिया प्राप्त गरिसकेपछि, अनुरोध नोभा (nova api) तर्फ पठाइएको छ।
3. Nova-api ले पहिले उत्पन्न भएको प्रमाणीकरण टोकन प्रयोग गरेर कीस्टोनलाई सम्पर्क गरेर तपाईंको अनुरोधको वैधता जाँच गर्दछ।
4. किस्टोनले प्रमाणीकरण गर्छ र यस प्रमाणीकरण टोकनमा आधारित अनुमति र प्रतिबन्धहरूमा जानकारी प्रदान गर्दछ।
5. Nova-api ले nova-database मा नयाँ VM को लागि प्रविष्टि सिर्जना गर्दछ र nova-scheduler मा मेसिन सिर्जना गर्न अनुरोध पास गर्दछ।
6. Nova-scheduler ले होस्ट (कम्प्युटर नोड) चयन गर्छ जसमा VM निर्दिष्ट प्यारामिटर, तौल र क्षेत्रहरूमा आधारित हुनेछ। यसको रेकर्ड र VM ID नोभा-डेटाबेसमा लेखिएको छ।
7. अर्को, nova-scheduler ले nova-compute लाई उदाहरण प्रयोग गर्न अनुरोधको साथ सम्पर्क गर्दछ। नोभा-कम्प्युट सम्पर्कहरू नोभा-कन्डक्टरहरू मेसिन प्यारामिटरहरू बारे जानकारी प्राप्त गर्नका लागि (नोभा-कन्डक्टर एक नोभा तत्व हो जसले नोभा-डेटाबेस र नोभा-कम्प्युट बीचको प्रोक्सी सर्भरको रूपमा कार्य गर्दछ, डाटाबेसमा समस्याहरूबाट बच्न नोभा-डेटाबेसमा अनुरोधहरूको संख्या सीमित गर्दछ। स्थिरता लोड कमी)।
8. नोभा-कन्डक्टरले नोभा-डाटाबेसबाट अनुरोध गरिएको जानकारी प्राप्त गर्दछ र यसलाई नोभा-कम्प्युटमा पास गर्दछ।
9. अर्को, छवि आईडी प्राप्त गर्न नोभा-कम्प्युट कलहरू झलक। Glace ले किस्टोनमा भएको अनुरोधलाई प्रमाणित गर्छ र अनुरोध गरिएको जानकारी फिर्ता गर्छ।
10. नेटवर्क प्यारामिटरहरूको बारेमा जानकारी प्राप्त गर्न नोभा-कम्प्युट सम्पर्कहरू न्यूट्रोन। झलक जस्तै, न्युट्रोनले किस्टोनमा अनुरोधलाई प्रमाणीकरण गर्छ, त्यसपछि यसले डाटाबेस (पोर्ट पहिचानकर्ता, इत्यादि) मा प्रविष्टि सिर्जना गर्दछ, पोर्ट सिर्जना गर्न अनुरोध सिर्जना गर्दछ, र अनुरोध गरिएको जानकारी नोभा-कम्प्युटमा फर्काउँछ।
11. भर्चुअल मेसिनमा भोल्युम आवंटित गर्न अनुरोधको साथ नोभा-कम्प्युट सम्पर्क सिन्डर। झलक जस्तै, साइडरले कीस्टोनमा अनुरोधलाई मान्य गर्दछ, भोल्युम सिर्जना अनुरोध सिर्जना गर्दछ, र अनुरोध गरिएको जानकारी फिर्ता गर्दछ।
12. Nova-compute contacts libvirt निर्दिष्ट प्यारामिटरहरूसँग भर्चुअल मेसिन प्रयोग गर्न अनुरोधको साथ।

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

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

न्युट्रोन, नेटवर्क सेवाको रूपमा, क्लाउड पूर्वाधारको नेटवर्क भाग प्रबन्ध गर्नको लागि एपीआई प्रदान गर्दछ। सेवाले नेटवर्क-एज-ए-सर्भिस (NaaS) नामक एब्स्ट्रेक्शन लेयर प्रदान गरेर ओपनस्ट्याकको नेटवर्किङ भागलाई शक्ति र व्यवस्थापन गर्छ। अर्थात्, सञ्जाल एउटै भर्चुअल मापनयोग्य एकाइ हो, उदाहरणका लागि, भर्चुअल CPU कोर वा RAM को मात्रा।

तर OpenStack को नेटवर्क भागको संरचनामा जानु अघि, यो नेटवर्कले OpenStack मा कसरी काम गर्छ र किन नेटवर्क क्लाउडको महत्त्वपूर्ण र अभिन्न अंग हो भनेर विचार गरौं।

त्यसैले हामीसँग दुईवटा RED ग्राहक VM र दुई GREEN ग्राहक VM हरू छन्। मानौं कि यी मेसिनहरू दुई हाइपरभाइजरहरूमा यस तरिकामा अवस्थित छन्:

यस समयमा, यो केवल 4 सर्भरहरूको भर्चुअलाइजेशन हो र अरू केहि छैन, किनकि हामीले अहिलेसम्म 4 सर्भरहरू भर्चुअलाइज गरेका छौं, तिनीहरूलाई दुई भौतिक सर्भरहरूमा राखेर। र अहिलेसम्म तिनीहरू नेटवर्कमा जडान भएका छैनन्।

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

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

VM हरू बीचको ट्राफिक विभाजित हुनु पर्ने हुनाले, भर्चुअल मेसिनहरू तर्फका पोर्टहरूमा विभिन्न vlan नम्बरहरू हुनेछन्। ट्याग नम्बरले एउटा भर्चुअल स्विच भित्र मात्र भूमिका खेल्छ, किनकि VxLAN मा इन्क्याप्सुलेटेड हुँदा हामी यसलाई सजिलै हटाउन सक्छौं, किनकि हामीसँग VNI हुनेछ।

अब हामी कुनै पनि समस्या बिना तिनीहरूको लागि हाम्रो मेशिन र भर्चुअल नेटवर्कहरू सिर्जना गर्न सक्छौं।

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

यो केहि जटिल छैन जस्तो देखिन्छ - हामी कन्ट्रोल नोडमा ब्रिज इन्टरफेस बनाउँछौं, यसमा ट्राफिक ड्राइभ गर्छौं र त्यहाँबाट हामी यसलाई आवश्यक पर्ने ठाउँमा रुट गर्छौं। तर समस्या यो हो कि RED क्लाइन्टले 10.0.0.0/24 नेटवर्क प्रयोग गर्न चाहन्छ, र GREEN क्लाइन्टले 10.0.0.0/24 नेटवर्क प्रयोग गर्न चाहन्छ। त्यो हो, हामी ठेगाना खाली ठाउँहरू प्रतिच्छेद गर्न सुरु गर्छौं। थप रूपमा, क्लाइन्टहरू चाहँदैनन् कि अन्य क्लाइन्टहरू तिनीहरूको आन्तरिक सञ्जालहरूमा रूट गर्न सक्षम छन्, जुन अर्थपूर्ण हुन्छ। नेटवर्कहरू र क्लाइन्ट डेटा ट्राफिक अलग गर्न, हामी तिनीहरूमध्ये प्रत्येकको लागि छुट्टै नेमस्पेस आवंटित गर्नेछौं। नेमस्पेस वास्तवमा लिनक्स सञ्जाल स्ट्याकको प्रतिलिपि हो, त्यो हो, नेमस्पेस RED मा ग्राहकहरू नेमस्पेस GREEN बाट ग्राहकहरूबाट पूर्ण रूपमा अलग छन् (राम्रो, या त यी ग्राहक सञ्जालहरू बीचको रूटिङलाई पूर्वनिर्धारित नेमस्पेस वा अपस्ट्रिम यातायात उपकरणहरूमा अनुमति दिइन्छ)।

त्यो हो, हामीले निम्न रेखाचित्र पाउँछौं:

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

तर, हामीले सबैभन्दा महत्त्वपूर्ण कुरा बिर्सेका छौं। भर्चुअल मेसिनले क्लाइन्टलाई सेवा प्रदान गर्नुपर्छ, अर्थात्, योसँग कम्तिमा एउटा बाह्य इन्टरफेस हुनुपर्छ जसको माध्यमबाट यो पुग्न सकिन्छ। त्यो हो, हामीले बाहिरी संसारमा जानुपर्छ। यहाँ विभिन्न विकल्पहरू छन्। सरल विकल्प गरौं। हामी प्रत्येक ग्राहकमा एउटा नेटवर्क थप्नेछौं, जुन प्रदायकको नेटवर्कमा मान्य हुनेछ र अन्य नेटवर्कहरूसँग ओभरल्याप हुने छैन। सञ्जालहरूले प्रदायक नेटवर्कको छेउमा विभिन्न VRF हरूलाई काट्न र हेर्न सक्छन्। नेटवर्क डाटा पनि प्रत्येक ग्राहक को नाम स्थान मा रहनेछ। यद्यपि, तिनीहरू अझै पनि एक भौतिक (वा बन्ड, जुन अधिक तार्किक छ) इन्टरफेस मार्फत बाहिरी संसारमा जान्छन्। ग्राहकको ट्राफिकलाई अलग गर्न, बाहिर जाने ट्राफिकलाई ग्राहकलाई छुट्याइएको VLAN ट्यागले ट्याग गरिनेछ।

नतिजाको रूपमा, हामीले यो रेखाचित्र पायौं:

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

वास्तवमा, हाम्रो योजना पहिले नै कार्ययोग्य छ, तर त्यहाँ केही बारीकताहरू छन्:

• हामीले हाम्रा मेसिनहरूलाई कुनै न कुनै रूपमा सुरक्षित गर्न आवश्यक छ, अर्थात्, ग्राहकतर्फ स्विच इन्टरफेसमा फिल्टर राख्नुहोस्।
• भर्चुअल मेसिनको लागि स्वचालित रूपमा IP ठेगाना प्राप्त गर्न सम्भव बनाउनुहोस्, ताकि तपाईंले प्रत्येक पटक कन्सोल मार्फत लग इन गर्नु पर्दैन र ठेगाना दर्ता गर्नुहोस्।

मेसिन सुरक्षाको साथ सुरु गरौं। यसका लागि तपाईले banal iptables प्रयोग गर्न सक्नुहुन्छ, किन होइन।

त्यो हो, अब हाम्रो टोपोलोजी अलि जटिल भएको छ:

अगाडि बढौं। हामीले DHCP सर्भर थप्नु पर्छ। प्रत्येक क्लाइन्टको लागि DHCP सर्भरहरू पत्ता लगाउनको लागि सबैभन्दा आदर्श स्थान पहिले नै माथि उल्लेख गरिएको नियन्त्रण नोड हुनेछ, जहाँ नेमस्पेसहरू अवस्थित छन्:

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

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

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

नतिजाको रूपमा, हामीले एक चाखलाग्दो र एकै समयमा राम्रोसँग सोचेको समाधान प्राप्त गर्‍यौं, जसमा निश्चित लचिलोपन छ तर अझै गल्ती सहनशीलता संयन्त्र छैन।

पहिलो, हामीसँग एउटा मात्र नियन्त्रण नोड छ - यसको विफलताले सबै प्रणालीहरूको पतन निम्त्याउनेछ। यो समस्या समाधान गर्न, तपाईंले कम्तिमा 3 नोडहरूको कोरम बनाउन आवश्यक छ। यसलाई रेखाचित्रमा थपौं:

स्वाभाविक रूपमा, सबै नोडहरू सिङ्क्रोनाइज हुन्छन् र जब सक्रिय नोड छोड्छ, अर्को नोडले यसको जिम्मेवारी लिन्छ।

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

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

Ceph निर्माण गर्न तपाईंलाई 3 थप नोडहरू चाहिन्छ। भण्डारणसँग अन्तरक्रिया पनि ब्लक, वस्तु र फाइल भण्डारण सेवाहरू प्रयोग गरेर नेटवर्क मार्फत गरिनेछ। स्किमामा भण्डारण थपौं:

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

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

फलस्वरूप, हामीसँग अब दोष-सहिष्णु प्रणाली छ। यस पूर्वाधारका सबै तत्वहरू कुनै न कुनै रूपमा व्यवस्थित हुनुपर्छ। यो पहिले वर्णन गरिएको थियो कि Openstack परियोजनाहरूको एक सेट हो, जसमध्ये प्रत्येकले एक विशेष प्रकार्य प्रदान गर्दछ। हामीले देखेको रूपमा, त्यहाँ पर्याप्त तत्वहरू छन् जुन कन्फिगर र नियन्त्रण गर्न आवश्यक छ। आज हामी नेटवर्क भाग बारे कुरा गर्नेछौं।

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

OpenStack मा, यो न्यूट्रोन हो जसले भर्चुअल मेसिन पोर्टहरूलाई साझा L2 नेटवर्कमा जडान गर्न, विभिन्न L2 नेटवर्कहरूमा अवस्थित VM हरू बीचको ट्राफिक राउटिङ सुनिश्चित गर्न, साथै बाहिरी मार्ग, NAT, Floating IP, DHCP, आदि जस्ता सेवाहरू प्रदान गर्न जिम्मेवार छ।

उच्च स्तरमा, सञ्जाल सेवा (आधारभूत भाग) को सञ्चालन निम्न रूपमा वर्णन गर्न सकिन्छ।

VM सुरु गर्दा, नेटवर्क सेवा:

1. दिइएको VM (वा पोर्टहरू) को लागि पोर्ट सिर्जना गर्दछ र यसको बारेमा DHCP सेवालाई सूचित गर्दछ;
2. नयाँ भर्चुअल सञ्जाल उपकरण सिर्जना गरिएको छ (libvirt मार्फत);
3. VM चरण 1 मा सिर्जना गरिएको पोर्ट(हरू) मा जडान हुन्छ;

अनौठो कुरा, न्युट्रोनको काम लिनक्समा डुब्ने सबैलाई परिचित मानक संयन्त्रहरूमा आधारित छ - नेमस्पेसहरू, iptables, linux ब्रिजहरू, openvswitch, conntrack, आदि।

यो तुरुन्तै स्पष्ट हुनुपर्छ कि न्यूट्रोन एक SDN नियन्त्रक होइन।

न्युट्रोन धेरै अन्तरसम्बन्धित घटकहरू हुन्छन्:

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

न्यूट्रोन-सर्भर वास्तवमा पाइथनमा लेखिएको एउटा अनुप्रयोग हो, जसमा दुई भागहरू छन्:

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

REST सेवा अन्य कम्पोनेन्टहरूबाट API कलहरू प्राप्त गर्न डिजाइन गरिएको हो (उदाहरणका लागि, केही जानकारी प्रदान गर्न अनुरोध, आदि)।

प्लगइनहरू प्लग-इन सफ्टवेयर कम्पोनेन्टहरू/मोड्युलहरू हुन् जुन API अनुरोधहरूको समयमा बोलाइन्छ - त्यो हो, सेवाको एट्रिब्युसन तिनीहरू मार्फत हुन्छ। प्लगइनहरू दुई प्रकारमा विभाजित छन् - सेवा र रूट। नियमको रूपमा, घोडा प्लगइन मुख्य रूपमा VM हरू बीचको ठेगाना स्पेस र L2 जडानहरू प्रबन्ध गर्न जिम्मेवार छ, र सेवा प्लगइनहरूले पहिले नै VPN वा FW जस्ता अतिरिक्त कार्यक्षमता प्रदान गर्दछ।

आज उपलब्ध प्लगइनहरूको सूची उदाहरणका लागि हेर्न सकिन्छ यहाँ

त्यहाँ धेरै सेवा प्लगइनहरू हुन सक्छन्, तर त्यहाँ केवल एक घोडा प्लगइन हुन सक्छ।

openstack-neutron-ml2 मानक ओपनस्ट्याक रूट प्लगइन हो। यो प्लगइनसँग मोड्युलर आर्किटेक्चर छ (यसको पूर्ववर्ती जस्तो नभई) र यसमा जडान भएका ड्राइभरहरू मार्फत नेटवर्क सेवा कन्फिगर गर्दछ। हामी प्लगइनलाई अलि पछि हेर्नेछौं, किनकि वास्तवमा यसले ओपनस्ट्याकको नेटवर्क भागमा रहेको लचिलोपन दिन्छ। रूट प्लगइन प्रतिस्थापन गर्न सकिन्छ (उदाहरणका लागि, कन्ट्रेल नेटवर्किङले यस्तो प्रतिस्थापन गर्दछ)।

RPC सेवा (rabbitmq-सर्भर) - एक सेवा जसले लाम व्यवस्थापन र अन्य OpenStack सेवाहरूसँग अन्तरक्रिया, साथै नेटवर्क सेवा एजेन्टहरू बीच अन्तरक्रिया प्रदान गर्दछ।

नेटवर्क एजेन्टहरू — एजेन्टहरू जुन प्रत्येक नोडमा अवस्थित छन्, जसको माध्यमबाट नेटवर्क सेवाहरू कन्फिगर गरिएका छन्।

त्यहाँ धेरै प्रकारका एजेन्टहरू छन्।

मुख्य अभिकर्ता हो L2 एजेन्ट। यी एजेन्टहरू प्रत्येक हाइपरभाइजरमा चल्छन्, जसमा नियन्त्रण नोडहरू (अधिक स्पष्ट रूपमा, भाडामा लिनेहरूका लागि कुनै पनि सेवा प्रदान गर्ने सबै नोडहरूमा) र तिनीहरूको मुख्य कार्य भर्चुअल मेसिनहरूलाई साझा L2 नेटवर्कमा जडान गर्नु हो, र कुनै पनि घटनाहरू हुँदा अलर्टहरू उत्पन्न गर्नुहोस्। उदाहरणका लागि पोर्ट असक्षम/सक्षम गर्नुहोस्)।

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

L3 एजेन्टले लिनक्स नेमस्पेसहरू प्रयोग गर्दछ प्रत्येक भाडामा लिने व्यक्तिलाई आफ्नै पृथक नेटवर्कहरूको सेट र भर्चुअल राउटरहरूको कार्यक्षमता प्रदान गर्न जसले ट्राफिकलाई मार्ग दिन्छ र लेयर 2 नेटवर्कहरूको लागि गेटवे सेवाहरू प्रदान गर्दछ।

डाटाबेस — नेटवर्कहरू, सबनेटहरू, पोर्टहरू, पोखरीहरू, आदिको पहिचानकर्ताहरूको डाटाबेस।

वास्तवमा, न्युट्रोनले कुनै पनि सञ्जाल संस्थाहरूको सिर्जनाबाट API अनुरोधहरू स्वीकार गर्दछ, अनुरोध प्रमाणीकरण गर्दछ, र RPC मार्फत (यदि यसले केही प्लगइन वा एजेन्ट पहुँच गर्दछ) वा REST API (यदि यसले SDN मा सञ्चार गर्छ) एजेन्टहरूलाई (प्लगइनहरू मार्फत) पठाउँछ। अनुरोध गरिएको सेवा व्यवस्थित गर्न आवश्यक निर्देशनहरू।

अब हामी परीक्षण स्थापनामा फर्कौं (यसलाई कसरी तैनात गरिएको छ र यसमा के समावेश छ, हामी पछि व्यावहारिक भागमा हेर्नेछौं) र प्रत्येक कम्पोनेन्ट कहाँ अवस्थित छ हेर्नुहोस्:

(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 प्लगइनमा केहि समय खर्च गर्न लायक छ।

मोड्युलर तह २

माथि उल्लेख गरिए अनुसार, प्लगइन एक मानक ओपनस्ट्याक रूट प्लगइन हो र यसको मोड्युलर आर्किटेक्चर छ।

ML2 प्लगइनको पूर्ववर्तीसँग मोनोलिथिक संरचना थियो, जसले अनुमति दिँदैन, उदाहरणका लागि, एक स्थापनामा धेरै प्रविधिहरूको मिश्रण प्रयोग गरेर। उदाहरण को लागी, तपाइँ एकै समयमा openvswitch र linuxbridge दुबै प्रयोग गर्न सक्नुहुन्न - कि त पहिलो वा दोस्रो। यस कारणको लागि, यसको वास्तुकलाको साथ ML2 प्लगइन सिर्जना गरिएको थियो।

ML2 मा दुईवटा कम्पोनेन्टहरू छन् - दुई प्रकारका ड्राइभरहरू: टाइप ड्राइभरहरू र मेकानिज्म ड्राइभरहरू।

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

प्रकार चालकहरूले निम्न नेटवर्क प्रकारहरू समावेश गर्दछ:

Flat - ट्याग बिना नेटवर्क
VLANs - ट्याग गरिएको नेटवर्क
स्थानीय — सबै-मा-एक स्थापनाहरूको लागि विशेष प्रकारको नेटवर्क (यस्ता स्थापनाहरू विकासकर्ताहरू वा प्रशिक्षणको लागि आवश्यक पर्दछ)
GRE - GRE टनेलहरू प्रयोग गरेर ओभरले नेटवर्क
VxLAN - VxLAN टनेलहरू प्रयोग गरेर ओभरले नेटवर्क

संयन्त्र चालकहरू प्रकार ड्राइभरमा निर्दिष्ट गरिएका प्रविधिहरूको संगठन सुनिश्चित गर्ने उपकरणहरू परिभाषित गर्नुहोस् - उदाहरणका लागि, openvswitch, sr-iov, opendaylight, OVN, आदि।

यो ड्राइभरको कार्यान्वयनमा निर्भर गर्दै, या त न्यूट्रोनद्वारा नियन्त्रित एजेन्टहरू प्रयोग गरिनेछ, वा बाह्य SDN नियन्त्रकमा जडानहरू प्रयोग गरिनेछ, जसले L2 नेटवर्कहरू, राउटिङ, आदि व्यवस्थित गर्न सम्बन्धित सबै समस्याहरूको ख्याल राख्छ।

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

Open vSwitch मा ब्रश गरौं

यस समयमा, OpenStack को एक प्रमुख घटक Open vSwitch हो।
जुनिपर कन्ट्रेल वा नोकिया न्युएज जस्ता कुनै अतिरिक्त विक्रेता SDN बिना OpenStack स्थापना गर्दा, OVS क्लाउड नेटवर्कको मुख्य नेटवर्क कम्पोनेन्ट हो र, iptables, conntrack, नेमस्पेसहरू सहित, तपाईंलाई पूर्ण बहु-टेनेन्सी ओभरले नेटवर्कहरू व्यवस्थित गर्न अनुमति दिन्छ। स्वाभाविक रूपमा, यो कम्पोनेन्ट प्रतिस्थापन गर्न सकिन्छ, उदाहरणका लागि, तेस्रो-पक्ष स्वामित्व (विक्रेता) SDN समाधानहरू प्रयोग गर्दा।

OVS एक खुला स्रोत सफ्टवेयर स्विच हो जुन भर्चुअल ट्राफिक फर्वार्डरको रूपमा भर्चुअलाइज्ड वातावरणमा प्रयोगको लागि डिजाइन गरिएको हो।

हाल, OVS सँग धेरै सभ्य कार्यक्षमता छ, जसमा QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, आदि जस्ता प्रविधिहरू समावेश छन्।

नोट: OVS लाई सुरुमा अत्यधिक लोड भएको टेलिकम प्रकार्यहरूको लागि सफ्ट स्विचको रूपमा कल्पना गरिएको थिएन र कम ब्यान्डविथ-माग गर्ने IT प्रकार्यहरू जस्तै WEB सर्भर वा मेल सर्भरको लागि अधिक डिजाइन गरिएको थियो। जे होस्, OVS थप विकसित भइरहेको छ र OVS को हालको कार्यान्वयनहरूले यसको कार्यसम्पादन र क्षमताहरूमा धेरै सुधार गरेको छ, जसले यसलाई उच्च लोड भएका प्रकार्यहरूसँग टेलिकम अपरेटरहरू द्वारा प्रयोग गर्न अनुमति दिन्छ, उदाहरणका लागि, त्यहाँ DPDK प्रवेगको लागि समर्थनको साथ OVS कार्यान्वयन छ।

त्यहाँ OVS को तीन महत्वपूर्ण कम्पोनेन्टहरू छन् जुन तपाईलाई सचेत हुन आवश्यक छ:

• कर्नेल मोड्युल - कर्नेल स्पेसमा अवस्थित एक घटक जसले नियन्त्रण तत्वबाट प्राप्त नियमहरूमा आधारित ट्राफिक प्रक्रिया गर्दछ;
• vस्विच डेमन (ovs-vswitchd) प्रयोगकर्ता स्पेसमा सुरु गरिएको एक प्रक्रिया हो जुन कर्नेल मोड्युल प्रोग्रामिङको लागि जिम्मेवार छ - अर्थात्, यसले स्विचको सञ्चालनको तर्कलाई प्रत्यक्ष रूपमा प्रतिनिधित्व गर्दछ।
• डाटाबेस सर्भर - OVS चलिरहेको प्रत्येक होस्टमा अवस्थित स्थानीय डाटाबेस, जसमा कन्फिगरेसन भण्डार गरिएको छ। SDN नियन्त्रकहरूले OVSDB प्रोटोकल प्रयोग गरेर यो मोड्युल मार्फत सञ्चार गर्न सक्छन्।

यो सबै निदान र व्यवस्थापन उपयोगिताहरु को एक सेट संग छ, जस्तै ovs-vsctl, ovs-appctl, ovs-ofctl, आदि।

हाल, ओपनस्ट्याक व्यापक रूपमा टेलिकम अपरेटरहरू द्वारा नेटवर्क प्रकार्यहरू यसमा स्थानान्तरण गर्न प्रयोग गरिन्छ, जस्तै EPC, SBC, HLR, इत्यादि। केहि प्रकार्यहरू OVS को साथ समस्या बिना बाँच्न सक्छन्, तर उदाहरणका लागि, EPC ग्राहक ट्राफिक प्रक्रिया गर्दछ - त्यसपछि यो पास हुन्छ। ट्राफिकको ठूलो मात्रा (अहिले ट्राफिक मात्रा प्रति सेकेन्ड धेरै सय गिगाबिट पुग्छ)। स्वाभाविक रूपमा, कर्नेल स्पेस मार्फत यस्तो ट्राफिक चलाउनु (किनकि पूर्वनिर्धारित रूपमा फर्वार्डर त्यहाँ अवस्थित छ) उत्तम विचार होइन। तसर्थ, OVS प्रायः DPDK एक्सेलेरेसन टेक्नोलोजी प्रयोग गरेर कर्नेललाई बाइपास गरेर NIC बाट प्रयोगकर्ता स्पेसमा ट्राफिक फर्वार्ड गर्न प्रयोगकर्ता स्पेसमा पूर्ण रूपमा तैनात गरिन्छ।

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

यसले वास्तविक लेआउटमा कसरी काम गर्छ?

खैर, अब व्यवहारिक भागमा जाऔं र यो सबै व्यवहारमा कसरी काम गर्दछ हेर्नुहोस्।

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

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

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

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

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

तपाइँ जाँच गर्न सक्नुहुन्छ कि नेस्टेड भर्चुअलाइजेसन सक्षम छ वा छैन यो जस्तै:

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

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

हामीले भर्चुअल मेसिनहरूबाट निम्न सर्किटहरू भेला गर्न आवश्यक छ:

मेरो केसमा, भर्चुअल मेसिनहरू जडान गर्न जुन भविष्यको स्थापनाको अंश हो (र मैले ती मध्ये 7 पाएँ, तर यदि तपाईंसँग धेरै स्रोतहरू छैनन् भने तपाईं 4 सँग प्राप्त गर्न सक्नुहुन्छ), मैले OpenvSwitch प्रयोग गरें। मैले एउटा ovs ब्रिज सिर्जना गरें र पोर्ट-समूहहरू मार्फत भर्चुअल मेसिनहरू जडान गरें। यो गर्नको लागि, मैले यो जस्तै 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 net-define मार्फत घोषणा गर्छौं:

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 ~]# 

नोट: यस परिदृश्यमा, पोर्ट ovs-br1 मा रहेको ठेगाना पहुँचयोग्य हुनेछैन किनभने यसमा vlan ट्याग छैन। यसलाई ठीक गर्न, तपाईंले आदेश जारी गर्न आवश्यक छ sudo ovs-vsctl सेट पोर्ट ovs-br1 ट्याग = 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

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

सफल स्थापना पछि, तपाईंसँग भर्चुअल मेसिन हुनुपर्छ जसमा तपाईंले अन्डरक्लाउड स्थापना गर्न सक्नुहुन्छ

[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

नोट: यदि तपाइँ ceph स्थापना गर्ने योजना बनाउनुहुन्न भने, तपाइँ ceph-सम्बन्धित आदेशहरू प्रविष्ट गर्न आवश्यक छैन। मैले क्वीन्स रिलिज प्रयोग गरें, तर तपाइँ तपाइँलाई मनपर्ने कुनै पनि प्रयोग गर्न सक्नुहुन्छ।

अर्को, प्रयोगकर्ताको गृह डाइरेक्टरी स्ट्याकमा अन्डरक्लाउड कन्फिगरेसन फाइल प्रतिलिपि गर्नुहोस्:

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

त्यसोभए, सेटिङहरू मार्फत जाऔं:

undercloud_hostname — अन्डरक्लाउड सर्भरको पूरा नाम, DNS सर्भरमा भएको प्रविष्टिसँग मेल खानुपर्छ

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

नेटवर्क_गेटवे — उही स्थानीय ठेगाना, जसले ओभरक्लाउड नोडहरू स्थापना गर्दा बाहिरी संसारमा पहुँचको लागि गेटवेको रूपमा काम गर्नेछ, स्थानीय आईपीसँग पनि मेल खान्छ।

undercloud_public_host - बाह्य API ठेगाना, प्रावधान नेटवर्कबाट कुनै पनि निःशुल्क ठेगाना तोकिएको छ

undercloud_admin_host आन्तरिक API ठेगाना, प्रावधान नेटवर्कबाट कुनै पनि निःशुल्क ठेगाना तोकिएको छ

undercloud_nameservers - DNS सर्भर

generate_service_certificate - यो रेखा हालको उदाहरणमा धेरै महत्त्वपूर्ण छ, किनभने यदि तपाईंले यसलाई गलतमा सेट गर्नुभएन भने, तपाईंले स्थापनाको क्रममा त्रुटि प्राप्त गर्नुहुनेछ, समस्या Red Hat बग ट्र्याकरमा वर्णन गरिएको छ।

local_interface नेटवर्क प्रावधान मा इन्टरफेस। यो इन्टरफेस अन्डरक्लाउड डिप्लोयमेन्टको समयमा पुन: कन्फिगर गरिनेछ, त्यसैले तपाईसँग अन्डरक्लाउडमा दुईवटा इन्टरफेसहरू हुन आवश्यक छ - एउटा यसलाई पहुँच गर्नको लागि, दोस्रो प्रावधानको लागि।

local_mtu - MTU। हामीसँग परीक्षण प्रयोगशाला छ र मसँग OVS स्विचको पोर्टहरूमा 1500 को MTU छ, यसलाई 1450 मा सेट गर्न आवश्यक छ ताकि VxLAN मा समावेश गरिएका प्याकेटहरू पास गर्न सकून्।

network_cidr - प्रावधान नेटवर्क

मजाक - बाह्य नेटवर्क पहुँच गर्न NAT प्रयोग गर्दै

masquerade_network - नेटवर्क जुन NATE हुनेछ

dhcp_start — ठेगाना पूलको सुरु ठेगाना जसबाट ओभरक्लाउड डिप्लोइमेन्टको बेला नोडहरूमा ठेगानाहरू तोकिन्छ।

dhcp_end — ठेगाना पूलको अन्तिम ठेगाना जसबाट ओभरक्लाउड डिप्लोइमेन्टको बेला नोडहरूमा ठेगानाहरू तोकिन्छ।

inspection_iprange - आत्मनिरीक्षणको लागि आवश्यक ठेगानाहरूको पोखरी (माथिको पोखरीसँग ओभरल्याप हुनु हुँदैन)

शेड्यूलर_अधिकतम_प्रयास - ओभरक्लाउड स्थापना गर्न प्रयासहरूको अधिकतम संख्या (नोडहरूको संख्या भन्दा बढी वा बराबर हुनुपर्छ)

फाइल वर्णन गरिसकेपछि, तपाईंले undercloud तैनात गर्न आदेश दिन सक्नुहुन्छ:

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 ~]$

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

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

हाम्रो भर्चुअल मेसिनहरूको डिस्कहरूसँग फोल्डरमा जानुहोस् र आवश्यक साइजको डिस्कहरू सिर्जना गर्नुहोस्:

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]# 

नोट: यदि तपाइँ यसलाई अध्ययन गर्नको लागि ceph स्थापना गर्ने योजना बनाउनुहुन्न भने, आदेशहरूले कम्तिमा दुईवटा डिस्कहरूसँग कम्तिमा 3 नोडहरू सिर्जना गर्दैनन्, तर टेम्प्लेटमा भर्चुअल डिस्कहरू vda, vdb, आदि प्रयोग गरिने संकेत गर्दछ।

राम्रो, अब हामीले यी सबै मेसिनहरूलाई परिभाषित गर्न आवश्यक छ:

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 

अन्त्यमा एउटा आदेश छ -print-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 ~]#

अब एक सानो nuance - tripleO स्थापना र आत्मनिरीक्षण समयमा सर्भर व्यवस्थापन गर्न IPMI प्रयोग गर्दछ।

Introspection नोडहरूको थप प्रावधानको लागि आवश्यक मापदण्डहरू प्राप्त गर्न हार्डवेयर निरीक्षण गर्ने प्रक्रिया हो। आत्मनिरीक्षण विडम्बना प्रयोग गरी गरिन्छ, एक सेवा नग्न धातु सर्भरहरूसँग काम गर्न डिजाइन गरिएको हो।

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

vbmc स्थापना गर्नुहोस्:

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 ~]#

मलाई लाग्छ कमाण्ड सिन्ट्याक्स स्पष्टीकरण बिना स्पष्ट छ। यद्यपि, अहिलेका लागि हाम्रा सबै सत्रहरू डाउन स्थितिमा छन्। तिनीहरूलाई UP स्थितिमा जानको लागि, तपाईंले तिनीहरूलाई सक्षम गर्न आवश्यक छ:

[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 फाइल तयार गर्छौं। हामीले पोर्टको पोप्पी ठेगाना संकेत गर्न आवश्यक छ जसको माध्यमबाट प्रावधान गरिनेछ, नोडहरूको प्यारामिटरहरू, तिनीहरूलाई नाम दिनुहोस् र कसरी ipmi मा पुग्ने संकेत गर्नुहोस्:

{
    "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 ~]$ 

यदि नोडहरू फरक अवस्थामा छन् भने, सामान्यतया व्यवस्थित गर्न सकिन्छ, त्यसपछि केहि गलत भयो र तपाईंले लग हेरेर यो किन भयो भनेर पत्ता लगाउन आवश्यक छ। ध्यान राख्नुहोस् कि यस परिदृश्यमा हामी भर्चुअलाइजेशन प्रयोग गर्दैछौं र भर्चुअल मेसिन वा vbmc को प्रयोगसँग सम्बन्धित बगहरू हुन सक्छन्।

अर्को, हामीले कुन नोडले कुन प्रकार्य प्रदर्शन गर्नेछ भनेर संकेत गर्न आवश्यक छ - त्यो हो, प्रोफाईल संकेत गर्नुहोस् जसको साथ नोड तैनात हुनेछ:

(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 ~]$

मेरो स्थापनालाई अझै एउटा सानो टच चाहिन्छ - नियन्त्रकमा मार्ग थप्दै, किनकि म काम गरिरहेको मेसिन फरक नेटवर्कमा छ। यो गर्नको लागि, तातो-व्यवस्थापक खाता अन्तर्गत control-1 मा जानुहोस् र मार्ग दर्ता गर्नुहोस्

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
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 मा छन्। अन्तिम रेखाचित्र यस्तो देखिन्छ:

वैसे, हाम्रो स्थापनामा, मेसिन ठेगानाहरू DHCP मार्फत जारी गरिएको थियो र, तपाईंले देख्न सक्नुहुन्छ, तिनीहरू "अनियमित रूपमा" जारी गरिएका छन्। तपाईले टेम्प्लेटमा कडाईका साथ परिभाषित गर्न सक्नुहुन्छ कुन ठेगाना प्रयोग गर्दा कुन मेसिनमा संलग्न हुनुपर्छ, यदि तपाईलाई आवश्यक छ भने।

भर्चुअल मेसिनहरू बीच ट्राफिक कसरी प्रवाह हुन्छ?

यस लेखमा हामी ट्राफिक पास गर्नका लागि तीन विकल्पहरू हेर्नेछौं

• एउटा L2 नेटवर्कमा एउटा हाइपरभाइजरमा दुईवटा मेसिनहरू
• एउटै L2 नेटवर्कमा फरक हाइपरभाइजरहरूमा दुई मेसिनहरू
• फरक नेटवर्कमा दुई मेसिनहरू (क्रस-नेटवर्क रूटिङ)

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

जाँच गर्न, निम्न रेखाचित्र सँगै राखौं:

हामीले 4 भर्चुअल मेसिनहरू सिर्जना गरेका छौं - 3 एउटा L2 नेटवर्कमा - नेट-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                                        |

(ओभरक्लाउड) [stack@undercloud ~]$
मेसिनहरू 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 ~]$ 

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

अर्थात्, ट्राफिकले यो नोडलाई VxLAN टनेलबाट मात्र छोड्न सक्छ र अरू केही छैन। यद्यपि, यदि तपाईंले DVR सक्रिय गर्नुभयो भने, स्थिति परिवर्तन हुनेछ, तर हामी यसलाई अर्को पटक व्यवहार गर्नेछौं। नेटवर्क आइसोलेसन प्रयोग गर्दा, उदाहरणका लागि 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 ~]$

वास्तवमा, हामी भन्न सक्छौं कि सबै कुरा उस्तै छ, तर IP ठेगाना अब भौतिक इन्टरफेसमा होइन तर भर्चुअल ब्रिजमा छ। यो गरिएको हो किनभने यो बन्दरगाह त्यो बन्दरगाह हो जसको माध्यमबाट ट्राफिक बाहिरी संसारमा जान्छ।

[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-id 0 ले संकेत गरेको छ। माथि आउटपुट।

यस समयमा अन्य सबै कुरा कम्प्युट नोडसँग मिल्दोजुल्दो छ - उही पुलहरू, उही टनेलहरू दुई कम्प्युट नोडहरूमा जाँदैछन्।

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

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

अहिलेसम्म हाम्रो नेटवर्क यस्तो देखिन्छ:

हामीसँग प्रत्येक कम्प्युटर नोडमा दुई भर्चुअल मेसिनहरू छन्। उदाहरणको रूपमा compute-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।

यहाँ ओपनस्ट्याकमा भर्चुअल नेटवर्क उपकरणहरूको प्रकारहरूमा थोरै बस्न लायक छ:
vtap - एक उदाहरण (VM) मा संलग्न भर्चुअल इन्टरफेस
qbr - लिनक्स ब्रिज
qvb र qvo - vEth जोडी लिनक्स ब्रिज र ओपन vSwitch ब्रिजमा जोडिएको छ
br-int, br-tun, br-vlan — vSwitch पुलहरू खोल्नुहोस्
patch-, int-br-, phy-br- - पुलहरू जडान गर्ने vSwitch प्याच इन्टरफेसहरू खोल्नुहोस्
qg, qr, ha, fg, sg - OVS मा जडान गर्न भर्चुअल यन्त्रहरूले प्रयोग गर्ने 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 भन्दा बढी छैन। 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 ~]$ 

हामी कम्प्यूट-० मा 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 ~]

ट्राफिक पोर्ट २ मा जानुपर्छ - हेरौं यो कस्तो प्रकारको पोर्ट हो:

[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 ~]$

यो patch-tun हो - अर्थात्, 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 मा प्याकेज गरी पोर्ट २ मा पठाइन्छ। पोर्ट २ ले कहाँ जान्छ हेरौं:

[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 ~]$

यो compute-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 ~]$

आउनुहोस् कम्प्युट-१ मा जानुहोस् र प्याकेजको साथ के हुन्छ हेर्नुहोस्:

[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 ~]$ 

Mac compute-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

ठीक छ, त्यसोभए हामी देख्छौं कि कम्प्युट-१ मा 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 चलाउनुहोस् compute-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 बाट Patek 10.0.1.88 (ICMP ट्राफिक) ठेगानामा जान्छ, र यो vni 22 को साथ VxLAN प्याकेटमा बेरिएको छ र प्याकेट होस्ट 192.168.255.19 (कम्प्युट-0) बाट होस्ट 192.168.255.26 मा जान्छ। .1 (गणना-XNUMX)। हामी जाँच गर्न सक्छौं कि VNI ovs मा निर्दिष्ट गरिएकोसँग मेल खान्छ।

यस लाइनमा फर्कौं कार्यहरू=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],आउटपुट:2। 0x16 हेक्साडेसिमल संख्या प्रणालीमा vni हो। यस नम्बरलाई १० औं प्रणालीमा रूपान्तरण गरौं:

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

अर्थात्, vni वास्तविकतासँग मेल खान्छ।

दोस्रो लाइनले रिटर्न ट्राफिक देखाउँछ, ठीक छ, त्यहाँ व्याख्या गर्न कुनै मतलब छैन, त्यहाँ सबै कुरा स्पष्ट छ।

विभिन्न नेटवर्कमा दुईवटा मेसिनहरू (अन्तर-सञ्जाल राउटिङ)

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

पहिले, हेरौं कि रूटिङले काम गर्छ:

$ 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

यस अवस्थामा प्याकेट गेटवेमा जानु पर्छ र त्यहाँ रूट गरिनु पर्छ, हामीले गेटवेको MAC ठेगाना पत्ता लगाउन आवश्यक छ, जसको लागि हामी उदाहरणमा ARP तालिका हेर्छौं:

$ 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 ~]$ 

पोर्ट २ ले कहाँ जान्छ हेरौं:

[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 सँग भौतिक पोर्ट थियो जसको माध्यमबाट नोडले बाहिर ट्राफिक पठाउन सक्छ। उदाहरणहरूको सिर्जनाले कम्प्युट नोडहरूमा कन्फिगरेसन परिवर्तन गर्‍यो - लिनक्स ब्रिज, iptables र इन्टरफेसहरू नोडहरूमा थपिएका थिए। सञ्जाल र भर्चुअल राउटरको सिर्जनाले पनि नियन्त्रण नोडको कन्फिगरेसनमा आफ्नो छाप छोड्यो।

त्यसैले, यो स्पष्ट छ कि गेटवे MAC ठेगाना नियन्त्रण नोडमा 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 बाट देखिने छ। यदि हामी ओपनस्ट्याकमा भर्चुअल पोर्टहरूको सूचीमा फर्कियौं भने, यस प्रकारको पोर्ट विभिन्न भर्चुअल उपकरणहरू OVS मा जडान गर्न प्रयोग गरिन्छ। थप सटीक हुनको लागि, qr भर्चुअल राउटरको पोर्ट हो, जुन नेमस्पेसको रूपमा प्रतिनिधित्व गरिन्छ।

सर्भरमा कुन नेमस्पेसहरू छन् हेरौं:

[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 ~]$ 

तीन प्रति जति धेरै। तर नामहरु द्वारा न्याय, तपाईं ती मध्ये प्रत्येक को उद्देश्य अनुमान गर्न सक्नुहुन्छ। हामी पछि ID 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 ~]$ 

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

[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 ~]$ 

अपेक्षित रूपमा, यातायात br-tun मा जान्छ, ट्राफिक अर्को कुन सुरुङमा जान्छ हेरौं:

[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 ~]$ 

ट्राफिक गणना-१ सुरुङमा जान्छ। खैर, compute-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 ~]$

वास्तवमा, हामी प्याकेज मार्फत सबै बाटो गयौं। मलाई लाग्छ कि तपाईंले याद गर्नुभयो कि ट्राफिक विभिन्न vxlan टनेलहरू मार्फत गयो र विभिन्न VNI हरूबाट बाहिर निस्कियो। हेरौं कुन प्रकारको VNI यी हुन्, जस पछि हामी नोडको नियन्त्रण पोर्टमा डम्प सङ्कलन गर्नेछौं र माथि वर्णन गरिए अनुसार ट्राफिक प्रवाह सुनिश्चित गर्नेछौं।
त्यसोभए, गणना-० को सुरुङमा निम्न कार्यहरू छन् = load:0->NXM_OF_VLAN_TCI[],load:0x0->NXM_NX_TUN_ID[],आउटपुट:16। 3x0 लाई दशमलव संख्या प्रणालीमा रूपान्तरण गरौं:

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

कम्प्युट-१ को सुरुङमा निम्न VNI: कार्यहरू = लोड: 1->NXM_OF_VLAN_TCI[], लोड: 0x0->NXM_NX_TUN_ID[], आउटपुट: 63 छ। 2x0 लाई दशमलव संख्या प्रणालीमा रूपान्तरण गरौं:

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 प्याकेट हो, जस भित्र ICMP प्याकेट होस्ट 10.0.1.85 बाट होस्ट 10.0.2.8 सम्म प्याकेज गरिएको छ। हामीले माथिको गणना गरे अनुसार, vni ले हामीले आउटपुटमा देखेको कुरासँग मेल खान्छ।

दोस्रो प्याकेट होस्ट 192.168.255.15 (कन्ट्रोल-1) बाट होस्ट 192.168.255.26 (कम्प्युट-1) vni 99 को साथमा vxlan प्याकेट हो, जस भित्र ICMP प्याकेट होस्ट 10.0.1.85 बाट होस्ट 10.0.2.8..XNUMX..XNUMX सम्म प्याकेज गरिएको छ। हामीले माथिको गणना गरे अनुसार, vni ले हामीले आउटपुटमा देखेको कुरासँग मेल खान्छ।

अर्को दुई प्याकेटहरू 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 ~]$ 

जसरी हामीले क्लाउड प्लेटफर्मको वास्तुकलाको बारेमा कुरा गर्यौं, यो राम्रो हुनेछ यदि मेसिनहरूले DHCP सर्भरबाट स्वचालित रूपमा ठेगानाहरू प्राप्त गरे। यी हाम्रा दुई नेटवर्कहरू 10.0.1.0/24 र 10.0.2.0/24 को लागि दुई DHCP सर्भरहरू हुन्।

यो सत्य हो भनेर जाँच गरौं। यस नेमस्पेसमा एउटा मात्र ठेगाना छ - 10.0.1.1 - DHCP सर्भरको ठेगाना, र यो 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 बाट क्लाउड समाधानसँग तुलना गर्ने बारे केही शब्दहरू भन्न चाहन्छु - मलाई यो प्रश्न विगत केही वर्षहरूमा प्रायः सोधिएको छ र, स्पष्ट रूपमा भन्नुपर्दा, म छु। पहिले नै थकित छ, तर अझै। मेरो विचारमा, यी दुई समाधानहरू तुलना गर्न धेरै गाह्रो छ, तर हामी निश्चित रूपमा भन्न सक्छौं कि दुबै समाधानहरूमा बेफाइदाहरू छन् र एउटा समाधान छनौट गर्दा तपाईंले फाइदा र विपक्षलाई तौल्नु आवश्यक छ।

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

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

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

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

स्रोत: www.habr.com