Ievads mākoņa infrastruktūras tīkla daļā

Ievads mākoņa infrastruktūras tīkla daļā

MākoņdatoÅ”ana arvien dziļāk iekļūst mÅ«su dzÄ«vē, un, iespējams, nav neviena cilvēka, kurÅ” kaut reizi nebÅ«tu izmantojis mākoņpakalpojumus. Taču, kas Ä«sti ir mākonis un kā tas darbojas, pat idejas lÄ«menÄ« zina retais. 5G jau kļūst par realitāti, un telekomunikāciju infrastruktÅ«ra sāk pāriet no polu risinājumiem uz mākoņa risinājumiem, tāpat kā tad, kad tā no pilnÄ«bā aparatÅ«ras risinājumiem pārcēlās uz virtualizētiem "pÄ«lāriem".

Å odien mēs runāsim par mākoņa infrastruktÅ«ras iekŔējo pasauli, jo Ä«paÅ”i mēs apskatÄ«sim tÄ«kla daļas pamatus.

Kas ir mākonis? Tā pati virtualizācija - profila skats?

Vairāk nekā loÄ£isks jautājums. Nē ā€“ tā nav virtualizācija, lai gan bez tās nevarētu iztikt. ApskatÄ«sim divas definÄ«cijas:

MākoņdatoÅ”ana (turpmāk tekstā ā€“ mākonis) ir modelis lietotājam draudzÄ«gas piekļuves nodroÅ”ināŔanai izkliedētajiem skaitļoÅ”anas resursiem, kas pēc pieprasÄ«juma ir jāizvieto un jāpalaiž ar iespējami zemāko latentumu un minimālām izmaksām pakalpojumu sniedzējam.

Virtualizācija - tā ir iespēja sadalÄ«t vienu fizisko entÄ«tiju (piemēram, serveri) vairākās virtuālajās, tādējādi palielinot resursu izmantoÅ”anu (piemēram, jums bija 3 serveri noslogoti ar 25-30 procentiem, pēc virtualizācijas jÅ«s saņemat 1 servera ielādi par 80-90 procentiem). Protams, virtualizācija patērē daļu resursu - jums ir jāpabaro hipervizors, tomēr, kā rāda prakse, spēle ir sveces vērta. Ideāls virtualizācijas piemērs ir VMWare, kas lieliski sagatavo virtuālās maŔīnas vai piemēram KVM, kam es dodu priekÅ”roku, bet tā ir gaumes lieta.

Mēs izmantojam virtualizāciju, to neapzinoties, un pat dzelzs marÅ”rutētāji jau izmanto virtualizāciju - piemēram, jaunākajā JunOS versijā operētājsistēma ir instalēta kā virtuāla maŔīna virs reāllaika Linux izplatÄ«Å”anas (Wind River 9). Bet virtualizācija nav mākonis, bet mākonis nevar pastāvēt bez virtualizācijas.

Virtualizācija ir viens no elementiem, uz kura tiek veidots mākonis.

Mākoņa izveide, vienkārÅ”i savācot vairākus hipervizorus vienā L2 domēnā, pievienojot pāris yaml rokasgrāmatas, lai automātiski reÄ£istrētu vlans, izmantojot kaut kādu ansible, un tam visam iesprÅ«dot kaut ko, piemēram, orÄ·estrÄ“Å”anas sistēmu, lai automātiski izveidotu virtuālās maŔīnas. Tas bÅ«s precÄ«zāk, taču iegÅ«tais FrankenÅ”teins nav mums vajadzÄ«gais mākonis, lai gan tas var bÅ«t galvenais sapnis citiem. Turklāt, ja ņemat to paÅ”u Openstack, tas bÅ«tÄ«bā joprojām ir FrankenÅ”teins, bet, labi, par to pagaidām nerunāsim.

Bet es saprotu, ka no iepriekŔ sniegtās definīcijas nav pilnīgi skaidrs, ko patiesībā var saukt par mākoni.

Tāpēc NIST (Nacionālais standartu un tehnoloģiju institūts) dokumentā ir sniegti 5 galvenie raksturlielumi, kādiem jābūt mākoņa infrastruktūrai:

Pakalpojumu sniegÅ”ana pēc pieprasÄ«juma. Lietotājam ir jānodroÅ”ina brÄ«va pieeja viņam pieŔķirtajiem datora resursiem (piemēram, tÄ«kliem, virtuālajiem diskiem, atmiņai, procesora kodoliem utt.), un Å”ie resursi ir jānodroÅ”ina automātiski ā€“ tas ir, bez pakalpojumu sniedzēja iejaukÅ”anās.

PlaŔa pakalpojuma pieejamība. Piekļuve resursiem jānodroŔina ar standarta mehānismiem, kas ļautu izmantot gan standarta personālos datorus, gan plānos klientus un mobilās ierīces.

Resursu apvienoÅ”ana baseinos. Resursu kopumiem jāspēj vienlaikus nodroÅ”ināt resursus vairākiem klientiem, nodroÅ”inot, ka klienti ir izolēti un brÄ«vi no savstarpējas ietekmes un konkurences par resursiem. PÅ«los ir iekļauti arÄ« tÄ«kli, kas norāda uz iespēju izmantot pārklājoÅ”u adresāciju. Baseinus jāspēj pielāgot pēc pieprasÄ«juma. PÅ«lu izmantoÅ”ana ļauj nodroÅ”ināt nepiecieÅ”amo resursu kļūdu tolerances lÄ«meni un fizisko un virtuālo resursu abstrakciju - pakalpojuma saņēmējam vienkārÅ”i tiek nodroÅ”ināts viņa pieprasÄ«tais resursu kopums (kur Å”ie resursi fiziski atrodas, cik daudz serveri un slēdži - klientam tas nav svarÄ«gi). Taču jāņem vērā fakts, ka pakalpojumu sniedzējam ir jānodroÅ”ina pārskatāma Å”o resursu rezervÄ“Å”ana.

Ātra pielāgoÅ”anās dažādiem apstākļiem. Pakalpojumiem ir jābÅ«t elastÄ«giem - ātra resursu nodroÅ”ināŔana, to pārdale, resursu pievienoÅ”ana vai samazināŔana pēc klienta pieprasÄ«juma, un no klienta puses ir jābÅ«t sajÅ«tai, ka mākoņa resursi ir bezgalÄ«gi. Lai atvieglotu izpratni, piemēram, jÅ«s neredzat brÄ«dinājumu, ka daļa no jÅ«su diska vietas pakalpojumā Apple iCloud ir pazudusi, jo servera cietais disks ir sabojājies un diskdziņi sabojājas. Turklāt no jÅ«su puses Ŕī servisa iespējas ir gandrÄ«z neierobežotas - vajag 2 TB - nekādu problēmu, samaksājāt un saņēmāt. LÄ«dzÄ«gu piemēru var sniegt ar Google.Drive vai Yandex.Disk.

Iespēja izmērÄ«t sniegto pakalpojumu. Mākoņsistēmām ir automātiski jākontrolē un jāoptimizē patērētie resursi, un Å”iem mehānismiem ir jābÅ«t pārskatāmiem gan lietotājam, gan pakalpojuma sniedzējam. Tas nozÄ«mē, ka jÅ«s vienmēr varat pārbaudÄ«t, cik daudz resursu jÅ«s un jÅ«su klienti patērē.

Ir vērts ņemt vērā faktu, ka Ŕīs prasÄ«bas pārsvarā ir prasÄ«bas publiskajam mākonim, tāpēc privātajam mākonim (tas ir, uzņēmuma iekŔējām vajadzÄ«bām palaistajam mākonim) Ŕīs prasÄ«bas var nedaudz koriģēt. Tomēr tie joprojām ir jādara, pretējā gadÄ«jumā mēs neiegÅ«sim visas mākoņdatoÅ”anas priekÅ”rocÄ«bas.

Kāpēc mums ir vajadzīgs mākonis?

Tomēr jebkura jauna vai esoÅ”a tehnoloÄ£ija, jebkurÅ” jauns protokols tiek radÄ«ts kaut kam (nu, protams, izņemot RIP-ng). Protokols nevienam nav vajadzÄ«gs protokola dēļ (nu, protams, izņemot RIP-ng). LoÄ£iski, ka mākonis ir izveidots, lai sniegtu lietotājam/klientam kādu pakalpojumu. Mēs visi esam pazÄ«stami ar vismaz pāris mākoņpakalpojumiem, piemēram, Dropbox vai Google.Docs, un es uzskatu, ka lielākā daļa cilvēku tos izmanto veiksmÄ«gi ā€“ piemēram, Å”is raksts tika uzrakstÄ«ts, izmantojot Google.Docs mākoņpakalpojumu. Taču mums zināmie mākoņpakalpojumi ir tikai daļa no mākoņa iespējām ā€” precÄ«zāk, tie ir tikai SaaS tipa pakalpojumi. Mēs varam nodroÅ”ināt mākoņpakalpojumu trÄ«s veidos: SaaS, PaaS vai IaaS veidā. Tas, kāds pakalpojums jums ir nepiecieÅ”ams, ir atkarÄ«gs no jÅ«su vēlmēm un iespējām.

Apskatīsim katru secībā:

ProgrammatÅ«ra kā pakalpojums (SaaS) ir modelis pilnvērtÄ«ga pakalpojuma sniegÅ”anai klientam, piemēram, e-pasta pakalpojums, piemēram, Yandex.Mail vai Gmail. Å ajā pakalpojuma sniegÅ”anas modelÄ« jÅ«s kā klients faktiski neko nedara, izņemot pakalpojumu izmantoÅ”anu ā€“ tas ir, jums nav jādomā par pakalpojuma iestatÄ«Å”anu, tā kļūdu toleranci vai dublÄ“Å”anu. Galvenais ir neapdraudēt savu paroli; pārējo jÅ«su vietā paveiks Ŕī pakalpojuma sniedzējs. No pakalpojumu sniedzēja viedokļa viņŔ ir pilnÄ«bā atbildÄ«gs par visu pakalpojumu - no servera aparatÅ«ras un resursdatora operētājsistēmām lÄ«dz datu bāzes un programmatÅ«ras iestatÄ«jumiem.

Platforma kā pakalpojums (PaaS) ā€” izmantojot Å”o modeli, pakalpojumu sniedzējs nodroÅ”ina klientam pakalpojuma sagatavi, piemēram, ņemsim Web serveri. Pakalpojuma sniedzējs nodroÅ”ināja klientam virtuālo serveri (patiesÄ«bā resursu kopumu, piemēram, RAM/CPU/Storage/Nets u.c.) un pat instalēja Å”ajā serverÄ« OS un nepiecieÅ”amo programmatÅ«ru, tomēr visu Å”o lietu dara pats klients un par pakalpojuma izpildi klients atbild. Pakalpojuma sniedzējs, tāpat kā iepriekŔējā gadÄ«jumā, ir atbildÄ«gs par fiziskā aprÄ«kojuma, hipervizoru, paÅ”as virtuālās maŔīnas darbÄ«bu, tās tÄ«kla pieejamÄ«bu utt., bet pats pakalpojums vairs nav tā atbildÄ«bas jomā.

InfrastruktÅ«ra kā pakalpojums (IaaS) - Ŕī pieeja jau ir interesantāka, faktiski pakalpojumu sniedzējs nodroÅ”ina klientam pilnÄ«gu virtualizētu infrastruktÅ«ru - tas ir, kādu resursu kopumu (kopu), piemēram, CPU kodoli, RAM, tÄ«kli utt. Viss pārējais ir atkarÄ«gs no klients - ko klients vēlas darÄ«t ar Å”iem resursiem pieŔķirtā pÅ«la (kvotas) ietvaros - piegādātājam tas nav Ä«paÅ”i svarÄ«gi. NeatkarÄ«gi no tā, vai klients vēlas izveidot savu vEPC vai pat izveidot mini operatoru un sniegt sakaru pakalpojumus - bez Å”aubām - dariet to. Šādā gadÄ«jumā pakalpojumu sniedzējs ir atbildÄ«gs par resursu nodroÅ”ināŔanu, to kļūdu toleranci un pieejamÄ«bu, kā arÄ« OS, kas ļauj apvienot Å”os resursus un padarÄ«t tos pieejamus klientam ar iespēju jebkurā laikā palielināt vai samazināt resursus. pēc klienta pieprasÄ«juma. Klients pats konfigurē visas virtuālās maŔīnas un citus sÄ«kumus, izmantojot paÅ”apkalpoÅ”anās portālu un konsoli, ieskaitot tÄ«klu iestatÄ«Å”anu (izņemot ārējos tÄ«klus).

Kas ir OpenStack?

