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

क्लाउड कॉम्प्युटिंग आपल्या जीवनात खोलवर आणि खोलवर प्रवेश करत आहे आणि कदाचित अशी एकही व्यक्ती नसेल ज्याने किमान एकदाही क्लाउड सेवा वापरली नसेल. तथापि, ढग म्हणजे नेमके काय आणि ते कसे कार्य करते, हे अगदी कल्पनेच्या पातळीवरही फार कमी लोकांना माहिती आहे. 5G आधीच एक वास्तविकता बनत आहे आणि टेलिकॉम इन्फ्रास्ट्रक्चर पोल सोल्यूशन्सपासून क्लाउड सोल्यूशन्सकडे जाऊ लागले आहे, जसे की ते पूर्णपणे हार्डवेअर सोल्यूशन्सपासून आभासी “पिलर” वर हलवले होते.

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

ढग म्हणजे काय? त्याच आभासीकरण - प्रोफाइल दृश्य?

तार्किक प्रश्नापेक्षा जास्त. नाही - हे व्हर्च्युअलायझेशन नाही, जरी ते त्याशिवाय केले जाऊ शकत नाही. चला दोन व्याख्या पाहू:

क्लाउड कॉम्प्युटिंग (यापुढे क्लाउड म्हणून संदर्भित) वितरित संगणकीय संसाधनांमध्ये वापरकर्ता-अनुकूल प्रवेश प्रदान करण्याचे मॉडेल आहे जे सेवा प्रदात्याला सर्वात कमी संभाव्य विलंब आणि किमान खर्चासह मागणीनुसार तैनात आणि लॉन्च केले जाणे आवश्यक आहे.

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

आम्ही हे लक्षात न घेता व्हर्च्युअलायझेशन वापरतो आणि अगदी लोखंडी राउटर देखील आधीपासून व्हर्च्युअलायझेशन वापरतात - उदाहरणार्थ, जुनोसच्या नवीनतम आवृत्तीमध्ये, ऑपरेटिंग सिस्टम रिअल-टाइम लिनक्स वितरण (विंड रिव्हर 9) वर व्हर्च्युअल मशीन म्हणून स्थापित केली आहे. पण व्हर्च्युअलायझेशन म्हणजे क्लाउड नसून क्लाउड व्हर्च्युअलायझेशनशिवाय अस्तित्वात नाही.

व्हर्च्युअलायझेशन हे बिल्डिंग ब्लॉक्सपैकी एक आहे ज्यावर क्लाउड तयार केले आहे.

एका L2 डोमेनमध्‍ये अनेक हायपरवायझर्स एकत्रित करून क्लाउड बनवणे, काही प्रकारच्या उत्तरदायित्वाद्वारे vlans स्वयंचलितपणे नोंदणी करण्यासाठी दोन yaml प्लेबुक जोडणे आणि व्हर्च्युअल मशीन स्वयंचलितपणे तयार करण्यासाठी ऑर्केस्ट्रेशन सिस्टमसारखे काहीतरी जॅम करणे कार्य करणार नाही. हे अधिक अचूक असेल, परंतु परिणामी फ्रँकेन्स्टाईन हा आपल्याला आवश्यक असलेला मेघ नाही, जरी ते इतरांसाठी अंतिम स्वप्न असू शकते. शिवाय, जर तुम्ही तेच ओपनस्टॅक घेतले तर ते मूलत: अजूनही फ्रँकेन्स्टाईन आहे, परंतु अरेरे, आत्ता त्याबद्दल बोलू नका.

परंतु मला समजले आहे की वर सादर केलेल्या व्याख्येवरून हे पूर्णपणे स्पष्ट नाही की प्रत्यक्षात ढग कशाला म्हणतात.

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

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

सेवेची विस्तृत उपलब्धता. मानक पीसी आणि पातळ क्लायंट आणि मोबाइल डिव्हाइस दोन्ही वापरण्याची परवानगी देण्यासाठी संसाधनांमध्ये प्रवेश मानक यंत्रणेद्वारे प्रदान केला जाणे आवश्यक आहे.

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

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

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

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

आम्हाला ढगाची गरज का आहे?

