Računalstvo u oblaku prodire sve dublje u naše živote i vjerojatno ne postoji niti jedna osoba koja barem jednom nije koristila neku uslugu u oblaku. No, što je točno oblak i kako funkcionira malo tko zna, čak i na razini ideje. 5G već postaje stvarnost i telekom infrastruktura počinje prelaziti s rješenja stupova na rješenja u oblaku, baš kao što je to učinila kada se s potpuno hardverskih rješenja preselila na virtualizirane "stupove".
Danas ćemo govoriti o unutarnjem svijetu infrastrukture oblaka, posebno ćemo se osvrnuti na osnove mrežnog dijela.
Što je oblak? Ista virtualizacija - prikaz profila?
Više nego logično pitanje. Ne - ovo nije virtualizacija, iako se bez nje ne bi moglo. Pogledajmo dvije definicije:
Cloud computing (u daljnjem tekstu Cloud) je model za pružanje jednostavnog pristupa distribuiranim računalnim resursima koji se moraju implementirati i pokrenuti na zahtjev uz najmanju moguću latenciju i minimalne troškove za pružatelja usluga.
Virtualizacija - to je mogućnost da jednu fizičku cjelinu (npr. server) podijelite na više virtualnih i time povećate iskoristivost resursa (npr. imali ste 3 servera opterećena 25-30 posto, nakon virtualizacije dobijete 1 server opterećen na 80-90 posto). Naravno, virtualizacija jede dio resursa - trebate hraniti hipervizor, ali, kako je praksa pokazala, igra je vrijedna svijeća. Idealan primjer virtualizacije je VMWare koji savršeno priprema virtualne strojeve ili npr. KVM koji mi je draži, ali to je stvar ukusa.
Koristimo virtualizaciju, a da toga nismo svjesni, a čak i željezni usmjerivači već koriste virtualizaciju - na primjer, u najnovijoj verziji JunOS-a, operativni sustav instaliran je kao virtualni stroj na vrhu Linux distribucije u stvarnom vremenu (Wind River 9). Ali virtualizacija nije oblak, ali oblak ne može postojati bez virtualizacije.
Virtualizacija je jedan od gradivnih blokova na kojima je izgrađen oblak.
Izrada oblaka jednostavnim prikupljanjem nekoliko hipervizora u jednu L2 domenu, dodavanjem nekoliko yaml playbook-ova za automatsku registraciju vlan-ova kroz neku vrstu ansibla i ometanje nečega poput sustava orkestracije na sve to za automatsko stvaranje virtualnih strojeva neće funkcionirati. Bit će točnije, ali rezultirajući Frankenstein nije oblak koji trebamo, iako bi drugima mogao biti ultimativni san. Štoviše, ako uzmete isti Openstack, to je u biti i dalje Frankenstein, ali dobro, nemojmo o tome za sada.
Ali razumijem da iz gornje definicije nije sasvim jasno što se zapravo može nazvati oblakom.
Stoga dokument NIST-a (National Institute of Standards and Technology) daje 5 glavnih karakteristika koje bi infrastruktura u oblaku trebala imati:
Pružanje usluga na zahtjev. Korisniku se mora omogućiti slobodan pristup računalnim resursima koji su mu dodijeljeni (kao što su mreže, virtualni diskovi, memorija, procesorske jezgre itd.), a ti resursi moraju biti osigurani automatski – dakle, bez intervencije davatelja usluge.
Široka dostupnost usluge. Pristup resursima mora biti osiguran standardnim mehanizmima kako bi se omogućilo korištenje standardnih računala i tankih klijenata i mobilnih uređaja.
Kombiniranje resursa u skupove. Skupovi resursa moraju biti u mogućnosti pružiti resurse većem broju klijenata u isto vrijeme, osiguravajući da su klijenti izolirani i oslobođeni međusobnog utjecaja i natjecanja za resurse. Mreže su također uključene u bazene, što ukazuje na mogućnost korištenja preklapajućeg adresiranja. Skupovi moraju imati mogućnost skaliranja na zahtjev. Korištenjem skupova moguće je osigurati potrebnu razinu tolerancije grešaka resursa i apstrakciju fizičkih i virtualnih resursa – primatelju usluge jednostavno se daje skup resursa koje je on tražio (gdje se ti resursi fizički nalaze, na koliko poslužitelji i preklopnici – nije bitno klijentu). Međutim, moramo uzeti u obzir činjenicu da pružatelj usluga mora osigurati transparentno rezerviranje ovih resursa.
Brza prilagodba različitim uvjetima. Usluge moraju biti fleksibilne - brzo osiguravanje resursa, njihova redistribucija, dodavanje ili smanjivanje resursa na zahtjev klijenta, a kod klijenta treba postojati osjećaj da su resursi oblaka beskonačni. Radi lakšeg razumijevanja, na primjer, ne vidite upozorenje da je dio vašeg prostora na disku u Apple iCloudu nestao jer se tvrdi disk na poslužitelju pokvario, a pogoni se kvare. Osim toga, s vaše strane, mogućnosti ove usluge su gotovo neograničene - potrebno vam je 2 TB - nema problema, platili ste i dobili. Sličan primjer može se dati s Google.Drive ili Yandex.Disk.
Mogućnost mjerenja pružene usluge. Cloud sustavi moraju automatski kontrolirati i optimizirati potrošene resurse, a ti mehanizmi moraju biti transparentni i korisniku i pružatelju usluge. Odnosno, uvijek možete provjeriti koliko resursa trošite vi i vaši klijenti.
Vrijedno je uzeti u obzir činjenicu da su ovi zahtjevi uglavnom zahtjevi za javni oblak, pa se za privatni oblak (odnosno oblak pokrenut za interne potrebe tvrtke) ovi zahtjevi mogu malo prilagoditi. Međutim, oni se još uvijek moraju učiniti, inače nećemo dobiti sve prednosti računalstva u oblaku.
Zašto nam treba oblak?
Međutim, svaka nova ili postojeća tehnologija, svaki novi protokol stvoren je za nešto (dobro, osim za RIP-ng, naravno). Nitko ne treba protokol radi protokola (dobro, osim RIP-nga, naravno). Logično je da je Cloud stvoren da pruži neku vrstu usluge korisniku/klijentu. Svima nam je poznato barem nekoliko usluga u oblaku, na primjer Dropbox ili Google.Docs, i vjerujem da ih većina ljudi uspješno koristi – primjerice, ovaj članak je napisan pomoću usluge u oblaku Google.Docs. Ali usluge u oblaku koje poznajemo samo su dio mogućnosti oblaka – točnije, samo su usluge tipa SaaS. Uslugu u oblaku možemo pružiti na tri načina: u obliku SaaS, PaaS ili IaaS. Koja Vam je usluga potrebna ovisi o Vašim željama i mogućnostima.
Pogledajmo svaki redom:
Softver kao usluga (SaaS) je model za pružanje potpune usluge klijentu, na primjer, usluge e-pošte kao što su Yandex.Mail ili Gmail. U ovom modelu pružanja usluga, vi kao klijent zapravo ne radite ništa osim što koristite usluge – odnosno ne morate razmišljati o postavljanju usluge, njenoj toleranciji na pogreške ili redundanciji. Najvažnije je ne kompromitirati svoju lozinku; pružatelj ove usluge učinit će ostalo za vas. Sa stajališta pružatelja usluga, on je u potpunosti odgovoran za cjelokupnu uslugu - od poslužiteljskog hardvera i host operativnih sustava do postavki baze podataka i softvera.
Platforma kao usluga (PaaS) — kada se koristi ovaj model, pružatelj usluge klijentu daje radni komad za uslugu, na primjer, uzmimo web poslužitelj. Davatelj usluge je klijentu osigurao virtualni poslužitelj (zapravo, skup resursa, kao što je RAM/CPU/Storage/Nets, itd.), čak je instalirao OS i potreban softver na ovaj poslužitelj, međutim, konfiguracija Sve to radi sam klijent, a za izvršenje usluge odgovara klijent. Davatelj usluge je, kao i u prethodnom slučaju, odgovoran za performanse fizičke opreme, hipervizora, samog virtualnog stroja, njegovu mrežnu dostupnost itd., ali sama usluga više nije u njegovom području odgovornosti.
Infrastruktura kao usluga (IaaS) - ovaj pristup je već zanimljiviji, zapravo, pružatelj usluge pruža klijentu kompletnu virtualiziranu infrastrukturu - to jest, neki skup (pool) resursa, kao što su CPU jezgre, RAM, mreže itd. Sve ostalo je na klijent - što klijent želi učiniti s tim resursima unutar dodijeljenog skupa (kvote) - nije posebno važno za dobavljača. Bez obzira želi li klijent kreirati vlastiti vEPC ili čak stvoriti mini operatera i pružati komunikacijske usluge - nema sumnje - učinite to. U takvom scenariju, pružatelj usluge odgovoran je za osiguravanje resursa, njihovu toleranciju na pogreške i dostupnost, kao i operativni sustav koji omogućuje njihovo objedinjavanje i stavljanje na raspolaganje klijentu, uz mogućnost povećanja ili smanjenja resursa u bilo kojem trenutku na zahtjev klijenta. Klijent sam konfigurira sve virtualne strojeve i ostale šljokice putem samouslužnog portala i konzole, uključujući i postavljanje mreža (osim vanjskih mreža).
Što je OpenStack?
U sve tri opcije pružatelj usluge treba OS koji će omogućiti stvaranje cloud infrastrukture. Zapravo, kod SaaS-a, više od jednog odjela odgovorno je za cijeli skup tehnologija - postoji odjel koji je odgovoran za infrastrukturu - to jest, on pruža IaaS drugom odjelu, ovaj odjel pruža SaaS klijentu. OpenStack je jedan od operativnih sustava u oblaku koji vam omogućuje da prikupite hrpu preklopnika, poslužitelja i sustava za pohranu u jedan skup resursa, podijelite taj zajednički skup u podskupove (stanare) i pružite te resurse klijentima preko mreže.
OpenStack je operativni sustav u oblaku koji vam omogućuje kontrolu velikih skupova računalnih resursa, pohranu podataka i mrežnih resursa, osiguranih i upravljanih putem API-ja koristeći standardne mehanizme provjere autentičnosti.
Drugim riječima, ovo je skup projekata besplatnog softvera koji je dizajniran za stvaranje usluga u oblaku (javnih i privatnih) - to jest, skup alata koji vam omogućuju kombiniranje poslužiteljske i preklopne opreme u jedan skup resursa, upravljanje te resurse, pružajući potrebnu razinu tolerancije na greške.
U vrijeme pisanja ovog materijala, OpenStack struktura izgleda ovako:
Slika preuzeta iz
Svaka od komponenti uključenih u OpenStack obavlja određenu funkciju. Ova distribuirana arhitektura omogućuje vam da u rješenje uključite skup funkcionalnih komponenti koje su vam potrebne. Međutim, neke komponente su korijenske komponente i njihovo uklanjanje će dovesti do potpune ili djelomične neoperabilnosti rješenja u cjelini. Ove komponente se obično klasificiraju kao:
- Nadzorna ploča — Web-bazirano GUI za upravljanje OpenStack uslugama
- Glavni princip je centralizirana usluga identiteta koja pruža funkciju autentifikacije i autorizacije za druge usluge, kao i upravljanje korisničkim vjerodajnicama i njihovim ulogama.
- Neutron - mrežni servis koji omogućuje povezivanje sučelja različitih OpenStack servisa (uključujući povezivanje između VM-ova i njihov pristup vanjskom svijetu)
- Ugarak — omogućuje pristup blok pohrani za virtualne strojeve
- Nova — upravljanje životnim ciklusom virtualnih strojeva
- Pogled — repozitorij slika i snimaka virtualnog stroja
- Brz — omogućuje pristup objektu za pohranu
- Ceilometar — usluga koja pruža mogućnost prikupljanja telemetrije i mjerenja dostupnih i potrošenih resursa
- vrućina — orkestracija na temelju predložaka za automatsko stvaranje i osiguravanje resursa
Kompletan popis svih projekata i njihovu namjenu možete pogledati .
Svaka OpenStack komponenta je usluga koja obavlja određenu funkciju i pruža API za upravljanje tom funkcijom i interakciju s drugim uslugama operativnog sustava u oblaku za stvaranje objedinjene infrastrukture. Na primjer, Nova pruža upravljanje računalnim resursima i API za pristup konfiguraciji ovih resursa, Glance pruža upravljanje slikama i API za upravljanje njima, Cinder pruža blok pohranu i API za upravljanje njima, itd. Sve su funkcije međusobno blisko povezane.
Međutim, ako pogledate, svi servisi koji se izvode u OpenStacku u konačnici su neka vrsta virtualnog stroja (ili spremnika) spojenog na mrežu. Postavlja se pitanje - zašto nam treba toliko elemenata?
Prođimo kroz algoritam za stvaranje virtualnog stroja i njegovo povezivanje s mrežom i trajnom pohranom u Openstacku.
- Kada kreirate zahtjev za kreiranje stroja, bilo da je to zahtjev putem Horizon (Nadzorna ploča) ili zahtjev preko CLI-ja, prva stvar koja se događa je autorizacija vašeg zahtjeva na Keystoneu - možete li kreirati stroj, ima li pravo korištenja ove mreže, je li vaša kvota nacrta itd.
- Keystone autentificira vaš zahtjev i generira autentifikacijski token u poruci odgovora, koji će se dalje koristiti. Nakon što Keystone dobije odgovor, zahtjev se šalje prema Novoj (nova api).
- Nova-api provjerava valjanost vašeg zahtjeva kontaktirajući Keystone koristeći prethodno generirani autent token
- Keystone provodi autentifikaciju i pruža informacije o dozvolama i ograničenjima na temelju ovog tokena autentifikacije.
- Nova-api stvara unos za novi VM u nova-bazi podataka i prosljeđuje zahtjev za stvaranje stroja nova-scheduleru.
- Nova-scheduler odabire host (računalni čvor) na kojem će VM biti postavljen na temelju navedenih parametara, težina i zona. Zapis o tome i VM ID zapisuju se u nova-bazu podataka.
- Zatim nova-scheduler kontaktira nova-compute sa zahtjevom za implementaciju instance. Nova-compute kontaktira nova-conductor za dobivanje informacija o parametrima stroja (nova-conductor je nova element koji djeluje kao proxy poslužitelj između nova-database i nova-compute, ograničavajući broj zahtjeva za nova-database kako bi se izbjegli problemi s bazom podataka smanjenje opterećenja konzistencije).
- Nova-conductor prima tražene informacije iz nova-baze podataka i prosljeđuje ih nova-computeu.
- Zatim nova-compute poziva pogled kako bi dobio ID slike. Glace potvrđuje zahtjev u Keystoneu i vraća tražene informacije.
- Nova-compute kontaktira neutron kako bi dobio informacije o mrežnim parametrima. Slično glanceu, neutron provjerava valjanost zahtjeva u Keystoneu, nakon čega kreira unos u bazi podataka (identifikator porta itd.), kreira zahtjev za kreiranje porta i vraća tražene informacije u nova-compute.
- Nova-compute kontaktira cinder sa zahtjevom za dodjelu volumena virtualnom stroju. Slično glanceu, cider potvrđuje zahtjev u Keystoneu, stvara zahtjev za stvaranje volumena i vraća tražene informacije.
- Nova-compute kontaktira libvirt sa zahtjevom za implementaciju virtualnog stroja s navedenim parametrima.
Zapravo, naizgled jednostavna operacija stvaranja jednostavnog virtualnog stroja pretvara se u takav vrtlog API poziva između elemenata platforme u oblaku. Štoviše, kao što vidite, čak i prethodno označene usluge također se sastoje od manjih komponenti između kojih dolazi do interakcije. Stvaranje stroja samo je mali dio onoga što vam platforma u oblaku omogućuje - postoji servis odgovoran za balansiranje prometa, servis odgovoran za blok pohranu, servis odgovoran za DNS, servis odgovoran za pružanje bare metal servera itd. Oblak vam omogućuje da se prema svojim virtualnim strojevima ponašate kao prema stadu ovaca (za razliku od virtualizacije). Ako se vašem računalu nešto dogodi u virtualnom okruženju - vratite ga iz sigurnosnih kopija itd., ali aplikacije u oblaku su izgrađene na takav način da virtualni stroj ne igra tako važnu ulogu - virtualni stroj je "umro" - nema problema - jednostavno se stvara novo, vozilo se temelji na predlošku i, kako kažu, jedinica nije primijetila gubitak lovca. Naravno, to osigurava prisutnost mehanizama orkestracije - pomoću predložaka Heat možete jednostavno implementirati složenu funkciju koja se sastoji od desetaka mreža i virtualnih strojeva.
Uvijek je vrijedno imati na umu da nema infrastrukture oblaka bez mreže – svaki element na ovaj ili onaj način komunicira s drugim elementima kroz mrežu. Osim toga, oblak ima apsolutno nestatičnu mrežu. Naravno, podložna mreža je više-manje statična - novi čvorovi i preklopnici ne dodaju se svaki dan, ali preklopna komponenta se može i neizbježno će se stalno mijenjati - nove mreže će se dodavati ili brisati, novi virtualni strojevi će se pojaviti, a stari će umrijeti. I kao što se sjećate iz definicije oblaka dane na samom početku članka, resursi bi se trebali dodjeljivati korisniku automatski i uz najmanju (ili još bolje, bez) intervencije pružatelja usluga. Odnosno, vrsta pružanja mrežnih resursa koja sada postoji u obliku front-enda u obliku vašeg osobnog računa dostupnog putem http/https i dežurnog mrežnog inženjera Vasilija kao backenda nije oblak, čak ni ako Vasilij ima osam ruku.
Neutron, kao mrežna usluga, pruža API za upravljanje mrežnim dijelom infrastrukture oblaka. Usluga pokreće i upravlja mrežnim dijelom Openstacka pružajući sloj apstrakcije nazvan Network-as-a-Service (NaaS). To jest, mreža je ista virtualna mjerljiva jedinica kao, na primjer, virtualne CPU jezgre ili količina RAM-a.
Ali prije nego prijeđemo na arhitekturu mrežnog dijela OpenStacka, razmotrimo kako ova mreža funkcionira u OpenStacku i zašto je mreža važan i sastavni dio oblaka.
Dakle, imamo dva CRVENA klijentska VM-a i dva ZELENA klijentska VM-a. Pretpostavimo da su ti strojevi smješteni na dva hipervizora na ovaj način:
Ovo je trenutno samo virtualizacija 4 poslužitelja i ništa više, budući da smo do sada samo virtualizirali 4 poslužitelja, smjestivši ih na dva fizička poslužitelja. A zasad nisu ni spojeni na mrežu.
Da bismo napravili oblak, moramo dodati nekoliko komponenti. Prvo virtualiziramo mrežni dio - trebamo spojiti ta 4 stroja u paru, a klijenti žele L2 vezu. Možete koristiti prekidač i konfigurirati trunk u njegovom smjeru i riješiti sve koristeći linux bridge ili, za naprednije korisnike, openvswitch (vratit ćemo se na ovo kasnije). Ali može postojati puno mreža, a stalno guranje L2 kroz prekidač nije najbolja ideja - postoje različiti odjeli, servisni pult, mjeseci čekanja da se aplikacija završi, tjedni rješavanja problema - u modernom svijetu ovo pristup više ne funkcionira. I što prije tvrtka to shvati, lakše će ići naprijed. Stoga ćemo između hipervizora odabrati L3 mrežu preko koje će naši virtualni strojevi komunicirati, a povrh ove L3 mreže izgradit ćemo virtualne L2 prekrivne mreže gdje će teći promet naših virtualnih strojeva. Možete koristiti GRE, Geneve ili VxLAN kao enkapsulaciju. Zadržimo se za sada na potonjem, iako nije posebno važno.
Moramo negdje locirati VTEP (nadam se da su svi upoznati s VxLAN terminologijom). Budući da imamo L3 mrežu koja dolazi izravno s poslužitelja, ništa nas ne sprječava da postavimo VTEP na same poslužitelje, a OVS (OpenvSwitch) je izvrstan u tome. Kao rezultat, dobili smo ovaj dizajn:
Budući da se promet između VM-ova mora podijeliti, priključci prema virtualnim strojevima imat će različite vlan brojeve. Broj oznake igra ulogu samo unutar jednog virtualnog preklopnika, budući da kada je enkapsuliran u VxLAN možemo ga lako ukloniti, jer ćemo imati VNI.
Sada možemo kreirati naše strojeve i virtualne mreže za njih bez ikakvih problema.
Međutim, što ako klijent ima drugo računalo, ali je na drugoj mreži? Trebamo rootanje između mreža. Razmotrit ćemo jednostavnu opciju kada se koristi centralizirano usmjeravanje - to jest, promet se usmjerava kroz posebne namjenske mrežne čvorove (dobro, u pravilu se kombiniraju s kontrolnim čvorovima, pa ćemo imati istu stvar).
Čini se kao ništa komplicirano - napravimo bridge sučelje na kontrolnom čvoru, dotjeramo promet do njega i odatle ga usmjeravamo kamo treba. Ali problem je u tome što CRVENI klijent želi koristiti mrežu 10.0.0.0/24, a ZELENI klijent želi koristiti mrežu 10.0.0.0/24. To jest, počinjemo presijecati adresne prostore. Osim toga, klijenti ne žele da drugi klijenti mogu usmjeravati u njihove interne mreže, što ima smisla. Kako bismo razdvojili mrežni i podatkovni promet klijenta, svakoj od njih dodijelit ćemo zaseban prostor imena. Prostor imena je zapravo kopija mrežnog stoga Linuxa, to jest, klijenti u prostoru imena RED potpuno su izolirani od klijenata iz prostora imena GREEN (dobro, dopušteno je ili usmjeravanje između ovih mreža klijenata kroz zadani prostor imena ili na uzvodnoj transportnoj opremi).
Odnosno, dobivamo sljedeći dijagram:
L2 tuneli konvergiraju od svih računalnih čvorova do kontrolnog čvora. čvor gdje se nalazi L3 sučelje za ove mreže, svaki u namjenskom prostoru imena za izolaciju.
Međutim, zaboravili smo najvažnije. Virtualni stroj mora pružati uslugu klijentu, odnosno mora imati barem jedno vanjsko sučelje preko kojeg se do njega može doći. Odnosno, trebamo izaći u vanjski svijet. Ovdje postoje različite opcije. Učinimo najjednostavniju opciju. Svakom klijentu ćemo dodati jednu mrežu koja će biti važeća u mreži pružatelja usluga i neće se preklapati s drugim mrežama. Mreže se također mogu presijecati i gledati različite VRF-ove na strani mreže pružatelja usluga. Mrežni podaci također će živjeti u imenskom prostoru svakog klijenta. Međutim, oni će i dalje izlaziti u vanjski svijet kroz jedno fizičko (ili vezu, što je logičnije) sučelje. Kako bi se odvojio klijentski promet, promet koji ide izvana bit će označen VLAN oznakom dodijeljenom klijentu.
Kao rezultat, dobili smo ovaj dijagram:
Razumno pitanje je zašto ne napraviti pristupnike na samim računalnim čvorovima? To nije veliki problem, štoviše, ako uključite distribuirani usmjerivač (DVR), to će raditi. U ovom scenariju razmatramo najjednostavniju opciju s centraliziranim pristupnikom, koji se prema zadanim postavkama koristi u Openstacku. Za visokoopterećene funkcije koristit će i distribuirani usmjerivač i tehnologije ubrzanja kao što su SR-IOV i Passthrough, ali kako kažu, to je sasvim druga priča. Najprije ćemo se pozabaviti osnovnim dijelom, a zatim idemo u detalje.
Zapravo, naša je shema već funkcionalna, ali postoji nekoliko nijansi:
- Moramo nekako zaštititi naše strojeve, odnosno staviti filter na switch sučelje prema klijentu.
- Omogućite virtualnom stroju automatsko dobivanje IP adrese, tako da se ne morate svaki put prijavljivati na njega preko konzole i registrirati adresu.
Počnimo sa zaštitom stroja. Za ovo možete koristiti banalne iptables, zašto ne.
Odnosno, sada je naša topologija postala malo kompliciranija:
Idemo dalje. Moramo dodati DHCP poslužitelj. Najidealnije mjesto za lociranje DHCP poslužitelja za svakog klijenta bio bi gore spomenuti kontrolni čvor, gdje se nalaze prostori imena:
Međutim, postoji mali problem. Što ako se sve ponovno pokrene i sve informacije o iznajmljivanju adresa na DHCP-u nestanu. Logično je da će strojevi dobiti nove adrese, što nije baš zgodno. Ovdje postoje dva izlaza - ili koristiti imena domena i dodati DNS poslužitelj za svakog klijenta, tada nam adresa neće biti posebno važna (slično mrežnom dijelu u k8s) - ali postoji problem s vanjskim mrežama, jer adrese se u njima mogu izdavati i preko DHCP-a - potrebna vam je sinkronizacija s DNS poslužiteljima u cloud platformi i vanjskim DNS poslužiteljem, što po meni nije baš fleksibilno, ali je sasvim moguće. Ili je druga opcija korištenje metapodataka - to jest, spremanje informacija o adresi izdanoj stroju tako da DHCP poslužitelj zna koju adresu izdati stroju ako je stroj već primio adresu. Druga je opcija jednostavnija i fleksibilnija jer vam omogućuje spremanje dodatnih informacija o automobilu. Dodajmo sada metapodatke agenta u dijagram:
Drugo pitanje o kojem također vrijedi razgovarati je mogućnost korištenja jedne vanjske mreže od strane svih klijenata, budući da će vanjske mreže, ako moraju biti valjane u cijeloj mreži, biti teške - morate stalno dodjeljivati i kontrolirati dodjelu tih mreža. Mogućnost korištenja jedne vanjske unaprijed konfigurirane mreže za sve klijente bit će vrlo korisna pri stvaranju javnog oblaka. To će olakšati implementaciju strojeva jer ne moramo konzultirati bazu podataka adresa i odabrati jedinstveni adresni prostor za vanjsku mrežu svakog klijenta. Osim toga, možemo registrirati vanjsku mrežu unaprijed, au trenutku implementacije trebat ćemo samo pridružiti vanjske adrese klijentskim strojevima.
I tu nam NAT dolazi u pomoć - samo ćemo klijentima omogućiti pristup vanjskom svijetu kroz zadani imenski prostor koristeći NAT prijevod. Pa, evo malog problema. Ovo je dobro ako se klijent poslužitelj ponaša kao klijent, a ne kao poslužitelj - to jest, inicira, a ne prihvaća veze. Ali kod nas će biti obrnuto. U ovom slučaju, moramo napraviti odredišni NAT tako da kontrolni čvor prilikom primanja prometa razumije da je taj promet namijenjen virtualnom stroju A klijenta A, što znači da moramo napraviti NAT prijevod s vanjske adrese, na primjer 100.1.1.1 .10.0.0.1, na internu adresu 100. U ovom slučaju, iako će svi klijenti koristiti istu mrežu, unutarnja izolacija je u potpunosti očuvana. To jest, moramo napraviti dNAT i sNAT na kontrolnom čvoru. Hoćete li koristiti jednu mrežu s plutajućim adresama ili vanjske mreže, ili oboje odjednom, ovisi o tome što želite unijeti u oblak. Nećemo dodavati plutajuće adrese u dijagram, već ćemo ostaviti vanjske mreže koje su već dodane ranije - svaki klijent ima svoju vlastitu vanjsku mrežu (u dijagramu su označene kao vlan 200 i XNUMX na vanjskom sučelju).
Kao rezultat toga, dobili smo zanimljivo, au isto vrijeme dobro promišljeno rješenje, koje ima određenu fleksibilnost, ali još uvijek nema mehanizme tolerancije grešaka.
Prvo, imamo samo jedan kontrolni čvor - njegov kvar će dovesti do kolapsa svih sustava. Da biste riješili ovaj problem, trebate napraviti najmanje kvorum od 3 čvora. Dodajmo ovo dijagramu:
Naravno, svi čvorovi su sinkronizirani i kada aktivni čvor napusti, drugi čvor će preuzeti njegove odgovornosti.
Sljedeći problem su diskovi virtualnih strojeva. Trenutno se pohranjuju na samim hipervizorima, au slučaju problema s hipervizorom gubimo sve podatke - a prisutnost napada ovdje neće pomoći ako izgubimo ne disk, već cijeli poslužitelj. Da bismo to učinili, moramo napraviti uslugu koja će djelovati kao front end za neku vrstu pohrane. Kakva će to biti pohrana nije nam osobito važna, ali trebala bi zaštititi naše podatke od kvara i diska i noda, a možda i cijelog ormara. Ovdje postoji nekoliko opcija - postoje, naravno, SAN mreže s Fibre Channelom, ali budimo iskreni - FC je već relikt prošlosti - analog E1 u transportu - da, slažem se, još uvijek se koristi, ali samo tamo gdje se bez toga apsolutno ne može. Stoga ne bih dobrovoljno postavio FC mrežu 2020., znajući da postoje druge, zanimljivije alternative. Iako svakome svoje, možda ima onih koji vjeruju da je FC sa svim svojim ograničenjima sve što nam treba - neću raspravljati, svatko ima svoje mišljenje. Međutim, po mom mišljenju najzanimljivije rješenje je korištenje SDS-a, kao što je Ceph.
Ceph vam omogućuje da izgradite visoko dostupno rješenje za pohranu podataka s hrpom mogućih opcija sigurnosne kopije, počevši od kodova s provjerom pariteta (analogno raidu 5 ili 6) do pune replikacije podataka na različite diskove, uzimajući u obzir lokaciju diskova u poslužitelji i poslužitelji u ormarima itd.
Za izgradnju Cepha potrebna su vam još 3 čvora. Interakcija s pohranom također će se odvijati putem mreže korištenjem usluga za pohranu blokova, objekata i datoteka. Dodajmo pohranu shemi:
Napomena: također možete napraviti hiperkonvergirane računalne čvorove - ovo je koncept kombiniranja nekoliko funkcija na jednom čvoru - na primjer, pohrana+računanje - bez dodjeljivanja posebnih čvorova za ceph pohranu. Dobit ćemo istu shemu otpornu na pogreške - budući da će SDS rezervirati podatke s razinom rezervacije koju odredimo. Međutim, hiperkonvergirani čvorovi uvijek su kompromis – budući da skladišni čvor ne grije samo zrak kako se čini na prvi pogled (budući da na njemu nema virtualnih strojeva) – on troši CPU resurse na servisiranje SDS-a (zapravo radi sve replikacija i oporavak nakon kvarova čvorova, diskova itd.). Odnosno, izgubit ćete dio snage računalnog čvora ako ga kombinirate s pohranom.
Svim ovim stvarima treba nekako upravljati - trebamo nešto pomoću čega možemo stvoriti stroj, mrežu, virtualni usmjerivač itd. Da bismo to učinili, dodat ćemo uslugu u kontrolni čvor koji će djelovati kao nadzorna ploča - klijent će se preko http/ https moći spojiti na ovaj portal i raditi sve što treba (dobro, skoro).
Kao rezultat toga, sada imamo sustav otporan na greške. Svim elementima te infrastrukture mora se nekako upravljati. Prethodno je opisano da je Openstack skup projekata od kojih svaki pruža određenu funkciju. Kao što vidimo, ima više nego dovoljno elemenata koje je potrebno konfigurirati i kontrolirati. Danas ćemo govoriti o mrežnom dijelu.
Neutronska arhitektura
U OpenStacku je Neutron taj koji je odgovoran za povezivanje portova virtualnog stroja na zajedničku L2 mrežu, osiguravanje usmjeravanja prometa između VM-ova koji se nalaze na različitim L2 mrežama, kao i vanjsko usmjeravanje, pružanje usluga kao što su NAT, Floating IP, DHCP, itd.
Na visokoj razini, rad mrežne usluge (osnovni dio) može se opisati na sljedeći način.
Prilikom pokretanja VM-a, mrežna usluga:
- Stvara port za određeni VM (ili portove) i obavještava DHCP uslugu o tome;
- Stvoren je novi virtualni mrežni uređaj (putem libvirt);
- VM se spaja na priključke kreirane u koraku 1;
Čudno, Neutronov rad temelji se na standardnim mehanizmima poznatim svima koji su ikada zaronili u Linux - namespaces, iptables, linux bridges, openvswitch, conntrack, itd.
Odmah treba pojasniti da Neutron nije SDN kontroler.
Neutron se sastoji od nekoliko međusobno povezanih komponenti:
Openstack-neutron-poslužitelj je demon koji radi sa zahtjevima korisnika putem API-ja. Ovaj demon nije uključen u registraciju bilo kakvih mrežnih veza, ali daje potrebne informacije za to svojim dodacima, koji zatim konfiguriraju željeni mrežni element. Neutron agenti na OpenStack čvorovima registriraju se na Neutron poslužitelju.
Neutron-server je zapravo aplikacija napisana u pythonu, koja se sastoji od dva dijela:
- REST usluga
- Neutron dodatak (jezgra/usluga)
REST usluga dizajnirana je za primanje API poziva od drugih komponenti (na primjer, zahtjev za pružanje nekih informacija, itd.)
Dodaci su programske komponente/moduli dodataka koji se pozivaju tijekom API zahtjeva - odnosno, atribucija usluge se odvija kroz njih. Dodaci su podijeljeni u dvije vrste - servisni i root. U pravilu, konjski dodatak uglavnom je odgovoran za upravljanje adresnim prostorom i L2 vezama između VM-ova, a servisni dodaci već pružaju dodatne funkcije kao što su VPN ili FW.
Popis dodataka dostupnih danas može se pogledati na primjer
Može postojati nekoliko servisnih dodataka, ali može postojati samo jedan konjski dodatak.
openstack-neutron-ml2 je standardni Openstack root plugin. Ovaj dodatak ima modularnu arhitekturu (za razliku od svog prethodnika) i konfigurira mrežnu uslugu putem upravljačkih programa povezanih s njom. Sam plugin ćemo pogledati malo kasnije, jer on zapravo daje fleksibilnost koju OpenStack ima u mrežnom dijelu. Root plugin se može zamijeniti (na primjer, Contrail Networking radi takvu zamjenu).
RPC usluga (rabbitmq-poslužitelj) — usluga koja omogućuje upravljanje redom čekanja i interakciju s drugim OpenStack uslugama, kao i interakciju između agenata mrežnih usluga.
Mrežni agenti — agenti koji se nalaze u svakom čvoru, preko kojih se konfiguriraju mrežni servisi.
Postoji nekoliko vrsta agenata.
Glavni agent je L2 agent. Ovi agenti rade na svakom od hipervizora, uključujući kontrolne čvorove (točnije, na svim čvorovima koji pružaju bilo kakvu uslugu za stanare) i njihova glavna funkcija je povezivanje virtualnih strojeva na zajedničku L2 mrežu, te generiranje upozorenja kada se dogode bilo kakvi događaji ( na primjer onemogućiti/omogućiti port).
Sljedeći, ne manje važan agent je L3 agent. Prema zadanim postavkama, ovaj agent radi isključivo na mrežnom čvoru (često se mrežni čvor kombinira s kontrolnim čvorom) i osigurava usmjeravanje između mreža stanara (i između svojih mreža i mreža drugih stanara, te je dostupan vanjskom svijetu, pružajući NAT, kao i DHCP usluga). Međutim, kada koristite DVR (distribuirani usmjerivač), potreba za dodatkom L3 također se pojavljuje na računalnim čvorovima.
L3 agent koristi Linux imenske prostore kako bi svakom zakupcu pružio skup vlastitih izoliranih mreža i funkcionalnost virtualnih usmjerivača koji usmjeravaju promet i pružaju usluge pristupnika za Layer 2 mreže.
Baza podataka — baza podataka identifikatora mreža, podmreža, portova, skupova itd.
Zapravo, Neutron prihvaća API zahtjeve od stvaranja bilo kojeg mrežnog entiteta, provjerava autentičnost zahtjeva i putem RPC-a (ako pristupa nekom dodatku ili agentu) ili REST API-ja (ako komunicira u SDN-u) prenosi agentima (putem dodataka) upute potrebne za organizaciju tražene usluge.
Sada se okrenimo testnoj instalaciji (kako je postavljena i što je uključeno u nju, vidjet ćemo kasnije u praktičnom dijelu) i vidimo gdje se koja komponenta nalazi:
(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 ~]$
Zapravo, to je cijela struktura Neutrona. Sada vrijedi potrošiti malo vremena na ML2 dodatak.
Modularni sloj 2
Kao što je gore spomenuto, dodatak je standardni korijenski dodatak OpenStack i ima modularnu arhitekturu.
Prethodnik dodatka ML2 imao je monolitnu strukturu, koja nije dopuštala, na primjer, korištenje mješavine nekoliko tehnologija u jednoj instalaciji. Na primjer, ne možete koristiti i openvswitch i linuxbridge u isto vrijeme - ni prvi ni drugi. Iz tog razloga je kreiran ML2 plugin sa svojom arhitekturom.
ML2 ima dvije komponente - dvije vrste pokretača: upravljačke programe tipa i upravljačke programe mehanizma.
Vrsta vozača odrediti tehnologije koje će se koristiti za organiziranje mrežnih veza, na primjer VxLAN, VLAN, GRE. Istodobno, vozač omogućuje korištenje različitih tehnologija. Standardna tehnologija je VxLAN enkapsulacija za preklapajuće mreže i vlan vanjske mreže.
Tipski upravljački programi uključuju sljedeće vrste mreža:
Ravne - mreža bez označavanja
VLAN - označena mreža
lokalne — posebna vrsta mreže za sve-u-jednom instalacije (takve instalacije su potrebne ili za programere ili za obuku)
GRE — preklapanje mreže korištenjem GRE tunela
VxLAN — preklapanje mreže pomoću VxLAN tunela
Pokretači mehanizama definirati alate koji osiguravaju organizaciju tehnologija navedenih u upravljačkom programu tipa - na primjer, openvswitch, sr-iov, opendaylight, OVN, itd.
Ovisno o implementaciji ovog pokretačkog programa, koristit će se ili agenti kojima upravlja Neutron ili će se koristiti veze s vanjskim SDN kontrolerom koji se brine o svim pitanjima vezanim uz organizaciju L2 mreža, usmjeravanje itd.
Primjer: ako koristimo ML2 zajedno s OVS-om, tada se L2 agent instalira na svaki računalni čvor koji upravlja OVS-om. No, ako koristimo npr. OVN ili OpenDayLight, tada je kontrola OVS-a u njihovoj nadležnosti - Neutron preko root plugina daje naredbe kontroleru, a on već radi ono što mu se kaže.
Osvježimo Open vSwitch
U ovom trenutku jedna od ključnih komponenti OpenStacka je Open vSwitch.
Kada instalirate OpenStack bez ikakvog dodatnog SDN-a dobavljača kao što je Juniper Contrail ili Nokia Nuage, OVS je glavna mrežna komponenta mreže u oblaku i, zajedno s iptables, conntrack, imenskim prostorima, omogućuje vam organiziranje potpunih višenamjenskih preklapajućih mreža. Naravno, ova se komponenta može zamijeniti, na primjer, kada koristite vlasnička SDN rješenja treće strane (dobavljača).
OVS je softverski prekidač otvorenog koda koji je dizajniran za korištenje u virtualiziranim okruženjima kao virtualni prosljeđivač prometa.
U ovom trenutku OVS ima vrlo pristojnu funkcionalnost, koja uključuje tehnologije kao što su QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK itd.
Napomena: OVS u početku nije zamišljen kao soft switch za visoko opterećene telekom funkcije i više je dizajniran za IT funkcije koje manje zahtijevaju propusnost kao što su WEB poslužitelj ili poslužitelj pošte. Međutim, OVS se dalje razvija i trenutne implementacije OVS-a uvelike su poboljšale njegovu izvedbu i mogućnosti, što omogućuje da ga koriste telekom operateri s visoko opterećenim funkcijama, na primjer, postoji implementacija OVS-a s podrškom za DPDK akceleraciju.
Tri su važne komponente OVS-a kojih morate biti svjesni:
- Kernel modul — komponenta smještena u prostoru jezgre koja obrađuje promet na temelju pravila primljenih od kontrolnog elementa;
- vSwitch daemon (ovs-vswitchd) je proces pokrenut u korisničkom prostoru koji je odgovoran za programiranje kernel modula - odnosno izravno predstavlja logiku rada switcha
- Poslužitelj baze podataka - lokalna baza podataka koja se nalazi na svakom hostu koji pokreće OVS, u kojoj je pohranjena konfiguracija. SDN kontroleri mogu komunicirati preko ovog modula koristeći OVSDB protokol.
Sve to prati skup dijagnostičkih i upravljačkih uslužnih programa, kao što su ovs-vsctl, ovs-appctl, ovs-ofctl itd.
Trenutačno Telekom operateri naširoko koriste Openstack za migraciju mrežnih funkcija na njega, kao što su EPC, SBC, HLR, itd. Neke funkcije mogu živjeti bez problema s OVS-om kakav jest, ali na primjer, EPC obrađuje pretplatnički promet - zatim prolazi kroz ogromna količina prometa (sada količina prometa doseže nekoliko stotina gigabita u sekundi). Naravno, vožnja takvog prometa kroz prostor jezgre (budući da je prosljeđivač tamo prema zadanim postavkama) nije najbolja ideja. Stoga se OVS često postavlja u potpunosti u korisnički prostor koristeći DPDK tehnologiju ubrzanja za prosljeđivanje prometa od NIC-a do korisničkog prostora zaobilazeći kernel.
Napomena: za oblak koji se koristi za telekom funkcije, moguće je poslati promet iz računalnog čvora zaobilazeći OVS izravno na preklopnu opremu. U tu svrhu koriste se SR-IOV i Passthrough mehanizmi.
Kako ovo funkcionira na stvarnom izgledu?
E, sad prijeđimo na praktični dio i vidimo kako to sve funkcionira u praksi.
Prvo, implementirajmo jednostavnu Openstack instalaciju. Budući da nemam set poslužitelja pri ruci za eksperimente, sastaviti ćemo prototip na jednom fizičkom poslužitelju od virtualnih strojeva. Da, naravno, takvo rješenje nije prikladno za komercijalne svrhe, ali da vidite primjer kako mreža radi u Openstacku, takva instalacija je dovoljna za oči. Štoviše, takva je instalacija još zanimljivija za potrebe obuke - jer možete uhvatiti promet itd.
Budući da trebamo vidjeti samo osnovni dio, ne možemo koristiti više mreža nego sve dizati koristeći samo dvije mreže, a druga mreža u ovom rasporedu služit će isključivo za pristup undercloudu i DNS poslužitelju. Za sada se nećemo doticati vanjskih mreža - ovo je tema za poseban veliki članak.
Pa krenimo redom. Prvo, malo teorije. Openstack ćemo instalirati koristeći TripleO (Openstack na Openstacku). Bit TripleO-a je da instaliramo Openstack all-in-one (dakle, na jednom čvoru), koji se zove undercloud, a zatim koristimo mogućnosti implementiranog Openstacka za instaliranje Openstacka namijenjenog radu, koji se naziva overcloud. Undercloud će koristiti svoju inherentnu sposobnost upravljanja fizičkim poslužiteljima (goli metal) - projekt Ironic - za pružanje hipervizora koji će obavljati uloge čvorova za računanje, kontrolu i pohranu. To jest, ne koristimo alate trećih strana za implementaciju Openstacka - mi implementiramo Openstack pomoću Openstacka. Bit će mnogo jasnije kako instalacija napreduje, tako da nećemo tu stati i krenuti naprijed.
Napomena: u ovom članku, radi jednostavnosti, nisam koristio mrežnu izolaciju za interne Openstack mreže, već je sve implementirano pomoću samo jedne mreže. Međutim, prisutnost ili odsutnost mrežne izolacije ne utječe na osnovnu funkcionalnost rješenja - sve će raditi potpuno isto kao i kod korištenja izolacije, ali promet će teći na istoj mreži. Za komercijalnu instalaciju, prirodno je potrebno koristiti izolaciju pomoću različitih vlan-ova i sučelja. Na primjer, ceph promet za upravljanje pohranom i sam podatkovni promet (strojni pristup diskovima, itd.) kada su izolirani koriste različite podmreže (Storage management i Storage) i to vam omogućuje da rješenje učinite tolerantnijim na greške dijeljenjem ovog prometa, na primjer , preko različitih priključaka ili koristeći različite QoS profile za različiti promet tako da podatkovni promet ne istiskuje signalni promet. U našem slučaju, oni će ići na istu mrežu i zapravo nas to ni na koji način ne ograničava.
Napomena: Budući da ćemo pokretati virtualne strojeve u virtualnom okruženju temeljenom na virtualnim strojevima, prvo moramo omogućiti ugniježđenu virtualizaciju.
Možete provjeriti je li ugniježđena virtualizacija omogućena ili ne ovako:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ako vidite slovo N, tada omogućujemo podršku za ugniježđenu virtualizaciju prema bilo kojem vodiču koji pronađete na mreži, na primjer .
Moramo sastaviti sljedeći krug od virtualnih strojeva:
U mom slučaju, za povezivanje virtualnih strojeva koji su dio buduće instalacije (a dobio sam ih 7, ali možete proći i s 4 ako nemate puno resursa), koristio sam OpenvSwitch. Napravio sam jedan ovs most i na njega povezao virtualne strojeve preko port-groups. Da bih to učinio, stvorio sam xml datoteku poput ove:
[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>Ovdje su deklarirane tri grupe priključaka - dva pristupna i jedan trunk (potonji je bio potreban za DNS poslužitelj, ali možete i bez njega ili ga instalirati na glavno računalo - što vam više odgovara). Zatim, koristeći ovaj predložak, izjavljujemo naše putem virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Sada uređujemo konfiguracije porta hipervizora:
[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 ~]# Napomena: u ovom scenariju adresa na portu ovs-br1 neće biti dostupna jer nema vlan oznaku. Da biste to popravili, trebate izdati naredbu sudo ovs-vsctl set port ovs-br1 tag=100. Međutim, nakon ponovnog pokretanja, ova oznaka će nestati (ako netko zna kako da ostane na mjestu, bio bih mu vrlo zahvalan). Ali to nije toliko važno, jer će nam ova adresa trebati samo tijekom instalacije i neće je trebati kada Openstack bude u potpunosti implementiran.
Zatim stvaramo podoblačni stroj:
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=ttyS0Tijekom instalacije postavite sve potrebne parametre kao što su naziv stroja, lozinke, korisnici, ntp serveri itd., možete odmah konfigurirati portove, ali meni osobno je nakon instalacije lakše ulogirati se na stroj preko konzolu i ispravite potrebne datoteke. Ako već imate gotovu sliku, možete je koristiti ili učiniti ono što sam ja učinio - preuzmite minimalnu sliku Centos 7 i upotrijebite je za instalaciju VM-a.
Nakon uspješne instalacije trebali biste imati virtualni stroj na koji možete instalirati Undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNajprije instalirajte alate potrebne za postupak instalacije:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud instalacija
Stvaramo korisnika skupa, postavljamo lozinku, dodajemo je u sudoer i dajemo mu mogućnost izvršavanja root naredbi kroz sudo bez potrebe za unosom lozinke:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackSada specificiramo puni naziv Underclouda u host datoteci:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Zatim dodajemo spremišta i instaliramo softver koji nam je potreban:
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-ansibleNapomena: ako ne planirate instalirati ceph, tada ne morate unositi naredbe koje se odnose na ceph. Koristio sam izdanje Queensa, ali možete koristiti bilo koje drugo koje želite.
Zatim kopirajte konfiguracijsku datoteku Undercloud u stog korisničkog matičnog direktorija:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSada moramo ispraviti ovu datoteku, prilagoditi je našoj instalaciji.
Morate dodati ove retke na početak datoteke:
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 = 10Dakle, prođimo kroz postavke:
undercloud_hostname — puno ime undercloud poslužitelja, mora odgovarati unosu na DNS poslužitelju
lokalni_ip — lokalna adresa pod oblakom prema mrežnom opskrbljivanju
mrežni_pristupnik — ista lokalna adresa, koja će djelovati kao pristupnik za pristup vanjskom svijetu tijekom instalacije overcloud čvorova, također se podudara s lokalnim ip-om
undercloud_javni_domaćin — vanjska API adresa, dodjeljuje se bilo koja slobodna adresa iz mreže za pružanje usluga
undercloud_admin_host internu API adresu, dodjeljuje se bilo koja slobodna adresa iz mreže za dodjelu
undercloud_nameservers — DNS poslužitelj
generirati_uslužni_certifikat - ova linija je vrlo važna u trenutnom primjeru, jer ako je ne postavite na false dobit ćete pogrešku tijekom instalacije, problem je opisan na Red Hat alatu za praćenje bugova
lokalno_sučelje sučelje u pružanju mrežnih usluga. Ovo sučelje će se rekonfigurirati tijekom implementacije Underclouda, tako da trebate imati dva sučelja na Undercloudu - jedno za pristup, drugo za pružanje usluga
lokalni_mtu - MTU. Pošto imamo ispitni laboratorij i imam MTU 1500 na portovima OVS switcha, potrebno ga je namjestiti na 1450 kako bi paketi enkapsulirani u VxLAN mogli prolaziti
mreža_cidr — mreža za opskrbu
maskarada — korištenje NAT-a za pristup vanjskoj mreži
maškarana_mreža - mreža koja će imati NAT
dhcp_start — početna adresa skupine adresa iz koje će se adrese dodjeljivati čvorovima tijekom postavljanja overclouda
dhcp_kraj — konačna adresa skupine adresa iz koje će se adrese dodjeljivati čvorovima tijekom postavljanja overclouda
inspekcija_iprange — skup adresa potrebnih za introspekciju (ne smije se preklapati s gornjim skupom)
planer_max_pokušaja — najveći broj pokušaja instaliranja overclouda (mora biti veći ili jednak broju čvorova)
Nakon što je datoteka opisana, možete dati naredbu za implementaciju Underclouda:
openstack undercloud install
Postupak traje od 10 do 30 minuta ovisno o Vašem željezu. Na kraju biste trebali vidjeti ovakav rezultat:
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.
#############################################################################Ovaj izlaz kaže da ste uspješno instalirali Undercloud i sada možete provjeriti status Underclouda i nastaviti s instaliranjem Overclouda.
Ako pogledate ifconfig izlaz, vidjet ćete da se pojavilo novo sučelje mosta
[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 0Implementacija Overclouda sada će se provoditi putem ovog sučelja.
Iz rezultata ispod možete vidjeti da imamo sve usluge na jednom čvoru:
(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 |
+--------------------------+-----------+----------+Ispod je konfiguracija dijela mreže 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 ~]$Overcloud instalacija
Trenutno imamo samo podoblake, a nemamo dovoljno čvorova iz kojih će se sklopiti nadoblak. Stoga, prije svega, implementirajmo virtualne strojeve koji su nam potrebni. Tijekom implementacije, Undercloud će sam instalirati OS i potreban softver na overcloud stroj - odnosno, ne trebamo kompletno implementirati stroj, već samo kreirati disk (ili diskove) za njega i odrediti njegove parametre - tj. , zapravo, dobivamo goli poslužitelj bez OS-a instaliranog na njemu.
Idemo u mapu s diskovima naših virtualnih strojeva i stvorimo diskove potrebne veličine:
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 160GBudući da radimo kao root, moramo promijeniti vlasnika ovih diskova kako ne bismo imali problema s pravima:
[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]# Napomena: ako ne planirate instalirati ceph kako biste ga proučavali, tada naredbe ne kreiraju najmanje 3 čvora s najmanje dva diska, već u predlošku naznačite da će se koristiti virtualni diskovi vda, vdb itd.
Super, sada moramo definirati sve ove strojeve:
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 Na kraju je naredba -print-xml > /tmp/storage-1.xml, koja kreira xml datoteku s opisom svakog stroja u mapi /tmp/, ako je ne dodate, nećete biti sposobni identificirati virtualne strojeve.
Sada moramo definirati sve ove strojeve u virsh-u:
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 ~]#Sada mala nijansa - tripleO koristi IPMI za upravljanje poslužiteljima tijekom instalacije i introspekcije.
Introspekcija je proces pregleda hardvera kako bi se dobili njegovi parametri potrebni za daljnje opskrbljivanje čvorova. Introspekcija se provodi pomoću ironic, usluge dizajnirane za rad s golim poslužiteljima.
Ali ovdje je problem - dok hardverski IPMI poslužitelji imaju zaseban priključak (ili zajednički priključak, ali to nije važno), virtualni strojevi nemaju takve priključke. Ovdje nam u pomoć dolazi štaka zvana vbmc - uslužni program koji vam omogućuje emulaciju IPMI porta. Ovu nijansu vrijedi obratiti pozornost posebno za one koji žele postaviti takav laboratorij na ESXI hipervizoru - da budem iskren, ne znam ima li analogni vbmc, pa se vrijedi zapitati o ovom pitanju prije nego što sve implementirate .
Instalirajte vbmc:
yum install yum install python2-virtualbmcAko vaš OS ne može pronaći paket, dodajte spremište:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSada postavljamo uslužni program. Ovdje je sve banalno do sramote. Sada je logično da na vbmc listi nema poslužitelja
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Da bi se pojavili, moraju se ručno deklarirati ovako:
[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 ~]#Mislim da je sintaksa naredbe jasna bez objašnjenja. Međutim, za sada su sve naše sesije u statusu NISU. Da bi prešli u GORE status, morate im omogućiti:
[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 posljednji dodir - trebate ispraviti pravila vatrozida (ili ga potpuno onemogućiti):
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
Sada idemo u Undercloud i provjerimo radi li sve. Adresa glavnog računala je 192.168.255.200, na Undercloud smo dodali potreban ipmitool paket tijekom pripreme za implementaciju:
[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 runningKao što vidite, uspješno smo pokrenuli kontrolni čvor putem vbmc-a. Sada ga isključimo i idemo dalje:
[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 ~]#Sljedeći korak je introspekcija čvorova na kojima će biti instaliran overcloud. Da bismo to učinili, moramo pripremiti json datoteku s opisom naših čvorova. Imajte na umu da, za razliku od instalacije na golim poslužiteljima, datoteka označava port na kojem se vbmc izvodi za svaki stroj.
[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:27Napomena: kontrolni čvor ima dva sučelja, ali u ovom slučaju to nije važno, u ovoj instalaciji jedno će nam biti dovoljno.
Sada pripremamo json datoteku. Moramo naznačiti poppy adresu porta kroz koji će se izvršiti opskrba, parametre čvorova, dati im imena i naznačiti kako doći do ipmi-ja:
{
"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"
}
]
}Sada moramo pripremiti slike za ironiju. Da biste to učinili, preuzmite ih putem wgeta i instalirajte:
(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 ~]$Prijenos slika u 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 ~]$Provjera jesu li sve slike učitane
(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 ~]$Još jedna stvar - trebate dodati DNS poslužitelj:
(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 ~]$Sada možemo dati naredbu za introspekciju:
(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 ~]$Kao što možete vidjeti iz rezultata, sve je završeno bez grešaka. Provjerimo jesu li svi čvorovi u dostupnom stanju:
(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 ~]$ Ako su čvorovi u drugom stanju, obično upravljivom, onda je nešto pošlo po zlu i morate pogledati zapisnik i shvatiti zašto se to dogodilo. Imajte na umu da u ovom scenariju koristimo virtualizaciju i da mogu postojati greške povezane s upotrebom virtualnih strojeva ili vbmc-a.
Zatim moramo naznačiti koji će čvor obavljati koju funkciju - to jest, naznačiti profil s kojim će se čvor postaviti:
(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 ~]$Navedite profil za svaki čvor:
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-d9afb69d1167Provjerimo da li smo sve napravili ispravno:
(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 ~]$Ako je sve ispravno, dajemo naredbu za postavljanje overclouda:
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 qemuU stvarnoj instalaciji, prirodno će se koristiti prilagođeni predlošci, u našem slučaju to će uvelike zakomplicirati proces, budući da će svako uređivanje u predlošku morati biti objašnjeno. Kao što je ranije napisano, čak i jednostavna instalacija bit će dovoljna da vidimo kako radi.
Napomena: qemu varijabla tipa --libvirt je neophodna u ovom slučaju, jer ćemo koristiti ugniježđenu virtualizaciju. U suprotnom, nećete moći pokretati virtualne strojeve.
Sada imate oko sat vremena, ili možda više (ovisno o mogućnostima hardvera) i možete se samo nadati da ćete nakon tog vremena vidjeti sljedeću poruku:
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 ~]$Sada imate gotovo potpunu verziju openstacka, na kojoj možete učiti, eksperimentirati itd.
Provjerimo radi li sve kako treba. U stogu korisničkog matičnog direktorija nalaze se dvije datoteke - jedna stackrc (za upravljanje podoblakom) i druga overcloudrc (za upravljanje preoblakom). Ove datoteke moraju biti navedene kao izvor jer sadrže podatke potrebne za provjeru autentičnosti.
(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 ~]$Moja instalacija i dalje zahtijeva jedan mali potez - dodavanje rute na kontroleru, budući da je stroj s kojim radim na drugoj mreži. Da biste to učinili, idite na control-1 pod računom heat-admin i registrirajte rutu
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Pa, sada možete ići u horizont. Svi podaci - adrese, prijava i lozinka - nalaze se u datoteci /home/stack/overcloudrc. Konačni dijagram izgleda ovako:
Usput, u našoj instalaciji, adrese stroja izdane su putem DHCP-a i, kao što vidite, izdaju se "nasumično". U predlošku možete strogo definirati koja adresa treba biti priložena kojem stroju tijekom implementacije, ako vam je potrebna.
Kako teče promet između virtualnih strojeva?
U ovom članku ćemo pogledati tri opcije za propuštanje prometa
- Dva stroja na jednom hipervizoru na jednoj L2 mreži
- Dva stroja na različitim hipervizorima na istoj L2 mreži
- Dva računala na različitim mrežama (cross-network rooting)
Slučajeve s pristupom vanjskom svijetu preko vanjske mreže, korištenjem plutajućih adresa, kao i distribuiranog usmjeravanja, razmotrit ćemo sljedeći put, za sada ćemo se usredotočiti na interni promet.
Da bismo provjerili, sastavimo sljedeći dijagram:
Napravili smo 4 virtualna računala - 3 na jednoj L2 mreži - net-1 i još 1 na net-2 mreži
(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 ~]$ Pogledajmo na kojim se hipervizorima nalaze stvoreni strojevi:
(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 |
(nadlak) [stack@undercloud ~]$
Strojevi vm-1 i vm-3 nalaze se na compute-0, strojevi vm-2 i vm-4 nalaze se na čvoru compute-1.
Osim toga, stvoren je virtualni usmjerivač koji omogućuje usmjeravanje između navedenih mreža:
(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 ~]$ Usmjerivač ima dva virtualna priključka koji djeluju kao pristupnici za mreže:
(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 ~]$ Ali prije nego što pogledamo kako promet teče, pogledajmo što trenutno imamo na kontrolnom čvoru (koji je također mrežni čvor) i na računskom čvoru. Počnimo s računskim čvorom.
[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 ~]$U ovom trenutku, čvor ima tri ovs mosta - br-int, br-tun, br-ex. Između njih, kao što vidimo, postoji skup sučelja. Radi lakšeg razumijevanja, nacrtajmo sva ova sučelja na dijagramu i vidimo što će se dogoditi.
Gledajući adrese na koje su podignuti VxLAN tuneli, može se vidjeti da je jedan tunel podignut na compute-1 (192.168.255.26), a drugi tunel izgleda na control-1 (192.168.255.15). Ali najzanimljivije je to što br-ex nema fizička sučelja, a ako pogledate koji su tokovi konfigurirani, možete vidjeti da ovaj most trenutno može samo ispuštati promet.
[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 ~]$ Kao što možete vidjeti iz izlaza, adresa je spojena izravno na fizički port, a ne na sučelje virtualnog mosta.
[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 ~]$
Prema prvom pravilu, sve što je došlo iz phy-br-ex porta mora se odbaciti.
Zapravo, promet trenutno ne postoji odakle drugdje dolaziti na ovaj most osim s ovog sučelja (sučelje s br-int), a sudeći po padovima, BUM promet je već ušao u most.
Odnosno, promet može napustiti ovaj čvor samo kroz VxLAN tunel i ništa drugo. Međutim, ako uključite DVR, situacija će se promijeniti, ali o tome ćemo drugi put. Kada koristite mrežnu izolaciju, na primjer koristeći vlan, nećete imati jedno L3 sučelje u vlan 0, već nekoliko sučelja. Međutim, VxLAN promet će napustiti čvor na isti način, ali također enkapsuliran u neku vrstu namjenskog vlan-a.
Razvrstali smo računalni čvor, prijeđimo na kontrolni čvor.
[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 ~]$Zapravo, možemo reći da je sve isto, ali IP adresa više nije na fizičkom sučelju već na virtualnom mostu. To je učinjeno jer je ova luka luka kroz koju će promet izlaziti u vanjski svijet.
[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 ~]$ Ovaj port je povezan s br-ex mostom i budući da na njemu nema vlan oznaka, ovaj port je trunk port na kojem su dopušteni svi vlan-ovi, sada promet ide van bez oznake, kao što pokazuje vlan-id 0 u izlaz iznad.
Sve ostalo u ovom trenutku je slično računalnom čvoru - isti mostovi, isti tuneli koji vode do dva računalna čvora.
U ovom članku nećemo razmatrati čvorove za pohranu, ali za razumijevanje je potrebno reći da je mrežni dio ovih čvorova banalan do sramote. U našem slučaju, postoji samo jedan fizički port (eth0) kojem je dodijeljena IP adresa i to je to. Ne postoje VxLAN tuneli, tunelski mostovi itd. - nema uopće ovs-a, jer to nema svrhe. Kada koristite mrežnu izolaciju, ovaj čvor će imati dva sučelja (fizički port, bodny ili samo dva vlan-a - nije bitno - ovisi što želite) - jedno za upravljanje, drugo za promet (pisanje na VM disk , čitanje s diska itd.)
Shvatili smo što imamo na čvorovima u nedostatku bilo kakvih usluga. Sada pokrenimo 4 virtualna računala i vidimo kako se mijenja gore opisana shema - trebali bismo imati portove, virtualne usmjerivače itd.
Za sada naša mreža izgleda ovako:
Imamo dva virtualna stroja na svakom računalnom čvoru. Koristeći compute-0 kao primjer, da vidimo kako je sve uključeno.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Stroj ima samo jedno virtualno sučelje - 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 ~]$
Ovo sučelje izgleda u linux mostu:
[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 ~]$ Kao što možete vidjeti iz izlaza, postoje samo dva sučelja u mostu - tap95d96a75-a0 i qvb95d96a75-a0.
Ovdje se vrijedi malo zadržati na vrstama virtualnih mrežnih uređaja u OpenStacku:
vtap - virtualno sučelje priključeno na instancu (VM)
qbr - Linux most
qvb i qvo - vEth par spojen na Linux most i Open vSwitch most
br-int, br-tun, br-vlan — Otvorite vSwitch mostove
patch-, int-br-, phy-br- - Open vSwitch patch sučelja koja povezuju mostove
qg, qr, ha, fg, sg - Otvorite vSwitch portove koje virtualni uređaji koriste za spajanje na OVS
Kao što razumijete, ako imamo qvb95d96a75-a0 port u mostu, koji je vEth par, onda negdje postoji njegov pandan, koji bi se logično trebao zvati qvo95d96a75-a0. Pogledajmo koji su portovi na OVS-u.
[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 ~]$ Kao što vidimo, luka je u br-int. Br-int djeluje kao prekidač koji prekida portove virtualnog stroja. Uz qvo95d96a75-a0, port qvo5bd37136-47 vidljiv je u izlazu. Ovo je priključak za drugi virtualni stroj. Kao rezultat toga, naš dijagram sada izgleda ovako:
Pitanje koje bi odmah trebalo zainteresirati pažljivog čitatelja - koji je linux most između porta virtualnog stroja i OVS porta? Činjenica je da se za zaštitu stroja koriste sigurnosne grupe koje nisu ništa više od iptables. OVS ne radi s iptables, pa je ova "štaka" izmišljena. Međutim, postaje zastario - zamjenjuje ga conntrack u novim izdanjima.
Odnosno, u konačnici shema izgleda ovako:
Dva stroja na jednom hipervizoru na jednoj L2 mreži
Budući da se ova dva VM-a nalaze na istoj L2 mreži i na istom hipervizoru, promet između njih će logično teći lokalno kroz br-int, budući da će oba stroja biti na istom VLAN-u:
[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 ~]$ Dva stroja na različitim hipervizorima na istoj L2 mreži
Sada da vidimo kako će teći promet između dva računala na istoj L2 mreži, ali smještena na različitim hipervizorima. Da budem iskren, ništa se neće puno promijeniti, samo će promet između hipervizora ići kroz vxlan tunel. Pogledajmo primjer.
Adrese virtualnih strojeva između kojih ćemo pratiti promet:
[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 ~]$ Gledamo tablicu prosljeđivanja u br-int na 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 ~]Promet bi trebao ići na priključak 2 - da vidimo kakav je to priključak:
[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 ~]$Ovo je patch-tun - to jest, sučelje u br-tun. Pogledajmo što se događa s paketom na 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 ~]$ Paket se pakira u VxLAN i šalje na port 2. Pogledajmo kamo port 2 vodi:
[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 ~]$Ovo je vxlan tunel na 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 ~]$Idemo na compute-1 i vidimo što će se sljedeće dogoditi s paketom:
[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 je u br-int tablici prosljeđivanja na compute-1, i kao što se može vidjeti iz gornjeg izlaza, vidljiv je kroz port 2, koji je port prema 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:46Pa, onda vidimo da u br-int na compute-1 postoji odredišni mak:
[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 ~]$ Odnosno, primljeni paket će letjeti na port 3, iza kojeg već postoji instanca virtualnog stroja-00000003.
Ljepota implementacije Openstacka za učenje na virtualnoj infrastrukturi je u tome što možemo lako uhvatiti promet između hipervizora i vidjeti što se s njim događa. Ovo je ono što ćemo sada učiniti, pokrenuti tcpdump na vnet portu prema 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*******************Prvi redak pokazuje da Patek s adrese 10.0.1.85 ide na adresu 10.0.1.88 (ICMP promet), te je zamotan u VxLAN paket s vni 22 i paket ide s hosta 192.168.255.19 (compute-0) na host 192.168.255.26 .1 (izračunaj-XNUMX). Možemo provjeriti odgovara li VNI onom navedenom u ovs.
Vratimo se na ovaj red akcije=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 je vni u heksadecimalnom brojevnom sustavu. Pretvorimo ovaj broj u 16. sustav:
16 = 6*16^0+1*16^1 = 6+16 = 22Odnosno, vni odgovara stvarnosti.
Drugi red prikazuje povratni promet, dobro, nema smisla objašnjavati, tamo je sve jasno.
Dva stroja na različitim mrežama (usmjeravanje između mreže)
Posljednji slučaj za danas je usmjeravanje između mreža unutar jednog projekta pomoću virtualnog usmjerivača. Razmatramo slučaj bez DVR-a (pogledat ćemo ga u drugom članku), tako da se usmjeravanje događa na mrežnom čvoru. U našem slučaju mrežni čvor nije smješten u zasebnu cjelinu i nalazi se na kontrolnom čvoru.
Prvo, da vidimo funkcionira li usmjeravanje:
$ 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 msBudući da u ovom slučaju paket mora ići do gatewaya i tamo biti preusmjeren, moramo saznati poppy adresu pristupnika, za što gledamo ARP tablicu u primjeru:
$ 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 eth0Sada da vidimo gdje treba poslati promet s destinacijom (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 ~]$ Pogledajmo kamo vodi priključak 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 ~]$ Sve je logično, promet ide na br-tun. Da vidimo u koji će vxlan tunel biti umotan:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Treći port je vxlan tunel:
[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 ~]$ Koji gleda na kontrolni čvor:
[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 ~]$ Promet je stigao do kontrolnog čvora, pa moramo otići do njega i vidjeti kako će se odvijati usmjeravanje.
Kao što se sjećate, kontrolni čvor iznutra izgledao je potpuno isto kao i računalni čvor - ista tri mosta, samo je br-ex imao fizički port kroz koji je čvor mogao slati promet van. Stvaranje instanci promijenilo je konfiguraciju na računalnim čvorovima - čvorovima su dodani linux bridge, iptables i sučelja. Stvaranje mreža i virtualnog usmjerivača ostavilo je traga i na konfiguraciji kontrolnog čvora.
Dakle, očito je da MAC adresa pristupnika mora biti u br-int tablici prosljeđivanja na kontrolnom čvoru. Provjerimo je li tu i gdje gleda:
[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 je vidljiv s priključka qr-0c52b15f-8f. Ako se vratimo na popis virtualnih portova u Openstacku, ovaj tip porta se koristi za povezivanje raznih virtualnih uređaja na OVS. Da budemo precizniji, qr je priključak za virtualni usmjerivač, koji je predstavljen kao imenski prostor.
Pogledajmo koji su prostori imena na poslužitelju:
[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 ~]$ Čak tri primjerka. No, sudeći po nazivima, možete pogoditi svrhu svakog od njih. Kasnije ćemo se vratiti na instance s ID-om 0 i 1, sada nas zanima imenski prostor 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 ~]$ Ovaj imenski prostor sadrži dva interna koja smo ranije stvorili. Oba virtualna porta su dodana u br-int. Provjerimo mac adresu porta qr-0c52b15f-8f, budući da je promet, sudeći po odredišnoj mac adresi, išao na ovo sučelje.
[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 ~]$ To jest, u ovom slučaju sve radi prema zakonima standardnog usmjeravanja. Budući da je promet namijenjen hostu 10.0.2.8, mora izaći kroz drugo sučelje qr-92fa49b5-54 i proći kroz vxlan tunel do računalnog čvora:
[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 ~]$ Sve je logično, bez iznenađenja. Pogledajmo gdje je poppy adresa hosta 10.0.2.8 vidljiva u br-int-u:
[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 ~]$ Očekivano, promet ide prema br-tunu, da vidimo kojim tunelom dalje ide promet:
[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 ~]$ Promet ide u tunel za izračunavanje-1. Pa, na compute-1 sve je jednostavno - od br-tun paket ide do br-int i od tamo do sučelja virtualnog stroja:
[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 ~]$ Provjerimo je li ovo doista ispravno sučelje:
[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 ~]$
Zapravo, prošli smo cijeli paket. Mislim da ste primijetili da je promet išao kroz različite vxlan tunele i izlazio s različitim VNI-jevima. Pogledajmo koji su to VNI-ji, nakon čega ćemo prikupiti deponiju na kontrolnom portu čvora i osigurati da promet teče točno kako je gore opisano.
Dakle, tunel za izračunavanje-0 ima sljedeće akcije=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Pretvorimo 0x16 u decimalni brojevni sustav:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel za compute-1 ima sljedeći VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Pretvorimo 0x63 u decimalni brojevni sustav:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Pa, sada pogledajmo deponij:
[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*******************Prvi paket je vxlan paket od hosta 192.168.255.19 (compute-0) do hosta 192.168.255.15 (control-1) s vni 22, unutar kojeg je ICMP paket pakiran od hosta 10.0.1.85 do hosta 10.0.2.8. Kao što smo izračunali gore, vni odgovara onome što smo vidjeli u izlazu.
Drugi paket je vxlan paket od hosta 192.168.255.15 (control-1) do hosta 192.168.255.26 (compute-1) s vni 99, unutar kojeg je pakiran ICMP paket od hosta 10.0.1.85 do hosta 10.0.2.8. Kao što smo izračunali gore, vni odgovara onome što smo vidjeli u izlazu.
Sljedeća dva paketa povratni su promet s 10.0.2.8, a ne s 10.0.1.85.
To jest, na kraju smo dobili sljedeću shemu kontrolnog čvora:
Izgleda da je to to? Zaboravili smo na dva imenska prostora:
[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 ~]$ Kako smo govorili o arhitekturi platforme u oblaku, bilo bi dobro kada bi strojevi primali adrese automatski s DHCP poslužitelja. Ovo su dva DHCP poslužitelja za naše dvije mreže 10.0.1.0/24 i 10.0.2.0/24.
Provjerimo je li to istina. Postoji samo jedna adresa u ovom prostoru imena - 10.0.1.1 - adresa samog DHCP poslužitelja, a također je uključena u 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 0Pogledajmo sadrže li procesi qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 u svom imenu na kontrolnom čvoru:
[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 ~]$ Postoji takav proces i na temelju informacija predstavljenih u gornjem izlazu, možemo, na primjer, vidjeti što trenutno imamo za najam:
[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 ~]$Kao rezultat, dobivamo sljedeći skup usluga na kontrolnom čvoru:
Pa, imajte na umu - ovo su samo - 4 stroja, 2 interne mreže i jedan virtualni usmjerivač... Mi ovdje sada nemamo vanjske mreže, hrpu različitih projekata, svaki sa svojim mrežama (preklapaju se), a mi imati distribuirani usmjerivač isključen, i na kraju Uostalom, postojao je samo jedan kontrolni čvor u testnom stolu (za toleranciju grešaka mora postojati kvorum od tri čvora). Logično je da je u trgovini sve “malo” kompliciranije, ali u ovom jednostavnom primjeru razumijemo kako bi to trebalo funkcionirati - naravno da je važno imate li 3 ili 300 imenskih prostora, ali sa stajališta rada cijelu strukturu, ništa se neće puno promijeniti... iako nećete uključiti neki SDN dobavljača. Ali to je sasvim druga priča.
Nadam se da je bilo zanimljivo. Ako imate bilo kakvih komentara/dopuna, ili sam negdje otvoreno lagao (ljud sam i moje mišljenje će uvijek biti subjektivno) - napišite što treba ispraviti/dodati - sve ćemo ispraviti/dodati.
Zaključno, želio bih reći nekoliko riječi o usporedbi Openstacka (i vanilla i dobavljača) s rješenjem za oblak iz VMWarea - ovo su mi pitanje postavljali prečesto u proteklih nekoliko godina i, iskreno govoreći, ja sam već umoran od toga, ali ipak. Po mom mišljenju, vrlo je teško usporediti ova dva rješenja, ali definitivno možemo reći da postoje nedostaci u oba rješenja i pri odabiru jednog rješenja potrebno je odvagnuti prednosti i nedostatke.
Ako je OpenStack rješenje koje pokreće zajednica, onda VMWare ima pravo raditi samo ono što želi (čitaj - ono što mu je isplativo) i to je logično - jer je komercijalna tvrtka koja je navikla zarađivati od svojih klijenata. Ali postoji jedno veliko i debelo ALI - možete se skinuti s OpenStacka, npr. Nokie, i uz male troškove prijeći na rješenje npr. Junipera (Contrail Cloud), ali teško da ćete uspjeti skinuti VMWare . Kod mene ova dva rješenja izgledaju ovako - Openstack (vendor) je običan kavez u koji te strpaju, ali imaš ključ i možeš otići u bilo kojem trenutku. VMWare je zlatni kavez, vlasnik ima ključ od kaveza i skupo će vas koštati.
Ne reklamiram ni prvi ni drugi proizvod - vi odaberite što vam treba. Ali da imam takav izbor, odabrao bih oba rješenja - VMWare za IT oblak (mala opterećenja, jednostavno upravljanje), OpenStack nekog dobavljača (Nokia i Juniper pružaju vrlo dobra rješenja po principu "ključ u ruke") - za Telekomov oblak. Ne bih koristio Openstack za čisti IT - to je kao da pucam u vrabce iz topa, ali ne vidim nikakve kontraindikacije za korištenje osim redundantnosti. Međutim, korištenje VMWare-a u telekomu je poput dovoza drobljenog kamena u Ford Raptoru - izvana je prekrasan, ali vozač mora napraviti 10 putovanja umjesto jednog.
Po mom mišljenju najveći nedostatak VMWare-a je njegova potpuna zatvorenost - tvrtka vam neće dati nikakve informacije o tome kako funkcionira, npr. vSAN ili što je u jezgri hipervizora - to joj jednostavno nije isplativo - tj. nikad ne postanite stručnjak za VMWare - bez podrške dobavljača, osuđeni ste na propast (vrlo često susrećem stručnjake za VMWare koji su zbunjeni trivijalnim pitanjima). Za mene VMWare kupuje auto sa zaključanom haubom - da, možda imate stručnjake koji mogu promijeniti zupčasti remen, ali samo onaj tko vam je prodao ovo rješenje može otvoriti haubu. Osobno ne volim rješenja u koja se ne mogu uklopiti. Reći ćete da možda nećete morati ulaziti ispod haube. Da, ovo je moguće, ali pogledat ću vas kada budete trebali sastaviti veliku funkciju u oblaku od 20-30 virtualnih strojeva, 40-50 mreža, od kojih polovica želi izaći van, a druga polovica traži SR-IOV ubrzanje, inače će vam trebati više desetaka ovih automobila - inače performanse neće biti dovoljne.
Postoje i druge točke gledišta, tako da samo vi možete odlučiti što ćete odabrati i, što je najvažnije, tada ćete biti odgovorni za svoj izbor. Ovo je samo moje mišljenje - osobe koja je vidjela i dodirnula barem 4 proizvoda - Nokia, Juniper, Red Hat i VMWare. Odnosno, imam s čime usporediti.
Izvor: www.habr.com