Visās trÄ«s opcijās pakalpojuma sniedzējam ir nepiecieÅ”ama OS, kas ļaus izveidot mākoņa infrastruktÅ«ru. Faktiski ar SaaS vairāk nekā viena nodaļa ir atbildÄ«ga par visu tehnoloÄ£iju kaudzi - ir nodaļa, kas ir atbildÄ«ga par infrastruktÅ«ru - tas ir, tā nodroÅ”ina IaaS citai nodaļai, Ŕī nodaļa nodroÅ”ina SaaS klientam. OpenStack ir viena no mākoņa operētājsistēmām, kas ļauj apkopot virkni slēdžu, serveru un uzglabāŔanas sistēmu vienā resursu baseinā, sadalÄ«t Å”o kopējo kopu apakÅ”pulkos (Ä«rniekiem) un nodroÅ”ināt Å”os resursus klientiem tÄ«klā.

OpenStack ir mākoņa operētājsistēma, kas ļauj kontrolēt lielus skaitļoÅ”anas resursu, datu krātuves un tÄ«kla resursu kopumus, kas nodroÅ”ināti un pārvaldÄ«ti, izmantojot API, izmantojot standarta autentifikācijas mehānismus.

Citiem vārdiem sakot, Å”is ir bezmaksas programmatÅ«ras projektu kopums, kas paredzēts mākoņpakalpojumu (gan publisko, gan privāto) izveidoÅ”anai - tas ir, rÄ«ku komplekts, kas ļauj apvienot serveri un komutācijas iekārtas vienā resursu kopumā, pārvaldÄ«t. Å”os resursus, nodroÅ”inot nepiecieÅ”amo kļūdu tolerances lÄ«meni.

Šī materiāla rakstīŔanas laikā OpenStack struktūra izskatās Ŕādi:
Ievads mākoņa infrastruktūras tīkla daļā
Bilde uzņemta no openstack.org

Katrs no OpenStack komponentiem veic noteiktu funkciju. Å Ä« izplatÄ«tā arhitektÅ«ra ļauj risinājumā iekļaut nepiecieÅ”amo funkcionālo komponentu komplektu. Tomēr daži komponenti ir saknes komponenti, un to noņemÅ”ana novedÄ«s pie risinājuma kā veseluma pilnÄ«gas vai daļējas nedarboÅ”anās. Å Ä«s sastāvdaļas parasti klasificē Ŕādi:

  • Mans Profils ā€” TÄ«mekļa GUI OpenStack pakalpojumu pārvaldÄ«bai
  • Pamatprincips ir centralizēts identitātes pakalpojums, kas nodroÅ”ina autentifikācijas un autorizācijas funkcionalitāti citiem pakalpojumiem, kā arÄ« lietotāju akreditācijas datu un viņu lomu pārvaldÄ«bu.
  • neitronu - tÄ«kla pakalpojums, kas nodroÅ”ina savienojamÄ«bu starp dažādu OpenStack pakalpojumu saskarnēm (tostarp savienojamÄ«bu starp virtuālajām maŔīnām un to piekļuvi ārpasaulei)
  • Plēnes ā€” nodroÅ”ina piekļuvi virtuālo maŔīnu bloku krātuvei
  • jaunums ā€” virtuālo maŔīnu dzÄ«ves cikla pārvaldÄ«ba
  • Skatiens ā€” virtuālās maŔīnas attēlu un momentuzņēmumu krātuve
  • Swift kods ā€” nodroÅ”ina piekļuvi krātuves objektam
  • Celometrs ā€” pakalpojums, kas nodroÅ”ina iespēju apkopot telemetriju un izmērÄ«t pieejamos un patērētos resursus
  • Siltums ā€” uz veidnēm balstÄ«ta orÄ·estrÄ“Å”ana resursu automātiskai izveidei un nodroÅ”ināŔanai

Pilns visu projektu saraksts un to mērÄ·is ir apskatāms Å”eit.

Katrs OpenStack komponents ir pakalpojums, kas veic noteiktu funkciju un nodroÅ”ina API, lai pārvaldÄ«tu Å”o funkciju un mijiedarbotos ar citiem mākoņa operētājsistēmas pakalpojumiem, lai izveidotu vienotu infrastruktÅ«ru. Piemēram, Nova nodroÅ”ina skaitļoÅ”anas resursu pārvaldÄ«bu un API, lai piekļūtu Å”o resursu konfigurÄ“Å”anai, Glance nodroÅ”ina attēlu pārvaldÄ«bu un API to pārvaldÄ«bai, Cinder nodroÅ”ina bloku krātuvi un API to pārvaldÄ«bai utt. Visas funkcijas ir savstarpēji ļoti cieÅ”i saistÄ«tas.

Tomēr, ja paskatās uz to, visi pakalpojumi, kas darbojas OpenStack, galu galā ir sava veida virtuālā maŔīna (vai konteiners), kas savienots ar tÄ«klu. Rodas jautājums ā€“ kāpēc mums vajag tik daudz elementu?

Apskatīsim algoritmu, lai izveidotu virtuālo maŔīnu un savienotu to ar tīklu un pastāvīgo krātuvi programmā Openstack.

  1. Kad veidojat pieprasÄ«jumu izveidot maŔīnu, neatkarÄ«gi no tā, vai tas ir pieprasÄ«jums, izmantojot Horizon (informācijas paneli) vai pieprasÄ«jums, izmantojot CLI, pirmā lieta, kas notiek, ir jÅ«su pieprasÄ«juma autorizācija Keystone ā€” vai varat izveidot maŔīnu, vai tai ir tiesÄ«bas izmantot Å”o tÄ«klu, vai jÅ«su kvotas projekts utt.
  2. Keystone autentificē jūsu pieprasījumu un atbildes ziņojumā ģenerē autentifikācijas pilnvaru, kas tiks izmantota turpmāk. Saņemot atbildi no Keystone, pieprasījums tiek nosūtīts uz Nova (nova api).
  3. Nova-api pārbauda jÅ«su pieprasÄ«juma derÄ«gumu, sazinoties ar Keystone, izmantojot iepriekÅ” Ä£enerētu autentifikācijas pilnvaru
  4. Keystone veic autentifikāciju un sniedz informāciju par atļaujām un ierobežojumiem, pamatojoties uz Ŕo autentifikācijas pilnvaru.
  5. Nova-api izveido jaunās virtuālās maŔīnas ierakstu nova-database un nosūta pieprasījumu izveidot maŔīnu nova-scheduler.
  6. Nova-scheduler atlasa resursdatoru (datora mezglu), uz kura tiks izvietota virtuālā maŔīna, pamatojoties uz norādītajiem parametriem, svariem un zonām. Ieraksts par Ŕo un virtuālās maŔīnas ID tiek ierakstīts nova-database.
  7. Pēc tam nova-scheduler sazinās ar nova-compute ar pieprasÄ«jumu izvietot gadÄ«jumu. Nova-compute sazinās ar nova-conductor, lai iegÅ«tu informāciju par maŔīnas parametriem (nova-conductor ir nova elements, kas darbojas kā starpniekserveris starp nova-database un nova-compute, ierobežojot pieprasÄ«jumu skaitu nova-database, lai izvairÄ«tos no problēmām ar datu bāzi konsistences slodzes samazināŔana).
  8. Nova-conductor saņem pieprasīto informāciju no nova-database un nodod to nova-compute.
  9. Pēc tam nova-compute zvani, lai iegūtu attēla ID. Glace apstiprina pieprasījumu Keystone un atgriež pieprasīto informāciju.
  10. Nova-compute sazinās ar neitronu, lai iegūtu informāciju par tīkla parametriem. Līdzīgi kā skatiens, neitrons apstiprina pieprasījumu Keystone, pēc tam izveido ierakstu datu bāzē (porta identifikatoru utt.), izveido pieprasījumu izveidot portu un atgriež pieprasīto informāciju nova-compute.
  11. Nova-compute sazinās ar lÅ«gumu pieŔķirt sējumu virtuālajai maŔīnai. LÄ«dzÄ«gi kā skatiens, sidrs apstiprina pieprasÄ«jumu Keystone, izveido sējuma izveides pieprasÄ«jumu un atgriež pieprasÄ«to informāciju.
  12. Nova-compute sazinās ar libvirt ar pieprasījumu izvietot virtuālo maŔīnu ar norādītajiem parametriem.

PatiesÄ«bā Ŕķietami vienkārÅ”a vienkārÅ”as virtuālās maŔīnas izveides darbÄ«ba pārvērÅ”as par Ŕādu API zvanu virpuli starp mākoņa platformas elementiem. Turklāt, kā redzat, pat iepriekÅ” noteiktie pakalpojumi sastāv no mazākiem komponentiem, starp kuriem notiek mijiedarbÄ«ba. MaŔīnas izveide ir tikai neliela daļa no tā, ko mākoņa platforma ļauj darÄ«t ā€“ ir pakalpojums, kas atbild par trafika lÄ«dzsvaroÅ”anu, pakalpojums, kas atbild par bloku krātuvi, pakalpojums, kas atbild par DNS, pakalpojums, kas atbild par tukÅ”a metāla serveru nodroÅ”ināŔanu utt. Mākonis ļauj jums izturēties pret virtuālajām maŔīnām kā pret aitu ganāmpulku (pretstatā virtualizācijai). Ja kaut kas notiek ar jÅ«su maŔīnu virtuālajā vidē - jÅ«s to atjaunojat no dublējumkopijām utt., bet mākoņa aplikācijas ir uzbÅ«vētas tā, ka virtuālā maŔīna nespēlē tik svarÄ«gu lomu - virtuālā maŔīna "nomira" - nav problēmu - vienkārÅ”i tiek izveidots jauns, transportlÄ«dzeklis ir balstÄ«ts uz veidni, un, kā saka, komanda nepamanÄ«ja cÄ«nÄ«tāja zaudējumu. Protams, tas nodroÅ”ina orÄ·estrÄ“Å”anas mehānismu klātbÅ«tni - izmantojot Heat veidnes, jÅ«s varat viegli izvietot sarežģītu funkciju, kas sastāv no desmitiem tÄ«klu un virtuālo maŔīnu.

Vienmēr ir vērts paturēt prātā, ka nav mākoņa infrastruktÅ«ras bez tÄ«kla ā€“ katrs elements tādā vai citādā veidā mijiedarbojas ar citiem elementiem caur tÄ«klu. Turklāt mākonim ir absolÅ«ti nestatisks tÄ«kls. Dabiski, ka apakÅ”tÄ«kls ir pat vairāk vai mazāk statisks - jauni mezgli un slēdži netiek pievienoti katru dienu, bet pārklājuma komponents var un neizbēgami mainÄ«sies pastāvÄ«gi - tiks pievienoti vai dzēsti jauni tÄ«kli, parādÄ«sies jaunas virtuālās maŔīnas un vecās. mirt. Un, kā jÅ«s atceraties no mākoņa definÄ«cijas, kas sniegta paŔā raksta sākumā, resursi lietotājam ir jāpieŔķir automātiski un ar vismazāko (vai vēl labāk, bez) pakalpojumu sniedzēja iejaukÅ”anās. Tas nozÄ«mē, ka tÄ«kla resursu nodroÅ”ināŔanas veids, kas tagad pastāv priekÅ”gala veidā jÅ«su personÄ«gā konta veidā, kuram var piekļūt, izmantojot http/https, un dežurējoÅ”ais tÄ«kla inženieris Vasilijs kā aizmugursistēma nav mākonis, pat ja Vasilijam ir astoņas rokas.

Neutron kā tÄ«kla pakalpojums nodroÅ”ina API mākoņa infrastruktÅ«ras tÄ«kla daļas pārvaldÄ«Å”anai. Pakalpojums nodroÅ”ina un pārvalda Openstack tÄ«kla daļu, nodroÅ”inot abstrakcijas slāni ar nosaukumu Network-as-a-Service (NaaS). Tas nozÄ«mē, ka tÄ«kls ir tāda pati virtuālā izmērāmā vienÄ«ba kā, piemēram, virtuālie CPU kodoli vai RAM apjoms.

Bet pirms pāriet uz OpenStack tÄ«kla daļas arhitektÅ«ru, apskatÄ«sim, kā Å”is tÄ«kls darbojas OpenStack un kāpēc tÄ«kls ir svarÄ«ga un neatņemama mākoņa sastāvdaļa.

Tātad mums ir divas RED klientu virtuālās maŔīnas un divas GREEN klienta virtuālās maŔīnas. Pieņemsim, ka Ŕīs maŔīnas atrodas uz diviem hipervizoriem Ŕādā veidā:

Ievads mākoņa infrastruktūras tīkla daļā

Å obrÄ«d tā ir tikai 4 serveru virtualizācija un nekas vairāk, jo lÄ«dz Å”im viss, ko esam paveikuÅ”i, ir virtualizējuÅ”i 4 serverus, novietojot tos uz diviem fiziskajiem serveriem. Un lÄ«dz Å”im tie pat nav savienoti ar tÄ«klu.