तथापि, कोणतेही नवीन किंवा विद्यमान तंत्रज्ञान, कोणताही नवीन प्रोटोकॉल एखाद्या गोष्टीसाठी तयार केला जातो (चांगले, अर्थातच, आरआयपी-एनजी वगळता). प्रोटोकॉलच्या फायद्यासाठी कोणालाही प्रोटोकॉलची आवश्यकता नाही (अर्थात, आरआयपी-एनजी वगळता). हे तार्किक आहे की क्लाउड वापरकर्ता/क्लायंटला काही प्रकारची सेवा प्रदान करण्यासाठी तयार केले गेले आहे. आम्ही सर्व किमान काही क्लाउड सेवांशी परिचित आहोत, उदाहरणार्थ ड्रॉपबॉक्स किंवा Google.Docs, आणि माझा विश्वास आहे की बहुतेक लोक त्यांचा यशस्वीपणे वापर करतात - उदाहरणार्थ, हा लेख Google.Docs क्लाउड सेवा वापरून लिहिला गेला आहे. परंतु आम्हाला माहित असलेल्या क्लाउड सेवा या क्लाउडच्या क्षमतांचाच भाग आहेत—अधिक तंतोतंत, त्या केवळ SaaS-प्रकारच्या सेवा आहेत. आम्ही तीन प्रकारे क्लाउड सेवा देऊ शकतो: SaaS, PaaS किंवा IaaS स्वरूपात. तुम्हाला कोणत्या सेवेची गरज आहे ते तुमच्या इच्छा आणि क्षमतांवर अवलंबून आहे.

चला प्रत्येक क्रमाने पाहू:

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

सेवा म्हणून प्लॅटफॉर्म (पीएएस) — हे मॉडेल वापरताना, सेवा प्रदाता क्लायंटला सेवेसाठी वर्कपीस प्रदान करतो, उदाहरणार्थ, वेब सर्व्हर घेऊ. सेवा प्रदात्याने क्लायंटला व्हर्च्युअल सर्व्हर (खरं तर, संसाधनांचा संच, जसे की RAM/CPU/स्टोरेज/नेट इ.) प्रदान केला आणि या सर्व्हरवर OS आणि आवश्यक सॉफ्टवेअर देखील स्थापित केले, तथापि, कॉन्फिगरेशन ही सर्व सामग्री क्लायंट स्वतः करतो आणि सेवेच्या कामगिरीसाठी क्लायंट उत्तर देतो. सेवा प्रदाता, मागील प्रकरणाप्रमाणे, भौतिक उपकरणे, हायपरव्हायझर्स, व्हर्च्युअल मशीन स्वतः, त्याची नेटवर्क उपलब्धता इत्यादींच्या कामगिरीसाठी जबाबदार आहे, परंतु सेवा स्वतःच यापुढे त्याच्या जबाबदारीच्या क्षेत्रात नाही.

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

OpenStack म्हणजे काय?

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

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

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

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

वरून घेतलेले चित्र openstack.org

OpenStack मध्ये समाविष्ट असलेले प्रत्येक घटक विशिष्ट कार्य करते. हे वितरित आर्किटेक्चर आपल्याला समाधानामध्ये आपल्याला आवश्यक असलेल्या कार्यात्मक घटकांचा संच समाविष्ट करण्यास अनुमती देते. तथापि, काही घटक हे मूळ घटक आहेत आणि ते काढून टाकल्याने संपूर्णपणे द्रावणाची पूर्ण किंवा आंशिक अकार्यक्षमता होईल. हे घटक सहसा खालीलप्रमाणे वर्गीकृत केले जातात:

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

सर्व प्रकल्पांची संपूर्ण यादी आणि त्यांचा उद्देश पाहता येईल येथे.

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

तथापि, आपण ते पाहिल्यास, OpenStack मध्ये चालणाऱ्या सर्व सेवा शेवटी नेटवर्कशी कनेक्ट केलेल्या काही प्रकारचे आभासी मशीन (किंवा कंटेनर) आहेत. प्रश्न उद्भवतो - आपल्याला इतक्या घटकांची आवश्यकता का आहे?

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

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

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

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

न्यूट्रॉन, नेटवर्क सेवा म्हणून, क्लाउड इन्फ्रास्ट्रक्चरच्या नेटवर्क भागाचे व्यवस्थापन करण्यासाठी API प्रदान करते. सेवा नेटवर्क-एज-ए-सर्व्हिस (NaaS) नावाचा अ‍ॅब्स्ट्रॅक्शन लेयर प्रदान करून ओपनस्टॅकच्या नेटवर्किंग भागाला सामर्थ्य देते आणि व्यवस्थापित करते. म्हणजेच, नेटवर्क हे समान व्हर्च्युअल मापन करण्यायोग्य युनिट आहे, उदाहरणार्थ, व्हर्च्युअल CPU कोर किंवा RAM चे प्रमाण.

