ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ നെറ്റ്‌വർക്ക് ഭാഗത്തേക്കുള്ള ആമുഖം

ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് നമ്മുടെ ജീവിതത്തിലേക്ക് കൂടുതൽ ആഴത്തിൽ തുളച്ചുകയറുന്നു, ഒരു തവണയെങ്കിലും ക്ലൗഡ് സേവനങ്ങളൊന്നും ഉപയോഗിക്കാത്ത ഒരു വ്യക്തി പോലും ഉണ്ടാകില്ല. എന്നിരുന്നാലും, ഒരു ക്ലൗഡ് എന്താണ്, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, ഒരു ആശയത്തിന്റെ തലത്തിൽ പോലും കുറച്ച് ആളുകൾക്ക് അറിയാം. 5G ഇതിനകം ഒരു യാഥാർത്ഥ്യമായി മാറുകയാണ്, ടെലികോം ഇൻഫ്രാസ്ട്രക്ചർ പില്ലർ സൊല്യൂഷനുകളിൽ നിന്ന് ക്ലൗഡ് സൊല്യൂഷനുകളിലേക്ക് നീങ്ങാൻ തുടങ്ങിയിരിക്കുന്നു, അത് പൂർണ്ണമായും ഹാർഡ്‌വെയർ സൊല്യൂഷനുകളിൽ നിന്ന് വെർച്വലൈസ്ഡ് “തൂണുകളിലേക്ക്” മാറിയതുപോലെ.

ഇന്ന് നമ്മൾ ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ആന്തരിക ലോകത്തെക്കുറിച്ച് സംസാരിക്കും, പ്രത്യേകിച്ച് ഞങ്ങൾ നെറ്റ്‌വർക്ക് ഭാഗത്തിന്റെ അടിസ്ഥാനകാര്യങ്ങൾ നോക്കും.

എന്താണ് മേഘം? അതേ വെർച്വലൈസേഷൻ - പ്രൊഫൈൽ കാഴ്ച?

ഒരു ലോജിക്കൽ ചോദ്യത്തേക്കാൾ കൂടുതൽ. ഇല്ല - ഇത് വെർച്വലൈസേഷൻ അല്ല, എന്നിരുന്നാലും ഇത് കൂടാതെ ഇത് ചെയ്യാൻ കഴിയില്ല. നമുക്ക് രണ്ട് നിർവചനങ്ങൾ നോക്കാം:

ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് (ഇനി ക്ലൗഡ് എന്ന് വിളിക്കുന്നു) വിതരണം ചെയ്ത കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളിലേക്ക് ഉപയോക്തൃ-സൗഹൃദ ആക്‌സസ് നൽകുന്നതിനുള്ള ഒരു മാതൃകയാണ്, അത് സേവന ദാതാവിന് സാധ്യമായ ഏറ്റവും കുറഞ്ഞ ലേറ്റൻസിയിലും കുറഞ്ഞ ചിലവിലും ആവശ്യാനുസരണം വിന്യസിക്കുകയും സമാരംഭിക്കുകയും വേണം.

വെർച്വലൈസേഷൻ - ഇത് ഒരു ഫിസിക്കൽ എന്റിറ്റിയെ (ഉദാഹരണത്തിന്, ഒരു സെർവർ) നിരവധി വെർച്വൽ ആയി വിഭജിക്കാനുള്ള കഴിവാണ്, അതുവഴി വിഭവങ്ങളുടെ ഉപയോഗം വർദ്ധിപ്പിക്കുന്നു (ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് 3 സെർവറുകൾ 25-30 ശതമാനം ലോഡുചെയ്തിരുന്നു, വെർച്വലൈസേഷനുശേഷം നിങ്ങൾക്ക് 1 സെർവർ ലോഡ് ചെയ്യപ്പെടും. 80-90 ശതമാനം). സ്വാഭാവികമായും, വിർച്ച്വലൈസേഷൻ ചില വിഭവങ്ങൾ തിന്നുതീർക്കുന്നു - നിങ്ങൾ ഹൈപ്പർവൈസറിന് ഭക്ഷണം നൽകേണ്ടതുണ്ട്, എന്നിരുന്നാലും, പ്രാക്ടീസ് കാണിച്ചിരിക്കുന്നതുപോലെ, ഗെയിം മെഴുകുതിരിക്ക് വിലമതിക്കുന്നു. വെർച്വലൈസേഷന്റെ ഉത്തമ ഉദാഹരണമാണ് വിഎംവെയർ, അത് വെർച്വൽ മെഷീനുകൾ നന്നായി തയ്യാറാക്കുന്നു, അല്ലെങ്കിൽ ഉദാഹരണത്തിന് കെവിഎം, ഞാൻ ഇഷ്ടപ്പെടുന്നു, പക്ഷേ ഇത് അഭിരുചിയുടെ കാര്യമാണ്.

ഞങ്ങൾ അത് തിരിച്ചറിയാതെ തന്നെ വിർച്ച്വലൈസേഷൻ ഉപയോഗിക്കുന്നു, കൂടാതെ ഇരുമ്പ് റൂട്ടറുകൾ പോലും ഇതിനകം തന്നെ വിർച്ച്വലൈസേഷൻ ഉപയോഗിക്കുന്നു - ഉദാഹരണത്തിന്, ജൂനോസിന്റെ ഏറ്റവും പുതിയ പതിപ്പിൽ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഒരു തത്സമയ ലിനക്സ് വിതരണത്തിന് (വിൻഡ് റിവർ 9) മുകളിൽ ഒരു വെർച്വൽ മെഷീനായി ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. എന്നാൽ വെർച്വലൈസേഷൻ എന്നത് ക്ലൗഡല്ല, എന്നാൽ വെർച്വലൈസേഷൻ കൂടാതെ ക്ലൗഡിന് നിലനിൽക്കാൻ കഴിയില്ല.

ക്ലൗഡ് നിർമ്മിച്ചിരിക്കുന്ന നിർമ്മാണ ബ്ലോക്കുകളിൽ ഒന്നാണ് വെർച്വലൈസേഷൻ.

ഒരു L2 ഡൊമെയ്‌നിലേക്ക് നിരവധി ഹൈപ്പർവൈസറുകൾ ശേഖരിച്ച് ഒരു ക്ലൗഡ് നിർമ്മിക്കുക, ഏതെങ്കിലും തരത്തിലുള്ള Ansible വഴി സ്വയമേവ vlans രജിസ്റ്റർ ചെയ്യുന്നതിനായി രണ്ട് yaml പ്ലേബുക്കുകൾ ചേർക്കുകയും വെർച്വൽ മെഷീനുകൾ സ്വയമേവ സൃഷ്‌ടിക്കുന്നതിന് മുകളിൽ ഒരു ഓർക്കസ്ട്രേഷൻ സിസ്റ്റം പോലെയുള്ള ഒന്ന് സ്ഥാപിക്കുകയും ചെയ്യുന്നത് പ്രവർത്തിക്കില്ല. ഇത് കൂടുതൽ കൃത്യതയുള്ളതായിരിക്കും, എന്നാൽ തത്ഫലമായുണ്ടാകുന്ന ഫ്രാങ്കെൻസ്റ്റൈൻ നമുക്ക് ആവശ്യമുള്ള മേഘമല്ല, മറ്റുള്ളവർക്ക് അത് ആത്യന്തിക സ്വപ്നമായിരിക്കാം. മാത്രമല്ല, നിങ്ങൾ അതേ ഓപ്പൺസ്റ്റാക്ക് എടുക്കുകയാണെങ്കിൽ, അത് അടിസ്ഥാനപരമായി ഇപ്പോഴും ഫ്രാങ്കെൻസ്റ്റൈനാണ്, പക്ഷേ ശരി, ഇപ്പോൾ അതിനെക്കുറിച്ച് സംസാരിക്കരുത്.

എന്നാൽ മുകളിൽ അവതരിപ്പിച്ച നിർവചനത്തിൽ നിന്ന് യഥാർത്ഥത്തിൽ ക്ലൗഡ് എന്ന് വിളിക്കാവുന്നത് പൂർണ്ണമായും വ്യക്തമല്ലെന്ന് ഞാൻ മനസ്സിലാക്കുന്നു.

അതിനാൽ, NIST (നാഷണൽ ഇൻസ്റ്റിറ്റ്യൂട്ട് ഓഫ് സ്റ്റാൻഡേർഡ്സ് ആൻഡ് ടെക്നോളജി)-ൽ നിന്നുള്ള ഒരു പ്രമാണം ഒരു ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിന് ഉണ്ടായിരിക്കേണ്ട 5 പ്രധാന സവിശേഷതകൾ നൽകുന്നു:

അഭ്യർത്ഥന പ്രകാരം സേവനം നൽകുന്നു. ഉപയോക്താവിന് അനുവദിച്ചിട്ടുള്ള കമ്പ്യൂട്ടർ ഉറവിടങ്ങളിലേക്ക് (നെറ്റ്‌വർക്കുകൾ, വെർച്വൽ ഡിസ്‌കുകൾ, മെമ്മറി, പ്രോസസർ കോറുകൾ മുതലായവ) സൗജന്യ ആക്‌സസ് നൽകണം, കൂടാതെ ഈ ഉറവിടങ്ങൾ സ്വയമേവ നൽകണം - അതായത്, സേവന ദാതാവിന്റെ ഇടപെടലില്ലാതെ.

സേവനത്തിന്റെ വിപുലമായ ലഭ്യത. സ്റ്റാൻഡേർഡ് പിസികളുടെയും നേർത്ത ക്ലയന്റുകളുടെയും മൊബൈൽ ഉപകരണങ്ങളുടെയും ഉപയോഗം അനുവദിക്കുന്നതിന് ഉറവിടങ്ങളിലേക്കുള്ള പ്രവേശനം സ്റ്റാൻഡേർഡ് മെക്കാനിസങ്ങൾ വഴി നൽകണം.

വിഭവങ്ങൾ സംയോജിപ്പിച്ച് കുളങ്ങൾ. റിസോഴ്‌സ് പൂളുകൾക്ക് ഒരേ സമയം ഒന്നിലധികം ക്ലയന്റുകൾക്ക് ഉറവിടങ്ങൾ നൽകാൻ കഴിയണം, ക്ലയന്റുകൾ ഒറ്റപ്പെട്ടവരും പരസ്പര സ്വാധീനവും വിഭവങ്ങൾക്കായുള്ള മത്സരവും ഇല്ലാത്തവരാണെന്ന് ഉറപ്പാക്കുന്നു. നെറ്റ്‌വർക്കുകളും പൂളുകളിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, ഇത് ഓവർലാപ്പിംഗ് വിലാസം ഉപയോഗിക്കുന്നതിനുള്ള സാധ്യതയെ സൂചിപ്പിക്കുന്നു. കുളങ്ങൾക്ക് ആവശ്യാനുസരണം അളക്കാൻ കഴിയണം. പൂളുകളുടെ ഉപയോഗം ആവശ്യമായ റിസോഴ്സ് ഫോൾട്ട് ടോളറൻസും ഫിസിക്കൽ, വെർച്വൽ റിസോഴ്സുകളുടെ അമൂർത്തീകരണവും നൽകുന്നത് സാധ്യമാക്കുന്നു - സേവനത്തിന്റെ സ്വീകർത്താവിന് അവൻ അഭ്യർത്ഥിച്ച വിഭവങ്ങളുടെ ഒരു കൂട്ടം നൽകുന്നു (ഈ ഉറവിടങ്ങൾ ഭൗതികമായി സ്ഥിതിചെയ്യുന്നിടത്ത്, എത്രയെണ്ണത്തിൽ സെർവറുകളും സ്വിച്ചുകളും - ഇത് ക്ലയന്റിന് പ്രശ്നമല്ല). എന്നിരുന്നാലും, ദാതാവ് ഈ വിഭവങ്ങളുടെ സുതാര്യമായ സംവരണം ഉറപ്പാക്കണം എന്ന വസ്തുത ഞങ്ങൾ കണക്കിലെടുക്കണം.

വ്യത്യസ്ത സാഹചര്യങ്ങളുമായി വേഗത്തിലുള്ള പൊരുത്തപ്പെടുത്തൽ. സേവനങ്ങൾ വഴക്കമുള്ളതായിരിക്കണം - വിഭവങ്ങളുടെ ദ്രുതഗതിയിലുള്ള പ്രൊവിഷൻ, അവയുടെ പുനർവിതരണം, ക്ലയന്റ് അഭ്യർത്ഥന പ്രകാരം വിഭവങ്ങൾ കൂട്ടിച്ചേർക്കുകയോ കുറയ്ക്കുകയോ ചെയ്യുക, ക്ലൗഡ് ഉറവിടങ്ങൾ അനന്തമാണെന്ന തോന്നൽ ക്ലയന്റിന്റെ ഭാഗത്ത് ഉണ്ടായിരിക്കണം. മനസ്സിലാക്കാനുള്ള എളുപ്പത്തിനായി, ഉദാഹരണത്തിന്, സെർവറിലെ ഹാർഡ് ഡ്രൈവ് തകരാറിലായതിനാൽ, ആപ്പിൾ ഐക്ലൗഡിലെ നിങ്ങളുടെ ഡിസ്ക് സ്ഥലത്തിന്റെ ഒരു ഭാഗം അപ്രത്യക്ഷമായി എന്ന മുന്നറിയിപ്പ് നിങ്ങൾ കാണുന്നില്ല, കൂടാതെ ഡ്രൈവുകൾ തകരാറിലാകുന്നു. കൂടാതെ, നിങ്ങളുടെ ഭാഗത്ത്, ഈ സേവനത്തിന്റെ സാധ്യതകൾ ഏതാണ്ട് പരിധിയില്ലാത്തതാണ് - നിങ്ങൾക്ക് 2 TB ആവശ്യമാണ് - ഒരു പ്രശ്നവുമില്ല, നിങ്ങൾ പണം നൽകി അത് സ്വീകരിച്ചു. സമാനമായ ഒരു ഉദാഹരണം Google.Drive അല്ലെങ്കിൽ Yandex.Disk ഉപയോഗിച്ച് നൽകാം.

നൽകിയ സേവനം അളക്കാനുള്ള സാധ്യത. ക്ലൗഡ് സിസ്റ്റങ്ങൾ ഉപഭോഗം ചെയ്യുന്ന വിഭവങ്ങൾ സ്വയമേവ നിയന്ത്രിക്കുകയും ഒപ്റ്റിമൈസ് ചെയ്യുകയും വേണം, കൂടാതെ ഈ സംവിധാനങ്ങൾ ഉപയോക്താവിനും സേവന ദാതാവിനും സുതാര്യമായിരിക്കണം. അതായത്, നിങ്ങളും നിങ്ങളുടെ ക്ലയന്റുകളും എത്ര വിഭവങ്ങൾ ഉപയോഗിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും പരിശോധിക്കാനാകും.

ഈ ആവശ്യകതകൾ കൂടുതലും ഒരു പൊതു ക്ലൗഡിനുള്ള ആവശ്യകതകളാണെന്ന വസ്തുത പരിഗണിക്കേണ്ടതാണ്, അതിനാൽ ഒരു സ്വകാര്യ ക്ലൗഡിന് (അതായത്, കമ്പനിയുടെ ആന്തരിക ആവശ്യങ്ങൾക്കായി സമാരംഭിച്ച ഒരു ക്ലൗഡ്), ഈ ആവശ്യകതകൾ ചെറുതായി ക്രമീകരിക്കാൻ കഴിയും. എന്നിരുന്നാലും, അവ ഇപ്പോഴും ചെയ്യേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം ക്ലൗഡ് കമ്പ്യൂട്ടിംഗിന്റെ എല്ലാ നേട്ടങ്ങളും നമുക്ക് ലഭിക്കില്ല.

എന്തുകൊണ്ടാണ് നമുക്ക് ഒരു മേഘം വേണ്ടത്?