Lai izveidotu mākoni, mums jāpievieno vairāki komponenti. Pirmkārt, mēs virtualizējam tÄ«kla daļu - mums ir jāsavieno Ŕīs 4 maŔīnas pa pāriem, un klienti vēlas L2 savienojumu. Varat izmantot slēdzi un konfigurēt maÄ£istrāli tā virzienā un atrisināt visu, izmantojot linux tiltu vai, pieredzējuŔākiem lietotājiem, openvswitch (pie tā atgriezÄ«simies vēlāk). Taču tÄ«klu var bÅ«t daudz, un nepārtraukta L2 stumÅ”ana caur slēdzi nav tā labākā ideja ā€“ ir dažādas nodaļas, apkalpoÅ”anas galds, mēneÅ”iem ilgi jāgaida, lÄ«dz tiks pabeigta lietojumprogramma, nedēļām ilga problēmu novērÅ”ana ā€“ mÅ«sdienu pasaulē tas ir pieeja vairs nedarbojas. Un jo ātrāk uzņēmums to saprot, jo vieglāk tam ir virzÄ«ties uz priekÅ”u. Tāpēc starp hipervizoriem mēs izvēlēsimies L3 tÄ«klu, caur kuru sazināsies mÅ«su virtuālās maŔīnas, un papildus Å”im L3 tÄ«klam mēs izveidosim virtuālos L2 pārklājuma tÄ«klus, kuros darbosies mÅ«su virtuālo maŔīnu trafiks. Kā iekapsulÄ“Å”anu varat izmantot GRE, Geneve vai VxLAN. Pagaidām pievērsÄ«simies pēdējam, lai gan tas nav Ä«paÅ”i svarÄ«gi.

Mums kaut kur jāatrod VTEP (es ceru, ka visi ir pazÄ«stami ar VxLAN terminoloÄ£iju). Tā kā mums ir L3 tÄ«kls, kas nāk tieÅ”i no serveriem, nekas neliedz mums izvietot VTEP paÅ”os serveros, un OVS (OpenvSwitch) lieliski to dara. Rezultātā mēs ieguvām Ŕādu dizainu:

Ievads mākoņa infrastruktūras tīkla daļā

Tā kā satiksme starp virtuālajām maŔīnām ir jāsadala, portiem, kas vērsti uz virtuālajām maŔīnām, bÅ«s atŔķirÄ«gi VLAN numuri. Taga numuram ir nozÄ«me tikai vienā virtuālajā slēdžā, jo, kad tas ir iekapsulēts VxLAN, mēs to varam viegli noņemt, jo mums bÅ«s VNI.

Ievads mākoņa infrastruktūras tīkla daļā

Tagad mēs varam bez problēmām izveidot viņiem savas maŔīnas un virtuālos tÄ«klus.

Tomēr ko darÄ«t, ja klientam ir cita iekārta, bet tas atrodas citā tÄ«klā? Mums ir nepiecieÅ”ama sakņu izveide starp tÄ«kliem. Mēs apskatÄ«sim vienkārÅ”u iespēju, ja tiek izmantota centralizēta marÅ”rutÄ“Å”ana - tas ir, trafika tiek marÅ”rutēta caur Ä«paÅ”iem Ä«paÅ”iem tÄ«kla mezgliem (kā likums, tie ir apvienoti ar vadÄ«bas mezgliem, tāpēc mums bÅ«s tas pats).

Å Ä·iet, ka nekas sarežģīts - mēs uztaisām tilta interfeisu uz vadÄ«bas mezgla, pievadām satiksmi uz to un no turienes virzām to, kur mums tas ir nepiecieÅ”ams. Bet problēma ir tā, ka RED klients vēlas izmantot 10.0.0.0/24 tÄ«klu, bet GREEN klients vēlas izmantot 10.0.0.0/24 tÄ«klu. Tas ir, mēs sākam krustot adreÅ”u telpas. Turklāt klienti nevēlas, lai citi klienti varētu marÅ”rutēt viņu iekŔējos tÄ«klos, kas ir loÄ£iski. Lai nodalÄ«tu tÄ«klus un klientu datu trafiku, katram no tiem pieŔķirsim atseviŔķu nosaukumvietu. Nosaukumvieta faktiski ir Linux tÄ«kla steka kopija, tas ir, klienti nosaukumvietā RED ir pilnÄ«bā izolēti no klientiem no nosaukumvietas GREEN (labi, vai nu marÅ”rutÄ“Å”ana starp Å”iem klientu tÄ«kliem ir atļauta, izmantojot noklusējuma nosaukumvietu vai augÅ”upējās transporta iekārtas).

Tas ir, mēs iegÅ«stam Ŕādu diagrammu:

Ievads mākoņa infrastruktūras tīkla daļā

L2 tuneļi saplūst no visiem skaitļoŔanas mezgliem uz vadības mezglu. mezgls, kurā atrodas Ŕo tīklu L3 interfeiss, katrs atseviŔķā nosaukumvietā izolācijai.

Tomēr mēs aizmirsām vissvarÄ«gāko. Virtuālajai maŔīnai ir jānodroÅ”ina pakalpojums klientam, tas ir, tai ir jābÅ«t vismaz vienam ārējam interfeisam, caur kuru to var sasniegt. Tas ir, mums ir jāiziet ārpasaulē. Å eit ir dažādas iespējas. IzdarÄ«sim vienkārŔāko variantu. Katram klientam pievienosim vienu tÄ«klu, kas bÅ«s derÄ«gs pakalpojumu sniedzēja tÄ«klā un nepārklāsies ar citiem tÄ«kliem. TÄ«kli var arÄ« krustoties un apskatÄ«t dažādus VRF pakalpojumu sniedzēja tÄ«kla pusē. TÄ«kla dati arÄ« dzÄ«vos katra klienta nosaukumu telpā. Tomēr viņi joprojām izies uz ārpasauli, izmantojot vienu fizisku (vai saiti, kas ir loÄ£iskāk) saskarni. Lai atdalÄ«tu klienta trafiku, datplÅ«sma, kas iziet ārpusē, tiks marķēta ar klientam pieŔķirto VLAN tagu.

Rezultātā mēs saņēmām Ŕādu diagrammu:

Ievads mākoņa infrastruktūras tīkla daļā

SaprātÄ«gs jautājums ir, kāpēc gan neizveidot vārtejas paÅ”os skaitļoÅ”anas mezglos? Tā nav liela problēma; turklāt, ja ieslēdzat sadalÄ«to marÅ”rutētāju (DVR), tas darbosies. Å ajā scenārijā mēs apsveram vienkārŔāko iespēju ar centralizētu vārteju, kas tiek izmantota pēc noklusējuma Openstack. Lielas slodzes funkcijām tie izmantos gan sadalÄ«to marÅ”rutētāju, gan paātrināŔanas tehnoloÄ£ijas, piemēram, SR-IOV un Passthrough, taču, kā viņi saka, tas ir pavisam cits stāsts. Vispirms apskatÄ«sim pamata daļu, un tad iedziļināsimies detaļās.

Patiesībā mūsu shēma jau darbojas, taču ir dažas nianses:

  • Mums ir kaut kā jāaizsargā mÅ«su maŔīnas, tas ir, slēdža saskarnē jāievieto filtrs pret klientu.
  • Dodiet iespēju virtuālajai maŔīnai automātiski iegÅ«t IP adresi, lai jums nebÅ«tu katru reizi tajā jāpiesakās caur konsoli un jāreÄ£istrē adrese.

Sāksim ar maŔīnu aizsardzÄ«bu. Å im nolÅ«kam varat izmantot banālus iptables, kāpēc gan ne.

Tas ir, tagad mūsu topoloģija ir kļuvusi nedaudz sarežģītāka:

Ievads mākoņa infrastruktūras tīkla daļā

Ejam tālāk. Mums jāpievieno DHCP serveris. Ideālākā vieta DHCP serveru atraÅ”anai katram klientam bÅ«tu jau iepriekÅ” minētais vadÄ«bas mezgls, kurā atrodas nosaukumu telpas:

Ievads mākoņa infrastruktūras tīkla daļā

Tomēr ir neliela problēma. Ko darÄ«t, ja viss tiek restartēts un visa informācija par adreÅ”u nomu DHCP tÄ«klā pazÅ«d. LoÄ£iski, ka automātiem tiks pieŔķirtas jaunas adreses, kas nav Ä«paÅ”i ērti. Å eit ir divas izejas - vai nu izmantojiet domēna nosaukumus un pievienojiet DNS serveri katram klientam, tad adrese mums nebÅ«s Ä«paÅ”i svarÄ«ga (lÄ«dzÄ«gi kā tÄ«kla daļai k8s) - taču ir problēma ar ārējiem tÄ«kliem, jo adreses tajās var izsniegt arÄ« caur DHCP - nepiecieÅ”ama sinhronizācija ar DNS serveriem mākoņplatformā un ārējais DNS serveris, kas manuprāt nav Ä«paÅ”i elastÄ«gs, bet ir pilnÄ«gi iespējams. Vai arÄ« otrā iespēja ir izmantot metadatus - tas ir, saglabāt informāciju par maŔīnai izsniegto adresi, lai DHCP serveris zinātu, kuru adresi iekārtai izsniegt, ja iekārta jau ir saņēmusi adresi. Otrā iespēja ir vienkārŔāka un elastÄ«gāka, jo ļauj saglabāt papildu informāciju par automaŔīnu. Tagad pievienosim diagrammai aÄ£enta metadatus:

Ievads mākoņa infrastruktūras tīkla daļā

Vēl viens jautājums, kas arÄ« ir vērts apspriest, ir iespēja visiem klientiem izmantot vienu ārējo tÄ«klu, jo ārējie tÄ«kli, ja tiem ir jābÅ«t derÄ«giem visā tÄ«klā, bÅ«s sarežģīti - jums ir pastāvÄ«gi jāpieŔķir un jākontrolē Å”o tÄ«klu pieŔķirÅ”ana. Iespēja izmantot vienu ārēju iepriekÅ” konfigurētu tÄ«klu visiem klientiem bÅ«s ļoti noderÄ«ga, veidojot publisko mākoni. Tas atvieglos maŔīnu izvietoÅ”anu, jo mums nav jāmeklē adreÅ”u datubāze un jāizvēlas unikāla adreÅ”u telpa katra klienta ārējam tÄ«klam. Turklāt mēs varam iepriekÅ” reÄ£istrēt ārējo tÄ«klu, un izvietoÅ”anas laikā mums bÅ«s jāsaista tikai ārējās adreses ar klientu iekārtām.

Un Å”eit mums palÄ«dz NAT ā€” mēs tikai nodroÅ”ināsim klientiem piekļuvi ārpasaulei, izmantojot noklusējuma nosaukumvietu, izmantojot NAT tulkojumu. Nu, lÅ«k, neliela problēma. Tas ir labi, ja klienta serveris darbojas kā klients, nevis kā serveris - tas ir, tas iniciē, nevis pieņem savienojumus. Bet mums bÅ«s otrādi. Å ajā gadÄ«jumā mums ir jāveic galamērÄ·a NAT, lai, saņemot trafiku, vadÄ«bas mezgls saprastu, ka Ŕī trafika ir paredzēta klienta A virtuālajai maŔīnai A, kas nozÄ«mē, ka mums ir jāveic NAT tulkojums no ārējās adreses, piemēram, 100.1.1.1. .10.0.0.1, uz iekŔējo adresi 100. Å ajā gadÄ«jumā, lai gan visi klienti izmantos vienu un to paÅ”u tÄ«klu, iekŔējā izolācija ir pilnÄ«bā saglabāta. Tas ir, mums ir jāveic dNAT un sNAT vadÄ«bas mezglā. Tas, vai izmantot vienu tÄ«klu ar peldoŔām adresēm vai ārējiem tÄ«kliem, vai abus vienlaikus, ir atkarÄ«gs no tā, ko vēlaties ievietot mākonÄ«. Mēs diagrammai nepievienosim peldoŔās adreses, bet atstāsim jau iepriekÅ” pievienotos ārējos tÄ«klus - katram klientam ir savs ārējais tÄ«kls (shēmā tie ir norādÄ«ti kā vlan 200 un XNUMX ārējā saskarnē).

Rezultātā saņēmām interesantu un tajā paŔā laikā pārdomātu risinājumu, kuram ir zināma elastÄ«ba, bet vēl nav kļūdu tolerances mehānismu.

Pirmkārt, mums ir tikai viens vadÄ«bas mezgls - tā kļūme novedÄ«s pie visu sistēmu sabrukuma. Lai novērstu Å”o problēmu, jums ir nepiecieÅ”ams vismaz 3 mezglu kvorums. Pievienosim diagrammai Å”o:

Ievads mākoņa infrastruktūras tīkla daļā

Protams, visi mezgli tiek sinhronizēti un, kad aktīvs mezgls aiziet, cits mezgls pārņems savus pienākumus.