परंतु ओपनस्टॅकच्या नेटवर्क भागाच्या आर्किटेक्चरकडे जाण्यापूर्वी, हे नेटवर्क ओपनस्टॅकमध्ये कसे कार्य करते आणि नेटवर्क क्लाउडचा एक महत्त्वाचा आणि अविभाज्य भाग का आहे याचा विचार करूया.

तर आमच्याकडे दोन RED क्लायंट VM आणि दोन GREEN क्लायंट VM आहेत. चला असे गृहीत धरू की ही मशीन दोन हायपरवाइजरवर या प्रकारे स्थित आहेत:

सध्या, हे फक्त 4 सर्व्हरचे व्हर्च्युअलायझेशन आहे आणि आणखी काही नाही, कारण आतापर्यंत आम्ही फक्त 4 सर्व्हरचे आभासीकरण केले आहे, त्यांना दोन भौतिक सर्व्हरवर ठेवून. आणि आतापर्यंत ते नेटवर्कशी कनेक्ट केलेले देखील नाहीत.

मेघ तयार करण्यासाठी, आपल्याला अनेक घटक जोडण्याची आवश्यकता आहे. प्रथम, आम्ही नेटवर्क भाग वर्च्युअलाइज करतो - आम्हाला ही 4 मशीन जोड्यांमध्ये जोडणे आवश्यक आहे आणि क्लायंटला L2 कनेक्शन हवे आहे. तुम्ही स्विच वापरू शकता आणि ट्रंक त्याच्या दिशेने कॉन्फिगर करू शकता आणि linux ब्रिज वापरून सर्वकाही सोडवू शकता किंवा अधिक प्रगत वापरकर्त्यांसाठी, openvswitch (आम्ही यावर नंतर परत येऊ). परंतु तेथे बरेच नेटवर्क असू शकतात आणि स्विचद्वारे L2 ला सतत ढकलणे ही सर्वोत्तम कल्पना नाही - तेथे भिन्न विभाग आहेत, एक सर्व्हिस डेस्क, अर्ज पूर्ण होण्याची प्रतीक्षा करण्यासाठी महिने, समस्यानिवारणाचे आठवडे - आधुनिक जगात हे दृष्टीकोन यापुढे कार्य करत नाही. आणि जितक्या लवकर एखाद्या कंपनीला हे समजेल तितके पुढे जाणे सोपे होईल. म्हणून, हायपरव्हायझर्समध्ये आम्ही एक L3 नेटवर्क निवडू ज्याद्वारे आमची आभासी मशीन संवाद साधतील आणि या L3 नेटवर्कच्या वर आम्ही आभासी L2 आच्छादन नेटवर्क तयार करू जिथे आमच्या व्हर्च्युअल मशीनची रहदारी चालेल. तुम्ही 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 मधील क्लायंट नेमस्पेस ग्रीन मधील क्लायंटपासून पूर्णपणे विलग आहेत (चांगले, या क्लायंट नेटवर्क्समधील राउटिंगला डीफॉल्ट नेमस्पेसद्वारे किंवा अपस्ट्रीम ट्रान्सपोर्ट उपकरणांवर परवानगी आहे).

म्हणजेच, आम्हाला खालील आकृती मिळते:

L2 बोगदे सर्व कंप्युटिंग नोड्सपासून कंट्रोल नोडमध्ये एकत्र होतात. नोड जेथे या नेटवर्कसाठी L3 इंटरफेस स्थित आहे, प्रत्येक अलगावसाठी समर्पित नेमस्पेसमध्ये आहे.

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

परिणामी, आम्हाला ही आकृती मिळाली:

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

वास्तविक, आमची योजना आधीपासूनच कार्यक्षम आहे, परंतु काही बारकावे आहेत:

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

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

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

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

न्यूट्रॉन आर्किटेक्चर

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

उच्च स्तरावर, नेटवर्क सेवेचे ऑपरेशन (मूलभूत भाग) खालीलप्रमाणे वर्णन केले जाऊ शकते.

