Computația în cloud pătrunde tot mai adânc în viața noastră și probabil nu există o persoană care să nu fi folosit măcar o dată servicii cloud. Dar ce este, de fapt, norul și cum funcționează? În mare parte, puțini știu chiar la nivel de idee. 5G devine deja o realitate, iar infrastructura de telecomunicații începe să treacă de la soluții tradiționale la soluții cloud, așa cum a trecut de la soluții pur hardware la stâlpi virtualizați.
Astăzi vom vorbi despre lumea interioară a infrastructurii cloud, în special despre elementele de bază ale părții de rețea.
Ce este un nor? O simplă virtualizare — o viziune laterală?
Este o întrebare complet logică. Nu — nu este virtualizare, deși nu a fost sărăcită de ea. Să examinăm două definiții:
Computația în cloud (denumită în continuare Norul) — este un model de furnizare a accesului prietenos pentru utilizator la resurse de calcul distribuite, care trebuie să fie desfășurate și activate la cerere, cu cea mai mică întârziere posibilă și cele mai mici costuri din partea furnizorului de servicii.
Virtualizare — este posibilitatea de a împărți o entitate fizică (de exemplu, un server) în mai multe entități virtuale, crescând astfel utilizarea resurselor (de exemplu, dacă aveați 3 servere, încărcate la 25-30 la sută, după virtualizare obțineți 1 server, încărcat la 80-90 la sută). Desigur, virtualizarea consumă o parte din resurse — trebuie să hrăniți hypervizorul, totuși, așa cum a arătat practică, efortul merită. Un exemplu ideal de virtualizare este VMWare, care pregătește excelent mașinile virtuale, sau KVM, care îmi place mai mult, dar asta ține de gust.
Folosim virtualizarea fără să ne dăm seama, iar chiar și routerele hardware deja folosesc virtualizarea — de exemplu, în cele mai recente versiuni ale sistemului de operare JunOS, acesta este instalat ca o mașină virtuală deasupra unei distribuții Linux în timp real (Wind River 9). Dar virtualizarea nu este norul, totuși norul nu poate exista fără virtualizare.
Virtualizarea este una dintre cărămizile pe care se construiește norul.
Crearea unui cloud, adunând pur și simplu câțiva hypervizori într-un singur domeniu L2, adăugând câteva playbook-uri YAML pentru configurarea automată a VLAN-urilor prin Ansible și suprapus pe toate o soluție de orchestrare pentru crearea automată a mașinilor virtuale — nu va funcționa. Mai exact, va funcționa, dar Frankenstein-ul obținut nu este tipul de cloud de care avem nevoie; deși, bineînțeles, pentru unii poate acesta să fie visul suprem. În plus, dacă luăm OpenStack — în esență este la fel un Frankenstein, dar hai să nu discutăm despre asta acum.
Dar înțeleg că din definiția prezentată mai sus nu este foarte clar ce anume poate fi numit cloud.
Prin urmare, în documentul NIST (Institutul Național de Standarde și Tehnologie) sunt prezentate 5 caracteristici principale pe care trebuie să le aibă o infrastructură de cloud:
Furnizarea serviciului la cerere. Utilizatorului trebuie să i se ofere acces liber la resursele de calcul alocate (cum ar fi rețelele, discurile virtuale, memoria, nucleele procesorului etc.), iar aceste resurse trebuie să fie furnizate automat — adică fără intervenția furnizorului de servicii.
Accesibilitate largă a serviciului. Accesul la resurse trebuie să fie asigurat prin mecanisme standard pentru a permite utilizarea atât pe calculatoare standard, cât și pe clienți subțiri și dispozitive mobile.
Uniunea resurselor în pool-uri. Pool-urile de resurse trebuie să asigure furnizarea simultană a resurselor către mai mulți clienți, asigurând izolare între clienți și absența influenței reciproce și competiției pentru resurse. În pool-uri sunt incluse și rețele, ceea ce sugerează posibilitatea utilizării adresării suprapuse. Pool-urile trebuie să suporte scalarea la cerere. Utilizarea pool-urilor permite asigurarea unei niveluri necesare de redundanță a resurselor și abstractizarea resurselor fizice și virtuale — clientului i se oferă pur și simplu setul de resurse solicitat (unde sunt localizate aceste resurse fizic, pe câte servere și comutatoare — clientul nu este interesat). Totuși, trebuie să avem în vedere că furnizorul trebuie să asigure rezervarea transparentă a acestor resurse.
Adaptare rapidă la diferite condiții. Serviciile ar trebui să fie flexibile — furnizarea rapidă de resurse, realocarea, adăugarea sau reducerea resurselor la cererea clientului, cu impresia că resursele cloud-ului sunt nesfârșite. Pentru a simplifica înțelegerea, de exemplu, nu primiți o avertizare că a dispărut o parte din spațiul de stocare din Apple iCloud din cauza unei defecțiuni a unui hard disk pe server, deși hard disk-urile se strică. În plus, din perspectiva dumneavoastră, capacitățile acestui serviciu sunt practic nelimitate — dacă aveți nevoie de 2 TB — nu este o problemă, plătiți și le obțineți. Un exemplu similar poate fi dat cu Google Drive sau Yandex.Disk.
Possibilitatea de a măsura serviciul furnizat. Sistemele cloud ar trebui să monitorizeze și să optimizeze automat resursele consumate, iar aceste mecanisme ar trebui să fie transparente atât pentru utilizator, cât și pentru furnizorul de servicii. Asta înseamnă că puteți verifica întotdeauna cât de multe resurse consumați dumneavoastră și clienții dumneavoastră.
Este important de menționat că aceste cerințe sunt în mare parte cerințe pentru un cloud public, așadar pentru un cloud privat (adică un cloud lansat pentru nevoile interne ale companiei) aceste cerințe pot fi ușor ajustate. Cu toate acestea, ele trebuie respectate, altfel nu vom obține toate beneficiile calculului în cloud.
De ce avem nevoie de cloud?
Cu toate acestea, orice tehnologie nouă sau existentă, orice protocol nou este creat pentru un scop (cu excepția, bineînțeles, a RIP-ng). Un protocol creat doar pentru a exista — nu este util (cu excepția, bineînțeles, a RIP-ng). Este logic că cloud-ul este creat pentru a oferi un anumit serviciu utilizatorului/clientului. Suntem cu toții familiarizați, măcar cu câteva servicii cloud, de exemplu Dropbox sau Google Docs, și presupun că majoritatea le utilizează cu succes — de exemplu, acest articol a fost scris folosind serviciul cloud Google Docs. Dar cunoscuții noștri servicii cloud sunt doar o parte din capacitățile cloud-ului — mai exact, acestea sunt doar servicii de tip SaaS. Putem oferi un serviciu cloud în trei moduri: sub formă de SaaS, PaaS sau IaaS. Ce tip de serviciu aveți nevoie depinde de dorințele și capacitățile dumneavoastră.
Să analizăm fiecare în ordine:
Software ca Serviciu (SaaS) — este un model de furnizare a unui serviciu complet pentru client, de exemplu un serviciu de e-mail precum Yandex.Mail sau Gmail. În acest model de furnizare a serviciului, tu, ca și client, nu trebuie să faci nimic altceva decât să folosești serviciul — adică nu trebuie să te gândești la configurarea serviciului, la reziliența acestuia sau la rezervare. Cel mai important este să nu-ți compromiți parola, toate celelalte vor fi gestionate de furnizorul acestui serviciu. Din perspectiva furnizorului de servicii — el răspunde complet de întregul serviciu — începând cu echipamentul serverului și sistemele de operare gazdă, până la configurările bazelor de date și ale software-ului.
Platform as a Service (PaaS) — utilizând acest model, furnizorul de servicii oferă clientului o schemă pentru serviciu, de exemplu un server web. Furnizorul de servicii a oferit clientului un server virtual (de fapt un set de resurse, cum ar fi RAM/CPU/Stocare/Internet etc.), și chiar a instalat pe acest server sistemul de operare și software-ul necesar, însă configurarea tuturor acestor lucruri este realizată de client, iar clientul este responsabil pentru funcționarea serviciului. Furnizorul de servicii, ca în cazul anterior, răspunde de funcționarea echipamentului fizic, a hypervisor-urilor, a mașinii virtuale în sine, a accesibilității acesteia în rețea etc., dar serviciul este deja în afara zonei sale de responsabilitate.
Infrastructure as a Service (IaaS) — această abordare este deja mai interesantă, de fapt furnizorul de servicii oferă clientului o infrastructură complet virtualizată — adică un anumit set (pool) de resurse, cum ar fi nuclee CPU, RAM, Rețele etc. Tot restul este treaba clientului — ce dorește clientul să facă cu aceste resurse în cadrul pool-ului alocat (cota) — nu este foarte important pentru furnizor. Dacă clientul dorește să își creeze propriul vEPC sau să devină un mic operator și să ofere servicii de comunicație — nu este o problemă — fă-o. În acest scenariu, furnizorul de servicii este responsabil pentru furnizarea resurselor, reziliența și disponibilitatea acestora, precum și pentru sistemul de operare care permite combinarea acestor resurse în pool-uri și furnizarea acestora clientului cu posibilitatea de a extinde sau reduce resursele la cererea clientului. Toate mașinile virtuale și alte setări le configurează clientul singur prin portalul de autoservire și consolă, inclusiv configurarea rețelelor (cu excepția rețelelor externe).
Ce este OpenStack?
În toate cele trei variante, furnizorul de servicii are nevoie de un sistem de operare care să permită crearea unei infrastructuri cloud. De fapt, în cazul SaaS, întreaga stivă tehnologică este gestionată de un singur departament — există un departament care se ocupă cu infrastructura, adică oferă IaaS unui alt departament, iar acest departament furnizează SaaS clientului. OpenStack este unul dintre sistemele de operare cloud care permite agregarea mai multor comutatoare, servere și sisteme de stocare într-un singur pool de resurse, împărțind acest pool comun în sub-pooluri (tenanți) și oferind aceste resurse clienților prin rețea.
OpenStack — este un sistem de operare cloud care permite controlul unor pooluri mari de resurse de calcul, stocare și resurse de rețea, provisionarea și managementul acestora realizându-se prin API folosind mecanisme standard de autentificare.
Cu alte cuvinte, este un set de proiecte de software liber destinat creării serviciilor cloud, (atât publice cât și private) — adică un set de instrumente care permite integrarea echipamentelor serverelor și comutatoarelor într-un singur pool de resurse, gestionând aceste resurse și asigurând nivelul necesar de disponibilitate.
La momentul redactării acestui material, structura OpenStack arată astfel:
Imaginea este preluată de pe
Fiecare componentă care face parte din OpenStack îndeplinește o anumită funcție. O astfel de arhitectură distribuită permite includerea în soluție a setului de componente funcționale de care aveți nevoie. Totuși, unele componente sunt componente de bază, iar eliminarea lor va duce la nefuncționarea completă sau parțială a soluției în ansamblu. Printre aceste componente se regăsesc:
- Tabloul de bord — GUI bazat pe web pentru gestionarea serviciilor OpenStack
- Keystone — un serviciu centralizat de identificare care oferă funcționalități de autentificare și autorizare pentru celelalte servicii, precum și gestionarea datelor de identificare ale utilizatorilor și a rolurilor acestora.
- Neutron — un serviciu de rețea care asigură conectivitatea între interfețele diverselor servicii OpenStack (inclusiv conectivitatea între VM-uri și accesul acestora la exterior)
- Cinder — oferă acces la stocare bloc pentru mașinile virtuale
- Nova — gestionarea ciclului de viață al mașinilor virtuale
- Glance — depozit pentru imagini de mașini virtuale și snapshot-uri
- Swift — oferă acces la stocarea de obiecte
- Ceilometer — serviciu care permite colectarea telemetriei și măsurarea resurselor existente și consumate
- Heat — orchestrare bazată pe șablon pentru crearea automată și provisionarea resurselor
Lista completă a tuturor proiectelor și scopul acestora poate fi consultată .
Fiecare componentă OpenStack este un serviciu responsabil pentru o anumită funcție și care oferă API pentru gestionarea acestei funcții și interacțiunea acestui serviciu cu alte servicii ale sistemului de operare cloud în scopul creării unei infrastructuri unitare. De exemplu, Nova se ocupă de gestionarea resurselor de calcul și API pentru accesarea configurării acestor resurse, Glance – gestionarea imaginilor și API pentru gestionarea acestora, Cinder – stocare pe blocuri și API pentru gestionarea acestuia etc. Toate funcțiile sunt interconectate într-un mod foarte strâns.
Cu toate acestea, dacă ne gândim, toate serviciile rulate în OpenStack reprezintă, în cele din urmă, o mașină virtuală (sau un container) conectat la rețea. Se pune întrebarea – de ce avem atât de multe elemente?
Să trecem prin algoritmul de creare a unei mașini virtuale și conectarea acesteia la rețea și la stocarea permanentă în OpenStack.
- Atunci când trimiteți o cerere pentru a crea o mașină, fie că este vorba de o cerere prin Horizon (Dashboard) sau de o cerere prin CLI, primul lucru care se întâmplă este autorizarea cererii dvs. la Keystone — puteți crea o mașină, aveți dreptul de a utiliza aceea rețea, vă ajunge cota proiectului etc.
- Keystone autentifică cererea dvs. și generează un token auth ca răspuns, care va fi folosit mai departe. După ce a primit răspunsul de la Keystone, cererea este trimisă către Nova (nova api).
- Nova-api verifică validitatea cererii dvs., adresându-se lui Keystone, folosind tokenul auth generat anterior.
- Keystone realizează autentificarea și furnizează, pe baza acestui token auth, informații despre permisiuni și restricții.
- Nova-api creează în baza de date nova o înregistrare despre noua VM și trimite cererea de creare a mașinii către nova-scheduler.
- Nova-scheduler alege gazda (nodul de calcul) pe care VM-ul va fi desfășurat pe baza parametrilor specificați, a greutăților și a zonelor. Informația despre aceasta și identificatorul VM sunt înregistrate în nova-database.
- Apoi, nova-scheduler se adresează la nova-compute cu o solicitare pentru desfășurarea instanței. Nova-compute se adresează la nova-conductor pentru a obține informații despre parametrii mașinii (nova-conductor este un element al nova care acționează ca un server proxy între nova-database și nova-compute, limitând numărul de solicitări către nova-database pentru a evita problemele de consistență a bazei de date și de reducere a încărcării).
- Nova-conductor primește informațiile solicitate din nova-database și le transmite la nova-compute.
- Apoi, nova-compute se adresează la glance pentru a obține ID-ul imaginii. Glance validează solicitarea în Keystone și returnează informațiile solicitate.
- Nova-compute se adresează la neutron pentru a obține informații despre parametrii rețelei. Similar cu glance, neutron validează solicitarea în Keystone, după care creează o înregistrare în baza de date (identificatorul portului etc.), creează o solicitare pentru crearea portului și returnează informațiile solicitate la nova-compute.
- Nova-compute se adresează la cinder cu o solicitare pentru alocarea unui volum mașinii virtuale. Similar cu glance, cinder validează solicitarea în Keystone, creează o solicitare pentru crearea volumului și returnează informațiile solicitate.
- Nova-compute se adresează la libvirt cu o solicitare pentru desfășurarea mașinii virtuale cu parametrii specificați.
De fapt, operația de creare a unei mașini virtuale simple se transformă într-un adevărat vortex de apeluri API între elementele platformei cloud. De asemenea, așa cum puteți observa, chiar și serviciile menționate anterior constau din componente mai mici, între care are loc interacțiunea. Crearea mașinii este doar o mică parte din ceea ce permite platforma cloud - există un serviciu responsabil de echilibrarea traficului, un serviciu pentru stocarea pe bloc, un serviciu pentru DNS, un serviciu pentru provisionarea serverelor bare metal etc. Cloud-ul vă permite să tratați mașinile virtuale ca pe un turmă de oi (spre deosebire de virtualizare). Dacă în mediu virtual vă întâmplă ceva cu mașina, o restaurați din backup-uri etc., aplicațiile cloud sunt concepute astfel încât mașinile virtuale să nu joace un rol atât de important - dacă mașina virtuală „a murit” - nu este o problemă - pur și simplu se creează o nouă mașină pe baza unui șablon și, cum se spune, echipa nu observă pierderea unui luptător. Evident, aceasta preconizează existența unor mecanisme de orchestrare - utilizând șabloane Heat, puteți desfășura fără probleme funcții complexe, constând din zeci de rețele și mașini virtuale.
Este întotdeauna bine să aveți în minte că infrastructura cloud nu există fără rețea - fiecare element interacționează mai mult sau mai puțin cu celelalte prin rețea. În plus, cloud-ul are o rețea absolut dinamică. Evident, rețeaua subiacente este mai mult sau mai puțin statică - nu în fiecare zi se adaugă noi noduri și comutatoare, cu toate acestea, componenta overlay poate și inevitabil va fi în continuă schimbare - vor fi adăugate sau eliminate noi rețele, vor apărea noi mașini virtuale și vor dispărea cele vechi. Și, așa cum vă amintiți din definiția cloud-ului dată la începutul articolului - resursele trebuie să fie alocate utilizatorului automat și cu minimal (sau mai bine, fără) intervenția furnizorului de servicii. Asta înseamnă că tipul de furnizare a resurselor de rețea, care există acum în forma frontend-ului, sub formă de panou personal accesibil prin http/https și cu inginerul de rețea de serviciu Vasilii în rol de backend - nu este cloud, chiar și cu cele opt mâini ale lui Vasilii.
Neutron, fiind un serviciu de rețea, oferă un API pentru gestionarea părții de rețea a infrastructurii cloud. Serviciul asigură funcționarea și gestionarea părții de rețea OpenStack, oferind un nivel de abstracție numit Network-as-a-Service (NaaS). Asta înseamnă că rețeaua este o unitate virtuală măsurabilă, la fel ca, de exemplu, nucleele virtuale CPU sau volumul RAM.
Dar înainte de a trece la arhitectura părții de rețea OpenStack, să vedem cum funcționează această rețea în OpenStack și de ce rețeaua este o parte importantă și integrantă a cloud-ului.
Așadar, avem două mașini virtuale ale clientului RED și două mașini virtuale ale clientului GREEN. Să presupunem că aceste mașini sunt amplasate pe două hypervizoruri în acest mod:
În acest moment, este pur și simplu virtualizarea a patru servere și nu mai mult, deoarece, până acum, tot ceea ce am făcut este să virtualizăm patru servere, amplasându-le pe două servere fizice. Mai mult, acestea nici măcar nu sunt conectate la rețea.
Pentru a crea un cloud, trebuie să adăugăm câțiva compuși. În primul rând, trebuie să virtualizăm partea de rețea - trebuie să conectăm aceste patru mașini în perechi, iar clienții doresc o conexiune L2. Putem folosi, bineînțeles, un switch și să configurăm un trunk în direcția sa și să rezolvăm totul folosind linux bridge, sau pentru utilizatorii mai avansați, openvswitch (la care ne vom întoarce). Dar rețelele pot fi foarte multe, iar a împinge constant L2 prin switch - nu este cea mai bună idee - deoarece diferite departamente, service desk, luni de așteptare pentru îndeplinirea unei cereri, săptămâni de troubleshooting - în lumea modernă, acest abordare nu mai funcționează. Și cu cât compania înțelege mai devreme acest lucru, cu atât mai ușor îi va fi să meargă mai departe. Prin urmare, între hypervizoruri, vom aloca o rețea L3 prin care vor comunica mașinile noastre virtuale, iar deasupra acestei rețele L3, vom construi rețele L2 (overlay) virtuale, unde va circula traficul mașinilor noastre virtuale. Putem folosi GRE, Geneve sau VxLAN pentru incapsulare. Deocamdată ne vom opri la ultima, deși acest lucru nu este foarte important.
Trebuie să amplasăm undeva VTEP (sper că toți sunteți familiarizați cu terminologia VxLAN). Deoarece de pe servere ieșim direct pe o rețea L3, nimic nu ne împiedică să amplasăm VTEP pe serverele în sine, iar OVS (OpenvSwitch) face acest lucru foarte bine. În consecință, am obținut o astfel de construcție:
Dată fiind necesitatea de a împărți traficul între VM-uri, porturile către mașinile virtuale vor avea numere VLAN diferite. Numărul etichetei are relevanță doar în interiorul unui singur switch virtual, întrucât prin encapsularea în VxLAN, îl putem elimina fără probleme, deoarece vom avea VNI.
Acum putem crea fără probleme mașinile și rețelele virtuale pentru acestea.
Dar ce se întâmplă dacă clientul are o altă mașină, dar aceasta se află într-o altă rețea? Avem nevoie de rutare între rețele. Vom discuta o variantă simplă, când se utilizează rutare centralizată — adică traficul este rutat prin noduri de rețea dedicate (de obicei, acestea sunt combinate cu noduri de control, deci se va întâmpla același lucru).
Părea simplu — creăm o interfață bridge pe nodul de control, direcționăm traficul pe aceasta și de acolo îl rutăm unde avem nevoie. Dar problema este că clientul RED vrea să folosească rețeaua 10.0.0.0/24, iar clientul GREEN vrea să folosească, de asemenea, rețeaua 10.0.0.0/24. Adică avem o suprapunere a spațiilor de adrese. În plus, clienții nu doresc ca alți clienți să poată fi rutati în rețelele lor interne, ceea ce este logic. Pentru a separa rețelele și traficul datelor clienților, le vom aloca fiecăruia un namespace separat. Namespace-ul este de fapt o copie a stivului de rețea Linux, deci clienții din namespace-ul RED sunt complet izolați de clienții din namespace-ul GREEN (sau rutarea între aceste rețele ale clienților este permisă prin default namespace sau deja pe echipamentele de transport superioare).
Deci obținem schema următoare:
Tunelurile L2 converg de la toate nodurile de calcul către nodul de control, unde se află interfața L3 pentru aceste rețele, fiecare într-un namespace dedicat pentru izolare.
Cu toate acestea, am uitat cel mai important lucru. Mașina virtuală trebuie să ofere un serviciu clientului, adică trebuie să aibă cel puțin o interfață externă, prin care să poată fi accesată. Asta înseamnă că trebuie să ne conectăm la lumea exterioară. Există mai multe opțiuni. Să facem cea mai simplă variantă. Vom adăuga clienților o rețea, care va fi validă în rețeaua furnizorului și nu se va suprapune cu alte rețele. Rețelele pot fi, de asemenea, suprapuse și să fie conectate la diferite VRF-uri în rețeaua furnizorului. Aceste rețele vor exista, de asemenea, în namespace-ul fiecărui client. Cu toate acestea, accesul la lumea exterioară se va face printr-o singură interfață fizică (sau bond, ceea ce este mai logic). Pentru a separa traficul clienților, traficul extern va fi etichetat cu un tag VLAN, dedicat clientului.
În final, am obținut următoarea schemă:
O întrebare rezonabilă — de ce să nu facem gateway-uri pe nodurile compute în sine? Nu există nicio problemă majoră în acest sens; mai mult, când se activează routerul distribuit (DVR), așa va funcționa. În acest scenariu, luăm în considerare cea mai simplă variantă cu un gateway centralizat, care este folosit implicit în Openstack. Pentru funcții cu încărcare ridicată, vor fi folosite atât routerul distribuit, cât și tehnologiile de accelerare, precum SR-IOV și Passthrough, dar, așa cum se spune, aceasta este deja o cu totul altă poveste. Deocamdată, să ne ocupăm de partea de bază, apoi vom intra în detalii.
Schemă noastră este deja funcțională, cu toate acestea, există câteva nuanțe:
- Trebuie să protejăm mașinile noastre, adică să aplicăm un filtru pe interfața switch-ului către client.
- Să facem posibilă obținerea automată a adresei IP de către mașina virtuală, astfel încât să nu fie necesar să intrăm de fiecare dată în consola ei și să setăm adresa.
Să începem cu protecția mașinilor. Pentru asta, putem folosi simplele iptables, de ce nu.
Asta înseamnă că topologia noastră s-a complicat un pic:
Să continuăm. Trebuie să adăugăm un server DHCP. Cel mai ideal loc pentru amplasarea serverelor DHCP pentru fiecare client va fi deja menționata nodă de control, unde se află namespace-urile:
Cu toate acestea, există o mică problemă. Ce se întâmplă dacă totul se repornește și toate informațiile despre închirierea adreselor pe DHCP dispar? Logica spune că mașinile vor primi adrese noi, ceea ce nu este foarte convenabil. Există două soluții — fie să utilizăm nume de domenii și să adăugăm un server DNS pentru fiecare client, atunci adresa nu va fi prea importantă (similar cu partea de rețea în k8s) — dar aici există o problemă cu rețelele externe, deoarece în ele adresele pot fi de asemenea alocate prin DHCP — este necesară sincronizarea între serverele DNS din platforma cloud și serverul DNS extern, ceea ce, din punctul meu de vedere, nu este foarte flexibil, dar este perfect posibil. Sau, a doua opțiune — utilizarea metadatelor — adică păstrarea informațiilor despre adresa alocată mașinii, astfel încât serverul DHCP să știe ce adresă să aloce mașinii dacă aceasta a mai primit o adresă. A doua opțiune este mai simplă și mai flexibilă, deoarece permite păstrarea informațiilor suplimentare despre mașină. Acum, pe schemă să adăugăm agenții de metadate:
O altă întrebare care merită discutată este despre posibilitatea utilizării unei rețele externe de către toți clienții, deoarece rețelele externe, dacă trebuie să fie valide în întreaga rețea, vor prezenta dificultăți — trebuie să alocăm constant și să controlăm alocarea acestor rețele. Posibilitatea de a folosi o rețea preconfigurată unică pentru toți clienții ar fi foarte utilă la crearea unui cloud public. Acest lucru va simplifica desfășurarea mașinilor, deoarece nu va trebui să ne comparăm cu baza de date a adreselor și să alegem un spațiu adresabil unic pentru rețeaua externă a fiecărui client. În plus, putem predefini rețeaua externă și, în momentul desfășurării, va trebui doar să asociem adresele externe cu mașinile clienților.
Și aici ne ajută NAT — pur și simplu vom permite clienților să iasă în lumea externă prin default namespace folosind traducerea NAT. Totuși, există o mică problemă. Este bine dacă serverul clientului funcționează ca un client și nu ca un server — adică inițiază și nu primește conexiuni. Dar noi vom face exact invers. În acest caz, trebuie să facem NAT de destinație, astfel încât, atunci când se primește trafic, nodul de control să înțeleagă că acest trafic este destinat mașinii virtuale A a clientului A, și deci trebuie să facem traducerea NAT dintr-o adresă externă, de exemplu 100.1.1.1 în adresa internă 10.0.0.1. În acest caz, deși toți clienții vor folosi aceeași rețea, izolarea internă este complet menținută. Așadar, trebuie să facem dNAT și sNAT pe nodul de control. Utilizarea unei rețele unice cu alocarea adreselor plutitoare sau rețele externe sau ambele simultan depinde de ceea ce doriți să aduceți în cloud. Nu vom adăuga adrese plutitoare pe schemă, ci vom lăsa rețelele externe deja adăugate anterior — fiecare client are rețeaua sa externă (pe schemă acestea sunt desemnate ca vlan 100 și 200 pe interfața externă).
În final, am obținut o soluție interesantă și, în același timp, bine gândită, care are o anumită flexibilitate, dar momentan nu dispune de mecanisme de reziliență la erori.
În primul rând, avem doar un singur nod de control — defectarea acestuia va conduce la prăbușirea tuturor sistemelor. Pentru a soluționa această problemă, este necesar să creăm un cvorum format din cel puțin 3 noduri. Să adăugăm acest lucru pe schemă:
Desigur, toate nodurile se sincronizează, iar în cazul defectării nodului activ, responsabilitățile sale vor fi preluate de un alt nod.
Următoarea problemă sunt discurile mașinilor virtuale. În acest moment, acestea sunt stocate pe hypervisore, iar în cazul unor probleme cu hypervisorul, pierdem toate datele — și prezența RAID-ului nu ajută în cazul în care pierdem nu un disc, ci serverul întreg. Pentru aceasta, trebuie să creăm un serviciu care să acționeze ca un frontend pentru un fel de stocare. Ce fel de stocare va fi nu este atât de important, dar aceasta trebuie să protejeze datele noastre împotriva defecțiunilor atât ale discurilor, cât și ale nodurilor, sau poate chiar întregului rack. Există mai multe opțiuni — există, desigur, rețele SAN cu Fiber Channel, dar să fim sinceri — FC este deja o relicvă a trecutului — un echivalent E1 în transport — da, sunt de acord, încă este utilizat, dar doar acolo unde nu se poate altfel. Așadar, nu aș dori să implementez voluntar o rețea FC în 2020, știind de existența altor alternative mai interesante. Deși fiecare cu părerea sa și este posibil să existe persoane care cred că FC, cu toate limitările sale, este tot ce avem nevoie — nu mă voi contrazice, fiecare are opinia sa. Totuși, cea mai interesantă soluție, din punctul meu de vedere, este utilizarea SDS, de exemplu Ceph.
Ceph permite construirea unei soluții de stocare a datelor cu înaltă disponibilitate, cu multe opțiuni de rezervare, începând de la coduri cu verificare a parității (echivalent RAID 5 sau 6) până la replicarea completă a datelor pe discuri diferite, ținând cont de amplasarea discurilor în servere și a serverelor în rack-uri etc.
Pentru a construi Ceph, sunt necesare încă 3 noduri. Interacțiunea cu stocarea se va realiza, de asemenea, prin rețea, folosind servicii de stocare pe bloc, obiect și fișier. Să adăugăm în schemă stocarea:
Notă: noduri compute hiperconvergente pot fi create — aceasta este o concepție care unește mai multe funcții pe un singur nod — de exemplu storage + compute — fără a aloca noduri speciale pentru stocarea ceph. Vom obține o schemă de redundanță similară — deoarece SDS va rezerva datele cu nivelul de rezervare specificat de noi. Totuși, nodurile hiperconvergente reprezintă întotdeauna un compromis — deoarece un nod de stocare nu doar că stă nefolosit, cum pare la prima vedere (deoarece nu are mașini virtuale) — el consumă resurse CPU pentru a gestiona SDS (de fapt, în fundal, efectuează toate replicările, recuperările în caz de defecțiune a nodurilor, discurilor etc.). Asta înseamnă că vei pierde o parte din puterea nodului compute dacă îl combini cu storage.
Toate aceste resurse trebuie gestionate cumva — avem nevoie de ceva prin care putem crea o mașină, o rețea, un router virtual etc. Pentru aceasta, pe nodul de control, vom adăuga un serviciu care va acționa ca un dashboard — clientul se va putea conecta la acest port через http/https și face tot ce are nevoie (aproape).
În final, acum avem un sistem de redundanță. Toate elementele acestei infrastructuri trebuie gestionate cumva. A fost menționat anterior că OpenStack este un set de proiecte, fiecare dintre acestea oferind o anumită funcție. Așa cum vedem, există mai mult decât suficiente elemente care trebuie configurate și controlate. Astăzi vom vorbi despre partea de rețea.
Arhitectura Neutron
În OpenStack, Neutron se ocupă de conectarea porturilor mașinilor virtuale la rețeaua L2 comună, de facilitarea rutării traficului între VM-uri aflate în rețele L2 diferite și de rutarea externă, oferind servicii precum NAT, Floating IP, DHCP etc.
Funcționarea de nivel superior a serviciului de rețea (partea de bază) poate fi descrisă astfel.
La pornirea unei VM, serviciul de rețea:
- Creează un port pentru această VM (sau porți) și notifică serviciul DHCP;
- Se creează un nou dispozitiv de rețea virtual (prin libvirt);
- VM-ul se conectează la portul creat în pasul 1 (porțile);
Din păcate, în esența sa, Neutron se bazează pe mecanisme standard bine cunoscute de toți cei care s-au adâncit vreodată în Linux — namespaces, iptables, poduri linux, openvswitch, conntrack etc.
Trebuie imediat clarificat că Neutron nu este un controler SDN.
Neutron este compus din mai multe componente interconectate:
Openstack-neutron-server — este un demon care, prin API, lucrează cu cererile utilizatorilor. Acest demon nu se ocupă cu definirea unor legaturi de rețea, ci oferă informațiile necesare plugin-urilor sale, care ulterior configurează elementul dorit al rețelei. Agenții Neutron de pe nodurile OpenStack se înregistrează pe serverul Neutron.
Neutron-server este de fapt o aplicație scrisă în Python, compusă din două părți:
- Serviciu REST
- Plugin Neutron (core/service)
Serviciul REST este destinat primirii apelurilor API din partea celorlalte componente (de exemplu, cereri pentru furnizarea unor informații etc.)
Plugin-urile sunt componente/module software conectabile care sunt invocate la cererile API — astfel, adăugarea unui serviciu se face prin acestea. Plugin-urile sunt împărțite în două tipuri — de serviciu și de bază. De obicei, plugin-ul de bază răspunde în principal de gestionarea spațiului de adresare și a conexiunilor L2 între VM-uri, în timp ce plugin-urile de serviciu oferă funcționalități suplimentare, cum ar fi VPN sau FW.
Lista plugin-urilor disponibile până în prezent poate fi consultată, de exemplu,
Pot exista mai multe plugin-uri de serviciu, însă plugin-ul de bază poate fi doar unul singur.
Openstack-neutron-ml2 — este plugin-ul de bază standard al OpenStack. Acest plugin are o arhitectură modulară (spre deosebire de predecesorul său) și prin driverele conectate la el realizează configurarea serviciului de rețea. Vom discuta plugin-ul puțin mai târziu, deoarece de fapt oferă flexibilitatea de care OpenStack dispune în domeniul rețelei. Plugin-ul de bază poate fi înlocuit (de exemplu, Contrail Networking face o astfel de înlocuire).
Serviciu RPC (rabbitmq-server) — serviciu care asigură gestionarea cozilor și interacțiunea cu alte servicii OpenStack, precum și interacțiunea între agenții serviciului de rețea.
Agenți de rețea — agenți care sunt localizați în fiecare nod, prin care se realizează configurarea serviciilor de rețea.
Agenții vin în mai multe tipuri.
Agenția principală este agenția L2. Acești agenți sunt porniți pe fiecare dintre hipervizoare, inclusiv nodurile de control (mai exact, pe toate nodurile care oferă vreo serviciu pentru chiriași) și funcția lor principală este de a conecta mașinile virtuale la rețeaua comună L2, precum și de a genera alerte în cazul apariției unor evenimente (de exemplu, dezactivarea/activarea unui port).
Următorul, nu mai puțin important, agent este agenția L3. Implicit, acest agent este pornit exclusiv pe nodul de rețea (de multe ori nodul de rețea este combinat cu nodul de control) și asigură rutarea între rețelele chiriașilor (atât între rețelele sale, cât și între rețelele altor chiriași, fiind disponibil și pentru legătura cu lumea exterioară, asigurând NAT și, de asemenea, serviciul DHCP). Cu toate acestea, atunci când se utilizează DVR (router distribuit), necesitatea plugin-ului L3 apare și pe nodurile de calcul.
Agentul L3 utilizează spații de nume Linux pentru a oferi fiecărui chiriaș un set de rețele izolate proprii și funcționalitatea routerelor virtuale, care rutează traficul și oferă servicii de gateway pentru rețelele de nivel 2.
Bază de date — o bază de date de identificatori pentru rețele, subrețele, porturi, pool-uri etc.
De fapt, Neutron primește cereri API pentru a crea diverse entități de rețea, autentifică cererea și, prin RPC (dacă se referă la un plugin sau agent) sau REST API (dacă comunică în SDN), transmite agenților (prin plugin-uri) instrucțiunile necesare pentru a organiza serviciul solicitat.
Acum să ne îndreptăm atenția către instalația de test (cum este desfășurată și ce conține vom analiza mai târziu în partea practică) și să vedem unde se află fiecare componentă:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Tip agent | Gazdă | Zonă de disponibilitate | Activ | Stat | Binare |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | agent Open vSwitch | overcloud-novacompute-1.localdomain | Niciunul | :-) | ÎN FUNCȚIUNE | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | agent L3 | overcloud-controller-0.localdomain | nova | :-) | ÎN FUNCȚIUNE | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | agent DHCP | overcloud-controller-0.localdomain | nova | :-) | ÎN FUNCȚIUNE | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | agent Open vSwitch | overcloud-novacompute-0.localdomain | Niciunul | :-) | ÎN FUNCȚIUNE | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | agent Open vSwitch | overcloud-controller-0.localdomain | Niciunul | :-) | ÎN FUNCȚIUNE | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | agent Metadata | overcloud-controller-0.localdomain | Niciunul | :-) | ÎN FUNCȚIUNE | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Iată întreaga structură Neutron. Acum ar trebui să acordăm ceva timp pluginului ML2.
Modular Layer 2
După cum s-a menționat mai sus, pluginul este pluginul de bază standard OpenStack și are o arhitectură modulară.
Predecesorul pluginului ML2 avea o structură monolitică, ceea ce nu permitea, de exemplu, utilizarea unui mix de tehnologii într-o singură instalare. De exemplu, nu puteai folosi atât openvswitch cât și linuxbridge simultan — fie unul, fie altul. Din acest motiv a fost creat pluginul ML2 cu arhitectura sa.
ML2 are două componente — două tipuri de drivere: Type drivers și Mechanism drivers.
Type drivers definește tehnologiile care vor fi utilizate pentru a organiza conexiunile de rețea, cum ar fi VxLAN, VLAN, GRE. Aceste drivere permit utilizarea de diverse tehnologii. Tehnologia standard este incapsularea VxLAN pentru rețelele overlay și VLAN-uri pentru rețelele externe.
Type drivers includ următoarele tipuri de rețele:
Flat — rețea fără etichetare
VLAN — rețea etichetată
Local — tip special de rețea pentru instalări tip all-in-one (astfel de instalări sunt necesare fie pentru dezvoltatori, fie pentru formare)
GRE — rețea overlay, care utilizează tuneluri GRE
VxLAN — rețea overlay, care utilizează tuneluri VxLAN
Mechanism drivers definirea resurselor care asigură organizarea tehnologiilor specificate în type driver - de exemplu, openvswitch, sr-iov, opendaylight, OVN etc.
În funcție de implementarea acestui driver, vor fi folosite fie agenți care sunt gestionați de Neutron, fie se vor utiliza conexiuni cu un controler SDN extern, care preia toate responsabilitățile pentru organizarea rețelelor L2, rutare etc.
De exemplu, dacă folosim ML2 împreună cu OVS, atunci pe fiecare nod de calcul se instalează un agent L2 care gestionează OVS. Cu toate acestea, dacă folosim, de exemplu, OVN sau OpenDayLight, atunci gestionarea OVS trece sub jurisdicția lor - Neutron, prin pluginul de bază, dă comenzi controlerului, iar acesta îndeplinește ceea ce i s-a spus.
Să ne reîmprospătăm memoria cu Open vSwitch
În prezent, una dintre componentele cheie ale OpenStack este Open vSwitch.
Atunci când se instalează OpenStack fără un SDN suplimentar de tip vendor, precum Juniper Contrail sau Nokia Nuage, OVS este componenta principală a rețelei cloud, iar împreună cu iptables, conntrack, namespaces permite organizarea unor rețele overlay complete cu multitenanță. Evident, această componentă poate fi înlocuită, de exemplu, atunci când se utilizează soluții SDN externe proprietare.
OVS este un switch software cu sursă deschisă, destinat utilizării în medii virtualizate ca un forwarder virtual de trafic.
În prezent, OVS are o funcționalitate foarte decentă, care include tehnologii precum QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK etc.
Notă: inițial, OVS nu a fost gândit ca un switch software pentru funcții telecom cu încărcare mare și a fost mai mult destinat funcțiilor IT cu cerințe mai scăzute de lățime de bandă, cum ar fi servere web sau servere de poștă. Cu toate acestea, OVS a fost îmbunătățit, iar implementările actuale ale OVS au îmbunătățit semnificativ performanța și capacitățile sale, ceea ce permite utilizarea acestuia de către operatori de telecomunicații cu funcții cu încărcare mare, de exemplu, există o implementare OVS cu suport pentru accelerarea DPDK.
Există trei componente importante ale OVS despre care trebuie să știți:
- Kernel module — componentă situată în kernel space, care efectuează prelucrarea traficului pe baza regulilor primite de la elementul de control;
- vSwitch daemon (ovs-vswitchd) este un proces care rulează în spațiul utilizatorului și este responsabil pentru programarea modulului kernel, adică reprezintă logica de funcționare a comutatorului.
- Server de baze de date. — o bază de date locală situată pe fiecare gazdă pe care este activat OVS, unde este stocată configurația. Prin acest modul, controller-ele SDN pot comunica prin protocolul OVSDB.
În plus, sunt disponibile un set de utilitare de diagnostica și management, cum ar fi ovs-vsctl, ovs-appctl, ovs-ofctl etc.
În prezent, Openstack este folosit pe scară largă de operatorii telecom pentru migrarea funcțiilor de rețea, cum ar fi EPC, SBC, HLR etc. O parte din aceste funcții pot funcționa fără probleme cu OVS așa cum este, însă EPC-ul, de exemplu, gestionează traficul utilizatorilor — adică trece prin el o cantitate uriașă de trafic (în prezent, volumele de trafic ajung la câteva sute de gigabiți pe secundă). Evident, direcționarea unui asemenea trafic prin spațiul kernelului (deoarece, în mod implicit, forwarderul este situat acolo) nu este cea mai bună idee. De aceea, OVS este adesea implementat în întregime în spațiul utilizatorului folosind tehnologia de accelerare DPDK pentru a dirija traficul din NIC în spațiul utilizatorului ocolind kernelul.
Notă: pentru cloud-ul implementat pentru funcții telecom, există o opțiune de a direcționa traficul de la nodul de calcul ocolind OVS direct către echipamentul de comutare. Pentru acest scop, sunt utilizate mecanismele SR-IOV și Passthrough.
Cum funcționează aceasta într-un model real?
Acum să trecem la partea practică și să vedem cum funcționează totul în practică.
Pentru început, vom implementa o instalare Openstack simplă. Deoarece nu am la dispoziție un set de servere pentru experimente, vom construi modelul pe un singur server fizic din mașini virtuale. Da, evident, pentru scopuri comerciale, această soluție nu este adecvată, dar pentru a vedea cum funcționează rețeaua în această instalare Openstack, va fi suficient. Acest tip de instalare este chiar mai interesant pentru scopuri educaționale — deoarece permite capturarea traficului etc.
Deoarece trebuie să vedem doar partea de bază, putem să nu folosim mai multe rețele și să utilizăm doar două rețele, în care a doua rețea va fi folosită exclusiv pentru acces la undercloud și serverul DNS. Rețelele externe nu le vom aborda deocamdată — acesta este un subiect pentru un articol aparte.
Așadar, să începem cu pașii corecți. Mai întâi, puțină teorie. Vom instala OpenStack folosind TripleO (OpenStack pe OpenStack). Conceptul TripleO constă în faptul că instalăm OpenStack all-in-one (adică pe un singur nod), numit undercloud, și apoi folosim capacitățile OpenStack-ului instalat pentru a instala OpenStack-ul destinat operării, numit overcloud. Undercloud va folosi capacitatea integrată de a gestiona servere fizice (bare metal) — proiectul Ironic — pentru a provisiona hypervisorii care vor îndeplini rolurile de noduri compute, control și storage. Cu alte cuvinte, nu folosim niciun instrument extern pentru a desfășura OpenStack — desfășurăm OpenStack cu forțele OpenStack. Pe parcursul instalării, totul va deveni mult mai clar, așa că nu ne vom opri aici și vom continua.
Observație: În această articol, pentru simplificare, nu am folosit izolația rețelei pentru rețelele interne OpenStack, iar totul a fost desfășurat folosind doar o singură rețea. Totuși, existența sau absența izolației rețelelor nu afectează funcționalitatea de bază a soluției — totul va funcționa exact la fel ca și în cazul utilizării izolației, dar traficul va circula într-o singură rețea. Pentru o instalare comercială, este evident necesar să se utilizeze izolația prin utilizarea unor VLAN-uri și interfețe diferite. De exemplu, traficul de management al stocării Ceph și traficul de date efective (interacțiunea mașinilor cu discurile etc.) utilizează subrețele diferite (Managementul stocării și Stocarea) în cazul izolației, ceea ce face ca soluția să fie mai rezistentă la defecțiuni, separând acest trafic, de exemplu, pe porturi diferite sau utilizând diferite profiluri QoS pentru trafic variat, pentru a evita ca traficul de date să fie împins în afara traficului de semnal. În cazul nostru, acestea vor circula în aceeași rețea, iar acest lucru nu ne limitează în niciun fel.
Observație: Deoarece intenționăm să lansăm mașini virtuale în medii virtuale bazate pe mașini virtuale, va trebui să activăm mai întâi virtualizarea nested.
Pentru a verifica dacă virtualizarea nested este activată sau nu, puteți face astfel:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Dacă vedeți litera N, atunci activați suportul pentru virtualizarea nested conform oricărui ghid pe care îl găsiți pe internet, de exemplu .
Trebuie să construim un astfel de schema din mașini virtuale:
În cazul meu, pentru conectivitatea mașinilor virtuale incluse în instalarea viitoare (am obținut 7, dar se poate lucra și cu 4, dacă nu aveți multe resurse), am folosit OpenvSwitch. Am creat un brigde ovs și am conectat mașinile virtuale la el prin grupuri de porturi. Pentru aceasta, am creat un fișier xml de forma următoare:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Aici sunt declare trei grupuri de porturi — două access și unul trunk (ultimul a fost necesar pentru serverul DNS, dar se poate renunța la el sau îl puteți ridica pe mașina gazdă — cum preferați). Apoi, folosind acest șablon, declarăm rețeaua noastră prin virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Acum ajustăm configurațiile porturilor hypervisor-ului:
[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 ~]# Notă: în acest scenariu adresa de pe portul ovs-br1 nu va fi disponibilă, deoarece nu are un tag VLAN. Pentru a corecta asta, trebuie să dați comanda sudo ovs-vsctl set port ovs-br1 tag=100. Totuși, după repornire, acest tag va dispărea (dacă cineva știe cum să-l facă să rămână pe loc — aș fi foarte recunoscător). Dar asta nu este atât de important, deoarece această adresă ne va fi necesară doar în timpul instalării și nu va fi necesară când OpenStack va fi complet desfășurat.
Apoi, creăm mașina undercloud:
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În timpul instalării, setați toate parametrii necesari, cum ar fi numele mașinii, parolele, utilizatorii, serverele NTP etc. Puteți configura imediat și porturile, dar personal prefer să intru în mașină prin consolă după instalare și să modific fișierele necesare. Dacă aveți deja o imagine gata, o puteți folosi, altfel puteți proceda ca mine — descărcați imaginea minimă CentOS 7 și folosiți-o pentru instalarea VM.
După instalarea reușită, ar trebui să aveți o mașină virtuală pe care să puteți instala undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningMai întâi, instalăm instrumentele necesare pe parcursul instalării:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalarea Undercloud
Creăm utilizatorul stack, stabilim o parolă, adăugăm în sudoer și îi dăm permisiunea de a executa comenzi root prin sudo fără a fi necesară introducerea parolei:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackAcum specificăm în fișierul hosts numele complet al undercloud:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Apoi, adăugăm repozitoriile și instalăm software-ul necesar:
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-ansibleNotă: dacă nu planificați să instalați ceph, atunci nu trebuie să introduceți comenzile legate de ceph. Am folosit versiunea Queens, dar puteți folosi oricare altă versiune care vă place.
Apoi, copiem fișierul de configurare undercloud în directorul home al utilizatorului stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confAcum trebuie să ajustăm acest fișier, adaptându-l la instalarea noastră.
La începutul fișierului trebuie să adăugăm următoarele linii:
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 = 10Așadar, să trecem prin configurații:
undercloud_hostname — numele complet al serverului undercloud, trebuie să corespundă cu înregistrarea de pe serverul DNS
local_ip — adresa locală undercloud către rețeaua de provisioning
network_gateway — aceeași adresă locală, care va acționa ca gateway pentru accesul la lumea externă în timpul instalării nodurilor overcloud, corespunde cu ip-ul local
undercloud_public_host — adresa API extern, se alocă orice adresă liberă din rețeaua de provisioning
undercloud_admin_host adresa API intern, se alocă orice adresă liberă din rețeaua de provisioning
undercloud_nameservers — server DNS
generate_service_certificate — această linie este foarte importantă în exemplul curent, deoarece dacă nu este setată la valoarea false, veți primi o eroare în timpul instalării, problema este descrisă în bugtracker-ul Red Hat
local_interface interfață în rețeaua de provisioning. Această interfață va fi reconfugurată în timpul implementării undercloud-ului, așa că undercloud-ul trebuie să aibă două interfețe - una pentru acces, iar cealaltă pentru provisioning
local_mtu — MTU. Deoarece avem un laborator de testare și MTU-ul meu este de 1500 pe porturile switch-ului OVS, trebuie setat la 1450 pentru a permite pachetele encapsulate în VxLAN
network_cidr — rețeaua de provisioning
masquerade — utilizarea NAT pentru accesul la rețeaua externă
masquerade_network — rețeaua care va fi NAT-uită
dhcp_start — adresa de început a pool-ului de adrese, din care vor fi asignate adrese nodurilor în timpul implementării overcloud-ului
dhcp_end — adresa finală a pool-ului de adrese, din care vor fi asignate adrese nodurilor în timpul implementării overcloud-ului
inspection_iprange — pool-ul de adrese necesar pentru efectuarea inspecției (nu trebuie să se suprapună cu pool-ul menționat anterior)
scheduler_max_attempts — numărul maxim de încercări de instalare a overcloud-ului (trebuie să fie mai mare sau egal cu numărul de noduri)
După ce fișierul a fost descris, se poate da comanda pentru implementarea undercloud-ului:
openstack undercloud install
Procedura durează între 10 și 30 de minute în funcție de hardware-ul dvs. În cele din urmă, ar trebui să vedeți următorul output:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Instalarea undercloud-ului este completă.
Fișierul care conține parolele pentru această instalare se află în
/home/stack/undercloud-passwords.conf.
Există de asemenea un fișier stackrc în /home/stack/stackrc.
Aceste fișiere sunt necesare pentru a interacționa cu serviciile OpenStack și ar trebui să fie
protejate.
#############################################################################Acest output indică faptul că ați instalat cu succes undercloud-ul și acum puteți verifica starea undercloud-ului și trece la instalarea overcloud-ului.
Dacă verificați outputul comenzii ifconfig, veți observa că a apărut o nouă interfață de bridge
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 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
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 0Acest interfață va fi folosită acum pentru desfășurarea overcloud.
Din ieșirea de mai jos, se observă că toate serviciile sunt pe aceeași nodă:
(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 |
+--------------------------+-----------+----------+Mai jos este prezentată configurația rețelei undercloud:
(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 ~]$Instalarea overcloud
În prezent, avem doar undercloud și ne lipsesc nodurile din care va fi construit overcloud. Așadar, primul lucru pe care îl vom face este să desfășurăm mașinile virtuale de care avem nevoie. În timpul desfășurării, undercloud va instala sistemul de operare și software-ul necesar pe mașinile overcloud — adică nu trebuie să desfășurăm complet mașina, ci doar să creăm un disc (sau discuri) pentru aceasta și să-i definim parametrii — practic obținem un server gol fără un sistem de operare instalat.
Trecem în folderul cu discurile mașinilor noastre virtuale și vom crea discurile de mărimea necesară:
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 160GFiindcă acționăm ca root, va trebui să schimbăm proprietarul acestor discuri pentru a nu întâmpina probleme cu drepturile:
[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]# Notă: Dacă nu intenționați să instalați ceph în scopuri de studiu, atunci comenzi nu creați cel puțin 3 noduri cu minimum două discuri, iar în șablon indicați că vor fi folosite discuri virtuale vda, vdb etc.
Excelent, acum trebuie să definim toate aceste mașini:
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 La final există comanda —print-xml > \/tmp\/storage-1.xml, care creează un fișier xml cu descrierea fiecărei mașini în dosarul \/tmp\/, dacă nu o adăugați, nu veți putea defini mașinile virtuale.
Acum trebuie să definim toate aceste mașini în 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 ~]#Acum un mic detaliu — tripleO folosește IPMI pentru a gestiona serverele în timpul instalării și introspecției.
Introspecția este procesul de inspectare a hardware-ului pentru a obține parametrii necesari pentru provisioning-ul ulterioar al nodurilor. Introspecția se efectuează cu ajutorul ironic — un serviciu destinat lucrului cu servere bare metal.
Dar aici apare o problemă — dacă la serverele fizice IPMI este un port dedicat (sau un port partajat, dar nu contează), la mașinile virtuale nu există astfel de porturi. Aici ne ajută un workaround numit vbmc — un utilitar care permite emularea unui port IPMI. Acest detaliu merită atenția celor care doresc să construiască un astfel de laborator pe un hypervisor ESXI — sincer, nu știu dacă există un analog al vbmc în acesta, așa că ar fi bine să vă ocupați de această problemă înainte de a începe desfășurarea.
Instalăm vbmc:
yum install python2-virtualbmcDacă sistemul dumneavoastră de operare nu găsește pachetul, adăugați repository-ul:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmAcum configurăm utilitarul. Aici totul este extrem de simplu. Acum este logic că în lista vbmc nu există servere
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Pentru a apărea, acestea trebuie anunțate manual astfel:
[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 ~]#Cred că sintaxa comenzii este clară și fără explicații. Totuși, deocamdată toate sesiunile noastre sunt în statutul DOWN. Pentru a trece în statutul UP, trebuie să le activăm:
[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 ~]#Și ultimul pas — trebuie să ajustăm regulile firewall-ului (sau să-l dezactivăm complet):
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
Acum ne vom conecta la undercloud și vom verifica dacă totul funcționează. Adresa mașinii gazdă este 192.168.255.200, iar pe undercloud am adăugat pachetul necesar ipmitool în timpul pregătirii pentru desfășurare:
[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 runningDupă cum puteți observa, am pornit cu succes nodul de control prin vbmc. Acum îl vom opri și vom continua:
[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 ~]#Următorul pas este introspecția nodurilor pe care se va instala overcloud. Pentru aceasta, trebuie să pregătim un fișier json cu detalii despre nodurile noastre. Rețineți că, spre deosebire de instalarea pe servere goale, în fișier este specificat portul pe care vbmc este pornit pentru fiecare dintre mașini.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interfață Tip Sursă Model MAC
-------------------------------------------------------
- rețea ovs-network-1 virtio 52:54:00:20:a2:2f
- rețea ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interfață Tip Sursă Model MAC
-------------------------------------------------------
- rețea ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interfață Tip Sursă Model MAC
-------------------------------------------------------
- rețea ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interfață Tip Sursă Model MAC
-------------------------------------------------------
- rețea ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interfață Tip Sursă Model MAC
-------------------------------------------------------
- rețea ovs-network-1 virtio 52:54:00:a7:fe:27Notă: pe nodul de control sunt două interfețe, dar în acest caz nu este important, pentru această instalare ne va ajunge și una singură.
Acum pregătim fișierul json. Trebuie să specificăm adresa MAC a portului prin care se va efectua provizionarea, parametrii nodului, să le dăm nume și să indicăm cum să accesăm 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"
}
]
}Acum trebuie să pregătim imaginile pentru ironic. Pentru aceasta le descărcăm prin wget și le instalăm:
(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 ~]$Încărcăm imaginile în undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Imaginea "overcloud-full-vmlinuz" a fost încărcată.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Nume | Format Disc | Dimensiune | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | activ |
+--------------------------------------+------------------------+-------------+---------+--------+
Imaginea "overcloud-full-initrd" a fost încărcată.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Nume | Format Disc | Dimensiune | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | activ |
+--------------------------------------+-----------------------+-------------+----------+--------+
Imaginea "overcloud-full" a fost încărcată.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Nume | Format Disc | Dimensiune | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | activ |
+--------------------------------------+----------------+-------------+------------+--------+
Imaginea "bm-deploy-kernel" a fost încărcată.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Nume | Format Disc | Dimensiune | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | activ |
+--------------------------------------+------------------+-------------+---------+--------+
Imaginea "bm-deploy-ramdisk" a fost încărcată.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Nume | Format Disc | Dimensiune | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | activ |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Verificăm că toate imaginile au fost încărcate
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Nume | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | activ |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | activ |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | activ |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | activ |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | activ |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Încă un pas — trebuie să adăugăm serverul DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Acum putem da comanda pentru introspecție:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
A început fluxul de lucru Mistral tripleo.baremetal.v1.register_or_update. ID execuție: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Așteptând mesaje în coada 'tripleo' fără limită de timp.
5 noduri au fost mutate cu succes în starea "manageable".
Nod înregistrat cu succes UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Nod înregistrat cu succes UUID b89a72a3-6bb7-429a-93bc-48393d225838
Nod înregistrat cu succes UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Nod înregistrat cu succes UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Nod înregistrat cu succes UUID 766ab623-464c-423d-a529-d9afb69d1167
Așteptând finalizarea introspecției...
A început fluxul de lucru Mistral tripleo.baremetal.v1.introspect. ID execuție: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Așteptând mesaje în coada 'tripleo' fără limită de timp.
Introspecția nodului b89a72a3-6bb7-429a-93bc-48393d225838 s-a finalizat. Stare:SUCCES. Erori:None
Introspecția nodului 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e s-a finalizat. Stare:SUCCES. Erori:None
Introspecția nodului bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 s-a finalizat. Stare:SUCCES. Erori:None
Introspecția nodului 766ab623-464c-423d-a529-d9afb69d1167 s-a finalizat. Stare:SUCCES. Erori:None
Introspecția nodului b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 s-a finalizat. Stare:SUCCES. Erori:None
Introspecție reușită pentru 5 noduri.
A început fluxul de lucru Mistral tripleo.baremetal.v1.provide. ID execuție: f5594736-edcf-4927-a8a0-2a7bf806a59a
Așteptând mesaje în coada 'tripleo' fără limită de timp.
5 noduri au fost mutate cu succes în starea "available".
(undercloud) [stack@undercloud ~]$După cum se poate vedea din ieșire, totul s-a finalizat fără erori. Să verificăm dacă toate nodurile sunt în starea available:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Nume | UUID Instanță | Stare Putere | Stare Provisional | Întreținere |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | oprește puterea | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | oprește puterea | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | oprește puterea | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | oprește puterea | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | oprește puterea | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Dacă nodurile sunt într-o altă stare, de obicei manageable, atunci ceva nu a funcționat și trebuie să verificăm jurnalul pentru a înțelege de ce s-a întâmplat asta. Rețineți că în acest scenariu folosim virtualizarea și pot apărea bug-uri legate de utilizarea mașinilor virtuale sau vbmc.
În continuare, trebuie să specificăm ce nod va îndeplini ce funcție — adică să indicăm profilul cu care va fi desfășurat nodul:
(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 ~]$Specificați un profil pentru fiecare nod:
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-d9afb69d1167Verificăm că am făcut totul corect:
(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 ~]$Dacă totul este corect, dăm comanda pentru a implementa 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Într-o instalare reală, evident, se vor folosi șabloane personalizate; în cazul nostru, acest lucru va complica foarte mult procesul, deoarece va trebui să explicăm fiecare modificare din șablon. Așa cum s-a menționat anterior, chiar și o instalare simplă ne va fi suficientă pentru a observa cum funcționează.
Notă: variabila —libvirt-type qemu este necesară în acest caz, deoarece vom folosi virtualizarea nested. În caz contrar, nu veți putea lansa mașini virtuale.
Acum aveți aproximativ o oră, sau poate mai mult (în funcție de capacitățile hardware-ului) și trebuie să sperați că, la finalul acestei perioade, veți vedea următorul mesaj:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stiva CREATE a fost finalizată cu succes
Stiva overcloud CREATE_COMPLETE
Host 192.168.255.21 nu a fost găsit în /home/stack/.ssh/known_hosts
A început fluxul de lucru Mistral tripleo.deployment.v1.get_horizon_url. ID de execuție: fcb996cd-6a19-482b-b755-2ca0c08069a9
Endpoint Overcloud: http://192.168.255.21:5000/
URL-ul Dashboard-ului Overcloud Horizon: http://192.168.255.21:80/dashboard
Fișier rc Overcloud: /home/stack/overcloudrc
Overcloud Implementat
(undercloud) [stack@undercloud ~]$Acum aveți aproape o versiune completă de OpenStack, pe care o puteți folosi pentru a învăța, a experimenta etc.
Să verificăm dacă totul funcționează corect. În directorul de acasă al utilizatorului stack există două fișiere — unul stackrc (pentru gestionarea undercloud) și al doilea overcloudrc (pentru gestionarea overcloud). Aceste fișiere trebuie specificate ca sursă, deoarece conțin informațiile necesare pentru autentificare.
(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 ~]$În instalarea mea, mai trebuie să adaug un mic detaliu — să creez o rută pe controler, deoarece mașina de la care lucrez se află în altă rețea. Pentru aceasta, ne vom conecta la control-1 cu contul heat-admin și vom adăuga ruta.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Ultima conectare: Vin Aug 14 09:47:40 2020 de la 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Și acum puteți accesa orizontul. Toate informațiile - adresele, numele de utilizator și parola - sunt în fișierul /home/stack/overcloudrc. Schema finală arată astfel:
Apropo, în instalarea noastră, adresele mașinilor au fost atribuite prin DHCP și, după cum vedeți, sunt atribuite „la întâmplare”. Puteți defini strict în template ce adresă trebuie asociată fiecărei mașini în timpul desfășurării, dacă este necesar.
Cum circulă traficul între mașinile virtuale?
În acest articol vom analiza trei variante de trecere a traficului.
- Două mașini pe același hypervisor într-o rețea L2.
- Două mașini pe hypervisoare diferite într-o rețea L2.
- Două mașini în rețele diferite (routing între rețele).
Cazurile cu ieșire în lumea externă prin rețeaua externă, folosind adrese flotante, precum și rutare distribuită le vom analiza data viitoare; deocamdată ne vom opri asupra traficului intern.
Pentru verificare, să construim următoarea schemă:
Am creat 4 mașini virtuale - 3 într-o rețea L2 - net-1, și încă una în rețeaua net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Nume | Tenant ID | Statut | Stare sarcină | Stare putere | Rețele |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIV | - | Rulare | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIV | - | Rulare | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIV | - | Rulare | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIV | - | Rulare | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Să ne uităm pe ce hypervisoare sunt amplasate mașinile create:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
Mașinile vm-1 și vm-3 sunt localizate pe compute-0, în timp ce mașinile vm-2 și vm-4 sunt pe nodul compute-1.
De asemenea, a fost creat un rutator virtual pentru a permite rutarea între rețelele specificate:
(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 ~]$ Rutatorul are două porturi virtuale care îndeplinesc rolul de gateway-uri pentru rețele:
(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 ~]$ Dar înainte de a verifica cum circulă traficul, haideți să vedem ce avem în prezent pe nodul de control (care este și nodul de rețea) și pe nodul compute. Să începem cu nodul compute.
[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 ~]$Momentan, nodul are trei brigde ovs — br-int, br-tun, br-ex. Între ele, așa cum vedem, există un set de interfețe. Pentru o mai bună înțelegere, vom reprezenta toate aceste interfețe pe un schemă și vom observa ce obținem.
La adresele unde sunt activate tunelurile VxLAN, se poate observa că un tunel este activ pe compute-1 (192.168.255.26), iar celălalt tunel se uită spre control-1 (192.168.255.15). Dar cel mai interesant este că br-ex nu are interfețe fizice, iar dacă ne uităm la fluxurile configurate, se poate observa că acest brigde, în acest moment, poate doar să blocheze traficul.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
greeth0: flags=4163 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
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 ~]$ După cum se poate observa din ieșire, adresa a fost atașată direct pe portul fizic, și nu pe interfața virtuală a brigde-ului.
[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 ~]$ Conform primei reguli, tot ceea ce provine din portul phy-br-ex trebuie să fie eliminat.
Totodată, în acest brigde nu există nicio altă sursă de trafic, în afară de această interfață (conexiunea cu br-int), iar având în vedere blocările, se pare că în brigde a ajuns trafic BUM.
Adică, de la acest nod, traficul poate ieși doar prin tunelul VxLAN și deloc altfel. Totuși, dacă activăm DVR, situația se va schimba, dar cu asta ne vom ocupa altă dată. Când se folosește izolarea rețelelor, de exemplu prin intermediul VLAN-urilor, veți avea mai multe interfețe L3 în VLAN-ul 0, nu doar una. Totuși, traficul VxLAN va ieși de la nod exact în același mod, dar încastrat și într-un VLAN dedicat.
Am rezolvat situația cu nodul compute, să trecem la nodul de control.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (intern)
eth0 1/2: (sistem)
phy-br-ex 2/niciunul: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (intern)
int-br-ex 1/niciunul: (patch: peer=phy-br-ex)
patch-tun 2/niciunul: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (intern)
patch-int 1/niciunul: (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 ~]$De fapt, se poate spune că totul este la fel, însă adresa IP nu mai este pe interfața fizică, ci pe un pod virtual. Acest lucru s-a făcut deoarece acest port este portul prin care va ieși traficul spre lumea externă.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 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
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 ~]$ Acest port este legat de podul br-ex, iar fiindcă nu are etichete VLAN, acesta este un port de tip trunk pe care sunt permise toate VLAN-urile; în prezent, traficul iese afară fără etichetă, ceea ce este indicat de vlan-id 0 în ieșirea de mai sus.
Tot restul în acest moment este similar cu nodul compute — aceleași poduri, aceleași tuneluri care duc către cele două noduri compute.
Nu vom discuta despre nodurile de stocare în acest articol, dar pentru a înțelege, trebuie să spunem că partea de rețea a acestor noduri este extrem de simplă. În cazul nostru, există un singur port fizic (eth0) asociat cu o adresă IP și atât. Nu există tuneluri VxLAN, punți de tuneluri etc. — nu există ovs deloc, deoarece nu are sens. Atunci când se utilizează izolarea rețelelor — pe acest nod vor fi două interfețe (porturi fizice, boduri sau pur și simplu două VLAN-uri — nu contează — depinde de ceea ce doriți) — unul pentru management, celălalt pentru trafic (scriere pe discul VM, citire de pe disc etc.).
Am înțeles ce avem pe noduri în absența unor servicii. Acum vom lansa 4 mașini virtuale și vom observa cum se schimbă schema descrisă mai sus — ar trebui să apară porturi, routere virtuale etc.
Până acum, rețeaua noastră arată așa:
Avem câte două mașini virtuale pe fiecare nod de calcul. Vom examina, de exemplu, compute-0, cum este totul conectat.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Mașina are un singur interfață virtuală — 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 ~]$
Această interfață se conectează la bridge-ul linux:
[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 ~]$ După cum se poate observa din ieșirea din bridge, există doar două interfețe — tap95d96a75-a0 și qvb95d96a75-a0.
Merită să ne oprim puțin asupra tipurilor de dispozitive de rețea virtuale în OpenStack:
vtap — interfață virtuală, conectată la instanță (VM)
qbr — Linux bridge
qvb și qvo — pereche de vEth, conectată la Linux bridge și Open vSwitch bridge
br-int, br-tun, br-vlan — punți Open vSwitch
patch-, int-br-, phy-br- — interfețe patch Open vSwitch, care conectează punți
qg, qr, ha, fg, sg — porturi Open vSwitch, utilizate de dispozitivele virtuale pentru a se conecta la OVS
Așa cum înțelegem, dacă avem în bridge un port qvb95d96a75-a0, care este o pereche vEth, atunci undeva există partea sa corespunzătoare, care logic ar trebui să se numească qvo95d96a75-a0. Să vedem ce porturi există pe 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 ~]$ Așa cum vedem, portul se află în br-int. Br-int acționează ca un switch, terminând porturile mașinilor virtuale. Pe lângă qvo95d96a75-a0, în ieșire se vede portul qvo5bd37136-47. Acesta este portul pentru a doua mașină virtuală. În final, schema noastră arată acum așa:
Întrebarea care ar trebui să intereseze imediat cititorul atent este: de ce un linux bridge între portul mașinii virtuale și portul OVS? Motivul este că pentru protejarea mașinii sunt utilizate grupuri de securitate, care nu sunt altceva decât iptables. OVS nu funcționează cu iptables, așa că a fost inventat un astfel de "workaround". Totuși, acesta își trăiește ultimele zile — locul său este luat de conntrack în noile versiuni.
Deci, în cele din urmă, schema arată așa:
Două mașini pe același hypervisor într-o rețea L2.
Dat fiind că cele două VM-uri se află în aceeași rețea L2 și pe același hypervisor, traficul dintre ele va circula logic local prin br-int, deoarece ambele mașini vor fi în același 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 ~]$ Două mașini pe hypervisoare diferite într-o rețea L2.
Acum să vedem cum va circula traficul între cele două mașini într-o singură rețea L2, dar situate pe hypervisori diferiți. Dacă să fim cinstiți, lucrurile nu se vor schimba semnificativ, doar că traficul între hypervisori va circula printr-un tunel vxlan. Să vedem prin exemplul.
Adresele mașinilor virtuale între care vom monitoriza traficul:
[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
Interfață Tip Sursă Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Verificăm tabela de forwarding în br-int pe compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]$Traficul ar trebui să meargă pe portul 2 — să vedem ce port este acesta:
[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 ~]$Acesta este patch-tun — adică interfața din br-tun. Să vedem ce se întâmplă cu pachetul pe br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Pachetul este ambalat în VxLAN și trimis pe portul 2. Să vedem unde duce portul 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Acesta este tunelul vxlan pe 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 ~]$Ne îndreptăm spre compute-1 și vedem ce se întâmplă mai departe cu pachetul:
[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-ul se află în tabela de forwarding br-int pe compute-1, și după cum se vede în output-ul de mai sus, el este vizibil prin portul 2, care este portul în direcția 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Și mai departe, vedem că în br-int pe compute-1 există MAC-ul de destinație:
[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 ~]$ Asta înseamnă că pachetul primit va fi trimis pe portul 3, unde se află deja mașina virtuală instance-00000003.
Toată frumusețea desfășurării Openstack pentru studiu pe o infrastructură virtuală este că putem captura fără probleme traficul între hyper-vizoare și observa ce se întâmplă cu acesta. Acest lucru îl vom face acum, lansând tcpdump pe portul vnet către compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: ascultând pe vnet3, tip de link EN10MB (Ethernet), dimensiune captură 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), lungime 134)
192.168.255.19.39096 > 192.168.255.26.4789: [fără cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), lungime 84)
10.0.1.85 > 10.0.1.88: ICMP solicitare echo, id 5634, seq 16, lungime 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), lungime 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [fără cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), lungime 84)
10.0.1.88 > 10.0.1.85: ICMP răspuns echo, id 5634, seq 16, lungime 64
*****************omitted*******************Prima linie arată că pachetul cu adresa 10.0.1.85 se îndreaptă către adresa 10.0.1.88 (trafic ICMP), fiind încapsulat într-un pachet VxLAN cu vni 22, iar pachetul se deplasează de pe gazda 192.168.255.19 (compute-0) către gazda 192.168.255.26 (compute-1). Putem verifica că VNI corespunde celui specificat în ovs.
Să ne întoarcem la această linie actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 este vni în sistemul hexadecimal. Să convertim acest număr în sistemul decimal:
16 = 6*16^0+1*16^1 = 6+16 = 22Deci vni corespunde realității.
A doua linie arată traficul invers, dar nu are sens să o explicăm, acolo este clar.
Două mașini în rețele diferite (routare între rețele)
Ultimul caz de astăzi este rutarea între rețele în cadrul unui singur proiect folosind un router virtual. Analizăm cazul fără DVR (acesta va fi discutat într-un alt articol), așa că rutarea se realizează pe nodul de rețea. În cazul nostru, nodul de rețea nu este desprins ca o entitate separată și se află pe nodul de control.
La început, să verificăm dacă rutarea funcționează:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 octeți de date
64 octeți de la 10.0.2.8: seq=0 ttl=63 timp=7.727 ms
64 octeți de la 10.0.2.8: seq=1 ttl=63 timp=3.832 ms
^C
--- statistici ping 10.0.2.8 ---
2 pachete transmise, 2 pachete primite, pierdere de 0%
round-trip min/med/max = 3.832/5.779/7.727 msÎn această situație, pachetul ar trebui să fie trimis la gateway și acolo să fie rutat, așa că trebuie să aflăm adresa MAC a gateway-ului, pentru care vom verifica tabelul ARP în instanță:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) la fa:16:3e:c4:64:70 [ether] pe eth0
host-10-0-1-1.openstacklocal (10.0.1.1) la fa:16:3e:e6:2c:5c [ether] pe eth0
host-10-0-1-90.openstacklocal (10.0.1.90) la fa:16:3e:83:ad:a4 [ether] pe eth0
host-10-0-1-88.openstacklocal (10.0.1.88) la fa:16:3e:72:ad:53 [ether] pe eth0Acum să vedem unde ar trebui să fie trimis traficul către destinația (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 ~]$ Să vedem unde duce portul 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Totul este logic, traficul se îndreaptă spre br-tun. Să vedem în ce tunel vxlan va fi împachetat:
[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 ~]$ Portul trei este un tunel vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Care se conectează la nodul de control:
[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 ~]$ Traficul a ajuns la nodul de control, așa că trebuie să ne mutăm pe el și să vedem cum va avea loc rutarea.
După cum vă amintiți, nodul de control arăta exact ca nodul de calcul — aceleași trei punți, doar că br-ex avea un port fizic, prin care nodul putea trimite trafic în afară. Crearea instanțelor a modificat configurația pe nodurile de calcul — au fost adăugate linux bridge, iptables și interfețe în noduri. Crearea rețelelor și a routerelor virtuale a lăsat, de asemenea, amprente asupra configurației nodului de control.
Așadar, este evident că adresa MAC a gateway-ului ar trebui să fie în tabela de forwarding a br-int pe nodul de control. Să verificăm că este acolo și în ce direcție se uită:
[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-ul este vizibil din portul qr-0c52b15f-8f. Dacă ne întoarcem la lista de porturi virtuale din OpenStack, acest tip de port este utilizat pentru a conecta diverse dispozitive virtuale la OVS. Mai exact, qr este un port către routerul virtual, care este reprezentat sub formă de namespace.
Să vedem ce namespace-uri sunt pe 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 ~]$ Avem trei instanțe. Dar, judecând după nume, putem ghici scopul fiecăreia dintre ele. Ne vom întoarce la instanțele cu ID 0 și 1 mai târziu, acum ne interesează namespace-ul 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 ~]$ În acest namespace, există două interfețe interne, care au fost create anterior de noi. Ambele porturi virtuale au fost adăugate în br-int. Să verificăm adresa MAC a portului qr-0c52b15f-8f, deoarece traficul, judecând după adresa MAC de destinație, mergea exact pe această interfață.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163 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
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 ~]$ Deci, în acest caz, totul funcționează conform legilor standard de rutare. Deoarece traficul este destinat gazdei 10.0.2.8, acesta trebuie să iasă prin a doua interfață qr-92fa49b5-54 și să plece prin tunelul vxlan către nodul compute:
[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 ~]$ Totul este logic, fără surprize. Să vedem de unde se vede adresa MAC a gazdei 10.0.2.8 în br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ După cum este normal, traficul se îndreaptă spre br-tun, să vedem în ce tunel va merge mai departe traficul:
[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 ~]$ Traficul este direcționat prin tunel către compute-1. Și pe compute-1 totul este simplu — din br-tun, pachetul ajunge în br-int și de acolo în interfața mașinii virtuale:
[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 ~]$ Să verificăm dacă acesta este într-adevăr interfața corectă:
[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 ~]$ Așadar, am parcurs întreaga cale a pachetului. Cred că ați observat că traficul a trecut prin diferite tuneluri vxlan și a ieșit cu diferite VNI. Să vedem care sunt aceste VNI, după care vom colecta un dump pe portul nodului de control și ne vom asigura că traficul circulă exact așa cum a fost descris mai sus.
Prin urmare, tunelul către compute-0 are următorul actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Să traducem 0x16 în sistemul zecimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunelul către compute-1 are următorul VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Să traducem 0x63 în sistemul zecimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Acum să vedem dump-ul:
[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*******************Primul pachet este un pachet vxlan de la gazda 192.168.255.19 (compute-0) la gazda 192.168.255.15 (control-1) cu vni 22, în interiorul căruia este ambalat un pachet ICMP de la gazda 10.0.1.85 la gazda 10.0.2.8. Așa cum am calculat mai sus, vni corespunde ceea ce am văzut în ieșiri.
Al doilea pachet este un pachet vxlan de la gazda 192.168.255.15 (control-1) la gazda 192.168.255.26 (compute-1) cu vni 99, în interiorul căruia este ambalat un pachet ICMP de la gazda 10.0.1.85 la gazda 10.0.2.8. Așa cum am calculat mai sus, vni corespunde ceea ce am văzut în ieșiri.
Următoarele două pachete reprezintă traficul invers de la 10.0.2.8 la 10.0.1.85.
Deci, în final, am obținut următoarea schemă pentru nodul de control:
Se pare că este totul? Am uitat de două namespace-uri:
[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 ~]$ Așa cum am discutat despre arhitectura platformei cloud — ar fi bine ca mașinile să primească adrese automat de la serverul DHCP. Acesta sunt cele două servere DHCP pentru cele două rețele 10.0.1.0/24 și 10.0.2.0/24.
Să verificăm dacă este așa. În acest namespace există doar o singură adresă — 10.0.1.1 — adresa serverului DHCP, și aceasta este de asemenea inclusă în br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
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 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
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 0Să vedem dacă există procese ce conțin în numele lor qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 pe nodul de control:
[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 ~]$ Există un astfel de proces și, pe baza informațiilor prezentate în ieșirea de mai sus, putem, de exemplu, să vedem ce avem în închiriere în acest moment:
[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 ~]$În final, obținem acest set de servicii pe nodul de control:
Și țineți cont că acestea sunt doar 4 mașini, 2 rețele interne și un router virtual… Nu avem acum rețele externe, o mulțime de proiecte diferite, fiecare cu rețele proprii (care se suprapun), iar routerul distribuit este oprit; de fapt, în standul de testare a existat doar un nod de control (pentru redundanță ar trebui să existe un cvorum de trei noduri). Este logic că în comerț, totul este „puțin” mai complicat, dar în acest exemplu simplu înțelegem cum ar trebui să funcționeze – aveți 3 sau 300 de spații de nume este cu siguranță important, dar din punctul de vedere al funcționării întregii construcții – nu se va schimba nimic semnificativ… cu excepția cazului în care introduceți un SDN de la un furnizor. Dar asta este o poveste complet diferită.
Sper că a fost interesant. Dacă aveți observații/precizări sau dacă undeva am mințit deschis (sunt om și opinia mea va fi întotdeauna subiectivă) – scrieți ce trebuie corectat/adăugat – totul se poate corecta/adăuga.
În concluzie, aș dori să spun câteva cuvinte despre compararea Openstack (atât varianta standard, cât și cea de la furnizori) cu soluția cloud de la compania VMWare – am fost întrebat prea des acest lucru în ultimii doi ani și, sincer, am obosit de la acest subiect, dar totuși. Din punctul meu de vedere, este foarte greu să compari aceste două soluții, dar se poate spune cu certitudine că ambele au dezavantaje și, alegând o soluție, trebuie să cântăriți toate avantajele și dezavantajele.
Dacă OpenStack este o soluție condusă de comunitate, atunci VMWare are dreptul să facă doar ceea ce vrea (citiți – ceea ce îi este benefic) și acest lucru este logic – deoarece este o companie comercială care a învățat să facă bani de pe urma clienților săi. Dar există un „dar” mare și important – puteți să treceți de la OpenStack, de exemplu, de la Nokia, și să faceți o tranziție mică la o soluție de la, să zicem, Juniper (Contrail Cloud), dar este puțin probabil să reușiți să părăsiți VMWare. Pentru mine, aceste două soluții arată astfel – Openstack (varianta de la furnizori) este o cușcă simplă, în care sunteți pus, dar aveți cheia și puteți ieși în orice moment. VMWare – este o cușcă de aur, cheia cuștii este la stăpân și vă va costa foarte mult.
Nu fac publicitate pentru niciunul dintre produse — alegeți ceea ce vi se potrivește. Însă, dacă ar fi să fac o alegere, aș opta pentru ambele soluții — VMWare pentru cloud IT (sarcini ușoare, gestionare convenabilă), OpenStack de la un vendor precum Nokia sau Juniper (oferă soluții foarte bune la cheie) — pentru cloud telecom. Nu aș folosi OpenStack pentru cloud IT pur — ar fi ca și cum ai trage cu tunul în vrăbii, dar nu văd contraindicații în utilizarea lui, în afară de redundanță. Totuși, utilizarea VMWare în telecom — e ca și cum ai transporta pietriș cu un Ford Raptor — arată bine, dar șoferul trebuie să facă 10 curse în loc de una.
Părerea mea este că cel mai mare dezavantaj al VMWare este închiderea totală — compania nu vă va oferi nicio informație despre modul în care funcționează, de exemplu, vSAN sau ce se află în nucleul hypervisor-ului — deoarece nu le este convenabil — adică nu veți deveni niciodată expert în VMWare — fără suportul vendorului sunteți condamnat (întâlnesc frecvent experți în VMWare care sunt blocați de întrebări banale). Pentru mine, VMWare este ca achiziționarea unei mașini cu capota încuiată — da, este posibil să aveți specialiști care pot schimba curelele, dar doar cel care v-a vândut soluția poate deschide capota. Personal, nu îmi plac soluțiile în care nu pot interveni. Vei spune că poate nu va trebui să te bagi sub capotă. Da, este posibil, dar mă voi uita la tine când va trebui să construiești o funcționalitate mare în cloud din 20-30 de mașini virtuale, 40-50 de rețele, jumătate dintre ele dorind să iasă afară, iar cealaltă jumătate cerând accelerare SR-IOV, altfel va trebui să mai ai câteva zeci de astfel de mașini — altfel lipsesc performanțele.
Există și alte puncte de vedere, așa că doar tu decizi ce să alegi și, cel mai important — tu ești responsabil pentru alegerea ta. Aceasta este doar părerea mea — a unei persoane care a văzut și a experimentat cel puțin 4 produse — Nokia, Juniper, Red Hat și VMWare. Deci, am cu ce să compar.
Sursa: habr.com