എന്നിരുന്നാലും, പുതിയതോ നിലവിലുള്ളതോ ആയ ഏതെങ്കിലും സാങ്കേതികവിദ്യ, എന്തെങ്കിലും പുതിയ പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കപ്പെടുന്നു (നന്നായി, RIP-ng ഒഴികെ, തീർച്ചയായും). ഒരു പ്രോട്ടോക്കോളിനായി ആർക്കും ഒരു പ്രോട്ടോക്കോൾ ആവശ്യമില്ല (നന്നായി, RIP-ng ഒഴികെ, തീർച്ചയായും). ഉപയോക്താവിന്/ക്ലയന്റിന് ഏതെങ്കിലും തരത്തിലുള്ള സേവനം നൽകാനാണ് ക്ലൗഡ് സൃഷ്ടിച്ചിരിക്കുന്നത് എന്നത് യുക്തിസഹമാണ്. നമുക്കെല്ലാവർക്കും കുറഞ്ഞത് രണ്ട് ക്ലൗഡ് സേവനങ്ങളെങ്കിലും പരിചിതമാണ്, ഉദാഹരണത്തിന് Dropbox അല്ലെങ്കിൽ Google.Docs, കൂടാതെ മിക്ക ആളുകളും അവ വിജയകരമായി ഉപയോഗിക്കുമെന്ന് ഞാൻ വിശ്വസിക്കുന്നു - ഉദാഹരണത്തിന്, ഈ ലേഖനം എഴുതിയത് Google.Docs ക്ലൗഡ് സേവനം ഉപയോഗിച്ചാണ്. എന്നാൽ നമുക്കറിയാവുന്ന ക്ലൗഡ് സേവനങ്ങൾ ക്ലൗഡിന്റെ കഴിവുകളുടെ ഒരു ഭാഗം മാത്രമാണ്-കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, അവ ഒരു SaaS-ടൈപ്പ് സേവനം മാത്രമാണ്. ഞങ്ങൾക്ക് മൂന്ന് തരത്തിൽ ഒരു ക്ലൗഡ് സേവനം നൽകാൻ കഴിയും: SaaS, PaaS അല്ലെങ്കിൽ IaaS രൂപത്തിൽ. നിങ്ങൾക്ക് ആവശ്യമുള്ള സേവനം നിങ്ങളുടെ ആഗ്രഹങ്ങളെയും കഴിവുകളെയും ആശ്രയിച്ചിരിക്കുന്നു.

നമുക്ക് ഓരോന്നും ക്രമത്തിൽ നോക്കാം:

ഒരു സേവനമായി സോഫ്റ്റ്വെയർ (SaaS) ക്ലയന്റിന് ഒരു പൂർണ്ണമായ സേവനം നൽകുന്നതിനുള്ള ഒരു മാതൃകയാണ്, ഉദാഹരണത്തിന്, Yandex.Mail അല്ലെങ്കിൽ Gmail പോലുള്ള ഇമെയിൽ സേവനം. ഈ സേവന ഡെലിവറി മോഡലിൽ, നിങ്ങൾ ഒരു ക്ലയന്റ് എന്ന നിലയിൽ, സേവനങ്ങൾ ഉപയോഗിക്കുന്നതല്ലാതെ യാതൊന്നും ചെയ്യുന്നില്ല - അതായത്, സേവനം സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ചോ അതിന്റെ തെറ്റ് സഹിഷ്ണുതയെക്കുറിച്ചോ ആവർത്തനത്തെക്കുറിച്ചോ നിങ്ങൾ ചിന്തിക്കേണ്ടതില്ല. നിങ്ങളുടെ പാസ്‌വേഡ് വിട്ടുവീഴ്ച ചെയ്യരുത് എന്നതാണ് പ്രധാന കാര്യം; ഈ സേവന ദാതാവ് ബാക്കി നിങ്ങൾക്കായി ചെയ്യും. സേവന ദാതാവിന്റെ കാഴ്ചപ്പാടിൽ, സെർവർ ഹാർഡ്‌വെയർ, ഹോസ്റ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ മുതൽ ഡാറ്റാബേസ്, സോഫ്റ്റ്‌വെയർ ക്രമീകരണങ്ങൾ വരെയുള്ള മുഴുവൻ സേവനത്തിന്റെയും പൂർണ ഉത്തരവാദിത്തം അവനാണ്.

ഒരു സേവനമായി പ്ലാറ്റ്ഫോം (PaaS) — ഈ മോഡൽ ഉപയോഗിക്കുമ്പോൾ, സേവന ദാതാവ് ക്ലയന്റിനു സേവനത്തിനായി ഒരു വർക്ക്പീസ് നൽകുന്നു, ഉദാഹരണത്തിന്, നമുക്ക് ഒരു വെബ് സെർവർ എടുക്കാം. സേവന ദാതാവ് ക്ലയന്റിന് ഒരു വെർച്വൽ സെർവർ നൽകി (വാസ്തവത്തിൽ, റാം/സിപിയു/സ്റ്റോറേജ്/നെറ്റ്‌സ് മുതലായവ പോലുള്ള ഒരു കൂട്ടം ഉറവിടങ്ങൾ), കൂടാതെ ഈ സെർവറിൽ ഒഎസും ആവശ്യമായ സോഫ്റ്റ്‌വെയറും ഇൻസ്റ്റാൾ ചെയ്തു, എന്നിരുന്നാലും, കോൺഫിഗറേഷൻ ഈ എല്ലാ കാര്യങ്ങളും ക്ലയന്റ് സ്വയം ചെയ്യുന്നു, സേവനത്തിന്റെ പ്രകടനത്തിന് ക്ലയന്റ് ഉത്തരം നൽകുന്നു. സേവന ദാതാവ്, മുമ്പത്തെ കാര്യത്തിലെന്നപോലെ, ഫിസിക്കൽ ഉപകരണങ്ങൾ, ഹൈപ്പർവൈസറുകൾ, വെർച്വൽ മെഷീൻ, അതിന്റെ നെറ്റ്‌വർക്ക് ലഭ്യത മുതലായവയുടെ പ്രകടനത്തിന് ഉത്തരവാദിയാണ്, എന്നാൽ സേവനം തന്നെ അതിന്റെ ഉത്തരവാദിത്ത മേഖലയിലല്ല.

ഒരു സേവനമായി ഇൻഫ്രാസ്ട്രക്ചർ (IaaS) - ഈ സമീപനം ഇതിനകം തന്നെ കൂടുതൽ രസകരമാണ്, വാസ്തവത്തിൽ, സേവന ദാതാവ് ക്ലയന്റിന് പൂർണ്ണമായ വെർച്വലൈസ്ഡ് ഇൻഫ്രാസ്ട്രക്ചർ നൽകുന്നു - അതായത്, CPU കോറുകൾ, റാം, നെറ്റ്‌വർക്കുകൾ മുതലായവ പോലുള്ള ചില സെറ്റ് (പൂൾ) ഉറവിടങ്ങൾ. ക്ലയന്റ് - അനുവദിച്ച പൂളിൽ (ക്വോട്ട) ഈ ഉറവിടങ്ങളുമായി ക്ലയന്റ് എന്താണ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നത് - ഇത് വിതരണക്കാരന് പ്രത്യേകിച്ച് പ്രധാനമല്ല. ക്ലയന്റ് സ്വന്തം vEPC സൃഷ്‌ടിക്കാൻ ആഗ്രഹിക്കുന്നുണ്ടോ അല്ലെങ്കിൽ ഒരു മിനി ഓപ്പറേറ്റർ സൃഷ്‌ടിച്ച് ആശയവിനിമയ സേവനങ്ങൾ നൽകണമോ - ഒരു ചോദ്യവുമില്ല - അത് ചെയ്യുക. അത്തരമൊരു സാഹചര്യത്തിൽ, ഉറവിടങ്ങൾ, അവയുടെ തെറ്റ് സഹിഷ്ണുത, ലഭ്യത എന്നിവ നൽകുന്നതിന് സേവന ദാതാവിന് ഉത്തരവാദിത്തമുണ്ട്. ഉപഭോക്താവിന്റെ അഭ്യർത്ഥന പ്രകാരം. നെറ്റ്‌വർക്കുകൾ സജ്ജീകരിക്കുന്നത് ഉൾപ്പെടെ (ബാഹ്യ നെറ്റ്‌വർക്കുകൾ ഒഴികെ) സെൽഫ് സർവീസ് പോർട്ടലും കൺസോളും വഴി ക്ലയന്റ് എല്ലാ വെർച്വൽ മെഷീനുകളും മറ്റ് ടിൻസലുകളും കോൺഫിഗർ ചെയ്യുന്നു.

എന്താണ് OpenStack?

മൂന്ന് ഓപ്ഷനുകളിലും, സേവന ദാതാവിന് ഒരു ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിക്കാൻ സഹായിക്കുന്ന ഒരു OS ആവശ്യമാണ്. വാസ്തവത്തിൽ, SaaS-ൽ, ഒന്നിലധികം ഡിവിഷനുകൾ സാങ്കേതികവിദ്യകളുടെ മുഴുവൻ സ്റ്റാക്കിനും ഉത്തരവാദികളാണ് - ഇൻഫ്രാസ്ട്രക്ചറിന് ഉത്തരവാദിത്തമുള്ള ഒരു ഡിവിഷൻ ഉണ്ട് - അതായത്, ഇത് മറ്റൊരു ഡിവിഷനിലേക്ക് IaaS നൽകുന്നു, ഈ ഡിവിഷൻ ക്ലയന്റിന് SaaS നൽകുന്നു. ഒരു കൂട്ടം സ്വിച്ചുകൾ, സെർവറുകൾ, സ്റ്റോറേജ് സിസ്റ്റങ്ങൾ എന്നിവ ഒരൊറ്റ റിസോഴ്‌സ് പൂളിലേക്ക് ശേഖരിക്കാനും ഈ പൊതു പൂളിനെ സബ്‌പൂളുകളായി (കുടിയാൻമാർ) വിഭജിക്കാനും നെറ്റ്‌വർക്കിലൂടെ ക്ലയന്റുകൾക്ക് ഈ ഉറവിടങ്ങൾ നൽകാനും നിങ്ങളെ അനുവദിക്കുന്ന ക്ലൗഡ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലൊന്നാണ് OpenStack.

ഓപ്പൺസ്റ്റാക്ക് കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ, ഡാറ്റ സംഭരണം, നെറ്റ്‌വർക്ക് ഉറവിടങ്ങൾ എന്നിവയുടെ വലിയ പൂളുകൾ നിയന്ത്രിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ക്ലൗഡ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റമാണ്, സ്റ്റാൻഡേർഡ് ഓതന്റിക്കേഷൻ മെക്കാനിസങ്ങൾ ഉപയോഗിച്ച് API വഴി നൽകുകയും നിയന്ത്രിക്കുകയും ചെയ്യുന്നു.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഇത് ക്ലൗഡ് സേവനങ്ങൾ (പബ്ലിക്, പ്രൈവറ്റ്) സൃഷ്ടിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ള ഒരു കൂട്ടം സ്വതന്ത്ര സോഫ്റ്റ്‌വെയർ പ്രോജക്റ്റുകളാണ് - അതായത്, സെർവറും സ്വിച്ചിംഗ് ഉപകരണങ്ങളും സംയോജിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു കൂട്ടം ടൂളുകൾ, മാനേജ് ചെയ്യുക ഈ ഉറവിടങ്ങൾ, ആവശ്യമായ തെറ്റ് സഹിഷ്ണുത നൽകുന്നു.

ഈ മെറ്റീരിയൽ എഴുതുന്ന സമയത്ത്, OpenStack ഘടന ഇതുപോലെ കാണപ്പെടുന്നു:

നിന്ന് എടുത്ത ചിത്രം openstack.org

OpenStack-ൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ഓരോ ഘടകങ്ങളും ഒരു പ്രത്യേക പ്രവർത്തനം നിർവ്വഹിക്കുന്നു. ഈ ഡിസ്ട്രിബ്യൂഡ് ആർക്കിടെക്ചർ നിങ്ങൾക്ക് ആവശ്യമുള്ള ഫങ്ഷണൽ ഘടകങ്ങളുടെ സെറ്റ് പരിഹാരത്തിൽ ഉൾപ്പെടുത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, ചില ഘടകങ്ങൾ റൂട്ട് ഘടകങ്ങളാണ്, അവ നീക്കംചെയ്യുന്നത് പരിഹാരത്തിന്റെ പൂർണ്ണമായോ ഭാഗികമായോ പ്രവർത്തനരഹിതമാക്കും. ഈ ഘടകങ്ങളെ സാധാരണയായി തരം തിരിച്ചിരിക്കുന്നു:

• ഡാഷ്ബോർഡ് — OpenStack സേവനങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള വെബ് അധിഷ്ഠിത GUI
• കെയ്സ്തൊനെ മറ്റ് സേവനങ്ങൾക്ക് ആധികാരികതയും അംഗീകാര പ്രവർത്തനവും നൽകുന്ന ഒരു കേന്ദ്രീകൃത ഐഡന്റിറ്റി സേവനമാണ്, കൂടാതെ ഉപയോക്തൃ ക്രെഡൻഷ്യലുകളും അവരുടെ റോളുകളും കൈകാര്യം ചെയ്യുന്നു.
• ന്യൂട്രോൺ - വിവിധ ഓപ്പൺസ്റ്റാക്ക് സേവനങ്ങളുടെ ഇന്റർഫേസുകൾക്കിടയിൽ കണക്റ്റിവിറ്റി നൽകുന്ന ഒരു നെറ്റ്‌വർക്ക് സേവനം (VM-കൾ തമ്മിലുള്ള കണക്റ്റിവിറ്റിയും പുറം ലോകത്തേക്കുള്ള അവയുടെ പ്രവേശനവും ഉൾപ്പെടെ)
• സിൻഡർ — വെർച്വൽ മെഷീനുകൾക്കുള്ള ബ്ലോക്ക് സ്റ്റോറേജിലേക്കുള്ള ആക്സസ് നൽകുന്നു
• നോവ — വെർച്വൽ മെഷീനുകളുടെ ലൈഫ് സൈക്കിൾ മാനേജ്മെന്റ്
• ഒറ്റനോട്ടത്തിൽ — വെർച്വൽ മെഷീൻ ഇമേജുകളുടെയും സ്നാപ്പ്ഷോട്ടുകളുടെയും ശേഖരം
• സ്വിഫ്റ്റ് — സ്റ്റോറേജ് ഒബ്ജക്റ്റിലേക്കുള്ള പ്രവേശനം നൽകുന്നു
• സീലോമീറ്റർ - ടെലിമെട്രി ശേഖരിക്കാനും ലഭ്യമായതും ഉപയോഗിക്കുന്നതുമായ വിഭവങ്ങൾ അളക്കാനുള്ള കഴിവ് നൽകുന്ന ഒരു സേവനം
• ഹീറ്റ് — സ്വയമേവ സൃഷ്ടിക്കുന്നതിനും വിഭവങ്ങൾ ലഭ്യമാക്കുന്നതിനുമുള്ള ടെംപ്ലേറ്റുകളെ അടിസ്ഥാനമാക്കിയുള്ള ഓർക്കസ്ട്രേഷൻ

എല്ലാ പ്രോജക്റ്റുകളുടെയും പൂർണ്ണമായ പട്ടികയും അവയുടെ ഉദ്ദേശ്യവും കാണാൻ കഴിയും ഇവിടെ.

ഓരോ ഓപ്പൺസ്റ്റാക്ക് ഘടകഭാഗവും ഒരു നിർദ്ദിഷ്ട ഫംഗ്ഷൻ നിർവ്വഹിക്കുന്ന ഒരു സേവനമാണ്, കൂടാതെ ആ ഫംഗ്ഷൻ നിയന്ത്രിക്കുന്നതിനും ഒരു ഏകീകൃത ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിക്കുന്നതിന് മറ്റ് ക്ലൗഡ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം സേവനങ്ങളുമായി സംവദിക്കുന്നതിനും ഒരു API നൽകുന്നു. ഉദാഹരണത്തിന്, നോവ കമ്പ്യൂട്ടിംഗ് റിസോഴ്‌സ് മാനേജ്‌മെന്റും ഈ റിസോഴ്‌സുകൾ കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള ആക്‌സസ്സിനായി ഒരു API നൽകുന്നു, Glance ഇമേജ് മാനേജ്‌മെന്റും അവ കൈകാര്യം ചെയ്യുന്നതിനുള്ള API നൽകുന്നു, Cinder ബ്ലോക്ക് സ്‌റ്റോറേജും അത് കൈകാര്യം ചെയ്യുന്നതിനുള്ള API യും നൽകുന്നു. എല്ലാ പ്രവർത്തനങ്ങളും വളരെ അടുത്ത രീതിയിൽ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു.