VM सुरू करताना, नेटवर्क सेवा:

1. दिलेल्या VM (किंवा पोर्ट) साठी एक पोर्ट तयार करते आणि त्याबद्दल DHCP सेवेला सूचित करते;
2. नवीन वर्च्युअल नेटवर्क उपकरण तयार केले आहे (libvirt द्वारे);
3. VM स्टेप 1 मध्ये तयार केलेल्या पोर्टशी कनेक्ट होते;

विचित्रपणे, न्यूट्रॉनचे कार्य लिनक्समध्ये प्रवेश केलेल्या प्रत्येकासाठी परिचित असलेल्या मानक यंत्रणेवर आधारित आहे - नेमस्पेस, iptables, लिनक्स ब्रिज, ओपनव्हस्विच, कॉन्ट्रॅक इ.

हे त्वरित स्पष्ट केले पाहिजे की न्यूट्रॉन SDN नियंत्रक नाही.

न्यूट्रॉनमध्ये अनेक परस्पर जोडलेले घटक असतात:

ओपनस्टॅक-न्यूट्रॉन-सर्व्हर एक डिमन आहे जो API द्वारे वापरकर्त्याच्या विनंतीसह कार्य करतो. हा राक्षस कोणत्याही नेटवर्क कनेक्शनची नोंदणी करण्यात गुंतलेला नाही, परंतु त्यासाठी आवश्यक माहिती त्याच्या प्लगइनना प्रदान करतो, जे नंतर इच्छित नेटवर्क घटक कॉन्फिगर करतात. OpenStack नोड्सवरील न्यूट्रॉन एजंट न्यूट्रॉन सर्व्हरवर नोंदणी करतात.

न्यूट्रॉन-सर्व्हर हे खरेतर अजगरात लिहिलेले अॅप्लिकेशन आहे, ज्यामध्ये दोन भाग आहेत:

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

REST सेवा इतर घटकांकडून API कॉल प्राप्त करण्यासाठी डिझाइन केलेली आहे (उदाहरणार्थ, काही माहिती प्रदान करण्याची विनंती इ.)

प्लगइन्स हे प्लग-इन सॉफ्टवेअर घटक/मॉड्यूल असतात ज्यांना API विनंती दरम्यान कॉल केले जाते - म्हणजेच, त्यांच्याद्वारे सेवेचे श्रेय दिले जाते. प्लगइन दोन प्रकारांमध्ये विभागले गेले आहेत - सेवा आणि रूट. नियमानुसार, घोडा प्लगइन मुख्यत्वे अॅड्रेस स्पेस आणि VMs दरम्यान 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 प्लगइनवर थोडा वेळ घालवणे योग्य आहे.

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

वर नमूद केल्याप्रमाणे, प्लगइन एक मानक ओपनस्टॅक रूट प्लगइन आहे आणि त्यात मॉड्यूलर आर्किटेक्चर आहे.

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

ML2 मध्ये दोन घटक आहेत - दोन प्रकारचे ड्रायव्हर्स: टाइप ड्रायव्हर्स आणि मेकॅनिझम ड्रायव्हर्स.

ड्रायव्हर्स टाइप करा नेटवर्क कनेक्शन्स आयोजित करण्यासाठी वापरले जाणारे तंत्रज्ञान निश्चित करा, उदाहरणार्थ VxLAN, VLAN, GRE. त्याच वेळी, ड्रायव्हर वेगवेगळ्या तंत्रज्ञानाचा वापर करण्यास परवानगी देतो. आच्छादन नेटवर्क आणि vlan बाह्य नेटवर्कसाठी VxLAN encapsulation हे मानक तंत्रज्ञान आहे.

टाइप ड्रायव्हर्समध्ये खालील नेटवर्क प्रकारांचा समावेश होतो:

फ्लॅट - टॅगिंगशिवाय नेटवर्क
व्हीएलएएन - टॅग केलेले नेटवर्क
स्थानिक — सर्व-इन-वन इंस्टॉलेशन्ससाठी एक विशेष प्रकारचे नेटवर्क (अशा इंस्टॉलेशन्स विकासकांसाठी किंवा प्रशिक्षणासाठी आवश्यक आहेत)
जीआरई — GRE बोगदे वापरून आच्छादन नेटवर्क
VxLAN — VxLAN बोगदे वापरून आच्छादित नेटवर्क

