Cloud computing pătrunde din ce în ce mai adânc în viețile noastre și probabil că nu există o singură persoană care să nu fi folosit măcar o dată niciun serviciu cloud. Cu toate acestea, ce este exact un nor și cum funcționează, puțini oameni știu, chiar și la nivelul unei idei. 5G devine deja o realitate, iar infrastructura de telecomunicații începe să treacă de la soluții de tip pol la soluții cloud, așa cum a făcut atunci când a trecut de la soluții complet hardware la „stâlpi” virtualizați.
Astăzi vom vorbi despre lumea interioară a infrastructurii cloud, în special ne vom uita la elementele de bază ale părții de rețea.
Ce este un nor? Aceeași virtualizare - vizualizare profil?
Mai mult decât o întrebare logică. Nu - aceasta nu este virtualizare, deși nu s-ar putea face fără ea. Să ne uităm la două definiții:
Cloud computing (denumit în continuare Cloud) este un model pentru furnizarea de acces ușor de utilizat la resursele de calcul distribuite care trebuie să fie implementate și lansate la cerere, cu cea mai mică latență posibilă și costuri minime pentru furnizorul de servicii.
Virtualizare - aceasta este capacitatea de a împărți o entitate fizică (de exemplu, un server) în mai multe virtuale, crescând astfel utilizarea resurselor (de exemplu, ați avut 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ă alimentați hipervizorul, cu toate acestea, așa cum a arătat practica, jocul merită lumânarea. Un exemplu ideal de virtualizare este VMWare, care pregătește perfect mașinile virtuale, sau de exemplu KVM, pe care îl prefer, dar asta e o chestiune de gust.
Folosim virtualizarea fără să ne dăm seama și chiar și routerele de fier folosesc deja virtualizarea - de exemplu, în cea mai recentă versiune de JunOS, sistemul de operare este instalat ca o mașină virtuală deasupra unei distribuții Linux în timp real (Wind River 9). Dar virtualizarea nu este cloud, dar cloud-ul nu poate exista fără virtualizare.
Virtualizarea este unul dintre elementele de bază pe care este construit cloud-ul.
Crearea unui nor prin simpla colectare a mai multor hipervizoare într-un domeniu L2, adăugarea de câteva manuale Yaml pentru înregistrarea automată a vlan-urilor printr-un fel de ansible și blocarea a ceva ca un sistem de orchestrare pe toate pentru a crea automat mașini virtuale nu va funcționa. Va fi mai precis, dar Frankensteinul rezultat nu este norul de care avem nevoie, deși poate fi visul suprem pentru alții. Mai mult, dacă iei același Openstack, în esență este încă Frankenstein, dar ei bine, să nu vorbim despre asta deocamdată.
Dar înțeleg că din definiția prezentată mai sus nu este complet clar ce poate fi numit de fapt un nor.
Prin urmare, un document de la NIST (Institutul Național de Standarde și Tehnologie) oferă 5 caracteristici principale pe care ar trebui să le aibă o infrastructură cloud:
Furnizarea de servicii la cerere. Utilizatorului trebuie să i se acorde acces gratuit la resursele informatice care îi sunt alocate (cum ar fi rețele, discuri virtuale, memorie, nuclee de procesor etc.), iar aceste resurse trebuie furnizate automat – adică fără intervenția furnizorului de servicii.
Disponibilitate largă de servicii. Accesul la resurse trebuie asigurat prin mecanisme standard care să permită utilizarea atât a PC-urilor standard, cât și a clienților subțiri și a dispozitivelor mobile.
Combinarea resurselor în pool-uri. Pool-urile de resurse trebuie să fie capabile să ofere resurse mai multor clienți în același timp, asigurându-se că clienții sunt izolați și lipsiți de influență reciprocă și concurență pentru resurse. Rețelele sunt, de asemenea, incluse în pool-uri, ceea ce indică posibilitatea utilizării adresei suprapuse. Piscinele trebuie să fie capabile să se extindă la cerere. Utilizarea pool-urilor face posibilă asigurarea nivelului necesar de toleranță la erori de resurse și de abstracție a resurselor fizice și virtuale - destinatarului serviciului i se oferă pur și simplu setul de resurse pe care l-a solicitat (unde sunt situate fizic aceste resurse, pe câte servere și comutatoare - nu contează pentru client). Totuși, trebuie să ținem cont de faptul că furnizorul trebuie să asigure rezervarea transparentă a acestor resurse.
Adaptare rapidă la diferite condiții. Serviciile trebuie să fie flexibile - furnizarea rapidă a resurselor, redistribuirea acestora, adăugarea sau reducerea resurselor la cererea clientului, iar din partea clientului ar trebui să existe sentimentul că resursele cloud sunt nesfârșite. Pentru ușurință de înțelegere, de exemplu, nu vedeți un avertisment că o parte din spațiul dvs. pe disc din Apple iCloud a dispărut deoarece hard disk-ul de pe server s-a defectat, iar unitățile se defectează. În plus, din partea dumneavoastră, posibilitățile acestui serviciu sunt aproape nelimitate - aveți nevoie de 2 TB - nicio problemă, ați plătit și primit. Un exemplu similar poate fi dat cu Google.Drive sau Yandex.Disk.
Posibilitatea de a măsura serviciul prestat. Sistemele cloud trebuie să controleze și să optimizeze automat resursele consumate, iar aceste mecanisme trebuie să fie transparente atât pentru utilizator, cât și pentru furnizorul de servicii. Adică puteți verifica oricând câte resurse consumați dvs. și clienții tăi.
Merită să luăm în considerare faptul că aceste cerințe sunt în mare parte cerințe pentru un cloud public, deci 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 încă trebuie făcute, altfel nu vom obține toate beneficiile cloud computing-ului.
De ce avem nevoie de un nor?
Cu toate acestea, orice tehnologie nouă sau existentă, orice protocol nou este creat pentru ceva (bine, cu excepția RIP-ng, desigur). Nimeni nu are nevoie de un protocol de dragul unui protocol (bine, cu excepția RIP-ng, desigur). Este logic ca Cloud-ul este creat pentru a oferi un fel de serviciu utilizatorului/clientului. Cu toții suntem familiarizați cu cel puțin câteva servicii cloud, de exemplu Dropbox sau Google.Docs, și cred că majoritatea oamenilor le folosesc cu succes - de exemplu, acest articol a fost scris folosind serviciul cloud Google.Docs. Dar serviciile cloud pe care le cunoaștem sunt doar o parte din capacitățile cloud-ului – mai precis, sunt doar un serviciu de tip SaaS. Putem oferi un serviciu cloud în trei moduri: sub formă de SaaS, PaaS sau IaaS. De ce serviciu aveți nevoie depinde de dorințele și capacitățile dumneavoastră.
Să ne uităm la fiecare în ordine:
Software-ul ca serviciu (SaaS) este un model pentru furnizarea unui serviciu cu drepturi depline clientului, de exemplu, un serviciu de e-mail precum Yandex.Mail sau Gmail. În acest model de livrare a serviciilor, dumneavoastră, ca client, nu faceți nimic altceva decât să utilizați serviciile - adică nu trebuie să vă gândiți la configurarea serviciului, la toleranța la erori sau la redundanța acestuia. Principalul lucru este să nu vă compromiteți parola; furnizorul acestui serviciu se va ocupa de restul pentru dvs. Din punctul de vedere al furnizorului de servicii, acesta este pe deplin responsabil pentru întregul serviciu - de la hardware-ul serverului și sistemele de operare gazdă până la setările de baze de date și software.
Platforma ca serviciu (PaaS) — atunci când utilizați acest model, furnizorul de servicii oferă clientului o piesă de prelucrat pentru serviciu, de exemplu, să luăm un server Web. Furnizorul de servicii a furnizat clientului un server virtual (de fapt, un set de resurse, precum RAM/CPU/Storage/Rețele etc.), și chiar a instalat pe acest server sistemul de operare și software-ul necesar, totuși, configurarea de toate aceste lucruri sunt făcute de client însuși și pentru prestarea serviciului clientul răspunde. Furnizorul de servicii, ca și în cazul precedent, este responsabil pentru performanța echipamentelor fizice, a hipervizoarelor, a mașinii virtuale în sine, a disponibilității rețelei sale etc., dar serviciul în sine nu mai este în aria sa de responsabilitate.
Infrastructura ca serviciu (IaaS) - această abordare este deja mai interesantă, de fapt, furnizorul de servicii oferă clientului o infrastructură virtualizată completă - adică un set (pool) de resurse, cum ar fi nuclee CPU, RAM, rețele etc. clientul - ce dorește clientul să facă cu aceste resurse în cadrul pool-ului alocat (cota) - nu este deosebit de important pentru furnizor. Indiferent dacă clientul dorește să-și creeze propriul vEPC sau chiar să creeze un mini operator și să ofere servicii de comunicare - fără îndoială - fă-o. Într-un astfel de scenariu, furnizorul de servicii este responsabil pentru furnizarea resurselor, toleranța și disponibilitatea acestora, precum și sistemul de operare care le permite să pună în comun aceste resurse și să le pună la dispoziție clientului cu posibilitatea de a crește sau reduce resursele în orice moment. la cererea clientului. Clientul configurează el însuși toate mașinile virtuale și alte betele prin intermediul portalului și al consolei de autoservire, inclusiv configurarea rețelelor (cu excepția rețelelor externe).
Ce este OpenStack?
În toate cele trei opțiuni, furnizorul de servicii are nevoie de un sistem de operare care să permită crearea unei infrastructuri cloud. De fapt, cu SaaS, mai mult de o divizie este responsabilă pentru întregul teanc de tehnologii - există o divizie care este responsabilă de infrastructură - adică oferă IaaS unei alte divizii, această divizie oferă SaaS clientului. OpenStack este unul dintre sistemele de operare cloud care vă permite să colectați o mulțime de switch-uri, servere și sisteme de stocare într-un singur pool de resurse, împărțiți acest pool comun în subpool-uri (chiriași) și furnizați aceste resurse clienților prin rețea.
OpenStack este un sistem de operare cloud care vă permite să controlați grupuri mari de resurse de calcul, stocare de date și resurse de rețea, furnizate și gestionate printr-un API folosind mecanisme standard de autentificare.
Cu alte cuvinte, acesta este un set de proiecte de software gratuit care este conceput pentru a crea servicii cloud (atât publice, cât și private) - adică un set de instrumente care vă permit să combinați serverul și comutarea echipamentelor într-un singur pool de resurse, să gestionați aceste resurse, oferind nivelul necesar de toleranță la erori.
La momentul scrierii acestui material, structura OpenStack arată astfel:
Poza luată de pe
Fiecare dintre componentele incluse în OpenStack îndeplinește o funcție specifică. Această arhitectură distribuită vă permite să includeți în soluție setul de componente funcționale de care aveți nevoie. Cu toate acestea, unele componente sunt componente rădăcină și îndepărtarea lor va duce la inoperabilitatea completă sau parțială a soluției în ansamblu. Aceste componente sunt de obicei clasificate ca:
- Contul Meu — GUI bazat pe web pentru gestionarea serviciilor OpenStack
- Keystone este un serviciu de identitate centralizat care oferă funcționalități de autentificare și autorizare pentru alte servicii, precum și gestionarea acreditărilor utilizatorilor și a rolurilor acestora.
- neutron - un serviciu de rețea care oferă conectivitate între interfețele diferitelor servicii OpenStack (inclusiv conectivitate între VM și accesul acestora la lumea exterioară)
- Zgură — oferă acces la stocarea bloc pentru mașinile virtuale
- Nova — managementul ciclului de viață al mașinilor virtuale
- ochire — depozit de imagini și instantanee ale mașinilor virtuale
- Rapid — oferă acces la obiectul de stocare
- Ceilometru — un serviciu care oferă capacitatea de a colecta telemetrie și de a măsura resursele disponibile și consumate
- căldură — orchestrare bazată pe șabloane pentru crearea și furnizarea automată a resurselor
O listă completă a tuturor proiectelor și scopul acestora poate fi vizualizată .
Fiecare componentă OpenStack este un serviciu care îndeplinește o anumită funcție și oferă un API pentru a gestiona acea funcție și a interacționa cu alte servicii ale sistemului de operare în cloud pentru a crea o infrastructură unificată. De exemplu, Nova oferă gestionarea resurselor de calcul și un API pentru acces la configurarea acestor resurse, Glance oferă management de imagine și un API pentru gestionarea acestora, Cinder oferă stocare bloc și un API pentru gestionarea acestora etc. Toate funcțiile sunt interconectate într-un mod foarte strâns.
Cu toate acestea, dacă te uiți la asta, toate serviciile care rulează în OpenStack sunt în cele din urmă un fel de mașină virtuală (sau container) conectată la rețea. Apare întrebarea - de ce avem nevoie de atâtea elemente?
Să trecem prin algoritmul pentru crearea unei mașini virtuale și conectarea acesteia la rețea și stocarea persistentă în Openstack.
- Când creați o solicitare pentru a crea o mașină, fie că este vorba de o solicitare prin Horizon (Dashboard) sau de o solicitare prin CLI, primul lucru care se întâmplă este autorizarea solicitării dvs. pe Keystone - puteți crea o mașină, are dreptul de a utiliza această rețea, face proiectul de cotă etc.
- Keystone vă autentifică cererea și generează un token de autentificare în mesajul de răspuns, care va fi folosit în continuare. După ce a primit un răspuns de la Keystone, cererea este trimisă către Nova (nova api).
- Nova-api verifică validitatea solicitării dvs. contactând Keystone folosind simbolul de autentificare generat anterior
- Keystone efectuează autentificare și oferă informații despre permisiuni și restricții bazate pe acest token de autentificare.
- Nova-api creează o intrare pentru noua VM în nova-database și transmite solicitarea de a crea mașina către nova-scheduler.
- Nova-scheduler selectează gazda (nodul computerului) pe care va fi implementat VM-ul pe baza parametrilor, greutăților și zonelor specificați. O înregistrare a acestui lucru și ID-ul VM sunt scrise în nova-database.
- Apoi, nova-scheduler contactează nova-compute cu o solicitare de implementare a unei instanțe. Nova-compute contactează nova-conductor pentru a obține informații despre parametrii mașinii (nova-conductor este un element 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 cu baza de date reducerea sarcinii de consistență).
- Nova-conductor primește informațiile solicitate de la nova-database și le transmite către nova-compute.
- Apoi, nova-compute apelează o privire pentru a obține ID-ul imaginii. Glace validează cererea în Keystone și returnează informațiile solicitate.
- Nova-compute contactează neutronul pentru a obține informații despre parametrii rețelei. Similar cu privirea, neutron validează cererea în Keystone, după care creează o intrare în baza de date (identificator de port, etc.), creează o cerere de creare a unui port și returnează informațiile solicitate către nova-compute.
- Nova-compute contactează cind cu o solicitare de a aloca un volum mașinii virtuale. Similar cu Glance, cidru validează cererea în Keystone, creează o cerere de creare a volumului și returnează informațiile solicitate.
- Nova-compute contactează libvirt cu o solicitare de a implementa o mașină virtuală cu parametrii specificați.
De fapt, o operațiune aparent simplă de a crea o mașină virtuală simplă se transformă într-un astfel de vârtej de apeluri API între elementele platformei cloud. Mai mult, după cum puteți vedea, chiar și serviciile desemnate anterior constau și din componente mai mici între care are loc interacțiunea. Crearea unei mașini este doar o mică parte din ceea ce vă permite să faceți platforma cloud - există un serviciu responsabil cu echilibrarea traficului, un serviciu responsabil pentru stocarea bloc, un serviciu responsabil cu DNS, un serviciu responsabil cu furnizarea de servere bare metal etc. Cloud-ul vă permite să vă tratați mașinile virtuale ca pe o turmă de oi (spre deosebire de virtualizare). Dacă se întâmplă ceva cu mașina dvs. într-un mediu virtual - o restabiliți din backup-uri etc., dar aplicațiile cloud sunt construite în așa fel încât mașina virtuală să nu joace un rol atât de important - mașina virtuală a „murit” - nicio problemă - se creează pur și simplu unul nou, vehiculul se bazează pe șablon și, după cum se spune, echipa nu a observat pierderea luptătoarei. Desigur, acest lucru prevede prezența mecanismelor de orchestrare - folosind șabloanele Heat, puteți implementa cu ușurință o funcție complexă constând din zeci de rețele și mașini virtuale.
Merită întotdeauna să rețineți că nu există infrastructură cloud fără o rețea - fiecare element într-un fel sau altul interacționează cu alte elemente prin intermediul rețelei. În plus, cloud-ul are o rețea absolut non-statică. Desigur, rețeaua de bază este și mai mult sau mai puțin statică - noi noduri și comutatoare nu sunt adăugate în fiecare zi, dar componenta de suprapunere se poate schimba și se va schimba inevitabil în mod constant - vor fi adăugate sau șterse noi rețele, vor apărea noi mașini virtuale și cele vechi vor apărea a muri. Și după cum vă amintiți din definiția cloud-ului dată chiar la începutul articolului, resursele ar trebui alocate utilizatorului în mod automat și cu cea mai mică (sau mai bine, fără) intervenție din partea furnizorului de servicii. Adică, tipul de furnizare a resurselor de rețea care există acum sub forma unui front-end sub forma unui cont personal accesibil prin http/https și a inginerului de rețea de serviciu Vasily ca backend nu este un cloud, chiar și dacă Vasily are opt mâini.
Neutron, ca serviciu de rețea, oferă un API pentru gestionarea porțiunii de rețea a infrastructurii cloud. Serviciul alimentează și gestionează porțiunea de rețea a Openstack prin furnizarea unui strat de abstractizare numit Network-as-a-Service (NaaS). Adică, rețeaua este aceeași unitate virtuală măsurabilă ca, de exemplu, nucleele CPU virtuale sau cantitatea de RAM.
Dar înainte de a trece la arhitectura părții de rețea a OpenStack, să luăm în considerare cum funcționează această rețea în OpenStack și de ce rețeaua este o parte importantă și integrantă a cloud-ului.
Deci avem două VM-uri client RED și două VM-uri client GREEN. Să presupunem că aceste mașini sunt situate pe două hipervizoare în acest fel:
Momentan, aceasta este doar virtualizarea a 4 servere și nimic mai mult, deoarece până acum tot ce am făcut este să virtualizăm 4 servere, plasându-le pe două servere fizice. Și până acum nici măcar nu sunt conectați la rețea.
Pentru a face un nor, trebuie să adăugăm mai multe componente. În primul rând, virtualizăm partea de rețea - trebuie să conectăm aceste 4 mașini în perechi, iar clienții doresc o conexiune L2. Puteți folosi un comutator și configura un trunk în direcția lui și puteți rezolva totul folosind un bridge linux sau, pentru utilizatorii mai avansați, openvswitch (vom reveni la asta mai târziu). Dar pot exista o mulțime de rețele, iar împingerea constantă a L2 printr-un comutator nu este cea mai bună idee - există diferite departamente, un birou de service, luni de așteptare pentru finalizarea unei cereri, săptămâni de depanare - în lumea modernă acest lucru abordarea nu mai funcționează. Și cu cât o companie înțelege mai devreme acest lucru, cu atât este mai ușor să avanseze. Prin urmare, între hipervizori vom selecta o rețea L3 prin care mașinile noastre virtuale vor comunica, iar deasupra acestei rețele L3 vom construi rețele virtuale de suprapunere L2 unde va rula traficul mașinilor noastre virtuale. Puteți utiliza GRE, Geneve sau VxLAN ca încapsulare. Să ne concentrăm pe acesta din urmă deocamdată, deși nu este deosebit de important.
Trebuie să găsim VTEP undeva (sper că toată lumea este familiarizată cu terminologia VxLAN). Deoarece avem o rețea L3 care vine direct de la servere, nimic nu ne împiedică să plasăm VTEP pe serverele în sine, iar OVS (OpenvSwitch) este excelent în a face acest lucru. Ca rezultat, am obținut acest design:
Deoarece traficul între mașinile virtuale trebuie împărțit, porturile către mașinile virtuale vor avea numere vlan diferite. Numărul etichetei joacă un rol doar în cadrul unui comutator virtual, deoarece atunci când este încapsulat în VxLAN, îl putem elimina cu ușurință, deoarece vom avea un VNI.
Acum ne putem crea mașinile și rețelele virtuale pentru ele fără probleme.
Totuși, ce se întâmplă dacă clientul are o altă mașină, dar se află pe o altă rețea? Avem nevoie de rooting între rețele. Ne vom uita la o opțiune simplă atunci când se utilizează rutarea centralizată - adică traficul este direcționat prin noduri speciale de rețea dedicate (bine, de regulă, acestea sunt combinate cu noduri de control, așa că vom avea același lucru).
Pare a fi nimic complicat - facem o interfață bridge pe nodul de control, conducem traficul către acesta și de acolo îl direcționăm acolo unde avem nevoie. Dar problema este că clientul RED dorește să folosească rețeaua 10.0.0.0/24, iar clientul GREEN vrea să folosească rețeaua 10.0.0.0/24. Adică începem să intersectăm spațiile de adrese. În plus, clienții nu doresc ca alți clienți să poată ruta în rețelele lor interne, ceea ce are sens. Pentru a separa rețelele și traficul de date client, vom aloca un spațiu de nume separat pentru fiecare dintre ele. Spațiul de nume este de fapt o copie a stivei de rețea Linux, adică clienții din spațiul de nume RED sunt complet izolați de clienții din spațiul de nume VERDE (ei bine, fie rutarea între aceste rețele de clienți este permisă prin spațiul de nume implicit, fie pe echipamentele de transport din amonte).
Adică, obținem următoarea diagramă:
Tunelurile L2 converg de la toate nodurile de calcul la nodul de control. nodul unde se află interfața L3 pentru aceste rețele, fiecare într-un spațiu de nume 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ă. Adică trebuie să ieșim în lumea exterioară. Există diferite opțiuni aici. Să facem cea mai simplă variantă. Vom adăuga o rețea la fiecare client, care va fi valabilă în rețeaua furnizorului și nu se va suprapune cu alte rețele. De asemenea, rețelele se pot intersecta și se pot uita la diferite VRF-uri din partea rețelei furnizorului. Datele din rețea vor locui și în spațiul de nume al fiecărui client. Cu toate acestea, ei vor ieși în continuare în lumea exterioară printr-o interfață fizică (sau legătura, ceea ce este mai logic). Pentru a separa traficul clientului, traficul care merge în exterior va fi etichetat cu o etichetă VLAN alocată clientului.
Ca rezultat, am obținut această diagramă:
O întrebare rezonabilă este de ce să nu faci gateway-uri pe nodurile de calcul în sine? Aceasta nu este o problemă mare; în plus, dacă porniți routerul distribuit (DVR), acesta va funcționa. În acest scenariu, luăm în considerare cea mai simplă opțiune cu un gateway centralizat, care este utilizat implicit în Openstack. Pentru funcțiile cu sarcină mare, vor folosi atât un router distribuit, cât și tehnologii de accelerare, cum ar fi SR-IOV și Passthrough, dar așa cum se spune, aceasta este o cu totul altă poveste. Mai întâi, să ne ocupăm de partea de bază, apoi vom intra în detalii.
De fapt, schema noastră este deja funcțională, dar există câteva nuanțe:
- Trebuie să ne protejăm cumva mașinile, adică să punem un filtru pe interfața de comutare către client.
- Faceți posibil ca o mașină virtuală să obțină automat o adresă IP, astfel încât să nu fie nevoie să vă conectați la ea prin consolă de fiecare dată și să înregistrați adresa.
Să începem cu protecția mașinii. Pentru asta poți folosi banale iptables, de ce nu.
Adică, acum topologia noastră a devenit puțin mai complicată:
Sa trecem peste. Trebuie să adăugăm un server DHCP. Cel mai ideal loc pentru a localiza serverele DHCP pentru fiecare client ar fi nodul de control deja menționat mai sus, unde se află spațiile de nume:
Cu toate acestea, există o mică problemă. Ce se întâmplă dacă totul repornește și toate informațiile despre închirierea adreselor pe DHCP dispar. Este logic ca mașinilor să li se dea noi adrese, ceea ce nu este foarte convenabil. Există două moduri de ieșire aici - fie folosiți nume de domenii și adăugați un server DNS pentru fiecare client, atunci adresa nu va fi deosebit de importantă pentru noi (similar cu partea de rețea din k8s) - dar există o problemă cu rețelele externe, deoarece adresele pot fi emise și în ele prin DHCP - aveți nevoie de sincronizare cu serverele DNS din platforma cloud și un server DNS extern, ceea ce în opinia mea nu este foarte flexibil, dar este destul de posibil. Sau a doua opțiune este să folosiți metadate - adică să salvați informații despre adresa emisă mașinii, astfel încât serverul DHCP să știe ce adresă să emită mașinii dacă aparatul a primit deja o adresă. A doua opțiune este mai simplă și mai flexibilă, deoarece vă permite să salvați informații suplimentare despre mașină. Acum să adăugăm metadatele agentului în diagramă:
O altă problemă care merită discutată este capacitatea de a utiliza o singură rețea externă de către toți clienții, deoarece rețelele externe, dacă trebuie să fie valabile în întreaga rețea, vor fi dificile - trebuie să alocați și să controlați constant alocarea acestor rețele. Abilitatea de a utiliza o singură rețea externă pre-configurată pentru toți clienții va fi foarte utilă atunci când se creează un cloud public. Acest lucru va facilita implementarea mașinilor deoarece nu trebuie să consultăm o bază de date de adrese și să selectăm un spațiu de adrese unic pentru rețeaua externă a fiecărui client. În plus, putem înregistra o rețea externă în avans, iar la momentul implementării va trebui doar să asociem adrese externe cu mașinile client.
Și aici NAT ne vine în ajutor - doar vom face posibil ca clienții să acceseze lumea exterioară prin spațiul de nume implicit folosind traducerea NAT. Ei bine, aici este o mică problemă. Acest lucru este bun dacă serverul client acționează ca un client și nu ca un server - adică, inițiază mai degrabă decât acceptă conexiuni. Dar pentru noi va fi invers. În acest caz, trebuie să facem NAT de destinație, astfel încât atunci când primește trafic, nodul de control să înțeleagă că acest trafic este destinat mașinii virtuale A a clientului A, ceea ce înseamnă că trebuie să facem o traducere NAT de la o adresă externă, de exemplu 100.1.1.1. .10.0.0.1, la o adresă internă 100. În acest caz, deși toți clienții vor folosi aceeași rețea, izolarea internă este complet păstrată. Adică trebuie să facem dNAT și sNAT pe nodul de control. Dacă folosiți o singură rețea cu adrese 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 în diagramă, ci vom lăsa rețelele externe deja adăugate mai devreme - fiecare client are propria sa rețea externă (în diagramă sunt indicate ca vlan 200 și XNUMX pe interfața externă).
Drept urmare, am primit o soluție interesantă și în același timp bine gândită, care are o anumită flexibilitate dar nu are încă mecanisme de toleranță la erori.
În primul rând, avem un singur nod de control - eșecul acestuia va duce la prăbușirea tuturor sistemelor. Pentru a remedia această problemă, trebuie să faceți cel puțin un cvorum de 3 noduri. Să adăugăm asta la diagramă:
Desigur, toate nodurile sunt sincronizate și când un nod activ pleacă, un alt nod își va prelua responsabilitățile.
Următoarea problemă este discurile mașinilor virtuale. În momentul de față, acestea sunt stocate pe hipervizoarele înșiși, iar în cazul unor probleme cu hipervizorul, pierdem toate datele - iar prezența unui raid nu va ajuta aici dacă pierdem nu discul, ci întregul server. Pentru a face acest lucru, trebuie să facem un serviciu care să acționeze ca front-end pentru un fel de stocare. Ce fel de stocare va fi nu este deosebit de important pentru noi, dar ar trebui să ne protejeze datele de defecțiunea atât a discului, cât și a nodului și, eventual, a întregului cabinet. Există mai multe opțiuni aici - există, desigur, rețele SAN cu Fibre Channel, dar să fim sinceri - FC este deja o relicvă a trecutului - un analog al E1 în transport - da, sunt de acord, este încă folosit, dar doar acolo unde este absolut imposibil fără ea. Prin urmare, nu aș implementa voluntar o rețea FC în 2020, știind că există și alte alternative mai interesante. Deși pentru fiecare a lui, ar putea exista cei care cred că FC, cu toate limitările sale, este tot ce avem nevoie - nu voi argumenta, fiecare are propria părere. Cu toate acestea, cea mai interesantă soluție, după părerea mea, este utilizarea unui SDS, precum Ceph.
Ceph vă permite să construiți o soluție de stocare a datelor cu o mare disponibilitate, cu o mulțime de opțiuni posibile de backup, începând cu codurile cu verificarea parității (analog cu raid 5 sau 6) terminând cu replicarea completă a datelor pe diferite discuri, ținând cont de locația discurilor în servere și servere în dulapuri etc.
Pentru a construi Ceph aveți nevoie de încă 3 noduri. Interacțiunea cu stocarea se va realiza și prin intermediul rețelei folosind servicii de stocare bloc, obiecte și fișiere. Să adăugăm spațiu de stocare la schemă:
Notă: puteți realiza și noduri de calcul hiperconvergente - acesta este conceptul de a combina mai multe funcții pe un singur nod - de exemplu, stocare+calculare - fără a dedica noduri speciale pentru stocarea ceph. Vom obține aceeași schemă tolerantă la erori - deoarece SDS va rezerva datele cu nivelul de rezervare pe care l-am specificat. Cu toate acestea, nodurile hiperconvergente sunt întotdeauna un compromis - deoarece nodul de stocare nu doar încălzește aerul așa cum pare la prima vedere (din moment ce nu există mașini virtuale pe el) - cheltuiește resursele CPU pentru deservirea SDS (de fapt, face totul replicarea și recuperarea după defecțiuni ale nodurilor, discurilor etc.). Adică, veți pierde o parte din puterea nodului de calcul dacă îl combinați cu stocarea.
Toate aceste lucruri trebuie gestionate cumva - avem nevoie de ceva prin care să putem crea o mașină, o rețea, un router virtual etc. Pentru a face acest lucru, vom adăuga un serviciu la nodul de control care va acționa ca un tablou de bord - clientul va putea să se conecteze la acest portal prin http/ https și să facă tot ce are nevoie (bine, aproape).
Drept urmare, avem acum un sistem tolerant la erori. Toate elementele acestei infrastructuri trebuie gestionate cumva. S-a descris anterior că Openstack este un set de proiecte, fiecare dintre acestea oferind o funcție specifică. După cum vedem, există mai mult decât suficiente elemente care trebuie configurate și controlate. Astăzi vom vorbi despre partea de rețea.
Arhitectura neutronilor
În OpenStack, Neutron este responsabil pentru conectarea porturilor mașinilor virtuale la o rețea comună L2, asigurând rutarea traficului între mașinile virtuale situate pe diferite rețele L2, precum și rutarea către exterior, oferind servicii precum NAT, Floating IP, DHCP etc.
La un nivel înalt, funcționarea serviciului de rețea (partea de bază) poate fi descrisă după cum urmează.
La pornirea VM-ului, serviciul de rețea:
- Creează un port pentru un anumit VM (sau porturi) și notifică serviciul DHCP despre acesta;
- Este creat un nou dispozitiv de rețea virtuală (prin libvirt);
- VM se conectează la porturile create la pasul 1;
Destul de ciudat, munca lui Neutron se bazează pe mecanisme standard familiare tuturor celor care s-au scufundat vreodată în Linux - spații de nume, iptables, poduri Linux, openvswitch, conntrack etc.
Ar trebui clarificat imediat că Neutron nu este un controler SDN.
Neutronul este format din mai multe componente interconectate:
Openstack-neutron-server este un demon care funcționează cu solicitările utilizatorilor prin intermediul API-ului. Acest demon nu este implicat în înregistrarea niciunei conexiuni de rețea, dar oferă informațiile necesare pentru aceasta pluginurilor sale, care apoi configurează elementul de rețea dorit. Agenții neutroni de pe nodurile OpenStack se înregistrează pe serverul Neutron.
Neutron-server este de fapt o aplicație scrisă în python, constând din două părți:
- Serviciul REST
- Plugin Neutron (nucleu/serviciu)
Serviciul REST este conceput pentru a primi apeluri API de la alte componente (de exemplu, o solicitare de furnizare a unor informații etc.)
Pluginurile sunt componente/module software plug-in care sunt apelate în timpul solicitărilor API - adică atribuirea unui serviciu are loc prin intermediul acestora. Pluginurile sunt împărțite în două tipuri - service și root. De regulă, pluginul Horse este responsabil în principal de gestionarea spațiului de adrese și a conexiunilor L2 dintre VM, iar pluginurile de servicii oferă deja funcționalități suplimentare, cum ar fi VPN sau FW.
Lista pluginurilor disponibile astăzi poate fi vizualizată, de exemplu
Pot exista mai multe plugin-uri de serviciu, dar poate exista doar un singur plugin-uri.
openstack-neutron-ml2 este pluginul standard de rădăcină Openstack. Acest plugin are o arhitectură modulară (spre deosebire de predecesorul său) și configurează serviciul de rețea prin drivere conectate la acesta. Ne vom uita la plugin-ul în sine puțin mai târziu, deoarece de fapt oferă flexibilitatea pe care OpenStack o are în partea de rețea. Pluginul rădăcină poate fi înlocuit (de exemplu, Contrail Networking face o astfel de înlocuire).
Serviciu RPC (rabbitmq-server) — un serviciu care asigură gestionarea cozilor și interacțiunea cu alte servicii OpenStack, precum și interacțiunea între agenții de servicii de rețea.
Agenți de rețea — agenți care se află în fiecare nod, prin care sunt configurate serviciile de rețea.
Există mai multe tipuri de agenți.
Agentul principal este agent L2. Acești agenți rulează pe fiecare dintre hipervizoare, inclusiv nodurile de control (mai precis, pe toate nodurile care oferă orice serviciu pentru chiriași) și funcția lor principală este de a conecta mașinile virtuale la o rețea L2 comună și, de asemenea, de a genera alerte atunci când apar evenimente ( de exemplu dezactivați/activați portul).
Următorul agent, nu mai puțin important este agent L3. În mod implicit, acest agent rulează exclusiv pe un nod de rețea (adesea nodul de rețea este combinat cu un nod de control) și oferă rutare între rețelele de chiriași (atât între rețelele sale, cât și rețelele altor chiriași și este accesibil lumii exterioare, oferind NAT, precum și serviciul DHCP). Cu toate acestea, atunci când utilizați un DVR (router distribuit), necesitatea unui plugin L3 apare și pe nodurile de calcul.
Agentul L3 utilizează spații de nume Linux pentru a oferi fiecărui chiriaș un set de propriile rețele izolate și funcționalitatea routerelor virtuale care direcționează traficul și oferă servicii de gateway pentru rețelele de nivel 2.
Baza de date — o bază de date cu identificatori de rețele, subrețele, porturi, pool-uri etc.
De fapt, Neutron acceptă solicitări API de la crearea oricăror entități de rețea, autentifică cererea și prin RPC (dacă accesează vreun plugin sau agent) sau API REST (dacă comunică în SDN) transmite agenților (prin pluginuri) instructiuni necesare organizarii serviciului solicitat .
Acum să trecem la instalarea de testare (cum este implementată și ce este inclus în ea, vom vedea mai târziu în partea practică) și să vedem unde se află fiecare componentă:
(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 ~]$
De fapt, asta este întreaga structură a Neutronului. Acum merită să petreceți ceva timp pe pluginul ML2.
Stratul modular 2
După cum am menționat mai sus, pluginul este un plugin rădăcină standard OpenStack și are o arhitectură modulară.
Predecesorul pluginului ML2 avea o structură monolitică, care nu permitea, de exemplu, utilizarea unui amestec de mai multe tehnologii într-o singură instalație. De exemplu, nu ați putea folosi atât openvswitch, cât și linuxbridge în același timp - nici primul, nici al doilea. Din acest motiv, a fost creat pluginul ML2 cu arhitectura sa.
ML2 are două componente - două tipuri de drivere: drivere de tip și drivere de mecanism.
Tip drivere determinați tehnologiile care vor fi utilizate pentru organizarea conexiunilor de rețea, de exemplu VxLAN, VLAN, GRE. În același timp, șoferul permite utilizarea diferitelor tehnologii. Tehnologia standard este încapsularea VxLAN pentru rețelele suprapuse și rețelele externe vlan.
Driverele de tip includ următoarele tipuri de rețea:
Plat - rețea fără etichetare
VLAN - rețea etichetată
Local — un tip special de rețea pentru instalații all-in-one (astfel de instalații sunt necesare fie pentru dezvoltatori, fie pentru instruire)
GRE — suprapunerea rețelei folosind tuneluri GRE
VxLAN — suprapunerea rețelei folosind tuneluri VxLAN
Drivere de mecanism definiți instrumente care asigură organizarea tehnologiilor specificate în driverul de tip - de exemplu, openvswitch, sr-iov, opendaylight, OVN etc.
În funcție de implementarea acestui driver, se vor folosi fie agenți controlați de Neutron, fie se vor folosi conexiuni la un controler SDN extern, care se ocupă de toate problemele legate de organizarea rețelelor L2, rutare etc.
Exemplu: dacă folosim ML2 împreună cu OVS, atunci este instalat un agent L2 pe fiecare nod de calcul care gestionează OVS. Totuși, dacă folosim, de exemplu, OVN sau OpenDayLight, atunci controlul OVS intră în jurisdicția lor - Neutron, prin plugin-ul root, dă comenzi controlerului și face deja ceea ce i s-a spus.
Să perfecționăm Open vSwitch
În prezent, una dintre componentele cheie ale OpenStack este Open vSwitch.
Când instalați OpenStack fără niciun SDN suplimentar de furnizor, cum ar fi Juniper Contrail sau Nokia Nuage, OVS este componenta principală de rețea a rețelei cloud și, împreună cu iptables, conntrack, spații de nume, vă permite să organizați rețele de suprapunere cu mai multe locații cu drepturi depline. Desigur, această componentă poate fi înlocuită, de exemplu, atunci când se utilizează soluții SDN proprietare (furnizor) terță parte.
OVS este un comutator software cu sursă deschisă care este conceput pentru a fi utilizat în medii virtualizate ca redirecționare de trafic virtual.
În acest moment, OVS are o funcționalitate foarte decentă, care include tehnologii precum QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK etc.
Notă: OVS nu a fost conceput inițial ca un comutator soft pentru funcții de telecomunicații foarte încărcate și a fost proiectat mai mult pentru funcții IT care necesită lățime de bandă mai puțin, cum ar fi serverul WEB sau serverul de e-mail. Cu toate acestea, OVS este în curs de dezvoltare și implementările actuale ale OVS și-au îmbunătățit considerabil performanța și capacitățile, ceea ce îi permite să fie utilizat de operatorii de telecomunicații cu funcții foarte încărcate, de exemplu, există o implementare OVS cu suport pentru accelerarea DPDK.
Există trei componente importante ale OVS de care trebuie să fii conștient:
- Modul kernel — o componentă situată în spațiul kernel care procesează traficul pe baza regulilor primite de la elementul de control;
- vSwitch daemon (ovs-vswitchd) este un proces lansat în spațiul utilizatorului care este responsabil pentru programarea modulului kernel - adică reprezintă direct logica funcționării comutatorului
- Server de baze de date - o bază de date locală situată pe fiecare gazdă care rulează OVS, în care este stocată configurația. Controlerele SDN pot comunica prin acest modul folosind protocolul OVSDB.
Toate acestea sunt însoțite de un set de utilități de diagnostic și management, precum ovs-vsctl, ovs-appctl, ovs-ofctl etc.
În prezent, Openstack este utilizat pe scară largă de operatorii de telecomunicații pentru a migra funcții de rețea către acesta, cum ar fi EPC, SBC, HLR etc. Unele funcții pot funcționa fără probleme cu OVS așa cum este, dar, de exemplu, EPC procesează traficul de abonați - apoi trece prin o cantitate uriașă de trafic (acum volumele de trafic ajung la câteva sute de gigabiți pe secundă). Desigur, conducerea unui astfel de trafic prin spațiul kernel (deoarece forwarder-ul este localizat în mod implicit acolo) nu este cea mai bună idee. Prin urmare, OVS este adesea implementat în întregime în spațiul utilizatorului folosind tehnologia de accelerare DPDK pentru a redirecționa traficul de la NIC la spațiul utilizator, ocolind nucleul.
Notă: pentru un cloud implementat pentru funcții de telecomunicații, este posibil să ieșiți trafic de la un nod de calcul ocolind OVS direct către echipamentul de comutare. În acest scop sunt utilizate mecanisme SR-IOV și Passthrough.
Cum funcționează acest lucru pe un aspect real?
Ei bine, acum să trecem la partea practică și să vedem cum funcționează totul în practică.
Mai întâi, să implementăm o instalare simplă Openstack. Deoarece nu am un set de servere la îndemână pentru experimente, vom asambla prototipul pe un server fizic de pe mașini virtuale. Da, firește, o astfel de soluție nu este potrivită pentru scopuri comerciale, dar pentru a vedea un exemplu de funcționare a rețelei în Openstack, o astfel de instalare este suficientă pentru ochi. Mai mult, o astfel de instalație este și mai interesantă în scopuri de antrenament - deoarece puteți prinde trafic etc.
Deoarece trebuie să vedem doar partea de bază, nu putem folosi mai multe rețele, ci putem ridica totul folosind doar două rețele, iar a doua rețea din acest aspect va fi folosită exclusiv pentru accesul la subcloud și la serverul DNS. Nu vom atinge rețelele externe deocamdată - acesta este un subiect pentru un articol mare separat.
Deci, să începem în ordine. În primul rând, o mică teorie. Vom instala Openstack folosind TripleO (Openstack pe Openstack). Esența TripleO este că instalăm Openstack all-in-one (adică pe un singur nod), numit undercloud, și apoi folosim capacitățile Openstack-ului implementat pentru a instala Openstack destinat funcționării, numit overcloud. Undercloud își va folosi capacitatea inerentă de a gestiona servere fizice (bare metal) - proiectul Ironic - pentru a furniza hipervizoare care vor îndeplini rolurile de calcul, control, noduri de stocare. Adică, nu folosim instrumente terțe pentru a implementa Openstack - implementăm Openstack folosind Openstack. Va deveni mult mai clar pe măsură ce instalarea progresează, așa că nu ne vom opri aici și nu vom merge mai departe.
Notă: În acest articol, de dragul simplității, nu am folosit izolarea rețelei pentru rețelele interne Openstack, dar totul este implementat folosind o singură rețea. Cu toate acestea, prezența sau absența izolării rețelei nu afectează funcționalitatea de bază a soluției - totul va funcționa exact la fel ca atunci când se folosește izolarea, dar traficul va circula pe aceeași rețea. Pentru o instalație comercială, este în mod natural necesar să folosiți izolarea folosind diferite vlan-uri și interfețe. De exemplu, traficul de gestionare a stocării ceph și traficul de date în sine (accesul mașinii la discuri etc.) atunci când este izolat, utilizează subrețele diferite (managementul stocării și stocarea) și acest lucru vă permite să faceți soluția mai tolerantă la erori prin împărțirea acestui trafic, de exemplu , prin diferite porturi sau folosind diferite profiluri QoS pentru trafic diferit, astfel încât traficul de date să nu comprima traficul de semnalizare. În cazul nostru, vor merge pe aceeași rețea și de fapt acest lucru nu ne limitează în niciun fel.
Notă: Deoarece vom rula mașini virtuale într-un mediu virtual bazat pe mașini virtuale, mai întâi trebuie să activăm virtualizarea imbricată.
Puteți verifica dacă virtualizarea imbricată este activată sau nu astfel:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Dacă vedeți litera N, atunci activăm suportul pentru virtualizarea imbricată conform oricărui ghid pe care îl găsiți în rețea, de exemplu .
Trebuie să asamblam următorul circuit din mașinile virtuale:
În cazul meu, pentru a conecta mașinile virtuale care fac parte din viitoarea instalare (și am primit 7 dintre ele, dar te poți descurca cu 4 dacă nu ai multe resurse), am folosit OpenvSwitch. Am creat o punte ovs și am conectat mașini virtuale la el prin grupuri de porturi. Pentru a face acest lucru, am creat un fișier xml ca acesta:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Aici sunt declarate trei grupuri de porturi - două de acces și un trunk (cel din urmă era necesar pentru serverul DNS, dar puteți face fără el sau îl puteți instala pe mașina gazdă - oricare este mai convenabil pentru dvs.). Apoi, folosind acest șablon, îl declarăm pe al nostru prin virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Acum edităm configurațiile portului hypervisor:
[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 accesibilă deoarece nu are o etichetă vlan. Pentru a remedia acest lucru, trebuie să lansați comanda sudo ovs-vsctl set port ovs-br1 tag=100. Cu toate acestea, după o repornire, această etichetă va dispărea (dacă cineva știe cum să o facă să rămână pe loc, îi voi fi foarte recunoscător). Dar acest lucru nu este atât de important, deoarece vom avea nevoie de această adresă doar în timpul instalării și nu vom avea nevoie de ea când Openstack este complet implementat.
Apoi, creăm o mașină 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 toți parametrii necesari, cum ar fi numele mașinii, parolele, utilizatorii, serverele ntp etc., puteți configura imediat porturile, dar pentru mine personal, după instalare, este mai ușor să vă autentificați în mașină prin consola și corectați fișierele necesare. Dacă aveți deja o imagine gata făcută, o puteți folosi sau face ceea ce am făcut eu - descărcați imaginea minimă Centos 7 și utilizați-o pentru a instala VM.
După instalarea cu succes, ar trebui să aveți o mașină virtuală pe care să puteți instala subcloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningMai întâi, instalați instrumentele necesare pentru procesul de instalare:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalare sub nor
Creăm un utilizator de stivă, setăm o parolă, o adăugăm la sudoer și îi dăm posibilitatea de a executa comenzi root prin sudo fără a fi nevoie să introduceți o parolă:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackAcum specificăm numele complet undercloud în fișierul hosts:
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 depozite și instalăm software-ul de care avem nevoie:
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 intenționați să instalați ceph, atunci nu este necesar să introduceți comenzi legate de ceph. Am folosit versiunea Queens, dar puteți folosi orice alta doriți.
Apoi, copiați fișierul de configurare undercloud în stiva de directoare de acasă a utilizatorului:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confAcum trebuie să corectăm acest fișier, ajustându-l la instalarea noastră.
Trebuie să adăugați aceste rânduri la începutul fișierului:
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 = 10Deci, să trecem prin setări:
undercloud_hostname — numele complet al serverului undercloud, trebuie să se potrivească cu intrarea de pe serverul DNS
local_ip — adresă locală sub cloud către furnizarea rețelei
network_gateway — aceeași adresă locală, care va acționa ca o poartă de acces la lumea exterioară în timpul instalării nodurilor de overcloud, coincide și cu ip local
undercloud_public_host — adresa API externă, se atribuie orice adresă liberă din rețeaua de furnizare
undercloud_admin_host adresa internă API, se atribuie orice adresă liberă din rețeaua de furnizare
undercloud_nameservers - server DNS
generate_service_certificat - această linie este foarte importantă în exemplul curent, deoarece dacă nu o setați la false, veți primi o eroare în timpul instalării, problema este descrisă pe dispozitivul de urmărire a erorilor Red Hat
interfață_locală interfață în furnizarea rețelei. Această interfață va fi reconfigurată în timpul implementării undercloud, așa că trebuie să aveți două interfețe pe undercloud - una pentru accesarea acesteia, a doua pentru aprovizionare
local_mtu — MTU. Deoarece avem un laborator de teste și am un MTU de 1500 pe porturile switch-ului OVS, este necesar să îl setăm la 1450, astfel încât pachetele încapsulate în VxLAN să poată trece prin
network_cidr — rețea de aprovizionare
mascaradă — utilizarea NAT pentru a accesa o rețea externă
masquerade_network - rețea care va fi NATed
dhcp_start — adresa de pornire a grupului de adrese din care adresele vor fi alocate nodurilor în timpul implementării overcloud
dhcp_end — adresa finală a grupului de adrese de la care adresele vor fi alocate nodurilor în timpul implementării overcloud
inspection_iprange — un grup de adrese necesare pentru introspecție (nu ar trebui să se suprapună cu grupul de mai sus)
scheduler_max_attempts — numărul maxim de încercări de a instala overcloud (trebuie să fie mai mare sau egal cu numărul de noduri)
După ce fișierul este descris, puteți da comanda pentru a implementa undercloud:
openstack undercloud install
Procedura durează de la 10 la 30 de minute, în funcție de fierul de călcat. În cele din urmă, ar trebui să vedeți rezultate ca aceasta:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Această ieșire spune că ați instalat cu succes undercloud și că acum puteți verifica starea undercloud și puteți continua la instalarea overcloud.
Dacă vă uitați la ieșirea ifconfig, veți vedea că a apărut o nouă interfață bridge
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Implementarea overcloud va fi acum efectuată prin această interfață.
Din rezultatul de mai jos puteți vedea că avem toate serviciile pe un singur 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 configurația părții de rețea 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 ~]$Instalare overcloud
Momentan avem doar undercloud și nu avem suficiente noduri din care să fie asamblat overcloud. Prin urmare, în primul rând, să implementăm mașinile virtuale de care avem nevoie. În timpul implementării, undercloud în sine va instala sistemul de operare și software-ul necesar pe mașina de overcloud - adică nu trebuie să implementăm complet mașina, ci doar să creăm un disc (sau discuri) pentru aceasta și să îi stabilim parametrii - adică , de fapt, obținem un server gol fără un sistem de operare instalat pe el.
Să mergem la folderul cu discurile mașinilor noastre virtuale și să creăm discuri de dimensiunea 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 160GDeoarece operăm ca root, trebuie să schimbăm proprietarul acestor discuri pentru a nu avea o problemă 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 pentru a-l studia, atunci comenzile nu creează cel puțin 3 noduri cu cel puțin două discuri, dar în șablon indică faptul că vor fi folosite discuri virtuale vda, vdb etc.
Grozav, 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 sfârșit există o comandă -print-xml > /tmp/storage-1.xml, care creează un fișier xml cu o descriere a fiecărei mașini din folderul /tmp/; dacă nu îl adăugați, nu veți fi capabil să identifice 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 o mică nuanță - 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 acestuia necesari pentru aprovizionarea ulterioară a nodurilor. Introspecția se realizează folosind ironic, un serviciu conceput pentru a funcționa cu servere bare metal.
Dar aici este problema - în timp ce serverele IPMI hardware au un port separat (sau un port partajat, dar acest lucru nu este important), atunci mașinile virtuale nu au astfel de porturi. Aici ne vine în ajutor o cârjă numită vbmc - un utilitar care vă permite să emulați un port IPMI. Această nuanță merită să acordați atenție mai ales pentru cei care doresc să înființeze un astfel de laborator pe un hipervizor ESXI - sincer să fiu, nu știu dacă are un analog de vbmc, așa că merită să vă întrebați despre această problemă înainte de a implementa totul .
Instalați vbmc:
yum install yum install python2-virtualbmcDacă sistemul de operare nu poate găsi pachetul, adăugați depozitul:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmAcum am configurat utilitarul. Totul aici este banal până la rușine. Acum este logic că nu există servere în lista vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Pentru ca acestea să apară, trebuie declarate 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ă, fără explicații. Cu toate acestea, deocamdată toate sesiunile noastre sunt în starea DOWN. Pentru ca acestea să treacă la starea SUS, trebuie să le activați:
[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 atingerea finală - trebuie să corectați regulile paravanului de protecție (sau să le dezactivați 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, să mergem la undercloud și să verificăm dacă totul funcționează. Adresa mașinii gazdă este 192.168.255.200, pe undercloud am adăugat pachetul ipmitool necesar în timpul pregătirii pentru implementare:
[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 vedea, am lansat cu succes nodul de control prin vbmc. Acum să o oprim și să mergem mai departe:
[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 va fi instalat overcloud. Pentru a face acest lucru, trebuie să pregătim un fișier json cu o descriere a nodurilor noastre. Vă rugăm să rețineți că, spre deosebire de instalarea pe serverele goale, fișierul indică portul pe care rulează vbmc pentru fiecare mașină.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Notă: nodul de control are două interfețe, dar în acest caz acest lucru nu este important, în această instalare una ne va fi suficientă.
Acum pregătim fișierul json. Trebuie să indicăm adresa poppy a portului prin care se va efectua furnizarea, parametrii nodurilor, să le dăm nume și să le indicăm cum să ajungeți la 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 imagini pentru ironic. Pentru a face acest lucru, descărcați-le prin wget și instalați:
(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ărcarea imaginilor în undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Verificați dacă toate imaginile s-au încărcat
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Încă un lucru - trebuie să adăugați un server 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
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$După cum puteți vedea din rezultat, totul s-a finalizat fără erori. Să verificăm dacă toate nodurile sunt în starea disponibilă:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Dacă nodurile sunt într-o stare diferită, de obicei gestionabilă, atunci ceva a mers prost și trebuie să vă uitați la jurnal și să vă dați seama de ce s-a întâmplat acest lucru. Rețineți că în acest scenariu folosim virtualizarea și pot exista erori asociate cu utilizarea mașinilor virtuale sau vbmc.
În continuare, trebuie să indicăm care nod va îndeplini ce funcție - adică să indicăm profilul cu care nodul va implementa:
(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 profilul 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-d9afb69d1167Să verificăm dacă 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ă, vor fi folosite în mod firesc șabloane personalizate, în cazul nostru acest lucru va complica foarte mult procesul, deoarece fiecare editare în șablon va trebui explicată. După cum am scris mai devreme, chiar și o simplă instalare va fi suficientă pentru a vedea cum funcționează.
Notă: variabila --libvirt-type qemu este necesară în acest caz, deoarece vom folosi virtualizarea imbricată. În caz contrar, nu veți putea rula mașini virtuale.
Acum aveți aproximativ o oră, sau poate mai mult (în funcție de capacitățile hardware-ului) și nu puteți decât să sperați că după acest timp veți vedea următoarea inscripție:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Acum aveți o versiune aproape completă de openstack, pe care puteți studia, experimenta etc.
Să verificăm dacă totul funcționează corect. În directorul principal al utilizatorului există două fișiere - unul stackrc (pentru gestionarea subcloudului) și al doilea overcloudrc (pentru gestionarea overcloud-ului). Aceste fișiere trebuie specificate ca sursă, deoarece conțin informații 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 ~]$Instalarea mea necesită încă o mică atingere - adăugarea unei rute pe controler, deoarece mașina cu care lucrez este într-o altă rețea. Pentru a face acest lucru, accesați control-1 sub contul heat-admin și înregistrați ruta
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Ei bine, acum poți merge la orizont. Toate informațiile - adrese, autentificare și parolă - se află în fișierul /home/stack/overcloudrc. Diagrama finală arată astfel:
Apropo, în instalația noastră, adresele mașinilor au fost emise prin DHCP și, după cum puteți vedea, sunt emise „la întâmplare”. Puteți defini strict în șablon ce adresă trebuie atașată la care mașină în timpul implementării, dacă aveți nevoie.
Cum circulă traficul între mașinile virtuale?
În acest articol ne vom uita la trei opțiuni pentru trecerea traficului
- Două mașini pe un hypervisor pe o rețea L2
- Două mașini pe hipervizoare diferite pe aceeași rețea L2
- Două mașini pe rețele diferite (înrădăcinare între rețele)
Cazurile cu acces la lumea exterioară printr-o rețea externă, folosind adrese flotante, precum și rutare distribuită, vom avea în vedere data viitoare, deocamdată ne vom concentra pe traficul intern.
Pentru a verifica, să punem cap la cap următoarea diagramă:
Am creat 4 mașini virtuale - 3 pe o rețea L2 - net-1 și încă 1 pe rețeaua net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Să vedem pe ce hipervizoare se află 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) [stiva@undercloud ~]$
Mașinile vm-1 și vm-3 sunt situate pe compute-0, mașinile vm-2 și vm-4 sunt situate pe nodul compute-1.
În plus, a fost creat un router 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 ~]$ Routerul are două porturi virtuale, care acționează ca 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 ne uita la modul în care circulă traficul, să ne uităm la ce avem în prezent pe nodul de control (care este și un nod de rețea) și pe nodul de calcul. Să începem cu nodul de calcul.
[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 ~]$În acest moment, nodul are trei poduri ovs - br-int, br-tun, br-ex. Între ele, după cum vedem, există un set de interfețe. Pentru ușurință de înțelegere, haideți să reprezentăm toate aceste interfețe pe diagramă și să vedem ce se întâmplă.
Privind adresele la care sunt ridicate tunelurile VxLAN, se poate observa că un tunel este ridicat la compute-1 (192.168.255.26), al doilea tunel caută control-1 (192.168.255.15). Dar cel mai interesant este că br-ex nu are interfețe fizice, iar dacă te uiți la ce fluxuri sunt configurate, poți vedea că acest bridge poate doar să scadă traficul în acest moment.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ După cum puteți vedea din ieșire, adresa este înșurubat direct la portul fizic, și nu la interfața de punte virtuală.
[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 ce a venit din portul phy-br-ex trebuie aruncat.
De fapt, în prezent, nu există niciun alt loc unde traficul să intre pe acest pod, cu excepția acestei interfețe (interfața cu br-int) și, judecând după picături, traficul BUM a zburat deja în pod.
Adică, traficul poate părăsi acest nod doar prin tunelul VxLAN și nimic altceva. Cu toate acestea, dacă porniți DVR-ul, situația se va schimba, dar ne vom ocupa de asta altă dată. Când utilizați izolarea rețelei, de exemplu folosind vlan-uri, veți avea nu o interfață L3 în vlan 0, ci mai multe interfețe. Cu toate acestea, traficul VxLAN va părăsi nodul în același mod, dar și încapsulat într-un fel de vlan dedicat.
Am rezolvat nodul de calcul, 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: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$De fapt, putem spune că totul este la fel, dar adresa IP nu mai este pe interfața fizică ci pe puntea virtuală. Acest lucru se face deoarece acest port este portul prin care traficul va ieși în lumea exterioară.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Acest port este legat de podul br-ex și, din moment ce nu există etichete vlan pe el, acest port este un port trunk pe care sunt permise toate vlan-urile, acum traficul iese fără etichetă, așa cum este indicat de vlan-id 0 în ieșire de mai sus.
Orice altceva în acest moment este similar cu nodul de calcul - aceleași poduri, aceleași tuneluri mergând către două noduri de calcul.
Nu vom lua în considerare nodurile de stocare în acest articol, dar pentru înțelegere este necesar să spunem că partea de rețea a acestor noduri este banală până la disgrație. În cazul nostru, există un singur port fizic (eth0) cu o adresă IP atribuită și asta este tot. Nu există tuneluri VxLAN, poduri de tunel etc. - nu există ovs deloc, deoarece nu are rost. Când se folosește izolarea rețelei, acest nod va avea două interfețe (porturi fizice, bodny sau doar două vlan-uri - nu contează - depinde ce vrei) - una pentru management, a doua pentru trafic (scriere pe discul VM). , citirea de pe disc etc.)
Ne-am dat seama ce avem pe noduri în absența oricăror servicii. Acum să lansăm 4 mașini virtuale și să vedem cum se schimbă schema descrisă mai sus - ar trebui să avem porturi, routere virtuale etc.
Până acum rețeaua noastră arată astfel:
Avem două mașini virtuale pe fiecare nod de computer. Folosind compute-0 ca exemplu, să vedem cum este inclus totul.
[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 o 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ță arată în 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 puteți vedea din ieșire, există doar două interfețe în pod - tap95d96a75-a0 și qvb95d96a75-a0.
Aici merită să ne gândim puțin la tipurile de dispozitive de rețea virtuală din OpenStack:
vtap - interfață virtuală atașată la o instanță (VM)
qbr - Linux bridge
qvb și qvo - perechea vEth conectată la bridge-ul Linux și la bridge-ul Open vSwitch
br-int, br-tun, br-vlan — Deschideți podurile vSwitch
patch-, int-br-, phy-br- - Deschideți interfețele vSwitch patch care conectează poduri
qg, qr, ha, fg, sg - Deschideți porturile vSwitch utilizate de dispozitivele virtuale pentru a se conecta la OVS
După cum înțelegeți, dacă avem un port qvb95d96a75-a0 în pod, care este o pereche vEth, atunci undeva există omologul său, care ar trebui să se numească în mod logic qvo95d96a75-a0. Să ne uităm la ce porturi sunt 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 ~]$ După cum putem vedea, portul este în br-int. Br-int acționează ca un comutator care termină porturile mașinii virtuale. Pe lângă qvo95d96a75-a0, portul qvo5bd37136-47 este vizibil în ieșire. Acesta este portul către a doua mașină virtuală. Ca rezultat, diagrama noastră arată acum astfel:
O întrebare care ar trebui să intereseze imediat cititorul atent - care este puntea linux între portul mașinii virtuale și portul OVS? Cert este că pentru a proteja mașina se folosesc grupuri de securitate, care nu sunt altceva decât iptables. OVS nu funcționează cu iptables, așa că această „cârjă” a fost inventată. Cu toate acestea, devine învechit - este înlocuit de conntrack în noile versiuni.
Adică, în cele din urmă, schema arată astfel:
Două mașini pe un hypervisor pe o rețea L2
Deoarece aceste două mașini virtuale sunt situate pe aceeași rețea L2 și pe același hypervisor, traficul dintre ele va circula în mod logic local prin br-int, deoarece ambele mașini vor fi pe 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 hipervizoare diferite pe aceeași rețea L2
Acum să vedem cum va merge traficul între două mașini din aceeași rețea L2, dar situate pe hipervizoare diferite. Sincer să fiu, nimic nu se va schimba prea mult, doar traficul dintre hipervizori va trece prin tunelul vxlan. Să ne uităm la un exemplu.
Adresele mașinilor virtuale între care vom urmări 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
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Ne uităm la tabelul de redirecționare î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ă în portul 2 - să vedem ce fel de port este:
[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 de 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 împachetat în VxLAN și trimis la 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 un tunel 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 ~]$Să mergem la compute-1 și să vedem ce se întâmplă în continuare 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 se află în tabelul de redirecționare br-int pe compute-1 și, după cum se poate vedea din rezultatul de mai sus, este vizibil prin portul 2, care este portul către 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:46Ei bine, atunci vedem că în br-int pe compute-1 există un mac 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 ~]$ Adică, pachetul primit va zbura către portul 3, în spatele căruia există deja o instanță de mașină virtuală-00000003.
Frumusețea implementării Openstack pentru învățare pe infrastructura virtuală este că putem captura cu ușurință traficul dintre hipervizori și să vedem ce se întâmplă cu acesta. Acesta este ceea ce vom face acum, rulați tcpdump pe portul vnet către compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Prima linie arată că Patek de la adresa 10.0.1.85 merge la adresa 10.0.1.88 (trafic ICMP) și este împachetat într-un pachet VxLAN cu vni 22 și pachetul trece de la gazda 192.168.255.19 (compute-0) la gazda 192.168.255.26. .1 (calculați-XNUMX). Putem verifica dacă VNI-ul se potrivește cu cel specificat în ovs.
Să revenim la această linie actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 este vni în sistemul numeric hexazecimal. Să transformăm acest număr în al 16-lea sistem:
16 = 6*16^0+1*16^1 = 6+16 = 22Adică vni corespunde realității.
A doua linie arată traficul de întoarcere, ei bine, nu are rost să-l explic, totul este clar acolo.
Două mașini pe rețele diferite (rutare inter-rețea)
Ultimul caz pentru astăzi este rutarea între rețele din cadrul unui proiect folosind un router virtual. Luăm în considerare un caz fără DVR (ne vom analiza într-un alt articol), așa că rutarea are loc pe nodul rețelei. În cazul nostru, nodul de rețea nu este plasat într-o entitate separată și este situat pe nodul de control.
Mai întâi, să vedem că rutarea funcționează:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msDeoarece în acest caz pachetul trebuie să meargă la gateway și să fie direcționat acolo, trebuie să aflăm adresa poppy a gateway-ului, pentru care ne uităm la tabelul ARP în instanță:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Acum să vedem unde ar trebui trimis traficul cu 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 merge pe br-tun. Să vedem în ce tunel vxlan va fi înfășurat:
[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 ~]$ Al treilea port 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 uită 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ă mergem la el și să vedem cum se va întâmpla rutarea.
După cum vă amintiți, nodul de control din interior arăta exact la fel ca nodul de calcul - aceleași trei poduri, doar br-ex avea un port fizic prin care nodul putea trimite trafic în exterior. Crearea instanțelor a schimbat configurația pe nodurile de calcul - linux bridge, iptables și interfețe au fost adăugate la noduri. Crearea rețelelor și a unui router virtual și-a pus amprenta și asupra configurației nodului de control.
Deci, este evident că adresa MAC a gateway-ului trebuie să fie în tabelul de redirecționare br-int de pe nodul de control. Să verificăm dacă este acolo și unde caută:
[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ă revenim la lista de porturi virtuale din Openstack, acest tip de port este folosit pentru a conecta diverse dispozitive virtuale la OVS. Pentru a fi mai precis, qr este un port către routerul virtual, care este reprezentat ca un spațiu de nume.
Să vedem ce spații de nume 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 ~]$ Cât trei exemplare. Dar judecând după nume, puteți ghici scopul fiecăruia dintre ele. Vom reveni la instanțele cu ID 0 și 1 mai târziu, acum ne interesează spațiul de nume 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 ~]$ Acest spațiu de nume conține două interne pe care le-am creat mai devreme. Ambele porturi virtuale au fost adăugate la br-int. Să verificăm adresa mac a portului qr-0c52b15f-8f, deoarece traficul, judecând după adresa mac de destinație, a mers către 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<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Adică, în acest caz, totul funcționează conform legilor de rutare standard. Deoarece traficul este destinat gazdei 10.0.2.8, acesta trebuie să iasă prin a doua interfață qr-92fa49b5-54 și să treacă prin tunelul vxlan către nodul de calcul:
[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 unde este vizibilă adresa de 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 era de așteptat, traficul se duce către br-tun, să vedem în ce tunel merge următorul trafic:
[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 intră în tunel pentru a calcula-1. Ei bine, pe compute-1 totul este simplu - de la br-tun pachetul merge la br-int și de acolo la 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ă aceasta 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 ~]$
De fapt, am trecut prin pachet. Cred că ați observat că traficul a trecut prin diferite tuneluri vxlan și a ieșit cu diferite VNI-uri. Să vedem ce fel de VNI sunt acestea, după care vom colecta un dump pe portul de control al nodului și ne vom asigura că traficul curge exact așa cum este descris mai sus.
Deci, tunelul pentru a calcula-0 are următoarele acțiuni=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Să convertim 0x16 în sistemul numeric zecimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunelul pentru a calcula-1 are următorul VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Să convertim 0x63 în sistemul numeric zecimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Ei bine, acum să ne uităm la gunoi:
[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 împachetat un pachet ICMP de la gazda 10.0.1.85 la gazda 10.0.2.8. După cum am calculat mai sus, vni se potrivește cu ceea ce am văzut în rezultat.
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 împachetat un pachet ICMP de la gazda 10.0.1.85 la gazda 10.0.2.8. După cum am calculat mai sus, vni se potrivește cu ceea ce am văzut în rezultat.
Următoarele două pachete sunt trafic de retur de la 10.0.2.8 nu de la 10.0.1.85.
Adică, în cele din urmă, am obținut următoarea schemă de noduri de control:
Arata ca asta e? Am uitat de două spații de nume:
[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 ~]$ Cum am vorbit despre arhitectura platformei cloud, ar fi bine ca mașinile să primească adrese automat de la un server DHCP. Acestea sunt două servere DHCP pentru cele două rețele noastre 10.0.1.0/24 și 10.0.2.0/24.
Să verificăm dacă acest lucru este adevărat. Există o singură adresă în acest spațiu de nume - 10.0.1.1 - adresa serverului DHCP în sine și 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<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Să vedem dacă procesele care conțin qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 în numele lor 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 rezultatul de mai sus, putem, de exemplu, să vedem ce avem în prezent de închiriat:
[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 ~]$Ca rezultat, obținem următorul set de servicii pe nodul de control:
Ei bine, rețineți - sunt doar 4 mașini, 2 rețele interne și un router virtual... Acum nu avem rețele externe aici, o grămadă de proiecte diferite, fiecare cu propriile rețele (suprapuse), și avem un router distribuit a fost oprit și, în cele din urmă, a existat un singur nod de control în bancul de testare (pentru toleranța la erori trebuie 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 - dacă aveți 3 sau 300 de spații de nume este desigur important, dar din punctul de vedere al funcționării întregului structura, nimic nu se va schimba prea mult... deși până când nu veți conecta un SDN de la furnizor. Dar asta este o cu totul altă poveste.
Sper că a fost interesant. Dacă aveți comentarii/adăugiri, sau undeva am mințit de-a dreptul (sunt om și părerea mea va fi întotdeauna subiectivă) - scrieți ce trebuie corectat/adăugat - vom corecta/adăugăm totul.
În concluzie, aș dori să spun câteva cuvinte despre compararea Openstack (atât vanilia cât și furnizorul) cu soluția cloud de la VMWare - mi s-a pus această întrebare prea des în ultimii doi ani și, sincer vorbind, sunt deja obosit de asta, dar totuși. În opinia mea, este foarte dificil să compari aceste două soluții, dar putem spune cu siguranță că există dezavantaje în ambele soluții și atunci când alegi o singură soluție trebuie să cântărești argumentele pro și contra.
Dacă OpenStack este o soluție bazată pe comunitate, atunci VMWare are dreptul să facă doar ceea ce dorește (citește - ce este profitabil pentru el) și acest lucru este logic - pentru că este o companie comercială obișnuită să facă bani de la clienții săi. Dar există unul mare și gras DAR - puteți renunța la OpenStack, de exemplu de la Nokia, și cu cheltuieli mici să treceți la o soluție de la, de exemplu, Juniper (Contrail Cloud), dar este puțin probabil să puteți renunța la VMWare . Pentru mine, aceste două soluții arată așa - Openstack (vânzător) este o simplă cușcă în care ești băgat, dar ai o cheie și poți pleca oricând. VMWare este o cușcă de aur, proprietarul are cheia cuștii și te va costa foarte mult.
Nu promovez nici primul produs, nici al doilea - tu alegi ceea ce ai nevoie. Dar dacă aș avea o astfel de alegere, aș alege ambele soluții - VMWare pentru cloud IT (încărcări reduse, management ușor), OpenStack de la un furnizor (Nokia și Juniper oferă soluții la cheie foarte bune) - pentru cloud Telecom. Nu aș folosi Openstack pentru IT pur - este ca și cum ați împușca vrăbii cu un tun, dar nu văd nicio contraindicație pentru utilizare, în afară de redundanță. Cu toate acestea, utilizarea VMWare în telecomunicații este ca și cum a transporta piatră zdrobită într-un Ford Raptor - este frumos din exterior, dar șoferul trebuie să facă 10 călătorii în loc de una.
În opinia mea, cel mai mare dezavantaj al VMWare este închiderea sa completă - compania nu vă va oferi nicio informație despre cum funcționează, de exemplu, vSAN sau ce este în nucleul hypervisor - pur și simplu nu este profitabil pentru el - adică veți nu devii niciodată un expert în VMWare - fără suport de furnizor, ești condamnat (de foarte multe ori mă întâlnesc cu experți VMWare care sunt derutați de întrebări banale). Pentru mine, VMWare cumpără o mașină cu capota blocată - da, poate ai specialiști care pot schimba cureaua de distribuție, dar numai cel care ți-a vândut această soluție poate deschide capota. Personal, nu-mi plac soluțiile în care nu mă pot încadra. Vei spune că s-ar putea să nu fii nevoit să mergi sub capotă. Da, acest lucru este posibil, dar mă voi uita la tine când trebuie să asamblați o funcție mare în cloud de la 20-30 de mașini virtuale, 40-50 de rețele, dintre care jumătate vor să iasă afară, iar a doua jumătate vă cere Accelerație SR-IOV, altfel veți avea nevoie de mai multe câteva zeci de aceste mașini - altfel performanța nu va fi suficientă.
Există și alte puncte de vedere, așa că doar tu poți decide ce să alegi și, cel mai important, vei fi apoi responsabil pentru alegerea ta. Aceasta este doar părerea mea - o persoană care a văzut și a atins cel puțin 4 produse - Nokia, Juniper, Red Hat și VMWare. Adică am cu ce să compar.
Sursa: www.habr.com