എന്നിരുന്നാലും, നിങ്ങൾ അത് നോക്കുകയാണെങ്കിൽ, ഓപ്പൺസ്റ്റാക്കിൽ പ്രവർത്തിക്കുന്ന എല്ലാ സേവനങ്ങളും ആത്യന്തികമായി നെറ്റ്‌വർക്കിലേക്ക് കണക്റ്റുചെയ്തിരിക്കുന്ന ഏതെങ്കിലും തരത്തിലുള്ള വെർച്വൽ മെഷീനാണ് (അല്ലെങ്കിൽ കണ്ടെയ്‌നർ). ചോദ്യം ഉയർന്നുവരുന്നു - എന്തുകൊണ്ടാണ് നമുക്ക് ഇത്രയധികം ഘടകങ്ങൾ വേണ്ടത്?

ഒരു വെർച്വൽ മെഷീൻ സൃഷ്‌ടിച്ച് അതിനെ നെറ്റ്‌വർക്കിലേക്കും ഓപ്പൺസ്റ്റാക്കിലെ സ്ഥിരമായ സംഭരണത്തിലേക്കും ബന്ധിപ്പിക്കുന്നതിനുള്ള അൽഗോരിതം നോക്കാം.

1. നിങ്ങൾ ഒരു മെഷീൻ സൃഷ്‌ടിക്കാൻ ഒരു അഭ്യർത്ഥന സൃഷ്‌ടിക്കുമ്പോൾ, അത് ഹൊറൈസൺ (ഡാഷ്‌ബോർഡ്) വഴിയുള്ള അഭ്യർത്ഥനയോ അല്ലെങ്കിൽ CLI വഴിയുള്ള അഭ്യർത്ഥനയോ ആകട്ടെ, ആദ്യം സംഭവിക്കുന്നത് കീസ്റ്റോണിലെ നിങ്ങളുടെ അഭ്യർത്ഥനയുടെ അംഗീകാരമാണ് - നിങ്ങൾക്ക് ഒരു മെഷീൻ സൃഷ്ടിക്കാൻ കഴിയുമോ, അതിനുണ്ടോ ഈ നെറ്റ്‌വർക്ക് ഉപയോഗിക്കാനുള്ള അവകാശം, നിങ്ങളുടെ ഡ്രാഫ്റ്റ് ക്വാട്ട മുതലായവ.
2. കീസ്റ്റോൺ നിങ്ങളുടെ അഭ്യർത്ഥന പ്രാമാണീകരിക്കുകയും പ്രതികരണ സന്ദേശത്തിൽ ഒരു ഓത്ത് ടോക്കൺ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു, അത് കൂടുതൽ ഉപയോഗിക്കും. കീസ്റ്റോണിൽ നിന്ന് ഒരു പ്രതികരണം ലഭിച്ച ശേഷം, അഭ്യർത്ഥന നോവയിലേക്ക് (nova api) അയയ്ക്കുന്നു.
3. മുമ്പ് ജനറേറ്റ് ചെയ്ത ഓത്ത് ടോക്കൺ ഉപയോഗിച്ച് കീസ്റ്റോണുമായി ബന്ധപ്പെട്ട് Nova-api നിങ്ങളുടെ അഭ്യർത്ഥനയുടെ സാധുത പരിശോധിക്കുന്നു
4. കീസ്റ്റോൺ പ്രാമാണീകരണം നടത്തുകയും ഈ ഓത്ത് ടോക്കണിനെ അടിസ്ഥാനമാക്കി അനുമതികളെയും നിയന്ത്രണങ്ങളെയും കുറിച്ചുള്ള വിവരങ്ങൾ നൽകുകയും ചെയ്യുന്നു.
5. Nova-api, nova-database-ൽ പുതിയ VM-നായി ഒരു എൻട്രി സൃഷ്ടിക്കുകയും, nova-scheduler-ലേക്ക് മെഷീൻ സൃഷ്ടിക്കുന്നതിനുള്ള അഭ്യർത്ഥന കൈമാറുകയും ചെയ്യുന്നു.
6. നോവ-ഷെഡ്യൂളർ, നിർദ്ദിഷ്ട പാരാമീറ്ററുകൾ, ഭാരം, സോണുകൾ എന്നിവ അടിസ്ഥാനമാക്കി VM വിന്യസിക്കുന്ന ഹോസ്റ്റ് (കമ്പ്യൂട്ടർ നോഡ്) തിരഞ്ഞെടുക്കുന്നു. ഇതിന്റെ ഒരു റെക്കോർഡും VM ഐഡിയും nova-database-ൽ എഴുതിയിരിക്കുന്നു.
7. അടുത്തതായി, നോവ-ഷെഡ്യൂളർ നോവ-കമ്പ്യൂട്ടുമായി ഒരു ഉദാഹരണം വിന്യസിക്കാനുള്ള അഭ്യർത്ഥനയുമായി ബന്ധപ്പെടുന്നു. മെഷീൻ പാരാമീറ്ററുകളെ കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കാൻ നോവ-കമ്പ്യൂട്ടർ നോവ-കണ്ടക്റ്റർ കോൺടാക്റ്റ് ചെയ്യുന്നു (നോവ-കണ്ടക്റ്റർ നോവ-ഡേറ്റാബേസിനും നോവ-കമ്പ്യൂട്ടിനും ഇടയിൽ ഒരു പ്രോക്സി സെർവറായി പ്രവർത്തിക്കുന്ന ഒരു നോവ ഘടകമാണ്, ഡാറ്റാബേസിലെ പ്രശ്നങ്ങൾ ഒഴിവാക്കാൻ നോവ-ഡേറ്റാബേസിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നു. സ്ഥിരത ലോഡ് കുറയ്ക്കൽ).
8. Nova-conductor, nova-database-ൽ നിന്ന് ആവശ്യപ്പെട്ട വിവരങ്ങൾ സ്വീകരിക്കുകയും അത് nova-compute-ലേക്ക് കൈമാറുകയും ചെയ്യുന്നു.
9. അടുത്തതായി, ഇമേജ് ഐഡി ലഭിക്കാൻ nova-compute കോളുകൾ നോക്കുക. Glace കീസ്റ്റോണിലെ അഭ്യർത്ഥന സാധൂകരിക്കുകയും ആവശ്യപ്പെട്ട വിവരങ്ങൾ തിരികെ നൽകുകയും ചെയ്യുന്നു.
10. നെറ്റ്‌വർക്ക് പാരാമീറ്ററുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുന്നതിന് നോവ-കമ്പ്യൂട്ട് കോൺടാക്റ്റ് ന്യൂട്രോൺ. നോട്ടത്തിന് സമാനമായി, കീസ്റ്റോണിലെ അഭ്യർത്ഥനയെ ന്യൂട്രോൺ സാധൂകരിക്കുന്നു, അതിനുശേഷം അത് ഡാറ്റാബേസിൽ (പോർട്ട് ഐഡന്റിഫയർ മുതലായവ) ഒരു എൻട്രി സൃഷ്ടിക്കുന്നു, ഒരു പോർട്ട് സൃഷ്ടിക്കാൻ ഒരു അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു, കൂടാതെ അഭ്യർത്ഥിച്ച വിവരങ്ങൾ നോവ-കമ്പ്യൂട്ടിലേക്ക് തിരികെ നൽകുന്നു.
11. വിർച്ച്വൽ മെഷീനിലേക്ക് ഒരു വോളിയം അനുവദിക്കുന്നതിനുള്ള അഭ്യർത്ഥനയോടെ നോവ-കമ്പ്യൂട്ട് കോൺടാക്റ്റ് സിൻഡർ. നോട്ടത്തിന് സമാനമായി, കീസ്റ്റോണിലെ അഭ്യർത്ഥനയെ സൈഡർ സാധൂകരിക്കുന്നു, ഒരു വോളിയം സൃഷ്ടിക്കൽ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു, അഭ്യർത്ഥിച്ച വിവരങ്ങൾ തിരികെ നൽകുന്നു.
12. Nova-compute contacts libvirt, നിർദ്ദിഷ്‌ട പാരാമീറ്ററുകൾ ഉള്ള ഒരു വെർച്വൽ മെഷീൻ വിന്യസിക്കുന്നതിനുള്ള അഭ്യർത്ഥന.

വാസ്തവത്തിൽ, ഒരു ലളിതമായ വെർച്വൽ മെഷീൻ സൃഷ്ടിക്കുന്നതിനുള്ള ലളിതമായ പ്രവർത്തനം, ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിലെ ഘടകങ്ങൾ തമ്മിലുള്ള API കോളുകളുടെ ഒരു ചുഴലിക്കാറ്റായി മാറുന്നു. മാത്രമല്ല, നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, മുമ്പ് നിയുക്ത സേവനങ്ങൾ പോലും പരസ്പരം ഇടപെടുന്ന ചെറിയ ഘടകങ്ങൾ ഉൾക്കൊള്ളുന്നു. ഒരു മെഷീൻ സൃഷ്‌ടിക്കുന്നത് ക്ലൗഡ് പ്ലാറ്റ്‌ഫോം നിങ്ങളെ അനുവദിക്കുന്നതിന്റെ ഒരു ചെറിയ ഭാഗം മാത്രമാണ് - ട്രാഫിക് സന്തുലിതമാക്കുന്നതിന് ഉത്തരവാദിത്തമുള്ള ഒരു സേവനം, ബ്ലോക്ക് സ്റ്റോറേജിന്റെ ഉത്തരവാദിത്തമുള്ള ഒരു സേവനം, DNS-ന്റെ ഉത്തരവാദിത്തമുള്ള ഒരു സേവനം, നഗ്നമായ മെറ്റൽ സെർവറുകൾ നൽകുന്നതിന് ഉത്തരവാദിത്തമുള്ള ഒരു സേവനം തുടങ്ങിയവയുണ്ട്. നിങ്ങളുടെ വെർച്വൽ മെഷീനുകളെ ഒരു ആട്ടിൻ കൂട്ടത്തെ പോലെ കൈകാര്യം ചെയ്യാൻ ക്ലൗഡ് നിങ്ങളെ അനുവദിക്കുന്നു (വെർച്വലൈസേഷനു വിരുദ്ധമായി). ഒരു വെർച്വൽ പരിതസ്ഥിതിയിൽ നിങ്ങളുടെ മെഷീന് എന്തെങ്കിലും സംഭവിച്ചാൽ - ബാക്കപ്പുകൾ മുതലായവയിൽ നിന്ന് നിങ്ങൾ അത് പുനഃസ്ഥാപിക്കുന്നു, എന്നാൽ ക്ലൗഡ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിച്ചിരിക്കുന്നത് വെർച്വൽ മെഷീൻ അത്ര പ്രധാന പങ്ക് വഹിക്കാത്ത വിധത്തിലാണ് - വെർച്വൽ മെഷീൻ "മരിച്ചു" - ഒരു പ്രശ്നവുമില്ല. - ഒരു പുതിയത് ലളിതമായി സൃഷ്ടിച്ചതാണ് വാഹനം ടെംപ്ലേറ്റിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, അവർ പറയുന്നതുപോലെ, പോരാളിയുടെ നഷ്ടം സ്ക്വാഡ് ശ്രദ്ധിച്ചില്ല. സ്വാഭാവികമായും, ഇത് ഓർക്കസ്ട്രേഷൻ മെക്കാനിസങ്ങളുടെ സാന്നിധ്യം നൽകുന്നു - ഹീറ്റ് ടെംപ്ലേറ്റുകൾ ഉപയോഗിച്ച്, ഡസൻ കണക്കിന് നെറ്റ്‌വർക്കുകളും വെർച്വൽ മെഷീനുകളും അടങ്ങുന്ന ഒരു സങ്കീർണ്ണ പ്രവർത്തനം നിങ്ങൾക്ക് എളുപ്പത്തിൽ വിന്യസിക്കാൻ കഴിയും.

ഒരു നെറ്റ്‌വർക്ക് ഇല്ലാതെ ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചർ ഇല്ല എന്നത് എല്ലായ്പ്പോഴും ഓർമ്മിക്കേണ്ടതാണ് - ഓരോ ഘടകങ്ങളും ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്ന് നെറ്റ്‌വർക്കിലൂടെ മറ്റ് ഘടകങ്ങളുമായി സംവദിക്കുന്നു. കൂടാതെ, ക്ലൗഡിന് തികച്ചും നോൺ-സ്റ്റാറ്റിക് നെറ്റ്‌വർക്ക് ഉണ്ട്. സ്വാഭാവികമായും, അണ്ടർലേ നെറ്റ്‌വർക്ക് കൂടുതലോ കുറവോ സ്റ്റാറ്റിക് ആണ് - എല്ലാ ദിവസവും പുതിയ നോഡുകളും സ്വിച്ചുകളും ചേർക്കില്ല, എന്നാൽ ഓവർലേ ഘടകം നിരന്തരം മാറുകയും അനിവാര്യമായും മാറുകയും ചെയ്യും - പുതിയ നെറ്റ്‌വർക്കുകൾ ചേർക്കുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യും, പുതിയ വെർച്വൽ മെഷീനുകൾ ദൃശ്യമാകും, പഴയവ ദൃശ്യമാകും. മരിക്കുന്നു. ലേഖനത്തിന്റെ തുടക്കത്തിൽ നൽകിയിരിക്കുന്ന ക്ലൗഡിന്റെ നിർവചനത്തിൽ നിന്ന് നിങ്ങൾ ഓർക്കുന്നത് പോലെ, ഉറവിടങ്ങൾ ഉപയോക്താവിന് സ്വയമേവയും സേവന ദാതാവിൽ നിന്നുള്ള ഏറ്റവും കുറഞ്ഞ (അല്ലെങ്കിൽ മികച്ചത്, ഇല്ലാതെ) ഇടപെടലോടെയും അനുവദിക്കണം. അതായത്, http/https വഴി ആക്‌സസ് ചെയ്യാവുന്ന നിങ്ങളുടെ സ്വകാര്യ അക്കൗണ്ടിന്റെ ഒരു ഫ്രണ്ട്-എൻഡ് രൂപത്തിൽ ഇപ്പോൾ നിലനിൽക്കുന്ന നെറ്റ്‌വർക്ക് ഉറവിടങ്ങളുടെ പ്രൊവിവിഷൻ തരം ഒരു ക്ലൗഡ് അല്ല. വാസിലിക്ക് എട്ട് കൈകളുണ്ടെങ്കിൽ.

ഒരു നെറ്റ്‌വർക്ക് സേവനമെന്ന നിലയിൽ ന്യൂട്രോൺ, ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ നെറ്റ്‌വർക്ക് ഭാഗം നിയന്ത്രിക്കുന്നതിന് ഒരു API നൽകുന്നു. Network-as-a-Service (NaaS) എന്ന അബ്‌സ്‌ട്രാക്ഷൻ ലെയർ നൽകിക്കൊണ്ട് ഈ സേവനം ഓപ്പൺസ്റ്റാക്കിന്റെ നെറ്റ്‌വർക്കിംഗ് ഭാഗത്തെ ശക്തിപ്പെടുത്തുകയും നിയന്ത്രിക്കുകയും ചെയ്യുന്നു. അതായത്, നെറ്റ്‌വർക്ക് എന്നത് വെർച്വൽ അളക്കാവുന്ന യൂണിറ്റാണ്, ഉദാഹരണത്തിന്, വെർച്വൽ സിപിയു കോറുകൾ അല്ലെങ്കിൽ റാമിന്റെ അളവ്.

എന്നാൽ OpenStack-ന്റെ നെറ്റ്‌വർക്ക് ഭാഗത്തിന്റെ ആർക്കിടെക്ചറിലേക്ക് പോകുന്നതിന് മുമ്പ്, OpenStack-ൽ ഈ നെറ്റ്‌വർക്ക് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും നെറ്റ്‌വർക്ക് ക്ലൗഡിന്റെ പ്രധാനവും അവിഭാജ്യ ഘടകവുമായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്നും നമുക്ക് നോക്കാം.

അതിനാൽ ഞങ്ങൾക്ക് രണ്ട് RED ക്ലയന്റ് 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 ഇന്റർഫേസ് സ്ഥിതിചെയ്യുന്ന നോഡ്, ഓരോന്നിനും ഒറ്റപ്പെടലിനായി പ്രത്യേക നെയിംസ്‌പെയ്‌സ്.

