የደመና መሠረተ ልማት አውታር ክፍል መግቢያ

ክላውድ ማስላት ወደ ህይወታችን እየገባ ነው እና ቢያንስ አንድ ጊዜ ምንም አይነት የደመና አገልግሎቶችን ያልተጠቀመ አንድም ሰው ላይኖር ይችላል። ሆኖም ግን, በትክክል ደመና ምን እንደሆነ እና እንዴት እንደሚሰራ, ጥቂት ሰዎች ያውቃሉ, በሃሳብ ደረጃ እንኳን. 5G ቀድሞውኑ እውን እየሆነ መጥቷል እና የቴሌኮም መሠረተ ልማት ከአምድ መፍትሄዎች ወደ ደመና መፍትሄዎች ልክ እንደ ሙሉ በሙሉ የሃርድዌር መፍትሄዎች ወደ ቨርቹዋል "ምሰሶዎች" ሲሸጋገር እንደነበረው ሁሉ.

ዛሬ ስለ ደመና መሠረተ ልማት ውስጣዊ ዓለም እንነጋገራለን, በተለይም የአውታረ መረብ ክፍልን መሰረታዊ ነገሮች እንመለከታለን.

ደመና ምንድን ነው? ተመሳሳይ ምናባዊ - የመገለጫ እይታ?

ከአመክንዮአዊ ጥያቄ በላይ። አይ - ይህ ቨርቹዋል አይደለም, ምንም እንኳን ያለሱ ማድረግ ባይቻልም. ሁለት ትርጓሜዎችን እንመልከት፡-

ክላውድ ማስላት (ከዚህ በኋላ ደመና ይባላል) ለአገልግሎት አቅራቢው በተቻለ ዝቅተኛ መዘግየት እና አነስተኛ ወጪ በፍላጎት ሊሰማሩ እና ሊጀመሩ የሚገባቸው የተከፋፈሉ የኮምፒዩተር ግብዓቶች ለተጠቃሚ ምቹ ተደራሽነት ለማቅረብ ሞዴል ነው።

ምናባዊነት - ይህ አንድ አካላዊ አካልን (ለምሳሌ አገልጋይ) ወደ ብዙ ቨርቹዋል የመከፋፈል ችሎታ ነው ፣በዚህም የሃብት አጠቃቀምን ይጨምራል (ለምሳሌ ፣ 3 አገልጋዮች በ25-30 በመቶ ተጭነዋል ፣ ከምናባዊነት በኋላ 1 አገልጋይ ይጫናል) በ 80-90 በመቶ)። በተፈጥሮ ፣ ምናባዊነት አንዳንድ ሀብቶችን ይበላል - ሃይፐርቫይዘርን መመገብ ያስፈልግዎታል ፣ ግን ልምምድ እንደሚያሳየው ጨዋታው ሻማው ዋጋ ያለው ነው። የቨርቹዋል አሰራር ጥሩ ምሳሌ VMWare ነው፣ እሱም ቨርቹዋል ማሽኖችን በፍፁም ያዘጋጃል፣ ወይም ለምሳሌ KVM፣ እኔ የምመርጠው፣ ግን ይህ የጣዕም ጉዳይ ነው።

እኛ ሳናውቀው ቨርቹዋልን እንጠቀማለን እና የብረት ራውተሮች እንኳን ቨርቹዋልን ይጠቀማሉ - ለምሳሌ ፣ በቅርብ ጊዜ የ JunOS ስሪት ፣ ኦፕሬቲንግ ሲስተም በእውነተኛ ጊዜ የሊኑክስ ስርጭት (የንፋስ ወንዝ 9) ላይ እንደ ምናባዊ ማሽን ተጭኗል። ነገር ግን ምናባዊነት ደመና አይደለም, ነገር ግን ደመና ያለ ቨርቹዋል ሊኖር አይችልም.

ቨርቹዋል ዳመና ከተሰራባቸው የግንባታ ብሎኮች አንዱ ነው።

በቀላሉ ብዙ ሃይፐርቫይዘሮችን ወደ አንድ L2 ጎራ በመሰብሰብ ደመና መስራት፣ አንዳንድ የያምል ጫወታ መጽሃፎችን በመጨመር vlansን በራስ-ሰር በሆነ መንገድ ለመመዝገብ እና እንደ ኦርኬስትራ ሲስተም የሆነ ነገር በላዩ ላይ በማስቀመጥ ምናባዊ ማሽኖችን በራስ ሰር ለመፍጠር አይሰራም። የበለጠ ትክክለኛ ይሆናል, ነገር ግን የተገኘው ፍራንከንስታይን እኛ የሚያስፈልገንን ደመና አይደለም, ምንም እንኳን ለሌሎች የመጨረሻው ህልም ሊሆን ይችላል. ከዚህም በላይ, ተመሳሳይ Opentack ከወሰዱ, በመሠረቱ አሁንም ፍራንከንስታይን ነው, ግን ኦህ ደህና, አሁን ስለዚያ አንነጋገር.

ነገር ግን ከላይ ከቀረበው ፍቺ አንጻር ደመና ምን ሊባል እንደሚችል ሙሉ በሙሉ ግልጽ እንዳልሆነ ተረድቻለሁ.

ስለዚህ፣ ከNIST (ብሔራዊ ደረጃዎች እና ቴክኖሎጂ ኢንስቲትዩት) የወጣ ሰነድ የደመና መሠረተ ልማት ሊኖረው የሚገባቸውን 5 ዋና ዋና ባህሪያት ያቀርባል፡-

ሲጠየቁ አገልግሎት መስጠት። ተጠቃሚው ለእሱ የተመደቡትን የኮምፒዩተር ሃብቶች (እንደ ኔትወርኮች፣ ቨርቹዋል ዲስኮች፣ ሜሞሪ፣ ፕሮሰሰር ኮሮች፣ ወዘተ) በነፃ ማግኘት አለበት፣ እና እነዚህ ግብአቶች በራስ ሰር መቅረብ አለባቸው - ማለትም ከአገልግሎት ሰጪው ጣልቃ ገብነት ሳይኖር።

ሰፊ የአገልግሎት አቅርቦት። ሁለቱንም መደበኛ ፒሲዎችን እና ቀጭን ደንበኞችን እና ተንቀሳቃሽ መሳሪያዎችን ለመጠቀም የግብአት መዳረሻ በመደበኛ ስልቶች መሰጠት አለበት።

መገልገያዎችን ወደ ገንዳዎች በማጣመር. የመገልገያ ገንዳዎች ሃብቶችን ለብዙ ደንበኞች በአንድ ጊዜ ማቅረብ መቻል አለባቸው፣ ይህም ተገልጋዮች የተገለሉ እና ከጋራ ተጽእኖ እና ከሀብቶች ውድድር የፀዱ መሆናቸውን ማረጋገጥ ነው። በገንዳዎቹ ውስጥ ኔትወርኮች ተካትተዋል፣ ይህ ደግሞ ተደራራቢ አድራሻን የመጠቀም እድልን ያሳያል። ገንዳዎች በፍላጎት መመዘን መቻል አለባቸው። ገንዳዎችን መጠቀም አስፈላጊ የሆነውን የሃብት ጥፋት መቻቻል እና የአካል እና ምናባዊ ሀብቶች ረቂቅነት ለማቅረብ ያስችላል - የአገልግሎቱ ተቀባይ በቀላሉ የጠየቀውን የሃብት ስብስብ (እነዚህ ሀብቶች በአካል በሚገኙበት ፣ ስንት ላይ) ይሰጣል ። አገልጋዮች እና መቀየሪያዎች - ለደንበኛው ምንም አይደለም). ይሁን እንጂ አቅራቢው የእነዚህን ሀብቶች ግልጽነት ማረጋገጥ ያለበትን እውነታ ግምት ውስጥ ማስገባት አለብን.

ለተለያዩ ሁኔታዎች ፈጣን መላመድ. አገልግሎቶቹ ተለዋዋጭ መሆን አለባቸው - ፈጣን የሃብት አቅርቦት፣ መልሶ ማከፋፈላቸው፣ በደንበኛው ጥያቄ ምንጮችን መጨመር ወይም መቀነስ፣ እና በደንበኛው በኩል የደመና ሃብቶች ማለቂያ የለሽ ናቸው የሚል ስሜት ሊኖር ይገባል። ለግንዛቤ ቀላል ለምሳሌ በአፕል iCloud ውስጥ ያለው የዲስክ ቦታዎ ክፍል ጠፍቷል ምክንያቱም በአገልጋዩ ላይ ያለው ሃርድ ድራይቭ ተበላሽቷል እና አሽከርካሪዎች ይበላሻሉ የሚል ማስጠንቀቂያ አይታዩም። በተጨማሪም ፣ በእርስዎ በኩል ፣ የዚህ አገልግሎት ዕድሎች ገደብ የለሽ ናቸው - 2 ቲቢ ያስፈልግዎታል - ምንም ችግር የለም ፣ ከፍለው ተቀብለዋል ። ተመሳሳይ ምሳሌ በ Google.Drive ወይም Yandex.Disk ሊሰጥ ይችላል.

የተሰጠውን አገልግሎት የመለካት እድል. የክላውድ ስርዓቶች የተበላሹ ሀብቶችን በራስ ሰር መቆጣጠር እና ማመቻቸት አለባቸው፣ እና እነዚህ ስልቶች ለተጠቃሚውም ሆነ ለአገልግሎት አቅራቢው ግልፅ መሆን አለባቸው። ያም ማለት እርስዎ እና ደንበኞችዎ ምን ያህል ሀብቶችን እንደሚጠቀሙ ሁልጊዜ ማረጋገጥ ይችላሉ።

እነዚህ መስፈርቶች በአብዛኛው ለህዝባዊ ደመና መስፈርቶች ናቸው የሚለውን እውነታ ግምት ውስጥ ማስገባት ተገቢ ነው, ስለዚህ ለግል ደመና (ይህም ለድርጅቱ ውስጣዊ ፍላጎቶች የተከፈተ ደመና), እነዚህ መስፈርቶች በትንሹ ሊስተካከሉ ይችላሉ. ሆኖም ግን, አሁንም መከናወን አለባቸው, አለበለዚያ ሁሉንም የክላውድ ማስላት ጥቅሞችን አናገኝም.

ደመና ለምን ያስፈልገናል?

ሆኖም፣ ማንኛውም አዲስ ወይም ነባር ቴክኖሎጂ፣ ማንኛውም አዲስ ፕሮቶኮል ለአንድ ነገር ተፈጥሯል (በእርግጥ ከ RIP-ng በስተቀር)። ለፕሮቶኮል ማንም ሰው ፕሮቶኮል አያስፈልገውም (በእርግጥ ከ RIP-ng በስተቀር)። ክላውድ ለተጠቃሚው/ደንበኛ የሆነ አይነት አገልግሎት ለመስጠት መፈጠሩ ምክንያታዊ ነው። ሁላችንም ቢያንስ ሁለት የደመና አገልግሎቶችን እናውቃቸዋለን፣ ለምሳሌ Dropbox ወይም Google.Docs፣ እና አብዛኛው ሰው በተሳካ ሁኔታ እንደሚጠቀምባቸው አምናለሁ - ለምሳሌ፣ ይህ ጽሁፍ የተጻፈው Google.Docs የደመና አገልግሎትን በመጠቀም ነው። ነገር ግን የምናውቃቸው የደመና አገልግሎቶች የዳመናው አቅም አካል ብቻ ናቸው-በይበልጥ በትክክል፣ የSaaS አይነት አገልግሎት ብቻ ናቸው። የደመና አገልግሎትን በሶስት መንገዶች ማቅረብ እንችላለን፡ በ SaaS፣ PaaS ወይም IaaS መልክ። የሚፈልጉት አገልግሎት በእርስዎ ፍላጎቶች እና ችሎታዎች ላይ የተመሰረተ ነው.

እያንዳንዱን በቅደም ተከተል እንመልከታቸው፡-

ሶፍትዌሮች እንደ አገልግሎት (ኤስ.ኤስ.ኤስ.) ለደንበኛው የተሟላ አገልግሎት ለማቅረብ ሞዴል ነው, ለምሳሌ የኢሜል አገልግሎት እንደ Yandex.Mail ወይም Gmail. በዚህ የአገልግሎት አሰጣጥ ሞዴል እርስዎ እንደ ደንበኛ አገልግሎቶቹን ከመጠቀም በቀር ምንም ነገር አያድርጉ - ማለትም አገልግሎቱን ስለማዋቀር ማሰብ አያስፈልግዎትም ፣ ስህተቱ መቻቻል ወይም ድግግሞሽ። ዋናው ነገር የይለፍ ቃልዎን ማበላሸት አይደለም, የዚህ አገልግሎት አቅራቢ ቀሪውን ለእርስዎ ያደርግልዎታል. ከአገልግሎት አቅራቢው አንጻር እሱ ለአገልግሎቱ ሙሉ በሙሉ ኃላፊነት አለበት - ከአገልጋይ ሃርድዌር እና አስተናጋጅ ኦፕሬቲንግ ሲስተሞች እስከ የውሂብ ጎታ እና የሶፍትዌር መቼቶች።

መድረክ እንደ አገልግሎት (PaaS) - ይህንን ሞዴል በሚጠቀሙበት ጊዜ አገልግሎት ሰጪው ለደንበኛው ለአገልግሎቱ የሥራ ቦታ ይሰጣል ፣ ለምሳሌ ፣ የድር አገልጋይ እንውሰድ። አገልግሎት አቅራቢው ለደንበኛው የቨርቹዋል አገልጋይ (በእርግጥ የሃብት ስብስብ፣ ለምሳሌ RAM/CPU/Storage/Nets ወዘተ)፣ እና በዚህ አገልጋይ ላይ ስርዓተ ክወናውን እና አስፈላጊ ሶፍትዌሮችን እንኳን ጭኗል፣ ሆኖም ግን የ እነዚህ ሁሉ ነገሮች በደንበኛው በራሱ እና ለአገልግሎቱ አፈጻጸም ደንበኛው መልስ ይሰጣል. አገልግሎት ሰጪው ልክ እንደበፊቱ ሁኔታ ለአካላዊ መሳሪያዎች፣ ሃይፐርቫይዘሮች፣ ቨርቹዋል ማሽኑ ራሱ፣ የአውታረ መረብ መገኘት፣ ወዘተ አፈጻጸም ሃላፊነት አለበት፣ ነገር ግን አገልግሎቱ እራሱ በሃላፊነት ቦታው ላይ የለም።