Nākamā problēma ir virtuālās maŔīnas diski. Å obrÄ«d tie tiek glabāti paÅ”os hipervizoros, un, ja rodas problēmas ar hipervizoru, mēs zaudējam visus datus - un reida klātbÅ«tne Å”eit nepalÄ«dzēs, ja mēs zaudēsim nevis disku, bet visu serveri. Lai to izdarÄ«tu, mums ir jāizveido pakalpojums, kas darbosies kā kāda veida krātuves priekÅ”gals. Mums nav Ä«paÅ”i svarÄ«gi, kāda veida krātuve tā bÅ«s, taču tai vajadzētu aizsargāt mÅ«su datus no diska un mezgla un, iespējams, visa korpusa kļūmēm. Å eit ir vairākas iespējas - ir, protams, SAN tÄ«kli ar Fibre Channel, bet bÅ«sim godÄ«gi - FC jau ir pagātnes relikts - E1 analogs transportā - jā, piekrÄ«tu, joprojām tiek izmantots, bet tikai tur, kur bez tā nav iespējams. Tāpēc es 2020. gadā brÄ«vprātÄ«gi neizvietotu FC tÄ«klu, zinot, ka ir arÄ« citas interesantākas alternatÄ«vas. Lai gan katram savs, iespējams, ir tādi, kas uzskata, ka FC ar visiem tās ierobežojumiem ir viss, kas mums vajadzÄ«gs - nestrÄ«dÄ“Å”os, katram savs viedoklis. Tomēr visinteresantākais risinājums, manuprāt, ir izmantot SDS, piemēram, Ceph.

Ceph ļauj izveidot ļoti pieejamu datu glabāŔanas risinājumu ar daudzām iespējamām rezerves iespējām, sākot ar kodiem ar paritātes pārbaudi (analogs 5. vai 6. reidam) un beidzot ar pilnu datu replikāciju dažādos diskos, ņemot vērā disku atraÅ”anās vietu serveri un serveri kabinetos utt.

Lai izveidotu Ceph, jums ir nepiecieÅ”ami vēl 3 mezgli. MijiedarbÄ«ba ar krātuvi tiks veikta arÄ« caur tÄ«klu, izmantojot bloku, objektu un failu uzglabāŔanas pakalpojumus. Pievienosim shēmai krātuvi:

Ievads mākoņa infrastruktūras tīkla daļā

PiezÄ«me: varat izveidot arÄ« hiperkonverģētus skaitļoÅ”anas mezglus ā€” tā ir vairāku funkciju apvienoÅ”anas koncepcija vienā mezglā, piemēram, krātuve+aprēķināŔana, neatvēlot Ä«paÅ”us mezglus ceph glabāŔanai. Mēs iegÅ«sim to paÅ”u kļūdu izturÄ«go shēmu - tā kā SDS rezervēs datus ar mÅ«su norādÄ«to rezervācijas lÄ«meni. Tomēr hiperkonverģētie mezgli vienmēr ir kompromiss ā€” tā kā uzglabāŔanas mezgls ne tikai silda gaisu, kā Ŕķiet pirmajā mirklÄ« (jo tajā nav virtuālo maŔīnu), ā€” tas tērē CPU resursus SDS apkalpoÅ”anai (patiesÄ«bā tas dara visu replikācija un atkopÅ”ana pēc mezglu, disku uc kļūmēm). Tas nozÄ«mē, ka, apvienojot to ar krātuvi, jÅ«s zaudēsit daļu no aprēķina mezgla jaudas.

Visas Ŕīs lietas ir kaut kā jāpārvalda ā€” mums ir nepiecieÅ”ams kaut kas, ar kura palÄ«dzÄ«bu mēs varam izveidot maŔīnu, tÄ«klu, virtuālo marÅ”rutētāju utt. Lai to izdarÄ«tu, vadÄ«bas mezglam pievienosim pakalpojumu, kas darbosies kā informācijas panelis ā€” klients varēs pieslēgties Å”im portālam caur http/ https un darÄ«t visu nepiecieÅ”amo (nu, gandrÄ«z).

Tā rezultātā mums tagad ir kļūmju izturÄ«ga sistēma. Visi Ŕīs infrastruktÅ«ras elementi ir kaut kā jāpārvalda. IepriekÅ” tika aprakstÄ«ts, ka Openstack ir projektu kopums, no kuriem katrs nodroÅ”ina noteiktu funkciju. Kā redzam, elementu, kas jākonfigurē un jākontrolē, ir vairāk nekā pietiekami. Å odien mēs runāsim par tÄ«kla daļu.

Neitronu arhitektūra

OpenStack tieÅ”i Neutron ir atbildÄ«gs par virtuālās maŔīnas pieslēgvietu pievienoÅ”anu kopējam L2 tÄ«klam, trafika marÅ”rutÄ“Å”anas nodroÅ”ināŔanu starp virtuālajām maŔīnām, kas atrodas dažādos L2 tÄ«klos, kā arÄ« izbraukÅ”anu, nodroÅ”inot tādus pakalpojumus kā NAT, Floating IP, DHCP u.c.

Augstā līmenī tīkla pakalpojuma (pamata daļas) darbību var raksturot Ŕādi.

Startējot virtuālo maŔīnu, tÄ«kla pakalpojums:

  1. Izveido portu dotajai VM (vai portiem) un paziņo par to DHCP servisam;
  2. Tiek izveidota jauna virtuālā tīkla ierīce (izmantojot libvirt);
  3. Virtuālā maŔīna izveido savienojumu ar 1. darbībā izveidoto(-iem) portu(-iem);

Savādi, bet Neutron darbs ir balstīts uz standarta mehānismiem, kas ir pazīstami ikvienam, kurŔ jebkad ir ieniris Linux - namespaces, iptables, Linux tilti, openvswitch, conntrack utt.

Nekavējoties jāprecizē, ka Neutron nav SDN kontrolieris.

Neitrons sastāv no vairākiem savstarpēji saistītiem komponentiem:

Ievads mākoņa infrastruktūras tīkla daļā

Openstack-neutron-serveris ir dēmons, kas darbojas ar lietotāju pieprasÄ«jumiem, izmantojot API. Å is dēmons nav iesaistÄ«ts tÄ«kla savienojumu reÄ£istrÄ“Å”anā, bet sniedz Å”im nolÅ«kam nepiecieÅ”amo informāciju saviem spraudņiem, kas pēc tam konfigurē vēlamo tÄ«kla elementu. Neitronu aÄ£enti OpenStack mezglos reÄ£istrējas Neutron serverÄ«.

Neitron-serveris faktiski ir lietojumprogramma, kas rakstīta python un sastāv no divām daļām:

  • REST serviss
  • Neitron spraudnis (pamats/pakalpojums)

Pakalpojums REST ir paredzēts API zvanu saņemÅ”anai no citiem komponentiem (piemēram, pieprasÄ«jumu sniegt kādu informāciju utt.)

Spraudņi ir spraudņu programmatÅ«ras komponenti/moduļi, kas tiek izsaukti API pieprasÄ«jumu laikā ā€” tas ir, pakalpojuma attiecināŔana notiek caur tiem. Spraudņi ir sadalÄ«ti divos veidos - serviss un saknes. Parasti zirga spraudnis galvenokārt ir atbildÄ«gs par adreÅ”u telpas un L2 savienojumu pārvaldÄ«bu starp virtuālajām maŔīnām, un pakalpojumu spraudņi jau nodroÅ”ina papildu funkcionalitāti, piemēram, VPN vai FW.

Piemēram, var apskatÄ«t Å”odien pieejamo spraudņu sarakstu Å”eit

Var būt vairāki pakalpojumu spraudņi, bet var būt tikai viens zirgu spraudnis.

openstack-neutron-ml2 ir standarta Openstack saknes spraudnis. Å im spraudnim ir modulāra arhitektÅ«ra (atŔķirÄ«bā no tā priekÅ”gājēja), un tas konfigurē tÄ«kla pakalpojumu, izmantojot tam pievienotos draiverus. PaÅ”u spraudni apskatÄ«sim nedaudz vēlāk, jo patiesÄ«bā tas nodroÅ”ina OpenStack tÄ«kla daļas elastÄ«bu. Saknes spraudni var aizstāt (piemēram, Contrail Networking veic Ŕādu nomaiņu).

RPC pakalpojums (rabbitmq-server) ā€” pakalpojums, kas nodroÅ”ina rindu pārvaldÄ«bu un mijiedarbÄ«bu ar citiem OpenStack pakalpojumiem, kā arÄ« mijiedarbÄ«bu starp tÄ«kla pakalpojumu aÄ£entiem.

TÄ«kla aÄ£enti ā€” aÄ£enti, kas atrodas katrā mezglā, caur kuriem tiek konfigurēti tÄ«kla pakalpojumi.

Ir vairāki aģentu veidi.

Galvenais aÄ£ents ir L2 aÄ£ents. Å ie aÄ£enti darbojas katrā no hipervizoriem, tostarp vadÄ«bas mezgliem (precÄ«zāk, visos mezglos, kas sniedz jebkādus pakalpojumus nomniekiem), un to galvenā funkcija ir savienot virtuālās maŔīnas ar kopēju L2 tÄ«klu, kā arÄ« Ä£enerēt brÄ«dinājumus, kad notiek kādi notikumi ( piemēram, atspējot/iespējot portu).

Nākamais, ne mazāk svarÄ«gais aÄ£ents ir L3 aÄ£ents. Pēc noklusējuma Å”is aÄ£ents darbojas tikai tÄ«kla mezglā (bieži tÄ«kla mezgls tiek apvienots ar vadÄ«bas mezglu) un nodroÅ”ina marÅ”rutÄ“Å”anu starp nomnieku tÄ«kliem (gan starp saviem tÄ«kliem, gan citu nomnieku tÄ«kliem, kā arÄ« ir pieejams ārpasaulei, nodroÅ”inot NAT, kā arÄ« DHCP pakalpojumu). Tomēr, izmantojot DVR (distributed router), nepiecieÅ”amÄ«ba pēc L3 spraudņa parādās arÄ« skaitļoÅ”anas mezglos.

L3 aÄ£ents izmanto Linux nosaukumvietas, lai nodroÅ”inātu katram nomniekam savu izolētu tÄ«klu kopu un virtuālo marÅ”rutētāju funkcionalitāti, kas marÅ”rutē trafiku un nodroÅ”ina vārtejas pakalpojumus 2. slāņa tÄ«kliem.

Datubāze ā€” tÄ«klu, apakÅ”tÄ«klu, portu, kopu utt. identifikatoru datu bāze.

Faktiski Neutron pieņem API pieprasÄ«jumus no jebkura tÄ«kla entÄ«tiju izveides, autentificē pieprasÄ«jumu un caur RPC (ja tas piekļūst kādam spraudnim vai aÄ£entam) vai REST API (ja tas sazinās SDN) pārsÅ«ta aÄ£entiem (izmantojot spraudņus) norādÄ«jumi, kas nepiecieÅ”ami pieprasÄ«tā pakalpojuma organizÄ“Å”anai.

Tagad pievērsīsimies testa instalācijai (kā tā tiek izvietota un kas tajā ir iekļauta, redzēsim vēlāk praktiskajā daļā) un redzēsim, kur atrodas katra sastāvdaļa:

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

Ievads mākoņa infrastruktūras tīkla daļā

Faktiski tā ir visa neitrona struktūra. Tagad ir vērts kādu laiku veltīt spraudnim ML2.

2. moduļu slānis

Kā minēts iepriekÅ”, spraudnis ir standarta OpenStack saknes spraudnis, un tam ir modulāra arhitektÅ«ra.

ML2 spraudņa priekÅ”gājējam bija monolÄ«ta struktÅ«ra, kas neļāva, piemēram, vienā instalācijā izmantot vairāku tehnoloÄ£iju sajaukumu. Piemēram, jÅ«s nevarējāt vienlaikus izmantot gan openvswitch, gan linuxbridge - ne pirmo, ne otro. Å Ä« iemesla dēļ tika izveidots spraudnis ML2 ar tā arhitektÅ«ru.

ML2 ir divas sastāvdaļas - divu veidu draiveri: tipa draiveri un mehānisma draiveri.

Ierakstiet draiverus noteikt tehnoloÄ£ijas, kas tiks izmantotas tÄ«kla savienojumu organizÄ“Å”anai, piemēram, VxLAN, VLAN, GRE. Tajā paŔā laikā vadÄ«tājs ļauj izmantot dažādas tehnoloÄ£ijas. Standarta tehnoloÄ£ija ir VxLAN iekapsulÄ“Å”ana pārklājuma tÄ«kliem un VLAN ārējiem tÄ«kliem.

Tipu draiveri ietver Ŕādus tīklu veidus:

Dzīvoklis - tīkls bez marķēŔanas
VLAN - atzīmēts tīkls
Uz vietas ā€” Ä«paÅ”a veida tÄ«kls instalācijām viss vienā (Ŕādas iekārtas ir vajadzÄ«gas izstrādātājiem vai apmācÄ«bai)
GRE ā€” pārklājuma tÄ«kls, izmantojot GRE tuneļus
VxLAN ā€” pārklājuma tÄ«kls, izmantojot VxLAN tuneļus