എന്നിരുന്നാലും, ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം ഞങ്ങൾ മറന്നു. വെർച്വൽ മെഷീൻ ക്ലയന്റിന് ഒരു സേവനം നൽകണം, അതായത്, അതിന് എത്തിച്ചേരാൻ കഴിയുന്ന ഒരു ബാഹ്യ ഇന്റർഫേസെങ്കിലും ഉണ്ടായിരിക്കണം. അതായത്, നമ്മൾ പുറം ലോകത്തേക്ക് പോകേണ്ടതുണ്ട്. ഇവിടെ വ്യത്യസ്ത ഓപ്ഷനുകൾ ഉണ്ട്. നമുക്ക് ഏറ്റവും ലളിതമായ ഓപ്ഷൻ ചെയ്യാം. ഓരോ ക്ലയന്റിലേക്കും ഞങ്ങൾ ഒരു നെറ്റ്‌വർക്ക് ചേർക്കും, അത് ദാതാവിന്റെ നെറ്റ്‌വർക്കിൽ സാധുതയുള്ളതും മറ്റ് നെറ്റ്‌വർക്കുകളുമായി ഓവർലാപ്പ് ചെയ്യുന്നതുമല്ല. നെറ്റ്‌വർക്കുകൾക്ക് വിഭജിക്കാനും ദാതാവിന്റെ നെറ്റ്‌വർക്കിന്റെ വശത്തുള്ള വ്യത്യസ്ത വിആർഎഫുകൾ നോക്കാനും കഴിയും. ഓരോ ക്ലയന്റിന്റെയും നെയിംസ്‌പെയ്‌സിൽ നെറ്റ്‌വർക്ക് ഡാറ്റയും നിലനിൽക്കും. എന്നിരുന്നാലും, അവർ ഇപ്പോഴും ഒരു ഫിസിക്കൽ (അല്ലെങ്കിൽ ബോണ്ട്, അത് കൂടുതൽ ലോജിക്കൽ) ഇന്റർഫേസിലൂടെ പുറം ലോകത്തേക്ക് പോകും. ക്ലയന്റ് ട്രാഫിക്ക് വേർതിരിക്കുന്നതിന്, പുറത്തേക്ക് പോകുന്ന ട്രാഫിക്ക് ക്ലയന്റിനായി അനുവദിച്ച VLAN ടാഗ് ഉപയോഗിച്ച് ടാഗ് ചെയ്യും.

തൽഫലമായി, ഞങ്ങൾക്ക് ഈ ഡയഗ്രം ലഭിച്ചു:

ന്യായമായ ഒരു ചോദ്യം എന്തുകൊണ്ട് കമ്പ്യൂട്ട് നോഡുകളിൽ തന്നെ ഗേറ്റ്‌വേകൾ ഉണ്ടാക്കിക്കൂടാ? ഇതൊരു വലിയ പ്രശ്നമല്ല; കൂടാതെ, നിങ്ങൾ വിതരണം ചെയ്ത റൂട്ടർ (DVR) ഓണാക്കുകയാണെങ്കിൽ, ഇത് പ്രവർത്തിക്കും. ഈ സാഹചര്യത്തിൽ, Openstack-ൽ സ്ഥിരസ്ഥിതിയായി ഉപയോഗിക്കുന്ന ഒരു കേന്ദ്രീകൃത ഗേറ്റ്‌വേ ഉള്ള ഏറ്റവും ലളിതമായ ഓപ്ഷൻ ഞങ്ങൾ പരിഗണിക്കുന്നു. ഉയർന്ന ലോഡ് ഫംഗ്‌ഷനുകൾക്കായി, അവർ വിതരണം ചെയ്‌ത റൂട്ടറും SR-IOV, Passthrough പോലുള്ള ആക്‌സിലറേഷൻ സാങ്കേതികവിദ്യകളും ഉപയോഗിക്കും, പക്ഷേ അവർ പറയുന്നതുപോലെ, ഇത് തികച്ചും വ്യത്യസ്തമായ കഥയാണ്. ആദ്യം, നമുക്ക് അടിസ്ഥാന ഭാഗം കൈകാര്യം ചെയ്യാം, തുടർന്ന് ഞങ്ങൾ വിശദാംശങ്ങളിലേക്ക് പോകാം.

യഥാർത്ഥത്തിൽ, ഞങ്ങളുടെ സ്കീം ഇതിനകം പ്രവർത്തനക്ഷമമാണ്, എന്നാൽ കുറച്ച് സൂക്ഷ്മതകളുണ്ട്:

• ഞങ്ങളുടെ മെഷീനുകളെ എങ്ങനെയെങ്കിലും സംരക്ഷിക്കേണ്ടതുണ്ട്, അതായത്, ക്ലയന്റിലേക്ക് സ്വിച്ച് ഇന്റർഫേസിൽ ഒരു ഫിൽട്ടർ ഇടുക.
• ഒരു വെർച്വൽ മെഷീന് സ്വയമേവ ഒരു IP വിലാസം ലഭിക്കുന്നത് സാധ്യമാക്കുക, അതുവഴി നിങ്ങൾ ഓരോ തവണയും കൺസോൾ വഴി ലോഗിൻ ചെയ്യേണ്ടതില്ല, വിലാസം രജിസ്റ്റർ ചെയ്യുക.

മെഷീൻ സംരക്ഷണത്തോടെ ആരംഭിക്കാം. ഇതിനായി നിങ്ങൾക്ക് banal iptables ഉപയോഗിക്കാം, എന്തുകൊണ്ട്.

അതായത്, ഇപ്പോൾ നമ്മുടെ ടോപ്പോളജി കുറച്ചുകൂടി സങ്കീർണ്ണമായിരിക്കുന്നു:

നമുക്ക് നീങ്ങാം. ഞങ്ങൾക്ക് ഒരു 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 വഴി ഈ പോർട്ടലിലേക്ക് കണക്റ്റുചെയ്യാനും അവന് ആവശ്യമുള്ളതെല്ലാം ചെയ്യാനും കഴിയും (നന്നായി, മിക്കവാറും).

തൽഫലമായി, നമുക്ക് ഇപ്പോൾ ഒരു തെറ്റ്-സഹിഷ്ണുത സംവിധാനമുണ്ട്. ഈ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ എല്ലാ ഘടകങ്ങളും എങ്ങനെയെങ്കിലും കൈകാര്യം ചെയ്യണം. ഓപ്പൺസ്റ്റാക്ക് ഒരു കൂട്ടം പ്രോജക്റ്റുകളാണെന്ന് മുമ്പ് വിവരിച്ചിരുന്നു, അവയിൽ ഓരോന്നും ഒരു പ്രത്യേക പ്രവർത്തനം നൽകുന്നു. നമ്മൾ കാണുന്നതുപോലെ, കോൺഫിഗർ ചെയ്യുകയും നിയന്ത്രിക്കുകയും ചെയ്യേണ്ട ആവശ്യത്തിലധികം ഘടകങ്ങൾ ഉണ്ട്. ഇന്ന് നമ്മൾ നെറ്റ്വർക്ക് ഭാഗത്തെക്കുറിച്ച് സംസാരിക്കും.

ന്യൂട്രോൺ ആർക്കിടെക്ചർ

ഓപ്പൺസ്റ്റാക്കിൽ, ഒരു സാധാരണ L2 നെറ്റ്‌വർക്കിലേക്ക് വെർച്വൽ മെഷീൻ പോർട്ടുകളെ ബന്ധിപ്പിക്കുന്നതിനും വ്യത്യസ്ത L2 നെറ്റ്‌വർക്കുകളിൽ സ്ഥിതിചെയ്യുന്ന VM-കൾക്കിടയിൽ ട്രാഫിക് റൂട്ടിംഗ് ഉറപ്പാക്കുന്നതിനും പുറത്തേക്കുള്ള റൂട്ടിംഗ് ഉറപ്പാക്കുന്നതിനും NAT, Floating IP, DHCP തുടങ്ങിയ സേവനങ്ങൾ നൽകുന്നതിനും ഉത്തരവാദി ന്യൂട്രോണാണ്.

ഉയർന്ന തലത്തിൽ, നെറ്റ്‌വർക്ക് സേവനത്തിന്റെ പ്രവർത്തനം (അടിസ്ഥാന ഭാഗം) ഇനിപ്പറയുന്ന രീതിയിൽ വിവരിക്കാം.

VM ആരംഭിക്കുമ്പോൾ, നെറ്റ്‌വർക്ക് സേവനം:

1. തന്നിരിക്കുന്ന VM (അല്ലെങ്കിൽ പോർട്ടുകൾ)ക്കായി ഒരു പോർട്ട് സൃഷ്‌ടിക്കുകയും അതിനെക്കുറിച്ച് DHCP സേവനത്തെ അറിയിക്കുകയും ചെയ്യുന്നു;
2. ഒരു പുതിയ വെർച്വൽ നെറ്റ്‌വർക്ക് ഉപകരണം സൃഷ്ടിച്ചു (libvirt വഴി);
3. ഘട്ടം 1-ൽ സൃഷ്ടിച്ച പോർട്ട്(കളിലേക്ക്) VM ബന്ധിപ്പിക്കുന്നു;

വിചിത്രമെന്നു പറയട്ടെ, ന്യൂട്രോണിന്റെ പ്രവർത്തനം ലിനക്സിലേക്ക് കടന്ന എല്ലാവർക്കും പരിചിതമായ സ്റ്റാൻഡേർഡ് മെക്കാനിസങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് - നെയിംസ്‌പേസുകൾ, ഐപ്‌ടേബിളുകൾ, ലിനക്സ് ബ്രിഡ്ജുകൾ, ഓപ്പൺസ്വിച്ച്, കോൺട്രാക്ക് മുതലായവ.

ന്യൂട്രോൺ ഒരു SDN കൺട്രോളർ അല്ലെന്ന് ഉടൻ വ്യക്തമാക്കണം.

ന്യൂട്രോണിൽ പരസ്പരബന്ധിതമായ നിരവധി ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

ഓപ്പൺസ്റ്റാക്ക്-ന്യൂട്രോൺ-സെർവർ API വഴിയുള്ള ഉപയോക്തൃ അഭ്യർത്ഥനകളിൽ പ്രവർത്തിക്കുന്ന ഒരു ഡെമൺ ആണ്. ഈ ഭൂതം ഏതെങ്കിലും നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ രജിസ്റ്റർ ചെയ്യുന്നതിൽ ഉൾപ്പെട്ടിട്ടില്ല, എന്നാൽ ഇതിന് ആവശ്യമായ വിവരങ്ങൾ അതിന്റെ പ്ലഗിനുകൾക്ക് നൽകുന്നു, അത് ആവശ്യമുള്ള നെറ്റ്‌വർക്ക് ഘടകം ക്രമീകരിക്കുന്നു. ഓപ്പൺസ്റ്റാക്ക് നോഡുകളിലെ ന്യൂട്രോൺ ഏജന്റുകൾ ന്യൂട്രോൺ സെർവറിൽ രജിസ്റ്റർ ചെയ്യുന്നു.

ന്യൂട്രോൺ-സെർവർ യഥാർത്ഥത്തിൽ പൈത്തണിൽ എഴുതിയ രണ്ട് ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്ന ഒരു ആപ്ലിക്കേഷനാണ്:

• വിശ്രമ സേവനം
• ന്യൂട്രോൺ പ്ലഗിൻ (കോർ/സർവീസ്)

മറ്റ് ഘടകങ്ങളിൽ നിന്ന് API കോളുകൾ സ്വീകരിക്കുന്നതിനാണ് REST സേവനം രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് (ഉദാഹരണത്തിന്, ചില വിവരങ്ങൾ നൽകാനുള്ള അഭ്യർത്ഥന മുതലായവ)

API അഭ്യർത്ഥനകൾക്കിടയിൽ വിളിക്കപ്പെടുന്ന പ്ലഗ്-ഇൻ സോഫ്റ്റ്‌വെയർ ഘടകങ്ങൾ/മൊഡ്യൂളുകളാണ് പ്ലഗിനുകൾ - അതായത്, ഒരു സേവനത്തിന്റെ ആട്രിബ്യൂഷൻ അവയിലൂടെയാണ് സംഭവിക്കുന്നത്. പ്ലഗിനുകളെ രണ്ട് തരങ്ങളായി തിരിച്ചിരിക്കുന്നു - സേവനവും റൂട്ടും. ചട്ടം പോലെ, കുതിര പ്ലഗിൻ പ്രധാനമായും വിലാസ ഇടവും VM-കൾ തമ്മിലുള്ള L2 കണക്ഷനുകളും കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഉത്തരവാദിത്തമാണ്, കൂടാതെ സേവന പ്ലഗിനുകൾ ഇതിനകം തന്നെ VPN അല്ലെങ്കിൽ FW പോലുള്ള അധിക പ്രവർത്തനം നൽകുന്നു.

ഇന്ന് ലഭ്യമായ പ്ലഗിന്നുകളുടെ ലിസ്റ്റ് ഉദാഹരണമായി കാണാൻ കഴിയും ഇവിടെ

നിരവധി സേവന പ്ലഗിനുകൾ ഉണ്ടാകാം, എന്നാൽ ഒരു കുതിര പ്ലഗിൻ മാത്രമേ ഉണ്ടാകൂ.

openstack-neutron-ml2 സാധാരണ Openstack റൂട്ട് പ്ലഗിൻ ആണ്. ഈ പ്ലഗിന് ഒരു മോഡുലാർ ആർക്കിടെക്ചർ ഉണ്ട് (അതിന്റെ മുൻഗാമിയായതിൽ നിന്ന് വ്യത്യസ്തമായി) കൂടാതെ നെറ്റ്‌വർക്ക് സേവനം അതുമായി ബന്ധിപ്പിച്ചിട്ടുള്ള ഡ്രൈവറുകൾ വഴി കോൺഫിഗർ ചെയ്യുന്നു. ഞങ്ങൾ പ്ലഗിൻ കുറച്ച് കഴിഞ്ഞ് നോക്കാം, കാരണം യഥാർത്ഥത്തിൽ ഇത് ഓപ്പൺസ്റ്റാക്കിന് നെറ്റ്‌വർക്ക് ഭാഗത്ത് ഉള്ള വഴക്കം നൽകുന്നു. റൂട്ട് പ്ലഗിൻ മാറ്റിസ്ഥാപിക്കാൻ കഴിയും (ഉദാഹരണത്തിന്, കോൺട്രെയ്ൽ നെറ്റ്‌വർക്കിംഗ് അത്തരമൊരു മാറ്റിസ്ഥാപിക്കുന്നു).

RPC സേവനം (rabbitmq-സെർവർ) — ക്യൂ മാനേജ്മെന്റും മറ്റ് ഓപ്പൺസ്റ്റാക്ക് സേവനങ്ങളുമായുള്ള ആശയവിനിമയവും നെറ്റ്‌വർക്ക് സേവന ഏജന്റുമാർ തമ്മിലുള്ള ആശയവിനിമയവും നൽകുന്ന ഒരു സേവനം.

നെറ്റ്‌വർക്ക് ഏജന്റുകൾ — നെറ്റ്‌വർക്ക് സേവനങ്ങൾ ക്രമീകരിച്ചിരിക്കുന്ന ഓരോ നോഡിലും സ്ഥിതിചെയ്യുന്ന ഏജന്റുകൾ.

നിരവധി തരം ഏജന്റുകളുണ്ട്.

പ്രധാന ഏജന്റ് ആണ് 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, contrack, namespaces എന്നിവയ്‌ക്കൊപ്പം പൂർണ്ണമായ മൾട്ടി-ടെനൻസി ഓവർലേ നെറ്റ്‌വർക്കുകൾ സംഘടിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. സ്വാഭാവികമായും, ഈ ഘടകം മാറ്റിസ്ഥാപിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, മൂന്നാം-കക്ഷി കുത്തക (വെണ്ടർ) SDN പരിഹാരങ്ങൾ ഉപയോഗിക്കുമ്പോൾ.

ഒവിഎസ് ഒരു ഓപ്പൺ സോഴ്‌സ് സോഫ്‌റ്റ്‌വെയർ സ്വിച്ചാണ്, അത് വെർച്വൽ ട്രാഫിക് ഫോർവേഡറായി വിർച്വലൈസ് ചെയ്‌ത പരിതസ്ഥിതികളിൽ ഉപയോഗിക്കാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു.

ഇപ്പോൾ, OVS-ന് വളരെ മാന്യമായ പ്രവർത്തനക്ഷമതയുണ്ട്, അതിൽ QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK മുതലായ സാങ്കേതികവിദ്യകൾ ഉൾപ്പെടുന്നു.

