கிளவுட் கம்ப்யூட்டிங் நம் வாழ்வில் ஆழமாகவும் ஆழமாகவும் ஊடுருவி வருகிறது, மேலும் ஒரு முறையாவது கிளவுட் சேவைகளைப் பயன்படுத்தாத ஒரு நபர் கூட இல்லை. இருப்பினும், ஒரு மேகம் சரியாக என்ன, அது எவ்வாறு செயல்படுகிறது, பெரும்பாலும், சிலருக்கு ஒரு யோசனையின் மட்டத்தில் கூட தெரியும். 5G ஏற்கனவே ஒரு யதார்த்தமாகி வருகிறது மற்றும் தொலைத்தொடர்பு உள்கட்டமைப்பு துருவ தீர்வுகளிலிருந்து கிளவுட் தீர்வுகளுக்கு நகரத் தொடங்குகிறது, அது முழு வன்பொருள் தீர்வுகளிலிருந்து மெய்நிகராக்கப்பட்ட "தூண்களுக்கு" நகர்ந்ததைப் போலவே.
இன்று நாம் கிளவுட் உள்கட்டமைப்பின் உள் உலகத்தைப் பற்றி பேசுவோம், குறிப்பாக நெட்வொர்க் பகுதியின் அடிப்படைகளைப் பார்ப்போம்.
மேகம் என்றால் என்ன? அதே மெய்நிகராக்கம் - சுயவிவரப் பார்வையா?
தர்க்கரீதியான கேள்வியை விட அதிகம். இல்லை - இது மெய்நிகராக்கம் அல்ல, இருப்பினும் இது இல்லாமல் செய்ய முடியாது. இரண்டு வரையறைகளைப் பார்ப்போம்:
கிளவுட் கம்ப்யூட்டிங் (இனிமேல் கிளவுட் என குறிப்பிடப்படுகிறது) விநியோகிக்கப்பட்ட கம்ப்யூட்டிங் வளங்களுக்கு பயனர் நட்பு அணுகலை வழங்குவதற்கான ஒரு மாதிரியாகும், இது சேவை வழங்குநருக்கு குறைந்தபட்ச தாமதம் மற்றும் குறைந்த செலவில் தேவைக்கேற்ப பயன்படுத்தப்பட வேண்டும்.
மெய்நிகராக்க - இது ஒரு இயற்பியல் நிறுவனத்தை (உதாரணமாக, ஒரு சர்வர்) பல மெய்நிகர் ஒன்றாகப் பிரிக்கும் திறன் ஆகும், இதன் மூலம் வளங்களின் பயன்பாட்டை அதிகரிக்கிறது (உதாரணமாக, உங்களிடம் 3 சேவையகங்கள் 25-30 சதவிகிதம் ஏற்றப்பட்டுள்ளன, மெய்நிகராக்கத்திற்குப் பிறகு நீங்கள் 1 சேவையகம் ஏற்றப்படும். 80-90 சதவீதம்). இயற்கையாகவே, மெய்நிகராக்கம் சில வளங்களைச் சாப்பிடுகிறது - நீங்கள் ஹைப்பர்வைசருக்கு உணவளிக்க வேண்டும், இருப்பினும், நடைமுறையில் காட்டப்பட்டுள்ளபடி, விளையாட்டு மெழுகுவர்த்திக்கு மதிப்புள்ளது. மெய்நிகராக்கத்திற்கு ஒரு சிறந்த உதாரணம் VMWare ஆகும், இது மெய்நிகர் இயந்திரங்களை மிகச்சரியாகத் தயாரிக்கிறது அல்லது எடுத்துக்காட்டாக KVM, நான் விரும்புவது, ஆனால் இது சுவைக்குரிய விஷயம்.
மெய்நிகராக்கத்தை நாங்கள் உணராமல் பயன்படுத்துகிறோம், மேலும் இரும்பு திசைவிகள் கூட ஏற்கனவே மெய்நிகராக்கத்தைப் பயன்படுத்துகின்றன - எடுத்துக்காட்டாக, ஜூனோஸின் சமீபத்திய பதிப்பில், இயக்க முறைமை நிகழ்நேர லினக்ஸ் விநியோகத்தின் (விண்ட் ரிவர் 9) மேல் ஒரு மெய்நிகர் இயந்திரமாக நிறுவப்பட்டுள்ளது. ஆனால் மெய்நிகராக்கம் என்பது மேகம் அல்ல, ஆனால் மெய்நிகராக்கம் இல்லாமல் மேகம் இருக்க முடியாது.
மெய்நிகராக்கம் என்பது மேகம் கட்டமைக்கப்பட்ட கட்டுமானத் தொகுதிகளில் ஒன்றாகும்.
ஒரு எல்2 டொமைனில் பல ஹைப்பர்வைசர்களைச் சேகரிப்பதன் மூலம் மேகக்கணியை உருவாக்குவது, சில வகையான அன்சிபிள் மூலம் விலான்களை தானாகப் பதிவுசெய்வதற்கு இரண்டு yaml பிளேபுக்குகளைச் சேர்ப்பது மற்றும் விர்ச்சுவல் இயந்திரங்களைத் தானாக உருவாக்குவதற்கு ஆர்கெஸ்ட்ரேஷன் சிஸ்டம் போன்றவற்றை ஜாம் செய்வது வேலை செய்யாது. இது மிகவும் துல்லியமாக இருக்கும், ஆனால் இதன் விளைவாக வரும் ஃபிராங்கண்ஸ்டைன் நமக்கு தேவையான மேகம் அல்ல, இருப்பினும் இது மற்றவர்களுக்கு இறுதி கனவாக இருக்கலாம். மேலும், நீங்கள் அதே ஓபன்ஸ்டாக்கை எடுத்துக் கொண்டால், அது அடிப்படையில் இன்னும் ஃபிராங்கண்ஸ்டைன் தான், ஆனால் ஓ, இப்போது அதைப் பற்றி பேச வேண்டாம்.
ஆனால் மேலே கொடுக்கப்பட்ட வரையறையிலிருந்து உண்மையில் மேகம் என்று அழைக்கப்படுவதை முற்றிலும் தெளிவாக இல்லை என்பதை நான் புரிந்துகொள்கிறேன்.
எனவே, NIST (நேஷனல் இன்ஸ்டிடியூட் ஆஃப் ஸ்டாண்டர்ட்ஸ் அண்ட் டெக்னாலஜி) வழங்கும் ஒரு ஆவணம் கிளவுட் உள்கட்டமைப்பு கொண்டிருக்க வேண்டிய 5 முக்கிய பண்புகளை வழங்குகிறது:
கோரிக்கையின் பேரில் சேவையை வழங்குதல். பயனருக்கு ஒதுக்கப்பட்ட கணினி வளங்களுக்கு (நெட்வொர்க்குகள், மெய்நிகர் வட்டுகள், நினைவகம், செயலி கோர்கள் போன்றவை) இலவச அணுகல் வழங்கப்பட வேண்டும், மேலும் இந்த ஆதாரங்கள் தானாகவே வழங்கப்பட வேண்டும் - அதாவது, சேவை வழங்குநரின் தலையீடு இல்லாமல்.
சேவையின் பரவலான கிடைக்கும். நிலையான கணினிகள் மற்றும் மெல்லிய கிளையன்ட்கள் மற்றும் மொபைல் சாதனங்கள் இரண்டையும் பயன்படுத்த அனுமதிக்கும் வகையில், ஆதாரங்களுக்கான அணுகல் நிலையான வழிமுறைகளால் வழங்கப்பட வேண்டும்.
வளங்களை குளங்களாக இணைத்தல். வளக் குளங்கள் ஒரே நேரத்தில் பல வாடிக்கையாளர்களுக்கு வளங்களை வழங்க முடியும், வாடிக்கையாளர்கள் தனிமைப்படுத்தப்பட்டிருப்பதை உறுதிசெய்து, பரஸ்பர செல்வாக்கு மற்றும் வளங்களுக்கான போட்டி இல்லாமல் இருக்க வேண்டும். நெட்வொர்க்குகள் குளங்களில் சேர்க்கப்பட்டுள்ளன, இது ஒன்றுடன் ஒன்று முகவரிகளைப் பயன்படுத்துவதற்கான வாய்ப்பைக் குறிக்கிறது. குளங்கள் தேவைக்கேற்ப அளவிடக்கூடியதாக இருக்க வேண்டும். குளங்களின் பயன்பாடு, தேவையான அளவிலான வள தவறு சகிப்புத்தன்மை மற்றும் இயற்பியல் மற்றும் மெய்நிகர் ஆதாரங்களின் சுருக்கத்தை வழங்குவதை சாத்தியமாக்குகிறது - சேவையைப் பெறுபவருக்கு அவர் கோரிய வளங்களின் தொகுப்புடன் (இந்த வளங்கள் உடல் ரீதியாக அமைந்துள்ள இடத்தில், எத்தனை சேவையகங்கள் மற்றும் சுவிட்சுகள் - இது வாடிக்கையாளருக்கு ஒரு பொருட்டல்ல). இருப்பினும், இந்த ஆதாரங்களின் வெளிப்படையான இடஒதுக்கீட்டை வழங்குநர் உறுதி செய்ய வேண்டும் என்ற உண்மையை நாம் கணக்கில் எடுத்துக்கொள்ள வேண்டும்.
வெவ்வேறு நிலைமைகளுக்கு விரைவான தழுவல். சேவைகள் நெகிழ்வானதாக இருக்க வேண்டும் - வளங்களை விரைவாக வழங்குதல், அவற்றின் மறுபகிர்வு, வாடிக்கையாளரின் வேண்டுகோளின் பேரில் வளங்களைச் சேர்ப்பது அல்லது குறைத்தல், மற்றும் கிளையண்டின் தரப்பில் கிளவுட் வளங்கள் முடிவற்றவை என்ற உணர்வு இருக்க வேண்டும். புரிந்துகொள்வதற்கு, எடுத்துக்காட்டாக, சேவையகத்தில் உள்ள ஹார்ட் டிரைவ் செயலிழந்ததால், உங்கள் வட்டு இடத்தின் ஒரு பகுதி Apple iCloud இல் மறைந்துவிட்டது என்ற எச்சரிக்கையை நீங்கள் காணவில்லை. கூடுதலாக, உங்கள் பங்கில், இந்த சேவையின் சாத்தியக்கூறுகள் கிட்டத்தட்ட வரம்பற்றவை - உங்களுக்கு 2 TB தேவை - பிரச்சனை இல்லை, நீங்கள் பணம் செலுத்தி அதைப் பெற்றீர்கள். இதே போன்ற உதாரணத்தை Google.Drive அல்லது Yandex.Disk உடன் கொடுக்கலாம்.
வழங்கப்பட்ட சேவையை அளவிடுவதற்கான சாத்தியம். கிளவுட் அமைப்புகள் தானாகக் கட்டுப்படுத்தி, நுகரப்படும் வளங்களை மேம்படுத்த வேண்டும், மேலும் இந்த வழிமுறைகள் பயனர் மற்றும் சேவை வழங்குநர் இருவருக்கும் வெளிப்படையாக இருக்க வேண்டும். அதாவது, நீங்களும் உங்கள் வாடிக்கையாளர்களும் எவ்வளவு ஆதாரங்களை பயன்படுத்துகிறீர்கள் என்பதை நீங்கள் எப்போதும் சரிபார்க்கலாம்.
இந்த தேவைகள் பெரும்பாலும் பொது மேகக்கணிக்கான தேவைகள் என்ற உண்மையை கருத்தில் கொள்வது மதிப்பு, எனவே ஒரு தனியார் கிளவுட் (அதாவது, நிறுவனத்தின் உள் தேவைகளுக்காக தொடங்கப்பட்ட மேகம்), இந்த தேவைகளை சற்று சரிசெய்யலாம். இருப்பினும், அவை இன்னும் செய்யப்பட வேண்டும், இல்லையெனில் கிளவுட் கம்ப்யூட்டிங்கின் அனைத்து நன்மைகளையும் நாங்கள் பெற மாட்டோம்.
நமக்கு ஏன் மேகம் தேவை?
இருப்பினும், ஏதேனும் புதிய அல்லது ஏற்கனவே உள்ள தொழில்நுட்பம், ஏதேனும் ஒரு புதிய நெறிமுறை உருவாக்கப்பட்டது (சரி, RIP-ng தவிர, நிச்சயமாக). ஒரு நெறிமுறைக்காக யாருக்கும் ஒரு நெறிமுறை தேவையில்லை (நிச்சயமாக, RIP-ng தவிர). பயனர்/வாடிக்கையாளருக்கு சில வகையான சேவைகளை வழங்குவதற்காக கிளவுட் உருவாக்கப்பட்டது என்பது தர்க்கரீதியானது. நாம் அனைவரும் குறைந்தது இரண்டு கிளவுட் சேவைகளை நன்கு அறிந்திருக்கிறோம், எடுத்துக்காட்டாக Dropbox அல்லது Google.Docs, மற்றும் பெரும்பாலான மக்கள் அவற்றை வெற்றிகரமாகப் பயன்படுத்துவார்கள் என்று நான் நம்புகிறேன் - எடுத்துக்காட்டாக, இந்த கட்டுரை Google.Docs கிளவுட் சேவையைப் பயன்படுத்தி எழுதப்பட்டது. ஆனால் நமக்குத் தெரிந்த கிளவுட் சேவைகள் கிளவுட்டின் திறன்களின் ஒரு பகுதி மட்டுமே - இன்னும் துல்லியமாக, அவை சாஸ் வகை சேவை மட்டுமே. நாங்கள் மூன்று வழிகளில் கிளவுட் சேவையை வழங்க முடியும்: SaaS, PaaS அல்லது IaaS வடிவத்தில். உங்களுக்கு என்ன சேவை தேவை என்பது உங்கள் ஆசைகள் மற்றும் திறன்களைப் பொறுத்தது.
ஒவ்வொன்றையும் வரிசையாகப் பார்ப்போம்:
ஒரு சேவையாக மென்பொருள் (சாஸ்) வாடிக்கையாளருக்கு முழு அளவிலான சேவையை வழங்குவதற்கான ஒரு மாதிரியாகும், எடுத்துக்காட்டாக, Yandex.Mail அல்லது Gmail போன்ற மின்னஞ்சல் சேவை. இந்த சேவை வழங்கல் மாதிரியில், ஒரு வாடிக்கையாளரான நீங்கள் உண்மையில் சேவைகளைப் பயன்படுத்துவதைத் தவிர வேறு எதையும் செய்யவில்லை - அதாவது, சேவையை அமைப்பது, அதன் தவறு சகிப்புத்தன்மை அல்லது பணிநீக்கம் பற்றி நீங்கள் சிந்திக்க வேண்டியதில்லை. முக்கிய விஷயம் உங்கள் கடவுச்சொல்லை சமரசம் செய்யக்கூடாது; இந்த சேவையின் வழங்குநர் உங்களுக்காக மீதமுள்ளதைச் செய்வார். சேவை வழங்குநரின் பார்வையில், சேவையக வன்பொருள் மற்றும் ஹோஸ்ட் இயக்க முறைமைகள் முதல் தரவுத்தளம் மற்றும் மென்பொருள் அமைப்புகள் வரை - முழு சேவைக்கும் அவர் முழுப் பொறுப்பு.
ஒரு சேவையாக இயங்குதளம் (PaaS) — இந்த மாதிரியைப் பயன்படுத்தும் போது, சேவை வழங்குநர் வாடிக்கையாளருக்கு சேவைக்கான பணியிடத்தை வழங்குகிறது, எடுத்துக்காட்டாக, ஒரு வலை சேவையகத்தை எடுத்துக்கொள்வோம். சேவை வழங்குநர் கிளையண்டிற்கு மெய்நிகர் சேவையகத்தை வழங்கியுள்ளார் (உண்மையில், RAM/CPU/Storage/Nets போன்ற வளங்களின் தொகுப்பு), மேலும் இந்த சேவையகத்தில் OS மற்றும் தேவையான மென்பொருளை நிறுவியிருந்தாலும், உள்ளமைவு இவை அனைத்தும் வாடிக்கையாளரால் செய்யப்படுகின்றன மற்றும் சேவையின் செயல்திறனுக்காக வாடிக்கையாளர் பதிலளிக்கிறார். சேவை வழங்குநர், முந்தைய வழக்கைப் போலவே, இயற்பியல் உபகரணங்கள், ஹைப்பர்வைசர்கள், மெய்நிகர் இயந்திரம், அதன் நெட்வொர்க் கிடைக்கும் தன்மை போன்றவற்றின் செயல்திறனுக்கு பொறுப்பாகும், ஆனால் சேவையே அதன் பொறுப்பில் இல்லை.
ஒரு சேவையாக உள்கட்டமைப்பு (IaaS) - இந்த அணுகுமுறை ஏற்கனவே மிகவும் சுவாரஸ்யமானது, உண்மையில், சேவை வழங்குநர் கிளையண்டிற்கு முழுமையான மெய்நிகராக்கப்பட்ட உள்கட்டமைப்பை வழங்குகிறது - அதாவது, CPU கோர்கள், ரேம், நெட்வொர்க்குகள் போன்ற வளங்களின் சில தொகுப்பு (குளம்) மற்ற அனைத்தும் வரை உள்ளன. கிளையன்ட் - கிளையன்ட் இந்த வளங்களை ஒதுக்கப்பட்ட குளத்தில் (ஒதுக்கீடு) என்ன செய்ய விரும்புகிறார் - இது சப்ளையருக்கு குறிப்பாக முக்கியமல்ல. வாடிக்கையாளர் தனது சொந்த vEPC ஐ உருவாக்க விரும்புகிறாரா அல்லது ஒரு மினி ஆபரேட்டரை உருவாக்கி தகவல் தொடர்பு சேவைகளை வழங்க விரும்புகிறாரா - கேள்வியே இல்லை - அதைச் செய்யுங்கள். அத்தகைய சூழ்நிலையில், ஆதாரங்களை வழங்குவதற்கு சேவை வழங்குநர் பொறுப்பு, அவற்றின் தவறு சகிப்புத்தன்மை மற்றும் கிடைக்கும் தன்மை, அத்துடன் இந்த ஆதாரங்களை ஒருங்கிணைக்க மற்றும் எந்த நேரத்திலும் வளங்களை அதிகரிக்க அல்லது குறைக்கும் திறனுடன் வாடிக்கையாளருக்கு கிடைக்கச் செய்யும் OS. வாடிக்கையாளரின் வேண்டுகோளின் பேரில். கிளையன்ட் அனைத்து மெய்நிகர் இயந்திரங்கள் மற்றும் பிற டின்செல்களை சுய-சேவை போர்டல் மற்றும் கன்சோல் மூலம் கட்டமைக்கிறார், இதில் நெட்வொர்க்குகளை அமைப்பது உட்பட (வெளிப்புற நெட்வொர்க்குகள் தவிர).
OpenStack என்றால் என்ன?
மூன்று விருப்பங்களிலும், சேவை வழங்குநருக்கு கிளவுட் உள்கட்டமைப்பை உருவாக்க உதவும் OS தேவை. உண்மையில், SaaS உடன், ஒன்றுக்கு மேற்பட்ட பிரிவுகள் தொழில்நுட்பங்களின் முழு அடுக்கிற்கும் பொறுப்பாகும் - உள்கட்டமைப்பிற்கு பொறுப்பான ஒரு பிரிவு உள்ளது - அதாவது, இது மற்றொரு பிரிவுக்கு IaaS ஐ வழங்குகிறது, இந்த பிரிவு வாடிக்கையாளருக்கு SaaS ஐ வழங்குகிறது. ஓபன்ஸ்டாக் என்பது கிளவுட் ஆப்பரேட்டிங் சிஸ்டங்களில் ஒன்றாகும், இது சுவிட்சுகள், சர்வர்கள் மற்றும் சேமிப்பக அமைப்புகளை ஒரே ஆதாரக் குழுவாகச் சேகரிக்கவும், இந்த பொதுவான குளத்தை சப்பூல்களாக (குத்தகைதாரர்கள்) பிரிக்கவும் மற்றும் நெட்வொர்க்கில் வாடிக்கையாளர்களுக்கு இந்த ஆதாரங்களை வழங்கவும் உங்களை அனுமதிக்கிறது.
OpenStack க்குக்கான ஒரு கிளவுட் ஆப்பரேட்டிங் சிஸ்டம், இது பெரிய அளவிலான கம்ப்யூட்டிங் வளங்கள், தரவு சேமிப்பு மற்றும் நெட்வொர்க் ஆதாரங்களைக் கட்டுப்படுத்த உங்களை அனுமதிக்கிறது, நிலையான அங்கீகார வழிமுறைகளைப் பயன்படுத்தி API மூலம் நிர்வகிக்கப்படுகிறது.
வேறு வார்த்தைகளில் கூறுவதானால், இது இலவச மென்பொருள் திட்டங்களின் தொகுப்பாகும், இது கிளவுட் சேவைகளை (பொது மற்றும் தனியார்) உருவாக்க வடிவமைக்கப்பட்டுள்ளது - அதாவது, சேவையகத்தையும் மாற்றும் உபகரணங்களையும் ஒருங்கிணைக்க உங்களை அனுமதிக்கும் கருவிகளின் தொகுப்பாகும் இந்த ஆதாரங்கள், தேவையான அளவு தவறு சகிப்புத்தன்மையை வழங்குகிறது.
இந்த உள்ளடக்கத்தை எழுதும் நேரத்தில், OpenStack அமைப்பு இதுபோல் தெரிகிறது:
படம் எடுக்கப்பட்டது
OpenStack இல் சேர்க்கப்பட்டுள்ள ஒவ்வொரு கூறுகளும் ஒரு குறிப்பிட்ட செயல்பாட்டைச் செய்கின்றன. இந்த விநியோகிக்கப்பட்ட கட்டமைப்பு உங்களுக்கு தேவையான செயல்பாட்டு கூறுகளின் தொகுப்பை தீர்வில் சேர்க்க அனுமதிக்கிறது. இருப்பினும், சில கூறுகள் ரூட் கூறுகள் மற்றும் அவற்றை அகற்றுவது தீர்வு முழுவதுமாக அல்லது பகுதியளவு இயலாமைக்கு வழிவகுக்கும். இந்த கூறுகள் பொதுவாக வகைப்படுத்தப்படுகின்றன:
- கட்டுப்பாட்டகம் - OpenStack சேவைகளை நிர்வகிப்பதற்கான இணைய அடிப்படையிலான GUI
- கீஸ்டோன் ஒரு மையப்படுத்தப்பட்ட அடையாளச் சேவையாகும், இது மற்ற சேவைகளுக்கான அங்கீகாரம் மற்றும் அங்கீகார செயல்பாட்டை வழங்குகிறது, அத்துடன் பயனர் நற்சான்றிதழ்கள் மற்றும் அவற்றின் பாத்திரங்களை நிர்வகிக்கிறது.
- நியூட்ரான் - பல்வேறு OpenStack சேவைகளின் இடைமுகங்களுக்கிடையே இணைப்பை வழங்கும் ஒரு பிணைய சேவை (VMகளுக்கு இடையேயான இணைப்பு மற்றும் வெளி உலகத்திற்கான அவற்றின் அணுகல் உட்பட)
- தழல் — மெய்நிகர் இயந்திரங்களுக்கான தொகுதி சேமிப்பகத்திற்கான அணுகலை வழங்குகிறது
- புதிய - மெய்நிகர் இயந்திரங்களின் வாழ்க்கை சுழற்சி மேலாண்மை
- பார்வை — மெய்நிகர் இயந்திர படங்கள் மற்றும் ஸ்னாப்ஷாட்களின் களஞ்சியம்
- ஸ்விஃப்ட் — சேமிப்பக பொருளுக்கான அணுகலை வழங்குகிறது
- சீலோமீட்டர் - டெலிமெட்ரியை சேகரிக்கும் திறனை வழங்கும் மற்றும் கிடைக்கும் மற்றும் நுகரப்படும் வளங்களை அளவிடும் ஒரு சேவை
- வெப்ப — தன்னியக்க உருவாக்கம் மற்றும் வளங்களை வழங்குவதற்கான வார்ப்புருக்களின் அடிப்படையில் ஆர்கெஸ்ட்ரேஷன்
அனைத்து திட்டங்களின் முழுமையான பட்டியலையும் அவற்றின் நோக்கத்தையும் பார்க்கலாம் .
ஒவ்வொரு OpenStack கூறுகளும் ஒரு குறிப்பிட்ட செயல்பாட்டைச் செய்யும் ஒரு சேவையாகும் மற்றும் அந்தச் செயல்பாட்டை நிர்வகிக்க ஒரு API ஐ வழங்குகிறது மற்றும் ஒரு ஒருங்கிணைந்த உள்கட்டமைப்பை உருவாக்க மற்ற கிளவுட் இயக்க முறைமை சேவைகளுடன் தொடர்பு கொள்கிறது. எடுத்துக்காட்டாக, நோவா கணினி வள மேலாண்மை மற்றும் இந்த ஆதாரங்களை உள்ளமைப்பதற்கான அணுகலுக்கான API ஐ வழங்குகிறது, Glance பட மேலாண்மை மற்றும் அவற்றை நிர்வகிப்பதற்கான API ஐ வழங்குகிறது, Cinder தொகுதி சேமிப்பகத்தையும் அதை நிர்வகிப்பதற்கான API போன்றவற்றையும் வழங்குகிறது. அனைத்து செயல்பாடுகளும் மிக நெருக்கமான வழியில் ஒன்றோடொன்று இணைக்கப்பட்டுள்ளன.
இருப்பினும், நீங்கள் அதைப் பார்த்தால், OpenStack இல் இயங்கும் அனைத்து சேவைகளும் இறுதியில் பிணையத்துடன் இணைக்கப்பட்ட ஒருவித மெய்நிகர் இயந்திரம் (அல்லது கொள்கலன்) ஆகும். கேள்வி எழுகிறது - நமக்கு ஏன் பல கூறுகள் தேவை?
ஒரு மெய்நிகர் இயந்திரத்தை உருவாக்கி அதை நெட்வொர்க்குடன் இணைப்பதற்கும் Openstack இல் தொடர்ந்து சேமிப்பதற்கும் வழிமுறையைப் பார்ப்போம்.
- ஒரு இயந்திரத்தை உருவாக்குவதற்கான கோரிக்கையை நீங்கள் உருவாக்கும் போது, அது Horizon (டாஷ்போர்டு) மூலமாகவோ அல்லது CLI மூலமாகவோ கோரிக்கையாக இருந்தாலும், முதலில் நடக்கும் உங்கள் கோரிக்கையை Keystone இல் அங்கீகரிக்க வேண்டும் - நீங்கள் ஒரு இயந்திரத்தை உருவாக்க முடியுமா, அதில் உள்ளதா இந்த நெட்வொர்க்கைப் பயன்படுத்துவதற்கான உரிமை, உங்கள் வரைவு ஒதுக்கீடு போன்றவை.
- கீஸ்டோன் உங்கள் கோரிக்கையை அங்கீகரிக்கிறது மற்றும் மறுமொழி செய்தியில் அங்கீகார டோக்கனை உருவாக்குகிறது, அது மேலும் பயன்படுத்தப்படும். கீஸ்டோனிடமிருந்து பதிலைப் பெற்ற பிறகு, கோரிக்கை நோவா (நோவா ஏபிஐ) நோக்கி அனுப்பப்படுகிறது.
- Nova-api முன்பு உருவாக்கப்பட்ட அங்கீகார டோக்கனைப் பயன்படுத்தி கீஸ்டோனைத் தொடர்புகொள்வதன் மூலம் உங்கள் கோரிக்கையின் செல்லுபடியை சரிபார்க்கிறது
- கீஸ்டோன் அங்கீகாரத்தை செய்கிறது மற்றும் இந்த அங்கீகார டோக்கனின் அடிப்படையில் அனுமதிகள் மற்றும் கட்டுப்பாடுகள் பற்றிய தகவலை வழங்குகிறது.
- Nova-api, nova-databaseல் புதிய VMக்கான உள்ளீட்டை உருவாக்கி, இயந்திரத்தை உருவாக்கும் கோரிக்கையை nova-schedulerக்கு அனுப்புகிறது.
- நோவா-திட்டமிடல் குறிப்பிட்ட அளவுருக்கள், எடைகள் மற்றும் மண்டலங்களின் அடிப்படையில் VM பயன்படுத்தப்படும் ஹோஸ்ட்டை (கணினி முனை) தேர்ந்தெடுக்கிறது. இதன் பதிவும் VM ஐடியும் நோவா-டேட்டாபேஸில் எழுதப்பட்டுள்ளன.
- அடுத்து, நோவா-திட்டமிடுபவர் நோவா-கணிப்பீட்டை ஒரு நிகழ்வைப் பயன்படுத்துவதற்கான கோரிக்கையுடன் தொடர்பு கொள்கிறார். Nova-compute nova-conductor to contacts about information about machine parameters (nova-conductor என்பது nova-database மற்றும் nova-compute இடையே ப்ராக்ஸி சர்வராக செயல்படும் ஒரு nova உறுப்பு, தரவுத்தளத்தில் உள்ள சிக்கல்களைத் தவிர்ப்பதற்காக nova-database-க்கான கோரிக்கைகளின் எண்ணிக்கையைக் கட்டுப்படுத்துகிறது. நிலைத்தன்மை சுமை குறைப்பு).
- Nova-conductor கோரப்பட்ட தகவலை nova-databaseல் இருந்து பெற்று, nova-computeக்கு அனுப்புகிறது.
- அடுத்து, பட ஐடியைப் பெற நோவா-கம்ப்யூட் க்ளான்ஸ் அழைப்புகள். கீஸ்டோனில் உள்ள கோரிக்கையை Glace சரிபார்த்து, கோரப்பட்ட தகவலை வழங்கும்.
- நெட்வொர்க் அளவுருக்கள் பற்றிய தகவலைப் பெற Nova-compute contacts neutron. பார்வையைப் போலவே, நியூட்ரான் கீஸ்டோனில் உள்ள கோரிக்கையை சரிபார்க்கிறது, அதன் பிறகு அது தரவுத்தளத்தில் (போர்ட் அடையாளங்காட்டி, முதலியன) ஒரு உள்ளீட்டை உருவாக்குகிறது, ஒரு போர்ட்டை உருவாக்குவதற்கான கோரிக்கையை உருவாக்குகிறது, மேலும் கோரப்பட்ட தகவலை நோவா-கணிப்பிற்குத் தருகிறது.
- Nova-compute contacts cinder with a Volume to allocate to the Virtual machine. பார்வையைப் போலவே, கீஸ்டோனில் உள்ள கோரிக்கையை சைடர் சரிபார்க்கிறது, தொகுதி உருவாக்க கோரிக்கையை உருவாக்குகிறது மற்றும் கோரப்பட்ட தகவலை வழங்குகிறது.
- Nova-compute contacts libvirt குறிப்பிட்ட அளவுருக்கள் கொண்ட ஒரு மெய்நிகர் இயந்திரத்தை பயன்படுத்துவதற்கான கோரிக்கையுடன்.
உண்மையில், ஒரு எளிய மெய்நிகர் இயந்திரத்தை உருவாக்கும் எளிமையான செயல்பாடு, கிளவுட் இயங்குதளத்தின் கூறுகளுக்கு இடையில் API அழைப்புகளின் சுழலாக மாறும். மேலும், நீங்கள் பார்க்க முடியும் என, முன்னர் நியமிக்கப்பட்ட சேவைகள் கூட சிறிய கூறுகளைக் கொண்டிருக்கின்றன, அவற்றுக்கிடையே தொடர்பு ஏற்படுகிறது. ஒரு இயந்திரத்தை உருவாக்குவது கிளவுட் பிளாட்ஃபார்ம் உங்களை அனுமதிப்பதில் ஒரு சிறிய பகுதி மட்டுமே - போக்குவரத்தை சமநிலைப்படுத்தும் ஒரு சேவை, தொகுதி சேமிப்பகத்திற்கு பொறுப்பான ஒரு சேவை, DNS க்கு பொறுப்பான சேவை, வெற்று உலோக சேவையகங்களை வழங்குவதற்கு பொறுப்பான சேவை போன்றவை உள்ளன. மேகம் உங்கள் மெய்நிகர் இயந்திரங்களை செம்மறி ஆட்டு மந்தை போல (மெய்நிகராக்கத்திற்கு மாறாக) நடத்த அனுமதிக்கிறது. மெய்நிகர் சூழலில் உங்கள் கணினியில் ஏதேனும் நேர்ந்தால் - காப்புப்பிரதிகள் போன்றவற்றிலிருந்து அதை மீட்டெடுக்கிறீர்கள், ஆனால் கிளவுட் பயன்பாடுகள் மெய்நிகர் இயந்திரம் அத்தகைய முக்கிய பங்கை வகிக்காத வகையில் கட்டமைக்கப்பட்டுள்ளன - மெய்நிகர் இயந்திரம் "இறந்தது" - பிரச்சனை இல்லை. - ஒரு புதியது வெறுமனே உருவாக்கப்பட்டது வாகனம் டெம்ப்ளேட்டை அடிப்படையாகக் கொண்டது மற்றும் அவர்கள் சொல்வது போல், போராளியின் இழப்பை அணி கவனிக்கவில்லை. இயற்கையாகவே, இது ஆர்கெஸ்ட்ரேஷன் பொறிமுறைகளின் இருப்பை வழங்குகிறது - வெப்ப வார்ப்புருக்களைப் பயன்படுத்தி, டஜன் கணக்கான நெட்வொர்க்குகள் மற்றும் மெய்நிகர் இயந்திரங்களைக் கொண்ட சிக்கலான செயல்பாட்டை நீங்கள் எளிதாக வரிசைப்படுத்தலாம்.
நெட்வொர்க் இல்லாமல் கிளவுட் உள்கட்டமைப்பு இல்லை என்பதை எப்போதும் நினைவில் கொள்வது மதிப்பு - ஒவ்வொரு உறுப்பும் ஒரு வழியில் அல்லது மற்றொன்று பிணையத்தின் மூலம் மற்ற உறுப்புகளுடன் தொடர்பு கொள்கிறது. கூடுதலாக, கிளவுட் முற்றிலும் நிலையான அல்லாத நெட்வொர்க்கைக் கொண்டுள்ளது. இயற்கையாகவே, அண்டர்லே நெட்வொர்க் இன்னும் அதிகமாகவோ அல்லது குறைவாகவோ நிலையானது - ஒவ்வொரு நாளும் புதிய முனைகள் மற்றும் சுவிட்சுகள் சேர்க்கப்படுவதில்லை, ஆனால் மேலடுக்கு கூறு தவிர்க்க முடியாமல் மாறலாம் - புதிய நெட்வொர்க்குகள் சேர்க்கப்படும் அல்லது நீக்கப்படும், புதிய மெய்நிகர் இயந்திரங்கள் தோன்றும் மற்றும் பழையவை தோன்றும். இறக்கின்றன. கட்டுரையின் ஆரம்பத்தில் கொடுக்கப்பட்ட மேகக்கணியின் வரையறையிலிருந்து நீங்கள் நினைவில் வைத்திருப்பது போல, ஆதாரங்கள் தானாகவே பயனருக்கு ஒதுக்கப்பட வேண்டும் மற்றும் சேவை வழங்குநரிடமிருந்து குறைந்தபட்சம் (அல்லது இன்னும் சிறப்பாக, இல்லாமல்) தலையீடு செய்யப்பட வேண்டும். அதாவது, http/https வழியாக அணுகக்கூடிய உங்கள் தனிப்பட்ட கணக்கின் வடிவத்தில் இப்போது இருக்கும் பிணைய வளங்களை வழங்குவதற்கான வகை ஒரு மேகம் அல்ல. வாசிலிக்கு எட்டு கைகள் இருந்தால்.
நியூட்ரான், நெட்வொர்க் சேவையாக, கிளவுட் உள்கட்டமைப்பின் நெட்வொர்க் பகுதியை நிர்வகிப்பதற்கான API ஐ வழங்குகிறது. Network-as-a-Service (NaaS) எனப்படும் சுருக்க அடுக்கை வழங்குவதன் மூலம் சேவையானது Openstack இன் நெட்வொர்க்கிங் பகுதியை இயக்குகிறது மற்றும் நிர்வகிக்கிறது. அதாவது, நெட்வொர்க் என்பது மெய்நிகர் அளவிடக்கூடிய அலகு, எடுத்துக்காட்டாக, மெய்நிகர் CPU கோர்கள் அல்லது ரேமின் அளவு.
ஆனால் OpenStack இன் நெட்வொர்க் பகுதியின் கட்டமைப்பிற்குச் செல்வதற்கு முன், இந்த நெட்வொர்க் OpenStack இல் எவ்வாறு செயல்படுகிறது மற்றும் நெட்வொர்க் ஏன் கிளவுட்டின் முக்கியமான மற்றும் ஒருங்கிணைந்த பகுதியாக உள்ளது என்பதைக் கருத்தில் கொள்வோம்.
எனவே எங்களிடம் இரண்டு சிவப்பு கிளையன்ட் VMகள் மற்றும் இரண்டு GREEN கிளையன்ட் VMகள் உள்ளன. இந்த இயந்திரங்கள் இரண்டு ஹைப்பர்வைசர்களில் இந்த வழியில் அமைந்துள்ளன என்று வைத்துக்கொள்வோம்:
இந்த நேரத்தில், இது 4 சேவையகங்களின் மெய்நிகராக்கம் மற்றும் அதற்கு மேல் எதுவும் இல்லை, ஏனெனில் இதுவரை நாங்கள் செய்ததெல்லாம் 4 சேவையகங்களை மெய்நிகராக்கி, அவற்றை இரண்டு இயற்பியல் சேவையகங்களில் வைப்பதுதான். மேலும் இதுவரை அவை நெட்வொர்க்குடன் இணைக்கப்படவில்லை.
மேகக்கணியை உருவாக்க, நாம் பல கூறுகளைச் சேர்க்க வேண்டும். முதலில், நெட்வொர்க் பகுதியை மெய்நிகராக்குகிறோம் - இந்த 4 இயந்திரங்களை ஜோடிகளாக இணைக்க வேண்டும், மேலும் வாடிக்கையாளர்களுக்கு L2 இணைப்பு தேவை. நீங்கள் ஒரு சுவிட்சைப் பயன்படுத்தலாம் மற்றும் அதன் திசையில் ஒரு டிரங்கை உள்ளமைக்கலாம் மற்றும் லினக்ஸ் பிரிட்ஜைப் பயன்படுத்தி எல்லாவற்றையும் தீர்க்கலாம் அல்லது மேம்பட்ட பயனர்களுக்கு, openvswitch (நாங்கள் இதற்குப் பிறகு திரும்புவோம்). ஆனால் நிறைய நெட்வொர்க்குகள் இருக்கலாம், மேலும் எல் 2 ஐ ஒரு சுவிட்ச் மூலம் தொடர்ந்து தள்ளுவது சிறந்த யோசனையல்ல - வெவ்வேறு துறைகள், ஒரு சேவை மேசை, ஒரு விண்ணப்பம் முடிவடைவதற்கு மாதங்கள் காத்திருக்கிறது, பல வாரங்கள் சரிசெய்தல் - நவீன உலகில் இது அணுகுமுறை இனி வேலை செய்யாது. ஒரு நிறுவனம் எவ்வளவு விரைவில் இதைப் புரிந்துகொள்கிறதோ, அவ்வளவு எளிதாக அது முன்னேறும். எனவே, ஹைப்பர்வைசர்களுக்கு இடையில், எங்கள் மெய்நிகர் இயந்திரங்கள் தொடர்பு கொள்ளும் 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 இல் உள்ள கிளையண்டுகள் க்ளையண்ட்டுகளில் இருந்து நேம்ஸ்பேஸ் GREEN இலிருந்து முற்றிலும் தனிமைப்படுத்தப்பட்டிருக்கும் (சரி, இந்த கிளையன்ட் நெட்வொர்க்குகளுக்கு இடையே ரூட்டிங் இயல்புநிலை நேம்ஸ்பேஸ் அல்லது அப்ஸ்ட்ரீம் போக்குவரத்து சாதனங்களில் அனுமதிக்கப்படுகிறது).
அதாவது, பின்வரும் வரைபடத்தைப் பெறுகிறோம்:
L2 சுரங்கங்கள் அனைத்து கம்ப்யூட்டிங் முனைகளிலிருந்தும் கட்டுப்பாட்டு முனைக்கு ஒன்றிணைகின்றன. இந்த நெட்வொர்க்குகளுக்கான L3 இடைமுகம் அமைந்துள்ள முனை, ஒவ்வொன்றும் தனிமைப்படுத்தப்பட்ட பெயர்வெளியில் உள்ளது.
இருப்பினும், மிக முக்கியமான விஷயத்தை நாங்கள் மறந்துவிட்டோம். மெய்நிகர் இயந்திரம் வாடிக்கையாளருக்கு ஒரு சேவையை வழங்க வேண்டும், அதாவது, குறைந்தபட்சம் ஒரு வெளிப்புற இடைமுகத்தையாவது அடைய வேண்டும். அதாவது, நாம் வெளி உலகத்திற்கு செல்ல வேண்டும். இங்கே வெவ்வேறு விருப்பங்கள் உள்ளன. எளிமையான விருப்பத்தை செய்வோம். ஒவ்வொரு கிளையண்டிலும் ஒரு நெட்வொர்க்கைச் சேர்ப்போம், இது வழங்குநரின் நெட்வொர்க்கில் செல்லுபடியாகும் மற்றும் பிற நெட்வொர்க்குகளுடன் ஒன்றுடன் ஒன்று சேராது. நெட்வொர்க்குகள் குறுக்கிடலாம் மற்றும் வழங்குநர் நெட்வொர்க்கின் பக்கத்தில் வெவ்வேறு VRFகளைப் பார்க்கலாம். நெட்வொர்க் தரவு ஒவ்வொரு கிளையண்டின் பெயர்வெளியிலும் இருக்கும். இருப்பினும், அவர்கள் இன்னும் ஒரு இயற்பியல் (அல்லது பிணைப்பு, இது மிகவும் தர்க்கரீதியான) இடைமுகத்தின் மூலம் வெளி உலகிற்குச் செல்வார்கள். கிளையன்ட் டிராஃபிக்கைப் பிரிக்க, வெளியில் செல்லும் ட்ராஃபிக் வாடிக்கையாளருக்கு ஒதுக்கப்பட்ட VLAN குறிச்சொல்லுடன் குறிக்கப்படும்.
இதன் விளைவாக, எங்களுக்கு இந்த வரைபடம் கிடைத்தது:
ஒரு நியாயமான கேள்வி என்னவென்றால், ஏன் கம்ப்யூட் முனைகளில் நுழைவாயில்களை உருவாக்கக்கூடாது? இது ஒரு பெரிய பிரச்சனை இல்லை; மேலும், நீங்கள் விநியோகிக்கப்பட்ட திசைவியை (DVR) இயக்கினால், இது வேலை செய்யும். இந்த சூழ்நிலையில், Openstack இல் இயல்பாகப் பயன்படுத்தப்படும் மையப்படுத்தப்பட்ட நுழைவாயில் கொண்ட எளிய விருப்பத்தை நாங்கள் பரிசீலித்து வருகிறோம். அதிக சுமை செயல்பாடுகளுக்கு, அவர்கள் விநியோகிக்கப்பட்ட திசைவி மற்றும் SR-IOV மற்றும் Passthrough போன்ற முடுக்கம் தொழில்நுட்பங்கள் இரண்டையும் பயன்படுத்துவார்கள், ஆனால் அவர்கள் சொல்வது போல், இது முற்றிலும் வேறுபட்ட கதை. முதலில், அடிப்படை பகுதியைக் கையாள்வோம், பின்னர் விவரங்களுக்குச் செல்வோம்.
உண்மையில், எங்கள் திட்டம் ஏற்கனவே செயல்படக்கூடியது, ஆனால் சில நுணுக்கங்கள் உள்ளன:
- நாம் எப்படியாவது எங்கள் இயந்திரங்களைப் பாதுகாக்க வேண்டும், அதாவது கிளையண்டை நோக்கி சுவிட்ச் இடைமுகத்தில் ஒரு வடிகட்டியை வைக்க வேண்டும்.
- ஒரு மெய்நிகர் இயந்திரம் தானாகவே ஐபி முகவரியைப் பெறுவதை சாத்தியமாக்குங்கள், இதனால் நீங்கள் ஒவ்வொரு முறையும் கன்சோல் மூலம் உள்நுழைந்து முகவரியைப் பதிவு செய்ய வேண்டியதில்லை.
இயந்திரங்களைப் பாதுகாப்பதில் இருந்து ஆரம்பிக்கலாம். இதற்கு நீங்கள் சாதாரணமான 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 நெட்வொர்க்கை தானாக முன்வந்து பயன்படுத்த மாட்டேன், மேலும் சுவாரஸ்யமான மாற்று வழிகள் உள்ளன. ஒவ்வொருவருக்கும் சொந்தமாக இருந்தாலும், எஃப்சி அதன் அனைத்து வரம்புகளும் நமக்குத் தேவை என்று நம்புபவர்கள் இருக்கலாம் - நான் வாதிட மாட்டேன், ஒவ்வொருவருக்கும் அவரவர் கருத்து உள்ளது. இருப்பினும், Ceph போன்ற SDS ஐப் பயன்படுத்துவதே எனது கருத்தில் மிகவும் சுவாரஸ்யமான தீர்வு.
Ceph ஆனது, சாத்தியமான காப்புப்பிரதி விருப்பங்களின் ஒரு கூட்டத்துடன் மிகவும் கிடைக்கக்கூடிய தரவு சேமிப்பக தீர்வை உருவாக்க உங்களை அனுமதிக்கிறது, சமச்சீர் சரிபார்ப்புடன் கூடிய குறியீடுகளில் தொடங்கி (ரெய்டு 5 அல்லது 6 ஐ ஒத்தது) வெவ்வேறு வட்டுகளுக்கு முழு தரவு நகலெடுப்புடன் முடிவடைகிறது, வட்டுகளின் இருப்பிடத்தை கணக்கில் எடுத்துக்கொள்கிறது. சர்வர்கள், மற்றும் அலமாரிகளில் உள்ள சர்வர்கள் போன்றவை.
Ceph ஐ உருவாக்க உங்களுக்கு மேலும் 3 முனைகள் தேவை. பிளாக், ஆப்ஜெக்ட் மற்றும் ஃபைல் ஸ்டோரேஜ் சேவைகளைப் பயன்படுத்தி சேமிப்பகத்துடனான தொடர்பு நெட்வொர்க் வழியாகவும் மேற்கொள்ளப்படும். திட்டத்தில் சேமிப்பகத்தைச் சேர்ப்போம்:
குறிப்பு: நீங்கள் ஹைபர்கான்வெர்ஜ் கம்ப்யூட் நோட்களையும் உருவாக்கலாம் - இது ஒரு முனையில் பல செயல்பாடுகளை இணைக்கும் கருத்து - எடுத்துக்காட்டாக, சேமிப்பு+கணிப்பு - செஃப் சேமிப்பகத்திற்கான சிறப்பு முனைகளை ஒதுக்காமல். அதே தவறு-சகிப்புத் திட்டத்தைப் பெறுவோம் - SDS ஆனது, நாங்கள் குறிப்பிடும் முன்பதிவு மட்டத்தில் தரவை முன்பதிவு செய்யும். எவ்வாறாயினும், மிகைப்படுத்தப்பட்ட முனைகள் எப்போதும் சமரசமாக இருக்கும் - சேமிப்பக முனையானது முதல் பார்வையில் தோன்றுவது போல் காற்றை சூடாக்குவதில்லை (அதில் மெய்நிகர் இயந்திரங்கள் இல்லை என்பதால்) - இது SDS க்கு சேவை செய்வதில் CPU வளங்களைச் செலவிடுகிறது (உண்மையில், இது அனைத்தையும் செய்கிறது கணுக்கள், வட்டுகள் போன்றவற்றின் தோல்விக்குப் பிறகு பிரதி மற்றும் மீட்பு). அதாவது, நீங்கள் அதை சேமிப்பகத்துடன் இணைத்தால் கம்ப்யூட் முனையின் சில சக்தியை இழக்க நேரிடும்.
இவை அனைத்தையும் எப்படியாவது நிர்வகிக்க வேண்டும் - ஒரு இயந்திரம், நெட்வொர்க், மெய்நிகர் திசைவி போன்றவற்றை உருவாக்கக்கூடிய ஏதாவது ஒன்று நமக்குத் தேவை. இதைச் செய்ய, கட்டுப்பாட்டு முனையில் டேஷ்போர்டாகச் செயல்படும் ஒரு சேவையைச் சேர்ப்போம். கிளையன்ட் http/ https வழியாக இந்த போர்ட்டலுடன் இணைக்க முடியும் மற்றும் அவருக்கு தேவையான அனைத்தையும் செய்ய முடியும் (சரி, கிட்டத்தட்ட).
இதன் விளைவாக, நாம் இப்போது ஒரு தவறு-சகிப்பு அமைப்பு உள்ளது. இந்த உள்கட்டமைப்பின் அனைத்து கூறுகளும் எப்படியாவது நிர்வகிக்கப்பட வேண்டும். ஓபன்ஸ்டாக் என்பது திட்டங்களின் தொகுப்பாகும் என்று முன்பு விவரிக்கப்பட்டது, ஒவ்வொன்றும் ஒரு குறிப்பிட்ட செயல்பாட்டை வழங்குகிறது. நாம் பார்க்கிறபடி, கட்டமைக்க மற்றும் கட்டுப்படுத்த வேண்டிய போதுமான கூறுகள் உள்ளன. இன்று நாம் பிணைய பகுதியைப் பற்றி பேசுவோம்.
நியூட்ரான் கட்டிடக்கலை
ஓபன்ஸ்டாக்கில், விர்ச்சுவல் மெஷின் போர்ட்களை பொதுவான எல்2 நெட்வொர்க்குடன் இணைப்பதற்கும், வெவ்வேறு எல்2 நெட்வொர்க்குகளில் உள்ள விஎம்களுக்கு இடையே ட்ராஃபிக் ரூட்டிங் செய்வதற்கும், வெளிப்புற ரூட்டிங் செய்வதற்கும், NAT, Floating IP, DHCP போன்ற சேவைகளை வழங்குவதற்கும் நியூட்ரான் பொறுப்பு.
உயர் மட்டத்தில், நெட்வொர்க் சேவையின் செயல்பாடு (அடிப்படை பகுதி) பின்வருமாறு விவரிக்கப்படலாம்.
VM ஐ தொடங்கும் போது, பிணைய சேவை:
- கொடுக்கப்பட்ட VM (அல்லது போர்ட்கள்) க்கு ஒரு போர்ட்டை உருவாக்குகிறது மற்றும் அது பற்றி DHCP சேவைக்கு தெரிவிக்கிறது;
- ஒரு புதிய மெய்நிகர் நெட்வொர்க் சாதனம் உருவாக்கப்பட்டது (libvirt வழியாக);
- படி 1 இல் உருவாக்கப்பட்ட போர்ட்(கள்) உடன் VM இணைக்கிறது;
விந்தை போதும், நியூட்ரானின் பணியானது லினக்ஸில் இதுவரை டைவ் செய்த அனைவருக்கும் தெரிந்த நிலையான வழிமுறைகளை அடிப்படையாகக் கொண்டது - பெயர்வெளிகள், ஐப்டேபிள்கள், லினக்ஸ் பிரிட்ஜ்கள், openvswitch, conntrack போன்றவை.
நியூட்ரான் ஒரு SDN கட்டுப்படுத்தி அல்ல என்பதை உடனடியாக தெளிவுபடுத்த வேண்டும்.
நியூட்ரான் பல ஒன்றோடொன்று இணைக்கப்பட்ட கூறுகளைக் கொண்டுள்ளது:
ஓபன்ஸ்டாக்-நியூட்ரான்-சர்வர் API மூலம் பயனர் கோரிக்கைகளுடன் செயல்படும் டீமான். இந்த அரக்கன் எந்த பிணைய இணைப்புகளையும் பதிவு செய்வதில் ஈடுபடவில்லை, ஆனால் இதற்கு தேவையான தகவலை அதன் செருகுநிரல்களுக்கு வழங்குகிறது, பின்னர் விரும்பிய பிணைய உறுப்பை உள்ளமைக்கிறது. ஓபன்ஸ்டாக் முனைகளில் உள்ள நியூட்ரான் முகவர்கள் நியூட்ரான் சர்வரில் பதிவு செய்கிறார்கள்.
நியூட்ரான்-சர்வர் உண்மையில் பைத்தானில் எழுதப்பட்ட ஒரு பயன்பாடாகும், இதில் இரண்டு பகுதிகள் உள்ளன:
- ஓய்வு சேவை
- நியூட்ரான் செருகுநிரல் (கோர்/சேவை)
REST சேவையானது பிற கூறுகளிலிருந்து API அழைப்புகளைப் பெற வடிவமைக்கப்பட்டுள்ளது (எடுத்துக்காட்டாக, சில தகவல்களை வழங்குவதற்கான கோரிக்கை போன்றவை)
செருகுநிரல்கள் என்பது API கோரிக்கைகளின் போது அழைக்கப்படும் செருகுநிரல் மென்பொருள் கூறுகள்/தொகுதிகள் - அதாவது, சேவையின் பண்புக்கூறு அவற்றின் மூலம் நிகழ்கிறது. செருகுநிரல்கள் இரண்டு வகைகளாக பிரிக்கப்பட்டுள்ளன - சேவை மற்றும் ரூட். ஒரு விதியாக, குதிரை செருகுநிரல் முக்கியமாக முகவரி இடம் மற்றும் VM களுக்கு இடையிலான L2 இணைப்புகளை நிர்வகிப்பதற்கு பொறுப்பாகும், மேலும் சேவை செருகுநிரல்கள் ஏற்கனவே VPN அல்லது FW போன்ற கூடுதல் செயல்பாட்டை வழங்குகின்றன.
உதாரணமாக இன்று கிடைக்கும் செருகுநிரல்களின் பட்டியலைப் பார்க்கலாம்
பல சேவை செருகுநிரல்கள் இருக்கலாம், ஆனால் ஒரே ஒரு குதிரை செருகுநிரல் மட்டுமே இருக்க முடியும்.
openstack-neutron-ml2 நிலையான Openstack ரூட் செருகுநிரல் ஆகும். இந்த சொருகி ஒரு மட்டு கட்டமைப்பைக் கொண்டுள்ளது (அதன் முன்னோடி போலல்லாமல்) மற்றும் அதனுடன் இணைக்கப்பட்ட இயக்கிகள் மூலம் பிணைய சேவையை உள்ளமைக்கிறது. சொருகி சிறிது நேரம் கழித்து பார்ப்போம், உண்மையில் இது ஓபன்ஸ்டாக் நெட்வொர்க் பகுதியில் உள்ள நெகிழ்வுத்தன்மையை அளிக்கிறது. ரூட் செருகுநிரலை மாற்றலாம் (எடுத்துக்காட்டாக, கான்ட்ரெயில் நெட்வொர்க்கிங் அத்தகைய மாற்றீட்டை செய்கிறது).
RPC சேவை (rabbitmq-server) — வரிசை மேலாண்மை மற்றும் பிற 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
மேலே குறிப்பிட்டுள்ளபடி, சொருகி ஒரு நிலையான OpenStack ரூட் சொருகி மற்றும் ஒரு மட்டு கட்டமைப்பைக் கொண்டுள்ளது.
ML2 செருகுநிரலின் முன்னோடி ஒரு ஒற்றைக் கட்டமைப்பைக் கொண்டிருந்தது, எடுத்துக்காட்டாக, ஒரு நிறுவலில் பல தொழில்நுட்பங்களின் கலவையைப் பயன்படுத்த அனுமதிக்கவில்லை. எடுத்துக்காட்டாக, நீங்கள் openvswitch மற்றும் linuxbridge இரண்டையும் ஒரே நேரத்தில் பயன்படுத்த முடியாது - முதல் அல்லது இரண்டாவது. இந்த காரணத்திற்காக, அதன் கட்டிடக்கலையுடன் ML2 செருகுநிரல் உருவாக்கப்பட்டது.
ML2 இரண்டு கூறுகளைக் கொண்டுள்ளது - இரண்டு வகையான இயக்கிகள்: வகை இயக்கிகள் மற்றும் இயந்திர இயக்கிகள்.
வகை இயக்கிகள் நெட்வொர்க் இணைப்புகளை ஒழுங்கமைக்கப் பயன்படுத்தப்படும் தொழில்நுட்பங்களைத் தீர்மானிக்கவும், எடுத்துக்காட்டாக VxLAN, VLAN, GRE. அதே நேரத்தில், இயக்கி வெவ்வேறு தொழில்நுட்பங்களைப் பயன்படுத்த அனுமதிக்கிறது. நிலையான தொழில்நுட்பம் மேலடுக்கு நெட்வொர்க்குகள் மற்றும் vlan வெளிப்புற நெட்வொர்க்குகளுக்கான VxLAN என்காப்சுலேஷன் ஆகும்.
வகை இயக்கிகள் பின்வரும் பிணைய வகைகளை உள்ளடக்கியது:
பிளாட் - குறியிடாமல் பிணையம்
VLANகள் - குறியிடப்பட்ட பிணையம்
உள்ளூர் - ஆல் இன் ஒன் நிறுவல்களுக்கான ஒரு சிறப்பு வகை நெட்வொர்க் (அத்தகைய நிறுவல்கள் டெவலப்பர்களுக்கு அல்லது பயிற்சிக்கு தேவை)
ஜி ஆர் ஈ — GRE சுரங்கங்களைப் பயன்படுத்தி மேலடுக்கு நெட்வொர்க்
VxLAN — VxLAN சுரங்கங்களைப் பயன்படுத்தி மேலடுக்கு நெட்வொர்க்
இயந்திர இயக்கிகள் வகை இயக்கியில் குறிப்பிடப்பட்டுள்ள தொழில்நுட்பங்களின் அமைப்பை உறுதி செய்யும் கருவிகளை வரையறுக்கவும் - எடுத்துக்காட்டாக, openvswitch, sr-iov, opendaylight, OVN போன்றவை.
இந்த இயக்கி செயல்படுத்தப்படுவதைப் பொறுத்து, நியூட்ரானால் கட்டுப்படுத்தப்படும் முகவர்கள் பயன்படுத்தப்படும் அல்லது வெளிப்புற SDN கட்டுப்படுத்திக்கான இணைப்புகள் பயன்படுத்தப்படும், இது L2 நெட்வொர்க்குகள், ரூட்டிங் போன்றவற்றை ஒழுங்கமைப்பது தொடர்பான அனைத்து சிக்கல்களையும் கவனித்துக்கொள்கிறது.
எடுத்துக்காட்டு: OVS உடன் ML2ஐப் பயன்படுத்தினால், OVSஐ நிர்வகிக்கும் ஒவ்வொரு கணினி முனையிலும் L2 முகவர் நிறுவப்பட்டிருக்கும். இருப்பினும், நாம் பயன்படுத்தினால், எடுத்துக்காட்டாக, OVN அல்லது OpenDayLight, பின்னர் OVS இன் கட்டுப்பாடு அவற்றின் அதிகார வரம்பிற்கு உட்பட்டது - நியூட்ரான், ரூட் சொருகி மூலம், கட்டுப்படுத்திக்கு கட்டளைகளை வழங்குகிறது, மேலும் அது ஏற்கனவே சொன்னதைச் செய்கிறது.
ஓபன் vSwitchல் பிரஷ் அப் செய்யலாம்
இந்த நேரத்தில், OpenStack இன் முக்கிய கூறுகளில் ஒன்று Open vSwitch ஆகும்.
Juniper Contrail அல்லது Nokia Nuage போன்ற கூடுதல் விற்பனையாளர் SDN இல்லாமல் OpenStack ஐ நிறுவும் போது, OVS என்பது கிளவுட் நெட்வொர்க்கின் முக்கிய பிணைய அங்கமாகும், மேலும் iptables, conntrack, namespaces ஆகியவற்றுடன் சேர்ந்து, முழு அளவிலான பல-குத்தகை மேலடுக்கு நெட்வொர்க்குகளை ஒழுங்கமைக்க உங்களை அனுமதிக்கிறது. இயற்கையாகவே, இந்த கூறு மாற்றப்படலாம், எடுத்துக்காட்டாக, மூன்றாம் தரப்பு தனியுரிம (விற்பனையாளர்) SDN தீர்வுகளைப் பயன்படுத்தும் போது.
OVS என்பது ஒரு ஓப்பன் சோர்ஸ் மென்பொருள் சுவிட்ச் ஆகும், இது மெய்நிகராக்கப்பட்ட சூழல்களில் மெய்நிகர் டிராஃபிக் ஃபார்வர்டராகப் பயன்படுத்த வடிவமைக்கப்பட்டுள்ளது.
இந்த நேரத்தில், OVS மிகவும் ஒழுக்கமான செயல்பாட்டைக் கொண்டுள்ளது, இதில் QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK போன்ற தொழில்நுட்பங்கள் உள்ளன.
குறிப்பு: OVS ஆனது அதிக ஏற்றப்பட்ட தொலைத்தொடர்பு செயல்பாடுகளுக்கான சாஃப்ட் ஸ்விட்ச் ஆகக் கருதப்படவில்லை, மேலும் இது WEB சர்வர் அல்லது மெயில் சர்வர் போன்ற குறைந்த அலைவரிசை தேவைப்படும் IT செயல்பாடுகளுக்காக வடிவமைக்கப்பட்டது. இருப்பினும், OVS மேலும் மேம்படுத்தப்பட்டு வருகிறது மற்றும் OVS இன் தற்போதைய செயலாக்கங்கள் அதன் செயல்திறன் மற்றும் திறன்களை பெரிதும் மேம்படுத்தியுள்ளன, இது அதிக ஏற்றப்பட்ட செயல்பாடுகளுடன் தொலைதொடர்பு ஆபரேட்டர்களால் பயன்படுத்த அனுமதிக்கிறது, எடுத்துக்காட்டாக, DPDK முடுக்கத்திற்கான ஆதரவுடன் OVS செயல்படுத்தல் உள்ளது.
நீங்கள் அறிந்திருக்க வேண்டிய OVS இன் மூன்று முக்கிய கூறுகள் உள்ளன:
- கர்னல் தொகுதி - கட்டுப்பாட்டு உறுப்பிலிருந்து பெறப்பட்ட விதிகளின் அடிப்படையில் போக்குவரத்தை செயலாக்கும் கர்னல் இடத்தில் அமைந்துள்ள ஒரு கூறு;
- vSwitch டீமான் (ovs-vswitchd) என்பது பயனர் இடத்தில் தொடங்கப்பட்ட ஒரு செயல்முறையாகும், இது கர்னல் தொகுதி நிரலாக்கத்திற்கு பொறுப்பாகும் - அதாவது, இது சுவிட்சின் செயல்பாட்டின் தர்க்கத்தை நேரடியாக பிரதிபலிக்கிறது.
- தரவுத்தள சேவையகம் - OVS இயங்கும் ஒவ்வொரு ஹோஸ்டிலும் உள்ள உள்ளூர் தரவுத்தளம், இதில் உள்ளமைவு சேமிக்கப்படுகிறது. SDN கட்டுப்படுத்திகள் OVSDB நெறிமுறையைப் பயன்படுத்தி இந்தத் தொகுதி மூலம் தொடர்பு கொள்ளலாம்.
இவை அனைத்தும் ovs-vsctl, ovs-appctl, ovs-ofctl போன்ற கண்டறியும் மற்றும் மேலாண்மை பயன்பாடுகளின் தொகுப்புடன் உள்ளன.
தற்போது, ஓபன்ஸ்டாக் தொலைத்தொடர்பு ஆபரேட்டர்களால் EPC, SBC, HLR போன்ற நெட்வொர்க் செயல்பாடுகளை மாற்றுவதற்குப் பயன்படுத்தப்படுகிறது. சில செயல்பாடுகள் OVS இல் சிக்கல்கள் இல்லாமல் வாழலாம், ஆனால் எடுத்துக்காட்டாக, EPC சந்தாதாரர் போக்குவரத்தை செயலாக்குகிறது - பின்னர் அது கடந்து செல்கிறது. ஒரு பெரிய அளவிலான போக்குவரத்து (இப்போது போக்குவரத்து அளவுகள் வினாடிக்கு பல நூறு ஜிகாபிட்களை எட்டுகின்றன). இயற்கையாகவே, அத்தகைய போக்குவரத்தை கர்னல் ஸ்பேஸ் மூலம் இயக்குவது (முன்னோக்கி முன்னிருப்பாக இருப்பதால்) சிறந்த யோசனை அல்ல. எனவே, OVS ஆனது DPDK முடுக்கம் தொழில்நுட்பத்தைப் பயன்படுத்தி கர்னலைப் புறக்கணித்து NIC இலிருந்து பயனர் இடத்திற்கு போக்குவரத்தை அனுப்புவதற்கு முற்றிலும் பயனர் இடத்தில் பயன்படுத்தப்படுகிறது.
குறிப்பு: தொலைத்தொடர்பு செயல்பாடுகளுக்காக பயன்படுத்தப்படும் மேகக்கணிக்கு, OVS ஐப் புறக்கணித்து, நேரடியாக சாதனங்களை மாற்றுவதற்கு ஒரு கணினி முனையிலிருந்து போக்குவரத்தை வெளியிட முடியும். இந்த நோக்கத்திற்காக SR-IOV மற்றும் Passthrough வழிமுறைகள் பயன்படுத்தப்படுகின்றன.
உண்மையான அமைப்பில் இது எப்படி வேலை செய்கிறது?
சரி, இப்போது நடைமுறைப் பகுதிக்குச் சென்று, நடைமுறையில் இது எவ்வாறு செயல்படுகிறது என்பதைப் பார்ப்போம்.
முதலில், ஒரு எளிய Openstack நிறுவலைப் பயன்படுத்துவோம். சோதனைகளுக்காக என்னிடம் ஒரு செட் சர்வர்கள் இல்லை என்பதால், மெய்நிகர் இயந்திரங்களிலிருந்து ஒரு இயற்பியல் சேவையகத்தில் முன்மாதிரியை அசெம்பிள் செய்வோம். ஆமாம், இயற்கையாகவே, அத்தகைய தீர்வு வணிக நோக்கங்களுக்காக பொருந்தாது, ஆனால் Openstack இல் நெட்வொர்க் எவ்வாறு செயல்படுகிறது என்பதற்கான உதாரணத்தைப் பார்க்க, அத்தகைய நிறுவல் கண்களுக்கு போதுமானது. மேலும், அத்தகைய நிறுவல் பயிற்சி நோக்கங்களுக்காக இன்னும் சுவாரஸ்யமானது - நீங்கள் போக்குவரத்தைப் பிடிக்க முடியும் என்பதால்.
நாம் அடிப்படை பகுதியை மட்டுமே பார்க்க வேண்டும் என்பதால், பல நெட்வொர்க்குகளைப் பயன்படுத்த முடியாது, ஆனால் இரண்டு நெட்வொர்க்குகளைப் பயன்படுத்தி அனைத்தையும் உயர்த்தலாம், மேலும் இந்த அமைப்பில் உள்ள இரண்டாவது நெட்வொர்க் அண்டர்கிளவுட் மற்றும் DNS சேவையகத்திற்கான அணுகலுக்கு மட்டுமே பயன்படுத்தப்படும். நாங்கள் இப்போது வெளிப்புற நெட்வொர்க்குகளைத் தொட மாட்டோம் - இது ஒரு தனி பெரிய கட்டுரைக்கான தலைப்பு.
எனவே, வரிசையில் தொடங்குவோம். முதலில், ஒரு சிறிய கோட்பாடு. டிரிபிள்ஓ (ஓபன்ஸ்டாக்கில் ஓபன்ஸ்டாக்) ஐப் பயன்படுத்தி ஓபன்ஸ்டாக்கை நிறுவுவோம். 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>மூன்று போர்ட் குழுக்கள் இங்கே அறிவிக்கப்பட்டுள்ளன - இரண்டு அணுகல் மற்றும் ஒரு தண்டு (பிந்தையது டிஎன்எஸ் சேவையகத்திற்குத் தேவைப்பட்டது, ஆனால் நீங்கள் அதை இல்லாமல் செய்யலாம் அல்லது ஹோஸ்ட் கணினியில் நிறுவலாம் - எது உங்களுக்கு மிகவும் வசதியானது). அடுத்து, இந்த டெம்ப்ளேட்டைப் பயன்படுத்தி, 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 ~]# குறிப்பு: இந்தச் சூழ்நிலையில், port ovs-br1 இல் உள்ள முகவரியை அணுக முடியாது, ஏனெனில் அது vlan குறிச்சொல்லைக் கொண்டிருக்கவில்லை. இதை சரிசெய்ய, நீங்கள் sudo ovs-vsctl set port ovs-br1 tag=100 கட்டளையை வழங்க வேண்டும். இருப்பினும், மறுதொடக்கம் செய்த பிறகு, இந்த குறிச்சொல் மறைந்துவிடும் (அது எப்படி இருக்க வேண்டும் என்று யாருக்காவது தெரிந்தால், நான் மிகவும் நன்றியுள்ளவனாக இருப்பேன்). ஆனால் இது அவ்வளவு முக்கியமல்ல, ஏனெனில் நிறுவலின் போது மட்டுமே இந்த முகவரி நமக்குத் தேவைப்படும் மற்றும் Openstack முழுமையாக பயன்படுத்தப்படும் போது அது தேவையில்லை.
அடுத்து, நாங்கள் ஒரு அண்டர்கிளவுட் இயந்திரத்தை உருவாக்குகிறோம்:
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 படத்தைப் பதிவிறக்கி, VM ஐ நிறுவ அதைப் பயன்படுத்தவும்.
வெற்றிகரமான நிறுவலுக்குப் பிறகு, நீங்கள் ஒரு மெய்நிகர் இயந்திரத்தை வைத்திருக்க வேண்டும், அதில் நீங்கள் அண்டர்கிளவுட் நிறுவ முடியும்
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningமுதலில், நிறுவல் செயல்முறைக்கு தேவையான கருவிகளை நிறுவவும்:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
அண்டர்கிளவுட் நிறுவல்
ஸ்டாக் பயனரை உருவாக்கி, கடவுச்சொல்லை அமைத்து, அதை சூடோயரில் சேர்த்து, கடவுச்சொல்லை உள்ளிடாமல் ரூட் கட்டளைகளை சூடோ மூலம் இயக்கும் திறனை அவருக்கு வழங்குகிறோம்:
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 சர்வரில் உள்ள நுழைவுடன் பொருந்த வேண்டும்
உள்ளூர்_ஐபி - நெட்வொர்க் வழங்கல் நோக்கிய உள்ளூர் அண்டர்கிளவுட் முகவரி
நெட்வொர்க்_கேட்வே — ஓவர் கிளவுட் முனைகளை நிறுவும் போது வெளி உலகத்தை அணுகுவதற்கான நுழைவாயிலாக செயல்படும் அதே உள்ளூர் முகவரி, உள்ளூர் ஐபியுடன் ஒத்துப்போகிறது.
undercloud_public_host - வெளிப்புற API முகவரி, வழங்குதல் நெட்வொர்க்கிலிருந்து எந்த இலவச முகவரியும் ஒதுக்கப்படும்
undercloud_admin_host அக API முகவரி, வழங்குதல் நெட்வொர்க்கிலிருந்து எந்த இலவச முகவரியும் ஒதுக்கப்படும்
undercloud_nameservers - டிஎன்எஸ் சர்வர்
உருவாக்க_சேவை_சான்றிதழ் - தற்போதைய எடுத்துக்காட்டில் இந்த வரி மிகவும் முக்கியமானது, ஏனெனில் நீங்கள் அதை தவறானதாக அமைக்கவில்லை என்றால், நிறுவலின் போது ஒரு பிழையைப் பெறுவீர்கள், சிக்கல் Red Hat பிழை டிராக்கரில் விவரிக்கப்பட்டுள்ளது.
உள்ளூர்_இடைமுகம் பிணைய வழங்கலில் இடைமுகம். அண்டர்கிளவுட் வரிசைப்படுத்தலின் போது இந்த இடைமுகம் மறுகட்டமைக்கப்படும், எனவே நீங்கள் அண்டர்கிளவுடில் இரண்டு இடைமுகங்களை வைத்திருக்க வேண்டும் - ஒன்று அதை அணுகுவதற்கு, இரண்டாவது வழங்குவதற்கு
உள்ளூர்_mtu - MTU. எங்களிடம் ஒரு சோதனை ஆய்வகம் இருப்பதால், OVS ஸ்விட்ச் போர்ட்களில் MTU 1500 இருப்பதால், VxLAN இல் இணைக்கப்பட்ட பாக்கெட்டுகள் கடந்து செல்ல, அதை 1450 ஆக அமைக்க வேண்டியது அவசியம்.
நெட்வொர்க்_சிடர் - வழங்குதல் நெட்வொர்க்
முகமூடி நடனம் - வெளிப்புற நெட்வொர்க்கை அணுக NAT ஐப் பயன்படுத்துதல்
முகமூடி_நெட்வொர்க் - NAT ஆக இருக்கும் நெட்வொர்க்
dhcp_start - ஓவர் கிளவுட் வரிசைப்படுத்தலின் போது முனைகளுக்கு முகவரிகள் ஒதுக்கப்படும் முகவரிக் குழுவின் தொடக்க முகவரி
dhcp_end - ஓவர் கிளவுட் வரிசைப்படுத்தலின் போது முனைகளுக்கு முகவரிகள் ஒதுக்கப்படும் முகவரிக் குழுவின் இறுதி முகவரி
ஆய்வு_பரப்பு - சுயபரிசோதனைக்கு தேவையான முகவரிகளின் தொகுப்பு (மேலே உள்ள குளத்துடன் ஒன்றுடன் ஒன்று சேரக்கூடாது)
திட்டமிடுபவர்_அதிகபட்ச_முயற்சிகள் - ஓவர் கிளவுட்டை நிறுவுவதற்கான அதிகபட்ச முயற்சிகள் (முனைகளின் எண்ணிக்கையை விட அதிகமாகவோ அல்லது சமமாகவோ இருக்க வேண்டும்)
கோப்பு விவரிக்கப்பட்ட பிறகு, அண்டர்கிளவுட் வரிசைப்படுத்த கட்டளையை நீங்கள் கொடுக்கலாம்:
openstack undercloud install
உங்கள் இரும்பை பொறுத்து செயல்முறை 10 முதல் 30 நிமிடங்கள் வரை ஆகும். இறுதியில் நீங்கள் இது போன்ற வெளியீட்டைப் பார்க்க வேண்டும்:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################நீங்கள் அண்டர்கிளவுடை வெற்றிகரமாக நிறுவிவிட்டீர்கள் என்றும், இப்போது அண்டர்கிளவுடின் நிலையைச் சரிபார்த்து, ஓவர் கிளவுட்டை நிறுவ தொடரலாம் என்றும் இந்த வெளியீடு கூறுகிறது.
ifconfig வெளியீட்டைப் பார்த்தால், ஒரு புதிய பிரிட்ஜ் இடைமுகம் தோன்றியிருப்பதைக் காண்பீர்கள்
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0இந்த இடைமுகத்தின் மூலம் ஓவர் கிளவுட் வரிசைப்படுத்தல் இப்போது மேற்கொள்ளப்படும்.
கீழே உள்ள வெளியீட்டில் இருந்து எங்களிடம் அனைத்து சேவைகளும் ஒரே முனையில் இருப்பதைக் காணலாம்:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+அண்டர்கிளவுட் நெட்வொர்க் பகுதியின் உள்ளமைவு கீழே உள்ளது:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$ஓவர் கிளவுட் நிறுவல்
தற்போது நம்மிடம் அண்டர்கிளவுட் மட்டுமே உள்ளது, மேலும் எங்களிடம் போதுமான முனைகள் இல்லை, அதில் இருந்து ஓவர் கிளவுட் கூடியிருக்கும். எனவே, முதலில், நமக்குத் தேவையான மெய்நிகர் இயந்திரங்களை வரிசைப்படுத்துவோம். வரிசைப்படுத்தலின் போது, அண்டர்கிளவுட் தானே ஓவர் கிளவுட் கணினியில் OS மற்றும் தேவையான மென்பொருளை நிறுவும் - அதாவது, நாங்கள் இயந்திரத்தை முழுமையாக வரிசைப்படுத்த தேவையில்லை, ஆனால் அதற்கான ஒரு வட்டை (அல்லது வட்டுகளை) உருவாக்கி அதன் அளவுருக்களை மட்டுமே தீர்மானிக்கவும் - அதாவது , உண்மையில், 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 ~]#கட்டளை தொடரியல் விளக்கம் இல்லாமல் தெளிவாக உள்ளது என்று நினைக்கிறேன். எவ்வாறாயினும், தற்போது எங்களின் அனைத்து அமர்வுகளும் கீழ் நிலையில் உள்ளன. அவர்கள் UP நிலைக்குச் செல்ல, நீங்கள் அவற்றை இயக்க வேண்டும்:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#மற்றும் இறுதி தொடுதல் - நீங்கள் ஃபயர்வால் விதிகளை சரிசெய்ய வேண்டும் (அல்லது அதை முழுவதுமாக முடக்கவும்):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
இப்போது அண்டர்கிளவுடுக்குச் சென்று எல்லாம் செயல்படுகிறதா என்று பார்க்கலாம். புரவலன் இயந்திரத்தின் முகவரி 192.168.255.200, வரிசைப்படுத்துதலுக்கான தயாரிப்பின் போது தேவையான ipmitool தொகுப்பை அண்டர்கிளவுடில் சேர்த்துள்ளோம்:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningநீங்கள் பார்க்க முடியும் என, நாங்கள் வெற்றிகரமாக vbmc வழியாக கட்டுப்பாட்டு முனையை துவக்கியுள்ளோம். இப்போது அதை அணைத்துவிட்டு தொடரலாம்:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#அடுத்த கட்டம் ஓவர் கிளவுட் நிறுவப்படும் முனைகளின் சுயபரிசோதனை ஆகும். இதைச் செய்ய, எங்கள் முனைகளின் விளக்கத்துடன் ஒரு json கோப்பைத் தயாரிக்க வேண்டும். வெற்று சேவையகங்களில் நிறுவுவது போலல்லாமல், ஒவ்வொரு கணினியிலும் vbmc இயங்கும் போர்ட்டை கோப்பு குறிப்பிடுகிறது என்பதை நினைவில் கொள்ளவும்.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27குறிப்பு: கட்டுப்பாட்டு முனையில் இரண்டு இடைமுகங்கள் உள்ளன, ஆனால் இந்த விஷயத்தில் இது முக்கியமல்ல, இந்த நிறுவலில் ஒன்று எங்களுக்கு போதுமானதாக இருக்கும்.
இப்போது நாம் json கோப்பை தயார் செய்கிறோம். வழங்கல் மேற்கொள்ளப்படும் துறைமுகத்தின் பாப்பி முகவரி, முனைகளின் அளவுருக்கள், அவற்றின் பெயர்களைக் கொடுத்து, ipmi ஐ எவ்வாறு பெறுவது என்பதைக் குறிப்பிட வேண்டும்:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}இப்போது நாம் முரண்பாட்டிற்கான படங்களை தயார் செய்ய வேண்டும். இதைச் செய்ய, அவற்றை wget வழியாகப் பதிவிறக்கி நிறுவவும்:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$அண்டர்கிளவுடில் படங்களை பதிவேற்றுகிறது:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$எல்லா படங்களும் ஏற்றப்பட்டுள்ளதா எனச் சரிபார்க்கிறது
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$இன்னும் ஒரு விஷயம் - நீங்கள் ஒரு DNS சேவையகத்தைச் சேர்க்க வேண்டும்:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$இப்போது நாம் சுயபரிசோதனைக்கான கட்டளையை கொடுக்கலாம்:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$நீங்கள் வெளியீட்டில் இருந்து பார்க்க முடியும் என, அனைத்து பிழைகள் இல்லாமல் முடிந்தது. எல்லா முனைகளும் கிடைக்கக்கூடிய நிலையில் உள்ளதா என்பதைச் சரிபார்ப்போம்:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ கணுக்கள் வேறு நிலையில் இருந்தால், பொதுவாக நிர்வகிக்கக்கூடியது, பின்னர் ஏதோ தவறு நடந்துவிட்டது, நீங்கள் பதிவைப் பார்த்து இது ஏன் நடந்தது என்பதைக் கண்டுபிடிக்க வேண்டும். இந்த சூழ்நிலையில் நாம் மெய்நிகராக்கத்தைப் பயன்படுத்துகிறோம் என்பதை நினைவில் கொள்ளவும், மேலும் மெய்நிகர் இயந்திரங்கள் அல்லது vbmc பயன்பாடுகளுடன் தொடர்புடைய பிழைகள் இருக்கலாம்.
அடுத்து, எந்த முனை எந்த செயல்பாட்டைச் செய்யும் என்பதை நாம் குறிப்பிட வேண்டும் - அதாவது, முனை வரிசைப்படுத்தும் சுயவிவரத்தைக் குறிக்கவும்:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$ஒவ்வொரு முனைக்கும் சுயவிவரத்தைக் குறிப்பிடவும்:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167நாங்கள் எல்லாவற்றையும் சரியாகச் செய்துள்ளோம் என்பதைச் சரிபார்க்கவும்:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$எல்லாம் சரியாக இருந்தால், overCloud ஐ வரிசைப்படுத்த கட்டளை கொடுக்கிறோம்:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuஉண்மையான நிறுவலில், தனிப்பயனாக்கப்பட்ட வார்ப்புருக்கள் இயற்கையாகவே பயன்படுத்தப்படும், எங்கள் விஷயத்தில் இது செயல்முறையை பெரிதும் சிக்கலாக்கும், ஏனெனில் டெம்ப்ளேட்டில் உள்ள ஒவ்வொரு திருத்தமும் விளக்கப்பட வேண்டும். முன்பு எழுதப்பட்டதைப் போல, இது எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்க ஒரு எளிய நிறுவல் கூட போதுமானதாக இருக்கும்.
குறிப்பு: இந்த விஷயத்தில் --libvirt-type qemu மாறி அவசியம், ஏனெனில் நாம் உள்ளமை மெய்நிகராக்கத்தைப் பயன்படுத்துவோம். இல்லையெனில், நீங்கள் மெய்நிகர் இயந்திரங்களை இயக்க முடியாது.
இப்போது உங்களிடம் ஒரு மணிநேரம் அல்லது அதற்கும் அதிகமாக இருக்கலாம் (வன்பொருளின் திறன்களைப் பொறுத்து) மற்றும் இந்த நேரத்திற்குப் பிறகு நீங்கள் பின்வரும் கல்வெட்டைப் பார்ப்பீர்கள் என்று மட்டுமே நம்பலாம்:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$இப்போது உங்களிடம் ஓபன்ஸ்டாக்கின் முழு அளவிலான பதிப்பு உள்ளது, அதில் நீங்கள் படிக்கலாம், பரிசோதனை செய்யலாம்.
எல்லாம் சரியாக வேலை செய்கிறதா என்று பார்ப்போம். பயனரின் ஹோம் டைரக்டரி ஸ்டேக்கில் இரண்டு கோப்புகள் உள்ளன - ஒரு ஸ்டாக்ர்க் (அண்டர்கிளவுட்டை நிர்வகிப்பதற்கு) மற்றும் இரண்டாவது ஓவர் கிளவுட்ர்க் (ஓவர் கிளவுட்டை நிர்வகிப்பதற்கு). இந்தக் கோப்புகள் ஆதாரமாகக் குறிப்பிடப்பட வேண்டும், ஏனெனில் அவை அங்கீகாரத்திற்குத் தேவையான தகவல்களைக் கொண்டிருக்கின்றன.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$எனது நிறுவலுக்கு இன்னும் ஒரு சிறிய தொடுதல் தேவைப்படுகிறது - நான் பணிபுரியும் இயந்திரம் வேறு நெட்வொர்க்கில் இருப்பதால், கட்டுப்படுத்தியில் ஒரு வழியைச் சேர்க்கிறது. இதைச் செய்ய, வெப்ப-நிர்வாகக் கணக்கின் கீழ் கட்டுப்பாடு-1 க்குச் சென்று வழியைப் பதிவு செய்யவும்
(undercloud) [stack@undercloud ~]$ ssh [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 மெய்நிகர் இயந்திரங்களை உருவாக்கியுள்ளோம் - ஒரு L3 நெட்வொர்க்கில் 2 - net-1, மேலும் 1 net-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 ~]$இந்த நேரத்தில், முனை மூன்று ovs பாலங்களைக் கொண்டுள்ளது - br-int, br-tun, br-ex. அவற்றுக்கிடையே, நாம் பார்ப்பது போல், இடைமுகங்களின் தொகுப்பு உள்ளது. எளிதில் புரிந்து கொள்ள, இந்த அனைத்து இடைமுகங்களையும் வரைபடத்தில் வரைந்து என்ன நடக்கிறது என்று பார்ப்போம்.
VxLAN சுரங்கங்கள் எழுப்பப்பட்ட முகவரிகளைப் பார்க்கும்போது, ஒரு சுரங்கப்பாதை கணக்கிட-1 (192.168.255.26) க்கு உயர்த்தப்பட்டிருப்பதைக் காணலாம், இரண்டாவது சுரங்கப்பாதை கட்டுப்பாட்டு-1 (192.168.255.15). ஆனால் மிகவும் சுவாரஸ்யமான விஷயம் என்னவென்றால், br-ex க்கு இயற்பியல் இடைமுகங்கள் இல்லை, மேலும் என்ன ஓட்டங்கள் கட்டமைக்கப்பட்டுள்ளன என்பதைப் பார்த்தால், இந்த பாலம் இந்த நேரத்தில் போக்குவரத்தை மட்டுமே குறைக்க முடியும் என்பதை நீங்கள் காணலாம்.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ வெளியீட்டில் இருந்து நீங்கள் பார்க்க முடியும் என, முகவரி நேரடியாக இயற்பியல் துறைமுகத்திற்கு திருகப்படுகிறது, மேலும் மெய்நிகர் பிரிட்ஜ் இடைமுகத்திற்கு அல்ல.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
முதல் விதியின்படி, ஃபை-பிஆர்-எக்ஸ் போர்ட்டிலிருந்து வந்த அனைத்தும் நிராகரிக்கப்பட வேண்டும்.
உண்மையில், இந்த இடைமுகத்திலிருந்து (br-int உடனான இடைமுகம்) தவிர வேறு எங்கும் இந்த பாலத்திற்குள் போக்குவரத்து வருவதற்கு தற்போது வேறு எங்கும் இல்லை, மேலும் துளிகள் மூலம் ஆராயும்போது, BUM போக்குவரத்து ஏற்கனவே பாலத்தில் பறந்து விட்டது.
அதாவது, போக்குவரத்து VxLAN சுரங்கப்பாதை வழியாக மட்டுமே இந்த முனையை விட்டு வெளியேற முடியும், வேறு எதுவும் இல்லை. இருப்பினும், நீங்கள் DVR ஐ இயக்கினால், நிலைமை மாறும், ஆனால் நாங்கள் அதை மற்றொரு முறை சமாளிப்போம். நெட்வொர்க் தனிமைப்படுத்தலைப் பயன்படுத்தும் போது, எடுத்துக்காட்டாக, vlans ஐப் பயன்படுத்தினால், உங்களிடம் Vlan 3 இல் ஒரு L0 இடைமுகம் இருக்காது, ஆனால் பல இடைமுகங்கள் இருக்கும். இருப்பினும், VxLAN ட்ராஃபிக் அதே வழியில் முனையிலிருந்து வெளியேறும், ஆனால் சில வகையான பிரத்யேக vlan இல் இணைக்கப்படும்.
நாங்கள் கம்ப்யூட் முனையை வரிசைப்படுத்தியுள்ளோம், கட்டுப்பாட்டு முனைக்கு செல்லலாம்.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$உண்மையில், எல்லாம் ஒன்றுதான் என்று நாம் கூறலாம், ஆனால் ஐபி முகவரியானது இயற்பியல் இடைமுகத்தில் இல்லை, ஆனால் மெய்நிகர் பாலத்தில் உள்ளது. இந்த துறைமுகம் வெளியுலகிற்கு போக்குவரத்து வெளியேறும் துறைமுகமாக இருப்பதால் இது செய்யப்படுகிறது.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ இந்த துறைமுகம் br-ex பிரிட்ஜுடன் இணைக்கப்பட்டுள்ளது, மேலும் அதில் vlan குறிச்சொற்கள் இல்லாததால், இந்த துறைமுகமானது அனைத்து vlanகளும் அனுமதிக்கப்படும் ஒரு டிரங்க் போர்ட் ஆகும், இப்போது போக்குவரத்து குறிச்சொல் இல்லாமல் வெளியே செல்கிறது, இது Vlan-id 0 ஆல் குறிப்பிடப்பட்டுள்ளது. மேலே வெளியீடு.
இந்த நேரத்தில் மற்ற அனைத்தும் கம்ப்யூட் முனையைப் போலவே உள்ளது - அதே பாலங்கள், அதே சுரங்கங்கள் இரண்டு கம்ப்யூட் முனைகளுக்குச் செல்கின்றன.
இந்த கட்டுரையில் சேமிப்பக முனைகளை நாங்கள் கருத்தில் கொள்ள மாட்டோம், ஆனால் புரிந்து கொள்ள இந்த முனைகளின் பிணைய பகுதி அவமானகரமான நிலைக்கு சாதாரணமானது என்று சொல்ல வேண்டும். எங்கள் விஷயத்தில், ஒரே ஒரு இயற்பியல் போர்ட் (eth0) அதற்கு ஒதுக்கப்பட்ட ஐபி முகவரியுடன் உள்ளது, அவ்வளவுதான். VxLAN சுரங்கப்பாதைகள், சுரங்கப்பாதை பாலங்கள் போன்றவை எதுவும் இல்லை - அதில் எந்த அர்த்தமும் இல்லை என்பதால், ovs எதுவும் இல்லை. பிணைய தனிமைப்படுத்தலைப் பயன்படுத்தும் போது, இந்த முனையில் இரண்டு இடைமுகங்கள் இருக்கும் (இயற்கை துறைமுகங்கள், பாடினி அல்லது இரண்டு vlans - இது ஒரு பொருட்டல்ல - இது நீங்கள் விரும்புவதைப் பொறுத்தது) - ஒன்று நிர்வாகத்திற்கு, இரண்டாவது போக்குவரத்து (VM வட்டில் எழுதுதல் , வட்டில் இருந்து படித்தல் போன்றவை)
எந்த சேவையும் இல்லாத நிலையில் முனைகளில் என்ன இருக்கிறது என்பதை நாங்கள் கண்டுபிடித்தோம். இப்போது 4 மெய்நிகர் இயந்திரங்களைத் தொடங்குவோம் மற்றும் மேலே விவரிக்கப்பட்ட திட்டம் எவ்வாறு மாறுகிறது என்பதைப் பார்ப்போம் - எங்களிடம் போர்ட்கள், மெய்நிகர் திசைவிகள் போன்றவை இருக்க வேண்டும்.
இதுவரை எங்கள் நெட்வொர்க் இதுபோல் தெரிகிறது:
ஒவ்வொரு கணினி முனையிலும் இரண்டு மெய்நிகர் இயந்திரங்கள் உள்ளன. கம்ப்யூட்-0யை உதாரணமாகப் பயன்படுத்தி, அனைத்தும் எவ்வாறு சேர்க்கப்பட்டுள்ளன என்பதைப் பார்ப்போம்.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ இயந்திரத்தில் ஒரே ஒரு மெய்நிகர் இடைமுகம் மட்டுமே உள்ளது - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
இந்த இடைமுகம் லினக்ஸ் பிரிட்ஜில் தெரிகிறது:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ வெளியீட்டிலிருந்து நீங்கள் பார்க்க முடியும் என, பிரிட்ஜில் இரண்டு இடைமுகங்கள் மட்டுமே உள்ளன - tap95d96a75-a0 மற்றும் qvb95d96a75-a0.
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 இல் உள்ளது. Br-int மெய்நிகர் இயந்திர போர்ட்களை நிறுத்தும் சுவிட்சாக செயல்படுகிறது. qvo95d96a75-a0 க்கு கூடுதலாக, போர்ட் qvo5bd37136-47 வெளியீட்டில் தெரியும். இது இரண்டாவது மெய்நிகர் இயந்திரத்திற்கான துறைமுகமாகும். இதன் விளைவாக, எங்கள் வரைபடம் இப்போது இதுபோல் தெரிகிறது:
கவனமுள்ள வாசகருக்கு உடனடியாக ஆர்வமாக இருக்கும் ஒரு கேள்வி - மெய்நிகர் இயந்திர துறைமுகத்திற்கும் OVS போர்ட்டிற்கும் இடையே உள்ள லினக்ஸ் பாலம் என்ன? உண்மை என்னவென்றால், இயந்திரத்தைப் பாதுகாக்க, பாதுகாப்பு குழுக்கள் பயன்படுத்தப்படுகின்றன, அவை iptables ஐத் தவிர வேறில்லை. OVS ஐப்டேபிள்களுடன் வேலை செய்யாது, எனவே இந்த "ஊன்றுகோல்" கண்டுபிடிக்கப்பட்டது. இருப்பினும், இது வழக்கற்றுப் போகிறது - இது புதிய வெளியீடுகளில் கான்ட்ராக் மூலம் மாற்றப்படுகிறது.
அதாவது, இறுதியில் திட்டம் இதுபோல் தெரிகிறது:
ஒரு 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 கம்ப்யூட்-1 இல் br-int பகிர்தல் அட்டவணையில் உள்ளது, மேலும் மேலே உள்ள வெளியீட்டில் இருந்து பார்க்க முடியும், இது போர்ட் 2 மூலம் தெரியும், இது br-tun நோக்கிய போர்ட் ஆகும்:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46சரி, கம்ப்யூட்-1 இல் br-int இல் ஒரு இலக்கு பாப்பி இருப்பதைக் காண்கிறோம்:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ அதாவது, பெறப்பட்ட பாக்கெட் போர்ட் 3 க்கு பறக்கும், அதன் பின்னால் ஏற்கனவே ஒரு மெய்நிகர் இயந்திர நிகழ்வு-00000003 உள்ளது.
மெய்நிகர் உள்கட்டமைப்பைக் கற்றுக்கொள்வதற்கு ஓபன்ஸ்டாக்கைப் பயன்படுத்துவதன் அழகு என்னவென்றால், ஹைப்பர்வைசர்களிடையே போக்குவரத்தை எளிதாகப் பிடிக்கலாம் மற்றும் அதில் என்ன நடக்கிறது என்பதைப் பார்க்கலாம். இதைத்தான் இப்போது செய்வோம், tcpdump ஐ vnet போர்ட்டில் கம்ப்யூட்-0 நோக்கி இயக்கவும்:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************10.0.1.85 முகவரியிலிருந்து படேக் முகவரி 10.0.1.88 (ICMP ட்ராஃபிக்) க்கு செல்கிறது, மேலும் அது vni 22 உடன் VxLAN பாக்கெட்டில் மூடப்பட்டிருக்கும் மற்றும் பேக்கெட் ஹோஸ்ட் 192.168.255.19 (கணக்கீடு-0) இலிருந்து ஹோஸ்ட் 192.168.255.26 க்கு செல்கிறது என்பதை முதல் வரி காட்டுகிறது. .1 (கணக்கீடு-XNUMX). ovs இல் குறிப்பிடப்பட்டுள்ள VNI உடன் பொருந்துகிறதா என்பதை நாம் சரிபார்க்கலாம்.
இந்த வரி செயல்களுக்கு திரும்புவோம்=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இந்த வழக்கில் பாக்கெட் நுழைவாயிலுக்குச் சென்று அங்கு அனுப்பப்பட வேண்டும் என்பதால், நுழைவாயிலின் பாப்பி முகவரியைக் கண்டுபிடிக்க வேண்டும், அதற்காக நாம் ARP அட்டவணையைப் பார்க்கிறோம்:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0இலக்கு (10.0.1.254) fa:16:3e:c4:64:70 எங்கே அனுப்பப்பட வேண்டும் என்பதை இப்போது பார்க்கலாம்:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ போர்ட் 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க்கு செல்கிறது. எந்த விஎக்ஸ்லான் சுரங்கப்பாதையில் இது மூடப்பட்டிருக்கும் என்று பார்ப்போம்:
[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 ~]$ போக்குவரத்து கட்டுப்பாட்டு முனையை அடைந்துள்ளது, எனவே நாம் அதற்குச் சென்று ரூட்டிங் எப்படி நடக்கும் என்பதைப் பார்க்க வேண்டும்.
நீங்கள் நினைவில் வைத்திருப்பது போல், உள்ளே உள்ள கட்டுப்பாட்டு முனையானது கம்ப்யூட் முனையைப் போலவே இருந்தது - அதே மூன்று பாலங்கள், பிஆர்-எக்ஸ் மட்டுமே ஒரு இயற்பியல் துறையைக் கொண்டிருந்தது, இதன் மூலம் கணு வெளியே போக்குவரத்தை அனுப்ப முடியும். நிகழ்வுகளின் உருவாக்கம் கம்ப்யூட் நோட்களில் உள்ளமைவை மாற்றியது - லினக்ஸ் பிரிட்ஜ், ஐப்டேபிள்கள் மற்றும் இடைமுகங்கள் முனைகளில் சேர்க்கப்பட்டன. நெட்வொர்க்குகள் மற்றும் ஒரு மெய்நிகர் திசைவி உருவாக்கம் கட்டுப்பாட்டு முனையின் கட்டமைப்பில் அதன் அடையாளத்தை விட்டுச் சென்றது.
எனவே, கேட்வே 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 இலிருந்து Mac தெரியும். ஓபன்ஸ்டாக்கில் உள்ள மெய்நிகர் போர்ட்களின் பட்டியலுக்கு நாம் திரும்பிச் சென்றால், பல்வேறு மெய்நிகர் சாதனங்களை OVS உடன் இணைக்க இந்த வகை போர்ட் பயன்படுத்தப்படுகிறது. இன்னும் துல்லியமாகச் சொல்வதானால், qr என்பது மெய்நிகர் திசைவிக்கான ஒரு போர்ட் ஆகும், இது பெயர்வெளியாகக் குறிப்பிடப்படுகிறது.
சர்வரில் என்ன பெயர்வெளிகள் உள்ளன என்று பார்ப்போம்:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ மூன்று பிரதிகள் வரை. ஆனால் பெயர்கள் மூலம் ஆராய, நீங்கள் அவர்கள் ஒவ்வொரு நோக்கம் யூகிக்க முடியும். நாங்கள் ID 0 மற்றும் 1 உடன் நிகழ்வுகளுக்குத் திரும்புவோம், இப்போது நாங்கள் பெயர்வெளி qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe இல் ஆர்வமாக உள்ளோம்:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ இந்த நேம்ஸ்பேஸில் நாம் முன்பு உருவாக்கிய இரண்டு உள்ளகங்கள் உள்ளன. இரண்டு மெய்நிகர் துறைமுகங்களும் br-int இல் சேர்க்கப்பட்டுள்ளன. போர்ட் qr-0c52b15f-8f இன் மேக் முகவரியைச் சரிபார்ப்போம், ட்ராஃபிக், இலக்கு மேக் முகவரி மூலம் தீர்மானிக்க, இந்த இடைமுகத்திற்குச் சென்றது.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ அதாவது, இந்த விஷயத்தில், அனைத்தும் நிலையான ரூட்டிங் சட்டங்களின்படி செயல்படுகின்றன. ட்ராஃபிக் ஹோஸ்ட் 10.0.2.8 க்கு விதிக்கப்பட்டுள்ளதால், அது இரண்டாவது இடைமுகம் qr-92fa49b5-54 வழியாக வெளியேறி, vxlan சுரங்கப்பாதை வழியாக கம்ப்யூட் முனைக்கு செல்ல வேண்டும்:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ எல்லாம் தர்க்கரீதியானது, ஆச்சரியங்கள் இல்லை. புரவலன் 10.0.2.8 இன் பாப்பி முகவரி br-int இல் எங்கு தெரியும் என்று பார்ப்போம்:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ எதிர்பார்த்தபடி, போக்குவரத்து 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 இல் எல்லாம் எளிது - br-tun இலிருந்து தொகுப்பு br-int க்கும் அங்கிருந்து மெய்நிகர் இயந்திர இடைமுகத்திற்கும் செல்கிறது:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ இது சரியான இடைமுகம்தானா என்பதைச் சரிபார்ப்போம்:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
உண்மையில், நாங்கள் தொகுப்பு வழியாக சென்றோம். போக்குவரத்து வெவ்வேறு vxlan சுரங்கங்கள் வழியாகச் சென்று வெவ்வேறு VNIகளுடன் வெளியேறியதை நீங்கள் கவனித்தீர்கள் என்று நினைக்கிறேன். இவை என்ன வகையான VNI என்று பார்ப்போம், அதன் பிறகு முனையின் கட்டுப்பாட்டு போர்ட்டில் ஒரு குப்பையை சேகரித்து, மேலே விவரிக்கப்பட்டுள்ளபடி போக்குவரத்து சரியாக பாய்வதை உறுதி செய்வோம்.
எனவே, கணக்கிடுவதற்கான சுரங்கப்பாதையில் பின்வரும் செயல்கள் உள்ளன=load:0->NXM_OF_VLAN_TCI[],load:0x0->NXM_NX_TUN_ID[],அவுட்புட்:16. 3x0 ஐ தசம எண் அமைப்பாக மாற்றுவோம்:
0x16 = 6*16^0+1*16^1 = 6+16 = 22கணக்கீடு-1க்கான சுரங்கப்பாதையில் பின்வரும் VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],அவுட்புட்:2 உள்ளது. 0x63 ஐ தசம எண் அமைப்பாக மாற்றுவோம்:
0x63 = 3*16^0+6*16^1 = 3+96 = 99சரி, இப்போது குப்பையைப் பார்ப்போம்:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************முதல் பாக்கெட் ஹோஸ்ட் 192.168.255.19 (கணினி-0) முதல் vni 192.168.255.15 உடன் 1 (கட்டுப்பாடு-22) வரை ஒரு vxlan பாக்கெட் ஆகும், அதன் உள்ளே ஒரு ICMP பாக்கெட் ஹோஸ்ட் 10.0.1.85 முதல் 10.0.2.8 ஹோஸ்ட் வரை தொகுக்கப்பட்டுள்ளது. நாம் மேலே கணக்கிட்டபடி, வெளியீட்டில் நாம் பார்த்ததை vni பொருந்துகிறது.
இரண்டாவது பாக்கெட் ஹோஸ்ட் 192.168.255.15 (கட்டுப்பாடு-1) முதல் 192.168.255.26 (கணினி-1) வரை vni 99 உடன் ஒரு vxlan பாக்கெட் ஆகும், அதன் உள்ளே ஒரு ICMP பாக்கெட் ஹோஸ்ட் 10.0.1.85 இலிருந்து ஹோஸ்ட் 10.0.2.8 வரை தொகுக்கப்பட்டுள்ளது. நாம் மேலே கணக்கிட்டபடி, வெளியீட்டில் நாம் பார்த்ததை 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 க்கு தான் விரும்புவதை மட்டுமே செய்ய உரிமை உண்டு (படிக்க - அதற்கு லாபம் என்ன) மற்றும் இது தர்க்கரீதியானது - ஏனெனில் இது ஒரு வணிக நிறுவனம், அதன் வாடிக்கையாளர்களிடமிருந்து பணம் சம்பாதிக்கப் பயன்படுகிறது. ஆனால் ஒரு பெரிய மற்றும் கொழுப்பு உள்ளது ஆனால் - நீங்கள் OpenStack லிருந்து வெளியேறலாம், எடுத்துக்காட்டாக Nokia இருந்து, மற்றும் சிறிய செலவில் தீர்வுக்கு மாறலாம், எடுத்துக்காட்டாக, Juniper (Contrail Cloud), ஆனால் நீங்கள் VMWare இல் இருந்து வெளியேற முடியாது. . என்னைப் பொறுத்தவரை, இந்த இரண்டு தீர்வுகளும் இப்படித்தான் இருக்கும் - ஓபன்ஸ்டாக் (விற்பனையாளர்) என்பது நீங்கள் வைக்கப்பட்டுள்ள ஒரு எளிய கூண்டு, ஆனால் உங்களிடம் ஒரு சாவி உள்ளது, நீங்கள் எந்த நேரத்திலும் வெளியேறலாம். VMWare ஒரு தங்கக் கூண்டு, உரிமையாளரிடம் கூண்டின் சாவி உள்ளது, அது உங்களுக்கு நிறைய செலவாகும்.
நான் முதல் தயாரிப்பையோ அல்லது இரண்டாவது தயாரிப்பையோ விளம்பரப்படுத்தவில்லை - உங்களுக்குத் தேவையானதை நீங்கள் தேர்வு செய்கிறீர்கள். ஆனால் எனக்கு அத்தகைய விருப்பம் இருந்தால், நான் இரண்டு தீர்வுகளையும் தேர்வு செய்வேன் - IT கிளவுட்க்கான VMWare (குறைந்த சுமைகள், எளிதான மேலாண்மை), சில விற்பனையாளர்களிடமிருந்து OpenStack (Nokia மற்றும் Juniper மிகச் சிறந்த ஆயத்த தயாரிப்பு தீர்வுகளை வழங்குகின்றன) - டெலிகாம் கிளவுட். நான் ஓபன்ஸ்டாக்கை தூய தகவல் தொழில்நுட்பத்திற்கு பயன்படுத்த மாட்டேன் - இது ஒரு பீரங்கியைக் கொண்டு சிட்டுக்குருவிகள் சுடுவது போன்றது, ஆனால் பணிநீக்கத்தைத் தவிர வேறு எந்த முரண்பாடுகளையும் நான் காணவில்லை. இருப்பினும், டெலிகாமில் விஎம்வேரைப் பயன்படுத்துவது ஃபோர்டு ராப்டரில் நொறுக்கப்பட்ட கல்லை இழுப்பது போன்றது - இது வெளியில் இருந்து அழகாக இருக்கிறது, ஆனால் டிரைவர் ஒன்றுக்கு பதிலாக 10 பயணங்களைச் செய்ய வேண்டும்.
என் கருத்துப்படி, VMWare இன் மிகப்பெரிய தீமை அதன் முழுமையான மூடல் - நிறுவனம் உங்களுக்கு எந்த தகவலையும் வழங்காது, எடுத்துக்காட்டாக, vSAN அல்லது ஹைப்பர்வைசர் கர்னலில் என்ன இருக்கிறது - அது லாபகரமானது அல்ல - அதாவது, நீங்கள் VMWare இல் ஒருபோதும் நிபுணராக மாறாதீர்கள் - விற்பனையாளர் ஆதரவு இல்லாமல், நீங்கள் அழிந்துவிட்டீர்கள் (அடிக்கடி கேள்விகளால் குழப்பமடையும் VMWare நிபுணர்களை நான் அடிக்கடி சந்திக்கிறேன்). என்னைப் பொறுத்தவரை, VMWare ஹூட் பூட்டப்பட்ட ஒரு காரை வாங்குகிறது - ஆம், டைமிங் பெல்ட்டை மாற்றக்கூடிய நிபுணர்கள் உங்களிடம் இருக்கலாம், ஆனால் இந்த தீர்வை உங்களுக்கு விற்றவர் மட்டுமே பேட்டை திறக்க முடியும். தனிப்பட்ட முறையில், நான் பொருந்தாத தீர்வுகளை நான் விரும்பவில்லை. நீங்கள் பேட்டைக்குக் கீழே செல்ல வேண்டியதில்லை என்று நீங்கள் கூறுவீர்கள். ஆம், இது சாத்தியம், ஆனால் 20-30 மெய்நிகர் இயந்திரங்கள், 40-50 நெட்வொர்க்குகள் ஆகியவற்றிலிருந்து ஒரு பெரிய செயல்பாட்டை நீங்கள் கிளவுட்டில் இணைக்க வேண்டியிருக்கும் போது நான் உங்களைப் பார்ப்பேன், அதில் பாதி வெளியே செல்ல விரும்புகிறது, இரண்டாவது பாதி கேட்கிறது SR-IOV முடுக்கம், இல்லையெனில் உங்களுக்கு இரண்டு டஜன் கார்கள் தேவைப்படும் - இல்லையெனில் செயல்திறன் போதுமானதாக இருக்காது.
மற்ற கண்ணோட்டங்கள் உள்ளன, எனவே எதை தேர்வு செய்வது என்பதை நீங்கள் மட்டுமே தீர்மானிக்க முடியும், மிக முக்கியமாக, உங்கள் விருப்பத்திற்கு நீங்கள் பொறுப்பாவீர்கள். இது எனது கருத்து மட்டுமே - Nokia, Juniper, Red Hat மற்றும் VMWare ஆகிய 4 தயாரிப்புகளையாவது பார்த்து தொட்டவர். அதாவது, நான் ஒப்பிடுவதற்கு ஒன்று உள்ளது.
ஆதாரம்: www.habr.com