Mehānismu draiveri definēt rÄ«kus, kas nodroÅ”ina tipa draiverÄ« norādÄ«to tehnoloÄ£iju organizÄ“Å”anu - piemēram, openvswitch, sr-iov, opendaylight, OVN u.c.

AtkarÄ«bā no Ŕī draivera ievieÅ”anas tiks izmantoti vai nu Neutron kontrolēti aÄ£enti, vai arÄ« savienojumi ar ārēju SDN kontrolieri, kas rÅ«pējas par visiem jautājumiem, kas saistÄ«ti ar L2 tÄ«klu organizÄ“Å”anu, marÅ”rutÄ“Å”anu utt.

Piemērs: ja mēs izmantojam ML2 kopā ar OVS, tad L2 aÄ£ents tiek instalēts katrā skaitļoÅ”anas mezglā, kas pārvalda OVS. Taču, ja lietojam, piemēram, OVN vai OpenDayLight, tad OVS vadÄ«ba nonāk viņu jurisdikcijā - Neutron caur root spraudni dod komandas kontrolierim, un tas jau dara to, ko lika.

Atjaunināsim informāciju par Open vSwitch

Šobrīd viens no OpenStack galvenajiem komponentiem ir Open vSwitch.
Instalējot OpenStack bez papildu pārdevēja SDN, piemēram, Juniper Contrail vai Nokia Nuage, OVS ir galvenā mākoņa tÄ«kla tÄ«kla sastāvdaļa un kopā ar iptables, conntrack, namespaces ļauj organizēt pilnvērtÄ«gus vairāku nomas pārklājumu tÄ«klus. Protams, Å”o komponentu var aizstāt, piemēram, izmantojot treŔās puses patentētus (pārdevēja) SDN risinājumus.

OVS ir atvērtā pirmkoda programmatÅ«ras slēdzis, kas paredzēts lietoÅ”anai virtualizētā vidē kā virtuālā trafika pārsÅ«tÄ«tājs.

Šobrīd OVS ir ļoti pieklājīga funkcionalitāte, kas ietver tādas tehnoloģijas kā QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK u.c.

PiezÄ«me: OVS sākotnēji netika iecerēts kā mÄ«ksts slēdzis ļoti noslogotām telekomunikāciju funkcijām, un tas bija vairāk paredzēts IT funkcijām, kurām ir mazāks joslas platums, piemēram, WEB serverim vai pasta serverim. Taču OVS tiek tālāk attÄ«stÄ«ts un paÅ”reizējās OVS implementācijas ir krietni uzlabojuÅ”as tā veiktspēju un iespējas, kas ļauj to izmantot telekomunikāciju operatoriem ar ļoti noslogotām funkcijām, piemēram, ir OVS implementācija ar atbalstu DPDK paātrinājumam.

Ir trīs svarīgi OVS komponenti, kas jums jāzina:

  • Kodola modulis ā€” komponents, kas atrodas kodola telpā, kas apstrādā trafiku, pamatojoties uz noteikumiem, kas saņemti no vadÄ«bas elementa;
  • vSlēdzis dēmons (ovs-vswitchd) ir lietotāja telpā palaists process, kas ir atbildÄ«gs par kodola moduļa programmÄ“Å”anu - tas ir, tas tieÅ”i atspoguļo slēdža darbÄ«bas loÄ£iku
  • Datu bāzes serveris - lokālā datu bāze, kas atrodas katrā resursdatorā, kurā darbojas OVS, un kurā tiek saglabāta konfigurācija. SDN kontrolleri var sazināties, izmantojot Å”o moduli, izmantojot OVSDB protokolu.

Tam visam ir pievienots diagnostikas un pārvaldības utilītu komplekts, piemēram, ovs-vsctl, ovs-appctl, ovs-ofctl utt.

PaÅ”laik Openstack plaÅ”i izmanto telekomunikāciju operatori, lai uz to migrētu tÄ«kla funkcijas, piemēram, EPC, SBC, HLR u.c. Dažas funkcijas var darboties bez problēmām ar tādu OVS, kāds tas ir, bet, piemēram, EPC apstrādā abonentu trafiku - tad tas iet cauri. milzÄ«gs satiksmes apjoms (tagad trafika apjoms sasniedz vairākus simtus gigabitu sekundē). Protams, Ŕādas trafika vadÄ«Å”ana caur kodola vietu (jo ekspeditors pēc noklusējuma atrodas tur) nav labākā ideja. Tāpēc OVS bieži tiek pilnÄ«bā izvietots lietotāju telpā, izmantojot DPDK paātrinājuma tehnoloÄ£iju, lai pārsÅ«tÄ«tu trafiku no NIC uz lietotāja vietu, apejot kodolu.

PiezÄ«me: mākonim, kas izvietots telekomunikāciju funkcijām, ir iespējams izvadÄ«t trafiku no skaitļoÅ”anas mezgla, apejot OVS, tieÅ”i uz komutācijas aprÄ«kojumu. Å im nolÅ«kam tiek izmantoti SR-IOV un Passthrough mehānismi.

Kā tas darbojas reālā izkārtojumā?

Nu, tagad pāriesim uz praktisko daļu un redzēsim, kā tas viss darbojas praksē.

Vispirms izvietosim vienkārÅ”u Openstack instalāciju. Tā kā man nav pie rokas serveru komplekta eksperimentiem, mēs saliksim prototipu vienā fiziskajā serverÄ« no virtuālajām maŔīnām. Jā, dabiski, ka Ŕāds risinājums nav piemērots komerciāliem nolÅ«kiem, taču, lai redzētu piemēru, kā Openstack darbojas tÄ«kls, ar Ŕādu instalāciju acÄ«m pietiek. Turklāt Ŕāda instalācija ir vēl interesantāka apmācÄ«bas nolÅ«kos - jo jÅ«s varat noÄ·ert satiksmi utt.

Tā kā mums ir jāredz tikai pamata daļa, mēs nevaram izmantot vairākus tÄ«klus, bet visu pacelt, izmantojot tikai divus tÄ«klus, un otrs tÄ«kls Å”ajā izkārtojumā tiks izmantots tikai piekļuvei undercloud un DNS serverim. Pagaidām mēs nepieskaramies ārējiem tÄ«kliem - Ŕī ir atseviŔķa liela raksta tēma.

Tātad, sāksim secÄ«bā. Pirmkārt, neliela teorija. Mēs instalēsim Openstack, izmantojot TripleO (Openstack uz Openstack). TripleO bÅ«tÄ«ba ir tāda, ka mēs instalējam Openstack all-in-one (tas ir, vienā mezglā), ko sauc par undercloud, un pēc tam izmantojam izvietotā Openstack iespējas, lai instalētu darbÄ«bai paredzēto Openstack, ko sauc par overcloud. Undercloud izmantos tai piemÄ«toÅ”o spēju pārvaldÄ«t fiziskos serverus (bezmetāla) ā€” Ironic projektu ā€”, lai nodroÅ”inātu hipervizorus, kas pildÄ«s skaitļoÅ”anas, vadÄ«bas un uzglabāŔanas mezglu funkcijas. Tas nozÄ«mē, ka mēs neizmantojam nekādus treÅ”o puÅ”u rÄ«kus, lai izvietotu Openstack ā€” mēs izvietojam Openstack, izmantojot Openstack. InstalÄ“Å”anas gaitā tas kļūs daudz skaidrāks, tāpēc mēs neapstāsimies un virzÄ«simies uz priekÅ”u.

PiezÄ«me. Å ajā rakstā vienkārŔības labad es neizmantoju tÄ«kla izolāciju iekŔējiem Openstack tÄ«kliem, bet viss tiek izvietots, izmantojot tikai vienu tÄ«klu. Taču tÄ«kla izolācijas esamÄ«ba vai neesamÄ«ba neietekmē risinājuma pamata funkcionalitāti ā€“ viss darbosies tieÅ”i tāpat, kā lietojot izolāciju, taču trafika plÅ«dÄ«s tajā paŔā tÄ«klā. Komerciālai instalācijai, protams, ir jāizmanto izolācija, izmantojot dažādus vlanus un saskarnes. Piemēram, ceph krātuves pārvaldÄ«bas trafiks un pati datu trafika (maŔīnas piekļuve diskiem utt.), kad tā ir izolēta, izmanto dažādus apakÅ”tÄ«klus (Storage management un Storage), un tas ļauj risinājumu padarÄ«t izturÄ«gāku pret kļūmēm, piemēram, sadalot Å”o trafiku. , izmantojot dažādus portus vai izmantojot dažādus QoS profilus dažādai trafikai, lai datu trafiks neizspiestu signalizācijas trafiku. MÅ«su gadÄ«jumā tie darbosies vienā tÄ«klā, un patiesÄ«bā tas mÅ«s nekādi neierobežo.

PiezÄ«me. Tā kā virtuālās maŔīnas darbināsim virtuālajā vidē, kuras pamatā ir virtuālās maŔīnas, vispirms ir jāiespējo ligzdotā virtualizācija.

Varat pārbaudÄ«t, vai ligzdotā virtualizācija ir iespējota vai nav, Ŕādi:


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

Ja redzat burtu N, mēs iespējojam atbalstu ligzdotai virtualizācijai saskaņā ar jebkuru ceļvedi, ko atrodat tÄ«klā, piemēram, Ŕāds .

Mums ir jāsamontē Ŕāda ķēde no virtuālajām maŔīnām:

Ievads mākoņa infrastruktūras tīkla daļā

Manā gadījumā, lai savienotu virtuālās maŔīnas, kas ir daļa no turpmākās instalācijas (un man ir 7 no tām, bet jūs varat iztikt ar 4, ja jums nav daudz resursu), es izmantoju OpenvSwitch. Es izveidoju vienu ovs tiltu un pievienoju tam virtuālās maŔīnas, izmantojot portu grupas. Lai to izdarītu, es izveidoju Ŕādu xml failu:


[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>

Å eit ir deklarētas trÄ«s portu grupas - divas piekļuves un viena maÄ£istrāle (pēdējā bija nepiecieÅ”ama DNS serverim, bet jÅ«s varat iztikt bez tā vai instalēt to resursdatorā - kā jums ērtāk). Pēc tam, izmantojot Å”o veidni, mēs deklarējam savu, izmantojot virsh net-define:


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

Tagad mēs rediģējam hipervizora porta konfigurācijas:


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

PiezÄ«me: Å”ajā gadÄ«jumā adrese portā ovs-br1 nebÅ«s pieejama, jo tai nav vlan taga. Lai to novērstu, jums ir jāizdod komanda sudo ovs-vsctl set port ovs-br1 tag=100. Tomēr pēc pārstartÄ“Å”anas Å”is tags pazudÄ«s (ja kāds zina, kā likt tam palikt vietā, bÅ«Å”u ļoti pateicÄ«gs). Bet tas nav tik svarÄ«gi, jo Ŕī adrese mums bÅ«s nepiecieÅ”ama tikai instalÄ“Å”anas laikā un nebÅ«s vajadzÄ«ga, kad Openstack bÅ«s pilnÄ«bā izvietots.

Tālāk mēs izveidojam mākoņdatoÅ”anas maŔīnu:


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

InstalÄ“Å”anas laikā jÅ«s iestatāt visus nepiecieÅ”amos parametrus, piemēram, maŔīnas nosaukumu, paroles, lietotājus, ntp serverus utt., jÅ«s varat uzreiz konfigurēt portus, bet man personÄ«gi pēc instalÄ“Å”anas ir vieglāk pieteikties maŔīnā caur konsoli un labojiet nepiecieÅ”amos failus. Ja jums jau ir gatavs attēls, varat to izmantot vai darÄ«t to, ko es darÄ«ju - lejupielādējiet minimālo Centos 7 attēlu un izmantojiet to VM instalÄ“Å”anai.

Pēc veiksmÄ«gas instalÄ“Å”anas jums vajadzētu bÅ«t virtuālai maŔīnai, kurā varat instalēt zem mākoņa


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

Vispirms instalējiet instalÄ“Å”anas procesam nepiecieÅ”amos rÄ«kus:

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

Undercloud uzstādīŔana

Mēs izveidojam steka lietotāju, iestatām paroli, pievienojam to sudoer un dodam viņam iespēju izpildīt root komandas, izmantojot sudo, neievadot paroli:


useradd stack
passwd stack

echo ā€œstack ALL=(root) NOPASSWD:ALLā€ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

Tagad saimniekdatora failā mēs norādām pilnu mākoņa nosaukumu:


vi /etc/hosts

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

Tālāk mēs pievienojam krātuves un instalējam nepiecieÅ”amo programmatÅ«ru:


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

Piezīme: ja neplānojat instalēt ceph, jums nav jāievada ar ceph saistītas komandas. Es izmantoju Queens izlaidumu, bet jūs varat izmantot jebkuru citu, kas jums patīk.

Pēc tam nokopējiet mākoņdatoÅ”anas konfigurācijas failu lietotāja mājas direktoriju kaudzē:


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

Tagad mums ir jālabo Ŕis fails, pielāgojot to mūsu instalācijai.

Faila sākumā jāpievieno Ŕīs rindas:

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

Tātad, iesim cauri iestatījumiem:

undercloud_hostname ā€” pilnam mākoņa servera nosaukumam jāsakrÄ«t ar DNS servera ierakstu

vietējais_ip ā€” lokālā mākoņdatoÅ”anas adrese tÄ«kla nodroÅ”ināŔanai

network_gateway ā€” tā pati vietējā adrese, kas darbosies kā vārteja piekļuvei ārpasaulei mākoņu mezglu uzstādÄ«Å”anas laikā, sakrÄ«t arÄ« ar vietējo IP

undercloud_public_host ā€” ārējā API adrese, tiek pieŔķirta jebkura brÄ«va adrese no nodroÅ”ināŔanas tÄ«kla

undercloud_admin_host iekŔējā API adrese, tiek pieŔķirta jebkura bezmaksas adrese no nodroÅ”ināŔanas tÄ«kla

undercloud_nameservers ā€” DNS serveris

Gene_service_certificate - Ŕī rinda ir ļoti svarÄ«ga paÅ”reizējā piemērā, jo, ja jÅ«s to neiestatÄ«sit uz false, instalÄ“Å”anas laikā tiks parādÄ«ta kļūda, problēma ir aprakstÄ«ta Red Hat kļūdu izsekotājā

vietējais_interfeiss saskarne tÄ«kla nodroÅ”ināŔanā. Å is interfeiss tiks pārkonfigurēts undercloud izvietoÅ”anas laikā, tāpēc jums ir jābÅ«t diviem interfeisiem undercloud ā€” vienai, lai piekļūtu tai, otrai ā€” nodroÅ”ināŔanai.

local_mtu ā€” MTU. Tā kā mums ir testÄ“Å”anas laboratorija un man ir MTU 1500 uz OVS slēdža portiem, ir jāiestata uz 1450, lai VxLAN iekapsulētās paketes varētu iziet cauri.

tÄ«kls_cidr ā€” nodroÅ”ināŔanas tÄ«kls

maskarāde ā€” izmantojot NAT, lai piekļūtu ārējam tÄ«klam

masquerade_network - tīkls, kas tiks savienots ar NAT

dhcp_start ā€” adreÅ”u kopas sākuma adrese, no kuras adreses tiks pieŔķirtas mezgliem mākoņa izvietoÅ”anas laikā

dhcp_end ā€” adreÅ”u kopas galÄ«gā adrese, no kuras adreses tiks pieŔķirtas mezgliem mākoņa izvietoÅ”anas laikā

inspekcijas_izlaide ā€” adreÅ”u kopums, kas nepiecieÅ”ams paÅ”pārbaudei (nedrÄ«kst pārklāties ar iepriekÅ” minēto kopu)

scheduler_max_attempts ā€” maksimālais mākoņu uzstādÄ«Å”anas mēģinājumu skaits (jābÅ«t lielākam vai vienādam ar mezglu skaitu)

Kad fails ir aprakstīts, varat dot komandu izvietot undercloud:


openstack undercloud install

ProcedÅ«ra ilgst no 10 lÄ«dz 30 minÅ«tēm atkarÄ«bā no jÅ«su gludekļa. Galu galā jums vajadzētu redzēt Ŕādu izvadi:

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.

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

Šī izvade norāda, ka esat veiksmīgi instalējis undercloud, un tagad varat pārbaudīt undercloud statusu un turpināt instalēt overcloud.

Ja paskatās uz ifconfig izvadi, jūs redzēsit, ka ir parādījies jauns tilta interfeiss

[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

Overcloud izvietoŔana tagad tiks veikta, izmantojot Ŕo saskarni.

No tālāk redzamās produkcijas varat redzēt, ka mums visi pakalpojumi ir vienā mezglā:

(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     |
+--------------------------+-----------+----------+

Zemāk ir mākoņa tīkla daļas konfigurācija:


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

Overcloud uzstādīŔana

Å obrÄ«d mums ir tikai mākonis, un mums nav pietiekami daudz mezglu, no kuriem tiks montēti mākoņi. Tāpēc, pirmkārt, izvietosim mums nepiecieÅ”amās virtuālās maŔīnas. IzvietoÅ”anas laikā Undercloud pats instalēs OS un nepiecieÅ”amo programmatÅ«ru overcloud maŔīnā - tas ir, mums nav pilnÄ«bā jāizvieto maŔīna, bet tikai jāizveido tai disks (vai diski) un jānosaka tā parametri - tas ir. , patiesÄ«bā mēs iegÅ«stam tukÅ”u serveri, kurā nav instalēta OS.

Dosimies uz mapi ar mÅ«su virtuālo maŔīnu diskiem un izveidosim vajadzÄ«gā izmēra diskus:


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

Tā kā mēs darbojamies kā root, mums ir jāmaina Å”o disku Ä«paÅ”nieks, lai nerastos problēmas ar tiesÄ«bām:


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

Piezīme: ja neplānojat instalēt ceph, lai to izpētītu, tad komandas neveido vismaz 3 mezglus ar vismaz diviem diskiem, bet veidnē norāda, ka tiks izmantoti virtuālie diski vda, vdb utt.

Lieliski, tagad mums ir jādefinē visas Ŕīs maŔīnas:


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 

Beigās ir komanda -print-xml > /tmp/storage-1.xml, kas izveido xml failu ar katras maŔīnas aprakstu mapē /tmp/; ja jÅ«s to nepievienosit, jÅ«s vairs nebÅ«siet. spēj identificēt virtuālās maŔīnas.

Tagad mums ir jādefinē visas Ŕīs maŔīnas 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 ~]#

Tagad neliela nianse ā€“ tripleO izmanto IPMI, lai pārvaldÄ«tu serverus instalÄ“Å”anas un paÅ”pārbaudes laikā.

Introspekcija ir aparatÅ«ras pārbaudes process, lai iegÅ«tu tās parametrus, kas nepiecieÅ”ami tālākai mezglu nodroÅ”ināŔanai. Introspekcija tiek veikta, izmantojot ironiju, pakalpojumu, kas paredzēts darbam ar tukÅ”a metāla serveriem.

Bet Å”eit ir problēma - lai gan aparatÅ«ras IPMI serveriem ir atseviŔķs ports (vai koplietots ports, bet tas nav svarÄ«gi), virtuālajām maŔīnām Ŕādu portu nav. Å eit mums palÄ«dz kruÄ·is ar nosaukumu vbmc - utilÄ«ta, kas ļauj emulēt IPMI portu. Å ai niansei ir vērts pievērst uzmanÄ«bu Ä«paÅ”i tiem, kas vēlas izveidot Ŕādu laboratoriju uz ESXI hipervizora - godÄ«gi sakot, es nezinu, vai tam ir vbmc analogs, tāpēc ir vērts padomāt par Å”o problēmu pirms visa izvietoÅ”anas. .

Instalējiet vbmc:


yum install yum install python2-virtualbmc

Ja jūsu operētājsistēma nevar atrast pakotni, pievienojiet repozitoriju:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

Tagad mēs iestatām utilītu. Šeit viss ir banāli līdz apkaunojumam. Tagad loģiski, ka vbmc sarakstā nav neviena servera


[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

Lai tie tiktu parādÄ«ti, tie ir manuāli jādeklarē Ŕādi:


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

Es domāju, ka komandu sintakse ir skaidra bez paskaidrojumiem. Tomēr pagaidām visas mūsu sesijas ir DOWN statusā. Lai tie pārietu uz UP statusu, tie ir jāiespējo:


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

Un pēdējais pieskāriens - jums ir jālabo ugunsmūra noteikumi (vai pilnībā jāatspējo):


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

Tagad pāriesim uz mākoņiem un pārbaudÄ«sim, vai viss darbojas. ResursmaŔīnas adrese ir 192.168.255.200, mākoņdatnē mēs pievienojām nepiecieÅ”amo ipmitool pakotni, gatavojoties izvietoÅ”anai:


[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

Kā redzat, mēs esam veiksmÄ«gi palaiduÅ”i vadÄ«bas mezglu, izmantojot vbmc. Tagad izslēgsim to un turpināsim:


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

Nākamais solis ir to mezglu introspekcija, uz kuriem tiks uzstādÄ«ts mākonis. Lai to izdarÄ«tu, mums ir jāsagatavo json fails ar mÅ«su mezglu aprakstu. LÅ«dzu, ņemiet vērā, ka atŔķirÄ«bā no instalÄ“Å”anas uz tukÅ”iem serveriem fails norāda portu, kurā darbojas vbmc katrai maŔīnai.


[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

Piezīme: vadības mezglam ir divas saskarnes, taču Ŕajā gadījumā tas nav svarīgi, Ŕajā instalācijā mums pietiks ar vienu.

Tagad mēs sagatavojam json failu. Mums jānorāda porta magoņu adrese, caur kuru tiks veikta nodroÅ”ināŔana, mezglu parametri, jāpieŔķir tiem nosaukumi un jānorāda, kā nokļūt 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"
        }
    ]
}

Tagad mums ir jāsagatavo attēli ironijai. Lai to izdarītu, lejupielādējiet tos, izmantojot wget, un instalējiet:

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

Attēlu augÅ”upielāde mākoņos:

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

Pārbauda, ā€‹ā€‹vai visi attēli ir ielādēti


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

Vēl viena lieta - jums jāpievieno DNS serveris:


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

Tagad mēs varam dot komandu paÅ”pārbaudei:

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

Kā redzat no izvades, viss tika pabeigts bez kļūdām. Pārbaudīsim, vai visi mezgli ir pieejamajā stāvoklī:


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

Ja mezgli ir citā stāvoklÄ«, parasti pārvaldāmi, tad kaut kas nogāja greizi, un jums ir jāaplÅ«ko žurnāls un jānoskaidro, kāpēc tas notika. Ņemiet vērā, ka Å”ajā scenārijā mēs izmantojam virtualizāciju un var bÅ«t kļūdas, kas saistÄ«tas ar virtuālo maŔīnu vai vbmc izmantoÅ”anu.

Tālāk mums jānorāda, kurŔ mezgls kādu funkciju pildīs, tas ir, jānorāda profils, ar kuru mezgls izvietos:


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

Norādiet katra mezgla profilu:


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

Pārbaudīsim, vai mēs visu izdarījām pareizi:


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

Ja viss ir pareizi, mēs dodam komandu izvietot overcloud:

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

Reālā instalācijā, protams, tiks izmantotas pielāgotas veidnes, mÅ«su gadÄ«jumā tas ievērojami sarežģīs procesu, jo katrs veidnes labojums bÅ«s jāpaskaidro. Kā jau tika rakstÄ«ts iepriekÅ”, pat ar vienkārÅ”u instalāciju mums pietiks, lai redzētu, kā tā darbojas.

PiezÄ«me: Å”ajā gadÄ«jumā ir nepiecieÅ”ams mainÄ«gais --libvirt tipa qemu, jo mēs izmantosim ligzdotu virtualizāciju. Pretējā gadÄ«jumā jÅ«s nevarēsit palaist virtuālās maŔīnas.

Tagad jums ir aptuveni stunda vai varbÅ«t vairāk (atkarÄ«bā no aparatÅ«ras iespējām), un jÅ«s varat tikai cerēt, ka pēc Ŕī laika jÅ«s redzēsit Ŕādu ziņojumu:


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

Tagad jums ir gandrīz pilnvērtīga openstack versija, kurā varat mācīties, eksperimentēt utt.

PārbaudÄ«sim, vai viss darbojas pareizi. Lietotāja mājas direktoriju stekā ir divi faili ā€“ viens stackrc (undercloud pārvaldÄ«bai) un otrs overcloudrc (overcloud pārvaldÄ«Å”anai). Å ie faili ir jānorāda kā avots, jo tie satur autentifikācijai nepiecieÅ”amo informāciju.


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

Manai instalÄ“Å”anai joprojām ir nepiecieÅ”ams neliels pieskāriens - marÅ”ruta pievienoÅ”ana kontrollerÄ«, jo iekārta, ar kuru es strādāju, atrodas citā tÄ«klā. Lai to izdarÄ«tu, siltuma administratora kontā dodieties uz kontroli-1 un reÄ£istrējiet marÅ”rutu


(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

Nu, tagad jūs varat doties uz horizontu. Visa informācija - adreses, pieteikŔanās vārds un parole - atrodas failā /home/stack/overcloudrc. Galīgā diagramma izskatās Ŕādi:

Ievads mākoņa infrastruktūras tīkla daļā

Starp citu, mÅ«su instalācijā maŔīnu adreses tika izsniegtas, izmantojot DHCP, un, kā redzat, tās tiek izsniegtas ā€œnejauÅ”iā€. Veidnē varat stingri noteikt, kura adrese ir jāpievieno kurai maŔīnai izvietoÅ”anas laikā, ja jums tā ir nepiecieÅ”ama.

Kā notiek trafika plūsma starp virtuālajām maŔīnām?

Å ajā rakstā mēs apskatÄ«sim trÄ«s iespējas garāmbraucoÅ”ai satiksmei

  • Divas maŔīnas vienā hipervizorā vienā L2 tÄ«klā
  • Divas maŔīnas dažādos hipervizoros vienā L2 tÄ«klā
  • Divas maŔīnas dažādos tÄ«klos (starptÄ«klu sakņoÅ”ana)

GadÄ«jumus ar piekļuvi ārējai pasaulei, izmantojot ārējo tÄ«klu, izmantojot peldoŔās adreses, kā arÄ« izkliedētu marÅ”rutÄ“Å”anu, mēs izskatÄ«sim nākamreiz, pagaidām koncentrēsimies uz iekŔējo trafiku.

Lai pārbaudītu, izveidosim Ŕādu diagrammu:

Ievads mākoņa infrastruktūras tīkla daļā

Mēs esam izveidojuÅ”i 4 virtuālās maŔīnas - 3 vienā L2 tÄ«klā - net-1 un vēl 1 tÄ«klā net-2

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

Apskatīsim, kādos hipervizoros atrodas izveidotās maŔīnas:

(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) [steck@undercloud ~]$
MaŔīnas vm-1 un vm-3 atrodas uz compute-0, maŔīnas vm-2 un vm-4 atrodas mezglā compute-1.

Turklāt ir izveidots virtuālais marÅ”rutētājs, lai nodroÅ”inātu marÅ”rutÄ“Å”anu starp norādÄ«tajiem tÄ«kliem:

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

MarÅ”rutētājam ir divi virtuālie porti, kas darbojas kā vārtejas tÄ«kliem:

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

Bet pirms mēs aplÅ«kojam trafika plÅ«smu, apskatÄ«sim, kas mums paÅ”laik ir vadÄ«bas mezglā (kas arÄ« ir tÄ«kla mezgls) un skaitļoÅ”anas mezglā. Sāksim ar skaitļoÅ”anas mezglu.


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

Å obrÄ«d mezglā ir trÄ«s ovs tilti - br-int, br-tun, br-ex. Starp tiem, kā mēs redzam, ir saskarņu kopums. Lai atvieglotu izpratni, uzzÄ«mēsim visas Ŕīs saskarnes diagrammā un redzēsim, kas notiek.

Ievads mākoņa infrastruktūras tīkla daļā

AplÅ«kojot adreses, uz kurām tiek pacelti VxLAN tuneļi, redzams, ka viens tunelis ir paaugstināts uz compute-1 (192.168.255.26), otrs tunelis izskatās uz control-1 (192.168.255.15). Bet pats interesantākais ir tas, ka br-ex nav fizisku saskarņu, un, ja paskatās, kādas plÅ«smas ir konfigurētas, var redzēt, ka Å”is tilts Å”obrÄ«d var tikai atmest satiksmi.


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

Kā redzat no izejas, adrese tiek pieskrÅ«vēta tieÅ”i fiziskajam portam, nevis virtuālā tilta saskarnei.


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

Saskaņā ar pirmo noteikumu viss, kas nāca no phy-br-ex porta, ir jāizmet.
PatiesÄ«bā Å”obrÄ«d nav kur citur satiksmei iekļūt Å”ajā tiltā, izņemot no Ŕīs saskarnes (saskarne ar br-int), un, spriežot pēc kritumiem, BUM satiksme jau ir ieplÅ«dusi tiltā.

Tas nozÄ«mē, ka satiksme var atstāt Å”o mezglu tikai caur VxLAN tuneli un neko citu. Taču, ja ieslēdzat DVR, situācija mainÄ«sies, bet ar to tiksim galā citreiz. Izmantojot tÄ«kla izolāciju, piemēram, izmantojot vlans, jums bÅ«s nevis viens L3 interfeiss vlan 0, bet gan vairākas saskarnes. Tomēr VxLAN trafiks iziet no mezgla tādā paŔā veidā, bet arÄ« iekapsulēts kaut kādā Ä«paŔā VLAN.

Mēs esam sakārtojuÅ”i aprēķina mezglu, pāriesim uz vadÄ«bas mezglu.


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

PatiesÄ«bā mēs varam teikt, ka viss ir vienāds, bet IP adrese vairs nav fiziskajā saskarnē, bet gan virtuālajā tiltā. Tas tiek darÄ«ts, jo Ŕī osta ir osta, caur kuru satiksme izies uz ārpasauli.


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

Å is ports ir piesaistÄ«ts br-ex tiltam un, tā kā uz tā nav vlan tagu, Å”is ports ir maÄ£istrālais ports, kurā ir atļauti visi vlani, tagad satiksme iet ārpusē bez atzÄ«mes, kā to norāda vlan-id 0 izvade iepriekÅ”.

Ievads mākoņa infrastruktūras tīkla daļā

Viss pārējais Å”obrÄ«d ir lÄ«dzÄ«gs skaitļoÅ”anas mezglam - tie paÅ”i tilti, tie paÅ”i tuneļi, kas iet uz diviem skaitļoÅ”anas mezgliem.

Å ajā rakstā mēs neapskatÄ«sim krātuves mezglus, taču, lai saprastu, jāsaka, ka Å”o mezglu tÄ«kla daļa ir banāla lÄ«dz apkaunojuma vietai. MÅ«su gadÄ«jumā ir tikai viens fiziskais ports (eth0) ar tam pieŔķirtu IP adresi, un tas arÄ« viss. Nav VxLAN tuneļu, tuneļu tiltu u.c. - ovs vispār nav, jo nav jēgas. Izmantojot tÄ«kla izolāciju, Å”im mezglam bÅ«s divas saskarnes (fiziskie porti, bodny vai tikai divi VLAN ā€” tas nav svarÄ«gi ā€” tas ir atkarÄ«gs no tā, ko vēlaties) - viens pārvaldÄ«bai, otrs trafikam (rakstÄ«Å”anai VM diskā , lasÄ«Å”ana no diska utt.)

Mēs noskaidrojām, kas mums ir uz mezgliem, ja nebija pakalpojumu. Tagad palaidÄ«sim 4 virtuālās maŔīnas un redzēsim, kā mainās iepriekÅ” aprakstÄ«tā shēma - mums vajadzētu bÅ«t portiem, virtuālajiem marÅ”rutētājiem utt.

Līdz Ŕim mūsu tīkls izskatās Ŕādi:

Ievads mākoņa infrastruktūras tīkla daļā

Mums ir divas virtuālās maŔīnas katrā datora mezglā. Izmantojot compute-0 kā piemēru, redzēsim, kā viss ir iekļauts.


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

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

Iekārtai ir tikai viens virtuālais interfeiss - 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 ~]$ 

Šis interfeiss izskatās Linux tiltā:

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

Kā redzat no izejas, tiltā ir tikai divas saskarnes - tap95d96a75-a0 un qvb95d96a75-a0.

Šeit ir vērts nedaudz pakavēties pie OpenStack virtuālā tīkla ierīču veidiem:
vtap ā€” virtuālais interfeiss, kas pievienots instancei (VM)
qbr - Linux tilts
qvb un qvo - vEth pāris, kas savienots ar Linux tiltu un Open vSwitch tiltu
br-int, br-tun, br-vlan ā€” atveriet vSwitch tiltus
patch-, int-br-, phy-br- ā€” atvērt vSwitch ielāpu saskarnes, kas savieno tiltus
qg, qr, ha, fg, sg ā€” atver vSwitch portus, ko izmanto virtuālās ierÄ«ces, lai izveidotu savienojumu ar OVS

Kā jūs saprotat, ja mums tiltā ir qvb95d96a75-a0 ports, kas ir vEth pāris, tad kaut kur ir tā līdzinieks, kuru loģiski vajadzētu saukt par qvo95d96a75-a0. Apskatīsim, kādi porti ir uz OVS.


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

Kā redzam, osta atrodas br-int. Br-int darbojas kā slēdzis, kas pārtrauc virtuālās maŔīnas portus. Papildus qvo95d96a75-a0 izvadā ir redzams ports qvo5bd37136-47. Å is ir ports uz otro virtuālo maŔīnu. Rezultātā mÅ«su diagramma tagad izskatās Ŕādi:

Ievads mākoņa infrastruktūras tīkla daļā

Jautājums, kuram uzreiz vajadzētu interesēt vērÄ«go lasÄ«tāju - kāds ir linux tilts starp virtuālās maŔīnas portu un OVS portu? Fakts ir tāds, ka maŔīnas aizsardzÄ«bai tiek izmantotas droŔības grupas, kas ir nekas vairāk kā iptables. OVS nedarbojas ar iptables, tāpēc tika izgudrots Å”is ā€œkruÄ·isā€. Tomēr tas kļūst novecojis - tas tiek aizstāts ar conntrack jaunajos izlaidumos.

Tas ir, galu galā shēma izskatās Ŕādi:

Ievads mākoņa infrastruktūras tīkla daļā

Divas maŔīnas vienā hipervizorā vienā L2 tīklā

Tā kā Ŕīs divas virtuālās maŔīnas atrodas tajā paŔā L2 tīklā un tajā paŔā hipervizorā, satiksme starp tām loģiski plūst lokāli caur br-int, jo abas maŔīnas būs vienā 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 ~]$ 

Divas maŔīnas dažādos hipervizoros vienā L2 tīklā

Tagad redzēsim, kā trafiks notiks starp divām maŔīnām tajā paŔā L2 tÄ«klā, bet kas atrodas dažādos hipervizoros. Ja godÄ«gi, nekas Ä«paÅ”i nemainÄ«sies, tikai satiksme starp hipervizoriem ies caur vxlan tuneli. ApskatÄ«sim piemēru.

To virtuālo maŔīnu adreses, starp kurām mēs vērosim trafiku:

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

Mēs aplÅ«kojam pārsÅ«tÄ«Å”anas tabulu br-int skaitļoÅ”anā-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 ~]