ശ്രദ്ധിക്കുക: ഉയർന്ന ലോഡുള്ള ടെലികോം ഫംഗ്‌ഷനുകൾക്കായുള്ള സോഫ്റ്റ് സ്വിച്ച് ആയിട്ടല്ല OVS ആദ്യം വിഭാവനം ചെയ്തിരുന്നത്, കൂടാതെ WEB സെർവർ അല്ലെങ്കിൽ മെയിൽ സെർവർ പോലുള്ള കുറഞ്ഞ ബാൻഡ്‌വിഡ്ത്ത് ആവശ്യപ്പെടുന്ന ഐടി ഫംഗ്‌ഷനുകൾക്കായി കൂടുതൽ രൂപകൽപ്പന ചെയ്‌തതാണ്. എന്നിരുന്നാലും, OVS കൂടുതൽ വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്നു, കൂടാതെ OVS-ന്റെ നിലവിലെ നിർവ്വഹണങ്ങൾ അതിന്റെ പ്രകടനവും കഴിവുകളും വളരെയധികം മെച്ചപ്പെടുത്തിയിട്ടുണ്ട്, ഇത് ഉയർന്ന ലോഡുചെയ്ത ഫംഗ്ഷനുകളുള്ള ടെലികോം ഓപ്പറേറ്റർമാർക്ക് ഇത് ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു, ഉദാഹരണത്തിന്, DPDK ആക്സിലറേഷനുള്ള പിന്തുണയോടെ ഒരു OVS നടപ്പിലാക്കൽ ഉണ്ട്.

നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട OVS-ന്റെ മൂന്ന് പ്രധാന ഘടകങ്ങളുണ്ട്:

• കേർണൽ മൊഡ്യൂൾ - നിയന്ത്രണ ഘടകത്തിൽ നിന്ന് ലഭിച്ച നിയമങ്ങളെ അടിസ്ഥാനമാക്കി ട്രാഫിക് പ്രോസസ്സ് ചെയ്യുന്ന കേർണൽ സ്ഥലത്ത് സ്ഥിതി ചെയ്യുന്ന ഒരു ഘടകം;
• v സ്വിച്ച് ഡെമൺ (ovs-vswitchd) എന്നത് കേർണൽ മൊഡ്യൂൾ പ്രോഗ്രാമിംഗിന് ഉത്തരവാദിയായ ഉപയോക്തൃ സ്ഥലത്ത് ആരംഭിച്ച ഒരു പ്രക്രിയയാണ് - അതായത്, ഇത് സ്വിച്ചിന്റെ പ്രവർത്തനത്തിന്റെ യുക്തിയെ നേരിട്ട് പ്രതിനിധീകരിക്കുന്നു.
• ഡാറ്റാബേസ് സെർവർ - കോൺഫിഗറേഷൻ സംഭരിച്ചിരിക്കുന്ന OVS പ്രവർത്തിക്കുന്ന ഓരോ ഹോസ്റ്റിലും സ്ഥിതിചെയ്യുന്ന ഒരു പ്രാദേശിക ഡാറ്റാബേസ്. SDN കൺട്രോളറുകൾക്ക് OVSDB പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് ഈ മൊഡ്യൂളിലൂടെ ആശയവിനിമയം നടത്താനാകും.

ovs-vsctl, ovs-appctl, ovs-ofctl മുതലായവ പോലുള്ള ഡയഗ്നോസ്റ്റിക്, മാനേജ്മെന്റ് യൂട്ടിലിറ്റികളുടെ ഒരു കൂട്ടം ഇതിനോടൊപ്പമുണ്ട്.

നിലവിൽ, EPC, SBC, HLR, തുടങ്ങിയ നെറ്റ്‌വർക്ക് ഫംഗ്‌ഷനുകൾ മൈഗ്രേറ്റ് ചെയ്യാൻ ടെലികോം ഓപ്പറേറ്റർമാർ ഓപ്പൺസ്റ്റാക്ക് വ്യാപകമായി ഉപയോഗിക്കുന്നു. ചില ഫംഗ്‌ഷനുകൾക്ക് OVS-ൽ പ്രശ്‌നങ്ങളില്ലാതെ ജീവിക്കാൻ കഴിയും, എന്നാൽ ഉദാഹരണത്തിന്, EPC സബ്‌സ്‌ക്രൈബർ ട്രാഫിക്ക് പ്രോസസ്സ് ചെയ്യുന്നു - തുടർന്ന് അത് കടന്നുപോകുന്നു. ഒരു വലിയ ട്രാഫിക് (ഇപ്പോൾ ട്രാഫിക് വോളിയം സെക്കൻഡിൽ നൂറുകണക്കിന് ജിഗാബൈറ്റിലെത്തുന്നു). സ്വാഭാവികമായും, കേർണൽ സ്‌പെയ്‌സിലൂടെ അത്തരം ട്രാഫിക് ഡ്രൈവ് ചെയ്യുന്നത് (ഫോർവേഡർ സ്ഥിരസ്ഥിതിയായി അവിടെ സ്ഥിതി ചെയ്യുന്നതിനാൽ) മികച്ച ആശയമല്ല. അതിനാൽ, കേർണലിനെ മറികടന്ന് എൻഐസിയിൽ നിന്ന് യൂസർ സ്പേസിലേക്ക് ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്നതിനായി ഡിപിഡികെ ആക്സിലറേഷൻ സാങ്കേതികവിദ്യ ഉപയോഗിച്ച് ഒവിഎസ് പൂർണ്ണമായും യൂസർ സ്പേസിൽ വിന്യസിക്കുന്നു.

ശ്രദ്ധിക്കുക: ടെലികോം ഫംഗ്‌ഷനുകൾക്കായി വിന്യസിച്ചിരിക്കുന്ന ഒരു ക്ലൗഡിനായി, ഒരു കമ്പ്യൂട്ട് നോഡിൽ നിന്ന് OVS-നെ നേരിട്ട് സ്വിച്ചിംഗ് ഉപകരണങ്ങളിലേക്ക് ബൈപാസ് ചെയ്‌ത് ട്രാഫിക്ക് ഔട്ട്‌പുട്ട് ചെയ്യാൻ സാധിക്കും. SR-IOV, Passthrough മെക്കാനിസങ്ങൾ ഇതിനായി ഉപയോഗിക്കുന്നു.

ഒരു യഥാർത്ഥ ലേഔട്ടിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കും?

ശരി, ഇപ്പോൾ നമുക്ക് പ്രായോഗിക ഭാഗത്തേക്ക് പോകാം, എല്ലാം പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നോക്കാം.

ആദ്യം, നമുക്ക് ഒരു ലളിതമായ Openstack ഇൻസ്റ്റലേഷൻ വിന്യസിക്കാം. പരീക്ഷണങ്ങൾക്കായി എന്റെ കൈയിൽ ഒരു സെറ്റ് സെർവറുകൾ ഇല്ലാത്തതിനാൽ, ഞങ്ങൾ വെർച്വൽ മെഷീനുകളിൽ നിന്ന് ഒരു ഫിസിക്കൽ സെർവറിൽ പ്രോട്ടോടൈപ്പ് കൂട്ടിച്ചേർക്കും. അതെ, സ്വാഭാവികമായും, അത്തരം ഒരു പരിഹാരം വാണിജ്യ ആവശ്യങ്ങൾക്ക് അനുയോജ്യമല്ല, എന്നാൽ ഓപ്പൺസ്റ്റാക്കിൽ നെറ്റ്വർക്ക് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ ഒരു ഉദാഹരണം കാണാൻ, അത്തരം ഒരു ഇൻസ്റ്റാളേഷൻ കണ്ണുകൾക്ക് മതിയാകും. മാത്രമല്ല, പരിശീലന ആവശ്യങ്ങൾക്കായി അത്തരമൊരു ഇൻസ്റ്റാളേഷൻ കൂടുതൽ രസകരമാണ് - നിങ്ങൾക്ക് ട്രാഫിക്ക് പിടിക്കാൻ കഴിയും എന്നതിനാൽ.

അടിസ്ഥാന ഭാഗം മാത്രം കാണേണ്ടതിനാൽ, ഞങ്ങൾക്ക് നിരവധി നെറ്റ്‌വർക്കുകൾ ഉപയോഗിക്കാനാവില്ല, പക്ഷേ രണ്ട് നെറ്റ്‌വർക്കുകൾ ഉപയോഗിച്ച് എല്ലാം ഉയർത്താം, കൂടാതെ ഈ ലേഔട്ടിലെ രണ്ടാമത്തെ നെറ്റ്‌വർക്ക് അണ്ടർക്ലൗഡിലേക്കും DNS സെർവറിലേക്കും ആക്‌സസ് ചെയ്യാൻ മാത്രമായി ഉപയോഗിക്കും. ഞങ്ങൾ ഇപ്പോൾ ബാഹ്യ നെറ്റ്‌വർക്കുകളിൽ സ്പർശിക്കില്ല - ഇത് ഒരു പ്രത്യേക വലിയ ലേഖനത്തിനുള്ള വിഷയമാണ്.

അതിനാൽ, നമുക്ക് ക്രമത്തിൽ ആരംഭിക്കാം. ആദ്യം, ഒരു ചെറിയ സിദ്ധാന്തം. ഞങ്ങൾ ട്രിപ്പിൾ ഒ (ഓപ്പൺസ്റ്റാക്കിലെ ഓപ്പൺസ്റ്റാക്ക്) ഉപയോഗിച്ച് ഓപ്പൺസ്റ്റാക്ക് ഇൻസ്റ്റാൾ ചെയ്യും. അണ്ടർക്ലൗഡ് എന്ന് വിളിക്കുന്ന ഓപ്പൺസ്റ്റാക്ക് ഓൾ-ഇൻ-വൺ (അതായത് ഒരു നോഡിൽ) ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, തുടർന്ന് ഓവർക്ലൗഡ് എന്ന് വിളിക്കപ്പെടുന്ന ഓപ്പൺസ്റ്റാക്ക് ഇൻസ്റ്റാൾ ചെയ്യാൻ വിന്യസിച്ചിരിക്കുന്ന ഓപ്പൺസ്റ്റാക്കിന്റെ കഴിവുകൾ ഉപയോഗിക്കുക എന്നതാണ് ട്രിപ്പിൾ ഒയുടെ സാരം. കമ്പ്യൂട്ട്, കൺട്രോൾ, സ്റ്റോറേജ് നോഡുകൾ എന്നിവയുടെ റോളുകൾ നിർവഹിക്കുന്ന ഹൈപ്പർവൈസറുകൾ നൽകുന്നതിന് അണ്ടർക്ലൗഡ് ഫിസിക്കൽ സെർവറുകൾ (ബെയർ മെറ്റൽ) - ഐറോണിക് പ്രോജക്റ്റ് - കൈകാര്യം ചെയ്യാനുള്ള അതിന്റെ അന്തർലീനമായ കഴിവ് ഉപയോഗിക്കും. അതായത്, Openstack വിന്യസിക്കാൻ ഞങ്ങൾ ഒരു മൂന്നാം കക്ഷി ടൂളുകളും ഉപയോഗിക്കുന്നില്ല - Openstack ഉപയോഗിച്ച് ഞങ്ങൾ Openstack വിന്യസിക്കുന്നു. ഇൻസ്റ്റാളേഷൻ പുരോഗമിക്കുമ്പോൾ ഇത് കൂടുതൽ വ്യക്തമാകും, അതിനാൽ ഞങ്ങൾ അവിടെ നിർത്തി മുന്നോട്ട് പോകില്ല.

കുറിപ്പ്: ഈ ലേഖനത്തിൽ, ലാളിത്യത്തിനായി, ആന്തരിക ഓപ്പൺസ്റ്റാക്ക് നെറ്റ്‌വർക്കുകൾക്കായി ഞാൻ നെറ്റ്‌വർക്ക് ഐസൊലേഷൻ ഉപയോഗിച്ചില്ല, പക്ഷേ എല്ലാം ഒരു നെറ്റ്‌വർക്ക് മാത്രം ഉപയോഗിച്ച് വിന്യസിച്ചിരിക്കുന്നു. എന്നിരുന്നാലും, നെറ്റ്‌വർക്ക് ഐസൊലേഷന്റെ സാന്നിധ്യമോ അഭാവമോ പരിഹാരത്തിന്റെ അടിസ്ഥാന പ്രവർത്തനത്തെ ബാധിക്കില്ല - ഒറ്റപ്പെടൽ ഉപയോഗിക്കുമ്പോൾ എല്ലാം കൃത്യമായി പ്രവർത്തിക്കും, പക്ഷേ ട്രാഫിക്ക് ഒരേ നെറ്റ്‌വർക്കിൽ ഒഴുകും. ഒരു വാണിജ്യ ഇൻസ്റ്റാളേഷനായി, വ്യത്യസ്ത vlans-ഉം ഇന്റർഫേസുകളും ഉപയോഗിച്ച് ഐസൊലേഷൻ ഉപയോഗിക്കേണ്ടത് സ്വാഭാവികമായും ആവശ്യമാണ്. ഉദാഹരണത്തിന്, ceph സ്റ്റോറേജ് മാനേജ്‌മെന്റ് ട്രാഫിക്കും ഡാറ്റാ ട്രാഫിക്കും തന്നെ (ഡിസ്കുകളിലേക്കുള്ള മെഷീൻ ആക്‌സസ് മുതലായവ) വ്യത്യസ്ത സബ്‌നെറ്റുകൾ (സ്റ്റോറേജ് മാനേജ്‌മെന്റ്, സ്‌റ്റോറേജ്) ഉപയോഗിക്കുന്നു, ഇത് ഈ ട്രാഫിക്കിനെ വിഭജിച്ച് പരിഹാരം കൂടുതൽ തെറ്റ്-സഹിഷ്ണുതയുള്ളതാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, ഉദാഹരണത്തിന്. , വ്യത്യസ്‌ത പോർട്ടുകളിൽ ഉടനീളം, അല്ലെങ്കിൽ വ്യത്യസ്‌ത ട്രാഫിക്കിനായി വ്യത്യസ്‌ത QoS പ്രൊഫൈലുകൾ ഉപയോഗിക്കുന്നതിലൂടെ ഡാറ്റാ ട്രാഫിക് സിഗ്നലിംഗ് ട്രാഫിക്കിനെ ചൂഷണം ചെയ്യില്ല. ഞങ്ങളുടെ കാര്യത്തിൽ, അവർ ഒരേ നെറ്റ്‌വർക്കിൽ പോകും, ​​വാസ്തവത്തിൽ ഇത് ഞങ്ങളെ ഒരു തരത്തിലും പരിമിതപ്പെടുത്തുന്നില്ല.

ശ്രദ്ധിക്കുക: വെർച്വൽ മെഷീനുകളെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു വെർച്വൽ എൻവയോൺമെന്റിൽ ഞങ്ങൾ വെർച്വൽ മെഷീനുകൾ പ്രവർത്തിപ്പിക്കാൻ പോകുന്നതിനാൽ, ഞങ്ങൾ ആദ്യം നെസ്റ്റഡ് വെർച്വലൈസേഷൻ പ്രവർത്തനക്ഷമമാക്കേണ്ടതുണ്ട്.

നെസ്റ്റഡ് വെർച്വലൈസേഷൻ പ്രവർത്തനക്ഷമമാണോ അല്ലയോ എന്ന് നിങ്ങൾക്ക് പരിശോധിക്കാം:

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

നിങ്ങൾ N അക്ഷരം കാണുകയാണെങ്കിൽ, നെറ്റ്‌വർക്കിൽ നിങ്ങൾ കണ്ടെത്തുന്ന ഏതെങ്കിലും ഗൈഡ് അനുസരിച്ച് നെസ്റ്റഡ് വെർച്വലൈസേഷനുള്ള പിന്തുണ ഞങ്ങൾ പ്രവർത്തനക്ഷമമാക്കുന്നു, ഉദാഹരണത്തിന് അത്തരമൊരു .

വെർച്വൽ മെഷീനുകളിൽ നിന്ന് ഞങ്ങൾ ഇനിപ്പറയുന്ന സർക്യൂട്ട് കൂട്ടിച്ചേർക്കേണ്ടതുണ്ട്:

എന്റെ കാര്യത്തിൽ, ഭാവിയിലെ ഇൻസ്റ്റാളേഷന്റെ ഭാഗമായ വെർച്വൽ മെഷീനുകൾ ബന്ധിപ്പിക്കുന്നതിന് (എനിക്ക് അവയിൽ 7 എണ്ണം ലഭിച്ചു, എന്നാൽ നിങ്ങൾക്ക് ധാരാളം വിഭവങ്ങൾ ഇല്ലെങ്കിൽ നിങ്ങൾക്ക് 4 ഉപയോഗിച്ച് നേടാം), ഞാൻ OpenvSwitch ഉപയോഗിച്ചു. ഞാൻ ഒരു ovs ബ്രിഡ്ജ് സൃഷ്‌ടിക്കുകയും പോർട്ട് ഗ്രൂപ്പുകൾ വഴി അതിലേക്ക് വെർച്വൽ മെഷീനുകൾ ബന്ധിപ്പിക്കുകയും ചെയ്തു. ഇത് ചെയ്യുന്നതിന്, ഞാൻ ഇതുപോലുള്ള ഒരു xml ഫയൽ സൃഷ്ടിച്ചു:

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