यंत्रणा चालक टाईप ड्रायव्हरमध्ये निर्दिष्ट केलेल्या तंत्रज्ञानाची संघटना सुनिश्चित करणारी साधने परिभाषित करा - उदाहरणार्थ, openvswitch, sr-iov, opendaylight, OVN, इ.

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

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

चला ओपन vSwitch वर ब्रश करू

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

OVS हे एक ओपन सोर्स सॉफ्टवेअर स्विच आहे जे आभासी ट्रॅफिक फॉरवर्डर म्हणून आभासी वातावरणात वापरण्यासाठी डिझाइन केलेले आहे.

याक्षणी, OVS मध्ये अतिशय सभ्य कार्यक्षमता आहे, ज्यामध्ये QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK इत्यादी तंत्रज्ञानाचा समावेश आहे.

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

OVS चे तीन महत्वाचे घटक आहेत ज्यांची तुम्हाला जाणीव असणे आवश्यक आहे:

• कर्नल मॉड्यूल — कर्नल स्पेसमध्ये स्थित एक घटक जो नियंत्रण घटकाकडून प्राप्त झालेल्या नियमांवर आधारित रहदारीवर प्रक्रिया करतो;
• vस्विच डेमन (ovs-vswitchd) ही वापरकर्ता स्पेसमध्ये सुरू केलेली प्रक्रिया आहे जी कर्नल मॉड्यूल प्रोग्रामिंगसाठी जबाबदार आहे - म्हणजेच ती स्विचच्या ऑपरेशनचे तर्क थेट दर्शवते
• डेटाबेस सर्व्हर - OVS चालवणाऱ्या प्रत्येक होस्टवर स्थित एक स्थानिक डेटाबेस, ज्यामध्ये कॉन्फिगरेशन संग्रहित केले जाते. SDN नियंत्रक OVSDB प्रोटोकॉल वापरून या मॉड्यूलद्वारे संवाद साधू शकतात.

हे सर्व निदान आणि व्यवस्थापन उपयुक्ततांच्या संचासह आहे, जसे की ovs-vsctl, ovs-appctl, ovs-ofctl इ.

सध्या, ओपनस्टॅकचा वापर दूरसंचार ऑपरेटर्सद्वारे नेटवर्क फंक्शन्समध्ये स्थलांतरित करण्यासाठी मोठ्या प्रमाणावर केला जातो, जसे की EPC, SBC, HLR, इ. काही फंक्शन्स OVS सह समस्यांशिवाय जगू शकतात, परंतु उदाहरणार्थ, EPC ग्राहकांच्या रहदारीवर प्रक्रिया करते - नंतर ते पुढे जाते मोठ्या प्रमाणात रहदारी (आता रहदारीचे प्रमाण प्रति सेकंद कित्येक शंभर गिगाबिट्सपर्यंत पोहोचते). साहजिकच, अशा ट्रॅफिकला कर्नल स्पेसमधून चालवणे (फॉरवर्डर तेथे डीफॉल्टनुसार स्थित असल्याने) ही सर्वोत्तम कल्पना नाही. त्यामुळे, कर्नलला बायपास करून NIC वरून वापरकर्त्याच्या जागेवर रहदारी अग्रेषित करण्यासाठी DPDK प्रवेग तंत्रज्ञानाचा वापर करून OVS अनेकदा पूर्णपणे वापरकर्त्याच्या जागेत तैनात केले जाते.

टीप: टेलिकॉम फंक्शन्ससाठी उपयोजित क्लाउडसाठी, ओव्हीएसला बायपास करून कॉम्प्युट नोडमधून थेट उपकरणे स्विच करण्यासाठी ट्रॅफिक आउटपुट करणे शक्य आहे. यासाठी SR-IOV आणि पासथ्रू यंत्रणा वापरली जातात.

हे प्रत्यक्ष मांडणीवर कसे कार्य करते?

बरं, आता व्यावहारिक भागाकडे वळू आणि हे सर्व व्यवहारात कसे कार्य करते ते पाहू.

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

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

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