Satiksmei vajadzētu virzÄ«ties uz 2. portu ā€” paskatÄ«simies, kāda veida osta tas ir:

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

Tas ir patch-tun - tas ir, interfeiss br-tun. Apskatīsim, kas notiek ar br-tun paku:

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

Pakete tiek iesaiņota VxLAN un nosÅ«tÄ«ta uz 2. portu. ApskatÄ«sim, kur ved 2. ports:

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

Å is ir vxlan tunelis uz compute-1:

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

Dosimies uz compute-1 un redzēsim, kas notiks tālāk ar paketi:

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

Mac ir br-int pārsūtīŔanas tabulā compute-1, un, kā redzams no iepriekŔ esoŔās izvades, tas ir redzams caur portu 2, kas ir ports virzienā uz br-tun:

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

Nu, tad mēs redzam, ka br-int uz compute-1 ir galamērķa magone:

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

Tas ir, saņemtā pakete lidos uz portu 3, aiz kura jau atrodas virtuālās maŔīnas instance-00000003.

Openstack izvietoÅ”ana mācÄ«bām virtuālajā infrastruktÅ«rā ir tāda, ka mēs varam viegli uztvert trafiku starp hipervizoriem un redzēt, kas ar to notiek. Tas ir tas, ko mēs tagad darÄ«sim, palaidÄ«sim tcpdump vnet portā virzienā uz compute-0:


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

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

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

Pirmajā rindā redzams, ka Patek no adreses 10.0.1.85 dodas uz adresi 10.0.1.88 (ICMP trafiks), un tas ir iesaiņots VxLAN paketē ar vni 22, un pakete pāriet no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.26. .1 ( aprēķina-XNUMX). Varam pārbaudÄ«t, vai VNÄŖ atbilst ovs norādÄ«tajam.

AtgriezÄ«simies pie Ŕīs rindas action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:2. 0x16 ir vni heksadecimālajā skaitļu sistēmā. Pārveidosim Å”o skaitli 16. sistēmā:


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

Tas ir, vni atbilst realitātei.

Otrajā rindā redzama atgrieÅ”anās satiksme, nu, nav jēgas to skaidrot, tur viss skaidrs.

Divas maŔīnas dažādos tÄ«klos (starptÄ«klu marÅ”rutÄ“Å”ana)

Pēdējais gadÄ«jums Å”odien ir marÅ”rutÄ“Å”ana starp tÄ«kliem viena projekta ietvaros, izmantojot virtuālo marÅ”rutētāju. Mēs apsveram gadÄ«jumu bez DVR (mēs to aplÅ«kosim citā rakstā), tāpēc marÅ”rutÄ“Å”ana notiek tÄ«kla mezglā. MÅ«su gadÄ«jumā tÄ«kla mezgls nav ievietots atseviŔķā entÄ«tijā un atrodas vadÄ«bas mezglā.