മൂന്ന് പോർട്ട് ഗ്രൂപ്പുകൾ ഇവിടെ പ്രഖ്യാപിച്ചു - രണ്ട് ആക്സസും ഒരു ട്രങ്കും (രണ്ടാമത്തേത് DNS സെർവറിന് ആവശ്യമായിരുന്നു, എന്നാൽ നിങ്ങൾക്ക് ഇത് കൂടാതെ തന്നെ ചെയ്യാം, അല്ലെങ്കിൽ ഹോസ്റ്റ് മെഷീനിൽ ഇൻസ്റ്റാൾ ചെയ്യാം - നിങ്ങൾക്ക് കൂടുതൽ സൗകര്യപ്രദമായത്). അടുത്തതായി, ഈ ടെംപ്ലേറ്റ് ഉപയോഗിച്ച്, virsh net-define വഴി ഞങ്ങളുടേത് പ്രഖ്യാപിക്കുന്നു:

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

ഇപ്പോൾ നമ്മൾ ഹൈപ്പർവൈസർ പോർട്ട് കോൺഫിഗറേഷനുകൾ എഡിറ്റ് ചെയ്യുന്നു:

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

ശ്രദ്ധിക്കുക: ഈ സാഹചര്യത്തിൽ, 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

അണ്ടർക്ലൗഡ് ഇൻസ്റ്റാളേഷൻ

ഞങ്ങൾ ഒരു സ്റ്റാക്ക് ഉപയോക്താവിനെ സൃഷ്‌ടിക്കുകയും ഒരു പാസ്‌വേഡ് സജ്ജമാക്കുകയും അത് sudoer-ലേക്ക് ചേർക്കുകയും പാസ്‌വേഡ് നൽകാതെ തന്നെ sudo വഴി റൂട്ട് കമാൻഡുകൾ എക്‌സിക്യൂട്ട് ചെയ്യാനുള്ള കഴിവ് നൽകുകയും ചെയ്യുന്നു:

useradd stack
passwd stack

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

ഇപ്പോൾ ഞങ്ങൾ ഹോസ്റ്റ് ഫയലിൽ പൂർണ്ണമായ അണ്ടർക്ലൗഡ് നാമം വ്യക്തമാക്കുന്നു:

vi /etc/hosts

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

അടുത്തതായി, ഞങ്ങൾ റിപ്പോസിറ്ററികൾ ചേർക്കുകയും ഞങ്ങൾക്ക് ആവശ്യമായ സോഫ്റ്റ്വെയർ ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യുന്നു:

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

ശ്രദ്ധിക്കുക: നിങ്ങൾ ceph ഇൻസ്റ്റാൾ ചെയ്യാൻ ഉദ്ദേശിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ ceph-മായി ബന്ധപ്പെട്ട കമാൻഡുകൾ നൽകേണ്ടതില്ല. ഞാൻ ക്വീൻസ് റിലീസ് ഉപയോഗിച്ചു, എന്നാൽ നിങ്ങൾക്ക് ഇഷ്ടമുള്ള മറ്റേതെങ്കിലും ഉപയോഗിക്കാം.

അടുത്തതായി, അണ്ടർക്ലൗഡ് കോൺഫിഗറേഷൻ ഫയൽ ഉപയോക്താവിന്റെ ഹോം ഡയറക്ടറി സ്റ്റാക്കിലേക്ക് പകർത്തുക:

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

ഇപ്പോൾ നമുക്ക് ഈ ഫയൽ ശരിയാക്കേണ്ടതുണ്ട്, ഇത് നമ്മുടെ ഇൻസ്റ്റാളേഷനിലേക്ക് ക്രമീകരിക്കുന്നു.

ഫയലിന്റെ തുടക്കത്തിൽ നിങ്ങൾ ഈ വരികൾ ചേർക്കേണ്ടതുണ്ട്:

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

അതിനാൽ, നമുക്ക് ക്രമീകരണങ്ങളിലൂടെ പോകാം:

undercloud_hostname — അണ്ടർക്ലൗഡ് സെർവറിന്റെ മുഴുവൻ പേര്, DNS സെർവറിലെ എൻട്രിയുമായി പൊരുത്തപ്പെടണം

local_ip - നെറ്റ്‌വർക്ക് പ്രൊവിഷനിംഗിനായുള്ള പ്രാദേശിക അണ്ടർക്ലൗഡ് വിലാസം

നെറ്റ്‌വർക്ക്_ഗേറ്റ്‌വേ - ഓവർക്ലൗഡ് നോഡുകളുടെ ഇൻസ്റ്റാളേഷൻ സമയത്ത് പുറം ലോകത്തിലേക്കുള്ള പ്രവേശനത്തിനുള്ള ഗേറ്റ്‌വേയായി പ്രവർത്തിക്കുന്ന അതേ പ്രാദേശിക വിലാസം പ്രാദേശിക ഐപിയുമായി യോജിക്കുന്നു.

undercloud_public_host - ബാഹ്യ API വിലാസം, പ്രൊവിഷനിംഗ് നെറ്റ്‌വർക്കിൽ നിന്നുള്ള ഏതെങ്കിലും സൗജന്യ വിലാസം അസൈൻ ചെയ്‌തിരിക്കുന്നു

undercloud_admin_host ആന്തരിക API വിലാസം, പ്രൊവിഷനിംഗ് നെറ്റ്‌വർക്കിൽ നിന്നുള്ള ഏത് സൗജന്യ വിലാസവും അസൈൻ ചെയ്‌തിരിക്കുന്നു

undercloud_nameservers - DNS സെർവർ

ജനറേറ്റ്_സർവീസ്_സർട്ടിഫിക്കറ്റ് - നിലവിലെ ഉദാഹരണത്തിൽ ഈ വരി വളരെ പ്രധാനമാണ്, കാരണം നിങ്ങൾ ഇത് തെറ്റായി സജ്ജമാക്കിയില്ലെങ്കിൽ, ഇൻസ്റ്റലേഷൻ സമയത്ത് നിങ്ങൾക്ക് ഒരു പിശക് ലഭിക്കും, പ്രശ്നം Red Hat ബഗ് ട്രാക്കറിൽ വിവരിച്ചിരിക്കുന്നു.

ലോക്കൽ_ഇന്റർഫേസ് നെറ്റ്‌വർക്ക് പ്രൊവിഷനിംഗിലെ ഇന്റർഫേസ്. അണ്ടർക്ലൗഡ് വിന്യാസ സമയത്ത് ഈ ഇന്റർഫേസ് പുനഃക്രമീകരിക്കപ്പെടും, അതിനാൽ നിങ്ങൾക്ക് അണ്ടർക്ലൗഡിൽ രണ്ട് ഇന്റർഫേസുകൾ ഉണ്ടായിരിക്കണം - ഒന്ന് അത് ആക്‌സസ് ചെയ്യുന്നതിന്, രണ്ടാമത്തേത് പ്രൊവിഷനിംഗിന്

പ്രാദേശിക_mtu - എം.ടി.യു. ഞങ്ങൾക്ക് ഒരു ടെസ്റ്റ് ലബോറട്ടറി ഉള്ളതിനാലും എനിക്ക് OVS സ്വിച്ച് പോർട്ടുകളിൽ 1500 MTU ഉള്ളതിനാലും, VxLAN-ൽ പൊതിഞ്ഞ പാക്കറ്റുകൾ കടന്നുപോകാൻ അത് 1450 ആയി സജ്ജീകരിക്കേണ്ടത് ആവശ്യമാണ്.

നെറ്റ്വർക്ക്_സിഡ്ർ - പ്രൊവിഷനിംഗ് നെറ്റ്‌വർക്ക്

മാസ്‌ക്വറേഡ് - ഒരു ബാഹ്യ നെറ്റ്‌വർക്ക് ആക്‌സസ് ചെയ്യാൻ NAT ഉപയോഗിക്കുന്നു

മാസ്ക്വെറേഡ്_നെറ്റ്‌വർക്ക് - നെറ്റ്‌വർക്ക്, അത് നാറ്റഡ് ആയിരിക്കും

dhcp_start - ഓവർക്ലൗഡ് വിന്യാസ സമയത്ത് നോഡുകളിലേക്ക് വിലാസങ്ങൾ നൽകപ്പെടുന്ന വിലാസ പൂളിന്റെ ആരംഭ വിലാസം

dhcp_end - ഓവർക്ലൗഡ് വിന്യാസ സമയത്ത് നോഡുകളിലേക്ക് വിലാസങ്ങൾ നൽകപ്പെടുന്ന വിലാസ പൂളിന്റെ അവസാന വിലാസം

ഇൻസ്പെക്ഷൻ_പ്രാഞ്ച് - ആത്മപരിശോധനയ്ക്ക് ആവശ്യമായ വിലാസങ്ങളുടെ ഒരു കൂട്ടം (മുകളിലുള്ള പൂളുമായി ഓവർലാപ്പ് ചെയ്യാൻ പാടില്ല)

ഷെഡ്യൂളർ_max_attempts - ഓവർക്ലൗഡ് ഇൻസ്റ്റാൾ ചെയ്യാനുള്ള പരമാവധി ശ്രമങ്ങൾ (നോഡുകളുടെ എണ്ണത്തേക്കാൾ വലുതോ തുല്യമോ ആയിരിക്കണം)

ഫയൽ വിവരിച്ച ശേഷം, നിങ്ങൾക്ക് undercloud വിന്യസിക്കാനുള്ള കമാൻഡ് നൽകാം:

openstack undercloud install

നിങ്ങളുടെ ഇരുമ്പിനെ ആശ്രയിച്ച് നടപടിക്രമം 10 മുതൽ 30 മിനിറ്റ് വരെ എടുക്കും. ആത്യന്തികമായി നിങ്ങൾ ഇതുപോലുള്ള ഔട്ട്പുട്ട് കാണണം:

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

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

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

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

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

നിങ്ങൾ അണ്ടർക്ലൗഡ് വിജയകരമായി ഇൻസ്റ്റാൾ ചെയ്തുവെന്നും ഇപ്പോൾ നിങ്ങൾക്ക് അണ്ടർക്ലൗഡിന്റെ നില പരിശോധിച്ച് ഓവർക്ലൗഡ് ഇൻസ്റ്റാൾ ചെയ്യാൻ തുടരാമെന്നും ഈ ഔട്ട്‌പുട്ട് പറയുന്നു.

ifconfig ഔട്ട്പുട്ട് നോക്കിയാൽ, ഒരു പുതിയ ബ്രിഡ്ജ് ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെട്ടതായി നിങ്ങൾ കാണും

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

ഈ ഇന്റർഫേസിലൂടെ ഓവർക്ലൗഡ് വിന്യാസം ഇപ്പോൾ നടപ്പിലാക്കും.

താഴെയുള്ള ഔട്ട്‌പുട്ടിൽ നിന്ന് ഞങ്ങൾക്ക് എല്ലാ സേവനങ്ങളും ഒരു നോഡിൽ ഉണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും:

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

അണ്ടർക്ലൗഡ് നെറ്റ്‌വർക്ക് ഭാഗത്തിന്റെ കോൺഫിഗറേഷൻ ചുവടെ:

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

ഓവർക്ലൗഡ് ഇൻസ്റ്റാളേഷൻ

ഇപ്പോൾ ഞങ്ങൾക്ക് അണ്ടർക്ലൗഡ് മാത്രമേ ഉള്ളൂ, ഓവർക്ലൗഡ് കൂട്ടിച്ചേർക്കപ്പെടുന്ന മതിയായ നോഡുകൾ ഞങ്ങളുടെ പക്കലില്ല. അതിനാൽ, ഒന്നാമതായി, നമുക്ക് ആവശ്യമുള്ള വെർച്വൽ മെഷീനുകൾ വിന്യസിക്കാം. വിന്യാസ സമയത്ത്, അണ്ടർക്ലൗഡ് തന്നെ ഓവർക്ലൗഡ് മെഷീനിൽ ഒഎസും ആവശ്യമായ സോഫ്റ്റ്വെയറും ഇൻസ്റ്റാൾ ചെയ്യും - അതായത്, ഞങ്ങൾ മെഷീൻ പൂർണ്ണമായും വിന്യസിക്കേണ്ടതില്ല, പക്ഷേ അതിനായി ഒരു ഡിസ്ക് (അല്ലെങ്കിൽ ഡിസ്കുകൾ) സൃഷ്ടിച്ച് അതിന്റെ പാരാമീറ്ററുകൾ നിർണ്ണയിക്കുക - അതായത് , വാസ്തവത്തിൽ, ഒരു OS ഇൻസ്റ്റാൾ ചെയ്യാത്ത ഒരു വെറും സെർവർ നമുക്ക് ലഭിക്കും .

നമുക്ക് നമ്മുടെ വെർച്വൽ മെഷീനുകളുടെ ഡിസ്കുകളുള്ള ഫോൾഡറിലേക്ക് പോയി ആവശ്യമായ വലുപ്പത്തിലുള്ള ഡിസ്കുകൾ സൃഷ്ടിക്കാം:

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

ഞങ്ങൾ റൂട്ട് ആയി പ്രവർത്തിക്കുന്നതിനാൽ, അവകാശങ്ങളിൽ ഒരു പ്രശ്നം ഉണ്ടാകാതിരിക്കാൻ ഈ ഡിസ്കുകളുടെ ഉടമയെ മാറ്റേണ്ടതുണ്ട്:

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

ശ്രദ്ധിക്കുക: നിങ്ങൾ അത് പഠിക്കുന്നതിനായി ceph ഇൻസ്റ്റാൾ ചെയ്യാൻ ഉദ്ദേശിക്കുന്നില്ലെങ്കിൽ, കമാൻഡുകൾ കുറഞ്ഞത് രണ്ട് ഡിസ്കുകളുള്ള 3 നോഡുകളെങ്കിലും സൃഷ്ടിക്കുന്നില്ല, പക്ഷേ ടെംപ്ലേറ്റിൽ വെർച്വൽ ഡിസ്കുകൾ vda, vdb മുതലായവ ഉപയോഗിക്കുമെന്ന് സൂചിപ്പിക്കുന്നു.

കൊള്ളാം, ഇപ്പോൾ നമുക്ക് ഈ മെഷീനുകളെല്ലാം നിർവചിക്കേണ്ടതുണ്ട്:

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

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

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

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

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

അവസാനം ഒരു കമാൻഡ് ഉണ്ട് -print-xml > /tmp/storage-1.xml, അത് /tmp/ ഫോൾഡറിലെ ഓരോ മെഷീന്റെയും വിവരണത്തോടുകൂടിയ ഒരു xml ഫയൽ സൃഷ്ടിക്കുന്നു; നിങ്ങൾ അത് ചേർത്തില്ലെങ്കിൽ, നിങ്ങൾ ആകില്ല വെർച്വൽ മെഷീനുകൾ തിരിച്ചറിയാൻ കഴിയും.

ഇപ്പോൾ നമുക്ക് ഈ മെഷീനുകളെല്ലാം വിർഷിൽ നിർവചിക്കേണ്ടതുണ്ട്:

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

എല്ലാം ശരിയാണെങ്കിൽ, ഓവർക്ലൗഡ് വിന്യസിക്കാൻ ഞങ്ങൾ കമാൻഡ് നൽകുന്നു:

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 വെർച്വൽ മെഷീനുകൾ സൃഷ്ടിച്ചു - 3 ഒരു L2 നെറ്റ്‌വർക്കിൽ - net-1, കൂടാതെ 1 നെറ്റ്-2 നെറ്റ്‌വർക്കിൽ വേറെയും

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

സൃഷ്ടിച്ച മെഷീനുകൾ ഏത് ഹൈപ്പർവൈസറുകളിലാണെന്ന് നോക്കാം:

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

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

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

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

(ഓവർക്ലൗഡ്) [stack@undercloud ~]$
മെഷീനുകൾ vm-1, vm-3 എന്നിവ കമ്പ്യൂട്ട്-0-ലും vm-2, vm-4 മെഷീനുകൾ നോഡ് കമ്പ്യൂട്ട്-1-ലും സ്ഥിതിചെയ്യുന്നു.