መሰረተ ልማት እንደ አገልግሎት (አይአይኤስ) - ይህ አቀራረብ ቀድሞውኑ የበለጠ ትኩረት የሚስብ ነው ፣ በእውነቱ ፣ አገልግሎት አቅራቢው ለደንበኛው የተሟላ ምናባዊ መሠረተ ልማት ያቀርባል - ማለትም ፣ እንደ ሲፒዩ ኮሮች ፣ ራም ፣ አውታረ መረቦች ፣ ወዘተ ያሉ አንዳንድ ሀብቶች ስብስብ (ገንዳ)። ደንበኛው - ደንበኛው በተመደበው ገንዳ (ኮታ) ውስጥ በእነዚህ ሀብቶች ምን ማድረግ እንደሚፈልግ - በተለይ ለአቅራቢው አስፈላጊ አይደለም. ደንበኛው የራሱን vEPC መፍጠር ወይም ሚኒ ኦፕሬተርን መፍጠር እና የግንኙነት አገልግሎቶችን መስጠት ቢፈልግ - ምንም ጥያቄ የለውም - ያድርጉት። በእንደዚህ ዓይነት ሁኔታ ውስጥ አገልግሎት ሰጪው ሀብቶችን ፣ ጥፋታቸውን መቻቻል እና ተገኝነት እንዲሁም እነዚህን ሀብቶች በአንድ ላይ እንዲያዋህዱ እና በማንኛውም ጊዜ ሀብቶችን የመጨመር ወይም የመቀነስ ችሎታ እንዲኖራቸው የሚያስችል ስርዓተ ክወና የመስጠት ሃላፊነት አለበት። በደንበኛው ጥያቄ. ደንበኛው ሁሉንም ቨርቹዋል ማሽኖች እና ሌሎች ቆርቆሮዎችን በራሱ አገልግሎት ፖርታል እና ኮንሶል ያዋቅራል፣ አውታረ መረቦችን ማቀናበርን ጨምሮ (ከውጫዊ አውታረ መረቦች በስተቀር)።

OpenStack ምንድን ነው?

በሶስቱም አማራጮች አገልግሎት አቅራቢው የክላውድ መሠረተ ልማት ለመፍጠር የሚያስችል ስርዓተ ክወና ያስፈልገዋል። በእውነቱ ፣ በ SaaS ፣ ከአንድ በላይ ክፍፍል ለጠቅላላው የቴክኖሎጂ ቁልል ተጠያቂ ነው - ለመሠረተ ልማት ኃላፊነት ያለው ክፍል አለ - ማለትም IaaS ለሌላ ክፍል ይሰጣል ፣ ይህ ክፍል ለደንበኛው SaaS ይሰጣል። OpenStack በርካታ ማብሪያና ማጥፊያዎችን፣ ሰርቨሮችን እና የማከማቻ ስርዓቶችን ወደ አንድ የመረጃ ቋት ለመሰብሰብ፣ ይህንን የጋራ ገንዳ ወደ ንዑስ ገንዳዎች (ተከራዮች) ከፍሎ እነዚህን ግብዓቶች በኔትወርኩ ለደንበኞች ለማቅረብ ከሚያስችል የደመና ኦፕሬቲንግ ሲስተሞች አንዱ ነው።

OpenStack መደበኛ የማረጋገጫ ስልቶችን በመጠቀም በኤፒአይ የሚቀርብ እና የሚተዳደር ትልልቅ የኮምፕዩቲንግ ሃብቶችን፣ የውሂብ ማከማቻ እና የአውታረ መረብ ሀብቶችን እንድትቆጣጠር የሚያስችል የደመና ኦፕሬቲንግ ሲስተም ነው።

በሌላ አነጋገር ይህ የደመና አገልግሎቶችን ለመፍጠር (የህዝብ እና የግል) ለመፍጠር የተነደፈ ነፃ የሶፍትዌር ፕሮጄክቶች ስብስብ ነው - ማለትም አገልጋይን እና መሳሪያዎችን ወደ አንድ የውሃ ገንዳ ውስጥ ለማዋሃድ ፣ ለማስተዳደር የሚያስችልዎ የመሳሪያዎች ስብስብ ነው ። እነዚህን ሀብቶች, አስፈላጊውን የስህተት መቻቻል ደረጃ ያቀርባል.

ይህን ጽሑፍ በሚጽፉበት ጊዜ የOpenStack መዋቅር ይህን ይመስላል፡-

የተወሰደው ፎቶ openstack.org

በ OpenStack ውስጥ የተካተቱት እያንዳንዱ ክፍሎች አንድ የተወሰነ ተግባር ያከናውናሉ. ይህ የተከፋፈለው አርክቴክቸር እርስዎ የሚፈልጉትን የተግባር ክፍሎች ስብስብ በመፍትሔው ውስጥ እንዲያካትቱ ያስችልዎታል። ይሁን እንጂ አንዳንድ አካላት የስር ክፍሎች ናቸው እና የእነሱ መወገድ በአጠቃላይ የመፍትሄው ሙሉ በሙሉ ወይም በከፊል ወደማይሰራ ይመራል. እነዚህ ክፍሎች ብዙውን ጊዜ እንደሚከተለው ይመደባሉ፡-

• ዳሽቦርድ - OpenStack አገልግሎቶችን ለማስተዳደር በድር ላይ የተመሠረተ GUI
• የማዕዘን ለሌሎች አገልግሎቶች የማረጋገጫ እና የፈቃድ ተግባርን እንዲሁም የተጠቃሚ ምስክርነቶችን እና ሚናዎቻቸውን የሚቆጣጠር ማዕከላዊ የማንነት አገልግሎት ነው።
• ኒንቱር - በተለያዩ የOpenStack አገልግሎቶች (በቪኤምኤስ መካከል ያለውን ግንኙነት እና ወደ ውጭው ዓለም ያላቸውን መዳረሻ ጨምሮ) በይነገጾች መካከል ግንኙነትን የሚሰጥ የአውታረ መረብ አገልግሎት።
• Cinder - ለምናባዊ ማሽኖች የማገጃ ማከማቻ መዳረሻ ይሰጣል
• ኖቫ - ምናባዊ ማሽኖች የሕይወት ዑደት አስተዳደር
• በጨረፍታ - የቨርቹዋል ማሽን ምስሎች እና ቅጽበተ-ፎቶዎች ማከማቻ
• ስዊፍት - ወደ ማከማቻው ነገር መዳረሻ ይሰጣል
• ሴሎሜትር - ቴሌሜትሪ ለመሰብሰብ እና ያሉትን እና ጥቅም ላይ የዋሉ ሀብቶችን ለመለካት ችሎታ የሚሰጥ አገልግሎት
• ሙቀት - በራስ-ሰር ለመፍጠር እና ሀብቶችን ለማቅረብ በአብነት ላይ የተመሠረተ ኦርኬስትራ

የሁሉም ፕሮጀክቶች ሙሉ ዝርዝር እና ዓላማቸው ሊታይ ይችላል እዚህ.

እያንዳንዱ የOpenStack አካል አንድ የተወሰነ ተግባር የሚያከናውን እና ያንን ተግባር ለማስተዳደር እና ከሌሎች የደመና ስርዓተ ክወና አገልግሎቶች ጋር አንድ ወጥ የሆነ መሠረተ ልማት ለመፍጠር ኤፒአይ የሚሰጥ አገልግሎት ነው። ለምሳሌ፣ ኖቫ የኮምፒውቲንግ ሪሶርስ አስተዳደር እና እነዚህን ሃብቶች ለማዋቀር ኤፒአይ ይሰጣል፣ Glance የምስል አስተዳደር እና እነሱን ለማስተዳደር ኤፒአይ ይሰጣል፣ ሲንደር የማገጃ ማከማቻ እና እሱን ለማስተዳደር ኤፒአይ ወዘተ ይሰጣል። ሁሉም ተግባራት በጣም ቅርብ በሆነ መንገድ እርስ በርስ የተያያዙ ናቸው.

ነገር ግን፣ ከተመለከቱት፣ በOpenStack ውስጥ የሚሰሩ ሁሉም አገልግሎቶች በመጨረሻ ከአውታረ መረቡ ጋር የተገናኙ አንዳንድ ምናባዊ ማሽን (ወይም ኮንቴይነሮች) ናቸው። ጥያቄው የሚነሳው - ​​ለምን ብዙ ንጥረ ነገሮችን እንፈልጋለን?

ምናባዊ ማሽንን ለመፍጠር እና ከአውታረ መረቡ ጋር ለማገናኘት እና በ Opentack ውስጥ ቀጣይነት ያለው ማከማቻን ለመፍጠር ስልተ ቀመሩን እንሂድ።

1. ማሽን ለመፍጠር ጥያቄ ሲፈጥሩ ፣ በሆራይዘን (ዳሽቦርድ) ወይም በ CLI በኩል ጥያቄ ፣ የመጀመሪያው ነገር የሚሆነው የጥያቄዎ ፈቃድ በ Keystone ላይ ነው - ማሽን መፍጠር ይችላሉ ፣ እሱ አለው? ይህን አውታረ መረብ የመጠቀም መብት፣ የእርስዎ ረቂቅ ኮታ ይሰራል፣ ወዘተ.
2. የቁልፍ ስቶን ጥያቄዎን ያረጋግጣል እና በምላሽ መልዕክቱ ውስጥ የማረጋገጫ ማስመሰያ ያመነጫል፣ ይህም የበለጠ ጥቅም ላይ ይውላል። ከKeystone ምላሽ ከደረሰን፣ ጥያቄው ወደ ኖቫ (nova api) ይላካል።
3. ኖቫ-ኤፒ ከዚህ ቀደም የመነጨውን የማረጋገጫ ማስመሰያ በመጠቀም የቁልፍ ስቶንን በማነጋገር የጥያቄዎን ትክክለኛነት ያረጋግጣል።
4. Keystone ማረጋገጫን ያከናውናል እና በዚህ የማረጋገጫ ማስመሰያ ላይ ተመስርተው ስለፍቃዶች እና ገደቦች መረጃ ይሰጣል።
5. Nova-api ለአዲሱ ቪኤም በ nova-database ውስጥ ግቤት ይፈጥራል እና ማሽኑን ለመፍጠር ጥያቄውን ለኖቫ-መርሐግብር አስተላላፊ ያስተላልፋል።
6. Nova-scheduler በተጠቀሱት መመዘኛዎች, ክብደቶች እና ዞኖች መሰረት VM የሚሰማራበትን አስተናጋጅ (የኮምፒዩተር ኖድ) ይመርጣል. የዚህ እና የቪኤም መታወቂያው መዝገብ ለኖቫ-ዳታቤዝ ተጽፏል።
7. በመቀጠል፣ nova-scheduler nova-computaን ለአብነት ለማሰማራት ጥያቄ ያነጋግራል። ስለ ማሽን መለኪያዎች መረጃ ለማግኘት Nova-compute ኖቫ-ኮንዳክተርን ያገናኛል (nova-conductor በ nova-database እና nova-compute መካከል እንደ ተኪ አገልጋይ ሆኖ የሚያገለግል የኖቫ ኤለመንት ነው፣ከዳታቤዝ ጋር የተያያዙ ችግሮችን ለማስወገድ ወደ ኖቫ ዳታቤዝ የሚቀርቡትን ጥያቄዎች ብዛት ይገድባል። ወጥነት ያለው ጭነት መቀነስ).
8. Nova-conductor የተጠየቀውን መረጃ ከኖቫ-ዳታ ቤዝ ተቀብሎ ወደ nova-computa ያስተላልፋል።
9. በመቀጠል፣ የምስሉን መታወቂያ ለማግኘት nova-compute በጨረፍታ ይጠራል። Glace በ Keystone ውስጥ ያለውን ጥያቄ አረጋግጦ የተጠየቀውን መረጃ ይመልሳል።
10. ስለ አውታረ መረብ መለኪያዎች መረጃ ለማግኘት ኖቫ-አስላ እውቂያዎች ኒውትሮን። ከጨረፍታ ጋር በሚመሳሰል መልኩ ኒውትሮን በ Keystone ውስጥ ያለውን ጥያቄ ያጸድቃል, ከዚያ በኋላ በመረጃ ቋቱ ውስጥ መግባትን ይፈጥራል (ወደብ መለያ, ወዘተ.) ወደብ የመፍጠር ጥያቄን ይፈጥራል እና የተጠየቀውን መረጃ ወደ ኖቫ-ኮምፒዩት ይመልሳል.
11. ኖቫ-ማስላት እውቂያዎች ሲንደር ለቨርቹዋል ማሽኑ የድምጽ መጠን ለመመደብ ጥያቄ በማቅረብ። ከጨረፍታ ጋር በሚመሳሰል መልኩ cider በ Keystone ውስጥ ያለውን ጥያቄ ያረጋግጣል፣ የድምጽ መጠን መፍጠር ጥያቄን ይፈጥራል እና የተጠየቀውን መረጃ ይመልሳል።
12. ከተገለጹት መመዘኛዎች ጋር ምናባዊ ማሽንን ለማሰማራት ጥያቄ በማቅረብ Nova-compute contacts libvirt.

እንደ እውነቱ ከሆነ፣ ቀላል የሚመስል አሰራር በደመና መድረክ አካላት መካከል ወደ እንደዚህ ዓይነት የኤፒአይ ጥሪዎች አዙሪት ይቀየራል። በተጨማሪም ፣ እርስዎ እንደሚመለከቱት ፣ ቀደም ሲል የተሰየሙ አገልግሎቶችም እንዲሁ በመካከላቸው መስተጋብር በሚፈጠርባቸው ትናንሽ አካላት ያቀፈ ነው። ማሽን መፍጠር የደመና መድረክ ከሚፈቅደው ውስጥ ትንሽ ክፍል ብቻ ነው - ትራፊክን የማመጣጠን ኃላፊነት ያለው አገልግሎት፣ የማገጃ ማከማቻ ኃላፊነት ያለው አገልግሎት፣ ለዲ ኤን ኤስ ኃላፊነት ያለው አገልግሎት፣ ባዶ የብረት አገልጋዮችን የማቅረብ ኃላፊነት ያለው አገልግሎት፣ ወዘተ. ደመናው ምናባዊ ማሽኖችዎን እንደ በግ መንጋ (ከቨርቹዋልነት በተቃራኒ) እንዲይዙ ይፈቅድልዎታል። በምናባዊ አካባቢ ውስጥ በማሽንዎ ላይ የሆነ ነገር ቢከሰት - ከመጠባበቂያ ቅጂዎች ወዘተ ወደነበረበት ይመልሱት ፣ ግን የደመና አፕሊኬሽኖች የተገነቡት ቨርቹዋል ማሽኑ ይህን ያህል አስፈላጊ ሚና በማይጫወትበት መንገድ ነው - ምናባዊው ማሽን “ሞተ” - ምንም ችግር የለም ። - አዲስ በቀላሉ ተፈጠረ ተሽከርካሪው በአብነት ላይ የተመሰረተ ነው, እና እነሱ እንደሚሉት, ቡድኑ የተዋጊውን ኪሳራ አላስተዋለም. በተፈጥሮ ይህ የኦርኬስትራ ስልቶችን መኖሩን ያቀርባል - የሙቀት አብነቶችን በመጠቀም, በደርዘን የሚቆጠሩ አውታረ መረቦችን እና ምናባዊ ማሽኖችን ያካተተ ውስብስብ ተግባርን በቀላሉ ማሰማራት ይችላሉ.

