Cloud computing prodire sve dublje i dublje u naše živote i vjerovatno ne postoji osoba koja barem jednom nije koristila usluge u oblaku. Međutim, šta je oblak i kako funkcioniše, uglavnom malo ljudi zna čak i na nivou ideje. 5G postaje stvarnost, a telekom infrastruktura počinje da se kreće sa polnih rješenja na rješenja u oblaku, kao što je to bilo kada je prešla sa potpuno hardverskih rješenja na virtuelizirane „stubove“.
Danas ćemo govoriti o unutrašnjem svijetu oblak infrastrukture, posebno ćemo analizirati osnove mrežnog dijela.
Šta je oblak? Ista virtuelizacija - pregled profila?
Više nego logično pitanje. Ne – ovo nije virtuelizacija, iako bez nje ne bi moglo. Razmotrite dvije definicije:
Cloud Computing (u daljem tekstu Cloud) je model za pružanje pristupa prilagođenog korisniku distribuiranim računarskim resursima koji moraju biti raspoređeni i pokrenuti na zahtjev sa najnižim mogućim kašnjenjem i minimalnim troškovima za pružatelja usluga.
Virtuelizacija - ovo je mogućnost podjele jednog fizičkog entiteta (npr. servera) na nekoliko virtuelnih, čime se povećava iskorištenost resursa (npr. imali ste 3 servera učitana za 25-30 posto, nakon virtuelizacije dobijate 1 učitan server za 80-90 posto). Naravno, virtuelizacija pojede neke od resursa - morate hraniti hipervizor, međutim, kao što je praksa pokazala, igra je vrijedna svijeće. Idealan primer virtuelizacije je VMWare, koji je odličan u pripremi virtuelnih mašina, ili na primer KVM, koji ja preferiram, ali ovo je već stvar ukusa.
Koristimo virtuelizaciju a da toga nismo svjesni, a čak i željezni ruteri već koriste virtuelizaciju - na primjer, u najnovijoj verziji JunOS-a, operativni sistem je instaliran kao virtuelna mašina na vrhu distribucije Linuxa u realnom vremenu (Wind River 9). Ali virtuelizacija nije oblak, ali oblak ne može postojati bez virtuelizacije.
Virtuelizacija je jedan od građevinskih blokova na kojima je izgrađen oblak.
Neće raditi napraviti oblak jednostavnim sakupljanjem nekoliko hipervizora u jednu L2 domenu, dodavanjem nekoliko yaml playbookova za automatsku registraciju vlan-ova kroz neku vrstu ansible-a i ubacivanjem nečega poput sistema orkestracije na njega za automatsko kreiranje virtuelnih mašina. Tačnije, ispostaviće se, ali nastali Frankenštajn nije oblak koji nam je potreban, iako je nekome, možda je nekome ovo krajnji san. Osim toga, ako uzmete isti Openstack, u stvari to je još uvijek Frankenstein, ali dobro, da ne pričamo o tome za sada.
Ali razumijem da iz gore predstavljene definicije nije sasvim jasno šta se zapravo može nazvati oblakom.
Dakle, dokument NIST-a (Nacionalnog instituta za standarde i tehnologiju) navodi 5 glavnih karakteristika koje infrastruktura oblaka treba da ima:
Pružanje usluge na zahtjev. Korisniku treba omogućiti slobodan pristup računarskim resursima koji su mu dodijeljeni (kao što su mreže, virtuelni diskovi, memorija, procesorska jezgra itd.), a ti resursi bi trebali biti obezbjeđeni automatski – odnosno bez intervencije provajdera servisa.
Široka dostupnost usluga. Pristup resursima bi trebao biti omogućen standardnim mehanizmima kako bi se mogli koristiti i standardni računari i tanki klijenti i mobilni uređaji.
Kombinovanje resursa u skupove. Skupovi resursa moraju biti u stanju da obezbede resurse za više klijenata u isto vreme, obezbeđujući da su klijenti izolovani i oslobođeni međusobnog uticaja i konkurencije za resurse. Mreže su također uključene u skupove, što ukazuje na mogućnost korištenja preklapajućeg adresiranja. Bazeni moraju biti u mogućnosti skalirati na zahtjev. Upotreba skupova omogućava da se obezbedi potreban nivo tolerancije na greške resursa i apstrakcije fizičkih i virtuelnih resursa – primatelju usluge jednostavno se obezbeđuje skup resursa koji je zatražio (gde se ti resursi fizički nalaze, koliko serveri i svičevi - nije bitno za klijenta). Međutim, moramo uzeti u obzir činjenicu da provajder mora osigurati transparentnu rezervaciju ovih resursa.
Brza adaptacija na različite uslove. Usluge moraju biti fleksibilne – brzo obezbijediti resurse, preraspodijeliti ih, dodati ili smanjiti resurse na zahtjev klijenta, a klijent mora imati osjećaj da su resursi u oblaku beskrajni. Radi lakšeg razumijevanja, na primjer, ne vidite upozorenje da je dio vašeg diskovnog prostora nestao u Apple iCloud-u zbog činjenice da je hard disk na serveru pokvaren, a diskovi se kvare. Osim toga, sa vaše strane, mogućnosti ovog servisa su gotovo neograničene - potrebno vam je 2 TB - nema problema, platili ste i primili. Slično, možete dati primjer sa Google.Drive ili Yandex.Disk.
Mogućnost mjerenja pružene usluge. Cloud sistemi bi trebali automatski kontrolirati i optimizirati potrošene resurse, a ovi mehanizmi trebaju biti transparentni i za korisnika i za pružaoca usluga. Odnosno, uvijek možete provjeriti koliko resursa trošite vi i vaši klijenti.
Vrijedi uzeti u obzir činjenicu da su ovi zahtjevi najvećim dijelom zahtjevi za javni oblak, pa se za privatni oblak (odnosno oblak pokrenut za interne potrebe kompanije) ovi zahtjevi mogu malo prilagoditi. Međutim, oni i dalje moraju biti ispunjeni, inače nećemo dobiti sve prednosti računarstva u oblaku.
Zašto nam je potreban oblak?
Međutim, svaka nova ili postojeća tehnologija, svaki novi protokol je stvoren za nešto (pa, osim za RIP-ng, naravno). Nikome nije potreban protokol radi protokola (pa, osim RIP-nga, naravno). Logično je da je Cloud kreiran da pruži neku vrstu usluge korisniku/klijentu. Svima nam je poznato barem nekoliko cloud servisa, kao što su Dropbox ili Google.Docs, i vjerujem da ih većina uspješno koristi – na primjer, ovaj članak je napisan pomoću cloud servisa Google.Docs. No, nama poznate usluge u oblaku samo su dio mogućnosti oblaka – točnije, to je samo usluga tipa SaaS. Uslugu u oblaku možemo pružiti na tri načina: u obliku SaaS, PaaS ili IaaS. Koja vam je usluga potrebna zavisi od vaših želja i mogućnosti.
Razmotrimo svaki redom:
Softver kao usluga (SaaS) je model za pružanje punopravne usluge klijentu, na primjer, servis pošte kao što je Yandex.Mail ili Gmail. U ovom modelu pružanja usluga vi, kao klijent, zapravo ne radite ništa, nego koristite usluge – odnosno ne morate razmišljati o konfiguraciji usluge, njenoj toleranciji grešaka ili redundantnosti. Glavna stvar je da ne ugrozite svoju lozinku, provajder ove usluge će učiniti ostalo za vas. Sa stanovišta pružaoca usluga, on je u potpunosti odgovoran za cjelokupnu uslugu - od serverskog hardvera i host operativnih sistema do podešavanja baze podataka i softvera.
Platforma kao usluga (PaaS) - kada se koristi ovaj model, provajder usluga daje klijentu radni komad za uslugu, na primjer, uzmimo web server. Dobavljač usluga je klijentu dao virtuelni server (u stvari, skup resursa, kao što su RAM / CPU / Storage / Nets, itd.), pa čak i instalirao OS i potreban softver na ovom serveru, međutim, klijent sam konfiguriše sve ove dobrote i za performanse usluge već klijent odgovara. Provajder servisa, kao iu prethodnom slučaju, odgovoran je za performanse fizičke opreme, hipervizora, same virtuelne mašine, njene dostupnosti mreže, itd., ali sama usluga je već izvan njegovog područja odgovornosti.
Infrastruktura kao usluga (IaaS) - ovaj pristup je već interesantniji, u stvari, provajder usluga klijentu pruža kompletnu virtuelizovanu infrastrukturu - odnosno neku vrstu skupa (pula) resursa, kao što su CPU jezgra, RAM, mreže, itd. Sve ostalo je zavisi od klijenta - šta klijent želi da uradi sa ovim resursima u okviru skupa koji mu je dodeljen (kvota) - nije posebno važno za dobavljača. Ako klijent želi kreirati vlastiti vEPC ili čak napraviti mini operatera i pružati komunikacijske usluge – nema sumnje – učinite to. U takvom scenariju, provajder usluga je odgovoran za obezbjeđivanje resursa, njihovu toleranciju grešaka i dostupnost, kao i za OS, koji omogućava udruživanje ovih resursa i pružanje klijentu sa mogućnošću povećanja ili smanjenja resursa u bilo kojem trenutku u zahtev klijenta. Klijent konfiguriše sve virtuelne mašine i ostale šljokice preko samouslužnog portala i konzola, uključujući i dodelu mreža (osim eksternih mreža).
Šta je OpenStack?
U sve tri opcije, pružatelju usluga je potreban OS koji će im omogućiti da kreiraju infrastrukturu u oblaku. U stvari, kod SaaS-a, više od jednog odjela je odgovorno za cijeli tehnološki stog – postoji odjel koji je odgovoran za infrastrukturu – to jest, pruža IaaS drugom odjelu, ovo odjeljenje pruža SaaS klijentu. OpenStack je jedan od operativnih sistema u oblaku koji vam omogućava da prikupite gomilu prekidača, servera i sistema za skladištenje u jedan skup resursa, podelite ovaj zajednički skup na podpule (stanare) i obezbedite ove resurse klijentima preko mreže.
OpenStack je operativni sistem u oblaku koji vam omogućava da kontrolišete velike grupe računarskih resursa, skladištenja podataka i mrežnih resursa, koji se obezbeđuju i upravljaju preko API-ja koristeći standardne mehanizme autentifikacije.
Drugim riječima, ovo je skup projekata besplatnog softvera koji je dizajniran za kreiranje usluga u oblaku (i javnih i privatnih) - to jest, skup alata koji vam omogućavaju kombiniranje serverske i komutacijske opreme u jedan skup resursa, upravljanje ove resurse, obezbeđujući neophodan nivo tolerancije grešaka.
U vrijeme pisanja ovog teksta, OpenStack struktura izgleda ovako:
Slika preuzeta sa
Svaka od komponenti koje čine OpenStack obavlja određenu funkciju. Ova distribuirana arhitektura vam omogućava da u rješenje uključite skup funkcionalnih komponenti koje su vam potrebne. Međutim, neke od komponenti su korijenske komponente i njihovo uklanjanje će dovesti do potpune ili djelomične neoperabilnosti rješenja u cjelini. Ove komponente se obično nazivaju:
- Komandna tabla - Web baziran GUI za upravljanje OpenStack uslugama
- glavni princip - centralizirana usluga identiteta koja pruža funkciju provjere autentičnosti i autorizacije za druge usluge, kao i upravljanje korisničkim vjerodajnicama i njihovim ulogama.
- Neutron - mrežni servis koji pruža povezanost između sučelja različitih OpenStack servisa (uključujući povezanost između VM-ova i njihov pristup vanjskom svijetu)
- Cinder — omogućava pristup blok memoriji za virtuelne mašine
- nova — upravljanje životnim ciklusom virtuelnih mašina
- Pogled - spremište slika i snimaka virtuelne mašine
- brz - omogućava pristup skladištu objekata
- Ceilometar - usluga koja pruža mogućnost prikupljanja telemetrije i mjerenja raspoloživih i potrošnih resursa
- vrućina — orkestracija zasnovana na šablonima za automatsko kreiranje i obezbeđivanje resursa
Možete pogledati kompletnu listu svih projekata i njihovu namjenu .
Svaka od komponenti OpenStack-a je usluga koja je odgovorna za određenu funkciju i pruža API za upravljanje ovom funkcijom i interakciju sa drugim uslugama cloud operativnog sistema u cilju stvaranja jedinstvene infrastrukture. Na primjer, Nova pruža upravljanje računalnim resursima i API za pristup konfiguraciji podataka resursa, Glance pruža upravljanje slikama i API za upravljanje njima, Cinder pruža blok pohranu i API za upravljanje, itd. Sve funkcije su međusobno povezane na vrlo blizak način.
Međutim, ako sudimo, onda su svi servisi koji rade u OpenStacku na kraju neka vrsta virtuelne mašine (ili kontejnera) povezana na mrežu. Postavlja se pitanje – zašto nam treba toliko elemenata?
Prođimo kroz algoritam za kreiranje virtuelne mašine i njeno povezivanje na mrežu i trajnu pohranu u Openstacku.
- Kada kreirate zahtjev za kreiranje automobila, bilo da se radi o zahtjevu preko Horizon (Dashboard) ili zahtjevu putem CLI-a, prva stvar koja se dešava je autorizacija vašeg zahtjeva na Keystone-u - možete li kreirati automobil, imate ili pravo da koristite ovu mrežu, da li vaš projekat kvote, itd.
- Keystone autentifikuje vaš zahtjev i generiše auth token u poruci odgovora, koji će se dalje koristiti. Nakon što je Keystone dobio odgovor, zahtjev se šalje prema Novoj (nova api).
- Nova-api provjerava valjanost vašeg zahtjeva tako što će kontaktirati Keystone koristeći prethodno generirani token
- Keystone vrši autentifikaciju i pruža informacije o dozvolama i ograničenjima na osnovu ovog tokena.
- Nova-api kreira unos za novi VM u nova-database i prosljeđuje zahtjev za kreiranje stroja nova-scheduleru.
- Nova-scheduler bira host (čvorni računar) na kojem će VM biti raspoređen na osnovu datih parametara, težina i zona. Zapis o tome i VM ID se upisuju u nova-database.
- Zatim nova-scheduler poziva nova-compute sa zahtjevom za implementaciju instance. Nova-compute poziva nova-conductor da dobije informacije o parametrima mašine (nova-conductor je nova element koji djeluje kao proxy server između nova-baze podataka i nova-compute, ograničavajući broj zahtjeva za nova-bazom podataka kako bi se izbjegli problemi sa smanjenjem opterećenja konzistentnosti baze podataka).
- Nova-conductor preuzima tražene informacije iz nova-baze podataka i prosljeđuje ih nova-compute-u.
- Zatim nova-compute poziva pogled da dobije ID slike. Glace potvrđuje zahtjev u Keystoneu i vraća tražene informacije.
- Nova-compute poziva neutron za informacije o mrežnim parametrima. Slično kao na prvi pogled, neutron potvrđuje zahtjev u Keystoneu, zatim kreira unos u bazi podataka (ID porta, itd.), kreira zahtjev za kreiranje porta i vraća tražene informacije u nova-compute.
- Nova-compute kontaktira cinder sa zahtjevom da dodijeli volumen virtuelnoj mašini. Slično kao na prvi pogled, jabukovača potvrđuje zahtjev u Keystoneu, kreira zahtjev za kreiranje volumena i vraća tražene informacije.
- Nova-compute poziva libvirt sa zahtjevom za postavljanje virtuelne mašine sa datim parametrima.
Zapravo, naizgled jednostavna operacija kreiranja jednostavne virtuelne mašine pretvara se u takav vrtlog API poziva između elemenata platforme u oblaku. Štaviše, kao što vidite, čak se i prethodno određene usluge sastoje od manjih komponenti između kojih dolazi do interakcije. Kreiranje mašine je samo mali deo onoga što vam platforma u oblaku omogućava - postoji servis odgovoran za balansiranje saobraćaja, servis odgovoran za pohranu blokova, servis odgovoran za DNS, servis odgovoran za obezbeđivanje golih metalnih servera, itd. Oblak vam omogućava da svoje virtuelne mašine tretirate kao stado ovaca (za razliku od virtuelizacije). Ako se nešto dogodi vašoj mašini u virtuelnom okruženju - vraćate je iz rezervnih kopija itd., ali aplikacije u oblaku su izgrađene na način da virtuelna mašina ne igra tako važnu ulogu - virtuelna mašina je "umrla" - nema problema - novi automobil je jednostavno kreiran na osnovu šablona i, kako kažu, odred nije primetio gubitak borca. Naravno, ovo omogućava prisustvo mehanizama orkestracije - koristeći Heat šablone, lako možete implementirati složenu funkciju koja se sastoji od desetina mreža i virtuelnih mašina.
Uvijek vrijedi 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, mreža podloge je čak više ili manje statična - novi čvorovi i prekidači se ne dodaju svaki dan, ali se komponenta preklapanja može i neizbježno će se stalno mijenjati - nove mreže će se dodavati ili uklanjati, nove virtuelne mašine će se pojaviti i stare će se umreti. I kao što se sjećate iz definicije oblaka date na samom početku članka, resursi bi trebali biti dodijeljeni korisniku automatski i uz najmanju (ili bolje bez) intervenciju pružatelja usluga. Odnosno, vrsta pružanja mrežnih resursa koja je sada u obliku frontenda u obliku vašeg ličnog računa dostupnog putem http / https i Vasilija, mrežnog inženjera na dužnosti kao backend, nije oblak, čak i ako Vasilij ima osam ruku.
Neutron, kao mrežni servis, pruža API za upravljanje mrežnim dijelom infrastrukture oblaka. Usluga obezbeđuje zdravlje i upravljanje mrežnim delom Openstack-a tako što obezbeđuje sloj apstrakcije nazvan Mreža kao usluga (NaaS). To jest, mreža je ista virtuelna mjerljiva jedinica, kao što su virtualna jezgra CPU-a ili količina RAM-a.
Ali prije nego što pređemo na arhitekturu mrežnog dijela OpenStack-a, pogledajmo kako ova mreža funkcionira u OpenStack-u i zašto je mreža važan i sastavni dio oblaka.
Dakle, imamo dvije RED klijentske virtuelne mašine i dvije ZELENE klijentske virtuelne mašine. Pretpostavimo da se ove mašine nalaze na dva hipervizora na ovaj način:
Trenutno je ovo samo virtuelizacija 4 servera i ništa više, pošto smo do sada uradili samo virtuelizovana 4 servera, stavljajući ih na dva fizička servera. A ipak nisu ni povezani na mrežu.
Da bismo dobili oblak, moramo dodati nekoliko komponenti. Prvo virtueliziramo mrežni dio - trebamo povezati ove 4 mašine u paru, a klijenti žele upravo L2 vezu. Naravno, možete koristiti prekidač i postaviti trunk u njegovom pravcu i sve riješiti pomoću linux bridge-a, ili za naprednije korisnike openvswitcha (na to ćemo se vratiti kasnije). Ali može biti mnogo mreža, a stalno guranje L2 kroz prekidač nije najbolja ideja - dakle različiti odjeli, servisni desk, mjeseci čekanja da se aplikacija završi, sedmice rješavanja problema - u modernom svijetu, ovo pristup više ne funkcioniše. I što prije kompanija to shvati, lakše je ići naprijed. Stoga ćemo između hipervizora izabrati L3 mrežu preko koje će naše virtuelne mašine komunicirati, a na vrhu ove L3 mreže izgradićemo virtuelne preklapajuće L2 (preklapanje) mreže gde će se odvijati saobraćaj naših virtuelnih mašina. Enkapsulacija može biti GRE, Geneve ili VxLAN. Za sada, fokusirajmo se na ovo drugo, iako to nije posebno važno.
Moramo negdje locirati VTEP (nadam se da su svi upoznati sa VxLAN terminologijom). Pošto L3 mreža odmah napušta naše servere, ništa nas ne sprečava da VTEP postavimo na same servere, a OVS (OpenvSwitch) je savršeno u stanju da to uradi. Kao rezultat, dobili smo sljedeću strukturu:
Pošto saobraćaj između VM-ova mora biti odvojen, portovi prema virtuelnim mašinama će imati različite vlan brojeve. Broj oznake igra ulogu samo unutar jednog virtuelnog prekidača, pošto ga prilikom inkapsulacije u VxLAN možemo lako ukloniti, pošto ćemo imati VNI.
Sada možemo kreirati naše mašine i virtuelne mreže za njih bez ikakvih problema.
Međutim, šta ako klijent ima drugu mašinu, ali je na drugoj mreži? Trebamo root-ovanje između mreža. Analizirat ćemo jednostavnu opciju kada se koristi centralizirano rutiranje - to jest, promet se usmjerava kroz posebne namjenske mrežne čvorove (dobro, u pravilu se kombiniraju s kontrolnim čvorovima, tako da ćemo imati istu stvar).
Čini se da nije ništa komplikovano - napravimo bridge interfejs na kontrolnom čvoru, dovedemo saobraćaj do njega i odatle ga usmerimo tamo gde nam je potreban. Ali problem je u tome što RED klijent želi da koristi 10.0.0.0/24 mrežu, a GREEN klijent želi da koristi mrežu 10.0.0.0/24. To jest, počinjemo sjecište adresnih prostora. Osim toga, klijenti ne žele da drugi klijenti mogu da rutiraju na njihove interne mreže, što je logično. Da bismo razdvojili mreže i promet ovih klijenata, dodijelit ćemo poseban prostor imena za svakog od njih. Imenski prostor je u stvari kopija Linux mrežnog steka, to jest, klijenti u imenskom prostoru RED su potpuno izolirani od klijenata iz imenskog prostora ZELENI (dobro, ili je rutiranje između ovih klijentskih mreža dozvoljeno kroz default imenski prostor ili već na višoj transportnoj opremi).
Odnosno, dobijamo sljedeću shemu:
L2 tuneli konvergiraju od svih računarskih čvorova do kontrolnog. čvor gdje se nalazi L3 sučelje za ove mreže, svaka u namjenskom imenskom prostoru za izolaciju.
Međutim, zaboravili smo ono najvažnije. Virtuelna mašina mora pružiti uslugu klijentu, odnosno mora imati barem jedno eksterno sučelje preko kojeg se može doći do nje. Odnosno, moramo izaći u vanjski svijet. Ovdje postoje različite opcije. Hajde da uradimo najjednostavniju opciju. Svakom klijentu ćemo dodati jednu mrežu, koja će važiti u mreži provajdera i neće se preklapati sa drugim mrežama. Mreže se također mogu ukrštati i gledati različite VRF-ove na strani mreže provajdera. Mrežni podaci će također živjeti u imenskom prostoru svakog klijenta. Međutim, oni će i dalje izlaziti u vanjski svijet preko jednog fizičkog (ili veze, što je logičnije) sučelja. Da bi se razdvojio klijentski promet, promet koji ide van bit će označen VLAN oznakom dodijeljenom klijentu.
Kao rezultat, dobili smo sljedeću shemu:
Razumno pitanje je zašto ne napraviti gateway na samim računarskim čvorovima? To nije veliki problem, štaviše, kada uključite distribuirani ruter (DVR), on će tako raditi. U ovom scenariju razmatramo najjednostavniju opciju sa centraliziranim gateway-om, koji se po defaultu koristi u Openstacku. Za funkcije visokog opterećenja koristit će i distribuirani ruter i tehnologije ubrzanja kao što su SR-IOV i Passthrough, ali kako kažu, ovo je sasvim druga priča. Prvo, hajde da se pozabavimo osnovnim delom, a zatim ćemo preći na detalje.
Zapravo, naša shema je već operativna, ali postoji nekoliko nijansi:
- Moramo nekako zaštititi naše mašine, odnosno okačiti filter na sučelje prekidača prema klijentu.
- Omogućite automatsko dobijanje ip adrese virtuelnom mašinom tako da ne morate svaki put da je unosite kroz konzolu i propisujete adresu.
Počnimo sa zaštitom automobila. Da biste to učinili, možete koristiti banalni iptables, zašto ne.
Odnosno, sada je naša topologija postala malo složenija:
Idemo dalje. Moramo dodati DHCP server. Najidealnije mjesto za lociranje DHCP servera za svakog od klijenata bio bi već spomenuti kontrolni čvor, gdje se nalaze prostori imena:
Međutim, postoji mali problem. Šta ako se sve ponovo pokrene i sve informacije o zakupu DHCP-a nestanu. Logično je da će mašine dobiti nove adrese, što nije baš zgodno. Postoje dva izlaza - ili koristite imena domena i dodajte DNS server za svakog klijenta, tada nam adresa neće biti bitna (slično mrežnom dijelu u k8s) - ali postoji problem sa vanjskim mrežama, jer adrese može se izdati i u njima putem DHCP-a - potrebna vam je sinhronizacija sa DNS serverima u cloud platformi i eksternim DNS serverom, što, po mom mišljenju, nije baš fleksibilno, ali je sasvim moguće. Ili druga opcija je korištenje metapodataka – to jest, za pohranjivanje informacija o adresi koja je izdata mašini tako da DHCP server zna koju adresu da izda mašini ako je mašina već primila adresu. Druga opcija je jednostavnija i fleksibilnija, jer vam omogućava da sačuvate dodatne informacije o automobilu. Sada dodajmo metapodatke agenta u šemu:
Još jedno pitanje o kojem također vrijedi razgovarati je mogućnost korištenja jedne eksterne mreže od strane svih klijenata, budući da će eksterne mreže, ako moraju biti važeće u cijeloj mreži, biti teške - potrebno je stalno alocirati i kontrolirati dodjelu tih mreža. Mogućnost korištenja jedne eksterne unaprijed konfigurirane mreže za sve klijente bit će vrlo korisna pri kreiranju javnog oblaka. Ovo će olakšati postavljanje mašina jer ne moramo da konsultujemo adresnu bazu podataka i da biramo jedinstveni adresni prostor za spoljnu mrežu svakog klijenta. Osim toga, možemo unaprijed registrirati eksternu mrežu i u vrijeme implementacije trebat ćemo samo povezati vanjske adrese sa klijentskim mašinama.
I tu NAT dolazi u pomoć - jednostavno ćemo omogućiti klijentima da pristupe vanjskom svijetu kroz zadani prostor imena koristeći NAT prijevod. Pa, evo malog problema. Ovo je dobro ako klijentski server radi kao klijent, a ne kao server - odnosno inicira i ne prihvata veze. Ali za nas će biti obrnuto. U ovom slučaju, moramo napraviti odredišni NAT tako da kada se primi promet, kontrolni čvor shvati da je taj promet namijenjen virtuelnoj mašini A klijenta A, što znači da trebamo napraviti NAT translaciju sa eksterne 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, interna izolacija je potpuno očuvana. To jest, treba da uradimo dNAT i sNAT na kontrolnom čvoru. Koristite jednu mrežu sa dodjeljivanjem plutajućih adresa ili eksternih mreža, ili obje odjednom - to je određeno činjenicom da je želite učvrstiti u oblak. Nećemo takođe stavljati plutajuće adrese na dijagram, ali ćemo ostaviti prethodno dodane eksterne mreže - svaki klijent ima svoju eksternu mrežu (na dijagramu su označeni kao vlan 200 i XNUMX na eksternom interfejsu).
Kao rezultat, dobili smo zanimljivo i ujedno dobro osmiš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 sistema. Da biste riješili ovaj problem, morate napraviti najmanje kvorum od 3 čvora. Dodajmo ovo dijagramu:
Naravno, svi čvorovi su sinkronizirani i kada aktivni čvor izađe, drugi čvor će preuzeti njegove dužnosti.
Sljedeći problem su diskovi virtuelnih mašina. Trenutno su pohranjeni na samim hipervizorima, a u slučaju problema s hipervizorom gubimo sve podatke - a prisustvo raida ovdje neće pomoći ako izgubimo ne disk, već cijeli server. Da bismo to učinili, moramo napraviti uslugu koja će djelovati kao frontend za bilo koju pohranu. Kakva će to biti pohrana nije nam posebno važno, ali bi trebalo zaštititi naše podatke od kvara i diska i čvora, a možda i cijelog ormarića. Ovdje postoji nekoliko opcija - naravno, postoje SAN mreže sa Fibre Channel-om, ali budimo iskreni - FC je već relikt prošlosti - analog E1 u transportu - da, slažem se, još uvijek se koristi, ali samo gde je nemoguće bez toga. Stoga ne bih dobrovoljno uveo FC mrežu 2020. godine, znajući da postoje druge interesantnije alternative. Iako je svakom svoje i možda ima onih koji vjeruju da je FC sa svim svojim ograničenjima sve što nam treba - neću se raspravljati, svako ima svoje mišljenje. Ipak, najzanimljivije rješenje po mom mišljenju je korištenje SDS-a, kao što je Ceph.
Ceph vam omogućava da izgradite visoko dostupno rješenje za pohranu s gomilom mogućih redundantnih opcija, od kodova pariteta (slično raid 5 ili 6) do potpune replikacije podataka na različite diskove, uzimajući u obzir lokaciju diskova na serverima i serverima u ormarićima itd.
Potrebna su vam još 3 čvora da napravite Ceph. Interakcija sa spremištem će se također vršiti preko mreže korištenjem usluga za pohranu blokova, objekata i datoteka. Dodajmo prostor za pohranu u šemu:
Napomena: također možete napraviti hiperkonvergirane računske čvorove - ovo je koncept kombiniranja nekoliko funkcija na jednom čvoru - na primjer, skladištenje+računanje - bez izdvajanja posebnih čvorova za ceph pohranu. Dobit ćemo istu shemu otporne na greške - budući da će SDS rezervirati podatke sa nivoom rezervacije koji odredimo. Međutim, hiperkonvergirani čvorovi su uvijek kompromis – budući da čvor za skladištenje ne zagrijava samo zrak kako se čini na prvi pogled (pošto na njemu nema virtuelnih mašina) – on troši CPU resurse na servisiranje SDS-a (u stvari, on radi sve replikacija i oporavak nakon kvarova čvorova, diskova, itd.). Odnosno, izgubit ćete dio računske snage čvora ako ga kombinirate sa pohranom.
Svim ovim stvarima treba nekako upravljati – potrebno nam je nešto preko čega možemo kreirati mašinu, mrežu, virtuelni ruter itd. Da biste to uradili, dodajte servis u kontrolni čvor koji će delovati kao kontrolna tabla – klijent će biti u mogućnosti da se povežete na ovaj portal preko http/ https i uradite sve što treba (pa, skoro).
Kao rezultat, sada imamo sistem otporan na greške. Svim elementima ove infrastrukture se mora nekako upravljati. Prethodno je opisano da je Openstack skup projekata, od kojih svaki pruža neku specifičnu 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 OpenStack-u, Neutron je odgovoran za povezivanje portova virtuelnih mašina na zajedničku L2 mrežu, obezbeđujući usmeravanje saobraćaja između VM-ova koji se nalaze u različitim L2 mrežama, kao i spoljno rutiranje, pružajući usluge kao što su NAT, Floating IP, DHCP, itd.
Rad mrežnog servisa na visokom nivou (osnovni dio) može se opisati na sljedeći način.
Prilikom pokretanja VM-a, mrežni servis:
- Kreira port za ovu VM (ili portove) i obavještava DHCP servis o tome;
- Kreiran je novi virtuelni mrežni uređaj (preko libvirta);
- VM se povezuje na port(ove) kreirane u koraku 1;
Začudo, Neutron je baziran na standardnim mehanizmima poznatim svima koji su ikada zaronili u Linux - to su prostori imena, iptables, linux mostovi, openvswitch, conntrack, itd.
Treba odmah pojasniti da Neutron nije SDN kontroler.
Neutron se sastoji od nekoliko međusobno povezanih komponenti:
openstack-neutron-server je demon koji radi sa korisničkim zahtjevima preko API-ja. Ovaj demon ne upisuje nikakve mrežne veze, ali pruža informacije potrebne za to svojim dodacima, koji zatim konfigurišu željeni mrežni element. Neutron agenti na OpenStack čvorovima su registrovani na Neutron serveru.
Neutron-server je zapravo aplikacija napisana na pythonu, koja se sastoji od dva dijela:
- REST service
- Neutron dodatak (jezgro/usluga)
REST usluga je dizajnirana da prima API pozive od drugih komponenti (na primjer, zahtjev za pružanjem nekih informacija, itd.)
Dodaci su plug-in softverske komponente/moduli koji se pozivaju na zahtjeve API-ja – odnosno dodjeljivanje neke vrste usluge se odvija preko njih. Dodaci su podijeljeni u dvije vrste - servisni i root. Po pravilu, root dodatak je uglavnom odgovoran za upravljanje adresnim prostorom i L2 konekcijama između VM-ova, dok servisni dodaci već pružaju dodatne funkcionalnosti, kao što su VPN ili FW.
Na primjer, može se vidjeti lista trenutno dostupnih dodataka
Može postojati nekoliko servisnih dodataka, ali može postojati samo jedan root dodatak.
openstack-neutron-ml2 je standardni Openstack root dodatak. Ovaj dodatak ima modularnu arhitekturu (za razliku od svog prethodnika) i konfiguriše mrežnu uslugu preko drajvera povezanih na njega. Razmotrit ćemo sam dodatak malo kasnije, jer on zapravo daje fleksibilnost koju OpenStack ima u mrežnom dijelu. Root dodatak se može zamijeniti (npr. Contrail Networking radi takvu zamjenu).
RPC servis (rabbitmq-server) — usluga koja pruža upravljanje redovima čekanja i interakciju sa drugim OpenStack servisima, kao i interakciju između agenata mrežnih usluga.
mrežni agenti - agenti koji se nalaze u svakom čvoru, preko kojih se konfigurišu mrežni servisi.
Agenti su nekoliko vrsta.
Glavni agent je L2 agent. Ovi agenti rade na svakom od hipervizora, uključujući i kontrolne čvorove (tačnije, na svim čvorovima koji pružaju bilo kakvu uslugu za stanare) i njihova glavna funkcija je povezivanje virtuelnih mašina na zajedničku L2 mrežu, kao i generisanje upozorenja kada dođe do bilo kakvih događaja (na primjer onemogućiti/omogućiti port).
Sljedeći, ništa manje važan agent je L3 agent. Podrazumevano, ovaj agent radi isključivo na mrežnom čvoru (često se mrežni čvor kombinuje sa kontrolnim čvorom) i obezbeđuje rutiranje između mreža zakupaca (i između svojih mreža i mreža drugih zakupaca, i dostupan je spoljnom svetu, obezbeđujući NAT, kao i DHCP servis). Međutim, kada se koristi DVR (distribuirani ruter), potreba za L3 dodatkom se pojavljuje i na računarskim čvorovima.
L3 agent koristi Linux imenske prostore kako bi svakom zakupcu pružio skup vlastitih izoliranih mreža i funkcionalnost virtuelnih rutera koji usmjeravaju promet i pružaju usluge pristupnika za mreže sloja 2.
baza podataka - baza podataka identifikatora za mreže, podmreže, portove, bazene, itd.
Zapravo, Neutron prihvata API zahtjeve od kreiranja bilo kojeg mrežnog entiteta, autentifikuje zahtjev i putem RPC-a (ako se odnosi na neku vrstu dodatka ili agenta) ili REST API-ja (ako komunicira u SDN) prenosi agentima (preko dodaci) uputstva potrebna za organizaciju tražene usluge.
Sada se okrenimo probnoj instalaciji (kako se postavlja i šta sadrži, videćemo kasnije u praktičnom delu) i vidimo gde 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 dodatak ML2.
Modularni sloj 2
Kao što je gore spomenuto, dodatak je standardni OpenStack root dodatak i ima modularnu arhitekturu.
Prethodnik dodatka ML2 imao je monolitnu strukturu, što nije dozvoljavalo, 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 dodatak sa svojom arhitekturom.
ML2 ima dvije komponente - dvije vrste drajvera: drajvere tipa i drajvere mehanizma.
Tip drajveri odrediti tehnologije koje će se koristiti za organiziranje mrežnih veza, na primjer VxLAN, VLAN, GRE. Istovremeno, vozač dozvoljava korištenje različitih tehnologija. Standardna tehnologija je VxLAN enkapsulacija za preklapajuće mreže i vanjske vlan mreže.
Tip drajvera su sljedeće vrste mreža:
Stan - 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 pomoću GRE tunela
VxLAN - preklapanje mreže koristeći VxLAN tunele
Vozači mehanizma definiraju sredstva koja obezbjeđuju organizaciju tehnologija navedenih u drajveru tipa - na primjer, openvswitch, sr-iov, opendaylight, OVN, itd.
U zavisnosti od implementacije ovog drajvera, koristiće se ili agenti koje kontroliše Neutron, ili će se koristiti konekcije na eksterni SDN kontroler, koji brine o svim pitanjima organizovanja L2 mreža, rutiranja itd.
Primjer: ako koristimo ML2 zajedno sa OVS-om, tada je L2 agent instaliran na svakom računarskom čvoru koji upravlja OVS-om. Međutim, ako koristimo, na primjer, OVN ili OpenDayLight, onda kontrola OVS-a dolazi u njihovu nadležnost - Neutron preko root plugina daje komande kontroleru, a on već radi ono što mu je rečeno.
Osvježimo memoriju Open vSwitch
U ovom trenutku, jedna od ključnih komponenti OpenStack-a je Open vSwitch.
Kada instalirate OpenStack bez ikakvog dodatnog dobavljača SDN-a kao što je Juniper Contrail ili Nokia Nuage, OVS je glavna mrežna komponenta mreže u oblaku i, zajedno sa iptables, conntrack, imenskim prostorima, omogućava vam da organizujete punopravne mreže sa više zakupaca. Naravno, ova komponenta se može zamijeniti, na primjer, kada se koriste SDN rješenja treće strane (vendor).
OVS je softverski prekidač otvorenog koda dizajniran za korištenje u virtualiziranim okruženjima kao virtuelni 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: U početku, OVS nije bio zamišljen kao softswitch za telekomunikacione funkcije visokog opterećenja i više je bio dizajniran za manje zahtjevne IT funkcije kao što su WEB server ili server pošte. Međutim, OVS je u fazi finalizacije i trenutne implementacije OVS-a su uvelike poboljšale njegove performanse i mogućnosti, što omogućava da ga koriste telekom operateri sa visoko opterećenim funkcijama, na primjer, postoji implementacija OVS-a sa podrškom za DPDK ubrzanje.
Treba imati na umu tri važne komponente OVS-a:
- Kernel modul — komponenta koja se nalazi u prostoru kernela koja obrađuje saobraćaj na osnovu pravila primljenih od kontrolnog elementa;
- vSwitch daemon (ovs-vswitchd) je proces pokrenut u korisničkom prostoru koji je odgovoran za programiranje modula kernela - odnosno direktno predstavlja logiku rada prekidača
- Server baze podataka je lokalna baza podataka koja se nalazi na svakom hostu koji radi OVS i koja pohranjuje konfiguraciju. Preko ovog modula, SDN kontroleri mogu komunicirati koristeći OVSDB protokol.
Sve ovo je popraćeno skupom dijagnostičkih i upravljačkih programa, kao što su ovs-vsctl, ovs-appctl, ovs-ofctl, itd.
Trenutno Openstack naširoko koriste telekom operateri za migraciju mrežnih funkcija na njega, kao što su EPC, SBC, HLR, itd. Neke funkcije mogu živjeti bez problema sa OVS-om u obliku u kojem jeste, ali npr. EPC procesi pretplatnički promet - tada prolazi kroz ogromnu količinu prometa (sada obim prometa dostiže nekoliko stotina gigabita u sekundi). Naravno, vožnja takvog saobraćaja kroz prostor kernela (pošto se prosleđivač tamo nalazi po defaultu) nije najbolja ideja. Stoga se OVS često postavlja u potpunosti u korisničkom prostoru koristeći DPDK tehnologiju ubrzanja za prosljeđivanje prometa od NIC-a do korisničkog prostora zaobilazeći kernel.
Napomena: za oblak raspoređen za telekomunikacione funkcije, moguće je emitovati saobraćaj sa računarskih čvorova zaobilazeći OVS direktno na komutatorsku opremu. U tu svrhu koriste se SR-IOV i Passthrough mehanizmi.
Kako to funkcionira na stvarnom rasporedu?
Pa, idemo sada na praktični dio i vidjeti kako to sve funkcionira u praksi.
Prvo, postavimo jednostavnu Openstack instalaciju. Pošto nemam pri ruci set servera za eksperimente, sastavit ćemo raspored na jednom fizičkom serveru sa virtuelnih mašina. Da, naravno, takvo rješenje nije prikladno za komercijalne svrhe, ali da vidite kako mreža radi u Openstacku, takva instalacija je dovoljna za oči. Štoviše, takva instalacija za potrebe obuke je još zanimljivija - jer možete uhvatiti promet itd.
S obzirom da trebamo vidjeti samo osnovni dio, ne možemo koristiti nekoliko mreža, već sve podići koristeći samo dvije mreže, a druga mreža u ovom rasporedu će se koristiti isključivo za pristup undercloud i dns serveru. Za sada se nećemo doticati vanjskih mreža - ovo je tema za poseban veliki članak.
Dakle, počnimo redom. Prvo, malo teorije. Openstack ćemo instalirati koristeći TripleO (Openstack na Openstack). Suština TripleO-a je da instaliramo Openstack sve-u-jednom (to jest, na jednom čvoru), koji se zove undercloud, a zatim koristimo mogućnosti raspoređenog Openstacka za instaliranje Openstack-a, dizajniranog za eksploataciju, koji se zove overcloud. Undercloud će koristiti svoju sposobnost upravljanja fizičkim serverima (goli metal) - projekat Ironic - da obezbedi hipervizore koji će delovati kao računarski, kontrolni i skladišni čvorovi. Odnosno, ne koristimo nikakve alate treće strane za implementaciju Openstack-a - mi implementiramo Openstack koristeći Openstack. Dalje uz instalaciju biće mnogo jasnije, tako da nećemo stati na tome i nastaviti dalje.
Napomena: U ovom članku, radi jednostavnosti, nisam koristio mrežnu izolaciju za interne mreže Openstack-a, već se sve postavlja koristeći samo jednu mrežu. Međutim, prisustvo ili odsustvo mrežne izolacije ne utiče na osnovnu funkcionalnost rješenja - sve će raditi potpuno isto kao i kada se koristi izolacija, ali će promet ići na istu mrežu. Za komercijalnu instalaciju, prirodno je potrebno koristiti izolaciju koristeći različite vlan-ove i sučelja. Na primjer, promet upravljanja ceph pohranom i direktni promet podataka (mašinski pristupi diskovima, itd.) koriste različite podmreže (upravljanje pohranom i skladište) tokom izolacije, a to vam omogućava da rješenje učinite otpornijim na greške tako što ćete podijeliti ovaj promet, za na primjer, u različite portove, ili koristiti različite QoS profile za različit promet tako da promet podataka ne istiskuje promet signalizacije. U našem slučaju, oni će ići na istu mrežu i to nas zapravo ni na koji način ne ograničava.
Napomena: Pošto ćemo pokretati virtuelne mašine u okruženju zasnovanom na virtuelnoj mašini, prvo moramo da omogućimo ugnežđenu virtuelizaciju.
Možete provjeriti da li je 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ćite podršku za ugniježđenu virtualizaciju prema bilo kojem vodiču koji pronađete na mreži, na primjer .
Moramo sastaviti sljedeću šemu sa virtuelnih mašina:
U mom slučaju, za povezivanje virtuelnih mašina koje su deo buduće instalacije (a dobio sam ih 7, ali možete proći i sa 4 ako nemate puno resursa), koristio sam OpenvSwitch. Napravio sam jedan ovs bridge i povezao virtuelne mašine na njega preko port-grupa. Da to uradim, kreirao sam xml fajl sledećeg oblika:
[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 portova - dva pristupa i jedan trunk (potonji je bio potreban za DNS server, ali možete i bez njega, ili ga podići na host stroju - kako vam više odgovara). Zatim, koristeći ovaj predložak, deklariramo naše kroz 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 konfiguraciju portova 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 ovs-br1 portu neće biti dostupna, jer nema vlan oznaku. Da biste ovo popravili, morate izdati naredbu sudo ovs-vsctl set port ovs-br1 tag=100. Međutim, nakon ponovnog pokretanja, ova oznaka će nestati (ako neko zna kako da ostane na svom mjestu, bit ću vrlo zahvalan). Ali to nije toliko važno, jer će nam ova adresa biti potrebna samo tokom instalacije i neće biti potrebna kada se Openstack u potpunosti implementira.
Zatim kreirajte mašinu u oblaku:
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=ttyS0Tokom instalacije postavljate sve potrebne parametre, kao što su naziv mašine, lozinke, korisnici, ntp serveri itd. Možete odmah konfigurisati portove, ali meni lično je lakše nakon instalacije da se ulogujem na mašinu preko konzole i ispravim potrebne datoteke. Ako već imate gotovu sliku, možete je koristiti ili učiniti kao što sam ja uradio - preuzmite minimalnu sliku Centos 7 i koristite je za instalaciju VM-a.
Nakon uspješne instalacije, trebali biste imati virtuelnu mašinu na koju možete instalirati undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPrvo ugrađujemo potrebne alate tokom procesa instalacije:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud instalacija
Kreiramo korisnika steka, postavljamo lozinku, dodajemo je u sudoer i dajemo mu mogućnost da izvršava root komande 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 puno undercloud ime u datoteci hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Zatim dodajte spremišta i instalirajte 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 da instalirate ceph, onda ne morate unositi komande vezane za ceph. Koristio sam izdanje Queensa, ali možete koristiti šta god želite.
Zatim kopirajte konfiguracijsku datoteku undercloud u kućni direktorij korisnika steka:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSada moramo popraviti ovu datoteku, prilagođavajući je našoj instalaciji.
Dodajte sljedeće redove 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, idemo kroz postavke:
undercloud_hostname - puno ime undercloud servera, mora odgovarati unosu na DNS serveru
lokalni_ip - lokalna adresa undercloud prema mrežnom obezbjeđivanju
network_gateway - ista lokalna adresa, koja će služiti kao gateway za pristup vanjskom svijetu tokom instalacije overcloud čvorova, također odgovara lokalnom IP-u
undercloud_public_host - eksterna API adresa, dodjeljuje se svaka slobodna adresa iz mreže za obezbjeđivanje
undercloud_admin_host adresa internog API-ja, dodjeljuje se svaka slobodna adresa iz mreže za obezbjeđivanje
undercloud_nameservers - DNS server
generate_service_certificate - ova linija je vrlo važna u trenutnom primjeru, jer ako je ne postavite na false dobit ćete grešku tokom instalacije, problem je opisan na Red Hat praćenju grešaka
lokalno_sučelje sučelje na mreži za proviziju. Ovo sučelje će biti rekonfigurirano tokom implementacije undercloud-a, tako da morate imati dva sučelja na undercloud-u - jedno za pristup njemu, drugo za obezbjeđivanje
local_mtu — MTU. Pošto imamo testnu laboratoriju i imam MTU 1500 na OVS portovima sviča, potrebno ga je podesiti na 1450 kako bi paketi inkapsulirani u VxLAN prošli
network_cidr — mreže za opskrbu
masquerade - korištenje NAT-a za pristup vanjskoj mreži
masquerade_network - mreža koja će biti NAT-Xia
dhcp_start - početnu adresu spremišta adresa iz koje će adrese biti dodijeljene čvorovima tokom implementacije prekomjernog oblaka
dhcp_end — konačnu adresu skupa adresa iz koje će adrese biti dodijeljene čvorovima tokom implementacije prekomjernog oblaka
inspection_iprange - skup adresa potrebnih za introspekciju (ne bi trebalo da se preklapa sa gornjim skupom)
scheduler_max_attempts — maksimalan broj pokušaja instaliranja overclouda (mora biti veći ili jednak broju čvorova)
Nakon što je datoteka opisana, možete izdati naredbu za implementaciju undercloud-a:
openstack undercloud install
Postupak traje od 10 do 30 minuta u zavisnosti od vaše pegle. Na kraju, trebali biste vidjeti ovakav izlaz:
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 preći na instalaciju overclouda.
Ako pogledate ifconfig izlaz, vidjet ćete da se pojavio novi bridge interfejs
[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 0Preko ovog interfejsa će se sada raditi na implementaciji overclouda.
Iz donjeg izlaza možete vidjeti da imamo sve usluge na istom č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 mrežnog dijela ispod oblaka:
(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 undercloud, a nemamo dovoljno čvorova iz kojih će se izgraditi overcloud. Stoga je prvi korak implementacija virtuelnih mašina koje su nam potrebne. Tokom implementacije, sam undercloud će instalirati OS i neophodan softver na overcloud mašine - to jest, ne moramo u potpunosti da implementiramo mašinu, već samo kreiramo disk (ili diskove) za nju i odredimo njene parametre - odnosno, u stvari dobijamo goli server bez instaliranog OS-a na njemu.
Idite u fasciklu sa diskovima naših virtuelnih mašina i kreirajte 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 160GPošto radimo kao root, moramo promijeniti vlasnika ovih diskova kako ne bismo imali problem 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 da instalirate ceph da biste ga proučavali, onda komande ne kreiraju najmanje 3 čvora sa najmanje dva diska, već u šablonu označavaju da će se koristiti virtuelni diskovi vda, vdb itd.
Odlično, sada moramo definirati sve ove mašine:
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 se nalaze naredbe - print-xml > /tmp/storage-1.xml, koja kreira xml fajl sa opisom svake mašine u /tmp/ folderu, ako ga ne dodate nećete moći za definisanje virtuelnih mašina.
Sada moramo definisati sve ove mašine u virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Sada mala nijansa - tripleO koristi IPMI za upravljanje serverima tokom instalacije i introspekcije.
Introspekcija je proces inspekcije hardvera kako bi se dobili njegovi parametri potrebni za dalje obezbjeđivanje čvora. Introspekcija se vrši uz pomoć ironic, servisa dizajniranog za rad sa golim metalnim serverima.
Ali evo problema - dok hardverski IPMI serveri imaju poseban port (ili zajednički port, ali to nije važno), virtuelne mašine nemaju takve portove. Ovdje nam u pomoć dolazi štaka pod nazivom vbmc - uslužni program koji vam omogućava da emulirate IPMI port. Ovu nijansu vrijedi obratiti pažnju posebno za one koji žele postaviti takav laboratorij na ESXI hipervizor - da budem iskren, ne znam da li ima analog od vbmc-a, pa se vrijedi zapitati o ovom problemu prije nego što sve implementirate .
Instaliraj 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 nema servera na vbmc listi
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Da bi se pojavile, moraju se ručno deklarirati na ovaj način:
[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 DOWN. Da bi se prebacili u status UP, potrebno ih je 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 - morate popraviti pravila zaštitnog zida (pa, ili ga potpuno isključ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 da li sve radi. Adresa host mašine je 192.168.255.200, na undercloud smo dodali neophodan ipmitool paket tokom 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 preko vbmc-a. Sada ga isključite i nastavite 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 postavljen 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 serverima, datoteka specificira port na kojem vbmc radi za svaku od mašina.
[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 interfejsa, ali u ovom slučaju to nije važno, u ovoj instalaciji će nam jedan biti dovoljan.
Sada pripremamo json fajl. Moramo navesti mak adresu porta preko kojeg će se vršiti provizija, parametre čvorova, dati im imena i naznačiti kako doći do ipmi-a:
{
"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 wget-a 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 ~]$Otpremite slike 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 ~]$Provjerite 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š jedan dodir - potrebno je da dodate dns server:
(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 narediti 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 izlaza, sve je završeno bez grešaka. Provjerite 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, kojim se obično može upravljati, onda je nešto pošlo po zlu i morate pogledati dnevnik da shvatite zašto se to dogodilo. Imajte na umu da u ovom scenariju koristimo virtualizaciju i da mogu postojati greške povezane s korištenjem virtualnih strojeva ili vbmc-a.
Zatim moramo odrediti koji će čvor obavljati koju funkciju - to jest, navesti profil s kojim će se čvor rasporediti:
(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 ~]$Odredite 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-d9afb69d1167Provjeravamo da li smo sve uradili kako treba:
(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 implementaciju 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 pravoj instalaciji će se prirodno koristiti prilagođeni predlošci, u našem slučaju to će uvelike zakomplicirati proces, jer će svako uređivanje šablona morati biti objašnjeno. Kao što je ranije napisano, čak i jednostavna instalacija bit će nam dovoljna da vidimo kako funkcionira.
Napomena: --libvirt-type qemu varijabla je potrebna u ovom slučaju jer ćemo koristiti ugniježđenu virtuelizaciju. U suprotnom, nećete pokretati virtuelne mašine.
Sada imate oko sat vremena, ili možda više (u zavisnosti od mogućnosti pegle) i možete se samo nadati da ćete nakon tog vremena vidjeti ovaj natpis:
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 punu verziju otvorenog steka, na kojoj možete učiti, eksperimentirati itd.
Hajde da proverimo da li sve radi kako treba. U steku kućnog direktorija korisnika postoje dva fajla - jedan stackrc (za upravljanje undercloud) i drugi overcloudrc (za upravljanje overcloud). Ove datoteke moraju biti specificirane kao izvor, jer sadrže informacije potrebne za autentifikaciju.
(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 ~]$Mojoj instalaciji još uvijek treba jedan mali dodir - da dodam rutu na kontroler, pošto je mašina s kojom radim na drugoj mreži. Da biste to učinili, idite na control-1 pod računom administratora topline i napišite 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 na horizont. Sve informacije - adrese, login i lozinka - nalaze se u datoteci /home/stack/overcloudrc. Konačni dijagram izgleda ovako:
Inače, u našoj instalaciji adrese mašina su se izdavale preko DHCP-a, a kao što vidite, izdaju se „bilo kako“. Možete hardkodirati u šablonu koja adresa treba da bude prikačena kojoj mašini tokom implementacije, ako vam je potrebna.
Kako promet teče između virtuelnih mašina?
U ovom članku ćemo pogledati tri opcije za propuštanje saobraćaja
- Dvije mašine na jednom hipervizoru na jednoj L2 mreži
- Dvije mašine na različitim hipervizorima u istoj L2 mreži
- Dvije mašine na različitim mrežama (root na više mreža)
Slučajevi sa pristupom vanjskom svijetu preko eksterne mreže, korištenjem plutajućih adresa, kao i distribuiranog rutiranja, bit će razmatrani sljedeći put, za sada ćemo se fokusirati na interni promet.
Da provjerimo, sastavimo sljedeći dijagram:
Napravili smo 4 virtuelne mašine - 3 u istoj L2 mreži - net-1, i još 1 u 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 hipervizorima se nalaze kreirane mašine:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Mašine vm-1 i vm-3 nalaze se na compute-0, mašine vm-2 i vm-4 se nalaze na čvoru compute-1.
Osim toga, kreiran je virtuelni ruter koji omogućava 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 ~]$ Ruter ima dva virtuelna porta koji služe 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 pogledamo kako se odvija promet, pogledajmo šta trenutno imamo na kontrolnom čvoru (koji je također mrežni čvor) i na računarskom čvoru. Počnimo sa računarskim č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 ~]$Trenutno postoje tri ovs mosta na čvoru — br-int, br-tun, br-ex. Između njih, kao što vidimo, postoji skup interfejsa. Radi lakšeg razumijevanja, ucrtajmo sva ova sučelja na dijagram i vidimo šta će se dogoditi.
Iz adresa na koje se podižu VxLAN tuneli, može se vidjeti da je jedan tunel podignut na compute-1 (192.168.255.26), drugi tunel gleda 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 smanjiti 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 se može vidjeti iz izlaza, adresa je pričvršćena direktno na fizički port, a ne na interfejs virtuelnog 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 luke mora biti odbačeno.
Zapravo, trenutno više nema odakle da dolazi saobraćaj na ovaj most osim sa ovog interfejsa (interfejsa sa br-int), a sudeći po padovima, BUM saobraćaj je već preleteo na most.
To jest, saobraćaj iz ovog čvora može otići samo kroz VxLAN tunel i ništa više. Međutim, ako uključite DVR, situacija će se promijeniti, ali ćemo se time pozabaviti nekom drugom prilikom. Kada koristite mrežnu izolaciju, na primjer, koristeći vlans, nećete imati jedno L3 sučelje u 0. vlanu, već nekoliko sučelja. Međutim, VxLAN saobraćaj će izaći iz čvora na potpuno isti način, ali takođe inkapsuliran u nekom namenskom vlan-u.
Shvatili smo računski čvor, idite 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, međutim, ip adresa više nije na fizičkom interfejsu, već na virtuelnom mostu. Ovo je učinjeno jer je ova luka luka kroz koju će saobraćaj ići 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 vezan za br-ex most i pošto nema nijednu vlan oznaku, ovaj port je trunk port na kojem su dozvoljeni svi vlanovi, sada saobraćaj ide van bez oznake, što pokazuje vlan-id 0 u izlaz iznad.
Sve ostalo je trenutno slično računarskom čvoru - isti mostovi, isti tuneli koji vode do dva računarska čvora.
U ovom članku nećemo razmatrati čvorove za skladištenje, ali za razumijevanje potrebno je reći da je mrežni dio ovih čvorova banalan za sramotu. U našem slučaju postoji samo jedan fizički port (eth0) kojem je dodijeljena ip adresa i to je to. Nema VxLAN tunela, tunelskih mostova itd - nema ovs-a, jer nema smisla. Kada koristite mrežnu izolaciju - ovaj čvor će imati dva interfejsa (fizički portovi, bodns ili samo dva vlan-a - nije bitno - zavisi šta želite) - jedno za kontrolu, drugo za saobraćaj (zapisivanje na VM disk , čitanje sa diska itd.).
Shvatili smo šta imamo na čvorovima u nedostatku ikakvih usluga. Sada pokrenimo 4 virtuelne mašine i vidimo kako se menja gore opisana šema - trebalo bi da imamo portove, virtuelne rutere itd.
Do sada naša mreža izgleda ovako:
Imamo dvije virtuelne mašine na svakom računarskom č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 ~]$ Mašina ima samo jedan virtuelni interfejs - 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 ~]$
Ovaj interfejs izgleda kao linux most:
[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 interfejsa u mostu - tap95d96a75-a0 i qvb95d96a75-a0.
Ovdje se vrijedi malo zadržati na vrstama virtualnih mrežnih uređaja u OpenStacku:
vtap - virtuelni interfejs povezan sa instancom (VM)
qbr - Linux most
qvb i qvo - vEth par povezan na Linux most i Open vSwitch most
br-int, br-tun, br-vlan - Otvoreni vSwitch mostovi
patch-, int-br-, phy-br- — Otvoreni vSwitch patch interfejsi koji povezuju mostove
qg, qr, ha, fg, sg - Otvoreni vSwitch portovi koje koriste virtuelni uređaji za povezivanje na OVS
Kao što razumete, ako imamo qvb95d96a75-a0 port u mostu, koji je vEth par, onda negde postoji njegov pandan, koji bi se logično trebao zvati qvo95d96a75-a0. Gledamo koji su portovi na OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kao što vidimo port je u br-int. Br-int djeluje kao prekidač koji završava portove virtuelne mašine. Pored qvo95d96a75-a0, port qvo5bd37136-47 je vidljiv u izlazu. Ovo je port za drugu virtuelnu mašinu. Kao rezultat toga, naša shema sada izgleda ovako:
Pitanje koje bi odmah trebalo da zanima pažljivog čitaoca je koji je linux most između porta virtuelne mašine i OVS porta? Činjenica je da se za zaštitu mašine koriste sigurnosne grupe, koje nisu ništa drugo do iptables. OVS ne radi sa iptablesom, pa je takva „štaka“ izmišljena. Međutim, on postaje zastario - zamjenjuje ga conntrack u novim izdanjima.
Odnosno, na kraju, shema izgleda ovako:
Dvije mašine na jednom hipervizoru na jednoj L2 mreži
Budući da su ova dva VM-a u istoj L2 mreži i na istom hipervizoru, bit će logično da promet između njih ide lokalno preko br-inta, jer će oba stroja biti u 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 ~]$ Dvije mašine na različitim hipervizorima u istoj L2 mreži
Sada da vidimo kako će se promet odvijati između dvije mašine u istoj L2 mreži, ali smještene na različitim hipervizorima. Da budem iskren, ništa se neće mnogo promeniti, samo će saobraćaj između hipervizora ići kroz vxlan tunel. Pogledajmo primjer.
Adrese virtuelnih mašina između kojih ćemo pratiti saobraćaj:
[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 tabelu 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 ~]Saobraćaj bi trebao ići na port 2 - pogledajte koji je to port:
[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, interfejs u br-tun. Da vidimo šta se dešava sa 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 pakuje u VxLAN i šalje na port 2. Gledamo kuda vodi port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$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 šta se dalje dešava sa 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 ~]$ Poppy se nalazi u br-int tabeli prosljeđivanja na compute-1, i kao što možete vidjeti iz izlaza iznad, vidljiv je kroz port 2, a to su portovi 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 postoji odredišni mak u br-int na compute-1:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Odnosno, primljeni paket će letjeti na port 3, iza kojeg već postoji virtualna mašina instance-00000003.
Ljepota implementacije Openstack-a za proučavanje na virtuelnoj infrastrukturi je u tome što lako možemo uhvatiti promet između hipervizora i vidjeti šta će se s njim dogoditi. 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 red pokazuje da paket sa adrese 10.0.1.85 ide na adresu 10.0.1.88 (ICMP saobraćaj), i da je umotan u VxLAN paket sa vni 22 i paket ide od hosta 192.168.255.19 (compute-0) do hosta 192.168.255.26 (računaj-1). Možemo provjeriti da li se VNI podudara s onim navedenim u ovs.
Vratimo se na ovu liniju actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 je vni u heksadecimalnom brojevnom sistemu. Pretvorimo ovaj broj u 16. sistem:
16 = 6*16^0+1*16^1 = 6+16 = 22To jest, vni je istina.
Drugi red pokazuje obrnuti saobraćaj, pa, tu nema smisla objašnjavati, pa je sve jasno.
Dvije mašine na različitim mrežama (usmjeravanje između mreža)
Posljednji slučaj za danas je rutiranje između mreža unutar istog projekta pomoću virtualnog rutera. Razmatramo slučaj bez DVR-a (razmotrit ćemo ga u drugom članku), tako da se usmjeravanje odvija na mrežnom čvoru. U našem slučaju, mrežni čvor nije zaseban entitet i nalazi se na kontrolnom čvoru.
Prvo, da vidimo da rutiranje funkcionira:
$ 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 bi u ovom slučaju paket trebao otići do gatewaya i tamo biti preusmjeren, moramo saznati mak adresu gatewaya, za što ćemo pogledati 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 promet treba biti poslat sa odredištem (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 kuda vodi port 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, saobraćaj ide na br-tun. Hajde 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 ~]$ Saobraćaj je odleteo do kontrolnog čvora, pa moramo otići do njega i videti kako će se rutiranje odvijati.
Kao što se sećate, kontrolni čvor iznutra je izgledao potpuno isto kao i računarski čvor - ista tri mosta, samo br-ex je imao fizički port kroz koji je čvor mogao da šalje saobraćaj napolje. Kreiranje instanci je promijenilo konfiguraciju na računarskim čvorovima - linux bridge, iptables i interfejsi su dodati čvorovima. Kreiranje mreža i virtuelnog rutera takođe je ostavilo traga na konfiguraciji kontrolnog čvora.
Dakle, očigledno, maka adresa gatewaya bi trebala biti u br-int tablici prosljeđivanja na kontrolnom čvoru. Hajde da proverimo da li je tu i gde izgleda:
[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 sa porta qr-0c52b15f-8f. Vraćajući se na listu virtuelnih portova u Openstack-u, ovaj tip porta se koristi za povezivanje različitih virtuelnih uređaja na OVS. Da budemo precizniji, qr je port prema virtuelnom ruteru, koji je predstavljen kao imenski prostor.
Hajde da vidimo koji je imenski prostor na serveru:
[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 ~]$ Postoje tri kopije. No, sudeći po imenima, možete pogoditi svrhu svakog od njih. Kasnije ćemo se vratiti na instance sa 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 kreirali ranije. Oba virtuelna porta su dodana u br-int. Provjerimo mac adresu porta qr-0c52b15f-8f, pošto je promet, sudeći po odredišnoj mac adresi, išao na ovaj interfejs.
[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 ~]$ Odnosno, u ovom slučaju sve radi po zakonima standardnog rutiranja. Pošto je saobraćaj namenjen hostu 10.0.2.8, on mora izaći kroz drugo sučelje qr-92fa49b5-54 i proći kroz vxlan tunel do računarskog č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. Gledamo odakle je u br-intu vidljiva mak adresa hosta 10.0.2.8:
[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 ~]$ Saobraćaj očekivano ide na br-tun, da vidimo u koji tunel će saobraćaj dalje:
[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 ~]$ Saobraćaj ide u tunel da bi izračunao-1. Pa, na compute-1, sve je jednostavno - od br-tun paket dolazi do br-int i odatle do interfejsa virtuelne mašine:
[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 da li je ovo zaista ispravan interfejs:
[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 put paketa. Mislim da ste primetili da je saobraćaj prolazio kroz različite vxlan tunele i izlazio sa različitim VNI-ovima. Hajde da vidimo šta su VNI, nakon čega ćemo prikupiti dump na kontrolnom portu čvora i uveriti se da promet ide tačno kako je gore opisano.
Dakle, tunel za compute-0 ima sljedeće akcije=učitavanje:0->NXM_OF_VLAN_TCI[],učitavanje:0x16->NXM_NX_TUN_ID[],izlaz:3. Hajde da prevedemo 0x16 u decimalni brojevni sistem:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel za compute-1 ima sljedeće VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Hajde da prevedemo 0x63 u decimalni brojevni sistem:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Pa, da vidimo sad dump:
[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) sa vni 22, unutar kojeg je ICMP paket upakovan od hosta 10.0.1.85 do hosta 10.0.2.8. Kao što smo izračunali iznad, 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) sa 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 iznad, vni odgovara onome što smo vidjeli u izlazu.
Sljedeća dva paketa su povratni promet od 10.0.2.8, a ne od 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 pričali o arhitekturi cloud platforme, bilo bi dobro kada bi mašine primale adrese automatski od DHCP servera. Ovo su dva DHCP servera za naše dvije mreže 10.0.1.0/24 i 10.0.2.0/24.
Hajde da proverimo da li je to tako. U ovom imenskom prostoru postoji samo jedna adresa - 10.0.1.1 - adresa samog DHCP servera, a takođe 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 da li procesi koji sadrže 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 osnovu informacija predstavljenih u izlazu iznad, možemo, na primjer, vidjeti šta trenutno imamo na zakupu:
[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, dobijamo sljedeći skup usluga na kontrolnom čvoru:
Pa, imajte na umu - ovo je samo - 4 mašine, 2 interne mreže i jedan virtuelni ruter... Mi ovde sada nemamo eksterne mreže, hrpe različitih projekata, svaki sa svojim mrežama (ukrštanjem), a imamo distribuirani ruter se isključio, ali je na kraju na kraju ostao samo jedan kontrolni čvor u testnom stolu (za toleranciju greške mora postojati kvorum od tri čvora). Logično je da je u trgovini sve “malo” komplikovanije, ali u ovom jednostavnom primjeru razumijemo kako bi to trebalo funkcionirati – da li imate 3 ili 300 imenskih prostora je naravno važno, ali sa stanovišta rada cijelu strukturu, ništa se neće bitno promijeniti... iako za sada ne uključujete SDN nekog dobavljača. Ali to je sasvim druga priča.
Nadam se da je bilo zanimljivo. Ako ima komentara/dopuna, ili negdje sam iskreno lagao (ja sam osoba i moje mišljenje će uvijek biti subjektivno) - napišite šta treba ispraviti / dodati - sve ćemo popraviti / dodati.
U zaključku, želio bih reći nekoliko riječi o poređenju Openstack-a (i vanile i dobavljača) sa VMWare-ovim rješenjem u oblaku - ovo pitanje su mi postavljali prečesto u posljednjih nekoliko godina i već sam se, iskreno, umorio od toga. , ali ipak. Po mom mišljenju, vrlo je teško porediti ova dva rješenja, ali definitivno možemo reći da u oba rješenja postoje nedostaci, a pri odabiru jednog rješenja potrebno je odvagnuti sve za i protiv.
Ako je OpenStack rješenje vođeno zajednici, onda VMWare ima pravo da radi samo ono što želi (čitaj – ono što mu koristi) i to je logično – jer je to komercijalna kompanija koja je navikla da zarađuje od svojih kupaca. Ali postoji jedno veliko i debelo ALI - možete napustiti OpenStack, na primjer, iz Nokie i prebaciti se na rješenje sa, na primjer, Juniper (Contrail Cloud), ali je malo vjerovatno da ćete izaći iz VMWarea. Za mene ova dva rješenja izgledaju ovako - Openstack (vendor) je jednostavan kavez u koji vas stavlja, ali imate ključ i možete otići u bilo koje vrijeme. VMWare je zlatni kavez, ključ od kaveza je kod vlasnika i koštaće vas mnogo.
Ne zalažem se ni za prvi ni za drugi proizvod - vi birate šta vam treba. Ali da imam takav izbor, odabrao bih oba rješenja - VMWare za IT oblak (malo opterećenje, jednostavno upravljanje), OpenStack od nekog proizvođača (Nokia i Juniper pružaju vrlo dobra rješenja ključ u ruke) - za Telecom oblak. Ne bih koristio Openstack za čisti IT - to je kao pucanje vrapca iz topa, ali ne vidim nikakve kontraindikacije za korištenje osim redundancije. Međutim, korištenje VMWare-a u telekomunikacijama je poput tegljenja drobljenog kamena u Ford Raptoru - to je lijepo izvana, ali vozač mora napraviti 10 putovanja umjesto jednog.
Po mom mišljenju, najveći nedostatak VMWare-a je njegova potpuna bliskost – kompanija vam neće dati nikakvu informaciju o tome kako radi, na primjer, vSAN ili šta je u jezgri hipervizora – to joj jednostavno nije isplativo – tj. nikada nećete postati stručnjak za VMWare - bez podrške dobavljača, osuđeni ste na propast (vrlo često srećem VMWare stručnjake koji su zbunjeni banalnim pitanjima). Za mene VMWare kupuje auto sa zaključanom haubom - da, možda imate stručnjake koji mogu promijeniti zupčasti kaiš, ali samo osoba koja vam je prodala ovo rješenje moći će otvoriti haubu. Lično, ne volim odluke u koje se ne mogu uklopiti. Reći ćete da možda nećete morati ići ispod haube. Da, to je moguće, ali pogledaću vas kada budete trebali prikupiti veliku funkciju u oblaku od 20-30 virtuelnih mašina, 40-50 mreža, od kojih polovina želi da izađe napolje, a druga polovina traži SR -IOV ubrzanje inače će vam trebati još par desetina ovih mašina - inače performanse neće biti dovoljne.
Postoje i druge tačke gledišta, tako da je na vama da odlučite šta ćete izabrati, a što je najvažnije, tada ćete biti odgovorni za svoj izbor. Ovo je samo moje mišljenje - osoba koja je vidjela i dodirnula najmanje 4 proizvoda - Nokia, Juniper, Red Hat i VMWare. Tako da imam šta da uporedim.
izvor: www.habr.com