टीप: या लेखात, साधेपणासाठी, मी अंतर्गत ओपनस्टॅक नेटवर्कसाठी नेटवर्क अलगाव वापरला नाही, परंतु सर्वकाही फक्त एक नेटवर्क वापरून तैनात केले आहे. तथापि, नेटवर्क अलगावची उपस्थिती किंवा अनुपस्थिती समाधानाच्या मूलभूत कार्यक्षमतेवर परिणाम करत नाही - प्रत्येक गोष्ट अलगाव वापरताना सारखीच कार्य करेल, परंतु त्याच नेटवर्कवर रहदारी वाहते. व्यावसायिक स्थापनेसाठी, नैसर्गिकरित्या भिन्न vlans आणि इंटरफेस वापरून अलगाव वापरणे आवश्यक आहे. उदाहरणार्थ, 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 set port ovs-br1 tag=100 कमांड जारी करणे आवश्यक आहे. तथापि, रीबूट केल्यानंतर, हा टॅग अदृश्य होईल (जर कोणाला माहित असेल की ते जागेवर कसे ठेवावे, मी खूप आभारी आहे). परंतु हे इतके महत्त्वाचे नाही, कारण आम्हाला केवळ स्थापनेदरम्यान या पत्त्याची आवश्यकता असेल आणि जेव्हा ओपनस्टॅक पूर्णपणे तैनात असेल तेव्हा याची आवश्यकता नाही.

पुढे, आम्ही अंडरक्लाउड मशीन तयार करतो:

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

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

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

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

प्रथम, स्थापना प्रक्रियेसाठी आवश्यक साधने स्थापित करा:

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

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

आम्ही एक स्टॅक वापरकर्ता तयार करतो, पासवर्ड सेट करतो, तो sudoer मध्ये जोडतो आणि त्याला पासवर्ड एंटर न करता sudo द्वारे रूट कमांड कार्यान्वित करण्याची क्षमता देतो:

useradd stack
passwd stack

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

आता आम्ही होस्ट फाइलमध्ये संपूर्ण अंडरक्लाउड नाव निर्दिष्ट करतो:

vi /etc/hosts

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

पुढे, आम्ही भांडार जोडतो आणि आम्हाला आवश्यक असलेले सॉफ्टवेअर स्थापित करतो:

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

टीप: तुम्‍ही 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 - एमटीयू. आमच्याकडे चाचणी प्रयोगशाळा असल्याने आणि माझ्याकडे OVS स्विच पोर्ट्सवर 1500 चे MTU असल्याने, ते 1450 वर सेट करणे आवश्यक आहे जेणेकरुन VxLAN मध्ये एन्कॅप्स्युलेट केलेले पॅकेट त्यामधून जाऊ शकतील.

नेटवर्क_सिडर - तरतूद नेटवर्क

मास्करेड - बाह्य नेटवर्कमध्ये प्रवेश करण्यासाठी NAT वापरणे

masquerade_network - नेटवर्क जे NATE केले जाईल

dhcp_start — अॅड्रेस पूलचा सुरुवातीचा पत्ता ज्यावरून ओव्हरक्लाउड डिप्लॉयमेंट दरम्यान नोड्सना पत्ते नियुक्त केले जातील

dhcp_end — अॅड्रेस पूलचा अंतिम पत्ता ज्यामधून ओव्हरक्लाउड डिप्लॉयमेंट दरम्यान नोड्सना पत्ते नियुक्त केले जातील

inspection_iprange - आत्मनिरीक्षणासाठी आवश्यक पत्त्यांचा एक पूल (वरील पूलसह ओव्हरलॅप नसावा)

शेड्यूलर_मॅक्स_प्रयत्न — ओव्हरक्लाउड स्थापित करण्याच्या प्रयत्नांची कमाल संख्या (नोड्सच्या संख्येपेक्षा जास्त किंवा समान असणे आवश्यक आहे)

फाइलचे वर्णन केल्यानंतर, तुम्ही अंडरक्लाउड तैनात करण्यासाठी कमांड देऊ शकता:

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

आता एक छोटासा महत्त्व - ट्रिपलओ इंस्टॉलेशन आणि आत्मनिरीक्षण दरम्यान सर्व्हर व्यवस्थापित करण्यासाठी IPMI वापरते.

नोड्सच्या पुढील तरतूदीसाठी आवश्यक असलेले पॅरामीटर्स प्राप्त करण्यासाठी हार्डवेअरची तपासणी करण्याची प्रक्रिया म्हणजे आत्मनिरीक्षण. बेअर मेटल सर्व्हरसह कार्य करण्यासाठी डिझाइन केलेली सेवा, उपरोधिक वापरून आत्मनिरीक्षण केले जाते.