കൂടാതെ, നിർദ്ദിഷ്ട നെറ്റ്‌വർക്കുകൾക്കിടയിൽ റൂട്ടിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നതിന് ഒരു വെർച്വൽ റൂട്ടർ സൃഷ്ടിച്ചു:

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

റൂട്ടറിന് രണ്ട് വെർച്വൽ പോർട്ടുകളുണ്ട്, അവ നെറ്റ്‌വർക്കുകളുടെ ഗേറ്റ്‌വേകളായി പ്രവർത്തിക്കുന്നു:

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

എന്നാൽ ട്രാഫിക് എങ്ങനെ ഒഴുകുന്നു എന്ന് നോക്കുന്നതിന് മുമ്പ്, നമുക്ക് ഇപ്പോൾ കൺട്രോൾ നോഡിലും (ഇത് ഒരു നെറ്റ്‌വർക്ക് നോഡും) കമ്പ്യൂട്ട് നോഡിലും എന്താണ് ഉള്ളതെന്ന് നോക്കാം. നമുക്ക് കമ്പ്യൂട്ട് നോഡിൽ നിന്ന് ആരംഭിക്കാം.

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

ഇപ്പോൾ, നോഡിന് മൂന്ന് 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 ~]$ 

ആദ്യ നിയമം അനുസരിച്ച്, phy-br-ex പോർട്ടിൽ നിന്ന് വന്നതെല്ലാം ഉപേക്ഷിക്കണം.
യഥാർത്ഥത്തിൽ, ഈ ഇന്റർഫേസിൽ നിന്ന് (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 ~]$

വാസ്തവത്തിൽ, എല്ലാം ഒന്നുതന്നെയാണെന്ന് നമുക്ക് പറയാം, എന്നാൽ IP വിലാസം ഫിസിക്കൽ ഇന്റർഫേസിൽ അല്ല, വെർച്വൽ ബ്രിഡ്ജിലാണ്. ഈ തുറമുഖം വഴി ഗതാഗതം പുറംലോകത്തേക്ക് പുറപ്പെടുന്ന തുറമുഖമായതിനാലാണ് ഇത് ചെയ്യുന്നത്.

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

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

ഈ പോർട്ട് br-ex ബ്രിഡ്ജുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, അതിൽ vlan ടാഗുകളൊന്നുമില്ലാത്തതിനാൽ, ഈ പോർട്ട് എല്ലാ vlanകൾക്കും അനുവദനീയമായ ഒരു ട്രങ്ക് പോർട്ടാണ്, ഇപ്പോൾ ട്രാഫിക് ഒരു ടാഗില്ലാതെ പുറത്തേക്ക് പോകുന്നു, ഇത് vlan-id 0 സൂചിപ്പിച്ചിരിക്കുന്നു. മുകളിൽ ഔട്ട്പുട്ട്.

മറ്റെല്ലാം ഇപ്പോൾ കമ്പ്യൂട്ട് നോഡിന് സമാനമാണ് - ഒരേ പാലങ്ങൾ, ഒരേ തുരങ്കങ്ങൾ രണ്ട് കമ്പ്യൂട്ട് നോഡുകളിലേക്ക് പോകുന്നു.