Vispirms apskatīsim, vai marŔrutēŔana darbojas:

$ 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

Tā kā Å”ajā gadÄ«jumā paketei ir jāiet uz vārteju un jānovirza tur, mums ir jānoskaidro vārtejas magones adrese, kuras gadÄ«jumā mēs skatāmies uz ARP tabulu:

$ 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

Tagad paskatīsimies, kur jānosūta satiksme ar galamērķi (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 ~]$ 

ApskatÄ«sim, kurp ved 2. ports:

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

Viss loģiski, satiksme iet uz br-tun. Apskatīsim, kurā vxlan tunelī tas tiks ietīts:

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

TreŔais ports ir vxlan tunelis:

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

Kas aplūko vadības mezglu:

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

Satiksme ir sasniegusi vadÄ«bas mezglu, tāpēc mums jādodas uz to un jāskatās, kā notiks marÅ”rutÄ“Å”ana.

Kā atceraties, vadÄ«bas mezgls iekŔā izskatÄ«jās tieÅ”i tāpat kā skaitļoÅ”anas mezgls - tie paÅ”i trÄ«s tilti, tikai br-ex bija fiziska pieslēgvieta, caur kuru mezgls varēja nosÅ«tÄ«t trafiku ārpusē. Instanču izveide mainÄ«ja konfigurāciju skaitļoÅ”anas mezglos - mezgliem tika pievienots linux tilts, iptables un saskarnes. TÄ«klu un virtuālā marÅ”rutētāja izveide arÄ« atstāja savas pēdas vadÄ«bas mezgla konfigurācijā.

Tātad ir skaidrs, ka vārtejas MAC adresei jābÅ«t vadÄ«bas mezgla br-int pārsÅ«tÄ«Å”anas tabulā. PārbaudÄ«sim, vai tas tur ir un kur tas meklē:

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

Mac ir redzams no porta qr-0c52b15f-8f. Ja mēs atgriežamies pie Openstack virtuālo portu saraksta, Ŕāda veida porti tiek izmantoti dažādu virtuālo ierīču savienoÅ”anai ar OVS. PrecÄ«zāk sakot, qr ir ports uz virtuālo marÅ”rutētāju, kas tiek attēlots kā nosaukumvieta.

Apskatīsim, kādas nosaukumvietas atrodas serverī:

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

Pat trÄ«s eksemplāri. Bet, spriežot pēc nosaukumiem, jÅ«s varat uzminēt katra no tiem mērÄ·i. Mēs vēlāk atgriezÄ«simies pie gadÄ«jumiem ar ID 0 un 1, tagad mÅ«s interesē nosaukumvieta 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 ~]$ 

Å ajā nosaukumvietā ir divas iekŔējās, kuras mēs izveidojām iepriekÅ”. Abi virtuālie porti ir pievienoti br-int. PārbaudÄ«sim porta qr-0c52b15f-8f mac adresi, jo trafiks, spriežot pēc galamērÄ·a mac adreses, nonāca Å”ajā saskarnē.

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

Tas ir, Å”ajā gadÄ«jumā viss darbojas saskaņā ar standarta marÅ”rutÄ“Å”anas likumiem. Tā kā trafiks ir paredzēts resursdatoram 10.0.2.8, tai ir jāiziet caur otro saskarni qr-92fa49b5-54 un jāiet cauri vxlan tuneli uz skaitļoÅ”anas mezglu:


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

Viss ir loģiski, bez pārsteigumiem. Apskatīsim, kur br-int ir redzama resursdatora 10.0.2.8 magones adrese:

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

Kā paredzēts, satiksme virzās uz br-tun, paskatīsimies, uz kuru tuneli satiksme virzīsies tālāk:

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

Satiksme ieiet tunelÄ«, lai aprēķinātu-1. Nu, compute-1 viss ir vienkārÅ”i - no br-tun pakotne nonāk br-int un no turienes uz virtuālās maŔīnas saskarni:

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

Pārbaudīsim, vai Ŕī patieŔām ir pareizā saskarne:

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

PatiesÄ«bā mēs izgājām cauri paku. Es domāju, ka pamanÄ«jāt, ka satiksme gāja pa dažādiem vxlan tuneļiem un izbrauca ar dažādiem VNI. ApskatÄ«sim, kas tie ir par VNI, pēc tam savāksim izgāztuvi mezgla vadÄ«bas portā un pārliecināsimies, ka satiksme notiek tieÅ”i tā, kā aprakstÄ«ts iepriekÅ”.
Tātad tunelim, lai aprēķinātu-0, ir Ŕādas darbÄ«bas=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:3. Pārveidosim 0x16 par decimālo skaitļu sistēmu:


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

Tunelim, lai aprēķinātu-1, ir Ŕāds VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],izeja:2. Pārveidosim 0x63 par decimālo skaitļu sistēmu:


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

Nu, tagad apskatīsim izgāztuvi:

[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*******************

Pirmā pakete ir vxlan pakete no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.15 (control-1) ar vni 22, kurā ir iesaiņota ICMP pakete no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. Kā mēs aprēķinājām iepriekÅ”, vni atbilst tam, ko mēs redzējām izvadē.

Otrā pakete ir vxlan pakete no resursdatora 192.168.255.15 (control-1) uz resursdatoru 192.168.255.26 (compute-1) ar vni 99, kurā ICMP pakete ir iepakota no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. Kā mēs aprēķinājām iepriekÅ”, vni atbilst tam, ko mēs redzējām izvadē.

Nākamās divas paketes ir atgriezeniskā trafika no 10.0.2.8, nevis 10.0.1.85.

Tas ir, galu galā mēs saņēmām Ŕādu vadÄ«bas mezgla shēmu:

Ievads mākoņa infrastruktūras tīkla daļā

Izskatās, ka tas tā ir? Mēs aizmirsām par divām nosaukumvietām:

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

Tā kā mēs runājām par mākoņa platformas arhitektÅ«ru, bÅ«tu labi, ja maŔīnas automātiski saņemtu adreses no DHCP servera. Å ie ir divi DHCP serveri mÅ«su diviem tÄ«kliem 10.0.1.0/24 un 10.0.2.0/24.

Pārbaudīsim, vai tā ir patiesība. Šajā nosaukumvietā ir tikai viena adrese - 10.0.1.1 - paŔa DHCP servera adrese, un tā ir iekļauta arī 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

Apskatīsim, vai procesi, kuru nosaukumā vadības mezglā ir ietverti 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 ~]$ 

Šāds process pastāv, un, pamatojoties uz iepriekÅ” iznākumā sniegto informāciju, mēs, piemēram, varam redzēt, kas mums Å”obrÄ«d ir Ä«rējams:

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

Rezultātā vadÄ«bas mezglā mēs iegÅ«stam Ŕādu pakalpojumu kopu:

Ievads mākoņa infrastruktūras tīkla daļā

Nu, paturiet prātā - Ŕīs ir tikai 4 maŔīnas, 2 iekŔējie tÄ«kli un viens virtuālais marÅ”rutētājs... Mums Å”eit nav ārējo tÄ«klu, ir daudz dažādu projektu, katram ir savi tÄ«kli (pārklājas), un mums ir sadalÄ«ts marÅ”rutētājs izslēdzās, un galu galā testa stendā bija tikai viens kontroles mezgls (lai nodroÅ”inātu kļūdu toleranci, ir jābÅ«t trÄ«s mezglu kvorumam). LoÄ£iski, ka tirdzniecÄ«bā viss ir ā€œnedaudzā€ sarežģītāk, taču Å”ajā vienkārÅ”ajā piemērā mēs saprotam, kā tam vajadzētu darboties ā€“ protams, ir svarÄ«gi, vai tev ir 3 vai 300 nosaukumvietas, bet no visas nosaukumvietas darbÄ«bas viedokļa. struktÅ«ra, nekas daudz nemainÄ«sies... lai gan, kamēr jÅ«s nepievienosiet kāda pārdevēja SDN. Bet tas ir pavisam cits stāsts.

Ceru, ka bija interesanti. Ja jums ir kādi komentāri/papildinājumi vai kaut kur es tieÅ”i meloju (esmu cilvēks un mans viedoklis vienmēr bÅ«s subjektÄ«vs) - rakstiet, kas jālabo/pievieno - visu labosim/pievienosim.

Nobeigumā es vēlos teikt dažus vārdus par Openstack (gan vaniļas, gan pārdevēja) salÄ«dzināŔanu ar mākoņrisinājumu no VMWare ā€” man Å”is jautājums pēdējo pāris gadu laikā ir uzdots pārāk bieži, un, atklāti sakot, es esmu jau apnicis, bet tomēr. Manuprāt, ir ļoti grÅ«ti salÄ«dzināt Å”os divus risinājumus, taču noteikti varam teikt, ka abiem risinājumiem ir trÅ«kumi un izvēloties vienu risinājumu ir jāizsver plusi un mÄ«nusi.

Ja OpenStack ir kopienas virzÄ«ts risinājums, tad VMWare ir tiesÄ«bas darÄ«t tikai to, ko vēlas (lasi - kas tam ir izdevÄ«gi) un tas ir loÄ£iski - jo tā ir komercsabiedrÄ«ba, kas ir pieradusi pelnÄ«t naudu no saviem klientiem. Bet ir viens liels un trekns BET - jÅ«s varat izkāpt no OpenStack, piemēram, no Nokia un ar nelieliem izdevumiem pāriet uz risinājumu, piemēram, no Juniper (Contrail Cloud), bet diez vai jÅ«s varēsit izkāpt no VMWare . Man Å”ie divi risinājumi izskatās Ŕādi - Openstack (vendor) ir vienkārÅ”s bÅ«ris, kurā tevi ieliek, bet tev ir atslēga un tu vari iziet jebkurā brÄ«dÄ«. VMWare ir zelta bÅ«ris, saimniekam ir bÅ«ra atslēga un tas tev izmaksās dārgi.

Es nereklamēju ne pirmo, ne otro produktu - jÅ«s izvēlaties to, kas jums nepiecieÅ”ams. Bet, ja man bÅ«tu tāda izvēle, es izvēlētos abus risinājumus - VMWare IT mākonim (zemas slodzes, vienkārÅ”a pārvaldÄ«ba), OpenStack no kāda pārdevēja (Nokia un Juniper nodroÅ”ina ļoti labus pabeigtus risinājumus) - Telecom mākonim. Es neizmantotu Openstack tikai IT vajadzÄ«bām - tas ir kā Å”aut uz zvirbuļiem ar lielgabalu, bet es neredzu nekādas kontrindikācijas tā lietoÅ”anai, izņemot atlaiÅ”anu. Tomēr VMWare izmantoÅ”ana telekomunikācijās ir kā Ŕķembu vilkÅ”ana ar Ford Raptor ā€” tas ir skaisti no ārpuses, bet vadÄ«tājam ir jāveic 10 braucieni, nevis viens.

Manuprāt lielākais VMWare mÄ«nuss ir tā pilnÄ«ga noslēgtÄ«ba - uzņēmums nedos nekādu informāciju par to kā tas darbojas, piemēram, vSAN vai kas atrodas hipervizora kodolā - tas viņam vienkārÅ”i nav izdevÄ«gi - proti, jÅ«s nekad nekļūsti par VMWare ekspertu ā€“ bez pārdevēja atbalsta tu esi lemts (ļoti bieži es sastopu VMWare ekspertus, kuri ir neizpratnē par triviāliem jautājumiem). Man VMWare pērk auto ar aizslēgtu motora pārsegu - jā, jums var bÅ«t speciālisti, kas var nomainÄ«t zobsiksnu, bet pārsegu var atvērt tikai tas, kurÅ” jums pārdeva Å”o risinājumu. PersonÄ«gi man nepatÄ«k risinājumi, kuros es nevaru iekļauties. Teiksiet, ka var nebÅ«t zem pārsega iet. Jā, tas ir iespējams, bet es paskatÄ«Å”os uz jums, kad jums bÅ«s jāsamontē liela funkcija mākonÄ« no 20-30 virtuālajām maŔīnām, 40-50 tÄ«kliem, no kuriem puse vēlas iet ārā, bet otrā puse prasa SR-IOV paātrinājums, pretējā gadÄ«jumā jums bÅ«s nepiecieÅ”ami vēl pāris desmiti Å”o automaŔīnu - pretējā gadÄ«jumā ar veiktspēju nepietiks.

Ir arÄ« citi viedokļi, tāpēc tikai jÅ«s varat izlemt, ko izvēlēties, un, pats galvenais, jÅ«s pēc tam bÅ«siet atbildÄ«gs par savu izvēli. Tas ir tikai mans viedoklis - cilvēks, kurÅ” ir redzējis un aptaustÄ«jis vismaz 4 produktus - Nokia, Juniper, Red Hat un VMWare. Tas ir, man ir ar ko salÄ«dzināt.

Avots: www.habr.com

Pievieno komentāru