परंतु येथे समस्या आहे - हार्डवेअर 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 ~]#

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

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

आता तुमच्याकडे ओपनस्टॅकची जवळजवळ पूर्ण आवृत्ती आहे, ज्यावर तुम्ही अभ्यास, प्रयोग इ.

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

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

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

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

(undercloud) [stack@undercloud ~]$ ssh [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 ट्रॅफिक त्याच प्रकारे नोड सोडेल, परंतु काही प्रकारच्या समर्पित vlan मध्ये देखील encapsulated.

आम्ही कंप्यूट नोडची क्रमवारी लावली आहे, चला कंट्रोल नोडकडे जाऊया.

[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 टॅग नसल्यामुळे, हे बंदर एक ट्रंक पोर्ट आहे ज्यावर सर्व vlan ला परवानगी आहे, आता रहदारी टॅगशिवाय बाहेर जाते, जसे 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.

येथे OpenStack मधील व्हर्च्युअल नेटवर्क डिव्हाइसेसच्या प्रकारांवर थोडे लक्ष देणे योग्य आहे:
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 मध्ये आहे. ब्र-इंट एक स्विच म्हणून कार्य करते जे आभासी मशीन पोर्ट्स बंद करते. qvo95d96a75-a0 व्यतिरिक्त, पोर्ट qvo5bd37136-47 आउटपुटमध्ये दृश्यमान आहे. हे दुसऱ्या व्हर्च्युअल मशीनचे पोर्ट आहे. परिणामी, आमचे आकृती आता असे दिसते:

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

म्हणजेच, शेवटी योजना अशी दिसते:

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

हे दोन VM एकाच L2 नेटवर्कवर आणि एकाच हायपरवाइजरवर स्थित असल्याने, दोन्ही मशीन एकाच VLAN वर असल्याने त्यांच्यामधील रहदारी तार्किकरित्या br-int द्वारे स्थानिक पातळीवर वाहते:

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

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

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

एकाच L2 नेटवर्कवर वेगवेगळ्या हायपरवाइजरवर दोन मशीन

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

व्हर्च्युअल मशीनचे पत्ते ज्या दरम्यान आम्ही रहदारी पाहू:

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

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

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

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

आम्ही कंप्यूट -0 वर br-int मध्ये फॉरवर्डिंग टेबल पाहतो:

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

ट्रॅफिक पोर्ट 2 वर जावे - ते कोणत्या प्रकारचे पोर्ट आहे ते पाहूया:

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

हे पॅच-ट्यून आहे - म्हणजेच, br-tun मधील इंटरफेस. br-tun वर पॅकेजचे काय होते ते पाहूया:

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

पॅकेट VxLAN मध्ये पॅक केले आहे आणि पोर्ट 2 वर पाठवले आहे. पोर्ट 2 कुठे नेतो ते पाहूया:

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

कंप्युट-1 वर हा एक vxlan बोगदा आहे:

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

चला गणना -1 वर जाऊ आणि पॅकेजचे पुढे काय होते ते पाहू:

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

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 मध्ये निर्दिष्ट केलेल्याशी जुळतो.

चला या ओळीवर परत येऊ या actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],आउटपुट:2. हेक्साडेसिमल संख्या प्रणालीमध्ये 0x16 हे vni आहे. चला ही संख्या 16 व्या प्रणालीमध्ये रूपांतरित करूया:

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

म्हणजेच, vni वास्तविकतेशी संबंधित आहे.

दुसरी ओळ रिटर्न ट्रॅफिक दर्शवते, बरं, ते समजावून सांगण्यात काही अर्थ नाही, तिथे सर्व काही स्पष्ट आहे.

वेगवेगळ्या नेटवर्कवर दोन मशीन्स (इंटर-नेटवर्क रूटिंग)

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

प्रथम, राउटिंग कार्य करते ते पाहू:

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

या प्रकरणात पॅकेट गेटवेवर जाणे आवश्यक आहे आणि तेथे जाणे आवश्यक आहे, आम्हाला गेटवेचा MAC पत्ता शोधण्याची आवश्यकता आहे, ज्यासाठी आम्ही उदाहरणामध्ये एआरपी टेबल पाहतो:

$ 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 शी जोडण्यासाठी केला जातो. अधिक अचूकपणे सांगायचे तर, क्यूआर हे आभासी राउटरचे पोर्ट आहे, जे नेमस्पेस म्हणून दर्शविले जाते.

सर्व्हरवर कोणती नेमस्पेस आहेत ते पाहूया:

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

तब्बल तीन प्रती. परंतु नावांनुसार, आपण त्या प्रत्येकाच्या उद्देशाचा अंदाज लावू शकता. आम्ही नंतर आयडी 0 आणि 1 सह उदाहरणांवर परत येऊ, आता आम्हाला नेमस्पेस qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe मध्ये स्वारस्य आहे:

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

या नेमस्पेसमध्ये आपण आधी तयार केलेल्या दोन अंतर्गत जागा आहेत. दोन्ही आभासी पोर्ट br-int मध्ये जोडले गेले आहेत. चला qr-0c52b15f-8f पोर्टचा मॅक पत्ता तपासू, कारण रहदारी, गंतव्य मॅक पत्त्यानुसार, या इंटरफेसवर जाते.

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

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

म्हणजेच, या प्रकरणात, सर्वकाही मानक रूटिंगच्या नियमांनुसार कार्य करते. यजमान 10.0.2.8 साठी ट्रॅफिक नियत असल्यामुळे, ते दुसऱ्या इंटरफेस qr-92fa49b5-54 मधून बाहेर पडणे आवश्यक आहे आणि vxlan बोगद्यामधून कंप्यूट नोडवर जाणे आवश्यक आहे:

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

सर्व काही तार्किक आहे, आश्चर्य नाही. 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 ~]$ 