ഈ ലേഖനത്തിൽ ഞങ്ങൾ സ്റ്റോറേജ് നോഡുകൾ പരിഗണിക്കില്ല, എന്നാൽ മനസ്സിലാക്കുന്നതിന് ഈ നോഡുകളുടെ നെറ്റ്‌വർക്ക് ഭാഗം അപമാനകരമായി നിസ്സാരമാണെന്ന് പറയേണ്ടതുണ്ട്. ഞങ്ങളുടെ കാര്യത്തിൽ, ഒരു IP വിലാസം നൽകിയിട്ടുള്ള ഒരു ഫിസിക്കൽ പോർട്ട് (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 - Linux ബ്രിഡ്ജ്
qvb, qvo - vEth ജോഡി ലിനക്സ് ബ്രിഡ്ജിലേക്കും ഓപ്പൺ vSwitch ബ്രിഡ്ജിലേക്കും ബന്ധിപ്പിച്ചിരിക്കുന്നു
br-int, br-tun, br-vlan — vSwitch ബ്രിഡ്ജുകൾ തുറക്കുക
pach-, int-br-, phy-br- - ബ്രിഡ്ജുകളെ ബന്ധിപ്പിക്കുന്ന vSwitch പാച്ച് ഇന്റർഫേസുകൾ തുറക്കുക
qg, qr, ha, fg, sg - OVS-ലേക്ക് കണക്റ്റുചെയ്യാൻ വെർച്വൽ ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്ന vSwitch പോർട്ടുകൾ തുറക്കുക

നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, ഞങ്ങൾക്ക് ബ്രിഡ്ജിൽ ഒരു qvb95d96a75-a0 പോർട്ട് ഉണ്ടെങ്കിൽ, അത് ഒരു vEth ജോഡിയാണ്, എവിടെയോ അതിന്റെ കൗണ്ടർപാർട്ട് ഉണ്ട്, അതിനെ യുക്തിപരമായി qvo95d96a75-a0 എന്ന് വിളിക്കണം. ഒവിഎസിൽ ഏതൊക്കെ പോർട്ടുകളാണ് ഉള്ളതെന്ന് നോക്കാം.

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

നമുക്ക് കാണാനാകുന്നതുപോലെ, പോർട്ട് br-int ൽ ആണ്. വെർച്വൽ മെഷീൻ പോർട്ടുകൾ അവസാനിപ്പിക്കുന്ന ഒരു സ്വിച്ച് ആയി Br-int പ്രവർത്തിക്കുന്നു. qvo95d96a75-a0 കൂടാതെ, പോർട്ട് qvo5bd37136-47 ഔട്ട്‌പുട്ടിൽ ദൃശ്യമാണ്. ഇതാണ് രണ്ടാമത്തെ വെർച്വൽ മെഷീനിലേക്കുള്ള പോർട്ട്. തൽഫലമായി, ഞങ്ങളുടെ ഡയഗ്രം ഇപ്പോൾ ഇതുപോലെ കാണപ്പെടുന്നു:

ശ്രദ്ധിക്കുന്ന വായനക്കാരന് ഉടനടി താൽപ്പര്യമുള്ള ഒരു ചോദ്യം - വെർച്വൽ മെഷീൻ പോർട്ടിനും OVS പോർട്ടിനും ഇടയിലുള്ള ലിനക്സ് ബ്രിഡ്ജ് എന്താണ്? മെഷീൻ പരിരക്ഷിക്കുന്നതിന്, സുരക്ഷാ ഗ്രൂപ്പുകൾ ഉപയോഗിക്കുന്നു എന്നതാണ് വസ്തുത, അത് iptables അല്ലാതെ മറ്റൊന്നുമല്ല. OVS iptables ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നില്ല, അതിനാൽ ഈ "ക്രച്ച്" കണ്ടുപിടിച്ചു. എന്നിരുന്നാലും, ഇത് കാലഹരണപ്പെട്ടുകൊണ്ടിരിക്കുന്നു - പുതിയ റിലീസുകളിൽ ഇത് കോൺട്രാക്ക് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു.

അതായത്, ആത്യന്തികമായി സ്കീം ഇതുപോലെ കാണപ്പെടുന്നു:

ഒരു L2 നെറ്റ്‌വർക്കിൽ ഒരു ഹൈപ്പർവൈസറിൽ രണ്ട് മെഷീനുകൾ

ഈ രണ്ട് VM-കളും ഒരേ L2 നെറ്റ്‌വർക്കിലും ഒരേ ഹൈപ്പർവൈസറിലുമായതിനാൽ, അവയ്‌ക്കിടയിലുള്ള ട്രാഫിക് യുക്തിപരമായി br-int വഴി പ്രാദേശികമായി ഒഴുകും, കാരണം രണ്ട് മെഷീനുകളും ഒരേ VLAN-ൽ ആയിരിക്കും:

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

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

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

ഒരേ L2 നെറ്റ്‌വർക്കിൽ വ്യത്യസ്ത ഹൈപ്പർവൈസറുകളിൽ രണ്ട് മെഷീനുകൾ

ഒരേ L2 നെറ്റ്‌വർക്കിലെ രണ്ട് മെഷീനുകൾക്കിടയിൽ ട്രാഫിക് എങ്ങനെ പോകുമെന്ന് ഇപ്പോൾ നോക്കാം, എന്നാൽ വ്യത്യസ്ത ഹൈപ്പർവൈസറുകളിൽ സ്ഥിതിചെയ്യുന്നു. സത്യം പറഞ്ഞാൽ, ഒന്നും വലിയ മാറ്റമൊന്നും വരുത്തില്ല, ഹൈപ്പർവൈസറുകൾ തമ്മിലുള്ള ഗതാഗതം vxlan ടണലിലൂടെ പോകും. ഒരു ഉദാഹരണം നോക്കാം.

ഞങ്ങൾ ട്രാഫിക് നിരീക്ഷിക്കുന്ന വെർച്വൽ മെഷീനുകളുടെ വിലാസങ്ങൾ:

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

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

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

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

കമ്പ്യൂട്ട്-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-ലെ പാക്കേജിന് എന്ത് സംഭവിക്കുമെന്ന് നമുക്ക് നോക്കാം:

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

പാക്കറ്റ് VxLAN-ൽ പാക്കേജുചെയ്‌ത് പോർട്ട് 2-ലേക്ക് അയച്ചു. പോർട്ട് 2 എവിടേക്കാണ് നയിക്കുന്നതെന്ന് നമുക്ക് നോക്കാം:

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

ഇത് കമ്പ്യൂട്ട്-1-ലെ ഒരു vxlan ടണലാണ്:

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

നമുക്ക് കമ്പ്യൂട്ട്-1-ലേക്ക് പോയി പാക്കേജിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കാം:

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

കമ്പ്യൂട്ട്-1-ലെ br-int ഫോർവേഡിംഗ് ടേബിളിലാണ് Mac, മുകളിലുള്ള ഔട്ട്‌പുട്ടിൽ നിന്ന് കാണാൻ കഴിയുന്നത് പോലെ, പോർട്ട് 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 ഉണ്ട്.

വെർച്വൽ ഇൻഫ്രാസ്ട്രക്ചറിനെ കുറിച്ച് പഠിക്കാൻ ഓപ്പൺസ്റ്റാക്ക് വിന്യസിക്കുന്നതിന്റെ ഭംഗി, ഹൈപ്പർവൈസറുകൾക്കിടയിൽ ട്രാഫിക്ക് എളുപ്പത്തിൽ പിടിച്ചെടുക്കാനും അതിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാനും കഴിയും എന്നതാണ്. ഇതാണ് ഞങ്ങൾ ഇപ്പോൾ ചെയ്യുന്നത്, കമ്പ്യൂട്ട്-0 ലേക്ക് vnet പോർട്ടിൽ tcpdump പ്രവർത്തിപ്പിക്കുക:

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

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

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

വിലാസം 10.0.1.85-ൽ നിന്നുള്ള Patek 10.0.1.88 (ICMP ട്രാഫിക്) എന്ന വിലാസത്തിലേക്ക് പോകുന്നുവെന്ന് ആദ്യ വരി കാണിക്കുന്നു, അത് vni 22 ഉള്ള ഒരു VxLAN പാക്കറ്റിൽ പൊതിഞ്ഞ്, പാക്കറ്റ് ഹോസ്റ്റ് 192.168.255.19 (കമ്പ്യൂട്ട്-0) ൽ നിന്ന് ഹോസ്റ്റ് 192.168.255.26-ലേക്ക് പോകുന്നു. .1 (കമ്പ്യൂട്ട്-XNUMX). VNI ovs-ൽ പറഞ്ഞിരിക്കുന്നതുമായി പൊരുത്തപ്പെടുന്നുണ്ടോയെന്ന് നമുക്ക് പരിശോധിക്കാം.

നമുക്ക് ഈ ലൈൻ പ്രവർത്തനങ്ങളിലേക്ക് മടങ്ങാം=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ഔട്ട്‌പുട്ട്:2. ഹെക്സാഡെസിമൽ നമ്പർ സിസ്റ്റത്തിൽ 0x16 vni ആണ്. നമുക്ക് ഈ നമ്പർ പത്താം സിസ്റ്റത്തിലേക്ക് പരിവർത്തനം ചെയ്യാം:

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

അതായത്, vni യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെടുന്നു.

രണ്ടാമത്തെ വരി റിട്ടേൺ ട്രാഫിക് കാണിക്കുന്നു, ശരി, അത് വിശദീകരിക്കുന്നതിൽ അർത്ഥമില്ല, എല്ലാം അവിടെ വ്യക്തമാണ്.

വ്യത്യസ്ത നെറ്റ്‌വർക്കുകളിൽ രണ്ട് മെഷീനുകൾ (ഇന്റർ-നെറ്റ്‌വർക്ക് റൂട്ടിംഗ്)

ഇന്നത്തെ അവസാന കേസ് ഒരു വെർച്വൽ റൂട്ടർ ഉപയോഗിച്ച് ഒരു പ്രോജക്റ്റിനുള്ളിലെ നെറ്റ്‌വർക്കുകൾക്കിടയിൽ റൂട്ടിംഗ് ആണ്. DVR ഇല്ലാത്ത ഒരു കേസ് ഞങ്ങൾ പരിഗണിക്കുന്നു (ഞങ്ങൾ അത് മറ്റൊരു ലേഖനത്തിൽ നോക്കും), അതിനാൽ റൂട്ടിംഗ് നെറ്റ്‌വർക്ക് നോഡിൽ സംഭവിക്കുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, നെറ്റ്‌വർക്ക് നോഡ് ഒരു പ്രത്യേക എന്റിറ്റിയിൽ സ്ഥാപിച്ചിട്ടില്ല, അത് നിയന്ത്രണ നോഡിൽ സ്ഥിതിചെയ്യുന്നു.

ആദ്യം, റൂട്ടിംഗ് പ്രവർത്തിക്കുന്നുവെന്ന് നോക്കാം:

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

ഈ സാഹചര്യത്തിൽ, പാക്കറ്റ് ഗേറ്റ്‌വേയിലേക്ക് പോകുകയും അങ്ങോട്ടേക്ക് നയിക്കുകയും ചെയ്യേണ്ടതിനാൽ, ഗേറ്റ്‌വേയുടെ പോപ്പി വിലാസം ഞങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട്, അതിനായി ഞങ്ങൾ ഉദാഹരണത്തിൽ 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-ലേക്ക് പോകുന്നു. ഏത് vxlan ടണലിലാണ് ഇത് പൊതിഞ്ഞിരിക്കുന്നതെന്ന് നോക്കാം:

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

മൂന്നാമത്തെ തുറമുഖം ഒരു vxlan ടണലാണ്:

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

ഏത് നിയന്ത്രണ നോഡിലേക്ക് നോക്കുന്നു:

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

ട്രാഫിക് കൺട്രോൾ നോഡിലെത്തി, അതിനാൽ ഞങ്ങൾ അതിലേക്ക് പോയി റൂട്ടിംഗ് എങ്ങനെ സംഭവിക്കുമെന്ന് കാണേണ്ടതുണ്ട്.

നിങ്ങൾ ഓർക്കുന്നതുപോലെ, ഉള്ളിലെ കൺട്രോൾ നോഡ് കമ്പ്യൂട്ട് നോഡിന് സമാനമായി കാണപ്പെട്ടു - അതേ മൂന്ന് പാലങ്ങളിൽ, ബ്ര-എക്‌സിന് മാത്രമേ ഒരു ഫിസിക്കൽ പോർട്ട് ഉണ്ടായിരുന്നുള്ളൂ, അതിലൂടെ നോഡിന് പുറത്തേക്ക് ട്രാഫിക് അയയ്‌ക്കാൻ കഴിയും. ഉദാഹരണങ്ങൾ സൃഷ്ടിക്കുന്നത് കമ്പ്യൂട്ട് നോഡുകളിലെ കോൺഫിഗറേഷൻ മാറ്റി - ലിനക്സ് ബ്രിഡ്ജ്, iptables, ഇന്റർഫേസുകൾ എന്നിവ നോഡുകളിലേക്ക് ചേർത്തു. നെറ്റ്‌വർക്കുകളുടെയും ഒരു വെർച്വൽ റൂട്ടറിന്റെയും സൃഷ്‌ടി നിയന്ത്രണ നോഡിന്റെ കോൺഫിഗറേഷനിൽ അതിന്റെ അടയാളം അവശേഷിപ്പിച്ചു.

അതിനാൽ, ഗേറ്റ്‌വേ MAC വിലാസം കൺട്രോൾ നോഡിലെ br-int ഫോർവേഡിംഗ് ടേബിളിലായിരിക്കണം എന്നത് വ്യക്തമാണ്. അത് അവിടെയുണ്ടെന്നും അത് എവിടെയാണ് നോക്കുന്നതെന്നും പരിശോധിക്കാം:

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

qr-0c52b15f-8f പോർട്ടിൽ നിന്ന് 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 ലേക്ക് ഗതാഗതം ടണലിലേക്ക് പോകുന്നു. ശരി, കമ്പ്യൂട്ട്-1-ൽ എല്ലാം ലളിതമാണ് - br-tun-ൽ നിന്ന് പാക്കേജ് br-int ലേക്ക് പോകുന്നു, അവിടെ നിന്ന് വെർച്വൽ മെഷീൻ ഇന്റർഫേസിലേക്ക്:

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

ഇത് തീർച്ചയായും ശരിയായ ഇന്റർഫേസ് ആണെന്ന് പരിശോധിക്കാം:

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

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

യഥാർത്ഥത്തിൽ, ഞങ്ങൾ പാക്കേജിലൂടെ കടന്നുപോയി. ട്രാഫിക് വ്യത്യസ്‌ത vxlan ടണലുകളിലൂടെ കടന്നുപോകുകയും വ്യത്യസ്‌ത VNI-കൾ ഉപയോഗിച്ച് പുറത്തുകടക്കുകയും ചെയ്‌തത് നിങ്ങൾ ശ്രദ്ധിച്ചിട്ടുണ്ടെന്ന് ഞാൻ കരുതുന്നു. ഇവ ഏത് തരത്തിലുള്ള വിഎൻഐ ആണെന്ന് നോക്കാം, അതിനുശേഷം ഞങ്ങൾ നോഡിന്റെ കൺട്രോൾ പോർട്ടിൽ ഒരു ഡംപ് ശേഖരിക്കുകയും മുകളിൽ വിവരിച്ചതുപോലെ ട്രാഫിക്ക് ഒഴുകുന്നുവെന്ന് ഉറപ്പാക്കുകയും ചെയ്യും.
അതിനാൽ, കമ്പ്യൂട്ട്-0-ലേക്കുള്ള ടണലിന് ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ ഉണ്ട്=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ഔട്ട്‌പുട്ട്:3. നമുക്ക് 0x16 ദശാംശ സംഖ്യ സിസ്റ്റത്തിലേക്ക് പരിവർത്തനം ചെയ്യാം:

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

കമ്പ്യൂട്ട്-1-ലേക്കുള്ള തുരങ്കത്തിന് ഇനിപ്പറയുന്ന VNI ഉണ്ട്: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. നമുക്ക് 0x63 ദശാംശ സംഖ്യ സിസ്റ്റത്തിലേക്ക് പരിവർത്തനം ചെയ്യാം:

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

ശരി, ഇപ്പോൾ നമുക്ക് ഡംപ് നോക്കാം:

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

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

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

ആദ്യത്തെ പാക്കറ്റ്, ഹോസ്റ്റ് 192.168.255.19 (കമ്പ്യൂട്ട്-0) മുതൽ 192.168.255.15 (കൺട്രോൾ-1) വരെയുള്ള vni 22-നുള്ള ഒരു vxlan പാക്കറ്റാണ്, അതിനുള്ളിൽ ഒരു ICMP പാക്കറ്റ് ഹോസ്റ്റ് 10.0.1.85-ൽ നിന്ന് ഹോസ്റ്റ് 10.0.2.8-ലേക്ക് പാക്കേജുചെയ്തിരിക്കുന്നു. ഞങ്ങൾ മുകളിൽ കണക്കാക്കിയതുപോലെ, ഔട്ട്പുട്ടിൽ നമ്മൾ കണ്ടതുമായി vni പൊരുത്തപ്പെടുന്നു.

രണ്ടാമത്തെ പാക്കറ്റ്, ഹോസ്റ്റ് 192.168.255.15 (നിയന്ത്രണം-1) മുതൽ 192.168.255.26 (കമ്പ്യൂട്ട്-1) വരെയുള്ള vni 99-നുള്ള ഒരു vxlan പാക്കറ്റാണ്, അതിനുള്ളിൽ ഒരു ICMP പാക്കറ്റ് ഹോസ്റ്റ് 10.0.1.85-ൽ നിന്ന് 10.0.2.8 ഹോസ്റ്റ് XNUMX-ലേക്ക് പാക്കേജുചെയ്തിരിക്കുന്നു. ഞങ്ങൾ മുകളിൽ കണക്കാക്കിയതുപോലെ, ഔട്ട്പുട്ടിൽ നമ്മൾ കണ്ടതുമായി vni പൊരുത്തപ്പെടുന്നു.

അടുത്ത രണ്ട് പാക്കറ്റുകൾ 10.0.2.8 അല്ല 10.0.1.85 ൽ നിന്നുള്ള റിട്ടേൺ ട്രാഫിക് ആണ്.

അതായത്, അവസാനം ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന നിയന്ത്രണ നോഡ് സ്കീം ലഭിച്ചു:

അത് പോലെയാണോ? രണ്ട് നെയിംസ്‌പെയ്‌സിനെ കുറിച്ച് ഞങ്ങൾ മറന്നു:

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

ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ ആർക്കിടെക്ചറിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചതുപോലെ, ഒരു ഡിഎച്ച്സിപി സെർവറിൽ നിന്ന് മെഷീനുകൾക്ക് വിലാസങ്ങൾ സ്വയമേവ ലഭിച്ചാൽ അത് നന്നായിരിക്കും. ഞങ്ങളുടെ രണ്ട് നെറ്റ്‌വർക്കുകൾക്കുള്ള 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 പ്ലഗ് ഇൻ ചെയ്യില്ല. എന്നാൽ അത് തികച്ചും വ്യത്യസ്തമായ ഒരു കഥയാണ്.

അത് രസകരമായിരുന്നുവെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. നിങ്ങൾക്ക് എന്തെങ്കിലും അഭിപ്രായങ്ങൾ / കൂട്ടിച്ചേർക്കലുകൾ ഉണ്ടെങ്കിൽ, അല്ലെങ്കിൽ എവിടെയെങ്കിലും ഞാൻ കള്ളം പറഞ്ഞിട്ടുണ്ടെങ്കിൽ (ഞാൻ മനുഷ്യനാണ്, എന്റെ അഭിപ്രായം എല്ലായ്പ്പോഴും ആത്മനിഷ്ഠമായിരിക്കും) - തിരുത്തേണ്ടവ/ചേർക്കേണ്ടവ എഴുതുക - ഞങ്ങൾ എല്ലാം ശരിയാക്കും/ചേർത്തും.

ഉപസംഹാരമായി, വിഎംവെയറിൽ നിന്നുള്ള ക്ലൗഡ് സൊല്യൂഷനുമായി ഓപ്പൺസ്റ്റാക്ക് (വാനിലയും വെണ്ടറും) താരതമ്യപ്പെടുത്തുന്നതിനെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു - കഴിഞ്ഞ രണ്ട് വർഷമായി എന്നോട് ഈ ചോദ്യം പലപ്പോഴും ചോദിച്ചിട്ടുണ്ട്, വ്യക്തമായി പറഞ്ഞാൽ, ഞാൻ ഇതിനകം മടുത്തു, പക്ഷേ ഇപ്പോഴും. എന്റെ അഭിപ്രായത്തിൽ, ഈ രണ്ട് പരിഹാരങ്ങളും താരതമ്യം ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, എന്നാൽ രണ്ട് പരിഹാരങ്ങളിലും ദോഷങ്ങളുണ്ടെന്ന് ഞങ്ങൾക്ക് തീർച്ചയായും പറയാൻ കഴിയും, ഒരു പരിഹാരം തിരഞ്ഞെടുക്കുമ്പോൾ നിങ്ങൾ ഗുണദോഷങ്ങൾ തീർക്കേണ്ടതുണ്ട്.

OpenStack ഒരു കമ്മ്യൂണിറ്റി-പ്രേരിതമായ പരിഹാരമാണെങ്കിൽ, VMWare-ന് അവർക്ക് ആവശ്യമുള്ളത് മാത്രം ചെയ്യാൻ അവകാശമുണ്ട് (വായിക്കുക - അതിന് ലാഭകരമായത്) ഇത് യുക്തിസഹമാണ് - കാരണം ഇത് അതിന്റെ ക്ലയന്റുകളിൽ നിന്ന് പണം സമ്പാദിക്കാൻ ഉപയോഗിക്കുന്ന ഒരു വാണിജ്യ കമ്പനിയാണ്. എന്നാൽ വലുതും തടിച്ചതുമായ ഒന്നുണ്ട് പക്ഷേ - നിങ്ങൾക്ക് OpenStack-ൽ നിന്ന് ഇറങ്ങാം, ഉദാഹരണത്തിന് നോക്കിയയിൽ നിന്ന്, ചെറിയ ചിലവിൽ നിന്ന്, ഉദാഹരണത്തിന്, Juniper (Contrail Cloud) എന്നതിൽ നിന്ന് ഒരു പരിഹാരത്തിലേക്ക് മാറാം, എന്നാൽ നിങ്ങൾക്ക് VMWare-ൽ നിന്ന് ഇറങ്ങാൻ സാധ്യതയില്ല. . എന്നെ സംബന്ധിച്ചിടത്തോളം, ഈ രണ്ട് പരിഹാരങ്ങളും ഇതുപോലെ കാണപ്പെടുന്നു - ഓപ്പൺസ്റ്റാക്ക് (വെണ്ടർ) നിങ്ങളെ ഇട്ടിരിക്കുന്ന ഒരു ലളിതമായ കൂട്ടാണ്, എന്നാൽ നിങ്ങൾക്ക് ഒരു താക്കോൽ ഉണ്ട്, നിങ്ങൾക്ക് എപ്പോൾ വേണമെങ്കിലും പോകാം. VMWare ഒരു സ്വർണ്ണ കൂട്ടാണ്, ഉടമയുടെ കൈവശം കൂടിന്റെ താക്കോൽ ഉണ്ട്, ഇതിന് നിങ്ങൾക്ക് ധാരാളം ചിലവ് വരും.

ആദ്യ ഉൽപ്പന്നമോ രണ്ടാമത്തേതോ ഞാൻ പ്രമോട്ട് ചെയ്യുന്നില്ല - നിങ്ങൾക്ക് ആവശ്യമുള്ളത് നിങ്ങൾ തിരഞ്ഞെടുക്കുക. എന്നാൽ എനിക്ക് അത്തരമൊരു ചോയ്‌സ് ഉണ്ടെങ്കിൽ, ഞാൻ രണ്ട് സൊല്യൂഷനുകളും തിരഞ്ഞെടുക്കും - ഐടി ക്ലൗഡിനായുള്ള VMWare (കുറഞ്ഞ ലോഡുകൾ, എളുപ്പമുള്ള മാനേജ്‌മെന്റ്), ചില വെണ്ടർമാരിൽ നിന്നുള്ള OpenStack (Nokia, Juniper എന്നിവ വളരെ മികച്ച ടേൺകീ സൊല്യൂഷനുകൾ നൽകുന്നു) - ടെലികോം ക്ലൗഡിനായി. ശുദ്ധമായ ഐടിക്കായി ഞാൻ ഓപ്പൺസ്റ്റാക്ക് ഉപയോഗിക്കില്ല - ഇത് ഒരു പീരങ്കി ഉപയോഗിച്ച് കുരുവികളെ വെടിവയ്ക്കുന്നത് പോലെയാണ്, പക്ഷേ അത് ഉപയോഗിക്കുന്നതിന് ആവർത്തനമല്ലാതെ മറ്റൊന്നും ഞാൻ കാണുന്നില്ല. എന്നിരുന്നാലും, ടെലികോമിൽ VMWare ഉപയോഗിക്കുന്നത് ഒരു ഫോർഡ് റാപ്റ്ററിൽ തകർന്ന കല്ല് വലിച്ചെറിയുന്നത് പോലെയാണ് - ഇത് പുറത്ത് നിന്ന് മനോഹരമാണ്, എന്നാൽ ഡ്രൈവർ ഒന്നിന് പകരം 10 ട്രിപ്പുകൾ നടത്തണം.

എന്റെ അഭിപ്രായത്തിൽ, VMWare-ന്റെ ഏറ്റവും വലിയ പോരായ്മ അതിന്റെ സമ്പൂർണ്ണ അടച്ചുപൂട്ടലാണ് - അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു വിവരവും കമ്പനി നിങ്ങൾക്ക് നൽകില്ല, ഉദാഹരണത്തിന്, vSAN അല്ലെങ്കിൽ ഹൈപ്പർവൈസർ കേർണലിൽ എന്താണ് ഉള്ളത് - ഇത് അതിന് ലാഭകരമല്ല - അതായത്, നിങ്ങൾ ഒരിക്കലും VMWare-ൽ ഒരു വിദഗ്ദ്ധനാകരുത് - വെണ്ടർ പിന്തുണയില്ലാതെ, നിങ്ങൾ നശിച്ചുപോകും (നിസാരമായ ചോദ്യങ്ങളാൽ ആശയക്കുഴപ്പത്തിലായ VMWare വിദഗ്ധരെ ഞാൻ പലപ്പോഴും കണ്ടുമുട്ടാറുണ്ട്). എന്നെ സംബന്ധിച്ചിടത്തോളം, VMWare ഹുഡ് ലോക്ക് ചെയ്‌ത ഒരു കാർ വാങ്ങുന്നു - അതെ, നിങ്ങൾക്ക് ടൈമിംഗ് ബെൽറ്റ് മാറ്റാൻ കഴിയുന്ന സ്പെഷ്യലിസ്റ്റുകൾ ഉണ്ടായിരിക്കാം, എന്നാൽ നിങ്ങൾക്ക് ഈ പരിഹാരം വിറ്റയാൾക്ക് മാത്രമേ ഹുഡ് തുറക്കാൻ കഴിയൂ. വ്യക്തിപരമായി, എനിക്ക് ഉൾക്കൊള്ളാൻ കഴിയാത്ത പരിഹാരങ്ങൾ എനിക്ക് ഇഷ്ടമല്ല. നിങ്ങൾക്ക് ഹുഡിന്റെ കീഴിൽ പോകേണ്ടി വരില്ല എന്ന് നിങ്ങൾ പറയും. അതെ, ഇത് സാധ്യമാണ്, എന്നാൽ 20-30 വെർച്വൽ മെഷീനുകൾ, 40-50 നെറ്റ്‌വർക്കുകൾ എന്നിവയിൽ നിന്ന് ക്ലൗഡിൽ ഒരു വലിയ ഫംഗ്ഷൻ കൂട്ടിച്ചേർക്കേണ്ടിവരുമ്പോൾ ഞാൻ നിങ്ങളെ നോക്കും, അതിൽ പകുതിയും പുറത്തേക്ക് പോകാൻ ആഗ്രഹിക്കുന്നു, രണ്ടാം പകുതി ആവശ്യപ്പെടുന്നു SR-IOV ആക്സിലറേഷൻ, അല്ലാത്തപക്ഷം നിങ്ങൾക്ക് ഈ കാറുകളുടെ രണ്ട് ഡസൻ കൂടുതൽ ആവശ്യമാണ് - അല്ലാത്തപക്ഷം പ്രകടനം മതിയാകില്ല.

മറ്റ് കാഴ്ചപ്പാടുകളുണ്ട്, അതിനാൽ എന്ത് തിരഞ്ഞെടുക്കണമെന്ന് നിങ്ങൾക്ക് മാത്രമേ തീരുമാനിക്കാൻ കഴിയൂ, ഏറ്റവും പ്രധാനമായി, നിങ്ങളുടെ തിരഞ്ഞെടുപ്പിന് നിങ്ങൾ ഉത്തരവാദിയായിരിക്കും. ഇത് എന്റെ അഭിപ്രായം മാത്രമാണ് - നോക്കിയ, ജൂനിപ്പർ, റെഡ് ഹാറ്റ്, വിഎംവെയർ എന്നിങ്ങനെ 4 ഉൽപ്പന്നങ്ങളെങ്കിലും കാണുകയും സ്പർശിക്കുകയും ചെയ്ത ഒരാൾ. അതായത്, എനിക്ക് താരതമ്യം ചെയ്യാനുണ്ട്.

അവലംബം: www.habr.com