ያለ አውታረ መረብ የደመና መሠረተ ልማት አለመኖሩን ሁል ጊዜ ማስታወስ ጠቃሚ ነው - እያንዳንዱ አካል በአንድ መንገድ ወይም በሌላ በአውታረ መረቡ በኩል ከሌሎች አካላት ጋር ይገናኛል። በተጨማሪም፣ ደመናው ፍፁም የማይንቀሳቀስ አውታረ መረብ አለው። በተፈጥሮ ስር ያለው አውታረመረብ የበለጠ ወይም ያነሰ የማይንቀሳቀስ ነው - አዳዲስ አንጓዎች እና ማብሪያ / ማጥፊያዎች በየቀኑ አይጨመሩም ፣ ግን ተደራቢው አካል ሁል ጊዜ ሊለዋወጥ እና ሊለወጥ ይችላል - አዳዲስ አውታረ መረቦች ይጨመራሉ ወይም ይሰረዛሉ ፣ አዳዲስ ቨርቹዋል ማሽኖች ይመጣሉ እና አሮጌዎቹ ይከሰታሉ። መሞት እና በአንቀጹ መጀመሪያ ላይ ከተሰጠው የዳመና ፍቺ እንዳስታውሱት ሀብቶች ለተጠቃሚው በራስ-ሰር እና በትንሹ (ወይም በተሻለ ፣ ያለ) በአገልግሎት አቅራቢው ጣልቃ መግባት አለባቸው። ማለትም፣ አሁን በግንባር-መጨረሻ መልክ ያለው የአውታረ መረብ ግብዓቶች አቅርቦት አይነት በግል መለያዎ በ http/https በኩል ሊደረስበት የሚችል እና ተረኛ አውታረ መረብ መሐንዲስ ቫሲሊ እንደ የኋላ ጀርባ ደመና አይደለም ፣ እንኳን ቫሲሊ ስምንት እጆች ካሉት.

ኒውትሮን፣ እንደ የአውታረ መረብ አገልግሎት፣ የደመና መሠረተ ልማት አውታር ክፍልን ለማስተዳደር ኤፒአይ ይሰጣል። አገልግሎቱ ኔትወርክ-አስ-አገልግሎት (NaaS) የተባለ የአብስትራክሽን ንብርብር በማቅረብ የ Opentackን የአውታረ መረብ ክፍል ያንቀሳቅሳል እና ያስተዳድራል። ማለትም፣ አውታረ መረቡ ልክ እንደ ቨርቹዋል ሲፒዩ ኮሮች ወይም የ RAM መጠን ተመሳሳይ ምናባዊ መለኪያ ነው።

ነገር ግን ወደ OpenStack የአውታረ መረብ ክፍል ከመሄዳችን በፊት ይህ አውታረ መረብ በOpenStack ውስጥ እንዴት እንደሚሰራ እና ለምን አውታረ መረቡ አስፈላጊ እና የደመና አካል እንደሆነ እናስብ።

ስለዚህ ሁለት የቀይ ደንበኛ ቪኤም እና ሁለት አረንጓዴ ደንበኛ ቪኤምዎች አሉን። እነዚህ ማሽኖች በዚህ መንገድ በሁለት ሃይፐርቫይዘሮች ላይ እንደሚገኙ እናስብ፡-

በአሁኑ ጊዜ ይህ የ 4 አገልጋዮች ምናባዊ ፈጠራ ብቻ ነው እና ምንም አይደለም ፣ ምክንያቱም እስካሁን ያደረግነው 4 አገልጋዮችን በሁለት አካላዊ አገልጋዮች ላይ በማስቀመጥ ቨርቹዋል ማድረግ ነው። እና እስካሁን ድረስ ከአውታረ መረቡ ጋር እንኳን አልተገናኙም.

ደመናን ለመሥራት, ብዙ ክፍሎችን መጨመር ያስፈልገናል. በመጀመሪያ ፣ የአውታረ መረብ ክፍሉን እናሳያለን - እነዚህን 4 ማሽኖች በጥንድ ማገናኘት አለብን ፣ እና ደንበኞቹ የ L2 ግንኙነት ይፈልጋሉ። ማብሪያ / ማጥፊያን መጠቀም እና ግንዱን ወደ እሱ አቅጣጫ ማዋቀር እና ሁሉንም ነገር በሊኑክስ ድልድይ በመጠቀም መፍታት ወይም ለበለጠ የላቀ ተጠቃሚዎች openvswitch (ወደዚህ በኋላ እንመለሳለን) ትችላለህ። ነገር ግን ብዙ ኔትወርኮች ሊኖሩ ይችላሉ, እና L2 ን በመቀየሪያ ውስጥ ያለማቋረጥ መግፋት ጥሩ ሀሳብ አይደለም - የተለያዩ ክፍሎች አሉ, የአገልግሎት ጠረጴዛ, ማመልከቻ እስኪጠናቀቅ የሚጠብቁ ወራት, የሳምንታት መላ ፍለጋ - በዘመናዊው ዓለም ይህ አካሄድ ከአሁን በኋላ አይሰራም። እና አንድ ኩባንያ ይህንን በተረዳ ቁጥር ወደ ፊት ለመራመድ ቀላል ይሆንለታል። ስለዚህ በሃይፐርቫይዘሮቹ መካከል ቨርቹዋል ማሽኖቻችን የሚግባቡበትን L3 ኔትወርክ እንመርጣለን በዚህ ኤል 3 ኔትወርክ ላይ የቨርቹዋል ማሽኖቻችን ትራፊክ የሚሰራባቸው ቨርቹዋል L2 ተደራቢ ኔትወርኮች እንገነባለን። GRE፣ Geneve ወይም VxLAN እንደ ማቀፊያ መጠቀም ይችላሉ። ምንም እንኳን በተለይ አስፈላጊ ባይሆንም ለአሁኑ በመጨረሻው ላይ እናተኩር።

VTEP የሆነ ቦታ ማግኘት አለብን (ሁሉም ሰው የVxLAN ቃላትን እንደሚያውቅ ተስፋ አደርጋለሁ)። ከአገልጋዮቹ በቀጥታ የሚመጣ የL3 ኔትወርክ ስላለን VTEPን በአገልጋዮቹ ላይ እንዳናስቀምጥ የሚከለክለን ምንም ነገር የለም፣ እና OVS (OpenvSwitch) ይህን በማድረግ ረገድ በጣም ጥሩ ነው። በውጤቱም, ይህንን ንድፍ አግኝተናል-

በቪኤም መካከል ያለው ትራፊክ መከፋፈል ስላለበት ወደ ቨርቹዋል ማሽኖቹ የሚሄዱት ወደቦች የተለያዩ የቪላን ቁጥሮች ይኖሯቸዋል። የመለያ ቁጥሩ የሚጫወተው ሚና የሚጫወተው በአንድ ምናባዊ መቀየሪያ ውስጥ ብቻ ነው፣ ምክንያቱም በVxLAN ውስጥ ሲገለበጥ በቀላሉ ልናስወግደው እንችላለን፣ ምክንያቱም VNI ስለሚኖረን ነው።

አሁን ማሽኖቻችንን እና ምናባዊ አውታረ መረቦችን ያለምንም ችግር ለእነሱ መፍጠር እንችላለን.

ነገር ግን፣ ደንበኛው ሌላ ማሽን ካለው፣ ግን በተለየ አውታረ መረብ ላይ ከሆነስ? በኔትወርኮች መካከል ስር መስደድ ያስፈልገናል. የተማከለ ማዘዋወር ጥቅም ላይ በሚውልበት ጊዜ ቀላል አማራጭን እንመለከታለን - ማለትም ትራፊክ በልዩ ልዩ የአውታረ መረብ ኖዶች (በጥሩ ሁኔታ ፣ እንደ አንድ ደንብ ፣ እነሱ ከቁጥጥር አንጓዎች ጋር ይጣመራሉ ፣ ስለዚህ እኛ ተመሳሳይ ነገር ይኖረናል)።

ምንም የተወሳሰበ አይመስልም - በመቆጣጠሪያ መስቀለኛ መንገድ ላይ የድልድይ በይነገጽ እንሰራለን, ትራፊክ ወደ እሱ እንነዳለን እና ከዚያ ወደምንፈልገው ቦታ እናዞራለን. ግን ችግሩ የ RED ደንበኛ የ 10.0.0.0/24 ኔትወርክን መጠቀም ይፈልጋል, እና የ GREEN ደንበኛ የ 10.0.0.0/24 አውታረመረብን መጠቀም ይፈልጋል. ማለትም የአድራሻ ቦታዎችን መቆራረጥ እንጀምራለን. በተጨማሪም, ደንበኞች ሌሎች ደንበኞች ወደ ውስጣዊ አውታረ መረቦቻቸው እንዲገቡ አይፈልጉም, ይህም ምክንያታዊ ነው. የአውታረ መረቦችን እና የደንበኛ ውሂብ ትራፊክን ለመለየት ለእያንዳንዳቸው የተለየ የስም ቦታ እንመድባለን። የስም ቦታ በእውነቱ የሊኑክስ አውታረመረብ ቁልል ቅጂ ነው፣ ማለትም፣ በስም ቦታ ውስጥ ያሉ ደንበኞች RED ሙሉ በሙሉ ከደንበኞች ከስም ቦታ GREEN የተገለሉ ናቸው (መልካም፣ በእነዚህ የደንበኛ ኔትወርኮች መካከል ማዘዋወር በነባሪ የስም ቦታ ወይም ወደላይ የመጓጓዣ መሳሪያዎች ይፈቀዳል።)

ማለትም የሚከተለውን ሥዕላዊ መግለጫ እናገኛለን።

L2 ዋሻዎች ከሁሉም የኮምፒዩተር ኖዶች ወደ መቆጣጠሪያ መስቀለኛ መንገድ ይሰባሰባሉ። መስቀለኛ መንገድ የእነዚህ አውታረ መረቦች L3 በይነገጽ የሚገኝበት፣ እያንዳንዱ ለብቻው በተዘጋጀ የስም ቦታ።

ሆኖም ግን, በጣም አስፈላጊ የሆነውን ነገር ረሳነው. ቨርቹዋል ማሽኑ ለደንበኛው አገልግሎት መስጠት አለበት, ማለትም, ቢያንስ አንድ ሊደረስበት የሚችል ውጫዊ በይነገጽ ሊኖረው ይገባል. ማለትም ወደ ውጭው ዓለም መውጣት አለብን። እዚህ የተለያዩ አማራጮች አሉ. በጣም ቀላሉን አማራጭ እናድርግ. ለእያንዳንዱ ደንበኛ አንድ አውታረ መረብ እንጨምራለን, ይህም በአቅራቢው አውታረመረብ ውስጥ የሚሰራ እና ከሌሎች አውታረ መረቦች ጋር መደራረብ የለበትም. ኔትወርኮቹ እርስበርስ መገናኘት እና በአቅራቢው አውታረመረብ በኩል የተለያዩ VRFዎችን ማየት ይችላሉ። የአውታረ መረብ ውሂብ በእያንዳንዱ ደንበኛ የስም ቦታ ላይም ይኖራል። ሆኖም፣ አሁንም በአንድ አካላዊ (ወይም ቦንድ፣ የበለጠ ምክንያታዊ በሆነ) በይነገጽ ወደ ውጭው ዓለም ይወጣሉ። የደንበኛ ትራፊክን ለመለየት ወደ ውጭ የሚሄደው ትራፊክ ለደንበኛው በተመደበው የVLAN መለያ ይሰየማል።

በውጤቱም, ይህንን ንድፍ አግኝተናል-

ምክንያታዊ ጥያቄ ለምን በኮምፕዩት ኖዶች ላይ መግቢያዎችን ራሳቸው አታዘጋጁም? ይህ ትልቅ ችግር አይደለም፤ በተጨማሪም የተከፋፈለውን ራውተር (DVR) ካበሩት ይሄ ይሰራል። በዚህ ሁኔታ፣ በነባሪ በ Opentack ውስጥ ጥቅም ላይ የሚውለውን የተማከለ መግቢያ በር ያለው ቀላሉ አማራጭን እያጤንን ነው። ለከፍተኛ ጭነት ተግባራት ሁለቱንም የተከፋፈለ ራውተር እና እንደ SR-IOV እና Passthrough ያሉ የፍጥነት ቴክኖሎጂዎችን ይጠቀማሉ ነገር ግን እነሱ እንደሚሉት ይህ ፈጽሞ የተለየ ታሪክ ነው። መጀመሪያ፣ ከመሠረታዊው ክፍል ጋር እንነጋገር፣ ከዚያም ወደ ዝርዝር ጉዳዮች እንገባለን።

በእውነቱ ፣ የእኛ እቅድ ቀድሞውኑ ሊሠራ የሚችል ነው ፣ ግን ሁለት ልዩነቶች አሉ-

• ማሽኖቻችንን እንደምንም መጠበቅ አለብን፣ ማለትም፣ ወደ ደንበኛው አቅጣጫ በማቀያየር በይነገጽ ላይ ማጣሪያ ማድረግ።
• ቨርቹዋል ማሽን በኮንሶል ውስጥ ሁል ጊዜ ገብተህ አድራሻውን እንዳትመዘግብ የአይ ፒ አድራሻን በራስ ሰር እንዲያገኝ አድርግ።

በማሽን ጥበቃ እንጀምር. ለዚህም ባናል iptables መጠቀም ይችላሉ, ለምን አይሆንም.

ማለትም፣ አሁን የእኛ ቶፖሎጂ ትንሽ የተወሳሰበ ሆኗል፡-

እንቀጥል። የDHCP አገልጋይ ማከል አለብን። ለእያንዳንዱ ደንበኛ የ DHCP አገልጋዮችን ለማግኘት በጣም ጥሩው ቦታ ከላይ የተጠቀሰው የቁጥጥር መስቀለኛ መንገድ ሲሆን የስም ቦታዎች የሚገኙበት ነው፡

ይሁን እንጂ ትንሽ ችግር አለ. ሁሉም ነገር እንደገና ቢነሳ እና በDHCP ላይ ስለመከራየት አድራሻዎች ሁሉም መረጃዎች ቢጠፉስ? ማሽኖቹ አዲስ አድራሻዎች መሰጠታቸው ምክንያታዊ ነው, ይህም በጣም ምቹ አይደለም. እዚህ ሁለት መንገዶች አሉ - ወይም የጎራ ስሞችን ይጠቀሙ እና ለእያንዳንዱ ደንበኛ የዲ ኤን ኤስ አገልጋይ ያክሉ ፣ ከዚያ አድራሻው ለእኛ በተለይ አስፈላጊ አይሆንም (በ k8 ውስጥ ካለው የአውታረ መረብ ክፍል ጋር ተመሳሳይ) - ግን በውጫዊ አውታረ መረቦች ላይ ችግር አለ ፣ ምክንያቱም አድራሻዎች በእነሱ ውስጥ በ DHCP በኩል ሊሰጡ ይችላሉ - በደመና መድረክ ውስጥ ከዲ ኤን ኤስ አገልጋዮች እና ውጫዊ የዲ ኤን ኤስ አገልጋይ ጋር ማመሳሰል ያስፈልግዎታል ፣ በእኔ አስተያየት በጣም ተለዋዋጭ አይደለም ፣ ግን በጣም ይቻላል ። ወይም ሁለተኛው አማራጭ ሜታዳታ መጠቀም ነው - ማለትም ለማሽኑ የተሰጠ አድራሻ መረጃን ማስቀመጥ የDHCP አገልጋይ ማሽኑ አስቀድሞ አድራሻ ከተቀበለ የትኛውን አድራሻ እንደሚሰጥ ያውቃል። ሁለተኛው አማራጭ ቀላል እና የበለጠ ተለዋዋጭ ነው, ምክንያቱም ስለ መኪናው ተጨማሪ መረጃ እንዲያስቀምጡ ያስችልዎታል. አሁን ወደ ሥዕላዊ መግለጫው ወኪል ሜታዳታ እንጨምር፡-