वाहतूक बोगद्यातून गणना-1 मध्ये जाते. बरं, 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 सह बाहेर पडली. चला हे कोणत्या प्रकारचे व्हीएनआय आहेत ते पाहू या, त्यानंतर आम्ही नोडच्या कंट्रोल पोर्टवर एक डंप गोळा करू आणि वर वर्णन केल्याप्रमाणे वाहतूक अचूकपणे वाहते याची खात्री करू.
तर, गणना-0 च्या बोगद्यामध्ये खालील क्रिया आहेत=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],आउटपुट:3. चला 0x16 दशांश संख्या प्रणालीमध्ये रूपांतरित करू:

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

गणना-1 च्या बोगद्यात खालील VNI आहेत:क्रिया=लोड:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],आउटपुट:2. चला 0x63 दशांश संख्या प्रणालीमध्ये रूपांतरित करू:

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

बरं, आता डंप पाहू:

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

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

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

पहिले पॅकेट होस्ट 192.168.255.19 (कंप्यूट-0) ते 192.168.255.15 (कंट्रोल-1) ते vni 22 सह होस्ट केलेले vxlan पॅकेट आहे, ज्यामध्ये ICMP पॅकेट होस्ट 10.0.1.85 ते होस्ट 10.0.2.8 पर्यंत पॅकेज केलेले आहे. आम्ही वर मोजल्याप्रमाणे, vni आउटपुटमध्ये जे पाहिले ते जुळते.

दुसरे पॅकेट होस्ट 192.168.255.15 (कंट्रोल-1) ते vni 192.168.255.26 सह होस्ट 1 (गणना-99) चे vxlan पॅकेट आहे, ज्यामध्ये ICMP पॅकेट होस्ट 10.0.1.85 ते होस्ट 10.0.2.8 पर्यंत पॅक केलेले आहे. आम्ही वर मोजल्याप्रमाणे, 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 हा सोन्याचा पिंजरा आहे, मालकाकडे पिंजऱ्याची चावी आहे आणि त्यासाठी तुम्हाला खूप खर्च येईल.

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

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

इतर दृष्टिकोन आहेत, त्यामुळे काय निवडायचे हे केवळ तुम्हीच ठरवू शकता आणि सर्वात महत्त्वाचे म्हणजे, तुम्ही तुमच्या निवडीसाठी जबाबदार असाल. हे फक्त माझे मत आहे - एक व्यक्ती ज्याने किमान 4 उत्पादने पाहिली आणि स्पर्श केली - नोकिया, जुनिपर, रेड हॅट आणि व्हीएमवेअर. म्हणजेच, माझ्याकडे तुलना करण्यासारखे काहीतरी आहे.

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