ሌላው ሊወያይበት የሚገባው ጉዳይ ደግሞ አንድ ውጫዊ አውታረ መረብ በሁሉም ደንበኞች የመጠቀም ችሎታ ነው ፣ ምክንያቱም ውጫዊ አውታረ መረቦች በጠቅላላው አውታረ መረብ ውስጥ ትክክለኛ መሆን ካለባቸው አስቸጋሪ ስለሚሆኑ - የእነዚህን አውታረ መረቦች ምደባ በቋሚነት መመደብ እና መቆጣጠር ያስፈልግዎታል። ህዝባዊ ደመናን ሲፈጥሩ ለሁሉም ደንበኞች አንድ ነጠላ ውጫዊ አስቀድሞ የተዋቀረ አውታረ መረብን የመጠቀም ችሎታ በጣም ጠቃሚ ይሆናል። ይህም ማሽኖችን ለማሰማራት ቀላል ያደርገዋል ምክንያቱም የአድራሻ ዳታቤዝ ማማከር እና ለእያንዳንዱ ደንበኛ ውጫዊ አውታረ መረብ ልዩ የአድራሻ ቦታ መምረጥ አያስፈልገንም. በተጨማሪም የውጭ ኔትወርክን አስቀድመን መመዝገብ እንችላለን እና በሚሰማሩበት ጊዜ የውጭ አድራሻዎችን ከደንበኛ ማሽኖች ጋር ብቻ ማያያዝ አለብን.

እና እዚህ NAT እኛን ለመርዳት መጥቷል - ደንበኞች የ NAT ትርጉምን በመጠቀም የውጭውን ዓለም በነባሪ የስም ቦታ እንዲደርሱ እናደርጋለን። ደህና, እዚህ ትንሽ ችግር አለ. ይህ ደንበኛ አገልጋይ እንደ አገልጋይ ሳይሆን እንደ ደንበኛ የሚሠራ ከሆነ ጥሩ ነው - ማለትም ግንኙነቶችን ከመቀበል ይልቅ ይጀምራል። ለእኛ ግን በተቃራኒው ይሆናል። በዚህ አጋጣሚ የመዳረሻ NAT ማድረግ አለብን ትራፊክ በሚቀበልበት ጊዜ የቁጥጥር መስቀለኛ መንገድ ይህ ትራፊክ ለደንበኛው A ምናባዊ ማሽን የታሰበ መሆኑን ይገነዘባል ፣ ይህ ማለት ከውጭ አድራሻ የ NAT ትርጉም ማድረግ አለብን ፣ ለምሳሌ 100.1.1.1 .10.0.0.1፣ ወደ የውስጥ አድራሻ 100. በዚህ ሁኔታ, ሁሉም ደንበኞች አንድ አይነት አውታረ መረብ ቢጠቀሙም, ውስጣዊ ማግለል ሙሉ በሙሉ ተጠብቆ ይገኛል. ማለትም በመቆጣጠሪያ መስቀለኛ መንገድ ላይ dNAT እና sNAT ማድረግ አለብን። ነጠላ ኔትወርክን በተንሳፋፊ አድራሻዎች ወይም ውጫዊ አውታረ መረቦች መጠቀም ወይም ሁለቱንም በአንድ ጊዜ መጠቀም ወደ ደመናው ማምጣት በሚፈልጉት ላይ ይወሰናል. በሥዕላዊ መግለጫው ላይ ተንሳፋፊ አድራሻዎችን አንጨምርም ፣ ግን ቀደም ሲል የተጨመሩትን ውጫዊ አውታረ መረቦች እንተወዋለን - እያንዳንዱ ደንበኛ የራሱ ውጫዊ አውታረመረብ አለው (በስዕሉ ላይ በውጫዊ በይነገጽ ላይ vlan 200 እና XNUMX ይጠቀሳሉ)።

በውጤቱም, አንድ አስደሳች እና በተመሳሳይ ጊዜ በደንብ የታሰበበት መፍትሄ አግኝተናል, እሱም የተወሰነ ተለዋዋጭነት ያለው ነገር ግን እስካሁን ድረስ የስህተት መቻቻል ዘዴዎች የሉትም.

በመጀመሪያ ደረጃ አንድ የቁጥጥር መስቀለኛ መንገድ ብቻ አለን - አለመሳካቱ የሁሉም ስርዓቶች ውድቀት ያስከትላል። ይህንን ችግር ለመፍታት ቢያንስ የ 3 ኖዶች ኮረም ማድረግ ያስፈልግዎታል። ይህንን ወደ ሥዕላዊ መግለጫው እንጨምር፡-

በተፈጥሮ ሁሉም አንጓዎች ተመሳስለዋል እና ንቁ የሆነ መስቀለኛ ክፍል ሲወጣ ሌላ መስቀለኛ መንገድ ኃላፊነቱን ይወስዳል።

የሚቀጥለው ችግር ምናባዊ ማሽን ዲስኮች ነው. በአሁኑ ጊዜ እነሱ በራሳቸው ሃይፐርቫይዘሮች ላይ ተከማችተዋል, እና በሃይፐርቫይዘር ችግር ውስጥ, ሁሉንም መረጃዎች እናጣለን - እና ወረራ መኖሩ ዲስኩን ሳይሆን መላውን አገልጋይ ካጣን እዚህ አይረዳም. ይህንን ለማድረግ ለአንድ ዓይነት ማከማቻ እንደ የፊት ለፊት ሆኖ የሚያገለግል አገልግሎት መስራት አለብን። ምን ዓይነት ማከማቻ እንደሚሆን ለእኛ በተለይ አስፈላጊ አይደለም, ነገር ግን የእኛን መረጃ ከሁለቱም ዲስኩ እና መስቀለኛ መንገድ, እና ምናልባትም ሙሉውን ካቢኔን አለመሳካት መጠበቅ አለበት. እዚህ ብዙ አማራጮች አሉ - በእርግጥ የ SAN አውታረ መረቦች ከፋይበር ቻናል ጋር አሉ ፣ ግን እውነቱን እንነጋገር ከተባለ - FC ቀድሞውኑ ያለፈ ታሪክ ነው - በትራንስፖርት ውስጥ የ E1 አናሎግ - አዎ ፣ እስማማለሁ ፣ አሁንም ጥቅም ላይ ይውላል ፣ ግን ያለ እሱ ፈጽሞ የማይቻል ከሆነ ብቻ። ስለዚህ፣ በ2020 የFC አውታረ መረብን በፈቃደኝነት አላሰማራም ፣ ሌሎች የበለጠ አስደሳች አማራጮች እንዳሉ አውቄ። ምንም እንኳን ለእያንዳንዳቸው ፣ FC ከሁሉም ገደቦች ጋር እኛ የምንፈልገው ብቻ ነው ብለው የሚያምኑ ሊኖሩ ይችላሉ - አልከራከርም ፣ ሁሉም ሰው የራሱ አስተያየት አለው። ሆኖም ግን, በእኔ አስተያየት በጣም የሚያስደስት መፍትሔ እንደ ሴፍ ያለ ኤስዲኤስ መጠቀም ነው.

ሴፍ እጅግ በጣም ብዙ የመጠባበቂያ አማራጮችን የያዘ የመረጃ ማከማቻ መፍትሄ እንድትገነቡ ይፈቅድልሃል፣ ከኮዶች ጋር እኩል ማጣራት (5 ወይም 6 ወረራ ተመሳሳይ ነው) በተለያዩ ዲስኮች ላይ ሙሉ መረጃ በማባዛት በማጠናቀቅ የዲስኮችን ቦታ ግምት ውስጥ ያስገባል። አገልጋዮች፣ እና አገልጋዮች በካቢኔ፣ ወዘተ.

Ceph ለመገንባት 3 ተጨማሪ አንጓዎች ያስፈልግዎታል። የማገጃ፣ የነገር እና የፋይል ማከማቻ አገልግሎቶችን በመጠቀም ከማከማቻው ጋር መስተጋብር በኔትወርኩ በኩል ይከናወናል። በእቅዱ ላይ ማከማቻ እንጨምር፡-

ማሳሰቢያ፡ በተጨማሪም hyperconverged compute nodes መስራት ይችላሉ - ይህ በአንድ መስቀለኛ መንገድ ላይ በርካታ ተግባራትን የማጣመር ጽንሰ-ሀሳብ ነው - ለምሳሌ ማከማቻ + ስሌት - ለሴፍ ማከማቻ ልዩ አንጓዎችን ሳይወስኑ። እኛ በገለጽነው የቦታ ማስያዣ ደረጃ ኤስዲኤስ መረጃ ስለሚይዝ ተመሳሳይ ስህተትን የሚቋቋም ዕቅድ እናገኛለን። ሆኖም ግን, hyperconverged አንጓዎች ሁልጊዜ ስምምነት ናቸው - የማከማቻ መስቀለኛ መንገድ መጀመሪያ በጨረፍታ (በእሱ ላይ ምንም ምናባዊ ማሽኖች ስለሌለ) ብቻ አየር ለማሞቅ አይደለም ጀምሮ - SDS አገልግሎት ላይ የሲፒዩ ሃብቶች (በእርግጥ, ሁሉንም ያደርጋል). የአንጓዎች, ዲስኮች, ወዘተ ውድቀቶች ከተከሰቱ በኋላ ማባዛትና ማገገም). ማለትም፣ ከማከማቻው ጋር ካዋህዱት የኮምፒዩት መስቀለኛ መንገድ የተወሰነውን ኃይል ታጣለህ።

እነዚህ ሁሉ ነገሮች በሆነ መንገድ መተዳደር አለባቸው - ማሽን ፣ አውታረ መረብ ፣ ቨርቹዋል ራውተር ፣ ወዘተ መፍጠር የምንችልበት አንድ ነገር እንፈልጋለን ይህንን ለማድረግ እንደ ዳሽቦርድ የሚሰራውን የቁጥጥር መስቀለኛ መንገድ አገልግሎት እንጨምራለን - የ ደንበኛው ከዚህ ፖርታል ጋር በ http/ https በኩል መገናኘት እና የሚፈልገውን ሁሉ ማድረግ ይችላል (በደንብ ማለት ይቻላል)።

በዚህም ምክንያት አሁን ስህተትን የሚቋቋም ሥርዓት አለን። ሁሉም የዚህ መሠረተ ልማት አካላት በሆነ መንገድ መተዳደር አለባቸው። ቀደም ሲል Opentack የፕሮጀክቶች ስብስብ እንደሆነ ተገልጿል, እያንዳንዱም የተለየ ተግባር ይሰጣል. እንደምናየው, ማዋቀር እና መቆጣጠር የሚያስፈልጋቸው ከበቂ በላይ ንጥረ ነገሮች አሉ. ዛሬ ስለ አውታረ መረቡ ክፍል እንነጋገራለን.

የኒውትሮን አርክቴክቸር

በOpenStack ውስጥ የቨርቹዋል ማሽን ወደቦችን ከጋራ L2 አውታረ መረብ ጋር የማገናኘት ፣በተለያዩ የኤል 2 ኔትወርኮች ላይ በሚገኙ ቪኤምኤዎች መካከል የትራፊክ ፍሰትን የማረጋገጥ ፣እንዲሁም ወደ ውጭ የማዘዋወር ፣እንደ NAT ፣floating IP ፣DHCP ፣ወዘተ ያሉ አገልግሎቶችን የመስጠት ሃላፊነት ያለው ኒውትሮን ነው።

በከፍተኛ ደረጃ የኔትወርክ አገልግሎት (መሠረታዊ ክፍል) አሠራር እንደሚከተለው ሊገለፅ ይችላል.

ቪኤም ሲጀምሩ የኔትወርክ አገልግሎት፡-

1. ለተወሰነ ቪኤም (ወይም ወደቦች) ወደብ ይፈጥራል እና ስለሱ የDHCP አገልግሎት ያሳውቃል፤
2. አዲስ ምናባዊ አውታረ መረብ መሳሪያ ተፈጥሯል (በሊብቪርት በኩል);
3. VM በደረጃ 1 ከተፈጠረው ወደብ (ዎች) ጋር ይገናኛል.

በሚገርም ሁኔታ የኒውትሮን ስራ ወደ ሊኑክስ ውስጥ ዘልቆ ለገባ ሰው ሁሉ በሚያውቃቸው መደበኛ ስልቶች ላይ የተመሰረተ ነው - የስም ቦታዎች፣ iptables፣ linux bridges፣ openvswitch፣ conntrack፣ ወዘተ.

ኒውትሮን የኤስዲኤን መቆጣጠሪያ እንዳልሆነ ወዲያውኑ ግልጽ ማድረግ አለበት.

ኒውትሮን በርካታ እርስ በርስ የተያያዙ ክፍሎችን ያቀፈ ነው፡-

Opentack-neutron-server በኤፒአይ በኩል ከተጠቃሚ ጥያቄዎች ጋር የሚሰራ ዴሞን ነው። ይህ ጋኔን ማንኛውንም የአውታረ መረብ ግንኙነቶች በመመዝገብ ላይ አይሳተፍም, ነገር ግን ለዚህ አስፈላጊ መረጃ ወደ ተሰኪዎቹ ያቀርባል, ከዚያም የሚፈለገውን የአውታረ መረብ አካል ያዋቅራል. በOpenStack nodes ላይ ያሉ የኒውትሮን ወኪሎች በኒውትሮን አገልጋይ ይመዘገባሉ።

ኒውትሮን-ሰርቨር በእውነቱ በፓይቶን የተጻፈ መተግበሪያ ነው ፣ ሁለት ክፍሎችን ያቀፈ።

• የ REST አገልግሎት
• የኒውትሮን ፕለጊን (ኮር/አገልግሎት)

የREST አገልግሎት ከሌሎች አካላት የኤፒአይ ጥሪዎችን ለመቀበል የተነደፈ ነው (ለምሳሌ አንዳንድ መረጃዎችን የመስጠት ጥያቄ፣ ወዘተ.)

ተሰኪዎች በኤፒአይ ጥያቄዎች ጊዜ የሚጠሩ ተሰኪ የሶፍትዌር ክፍሎች/ሞዱሎች ናቸው - ማለትም የአንድ አገልግሎት ባህሪ በእነሱ በኩል ነው። ፕለጊኖች በሁለት ይከፈላሉ - አገልግሎት እና ስር. እንደ ደንቡ፣ የፈረስ ፕለጊን በዋናነት በቪኤምኤስ መካከል ያለውን የአድራሻ ቦታ እና የኤል 2 ግንኙነቶችን የማስተዳደር ሃላፊነት አለበት፣ እና የአገልግሎት ተሰኪዎች እንደ VPN ወይም FW ያሉ ተጨማሪ ተግባራትን አስቀድመው ይሰጣሉ።

ዛሬ የሚገኙት ተሰኪዎች ዝርዝር ለምሳሌ ሊታዩ ይችላሉ። እዚህ

በርካታ የአገልግሎት ተሰኪዎች ሊኖሩ ይችላሉ፣ ግን አንድ የፈረስ ፕለጊን ብቻ ሊኖር ይችላል።

ክፈት-ኒውትሮን-ml2 መደበኛ የ Opentack root ተሰኪ ነው። ይህ ፕለጊን ሞጁል አርክቴክቸር አለው (ከቀድሞው የተለየ) እና የኔትወርክ አገልግሎቱን ከእሱ ጋር በተገናኙ ሾፌሮች ያዋቅራል። በእውነቱ OpenStack በአውታረ መረቡ ክፍል ውስጥ ያለውን ተለዋዋጭነት ስለሚሰጥ ተሰኪውን ትንሽ ቆይተን እንመለከታለን። የስር ፕለጊኑ ሊተካ ይችላል (ለምሳሌ፣ Contrail Networking እንደዚህ አይነት ምትክ ይሰራል)።

RPC አገልግሎት (rabbitmq-አገልጋይ) - የወረፋ አስተዳደር እና ከሌሎች የOpenStack አገልግሎቶች ጋር እንዲሁም በኔትወርክ አገልግሎት ወኪሎች መካከል መስተጋብር የሚሰጥ አገልግሎት።

የአውታረ መረብ ወኪሎች - በእያንዳንዱ መስቀለኛ መንገድ ውስጥ የሚገኙ ወኪሎች, በየትኛው የአውታረ መረብ አገልግሎቶች የተዋቀሩ ናቸው.

በርካታ አይነት ወኪሎች አሉ.

ዋናው ወኪል ነው L2 ወኪል. እነዚህ ወኪሎች የቁጥጥር ኖዶችን ጨምሮ በእያንዳንዱ ሃይፐርቫይዘሮች ላይ ይሰራሉ ​​(በተለይም ለተከራዮች ማንኛውንም አገልግሎት በሚሰጡ ሁሉም አንጓዎች ላይ) እና ዋና ተግባራቸው ቨርቹዋል ማሽኖችን ከአንድ የጋራ L2 አውታረ መረብ ጋር ማገናኘት ነው ፣ እና ማንኛውም ክስተቶች ሲከሰቱ ማንቂያዎችን ያመነጫሉ ( ለምሳሌ ወደቡን ማሰናከል/ማንቃት)።

ቀጣዩ, ምንም ያነሰ አስፈላጊ ወኪል ነው L3 ወኪል. በነባሪነት ይህ ወኪል በኔትወርክ መስቀለኛ መንገድ ላይ ብቻ ይሰራል (ብዙውን ጊዜ የአውታረ መረብ መስቀለኛ መንገድ ከቁጥጥር መስቀለኛ መንገድ ጋር ይጣመራል) እና በተከራይ አውታረ መረቦች መካከል (በሁለቱም በኔትወርኩ እና በሌሎች ተከራዮች አውታረ መረቦች መካከል) እና ለውጭው ዓለም ተደራሽ ነው ፣ NAT፣ እንዲሁም DHCP አገልግሎት)። ነገር ግን, DVR (የተከፋፈለ ራውተር) ሲጠቀሙ, የ L3 ፕለጊን አስፈላጊነት በስሌት ኖዶች ላይም ይታያል.

የL3 ወኪል ለእያንዳንዱ ተከራይ የራሱ የተገለሉ ኔትወርኮች ስብስብ እና ትራፊክን የሚያንቀሳቅሱ እና ለላብር 2 ኔትወርኮች መተላለፊያ አገልግሎት የሚሰጡ ምናባዊ ራውተሮችን ለማቅረብ የሊኑክስ ስም ቦታዎችን ይጠቀማል።

የውሂብ ጎታ - የአውታረ መረቦች ፣ ንዑስ መረቦች ፣ ወደቦች ፣ ገንዳዎች ፣ ወዘተ መለያዎች የውሂብ ጎታ።

በእርግጥ ኒውትሮን ከማንኛውም የአውታረ መረብ አካላት መፈጠር የኤፒአይ ጥያቄዎችን ይቀበላል ፣ጥያቄውን ያረጋግጣል እና በ RPC በኩል (አንዳንድ ተሰኪ ወይም ወኪል ከደረሰ) ወይም REST API (በኤስዲኤን ውስጥ የሚገናኝ ከሆነ) ወደ ተወካዮቹ (በፕለጊን) ያስተላልፋል የተጠየቀውን አገልግሎት ለማደራጀት አስፈላጊ መመሪያዎች .

አሁን ወደ የሙከራ መጫኛ እንሸጋገር (እንዴት እንደሚዘረጋ እና በውስጡ ምን እንደሚካተት ፣ በኋላ በተግባራዊው ክፍል ውስጥ እናያለን) እና እያንዳንዱ አካል የት እንደሚገኝ ይመልከቱ ።

(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 root ተሰኪ ነው እና ሞጁል አርክቴክቸር አለው።

የ ML2 ፕለጊን ቀዳሚው ሞኖሊቲክ መዋቅር ነበረው ፣ እሱም አይፈቅድም ፣ ለምሳሌ ፣ በአንድ ጭነት ውስጥ በርካታ ቴክኖሎጂዎች ድብልቅ። ለምሳሌ ሁለቱንም Openvswitch እና linuxbridge በተመሳሳይ ጊዜ መጠቀም አይችሉም - የመጀመሪያውንም ሆነ ሁለተኛው። በዚህ ምክንያት፣ ከሥነ ሕንፃው ጋር ያለው ML2 ተሰኪ ተፈጠረ።

ML2 ሁለት አካላት አሉት - ሁለት አይነት ሾፌሮች፡ አይነት ሾፌሮች እና ሜካኒዝም ነጂዎች።

ነጂዎችን ይተይቡ የአውታረ መረብ ግንኙነቶችን ለማደራጀት የሚያገለግሉ ቴክኖሎጂዎችን ይወስኑ ለምሳሌ VxLAN, VLAN, GRE. በተመሳሳይ ጊዜ አሽከርካሪው የተለያዩ ቴክኖሎጂዎችን መጠቀም ይፈቅዳል. ደረጃውን የጠበቀ ቴክኖሎጂ VxLAN ለተደራራቢ ኔትወርኮች እና ለ vlan ውጫዊ አውታረ መረቦች ማቀፊያ ነው።

ዓይነት አሽከርካሪዎች የሚከተሉትን የኔትወርክ ዓይነቶች ያካትታሉ:

ጠፍጣፋ - መለያ ሳይሰጥ አውታረ መረብ
ቪላን - መለያ የተሰጠው አውታረ መረብ
አካባቢያዊ - ለሁሉም-በአንድ ጭነቶች ልዩ የአውታረ መረብ አይነት (እንደዚህ ያሉ ጭነቶች ለገንቢዎች ወይም ለስልጠና ያስፈልጋሉ)
GRE - GRE ዋሻዎችን በመጠቀም ተደራቢ አውታረ መረብ
VxLAN - VxLAN ዋሻዎችን በመጠቀም ተደራቢ አውታረ መረብ

ሜካኒዝም ነጂዎች በአይነት ሾፌር ውስጥ የተገለጹትን ቴክኖሎጂዎች አደረጃጀት የሚያረጋግጡ መሳሪያዎችን ይግለጹ - ለምሳሌ openvswitch, sr-iov, opendaylight, OVN, ወዘተ.

በዚህ ሾፌር አተገባበር ላይ በመመስረት በኒውትሮን ቁጥጥር ስር ያሉ ወኪሎች ጥቅም ላይ ይውላሉ ወይም ከ L2 አውታረ መረቦች ማደራጀት ፣ ማዘዋወር ፣ ወዘተ ጋር የተያያዙ ሁሉንም ጉዳዮችን የሚንከባከበው ከውጭ SDN መቆጣጠሪያ ጋር ግንኙነቶች ጥቅም ላይ ይውላሉ።

ምሳሌ፡- ML2ን ከኦቪኤስ ጋር አብረን ከተጠቀምን በእያንዳንዱ ኦቪኤስን የሚያስተዳድር የL2 ወኪል ይጫናል። ነገር ግን፣ ለምሳሌ OVN ወይም OpenDayLight ን ከተጠቀምን የ OVS ቁጥጥር በእነርሱ ስልጣን ስር ይመጣል - ኒውትሮን በስር ፕለጊን በኩል ለተቆጣጣሪው ትዕዛዝ ይሰጣል እና አስቀድሞ የተነገረውን ያደርጋል።

በ Open vSwitch ላይ እንቦርሽ

በአሁኑ ጊዜ ከOpenStack ቁልፍ አካላት አንዱ Open vSwitch ነው።
እንደ Juniper Contrail ወይም Nokia Nuage ያለ ተጨማሪ አቅራቢ ኤስዲኤን ሳይኖር OpenStackን ሲጭኑ OVS የክላውድ ኔትዎርክ ዋና የኔትወርክ አካል ሲሆን ከ iptables፣ conntrack፣ የስም ቦታዎች ጋር ሙሉ ለሙሉ የተደራጁ ባለብዙ ተከራይ ተደራቢ ኔትወርኮችን እንዲያደራጁ ይፈቅድልዎታል። በተፈጥሮ, ይህ አካል ሊተካ ይችላል, ለምሳሌ, የሶስተኛ ወገን የባለቤትነት (ሻጭ) SDN መፍትሄዎችን ሲጠቀሙ.

OVS እንደ ምናባዊ ትራፊክ አስተላላፊ ሆኖ በምናባዊ አካባቢዎች ውስጥ ጥቅም ላይ እንዲውል የተቀየሰ ክፍት ምንጭ ሶፍትዌር ማብሪያ / ማጥፊያ ነው።

በአሁኑ ጊዜ ኦቪኤስ በጣም ጨዋ ተግባር አለው፣ እሱም እንደ QoS፣ LACP፣ VLAN፣ VxLAN፣ GENEVE፣ OpenFlow፣ DPDK፣ ወዘተ ያሉ ቴክኖሎጂዎችን ያካትታል።

ማሳሰቢያ፡ OVS መጀመሪያ ላይ በጣም ለተጫኑ የቴሌኮም ተግባራት እንደ ለስላሳ ማብሪያ / ማጥፊያ ተብሎ አልተፀነሰም እና የበለጠ የተነደፈው ባነሰ የመተላለፊያ ይዘት ለሚጠይቁ የአይቲ ተግባራት እንደ WEB አገልጋይ ወይም የፖስታ አገልጋይ። ነገር ግን ኦቪኤስ የበለጠ እየጎለበተ ሲሆን አሁን ያሉት የኦቪኤስ አተገባበር አፈፃፀሙን እና አቅሙን በእጅጉ አሻሽሏል ይህም ከፍተኛ ጭነት ባላቸው የቴሌኮም ኦፕሬተሮች እንዲጠቀም ያስችለዋል ለምሳሌ ለዲፒዲኬ ማፋጠን ድጋፍ ያለው የኦቪኤስ ትግበራ አለ።

ማወቅ ያለብዎት ሶስት አስፈላጊ የ OVS አካላት አሉ፡-

• የከርነል ሞጁል - ከቁጥጥር ኤለመንት በተቀበሉት ደንቦች ላይ በመመርኮዝ ትራፊክን የሚያስኬድ በከርነል ቦታ ውስጥ የሚገኝ አካል;
• vSwitch ዴሞን (ovs-vswitchd) የከርነል ሞጁሉን ፕሮግራም የማዘጋጀት ኃላፊነት ያለው በተጠቃሚ ቦታ የተጀመረ ሂደት ነው - ማለትም የመቀየሪያውን አሠራር ሎጂክ በቀጥታ ይወክላል።
• የውሂብ ጎታ አገልጋይ - በእያንዳንዱ አስተናጋጅ OVS ላይ የሚገኝ የአካባቢ ዳታቤዝ፣ አወቃቀሩ የተከማቸበት። የኤስዲኤን መቆጣጠሪያዎች የ OVSDB ፕሮቶኮልን በመጠቀም በዚህ ሞጁል በኩል መገናኘት ይችላሉ።

ይህ ሁሉ እንደ ovs-vsctl, ovs-appctl, ovs-ofctl, ወዘተ የመሳሰሉ የምርመራ እና የአስተዳደር መገልገያዎች ስብስብ ጋር አብሮ ይመጣል.

በአሁኑ ጊዜ የቴሌኮም ኦፕሬተሮች እንደ ኢፒሲ ፣ኤስቢሲ ፣ኤችኤልአር ፣ወዘተ ያሉ የቴሌኮም ኦፕሬተሮች የኔትዎርክ ተግባራትን ወደ እሱ ለማሸጋገር በቴሌኮም ኦፕሬተሮች በብዛት ጥቅም ላይ ይውላሉ። ከፍተኛ መጠን ያለው ትራፊክ (አሁን የትራፊክ መጠኖች በሰከንድ መቶ ጊጋቢትስ ይደርሳል)። በተፈጥሮ፣ እንዲህ ያለውን ትራፊክ በከርነል ቦታ ማሽከርከር (አስተላላፊው በነባሪነት ስለሚገኝ) ጥሩ ሀሳብ አይደለም። ስለዚህ፣ OVS ብዙውን ጊዜ ከኤንአይሲ ወደ ከርነል ወደ ሚያልፍ የተጠቃሚ ቦታ ለማስተላለፍ የዲፒዲኬ ማጣደፍ ቴክኖሎጂን በመጠቀም ሙሉ በሙሉ በተጠቃሚ ቦታ ላይ ይሰራጫል።

ማሳሰቢያ፡ ለቴሌኮም ተግባራት ለተዘረጋው ደመና፣ ከኮምፒዩት መስቀለኛ መንገድ ኦቪኤስን በማለፍ በቀጥታ ወደ መሳሪያ መቀየሪያ ትራፊክ ማውጣት ይቻላል። ለዚህ ዓላማ የ SR-IOV እና Passthrough ዘዴዎች ጥቅም ላይ ይውላሉ.

ይህ በእውነተኛ አቀማመጥ ላይ እንዴት ይሠራል?

ደህና ፣ አሁን ወደ ተግባራዊ ክፍል እንሂድ እና ሁሉም በተግባር እንዴት እንደሚሰራ ይመልከቱ።

መጀመሪያ፣ ቀላል የ Opentack ጭነትን እናሰማራ። ለሙከራዎች በእጄ ላይ የአገልጋዮች ስብስብ ስለሌለኝ ፕሮቶታይቡን በአንድ አካላዊ አገልጋይ ላይ ከምናባዊ ማሽኖች እንሰበስባለን። አዎን, በተፈጥሮ, እንዲህ ዓይነቱ መፍትሔ ለንግድ ዓላማዎች ተስማሚ አይደለም, ነገር ግን አውታረ መረቡ በ Opentack ውስጥ እንዴት እንደሚሰራ የሚያሳይ ምሳሌ ለማየት, እንዲህ ዓይነቱ ጭነት ለዓይኖች በቂ ነው. በተጨማሪም ፣ እንዲህ ዓይነቱ ጭነት ለሥልጠና ዓላማዎች የበለጠ ትኩረት የሚስብ ነው - ትራፊክን ስለሚይዙ ፣ ወዘተ.

ዋናውን ክፍል ብቻ ማየት ስለምንችል ብዙ ኔትወርኮችን መጠቀም አንችልም ነገር ግን ሁሉንም ሁለት አውታረ መረቦችን በመጠቀም ሁሉንም ነገር ማሳደግ አንችልም, እና በዚህ አቀማመጥ ውስጥ ያለው ሁለተኛው አውታረ መረብ የስር ደመና እና ዲ ኤን ኤስ አገልጋይን ለመድረስ ብቻ ጥቅም ላይ ይውላል. ለአሁን ውጫዊ አውታረ መረቦችን አንነካም - ይህ የተለየ ትልቅ ርዕስ ርዕስ ነው.

ስለዚህ, በቅደም ተከተል እንጀምር. በመጀመሪያ, ትንሽ ንድፈ ሐሳብ. TripleO (Openstack on Openstack) በመጠቀም Opentackን እንጭነዋለን። የTripleO ዋናው ነገር Opentack all-in-oneን (በአንድ መስቀለኛ መንገድ ላይ) ስንጭን ከክላውድ በታች ተብሎ የሚጠራውን እና ከዚያም የተዘረጋውን Opentack አቅም ተጠቅመን ኦቨር ክሎድ ተብሎ የሚጠራውን ለስራ የታሰበ Opentackን መጫን ነው። Undercloud በባህሪው ያለውን ችሎታ አካላዊ አገልጋዮችን (ባዶ ብረት) - ኢሪኒክ ፕሮጄክትን - የሂሳብ፣ የቁጥጥር እና የማከማቻ ኖዶችን ሚና የሚጫወቱ ሃይፐርቫይዘሮችን ለማቅረብ ይጠቀማል። ማለትም Opentackን ለማሰማራት የሶስተኛ ወገን መሳሪያዎችን አንጠቀምም - Opentackን በመጠቀም እናሰማራለን። መጫኑ እየገፋ ሲሄድ የበለጠ ግልጽ ይሆናል, ስለዚህ እዚያ ቆመን ወደ ፊት አንሄድም.

ማሳሰቢያ: በዚህ ጽሑፍ ውስጥ, ለቀላልነት, ለውስጣዊ Opentack አውታረ መረቦች የአውታረ መረብ ማግለል አልተጠቀምኩም, ነገር ግን ሁሉም ነገር አንድ አውታረ መረብ ብቻ በመጠቀም ነው የሚሰራው. ይሁን እንጂ የአውታረ መረብ መገለል መኖሩ ወይም አለመኖሩ የመፍትሄውን መሠረታዊ ተግባር አይጎዳውም - ሁሉም ነገር በተናጠል በሚጠቀሙበት ጊዜ በትክክል ይሰራል, ነገር ግን ትራፊክ በተመሳሳይ አውታረ መረብ ላይ ይፈስሳል. ለንግድ መጫኛ በተፈጥሮ የተለያዩ ቪላኖች እና መገናኛዎችን በመጠቀም ማግለል መጠቀም አስፈላጊ ነው. ለምሳሌ የሴፍ ማከማቻ አስተዳደር ትራፊክ እና የመረጃ ትራፊክ ራሱ (የማሽን ወደ ዲስኮች ወዘተ) ሲገለሉ የተለያዩ ሳብኔት (Storage Management and Storage) ይጠቀሙ እና ይሄ ትራፊክን በመከፋፈል መፍትሄውን የበለጠ ስህተት የሚቋቋም ለማድረግ ያስችላል። ፣ በተለያዩ ወደቦች ላይ ወይም የተለያዩ የQoS መገለጫዎችን ለተለያዩ ትራፊክ በመጠቀም የውሂብ ትራፊክ ምልክት ትራፊክን እንዳያሳጣ። በእኛ ሁኔታ, በተመሳሳይ አውታረ መረብ ውስጥ ይሄዳሉ እና በእውነቱ ይህ በምንም መልኩ አይገድበንም.

ማሳሰቢያ፡ በቨርቹዋል ማሽኖች ላይ ተመስርተን ቨርቹዋል ማሽኖችን በምናባዊ አከባቢ ውስጥ ስለምናሄድ መጀመሪያ የጎጆ ቨርቹዋል ማድረግን ማንቃት አለብን።

የጎጆ ቨርቹዋልነት እንደነቃ ወይም እንዳልሆነ ማረጋገጥ ይችላሉ፡-

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

N ፊደል ካዩ፣ በኔትወርኩ ላይ በሚያገኙት ማንኛውም መመሪያ መሰረት ለጎጆ ቨርቹዋልላይዜሽን ድጋፍን እናነቃለን። እንዲህ ያለ .

የሚከተለውን ወረዳ ከምናባዊ ማሽኖች መሰብሰብ አለብን።

በእኔ ሁኔታ, የወደፊቱ ተከላ አካል የሆኑትን ምናባዊ ማሽኖችን ለማገናኘት (እና 7ቱን አግኝቻለሁ, ነገር ግን ብዙ ሀብቶች ከሌሉዎት በ 4 ማግኘት ይችላሉ), OpenvSwitch ን ተጠቀምኩ. አንድ የኦቭስ ድልድይ ፈጠርኩ እና ቨርቹዋል ማሽኖችን በፖርት-ቡድኖች አገናኘሁ። ይህንን ለማድረግ የ xml ፋይልን እንደሚከተለው ፈጠርኩ፡-

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

ሶስት የወደብ ቡድኖች እዚህ ይታወቃሉ - ሁለት መዳረሻ እና አንድ ግንድ (የኋለኛው ለዲ ኤን ኤስ አገልጋይ ያስፈልግ ነበር ፣ ግን ያለሱ ማድረግ ይችላሉ ፣ ወይም በአስተናጋጅ ማሽን ላይ ይጫኑት - ለእርስዎ የበለጠ ምቹ)። በመቀጠል፣ ይህን አብነት በመጠቀም የኛን በvirsh net-define በኩል እናውጃለን፡-

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

አሁን የሃይፐርቫይዘር ወደብ አወቃቀሮችን እናስተካክላለን፡

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

ማስታወሻ፡ በዚህ ሁኔታ፡ በፖርት ovs-br1 ላይ ያለው አድራሻ የቪላን መለያ ስለሌለው ተደራሽ አይሆንም። ይህንን ለማስተካከል፣ sudo ovs-vsctl set port ovs-br1 tag=100 የሚለውን ትዕዛዝ መስጠት አለቦት። ነገር ግን፣ ከዳግም ማስነሳት በኋላ፣ ይህ መለያ ይጠፋል (አንድ ሰው እንዴት በቦታው እንዲቆይ ማድረግ እንዳለበት የሚያውቅ ከሆነ በጣም አመስጋኝ ነኝ)። ነገር ግን ይህ በጣም አስፈላጊ አይደለም, ምክንያቱም ይህ አድራሻ በሚጫንበት ጊዜ ብቻ ነው የምንፈልገው እና ​​Opentack ሙሉ በሙሉ ሲሰራጭ አያስፈልገንም.

በመቀጠል ፣ ከደመና በታች የሆነ ማሽን እንፈጥራለን-

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

በመጫን ጊዜ ሁሉንም አስፈላጊ መለኪያዎች ማለትም የማሽኑ ስም ፣ የይለፍ ቃሎች ፣ ተጠቃሚዎች ፣ ntp አገልጋዮች ፣ ወዘተ ያዘጋጃሉ ፣ ወዲያውኑ ወደቦችን ማዋቀር ይችላሉ ፣ ግን ለእኔ በግል ፣ ከተጫነ በኋላ ወደ ማሽኑ ለመግባት ቀላል ነው ። ኮንሶል እና አስፈላጊዎቹን ፋይሎች ያስተካክሉ. አስቀድሞ የተዘጋጀ ምስል ካለዎት ሊጠቀሙበት ይችላሉ ወይም ያደረኩትን ያድርጉ - አነስተኛውን የሴንቶስ 7 ምስል ያውርዱ እና ቪኤም ለመጫን ይጠቀሙበት።

በተሳካ ሁኔታ ከተጫኑ በኋላ, ከደመና በታች መጫን የሚችሉበት ቨርቹዋል ማሽን ሊኖርዎት ይገባል

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

በመጀመሪያ, ለመጫን ሂደት አስፈላጊ የሆኑትን መሳሪያዎች ይጫኑ:

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

ከደመና በታች መጫን

ቁልል ተጠቃሚ እንፈጥራለን ፣ የይለፍ ቃል አዘጋጅተናል ፣ ወደ ሱዶር እንጨምረዋለን እና የይለፍ ቃል ሳያስገባ በሱዶ በኩል ስርወ ትዕዛዞችን እንዲፈጽም እንሰጠዋለን ።

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_አስተናጋጅ ስም - የደመናው አገልጋይ ሙሉ ስም ፣ በዲ ኤን ኤስ አገልጋይ ላይ ካለው ግቤት ጋር መዛመድ አለበት።

local_ip - የአካባቢ የደመና አድራሻ ወደ አውታረ መረብ አቅርቦት

የአውታረ መረብ_ጌትዌይ - የደመና ኖዶች በሚጫኑበት ጊዜ ወደ ውጭው ዓለም እንደ መግቢያ በር ሆኖ የሚያገለግለው ተመሳሳይ የአካባቢ አድራሻ ፣ እንዲሁም ከአካባቢው ip ጋር ይዛመዳል።

የደመና_ሕዝብ_አስተናጋጅ - ውጫዊ የኤፒአይ አድራሻ ፣ ከአቅርቦት አውታረ መረብ ነፃ የሆነ ማንኛውም አድራሻ ተመድቧል

undercloud_admin_አስተናጋጅ የውስጥ ኤፒአይ አድራሻ፣ ከአቅራቢው አውታረመረብ ነፃ የሆነ ማንኛውም አድራሻ ተመድቧል

የደመና_ስም አገልጋዮች - የዲ ኤን ኤስ አገልጋይ

የአገልግሎት_ሰርተፍኬት ማመንጨት - ይህ መስመር አሁን ባለው ምሳሌ ውስጥ በጣም አስፈላጊ ነው, ምክንያቱም ወደ ውሸት ካላቀናበሩት በመጫን ጊዜ ስህተት ይደርስዎታል, ችግሩ በ Red Hat bug መከታተያ ላይ ተገልጿል.

የአካባቢ_በይነገጽ በአውታረ መረብ አቅርቦት ውስጥ በይነገጽ. ይህ በይነገጽ በደመና ስር በሚሰማራበት ጊዜ እንደገና ይዋቀራል፣ ስለዚህ ሁለት በይነገጾች በክላውድ ላይ ሊኖርዎት ይገባል - አንደኛው እሱን ለማግኘት ፣ ሁለተኛው ለማቅረብ።

local_mtu - MTU. የሙከራ ላብራቶሪ ስላለን እና በኦቪኤስ ማብሪያ ወደቦች ላይ MTU 1500 ስላለኝ በVxLAN ውስጥ የታሸጉ እሽጎች እንዲያልፉ ወደ 1450 ማቀናበሩ አስፈላጊ ነው።

አውታረ መረብ_cidr - አቅርቦት አውታረ መረብ

ጌጣጌጥ - የውጭ አውታረ መረብን ለመድረስ NAT ን በመጠቀም

masquerade_አውታረ መረብ - NATed የሚሆን አውታረ መረብ

dhcp_ጀምር - ከመጠን በላይ ደመና በሚሠራበት ጊዜ አድራሻዎች ወደ አንጓዎች የሚመደብበት የአድራሻ ገንዳ መነሻ አድራሻ

dhcp_መጨረሻ - ከመጠን በላይ ደመና በሚሠራበት ጊዜ አድራሻዎች ወደ አንጓዎች የሚመደብበት የአድራሻ ገንዳ የመጨረሻ አድራሻ

መፈተሽ_iprange - ለውስጣዊ እይታ አስፈላጊ የሆኑ የአድራሻ ገንዳዎች (ከላይ ካለው ገንዳ ጋር መደራረብ የለበትም)

የጊዜ መርሐግብር_ከፍተኛ_ሙከራዎች - ከመጠን በላይ ደመናን ለመጫን ከፍተኛው ሙከራዎች ብዛት (ከአንጓዎች ብዛት የበለጠ ወይም እኩል መሆን አለበት)

ፋይሉ ከተገለፀ በኋላ ከደመና በታች ለማሰማራት ትእዛዝ መስጠት ይችላሉ-

openstack undercloud install

በብረትዎ ላይ በመመስረት ሂደቱ ከ 10 እስከ 30 ደቂቃዎች ይወስዳል. በመጨረሻ የሚከተለውን ውጤት ማየት አለብዎት:

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

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

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

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

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

ይህ ውፅዓት በተሳካ ሁኔታ ከክላውድ በታች እንደጫኑ እና አሁን የደመናውን ሁኔታ መፈተሽ እና ከመጠን በላይ ደመናን መጫን መቀጠል እንደሚችሉ ይናገራል።

የ ifconfig ውፅዓትን ከተመለከቱ ፣ አዲስ የድልድይ በይነገጽ እንደታየ ያያሉ።

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

የደመና ማሰማራት አሁን በዚህ በይነገጽ በኩል ይከናወናል።

ከታች ካለው ውፅዓት ሁሉንም አገልግሎቶች በአንድ መስቀለኛ መንገድ ላይ እንዳለን ማየት ይችላሉ፡-

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

ከታች ያለው የደመና አውታረ መረብ ክፍል ውቅር ነው።

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

ከመጠን በላይ ደመና መጫን

በአሁኑ ጊዜ ከደመና በታች ብቻ ነው ያለን ፣ እና ደመና የሚሰበሰብባቸው በቂ አንጓዎች የሉንም። ስለዚህ, በመጀመሪያ, እኛ የምንፈልገውን ምናባዊ ማሽኖችን እናሰማራ. በማሰማራቱ ወቅት, undercloud እራሱ ስርዓተ ክወናውን እና አስፈላጊውን ሶፍትዌር በኦፕራሲዮኑ ማሽን ላይ ይጭናል - ማለትም ማሽኑን ሙሉ በሙሉ ማሰማራት አያስፈልገንም, ነገር ግን ለእሱ ዲስክ (ወይም ዲስኮች) ብቻ ይፍጠሩ እና ግቤቶችን ይወስናሉ - ይህ ማለት ነው. በእውነቱ, በላዩ ላይ ስርዓተ ክወና ሳይጫን ባዶ አገልጋይ እናገኛለን.

ከቨርቹዋል ማሽኖቻችን ዲስኮች ጋር ወደ አቃፊው እንሂድ እና የሚፈለገው መጠን ያላቸውን ዲስኮች እንፍጠር፡-

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

እንደ ስር እየሠራን ስለሆነ የመብቶች ችግር እንዳይፈጠር የእነዚህን ዲስኮች ባለቤት መለወጥ አለብን።

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

ማሳሰቢያ: እሱን ለማጥናት 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 አለ፣ይህም xml ፋይል በ/tmp/ ፎልደር ውስጥ የእያንዳንዱን ማሽን ገለጻ ያለው ፋይል ይፈጥራል፤ ካልጨመሩት ግን አይሆኑም። ምናባዊ ማሽኖችን መለየት ይችላል.

አሁን እነዚህን ሁሉ ማሽኖች በ virsh ውስጥ መግለፅ አለብን-

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

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

[root@hp-gen9 ~]#

አሁን ትንሽ ንኡስ - tripleO በተጫነ እና በውስጠ-እይታ ወቅት አገልጋዮችን ለማስተዳደር IPMI ይጠቀማል።

ኢንትሮስፔክሽን ለአንጓዎች ተጨማሪ አቅርቦት አስፈላጊ የሆኑትን መለኪያዎች ለማግኘት ሃርድዌርን የመፈተሽ ሂደት ነው። ከባዶ የብረት ሰርቨሮች ጋር ለመስራት የተነደፈውን አገልግሎት ኢሪኒክ በመጠቀም ኢንትሮሴክሽን ይካሄዳል።

ግን ችግሩ እዚህ አለ - የሃርድዌር IPMI አገልጋዮች የተለየ ወደብ (ወይም የጋራ ወደብ, ግን ይህ አስፈላጊ አይደለም), ከዚያ ምናባዊ ማሽኖች እንደዚህ አይነት ወደቦች የላቸውም. እዚህ vbmc የሚባል ክራንች ወደእኛ ይመጣል - የ IPMI ወደብ ለመምሰል የሚያስችል መገልገያ። ይህ ልዩነት በተለይ በ ESXI hypervisor ላይ እንደዚህ ያለ ላቦራቶሪ ለማዘጋጀት ለሚፈልጉ ሰዎች ትኩረት መስጠት ተገቢ ነው - እውነቱን ለመናገር የ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 ~]#

እኔ እንደማስበው የትእዛዝ አገባብ ያለ ማብራሪያ ግልጽ ነው. ነገር ግን፣ ለአሁን ሁሉም ክፍለ ጊዜዎቻችን በ DOWN ሁኔታ ላይ ናቸው። ወደ 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 ~]$

አንድ ተጨማሪ ነገር - የዲ ኤን ኤስ አገልጋይ ማከል ያስፈልግዎታል:

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

አሁን ለመግቢያ ትዕዛዙን መስጠት እንችላለን-

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


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

ከውጤቱ ላይ እንደሚታየው, ሁሉም ነገር ያለ ስህተቶች ተጠናቅቋል. ሁሉም አንጓዎች በሚገኙበት ሁኔታ ውስጥ መሆናቸውን እንፈትሽ፡

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

መስቀለኛ መንገዶቹ በተለየ ሁኔታ ውስጥ ከሆኑ፣ አብዛኛውን ጊዜ ሊተዳደሩ የሚችሉ፣ ከዚያ የሆነ ችግር ተፈጥሯል እና ምዝግብ ማስታወሻውን መመልከት እና ይህ ለምን እንደተከሰተ ማወቅ ያስፈልግዎታል። በዚህ ሁኔታ ቨርቹዋልላይዜሽን እየተጠቀምን እንደሆነ እና ከቨርቹዋል ማሽኖች ወይም vbmc አጠቃቀም ጋር የተያያዙ ስህተቶች ሊኖሩ እንደሚችሉ ያስታውሱ።

በመቀጠል የትኛው መስቀለኛ መንገድ የትኛውን ተግባር እንደሚፈጽም መጠቆም አለብን - ማለትም ፣ መስቀለኛ መንገዱ የሚዘረጋበትን መገለጫ ያመልክቱ።

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

ለእያንዳንዱ መስቀለኛ መንገድ መገለጫውን ይግለጹ፡

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

ሁሉንም ነገር በትክክል እንደሰራን እንረጋግጥ፡-

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

ሁሉም ነገር ትክክል ከሆነ ፣ ከመጠን በላይ ደመናን ለማሰማራት ትእዛዝ እንሰጣለን-

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

በእውነተኛ መጫኛ ውስጥ, የተበጁ አብነቶች በተፈጥሮ ጥቅም ላይ ይውላሉ, በእኛ ሁኔታ ይህ ሂደቱን በእጅጉ ያወሳስበዋል, ምክንያቱም በአብነት ውስጥ ያለው እያንዳንዱ አርትዖት መገለጽ አለበት. ቀደም ሲል እንደተፃፈው, እንዴት እንደሚሰራ ለማየት ቀላል መጫኛ እንኳን በቂ ይሆናል.

ማሳሰቢያ፡--libvirt-type qemu ተለዋዋጭ በዚህ አጋጣሚ አስፈላጊ ነው፣ምክንያቱም የጎጆ ቨርችላላይዜሽን እንጠቀማለን። አለበለዚያ, ምናባዊ ማሽኖችን ማሄድ አይችሉም.

አሁን አንድ ሰዓት ያህል አለዎት ወይም ምናልባት ተጨማሪ (እንደ ሃርድዌር ችሎታዎች ላይ በመመስረት) እና ከዚህ ጊዜ በኋላ የሚከተለውን መልእክት እንደሚመለከቱ ተስፋ ማድረግ ይችላሉ-

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

 Stack overcloud CREATE_COMPLETE 

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

አሁን ማጥናት፣ መሞከር፣ ወዘተ የምትችልበት የተከፈተ ስታክ ሙሉ ለሙሉ ማለት ይቻላል እትም አለህ።

ሁሉም ነገር በትክክል እየሰራ መሆኑን እንፈትሽ። በተጠቃሚው የቤት ማውጫ ውስጥ ሁለት ፋይሎች አሉ - አንድ stackrc (ከክላውድ በታች ለማስተዳደር) እና ሁለተኛው overcloudrc (overcloudን ለማስተዳደር)። ለማረጋገጫ አስፈላጊ መረጃዎችን ስለያዙ እነዚህ ፋይሎች እንደ ምንጭ መገለጽ አለባቸው።

(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 አውታረመረብ ላይ በተለያዩ hypervisors ላይ ሁለት ማሽኖች
• በተለያዩ አውታረ መረቦች ላይ ያሉ ሁለት ማሽኖች (የአውታረ መረብ ስርወ-ስርጭት)

በውጫዊ አውታረመረብ በኩል ወደ ውጫዊው ዓለም መዳረሻ ያላቸው ጉዳዮች ፣ ተንሳፋፊ አድራሻዎችን በመጠቀም ፣ እንዲሁም የተከፋፈሉ መንገዶችን ፣ በሚቀጥለው ጊዜ እንመለከታለን ፣ አሁን በውስጣዊ ትራፊክ ላይ እናተኩራለን ።

ለማጣራት፣ የሚከተለውን ሥዕላዊ መግለጫ አንድ ላይ እናስቀምጥ፡-

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                                        |

(overcloud) [stack@undercloud ~]$
ማሽኖች vm-1 እና vm-3 በ compute-0፣ ማሽኖች vm-2 እና vm-4 በ node compute-1 ላይ ይገኛሉ።

በተጨማሪም፣ በተገለጹት አውታረ መረቦች መካከል ማዘዋወርን ለማንቃት ምናባዊ ራውተር ተፈጥሯል፡-

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

ራውተሩ ሁለት ምናባዊ ወደቦች አሉት፣ እነሱም ለአውታረ መረቦች መግቢያዎች ሆነው ያገለግላሉ።

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

ነገር ግን የትራፊክ ፍሰቱ እንዴት እንደሚካሄድ ከማየታችን በፊት፣ አሁን ያለንበትን የቁጥጥር መስቀለኛ መንገድ (ይህም የአውታረ መረብ መስቀለኛ መንገድ ነው) እና በኮምፒተር መስቀለኛ መንገድ ላይ ያለውን እንመልከት። በስሌት መስቀለኛ መንገድ እንጀምር።

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

በአሁኑ ጊዜ መስቀለኛ መንገድ ሶስት ኦቭስ ድልድዮች አሉት - br-int, br-tun, br-ex. በመካከላቸው, እንደምናየው, የመገናኛዎች ስብስብ አለ. ለግንዛቤ ቀላልነት፣ እነዚህን ሁሉ በይነገጾች በሥዕላዊ መግለጫው ላይ እንይ እና ምን እንደሚፈጠር እንይ።

የ VxLAN ዋሻዎች የሚነሱባቸውን አድራሻዎች ስንመለከት፣ አንድ ዋሻ ወደ ስሌት-1 (192.168.255.26) ሲነሳ፣ ሁለተኛው መሿለኪያ ወደ መቆጣጠሪያ-1 (192.168.255.15) እንደሚመለከት መረዳት ይቻላል። ግን በጣም የሚያስደንቀው ነገር br-ex አካላዊ መገናኛዎች የሉትም ፣ እና ምን ፍሰቶች እንደተዋቀሩ ከተመለከቱ ፣ ይህ ድልድይ በአሁኑ ጊዜ ትራፊክን ብቻ ሊጥል እንደሚችል ማየት ይችላሉ።

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

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

ከውጤቱ ላይ እንደሚታየው አድራሻው በቀጥታ ወደ አካላዊ ወደብ እንጂ ወደ ምናባዊ ድልድይ በይነገጽ አይደለም.

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

በመጀመሪያው ህግ መሰረት, ከ phy-br-ex ወደብ የመጣው ሁሉም ነገር መጣል አለበት.
በእውነቱ፣ በአሁኑ ጊዜ ትራፊክ ወደዚህ ድልድይ የሚመጣበት ሌላ ምንም ቦታ የለም ከዚህ በይነገጽ (ከ br-int ጋር ያለው በይነገጽ)፣ እና በጠብታዎቹ ስንገመግም፣ BUM ትራፊክ ቀድሞውኑ ወደ ድልድዩ ገብቷል።

ማለትም፣ ትራፊክ ይህንን መስቀለኛ መንገድ ሊተው የሚችለው በVxLAN ዋሻ በኩል ብቻ እንጂ ሌላ ምንም አይደለም። ነገር ግን፣ DVR ን ካበሩት፣ ሁኔታው ​​ይቀየራል፣ ነገር ግን ያንን ሌላ ጊዜ እናስተናግዳለን። የአውታረ መረብ ማግለል ሲጠቀሙ ለምሳሌ vlansን በመጠቀም በ vlan 3 ውስጥ አንድ L0 በይነገጽ አይኖርዎትም ፣ ግን ብዙ በይነገሮች። ሆኖም፣ የVxLAN ትራፊክ መስቀለኛ መንገድን በተመሳሳይ መንገድ ይተዋል፣ ነገር ግን በተወሰነ የቪላን አይነት ውስጥም ተቀርጿል።

የስሌት መስቀለኛ መንገድን አስተካክለናል, ወደ መቆጣጠሪያ መስቀለኛ መንገድ እንሂድ.

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

እንደ እውነቱ ከሆነ, ሁሉም ነገር አንድ ነው ማለት እንችላለን, ነገር ግን የአይፒ አድራሻው በአካላዊ በይነገጽ ላይ ሳይሆን በምናባዊ ድልድይ ላይ ነው. ይህ የሚደረገው ይህ ወደብ ትራፊክ ወደ ውጭው ዓለም የሚወጣበት ወደብ ስለሆነ ነው።

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

ይህ ወደብ ከብሪ-ኤክስ ድልድይ ጋር የተሳሰረ ነው እና በላዩ ላይ ምንም የቪላን መለያዎች ስለሌለ ይህ ወደብ ሁሉም vlans የተፈቀደበት ግንድ ወደብ ነው ፣ አሁን ትራፊክ ያለ መለያ ወደ ውጭ ይወጣል ፣ በ vlan-id 0 እንደተመለከተው ከላይ ውፅዓት.

በአሁኑ ጊዜ ሁሉም ነገር ከኮምፒዩተር መስቀለኛ መንገድ ጋር ተመሳሳይ ነው - ተመሳሳይ ድልድዮች ፣ ተመሳሳይ ዋሻዎች ወደ ሁለት ስሌት ኖዶች ይሄዳሉ።

በዚህ ጽሑፍ ውስጥ የማጠራቀሚያ አንጓዎችን አንመለከትም ፣ ግን ለመረዳት የእነዚህ አንጓዎች የአውታረ መረብ ክፍል እስከ ውርደት ድረስ ባናል ነው ማለት ያስፈልጋል ። በእኛ ሁኔታ አንድ የአይ ፒ አድራሻ ያለው አንድ አካላዊ ወደብ (eth0) ብቻ አለ እና ያ ነው። ምንም የ VxLAN ዋሻዎች, መሿለኪያ ድልድዮች, ወዘተ የለም - ምንም ፋይዳ ስለሌለ ምንም ኦቭስ የለም. የአውታረ መረብ መነጠልን በሚጠቀሙበት ጊዜ ይህ መስቀለኛ መንገድ ሁለት በይነገጾች ይኖረዋል (አካላዊ ወደቦች ፣ ቦዲኒ ፣ ወይም ሁለት ቭላኖች ብቻ - ምንም አይደለም - በሚፈልጉት ላይ የተመሠረተ ነው) - አንዱ ለአስተዳደር ፣ ሁለተኛው ለትራፊክ (ወደ ቪኤም ዲስክ መጻፍ)። ፣ ከዲስክ ማንበብ ፣ ወዘተ.)

ምንም አይነት አገልግሎት በማይኖርበት ጊዜ በመስቀለኛ መንገድ ላይ ምን እንዳለን አውቀናል. አሁን 4 ምናባዊ ማሽኖችን እናስጀምር እና ከላይ የተገለፀው እቅድ እንዴት እንደሚቀየር እንይ - ወደቦች ፣ ምናባዊ ራውተሮች ፣ ወዘተ ሊኖረን ይገባል ።

እስካሁን ድረስ የእኛ አውታረ መረብ ይህንን ይመስላል።

በእያንዳንዱ የኮምፒተር መስቀለኛ መንገድ ላይ ሁለት ምናባዊ ማሽኖች አሉን. Compute-0ን እንደ ምሳሌ በመጠቀም ሁሉም ነገር እንዴት እንደሚካተት እንይ።

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

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

ማሽኑ አንድ ምናባዊ በይነገጽ ብቻ ነው ያለው - tap95d96a75-a0:

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

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

ይህ በይነገጽ በሊኑክስ ድልድይ ውስጥ ይታያል-

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

ከውጤቱ እንደሚታየው በድልድዩ ውስጥ ሁለት መገናኛዎች ብቻ አሉ - tap95d96a75-a0 እና qvb95d96a75-a0።

እዚህ በOpenStack ውስጥ ባሉ የቨርቹዋል አውታረመረብ መሳሪያዎች ዓይነቶች ላይ ትንሽ መኖር ጠቃሚ ነው፡-
vtap - ምናባዊ በይነገጽ ከአብነት (VM) ጋር ተያይዟል
qbr - ሊኑክስ ድልድይ
qvb እና qvo - ከሊኑክስ ድልድይ እና ክፈት vSwitch ድልድይ ጋር የተገናኙ vEth ጥንድ
br-int፣ br-tun፣ br-vlan - የvSwitch ድልድዮችን ክፈት
patch-, int-br-, phy-br- - ድልድዮችን የሚያገናኙ የvSwitch patch በይነገጾችን ክፈት
qg, qr, ha, fg, sg - ከኦቪኤስ ጋር ለመገናኘት በምናባዊ መሳሪያዎች የሚጠቀሙባቸውን 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 በውጤቱ ውስጥ ይታያል። ይህ ወደ ሁለተኛው ምናባዊ ማሽን ወደብ ነው. በውጤቱም ፣ የእኛ ሥዕላዊ መግለጫ አሁን ይህንን ይመስላል።

ትኩረት የሚስብ አንባቢን ወዲያውኑ ሊስብ የሚገባው ጥያቄ - በቨርቹዋል ማሽን ወደብ እና በኦቪኤስ ወደብ መካከል ያለው የሊኑክስ ድልድይ ምንድነው? እውነታው ግን ማሽኑን ለመጠበቅ, የደህንነት ቡድኖች ጥቅም ላይ ይውላሉ, ይህም ከ iptables የበለጠ አይደለም. OVS ከ iptables ጋር አይሰራም, ስለዚህ ይህ "ክራች" ተፈጠረ. ነገር ግን፣ ጊዜው ያለፈበት እየሆነ መጥቷል - በአዲስ እትሞች ውስጥ በኮንትራክክ እየተተካ ነው።

ማለትም ፣ በመጨረሻም ፣ እቅዱ እንደዚህ ይመስላል

በአንድ L2 አውታረመረብ ላይ በአንድ ሃይፐርቫይዘር ላይ ሁለት ማሽኖች

እነዚህ ሁለቱ ቪኤምዎች በአንድ 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 አውታረመረብ ላይ በተለያዩ hypervisors ላይ ሁለት ማሽኖች

አሁን ትራፊክ በሁለት ማሽኖች መካከል በአንድ L2 አውታረመረብ መካከል እንዴት እንደሚሄድ እንይ ፣ ግን በተለያዩ hypervisors ላይ ይገኛል። እውነቱን ለመናገር፣ ምንም ነገር ብዙም አይለወጥም፣ በሃይፐርቫይዘሮች መካከል ያለው ትራፊክ በvxlan መሿለኪያ ውስጥ ብቻ ያልፋል። አንድ ምሳሌ እንመልከት።

ትራፊክ የምንመለከትባቸው የቨርቹዋል ማሽኖች አድራሻዎች፡-

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

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

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

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

የማስተላለፊያ ጠረጴዛውን በ br-int on compute-0 ውስጥ እንመለከታለን፡-

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

ይህ patch-tun ነው - ማለትም በbr-tun ውስጥ ያለው በይነገጽ። እሽጉ በbr-tun ላይ ምን እንደሚፈጠር እንይ፡-

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

ፓኬቱ በVxLAN ታሽጎ ወደብ 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 ~]$

ይህ compute-1 ላይ vxlan ዋሻ ነው፡-

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

ወደ ስሌት-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 ~]$ 

ማክ በ br-int የማስተላለፊያ ሠንጠረዥ ውስጥ በ compute-1 ላይ ይገኛል፣ እና ከላይ ካለው ውፅዓት እንደሚታየው፣ ወደብ 2 በኩል ይታያል፣ እሱም ወደብ ወደብ - ብሩ:

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

እንግዲህ፣ በ br-int በ compute-1 ውስጥ የመድረሻ ፓፒ እንዳለ እናያለን፡-

[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 አለ።

በምናባዊ መሠረተ ልማት ላይ ለመማር Opentackን ማሰማራቱ ውበቱ በቀላሉ በሃይፐርቫይዘሮች መካከል ያለውን ትራፊክ ለመያዝ እና በእሱ ላይ ምን እየተፈጠረ እንዳለ ለማየት መቻል ነው። አሁን የምናደርገው ይህ ነው፣ tcpdump በ vnet port ላይ ወደ ስሌት-0 ያሂዱ፡

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

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

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

የመጀመሪያው መስመር እንደሚያሳየው ፓቴክ ከአድራሻ 10.0.1.85 ወደ አድራሻው 10.0.1.88 (ICMP ትራፊክ) ይሄዳል እና በ VxLAN ፓኬት ከ vni 22 ጋር ተጠቅልሎ እና ፓኬጁ ከአስተናጋጅ 192.168.255.19 (ኮምፕዩተር-0) ለማስተናገድ 192.168.255.26 .1 ( ስሌት-XNUMX). VNI በኦቭኤስ ከተጠቀሰው ጋር እንደሚዛመድ ማረጋገጥ እንችላለን።

ወደዚህ መስመር ድርጊቶች=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2 እንመለስ። 0x16 በሄክሳዴሲማል ቁጥር ስርዓት vni ነው። ይህን ቁጥር ወደ 16ኛው ስርዓት እንለውጠው፡-

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 አድራሻ በመቆጣጠሪያ መስቀለኛ መንገድ ላይ ባለው የብሬ-ኢንት ማስተላለፊያ ጠረጴዛ ላይ መሆን እንዳለበት ግልጽ ነው። እዚያ እንዳለ እና የት እንደሚታይ እንፈትሽ፡-

[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 ይታያል። በ Opentack ውስጥ ወደ ቨርቹዋል ወደቦች ዝርዝር ከተመለስን የዚህ አይነት ወደብ የተለያዩ ምናባዊ መሳሪያዎችን ከኦቪኤስ ጋር ለማገናኘት ይጠቅማል። ይበልጥ ትክክለኛ ለመሆን፣ 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 ~]$ 

እስከ ሦስት ቅጂዎች. ነገር ግን በስሞቹ በመመዘን የእያንዳንዳቸውን ዓላማ መገመት ትችላለህ። በኋላ መታወቂያ 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 ያለው መሿለኪያ የሚከተሉትን ድርጊቶች=ጭነት፡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 (compute-0) 192.168.255.15 (መቆጣጠሪያ-1) ከ vni 22 ጋር ለማስተናገድ የቪክስላን ፓኬት ነው፣ በውስጡም የICMP ፓኬት ከአስተናጋጅ 10.0.1.85 10.0.2.8ን ለማስተናገድ የታሸገ ነው። ከላይ እንዳሰላነው፣ vni በውጤቱ ላይ ካየነው ጋር ይዛመዳል።

ሁለተኛው ፓኬት ከአስተናጋጅ 192.168.255.15 (ቁጥጥር-1) 192.168.255.26 (compute-1) ከ vni 99 ጋር የሚያስተናግድ የvxlan ፓኬት ሲሆን በውስጡም የICMP ፓኬት ከአስተናጋጅ 10.0.1.85 10.0.2.8ን ለማስተናገድ የታሸገ ነው። ከላይ እንዳሰላነው፣ vni በውጤቱ ላይ ካየነው ጋር ይዛመዳል።

የሚቀጥሉት ሁለት እሽጎች የመመለሻ ትራፊክ ከ 10.0.2.8 10.0.1.85 አይደለም.

ማለትም ፣ በመጨረሻ የሚከተለውን የቁጥጥር መስቀለኛ መንገድ አግኝተናል።

ያ ይመስላል? ስለ ሁለት የስም ቦታዎች ረስተናል፡-

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

ስለ ደመና መድረክ አርክቴክቸር ስንነጋገር፣ ማሽኖች አድራሻዎችን ከDHCP አገልጋይ በቀጥታ ቢቀበሉ ጥሩ ነው። እነዚህ ለሁለቱ አውታረ መረቦች 10.0.1.0/24 እና 10.0.2.0/24 ሁለት የDHCP አገልጋዮች ናቸው።

ይህ እውነት መሆኑን እንፈትሽ። በዚህ የስም ቦታ ውስጥ አንድ አድራሻ ብቻ አለ - 10.0.1.1 - የDHCP አገልጋይ ራሱ አድራሻ እና በ br-int ውስጥም ተካትቷል፡

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

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

qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 በስማቸው የያዙ ሂደቶች በቁጥጥር መስቀለኛ መንገድ ላይ እንዳሉ እንይ፡-

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

እንደዚህ አይነት ሂደት አለ እና ከላይ ባለው ውጤት ላይ በቀረበው መረጃ ላይ በመመስረት, ለምሳሌ, በአሁኑ ጊዜ ለኪራይ ያለንን ማየት እንችላለን:

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

በዚህ ምክንያት በመቆጣጠሪያ መስቀለኛ መንገድ ላይ የሚከተሉትን የአገልግሎቶች ስብስብ እናገኛለን:

ደህና ፣ ልብ ይበሉ - ይህ 4 ማሽኖች ፣ 2 የውስጥ አውታረ መረቦች እና አንድ ምናባዊ ራውተር ብቻ ነው ... አሁን እዚህ ውጫዊ አውታረ መረቦች የሉንም ፣ የተለያዩ ፕሮጄክቶች ፣ እያንዳንዳቸው የራሳቸው አውታረ መረቦች (ተደራቢ) ያላቸው ፣ እና እኛ አለን ። የተከፋፈለው ራውተር ጠፍቷል፣ እና በመጨረሻ፣ በሙከራ አግዳሚ ወንበሩ ውስጥ አንድ የቁጥጥር መስቀለኛ መንገድ ብቻ ነበር (ለስህተት መቻቻል የሶስት አንጓዎች ምልአተ ጉባኤ መሆን አለበት።) በንግዱ ውስጥ ሁሉም ነገር “ትንሽ” የበለጠ የተወሳሰበ መሆኑ ምክንያታዊ ነው ፣ ግን በዚህ ቀላል ምሳሌ ውስጥ እንዴት እንደሚሰራ እንረዳለን - 3 ወይም 300 የስም ቦታዎች ካለዎት በእርግጥ አስፈላጊ ነው ፣ ግን ከኦፕሬሽኑ አሠራር አንፃር ሙሉ መዋቅር፣ ምንም ነገር ብዙም አይለወጥም... ምንም እንኳን አንዳንድ ሻጭ SDNን ባይሰኩም። ግን ያ ፈጽሞ የተለየ ታሪክ ነው።

አስደሳች ነበር ብዬ ተስፋ አደርጋለሁ። አስተያየቶች/ተጨማሪዎች ካሉዎት ወይም የሆነ ቦታ ላይ በትክክል የዋሸሁ ከሆነ (እኔ ሰው ነኝ እና የእኔ አስተያየት ሁል ጊዜ ተጨባጭ ይሆናል) - መስተካከል ያለበትን ይፃፉ / የሚጨመሩትን - ሁሉንም ነገር እናስተካክላለን / እንጨምራለን.

በማጠቃለያው Opentackን (ሁለቱንም ቫኒላ እና ሻጭ) ከ VMWare ከደመናው መፍትሄ ጋር ስለማነፃፀር ጥቂት ቃላት ማለት እፈልጋለሁ - ይህንን ጥያቄ ላለፉት ሁለት ዓመታት ብዙ ጊዜ ጠይቄያለሁ እና እውነቱን ለመናገር ፣ እኔ ነኝ ቀድሞውኑ ደክሞታል, ግን አሁንም. በእኔ አስተያየት እነዚህን ሁለት መፍትሄዎች ማነፃፀር በጣም ከባድ ነው, ነገር ግን በእርግጠኝነት በሁለቱም መፍትሄዎች ውስጥ ጉድለቶች እንዳሉ መናገር እንችላለን እና አንድ መፍትሄ በሚመርጡበት ጊዜ ጥቅሞቹን እና ጉዳቶቹን ማመዛዘን ያስፈልግዎታል.

OpenStack በማህበረሰብ የሚመራ መፍትሄ ከሆነ VMWare የፈለገውን ብቻ የማድረግ መብት አለው (ማንበብ - ትርፋማ የሚሆነውን) እና ይህ ምክንያታዊ ነው - ምክንያቱም ከደንበኞቹ ገንዘብ ለማግኘት የሚውል የንግድ ኩባንያ ነው። ግን አንድ ትልቅ እና ወፍራም አለ ነገር ግን - ከ OpenStack መውጣት ይችላሉ ፣ ለምሳሌ ከኖኪያ ፣ እና በትንሽ ወጭ ወደ መፍትሄ ለምሳሌ ፣ Juniper (Contrail Cloud) ፣ ግን ከ VMWare መውጣት የመቻል ዕድሉ ከፍተኛ ነው። . ለእኔ፣ እነዚህ ሁለት መፍትሄዎች ይህን ይመስላሉ - Opentack (አቅራቢ) የተቀመጡበት ቀላል ቤት ነው፣ ነገር ግን ቁልፍ አለህ እና በማንኛውም ጊዜ መተው ትችላለህ። VMWare ወርቃማ ቤት ነው, ባለቤቱ የቤቱን ቁልፍ አለው እና ብዙ ያስወጣዎታል.

የመጀመሪያውን ወይም ሁለተኛውን አላስተዋውቅም - የሚፈልጉትን ይምረጡ። ነገር ግን እንደዚህ አይነት ምርጫ ቢኖረኝ ሁለቱንም መፍትሄዎች እመርጣለሁ - VMWare ለ IT ደመና (ዝቅተኛ ጭነት, ቀላል አስተዳደር), OpenStack ከአንዳንድ አቅራቢዎች (Nokia እና Juniper በጣም ጥሩ የማዞሪያ መፍትሄዎችን ያቀርባሉ) - ለቴሌኮም ደመና. Opentack ን ለንፁህ አይቲ አልጠቀምም - ድንቢጦችን በመድፍ እንደመተኮስ ነው፣ ነገር ግን እሱን ከመጠቀም ሌላ ምንም ዓይነት ተቃርኖ አላየሁም። ሆኖም VMWareን በቴሌኮም መጠቀም በፎርድ ራፕተር ውስጥ የተቀጠቀጠ ድንጋይ እንደመጎተት ነው - ከውጪ ቆንጆ ነው፣ ነገር ግን አሽከርካሪው ከአንድ ጊዜ ይልቅ 10 ጉዞዎችን ማድረግ አለበት።

በእኔ አስተያየት የ VMWare ትልቁ ኪሳራ ሙሉ በሙሉ ዝግነቱ ነው - ኩባንያው እንዴት እንደሚሰራ ምንም መረጃ አይሰጥዎትም ፣ ለምሳሌ ፣ vSAN ወይም በሃይፐርቪዘር ከርነል ውስጥ ስላለው - በቀላሉ ለእሱ አትራፊ አይደለም - ማለትም ፣ እርስዎ ይረዱዎታል። በVMWare ውስጥ ኤክስፐርት አትሁኑ - ያለ ሻጭ ድጋፍ፣ አንተ ጥፋተኛ ነህ (በጣም ብዙ ጊዜ በጥቃቅን ጥያቄዎች የሚደነግጡ የVMWare ባለሙያዎችን አገኛለሁ። ለእኔ VMWare ኮፈኑን ተቆልፎ መኪና እየገዛ ነው - አዎ፣ የጊዜ ቀበቶውን የሚቀይሩ ልዩ ባለሙያዎች ሊኖሩዎት ይችላሉ፣ ግን ይህንን መፍትሄ የሸጠው ብቻ ኮፈኑን ሊከፍት ይችላል። በግለሰብ ደረጃ, እኔ ልስማማባቸው የማልችላቸውን መፍትሄዎች አልወድም. ከሽፋን ስር መሄድ አይጠበቅብህም ትላለህ። አዎ, ይህ ይቻላል, ነገር ግን ከ20-30 ቨርቹዋል ማሽኖች, 40-50 ኔትወርኮች, ግማሹ ወደ ውጭ መውጣት የሚፈልግ ትልቅ ተግባር በደመና ውስጥ መሰብሰብ ሲያስፈልግህ እመለከትሃለሁ, እና ሁለተኛው አጋማሽ ይጠይቃል. SR-IOV ማጣደፍ፣ ያለበለዚያ ከእነዚህ መኪኖች ውስጥ ሁለት ደርዘን ተጨማሪ ያስፈልግዎታል - አለበለዚያ አፈፃፀሙ በቂ አይሆንም።

ሌሎች የአመለካከት ነጥቦች አሉ, ስለዚህ እርስዎ ብቻ ምን እንደሚመርጡ መወሰን ይችላሉ, እና ከሁሉም በላይ, ለእርስዎ ምርጫ ተጠያቂ ይሆናሉ. ይህ የኔ አስተያየት ነው - ቢያንስ 4 ምርቶችን አይቶ የነካ ሰው - ኖኪያ፣ ጁኒፐር፣ ቀይ ኮፍያ እና ቪኤምዋሬ። ማለትም እኔ የማወዳደር ነገር አለኝ።

ምንጭ: hab.com