Oblačno računarstvo sve više prodire u naš život i sigurno nema osobe koja barem jednom nije koristila neke oblake usluge. Međutim, što je zapravo oblak i kako on funkcionira većini ljudi ostaje nejasno, čak i na nivo ideje. 5G postaje stvarnost i telekomunikacijska infrastruktura počinje prelaziti s tradicionalnih rješenja na oblačna, baš kao što se nekada prelazilo s potpuno hardverskih rješenja na virtualizirane "stubove".
Danas ćemo razgovarati o unutarnjem svijetu oblačne infrastrukture, posebno ćemo razraditi osnove mrežne komponente.
Što je oblak? Je li to virtualizacija – samo drugačiji pogled?
Više nego logično pitanje. Ne – to nije virtualizacija, iako se ne može izbjeći. Razmotrit ćemo dva definicije:
Oblačno računarstvo (dalje Oblačno) — to je model pružanja korisničkog pristupa distribuisanim računalnim resursima koji se moraju rasporediti i pokrenuti na zahtjev s minimalnim kašnjenjem i minimalnim troškovima za pružatelja usluga.
Virtualizacija — to je mogućnost dijeljenja jedne fizičke jedinke (na primjer server) na nekoliko virtualnih, čime se povećava iskorištenje resursa (na primjer, imali ste 3 servera opterećena 25-30 posto, a nakon virtualizacije dobivate 1 server opterećen 80-90 posto). Naravno, virtualizacija zauzima određeni dio resursa — morate održavati hipervizor, no, kako pokazuje praksa, igra vrijedi truda. Savršen primjer virtualizacije je VMWare, koja odlično priprema virtualne mašine, ili, na primjer, KVM, koji mi se više sviđa, ali to je već stvar ukusa.
Virtualizaciju koristimo ne primjećujući je, pa čak i hardverski usmjerivači već koriste virtualizaciju — na primjer, u najnovijim verzijama JunOS operativnog sistema instalira se kao virtuelna mašina iznad real-time linux distribucije (Wind River 9). No, virtualizacija nije oblak, ali oblak ne može postojati bez virtualizacije.
Virtualizacija je jedna od građevinskih blokova na kojima se gradi oblak.
Izgradnja oblaka samo spajanjem nekoliko hipervizora u jedan L2 domen, dodavanjem nekoliko yaml skripti za automatsko podešavanje VLAN-ova putem nekog ansible alata i korištenjem nečega poput sustava orkestracije za automatsko kreiranje virtualnih mašina — nije moguće. Tačnije, moguće je, ali rezultat bi bio Frankenskein — nije to oblak koji nam je potreban, iako možda za nekoga to može biti san. Uz to, ako uzmemo OpenStack — to je takođe pravi Frankenskein, ali ostavimo to za kasnije.
Ali razumijem da iz prethodne definicije nije potpuno jasno što se zapravo može nazvati oblakom.
Stoga su u dokumentu NIST-a (Nacionalni institut za standarde i tehnologiju) navedene 5 osnovnih karakteristika koje bi infrastruktura oblaka trebala imati:
Usluga na zahtjev. Korisniku bi trebao biti omogućen slobodan pristup dodijeljenim računalnim resursima (kao što su mreže, virtualni diskovi, memorija, jezgre procesora itd.), a ti resursi trebaju biti dodijeljeni automatski — bez intervencije pružatelja usluga.
Široka dostupnost usluga. Pristup resursima treba biti omogućen standardnim mehanizmima kako bi se omogućila korištenja standardnih računala, tankih klijenata i mobilnih uređaja.
Ujedinjavanje resursa u skupine. Skupine resursa trebaju omogućiti istovremenu dodjelu resursa nekoliko klijenata, osiguravajući izolaciju klijenata i odsustvo međusobnog utjecaja među njima i konkurencije za resurse. U skupine se uključuju i mreže, što sugerira mogućnost korištenja preklapajuće adresacije. Skupine trebaju podržavati skaliranje na zahtjev. Korištenje skupina omogućava postizanje potrebnog nivoa otpornosti na kvarove resursa i apstrakciju fizičkih i virtualnih resursa — korisniku usluga se jednostavno pruža traženi set resursa (gdje su ti resursi fizički smješteni, na koliko servera i prekidača — klijentu to nije važno). Međutim, treba imati na umu da pružatelj mora osigurati transparentno rezervisanje tih resursa.
Brza prilagodba različitim uvjetima. Usluge trebaju biti fleksibilne — brzo pružanje resursa, njihovo preusmjeravanje, dodavanje ili smanjenje resursa na zahtjev klijenta, pri čemu klijent treba imati osjećaj da su resursi oblaka beskonačni. Radi lakšeg razumijevanja, primjerice, ne primjećujete obavijest da vam je u Apple iCloud-u nestao dio diskovnog prostora zbog kvara tvrdom disku na serveru, a tvrdi diskovi se kvare. Osim toga, mogućnosti ovog servisa s vaše strane su praktički beskrajne — trebate 2 TB — nema problema, platili ste i dobili. Sličan primjer može se dati s Google Drive-om ili Yandex.Disk-om.
Mogućnost mjerenja pružene usluge. Oblačni sustavi trebaju automatski kontrolirati i optimizirati potrošene resurse, pri čemu ti mehanizmi trebaju biti transparentni i za korisnika i za pružatelja usluga. To znači da uvijek možete provjeriti koliko resursa vi i vaši klijenti trošite.
Važno je uzeti u obzir da su ti zahtjevi većinom zahtjevi za javno oblaka, stoga se za privatno oblak (odnosno oblak pokrenut za interne potrebe kompanije) ti zahtjevi mogu malo prilagoditi. Ipak, oni se i dalje moraju ispuniti, inače nećemo dobiti sve prednosti oblačnog računarstva.
Zašto nam treba oblak?
Međutim, svaka nova ili postojeća tehnologija, svaki novi protokol se stvara s nekim ciljem (osim RIP-ng, naravno). Protokol radi protokola — nikome nije potreban (osim RIP-ng, naravno). Logično je da se oblak stvara kako bi korisniku/klijentu pružio neku uslugu. Svi smo barem upoznati s nekim oblačnim uslugama, poput Dropboxa ili Google Docs-a i pretpostavljam da većina njih uspješno koristi — na primjer, ovaj članak je napisan koristeći oblačnu uslugu Google Docs. Ali poznate oblačne usluge su samo dio mogućnosti oblaka — točnije, to su samo SaaS tip usluga. Pružiti oblačnu uslugu možemo na tri načina: u obliku SaaS, PaaS ili IaaS. Koja vam usluga treba ovisi o vašim željama i mogućnostima.
Razmotrite svaki od njih redom:
Software as a Service (SaaS) — to je model pružanja potpunog servisa korisniku, na primjer, usluga e-pošte poput Yandex.Mail ili Gmail. U ovom modelu pružanja usluga, kao korisnik zapravo ne radite ništa osim korištenja usluge — to jest, ne morate razmišljati o konfiguraciji usluge, njenoj otpornosti na kvarove ili rezerviranju. Glavno je ne kompromitirati lozinku, sve ostalo će za vas obaviti pružatelj usluga. Sa stajališta pružatelja usluga — on je potpuno odgovoran za cijelu uslugu — počevši od serverske opreme i host operativnih sustava, do postavki baza podataka i softvera.
Platforma kao usluga (PaaS) — kada se koristi ovaj model, pružatelj usluga korisniku pruža predložak za uslugu, na primjer, uzmimo Web server. Pružatelj usluga je korisniku dao virtualni server (u suštini set resursa, poput RAM-a / CPU-a / pohrane / mreža itd.), i čak je instalirao operativni sustav i potrebno softver na taj server, međutim, konfiguraciju svega toga radi sam korisnik i za funkcionalnost usluge već odgovara korisnik. Pružatelj usluga, kao i u prethodnom slučaju, odgovara za funkcionalnost fizičke opreme, hipervizora, same virtualne mašine, njene mrežne dostupnosti itd., ali je sama usluga već izvan njegove odgovornosti.
Infrastruktura kao usluga (IaaS) — ovaj pristup je već zanimljiviji, zapravo pružatelj usluga korisniku pruža potpunu virtualiziranu infrastrukturu — to jest, neki set (pool) resursa, poput CPU jezgri, RAM-a, mreža itd. Sve ostalo — stvar je korisnika — što korisnik želi učiniti s tim resursima unutar dodijeljenog mu poola (kvote) — pružatelju nije toliko važno. Ako korisnik želi stvoriti svoj vlastiti vEPC ili čak postati mali operater i pružati telekomunikacijske usluge — nema problema — samo naprijed. U takvom scenariju pružatelj usluga odgovara za opskrbu resursima, njihovu otpornost na kvarove i dostupnost, kao i za operativni sustav koji omogućava objedinjavanje tih resursa u poolove i njihovo pružanje korisniku s mogućnošću da u bilo kojem trenutku poveća ili smanji resurse na zahtjev korisnika. Sve virtualne mašine i ostalu opremu korisnik konfigurira sam putem portala za samoposluživanje i konzole, uključujući i postavljanje mreža (osim vanjskih mreža).
Što je OpenStack?
U sva tri varijante, dobavljaču usluga potrebna je operacijska sustav koja omogućuje izgradnju cloud infrastrukture. U stvari, u SaaS rješenju za cijeli set ovih tehnologija ne odgovara jedno odjeljenje — postoji odjeljenje koje je zaduženo za infrastrukturu — što znači da pruža IaaS drugom odjeljenu, a taj odjel pruža SaaS klijentima. OpenStack je jedan od cloud operativnih sustava koji omogućuje skupljanje mnogo preklopnika, poslužitelja i sustava za pohranu u jedinstveni resursni bazen, razdvaja ovaj zajednički bazen na pod-bazene (tenante) i pruža te resurse klijentima putem mreže.
OpenStack — to je cloud operativni sustav koji omogućuje upravljanje velikim bazenima računalnih resursa, pohrane podataka i mrežnih resursa, čije se provizioniranje i upravljanje vrši putem API-a koristeći standardne mehanizme autentifikacije.
Drugim riječima, to je skup projekata slobodnog softvera koji je namijenjen za stvaranje oblaka usluga, (kako javnih, tako i privatnih) — to jest, skup alata koji omogućuju povezivanje poslužiteljske i preklopničke opreme u jedinstveni bazen resursa, upravljanje tim resursima, osiguravajući potrebnu razinu otpornosti na kvarove.
U trenutku pisanja ovog materijala struktura OpenStack izgleda ovako:
Slika preuzeta s
Svaka od komponenti koje čine OpenStack obavlja određenu funkciju. Ova distribuirana arhitektura omogućuje uključivanje seta funkcionalnih komponenti potrebnih za rješenje. Međutim, neke komponente su temeljne komponente i njihovo uklanjanje će dovesti do potpune ili djelomične neispravnosti rješenja u cjelini. Takvim komponentama obično pripadaju:
- Nadzorna ploča — GUI baziran na webu za upravljanje OpenStack uslugama
- Keystone — centralizirana usluga identifikacije koja pruža funkcionalnost autentifikacije i autorizacije za druge usluge, kao i upravljanje korisničkim podacima i njihovim ulogama.
- Neutron — mrežna usluga koja osigurava povezivanje između sučelja raznih OpenStack usluga (uključujući povezivanje između VM-ova i njihov pristup vanjskom svijetu)
- Cinder — omogućava pristup blok-hraništu za virtualne strojeve
- Nova — upravljanje životnim ciklusom virtualnih mašina
- Glance — repozitorij slika virtualnih mašina i snapshotova
- Swift — pruža pristup objektnoj pohrani
- Ceilometer — usluga koja omogućava prikupljanje telemetrije i mjerenje postojećih i potrošačkih resursa
- Heat — orkestracija temeljem predloška za automatsko stvaranje i provizijiranje resursa
Potpun popis svih projekata i njihova namjena može se vidjeti .
Svaka od komponenti OpenStack-a je usluga koja odgovara za određenu funkciju i osigurava API za upravljanje tom funkcijom i interakciju te usluge s drugim uslugama oblaka s ciljem stvaranja jedinstvene infrastrukture. Na primjer, Nova osigurava upravljanje računalnim resursima i API za pristup konfiguriranju tih resursa, Glance – upravljanje slikama i API za upravljanje njima, Cinder – blokovna pohrana i API za upravljanje njome itd. Sve funkcije su međusobno vrlo usko povezane.
Međutim, ako razmislimo, sve usluge pokrenute u OpenStack-u predstavljaju neku virtualnu mašinu (ili kontejner) povezanu s mrežom. Otvoreno je pitanje — zašto nam treba toliko elemenata?
Pogledajmo algoritam za stvaranje virtualne mašine i njeno povezivanje s mrežom i stalnom pohranom u OpenStack-u.
- Kada kreirate zahtjev za stvaranje mašine, bilo da je to zahtjev putem Horizon (Dashboard) ili putem CLI-a, prvo što se događa — to je autorizacija vašeg zahtjeva na Keystone-u — možete li stvarati mašine, imate li pravo koristiti tu mrežu, ima li vaš projekt dovoljno kvota itd.
- Keystone vrši autentifikaciju vašeg zahtjeva i generira u povratnoj poruci auth-token koji će se dalje koristiti. Nakon što primi odgovor od Keystone-a, zahtjev se šalje prema Nova (nova api).
- Nova-api provjerava valjanost vašeg zahtjeva, obraćajući se Keystone-u, koristeći prethodno generirani auth-token.
- Keystone vrši autentifikaciju i pruža na temelju tog auth-token-a informacije o dozvolama i ograničenjima.
- Nova-api stvara u nova-database zapis o novoj VM i prosljeđuje zahtjev za stvaranje mašine u nova-scheduler.
- Nova-scheduler odabire hosta (računalnu nodu) na kojoj će VM biti raspoređena na temelju zadanih parametara, težina i zona. Zapis o tome i identifikator VM-a upisuju se u nova-datoteku.
- Nakon toga, nova-scheduler se obraća nova-compute s zahtjevom za raspoređivanje instance. Nova-compute se obraća nova-conductoru radi dobivanja informacija o parametrima mašine (nova-conductor je komponenta nove koja djeluje kao proxy server između nova-datoteke i nova-compute, ograničavajući broj zahtjeva prema nova-datoteci kako bi se izbjegli problemi s konzistencijom baze podataka i smanjilo opterećenje).
- Nova-conductor dobiva tražene informacije iz nova-datoteke i prosljeđuje ih nova-compute.
- Nakon toga, nova-compute se obraća glanceu radi dobivanja ID-a slike. Glance provodi validaciju zahtjeva u Keystoneu i vraća tražene informacije.
- Nova-compute se obraća neutronu radi dobivanja informacija o parametrima mreže. Slično kao glance, neutron provodi validaciju zahtjeva u Keystoneu, nakon čega stvara zapis u bazi podataka (identifikator porta itd.), stvara zahtjev za izradom porta i vraća tražene informacije nazad u nova-compute.
- Nova-compute se obraća cinderu s zahtjevom za dodjeljivanje volumena virtualnoj mašini. Slično kao glance, cinder provodi validaciju zahtjeva u Keystoneu, stvara zahtjev za izradom volumena i vraća tražene informacije.
- Nova-compute se obraća libvirtu s zahtjevom za raspoređivanje virtualne mašine s zadanim parametrima.
Čini se da jednostavna operacija stvaranja virtualne mašine postaje vrtlog API poziva između elemenata oblaka. Kao što vidite, čak su i ranije imenovane usluge sastavljene od manjih komponenti koje međusobno komuniciraju. Stvaranje mašine je samo mali deo onoga što vam oblak omogućuje—tu su usluge za balansiranje prometa, usluge za blokovno skladištenje, usluge za DNS, kao i usluge za provisining bare metal servera itd. Oblak vam omogućava da na svoje virtualne mašine gledate kao na stado ovaca (za razliku od virtualizacije). Ako se u virtualnom okruženju nešto dogodi sa mašinom—vratite je iz rezervnih kopija itd., dok su cloud aplikacije dizajnirane na način da virtualne mašine ne igraju toliku ulogu—ako je virtualna mašina
Uvijek treba imati na umu da nije moguće imati oblačnu infrastrukturu bez mreže—svaki element na neki način komunicira s drugim elementima putem mreže. Osim toga, oblak ima apsolutno nestatičnu mrežu. Naravno, underlay mreža je više-manje statična—nije svaki dan dodano novih čvorova i sklopova, međutim overlay komponenta može, i neizbježno će, stalno mijenjati—dodavat će se ili uklanjati nove mreže, nove virtualne mašine će se pojavljivati i stare će umirati. I kao što se sjećate iz definicije oblaka dane na početku članka—resursi bi se trebali dodeljivati korisnicima automatski, uz minimalno (ili bolje, bez) uplitanja pružatelja usluga. Dakle, ona vrsta pružanja mrežnih resursa koja trenutno postoji u obliku frontend-a, to jest vašeg ličnog kabineta dostupnog putem http/https i dežurnog mrežnog inženjera Vasilija kao backend-a—to nije oblak, čak ni uz Vasilijevih osam ruku.
Neutron, kao mrežna usluga, pruža API za upravljanje mrežnim dijelom oblaka infrastrukture. Usluga osigurava funkcionalnost i upravljanje mrežnim dijelom OpenStack-a, nudeći razinu apstrakcije koja se zove Network-as-a-Service (NaaS). Drugim riječima, mreža je jedina virtualna mjerna jedinica, kao što su virtualna CPU jezgra ili količina RAM-a.
No, prije nego pređemo na arhitekturu mrežnog dijela OpenStack-a, razmotrimo kako ta mreža radi u OpenStack-u i zašto je mreža važan i neizostavni dio oblaka.
Dakle, imamo dvije virtualne mašine klijenta RED i dvije virtualne mašine klijenta GREEN. Pretpostavimo da su te mašine raspoređene na dva hipervizora na sljedeći način:
Trenutno je to samo virtualizacija 4 servera i ništa više, jer sve što smo napravili je virtualizacija 4 servera, smještenih na dva fizička servera. Osim toga, trenutno nisu ni povezani na mrežu.
Da bismo dobili oblak, moramo dodati nekoliko komponenti. Prvo, virtualiziramo mrežni dio — moramo povezati te 4 mašine u parove, uzimajući u obzir da klijenti žele L2 vezu. Naravno, možemo koristiti prekidač i postaviti trunk prema njemu te sve riješiti pomoću Linux bridža, ili za naprednije korisnike OpenvSwitch (njemu ćemo se još vratiti). No, mreža može biti vrlo mnogo, a stalno provlačiti L2 kroz prekidač — nije najbolja ideja — jer različiti odjeli, servisni desk, mjeseci čekanja na izvršenje zahtjeva, tjedni rješavanja problema — u modernom svijetu takav pristup više ne funkcionira. I koliko prije kompanija to shvati — to joj je lakše napredovati. Zato ćemo između hipervizora dodijeliti L3 mrežu preko koje će komunicirati naše virtualne mašine, a na tu L3 mrežu izgraditi virtualne preklapajuće L2 (overlay) mreže, na kojima će se kretati promet naših virtualnih mašina. Za enkapsulaciju možemo koristiti GRE, Geneve ili VxLAN. Za sada ćemo se fokusirati na posljednji, iako to nije toliko važno.
Moramo negdje smjestiti VTEP (nadam se da ste svi upoznati s terminologijom VxLAN). Budući da nam s poslužitelja izlazi odmah L3 mreža, ništa nam ne smeta da smjestimo VTEP na same poslužitelje, a OVS (OpenvSwitch) to odlično radi. Na kraju imamo ovakvu konstrukciju:
Budući da se promet između VM mora razdvojiti, portovi prema virtualnim strojevima će imati različite brojeve VLAN-ova. Broj oznake igra ulogu samo unutar jednog virtualnog prekidača, jer prilikom enkapsulacije u VxLAN možemo bez problema ukloniti oznaku, jer ćemo imati VNI.
Sada možemo reproducirati naše strojeve i virtualne mreže za njih bez ikakvih problema.
Međutim, što ako klijent ima još jedan stroj, ali je u drugoj mreži? Potrebno nam je usmjeravanje između mreža. Analizirat ćemo jednostavan primjer kada se koristi centralizirano usmjeravanje — to jest, promet se usmjerava kroz posebne dodijeljene mrežne čvorove (obično su oni spojeni s kontrolnim čvorovima, tako da ćemo imati isto).
Izgleda da nema ništa komplicirano — pravi mostovni sučelje na kontrolnom čvoru, usmjeravamo promet prema njemu i odatle ga usmjeravamo gdje nam treba. No, problem je što klijent RED želi koristiti mrežu 10.0.0.0/24, a klijent GREEN želi koristiti mrežu 10.0.0.0/24. Dakle, počinje nam se preklapanje adresnih prostora. Osim toga, klijenti ne žele da drugi klijenti mogu usmjeravati u njihove interne mreže, što je logično. Da bismo razdvojili mreže i promet podataka klijenata, svakom od njih odvojićemo poseban namespace. Namespace je zapravo kopija mrežnog stoga Linuxa, što znači da su klijenti u namespace RED potpuno izolirani od klijenata iz namespace GREEN (ili je usmjeravanje između tih klijenata dopušteno kroz default namespace ili već na višem transportnom uređaju).
Dakle, dobivamo takvu shemu:
L2 tuneli se skupljaju sa svih računalnih čvorova na kontrolni čvor, gdje se nalazi L3 sučelje za te mreže, svaki u dodijeljenom namespaceu radi izolacije.
Međutim, zaboravili smo najvažnije. Virtualna mašina mora pružati uslugu korisniku, što znači da bi trebala imati barem jedan vanjski sučelje preko kojeg se može pristupiti. To zahtijeva izlaz u vanjski svijet. Postoje različite opcije. Uzet ćemo najjednostavniju varijantu. Dodajmo korisnicima po jednu mrežu, koja će biti valjana u mreži davatelja i neće se preklapati s drugim mrežama. Mreže također mogu biti preklapajuće i gledati u različite VRF-ove na strani mreže davatelja. Te će mreže također živjeti u namespaceu svakog korisnika. Ipak, izlaz u vanjski svijet će imati kroz jedan fizički (ili bond, što je logičnije) sučelje. Da bismo odvojili promet korisnika, promet koji izlazi van će se označiti VLAN oznakom koja je dodijeljena korisniku.
Na kraju smo dobili ovakvu shemu:
Razuman je pitanje — zašto ne stvoriti gatewaye na samim compute čvorovima? Velikih problema tu nema, štoviše, kad se uključi distribuirani usmjerivač (DVR) to će također raditi. U ovom scenariju razmatramo najjednostavniju varijantu s centraliziranim gatewayom, koji se u Openstacku koristi po defaultu. Za visoko opterećene funkcije koristit će se i distribuirani usmjerivač, kao i tehnologije ubrzanja poput SR-IOV i Passthrough, ali kako se kaže, to je već posve druga priča. Prvo ćemo se pozabaviti osnovnim dijelom, a zatim ćemo se pozabaviti detaljima.
Naša shema je već funkcionalna, međutim, postoje neki detalji:
- Moramo na neki način zaštititi naše mašine, to jest, postaviti filter na sučelje switch-a prema korisniku.
- Omogućiti automatsko dobivanje IP adrese od strane virtualne mašine, kako ne bismo morali svaki put ulaziti u nju putem konzole i ručno unositi adresu.
Počnimo s zaštitom mašine. U tu svrhu možemo koristiti osnovne iptables, zašto ne.
To znači da je naša topologija sada malo složenija:
Idemo dalje. Moramo dodati DHCP server. Idealno mjesto za postavljanje DHCP servera za svakog korisnika bit će već spomenuti kontrolni čvor, gdje se nalaze namespaces:
Međutim, postoji mali problem. Što ako se sve ponovo pokrene i sve informacije o iznajmljivanju adresa na DHCP-u nestanu? Logično je da će računalima biti dodeljene nove adrese, što nije baš zgodno. Opcije su dve — ili koristiti domena imena i dodati DNS server za svakog klijenta, tada nam adresa neće biti toliko važna (na sličan način kao u mrežnoj komponenti u k8s) — ali ovde postoji problem s vanjskim mrežama, jer se i njima adrese mogu dodeliti putem DHCP-a — potrebna je sinhronizacija s DNS serverima u oblaku i vanjskim DNS serverom, što smatram nije baš fleksibilno, iako je sasvim izvodljivo. Druga opcija — koristiti metapodatke — odnosno čuvati informacije o dodeljenoj adresi mašini kako bi DHCP server znao koju adresu dodeliti mašini ako je već dobila adresu. Druga opcija je jednostavnija i fleksibilnija, jer omogućuje čuvanje dodatnih informacija o mašini. Sada ćemo dodati agenta metapodataka u šemu:
Još jedno pitanje koje takođe treba razjasniti — to je mogućnost korišćenja jedne vanjske mreže od strane svih klijenata, jer će biti teško obezbediti da vanjske mreže budu validne u celoj mreži — stalno treba dodeljivati i kontrolisati dodeljivanje tih mreža. Opcija korišćenja jedne predkonfigurirane vanjske mreže za sve klijente biće veoma korisna prilikom kreiranja javnog oblaka. To će pojednostaviti raspoređivanje mašina, jer nećemo morati da se usklađujemo s bazom podataka adresa i biramo jedinstveni adresni prostor za vanjsku mrežu svakog klijenta. Pored toga, možemo unapred definisati vanjsku mrežu i prilikom raspoređivanja biće potrebno samo da asociramo vanjske adrese s klijentskim mašinama.
I ovdje nam pomaže NAT — jednostavno ćemo omogućiti klijentima izlazak u vanjski svijet kroz default namespace koristeći NAT prevođenje. Međutim, tu se javlja mala poteškoća. To je dobro ako klijentski server radi kao klijent, a ne kao server — to jest, inicira, a ne prima veze. No, kod nas će situacija biti suprotna. U tom slučaju, trebamo napraviti destination NAT, kako bi kontrolna čvora razumjela da je ovaj promet namijenjen virtualnoj mašini A klijenta A, a to znači da trebamo napraviti NAT prevođenje iz vanjske adrese, na primjer 100.1.1.1 u unutarnju adresu 10.0.0.1. Na taj način, iako svi klijenti koriste istu mrežu, unutarnja izolacija se u potpunosti čuva. Drugim riječima, trebamo na kontrolnoj čvoru napraviti dNAT i sNAT. Korištenje jedinstvene mreže s dodjeljivanjem plavilih adresa ili vanjskih mreža, ili oboje odjednom, ovisi o tome što želite prenijeti u oblak. Nećemo na shemu dodavati plave adrese, već ćemo ostaviti već ranije dodane vanjske mreže — svaki klijent ima svoju vanjsku mrežu (na shemi označene kao VLAN 100 i 200 na vanjskom sučelju).
Na kraju smo dobili zanimljivo, a istovremeno i promišljeno rješenje, koje posjeduje određenu fleksibilnost, ali još uvijek nema mehanizme otpornosti na kvarove.
Prvo, imamo samo jednu kontrolnu čvoru — njezin kvar će dovesti do kolapsa svih sustava. Da bismo riješili ovaj problem, potrebno je stvoriti barem kvorum od 3 čvora. Dodajmo to na shemu:
Naravno, svi čvorovi se sinkroniziraju, a kada aktivni čvor pređe iz sustava, njegove obaveze preuzima drugi čvor.
Sljedeći problem su diskovi virtualnih strojeva. Trenutno se pohranjuju na samim hipervizorima i u slučaju problema s hipervizorom gubimo sve podatke – a prisutnost RAID-a ne pomaže ako izgubimo ne disk, već cijeli server. Za to nam je potrebna usluga koja će djelovati kao frontend za bilo koju pohranu. Koja će to pohrana biti, nije nam toliko važno, ali mora zaštititi naše podatke od kvara i diska i čvora, a možda čak i cijelog ormara. Opcija je nekoliko – naravno, postoje SAN mreže s Fiber Channel, ali budimo iskreni – FC je već relikt prošlosti – ekvivalent E1 u transportu – slažem se, još se koristi, ali samo tamo gdje se bez njega ne može. Stoga se ne bih odlučio za implementaciju FC mreže 2020. godine, znajući za postojanje drugih zanimljivijih alternativa. Iako svatko svoje i možda će se naći oni koji smatraju da je FC sa svim svojim ograničenjima upravo ono što nam treba – neću se svađati, svatko ima svoje mišljenje. Međutim, najzanimljivije rješenje po mom mišljenju je korištenje SDS-a, primjerice Ceph.
Ceph omogućuje izradu visoko dostupnog rješenja za pohranu podataka s nizom opcija za rezervnu kopiju, počevši od kodova s provjerom pariteta (ekvivalent RAID 5 ili 6) do potpune replikacije podataka na različite diskove uzimajući u obzir položaj diskova u serverima i servere u ormarima itd.
Za izgradnju Ceph-a potrebno je još 3 čvora. Interakcija s pohranom odvijat će se također putem mreže koristeći usluge blokovne, objektne i datotečne pohrane. Dodajmo u shemu pohranu:
Napomena: također možete napraviti hiperkonvergirane compute čvorove — to je koncept spajanja više funkcija na jednom čvoru — na primjer storage+compute — ne izdvajati posebne čvorove za ceph storage. Dobit ćemo jednaku shemu otpornosti na kvarove — budući da SDS rezervira podatke na razini rezervacije koju smo odredili. Međutim, hiperkonvergirani čvorovi su uvijek kompromis — budući da storage čvor ne samo da ne troši resurse uzalud (budući da na njemu nema virtualnih strojeva) — troši resurse CPU-a na održavanje SDS-a (u pozadini radi sve replikacije, oporavke od kvara čvorova, diskova itd.). To znači da ćete izgubiti dio snage compute čvora ako ga spojite sa storage-om.
Sve to treba nekako upravljati — potrebno je nešto, preko čega možemo kreirati stroj, mrežu, virtualni usmjerivač itd. Za to ćemo na kontrolni čvor dodati uslugu koja će imati ulogu dashboard-a — korisnik se može povezati na ovaj portal putem http/https i obaviti sve što mu je potrebno (pa skoro sve).
Kao rezultat toga imamo otpornu sistem. Svime elementima ove infrastrukture treba nekako upravljati. Ranije je opisano da je OpenStack skup projekata, od kojih svaki pruža neku određenu funkciju. Kao što vidimo, postoji više nego dovoljno elemenata koje treba konfigurirati i kontrolirati. Danas ćemo razgovarati o mrežnom dijelu.
Arhitektura Neutron
U OpenStack-u, Neutron je onaj koji odgovara za povezivanje portova virtualnih strojeva na zajedničku L2 mrežu, osiguranje usmjeravanja prometa između VM-ova koji su u različitim L2 mrežama kao i usmjeravanje prema van, pružanje takvih usluga kao što su NAT, Floating IP, DHCP itd.
Visokorazmjenski rad mrežne usluge (osnovni dio) može se opisati ovako.
Prilikom pokretanja VM-a, mrežna usluga:
- Stvara port za ovaj VM (ili portove) i obavještava o tome DHCP uslugu;
- Stvara se novi virtualni mrežni uređaj (kroz libvirt);
- VM se povezuje na port(ove) stvorene u prvom koraku;
Naizgled, osnova rada Neutrona leži u standardnim mehanizmima poznatim svima onima koji su se ikada bavili Linuxom — to su namespaces, iptables, linux bridges, openvswitch, conntrack itd.
Odmah treba napomenuti da Neutron nije SDN kontroler.
Neutron se sastoji od nekoliko međusobno povezanih komponenti:
Openstack-neutron-server — to je demon koji radi s korisničkim zahtjevima putem API-ja. Ovaj demon ne upravlja mrežnim vezama, već pruža potrebne informacije svojim pluginovima koji zatim konfiguriraju željeni mrežni element. Neutron-ageni na OpenStack čvorovima registriraju se na Neutron serveru.
Neutron-server je zapravo aplikacija napisana na Pythonu, koja se sastoji od dva dijela:
- REST usluga
- Neutron Plugin (core/service)
REST usluga je namijenjena za primanje API poziva od ostalih komponenti (na primjer, zahtjev za pružanjem određenih informacija itd.)
Pluginovi su priključni programski komponente/moduli koji se pozivaju prilikom API zahtjeva — tj. dodavanje nekog servisa se odvija preko njih. Pluginovi se dijele na dva tipa — servisni i korijenski. Obično, korijenski plugin uglavnom odgovara za upravljanje adresnim prostorom i L2 povezivanja između VM-a, dok servisni pluginovi osiguravaju dodatne funkcionalnosti poput VPN-a ili FW-a.
Popis dostupnih pluginova danas se može vidjeti, na primjer,
Servisnih pluginova može biti više, no korijenski plugin može biti samo jedan.
Openstack-neutron-ml2 — to je standardni korijenski plugin Openstacka. Ovaj plugin ima modularnu arhitekturu (za razliku od svog prethodnika) i putem priključenih drajvera konfigurira mrežnu uslugu. Sam plugin ćemo razmotriti malo kasnije, jer zapravo pruža onu fleksibilnost koju OpenStack ima u mrežnom dijelu. Korijenski plugin može biti zamijenjen (na primjer, Contrail Networking vrši takvu zamjenu).
RPC usluga (rabbitmq-server) — usluga koja osigurava upravljanje redovima i interakciju s drugim OpenStack uslugama, kao i interakciju između agenata mrežne usluge.
Mrežni agenti — agenti koji se nalaze u svakoj čvoru, putem kojih se konfiguriraju mrežne usluge.
Agent može biti nekoliko vrsta.
Glavni agent — to je L2 agent. Ovi agenti se pokreću na svakom od hipervizora uključujući i kontrolne čvorove (preciznije na svim čvorovima koji pružaju bilo koju uslugu za tenante), a njihova glavna funkcija je povezivanje virtualnih mašina s zajedničkom L2 mrežom, kao i generiranje obavijesti prilikom nastanka bilo kakvih događaja (na primjer isključivanja/uključivanja porta).
Sljedeći, ne manje važan agent je L3 agent. Podrazumijeva se da se ovaj agent pokreće isključivo na mrežnom čvoru (često se mrežni čvor poklapa s kontrolnim čvorom) i omogućuje usmjeravanje između mreža tenanata (kako između njegovih mreža i mreža drugih tenanata, tako i pristup vanjskom svijetu, omogućujući NAT, kao i DHCP uslugu). Međutim, prilikom korištenja DVR-a (distribuirani usmjerivač) potreba za L3 pluginom se javlja i na računalnim čvorovima.
L3 agent koristi Linux namespaces za pružanje svakom tenant-u seta vlastitih izoliranih mreža i funkcionalnosti virtualnih usmjerivača, koji usmjeravaju promet i pružaju usluge gateway-a za Layer 2 mreže.
Baza podataka — baza podataka identifikatora mreža, podmreža, portova, пулova itd.
U suštini, Neutron prima API zahtjeve za kreiranje bilo kojih mrežnih entiteta, autentificira zahtjev, i putem RPC (ako se obraća nekom plugu ili agentu) ili REST API (ako komunicira u SDN) prenosi agentima (putem plugina) upute potrebne za organizaciju tražene usluge.
Sada se obratimo testnoj instalaciji (kako je postavljena i što je uključuje, pogledat ćemo kasnije u praktičnom dijelu) i pogledajmo gdje se koja komponenta nalazi:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Evo, to je cijela struktura Neutrona. Sad vrijedi posvetiti malo vremena ML2 plug-inu.
Modular Layer 2
Kao što je već spomenuto, plug-in je standardni osnovni plug-in OpenStacka i ima modularnu arhitekturu.
Prethodnik ML2 plug-ina imao je monolitnu strukturu koja nije dopuštala, na primjer, korištenje mješavine nekoliko tehnologija u jednoj instalaciji. Na primjer, niste mogli koristiti i openvswitch i linuxbridge istovremeno — ili jedno ili drugo. Iz tog razloga stvoren je ML2 plug-in sa svom svojom arhitekturom.
ML2 ima dvije komponente — dva tipa drajvera: Type drivers i Mechanism drivers.
Type drivers određuju tehnologije koje će se koristiti za organizaciju mrežnih povezivanja, na primjer VxLAN, VLAN, GRE. Drajver pri tome omogućava korištenje različitih tehnologija. Standardna tehnologija je VxLAN enkapsulacija za overlay mreže i vlan vanjske mreže.
Među Type drivers su sljedeće vrste mreža:
Flat — mreža bez oznaka
VLAN — označena mreža
Local — poseban tip mreže za instalacije tipa all-in-one (takve instalacije su potrebne ili za programere ili za obuku)
GRE — overlay mreža koja koristi GRE tunele
VxLAN — overlay mreža koja koristi VxLAN tunele
Mechanism drivers određuju sredstva koja osiguravaju organizaciju navedenih u type driver tehnologija — na primjer, openvswitch, sr-iov, opendaylight, OVN itd.
Ovisno o implementaciji ovog drajvera, koristiće se ili agenti kojima upravlja Neutron, ili će se koristiti veze s vanjskim SDN kontrolerom koji preuzima sve obaveze oko organizacije L2 mreža, rutiranja itd.
Na primjer, ako koristimo ML2 zajedno s OVS-om, svaki računarski čvor ima L2 agenta koji upravlja OVS-om. Međutim, ako koristimo, na primjer, OVN ili OpenDayLight, upravljanje OVS-om prelazi pod njihovu nadležnost — Neutron putem korijenskog plugina daje komande kontroleru, a on izvršava ono što mu je rečeno.
Osvježimo pamćenje o Open vSwitch-u
Trenutno je jedan od ključnih komponenti OpenStack-a Open vSwitch.
Pri instalaciji OpenStack-a bez dodatnog vendor SDN-a poput Juniper Contrail-a ili Nokia Nuage, OVS je osnovna mrežna komponenta oblaka i u kombinaciji s iptables, conntrack, namespaces omogućava organizaciju punopravnih overlay mreža s multitenancy. Naravno, ova komponenta može biti zamenjena, na primjer, pri korišćenju eksternih vlasničkih (vendor) SDN rešenja.
OVS je softverski preklopnik otvorenog koda koji se koristi u virtualizovanim okruženjima kao virtuelni proslednik saobraćaja.
Trenutno OVS ima vrlo solidne funkcionalnosti, uključujući tehnologije poput QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK itd.
Napomena: prvobitno OVS nije zamišljen kao softverski preklopnik za visoko opterećene telekom funkcije i više je bio prilagođen manje zahtevnim IT funkcijama poput WEB servera ili servera za e-poštu. Međutim, OVS se unapređuje, a trenutne implementacije OVS-a značajno su poboljšale njegovu performansu i mogućnosti što omogućava njegovu upotrebu kod operatera telekomunikacija sa visoko opterećenim funkcijama, na primjer postoji implementacija OVS-a sa podrškom za DPDK ubrzanje.
Postoje tri važne komponente OVS-a o kojima je potrebno znati:
- Kernel modul — komponenta smeštena u kernel prostoru koja obrađuje saobraćaj na osnovu pravila koja dobija od upravljačkog dela;
- vSwitch daemon (ovs-vswitchd) je proces koji se pokreće u user prostoru i odgovoran je za programiranje kernel modula — to jest predstavlja logiku ostvarivanja rada preklopnika.
- Poslužitelj baze podataka — lokalna baza podataka koja se nalazi na svakom hostu na kojem je pokrenut OVS i u kojoj se čuva konfiguracija. Ovaj modul omogućava komunikaciju SDN kontrolera putem OVSDB protokola.
U tu svrhu dolazi i set dijagnostičkih i upravljačkih alata, kao što su ovs-vsctl, ovs-appctl, ovs-ofctl i dr.
Trenutno se Openstack široko koristi od strane telekom operatera za migraciju mrežnih funkcija, kao što su EPC, SBC, HLR i dr. Dio funkcija može nesmetano raditi s OVS-om onako kako jest, ali primjerice, EPC obrađuje promet korisnika — što znači da propušta ogroman volumen prometa (sadašnji promet doseže nekoliko stotina gigabita u sekundi). Naravno, propuštati takav promet kroz kernel prostor (budući da je po defaultu proksy tamo smješten) nije najbolja ideja. Stoga se OVS često implementira potpuno u user prostoru koristeći DPDK tehnologiju za prosljeđivanje prometa iz NIC-a u user prostor, zaobilazeći kernel.
Napomena: za oblak postavljen za telekom funkcije postoji mogućnost prosljeđivanja prometa s compute čvora direktno u preklopnu opremu, zaobilazeći OVS. Za ovu svrhu koriste se mehanizmi SR-IOV i Passthrough.
Kako to funkcionira na stvarnom modelu?
Sada možemo preći na praktični dio i vidjeti kako to sve funkcionira u praksi.
Za početak, postavit ćemo jednostavnu Openstack instalaciju. Budući da nemam set servera pri ruci za eksperimentiranje, model ćemo graditi na jednom fizičkom serveru iz virtualnih mašina. Da, naravno da takvo rješenje nije prikladno za komercijalne svrhe, ali da bismo vidjeli primjer kako funkcionira mreža u Openstack-u, takva instalacija je više nego dovoljna. Osim toga, takva instalacija je čak zanimljivija za svrhe učenja — jer se može uhvatiti promet itd.
Budući da nam je potrebno vidjeti samo osnovni dio, možemo ne koristiti više mreža, nego sve podići koristeći samo dvije mreže, pri čemu će se druga mreža u ovom modelu koristiti isključivo za pristup undercloud-u i DNS poslužitelju. Vanjske mreže za sada nećemo obrađivati — to je tema za odvojeni, veći članak.
Dakle, krenimo redom. Prvo malo teorije. Instalirat ćemo Openstack koristeći TripleO (Openstack na Openstacku). Bit TripleO je da instaliramo Openstack all-in-one (znači na jednu nodu), koja se naziva undercloud, a zatim koristimo mogućnosti raspoređenog Openstacka kako bismo instalirali Openstack namijenjen proizvodnji, koji se naziva overcloud. Undercloud će koristiti mogućnosti upravljanja fizičkim serverima (bare metal) — projekt Ironic — za provisioniranje hypervizora koji će obavljati uloge compute, control i storage nodova. Drugim riječima, ne koristimo nikakve vanjske alate za raspoređivanje Openstacka — raspoređujemo Openstack vlastitim snagama Openstacka. Dalje, tijekom instalacije će postati jasnije, pa nećemo stajati ovdje i krenut ćemo naprijed.
Napomena: U ovom članku, radi pojednostavljenja, nisam koristio mrežnu izolaciju za interne mreže Openstacka, a sve je raspoređeno koristeći samo jednu mrežu. Međutim, postojanje ili nepostojanje izolacije mreža ne utječe na osnovnu funkcionalnost rješenja — sve će raditi točno na isti način kao i pri korištenju izolacije, samo će promet prolaziti unutar jedne mreže. Za komercijalnu instalaciju naravno treba koristiti izolaciju uz korištenje različitih VLAN-ova i sučelja. Na primjer, promet upravljanja Ceph pohranom i promet podataka (pristupi strojeva diskovima itd.) koriste različite podmreže (Storage management i Storage) pri izolaciji, što čini rješenje otpornijim na kvarove, dijeleći taj promet na različite portove ili koristeći različite QoS profile za različit promet, tako da promet podataka ne ugrozi signalni promet. U našem slučaju, oni će ići u istoj mreži i to nas zapravo nimalo ne ograničava.
Napomena: Kako planiramo pokretati virtualne strojeve u virtualnom okruženju temeljenom na virtualnim strojevima, prvo moramo uključiti nested virtualizaciju.
Možete provjeriti je li nested virtualizacija uključena ili ne na sljedeći način:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ako vidite slovo N, uključite podršku za nested virtualizaciju prema bilo kojem vodiču koji pronađete na mreži, na primjer .
Trebamo sastaviti ovakvu shemu od virtualnih strojeva:
U mom slučaju, za spajanje virtualnih mašina uključenih u buduću instalaciju (njih imam 7, ali možete preživjeti s 4 ako nemate mnogo resursa), koristio sam OpenvSwitch. Napravio sam jedan ovs most i povezao ga s virtualnim mašinama putem port-grupa. Za to sam stvorio xml datoteku sljedećeg oblika:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Ovdje su definirane tri port grupe — dvije access i jedna trunk (potonja je bila potrebna za DNS poslužitelj, ali se može i bez nje, ili je podići na host mašini — kako vam više odgovara). Zatim, koristeći ovu šablon, definiramo našu mrežu preko virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Sada podešavamo konfiguraciju portova hipervizora:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TIP=Ethernet
IME=ens1f0
UREĐAJ=ens1f0
TIP=OVSPort
TIPUREĐAJA=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=da
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
UREĐAJ=ovs-br1
TIPUREĐAJA=ovs
TIP=OVSBridge
BOOTPROTO=static
ONBOOT=da
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Napomena: u ovom scenariju adresa na portu ovs-br1 neće biti dostupna, jer nema VLAN taga. Da biste to ispravili, potrebno je izvršiti naredbu sudo ovs-vsctl set port ovs-br1 tag=100. Međutim, nakon ponovnog pokretanja, taj tag će nestati (ako netko zna kako ga zadržati, bio bih veoma zahvalan). No, to nije toliko važno, jer će nam ta adresa biti potrebna samo u vrijeme instalacije i neće biti potrebna kada se OpenStack potpuno postavi.
Zatim kreiramo undercloud mašinu:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Tijekom instalacije postavljate sve potrebne parametre, kao što su ime stroja, lozinke, korisnici, NTP serveri itd., možete odmah postaviti i portove, ali osobno mi je jednostavnije nakon instalacije pristupiti stroju kroz konzolu i ispraviti potrebne datoteke. Ako već imate gotovu sliku, možete je koristiti, ili postupiti kao ja — preuzeti minimalnu sliku CentOS 7 i koristiti je za instalaciju VM-a.
Nakon uspješne instalacije, trebali biste imati virtualni stroj na kojem možete instalirati undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPrvo instaliramo potrebne alate za instalaciju:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalacija Undercloud-a
Kreiramo korisnika stack, postavljamo lozinku, dodajemo ga u sudoer i omogućujemo mu izvršavanje root naredbi putem 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 u datoteci hosts navodimo puno ime undercloud-a:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Zatim dodajemo repozitorije i instaliramo potrebni softver:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleNapomena: ako ne planirate instalirati ceph, ne trebate unositi naredbe koje se odnose na ceph. Koristio sam verziju Queens, ali možete koristiti bilo koju drugu koja vam se sviđa.
Zatim kopiramo konfiguracijsku datoteku undercloud u korisničku direktoriju korisnika stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSada je potrebno urediti ovu datoteku, prilagodivši je našoj instalaciji.
Na početak datoteke potrebno je dodati sljedeće retke:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Dakle, proći ćemo kroz postavke:
undercloud_hostname — puno ime undercloud servera, mora se podudarati s unosom na DNS serveru.
local_ip — lokalna adresa undercloud prema provizioniranoj mreži
network_gateway — ista ta lokalna adresa, koja će služiti kao gateway za pristup vanjskom svijetu tijekom instalacije overcloud čvorova, također se poklapa s lokalnom IP
undercloud_public_host — adresa vanjskog API-a, dodijeljuje se bilo kojoj slobodnoj adresi iz provizionirajuće mreže
undercloud_admin_host adresa unutarnjeg API-a, dodijeljuje se bilo kojoj slobodnoj adresi iz provizionirajuće mreže
undercloud_nameservers — DNS server
generate_service_certificate — ovaj redak je vrlo važan u trenutnom primjeru, jer ako ga ne postavite na false, dobit ćete pogrešku tijekom instalacije, problem je opisan na bug trackeru Red Hat
local_interface interfejs u provizionirajućoj mreži. Ovaj interfejs će biti rekonfiguriran tijekom postavljanja undercloud-a, stoga undercloud mora imati dva interfejsa — jedan za pristup, drugi za provizioniranje
local_mtu — MTU. Budući da imamo testnu laboratoriju i MTU mi je 1500 na OVS switch portovima, potrebno je postaviti na 1450, kako bi prošli inkapsulirani VxLAN paketi
network_cidr — provizionirajuća mreža
masquerade — korištenje NAT-a za pristup vanjskoj mreži
masquerade_network — mreža koja će se NAT-ati
dhcp_start — početna adresa IP adresa iz koje će se dodijeliti adrese čvorovima tijekom postavljanja overcloud-a
dhcp_end — završna adresa IP adresa iz koje će se dodijeliti adrese čvorovima tijekom postavljanja overcloud-a
inspection_iprange — raspon adresa potreban za introspekciju (ne smije se preklapati s gore spomenutim rasponom)
scheduler_max_attempts — maksimalni broj pokušaja instalacije overcloud-a (treba biti veći ili jednak broju čvorova)
Nakon što je datoteka opisana, možete dati naredbu za postavljanje undercloud-a:
openstack undercloud install
Postupak traje od 10 do 30 minuta ovisno o vašem hardveru. Na kraju biste trebali vidjeti ovakav ishod:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Instalacija undercloud-a je završena.
Datoteka koja sadrži lozinke ove instalacije se nalazi na
/home/stack/undercloud-passwords.conf.
Također postoji i stackrc datoteka na /home/stack/stackrc.
Ove datoteke su potrebne za interakciju s OpenStack uslugama i trebaju biti
osigurane.
#############################################################################Ovaj ishod govori da ste uspješno instalirali undercloud i sada možete provjeriti stanje undercloud-a i preći na instalaciju overcloud-a.
Ako pogledate ishod ifconfig, vidjet ćete da je pojavio novi bridž interfejs
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Ovaj će se interfejs sada koristiti za implementaciju overclouda.
Iz prikaza ispod možemo vidjeti da su svi servisi na jednoj nodi:
(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 prikazana konfiguracija mrežnog dela underclouda:
(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 ~]$Instalacija overclouda
Trenutno imamo samo undercloud, i nedostaju nam nodovi s kojih će se sastavljati overcloud. Stoga ćemo prvo postaviti potrebne virtuelne mašine. Tokom implementacije, undercloud će sam instalirati OS i potrebni softver na overcloud mašine — tako da nam nije potrebno potpuno postavljati mašinu, već samo kreirati disk (ili diskove) i odrediti njene parametre — što znači da zapravo dobijamo prazni server bez instaliranog OS-a.
Prelazimo u folder s diskovima naših virtuelnih mašina i kreiramo diskove potrebne veličine:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GBudući da delujemo iz root-a, moramo promeniti vlasnika ovih diskova kako ne bismo naišli na probleme s pravima:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Napomena: Ako ne planirate instalirati ceph za učenje, nemojte kreirati manje od 3 čvora s najmanje dva diska, a u predlošku navedite da će se koristiti virtualni diskovi vda, vdb itd.
Odlično, sada moramo definirati sve te 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 postoje naredbe —print-xml > /tmp/storage-1.xml, koja stvara xml datoteku s opisom svake mašine u mapi /tmp/, ako je ne dodate, nećete moći definirati virtualne mašine.
Sada moramo sve te mašine definirati 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 isključen
- compute-2 isključen
- control-1 isključen
- storage-1 isključen
- storage-2 isključen
[root@hp-gen9 ~]#Sad imamo jedan mali detalj — tripleO koristi IPMI za upravljanje serverima tokom instalacije i introspekcije.
Introspekcija je proces inspekcije hardverskog dela u cilju dobijanja njegovih parametara potrebnih za daljnje provizijoning nodova. Introspekcija se vrši uz pomoć ironic — usluge namenjene radu sa bare metal serverima.
Ali tu je problem — ako su kod fizičkih servera IPMI to poseban port (ili zajednički port, ali to nije bitno), kod virtuelnih mašina takvi portovi ne postoje. Tu nam pomaže trik pod nazivom vbmc — alat koji emulira IPMI port. Na ovu nijansu posebno treba obratiti pažnju onima koji žele podići laboratoriju na ESXI hypervisoru — iskreno, ne znam da li postoji analog vbmc u njemu, pa je važno razmisliti o tome pre nego što sve postavite.
Instaliramo vbmc:
yum install python2-virtualbmcAko vaša OS ne može da pronađe paket, dodajte repozitorij:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSada konfigurišemo alatku. Ovdje je sve jednostavno do besmisla. Sada je logično da na listi vbmc nema nikakvih servera
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Da bi se oni pojavili, potrebno ih je ručno deklarisati na sledeći 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 komande jasna i bez objašnjenja. Međutim, za sada su sve naše sesije u statusu DOWN. Da bi prešle u status UP, potrebno je da ih uključite:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Pokrenuta je vBMC instanca za domenu control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Pokrenuta je vBMC instanca za domenu storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Pokrenuta je vBMC instanca za domenu storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Pokrenuta je vBMC instanca za domenu compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Pokrenuta je vBMC instanca za domenu compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Ime domene | Status | Adresa | Port |
+-------------+---------+---------+------+
| compute-1 | radi | :: | 7004 |
| compute-2 | radi | :: | 7005 |
| control-1 | radi | :: | 7001 |
| storage-1 | radi | :: | 7002 |
| storage-2 | radi | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#I poslednji korak — treba prilagoditi pravila vatrozida (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 ćemo ući u undercloud i proveriti da li sve radi. Adresa host mašine — 192.168.255.200, na undercloudu smo dodali potrebni paket ipmitool tokom pripreme za deployment:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Upravljačka jedinica napajanja je isključena
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Upravljačka jedinica napajanja: Uključeno
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Ime Status
----------------------------------------------------
6 dns-server radi
64 undercloud radi
65 control-1 radiKao što vidite, uspešno smo pokrenuli control čvor putem vbmc. Sada ćemo ga isključiti i nastaviti dalje:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Upravljačka jedinica napajanja: Isključeno
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Upravljačka jedinica napajanja je isključena
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Ime Status
----------------------------------------------------
6 dns-server radi
64 undercloud radi
- compute-1 isključen
- compute-2 isključen
- control-1 isključen
- storage-1 isključen
- storage-2 isključen
[root@hp-gen9 ~]#Sledeći korak — introspekcija čvorova na koje će se instalirati overcloud. Za to trebamo pripremiti json datoteku sa opisom naših čvorova. Imajte na umu da, za razliku od instalacije na praznim serverima, u datoteci je naveden port na kojem radi vbmc 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: na kontrolnom čvorištu postoje dva sučelja, ali u ovom slučaju to nije važno, u ovoj instalaciji nam je dovoljno i jedno.
Sada pripremamo json datoteku. Moramo navesti MAC adresu porta koji će se koristiti za proviziju, parametre čvorova, imenovati ih i navesti kako pristupiti IPMI:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Sada trebamo pripremiti slike za Ironic. Za to ih preuzimamo putem wget-a i instaliramo:
(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 ~]$Preuzimamo slike u undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~\/images\/
Image "overcloud-full-vmlinuz" je uploadan.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktivan |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" je uploadan.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktivan |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" je uploadan.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktivan |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" je uploadan.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktivan |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" je uploadan.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktivan |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Provjeravamo da li su sve slike učitane
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktivan |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktivan |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktivan |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktivan |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktivan |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Još jedan detalj — potrebno je dodati DNS poslužitelj:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI je zastario i bit će uklonjen u budućnosti. Umjesto toga upotrijebite openstack CLI.
Ažurirana podmreža: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Sada možemo dati naredbu za introspekciju:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Započeta Mistral Workflow tripleo.baremetal.v1.register_or_update. ID izvršenja: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Čekam poruke na redu 'tripleo' bez vremenskog ograničenja.
5 node(a) uspješno premješteno u stanje "upravljivo".
U uspjehu registriran čvor UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
U uspjehu registriran čvor UUID b89a72a3-6bb7-429a-93bc-48393d225838
U uspjehu registriran čvor UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
U uspjehu registriran čvor UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
U uspjehu registriran čvor UUID 766ab623-464c-423d-a529-d9afb69d1167
Čekam da introspekcija završi...
Započeta Mistral Workflow tripleo.baremetal.v1.introspect. ID izvršenja: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Čekam poruke na redu 'tripleo' bez vremenskog ograničenja.
Introspekcija čvora b89a72a3-6bb7-429a-93bc-48393d225838 završena. Status:SUCCESS. Greške:Nema
Introspekcija čvora 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e završena. Status:SUCCESS. Greške:Nema
Introspekcija čvora bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 završena. Status:SUCCESS. Greške:Nema
Introspekcija čvora 766ab623-464c-423d-a529-d9afb69d1167 završena. Status:SUCCESS. Greške:Nema
Introspekcija čvora b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 završena. Status:SUCCESS. Greške:Nema
Uspješno introspektivno 5 node(a).
Započeta Mistral Workflow tripleo.baremetal.v1.provide. ID izvršenja: f5594736-edcf-4927-a8a0-2a7bf806a59a
Čekam poruke na redu 'tripleo' bez vremenskog ograničenja.
5 node(a) uspješno premješteno u stanje "dostupno".
(undercloud) [stack@undercloud ~]$Kao što se može vidjeti iz izlaza, sve je završeno bez grešaka. Provjerimo jesu li svi nalozi u stanju dostupno:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Naziv | UUID instancije| Stanje napajanja | Stanje nabave | Održavanje |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | kontrola-1| None | isključen | dostupno | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | skladište-1| None | isključen | dostupno | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | skladište-2| None | isključen | dostupno | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | obrada-1 | None | isključen | dostupno | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | obrada-2 | None | isključen | dostupno | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Ako su čvorovi u drugom stanju, obično upravljivom, to znači da nešto nije u redu i potrebno je provjeriti logove kako bismo shvatili zašto je došlo do toga. Imajte na umu da u ovom scenariju koristimo virtualizaciju i mogu postojati greške povezane s korištenjem virtualnih strojeva ili vbmc-a.
Dalje, trebamo odrediti koja će čvor obavljati koju funkciju — to jest, odrediti profil s kojim će se čvor postavljati:
(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 ~]$Postavljamo 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 jesmo li sve ispravno napravili:
(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 u redu, dajemo naredbu za implementaciju overcloud-a:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuU stvarnoj instalaciji naravno će se koristiti prilagođene predloške, u našem slučaju to će vrlo otežati proces jer će biti potrebno objasniti svaku promjenu u predlošku. Kao što je ranije napisano — čak će nam jednostavna instalacija biti dovoljna da vidimo kako to funkcionira.
Napomena: varijabla —libvirt-type qemu je u ovom slučaju potrebna jer ćemo koristiti nested virtualizaciju. U suprotnom, virtualne mašine neće moći pokrenuti.
Sada imate oko sat vremena, a možda i više (ovisno o mogućnostima hardvera) i trebate se nadati da ćete nakon toga vidjeti sljedeću poruku:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stvaranje CREATE završeno uspješno
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 nije pronađen u /home/stack/.ssh/known_hosts
Započeta Mistral Workflow tripleo.deployment.v1.get_horizon_url. ID izvršenja: fcb996cd-6a19-482b-b755-2ca0c08069a9
Endpoint za Overcloud: http://192.168.255.21:5000/
URL za Horizon Dashboard Overcloud-a: http://192.168.255.21:80/dashboard
Rc datoteka za Overcloud: /home/stack/overcloudrc
Overcloud je implementiran
(undercloud) [stack@undercloud ~]$Sada imate gotovo punu verziju OpenStack-a na kojoj možete učiti, provoditi eksperimente itd.
Provjerimo radi li sve u redu. U matičnoj direktoriji korisnika stack postoje dvije datoteke — jedna je stackrc (za upravljanje undercloud-om) i druga overcloudrc (za upravljanje overcloud-om). Te datoteke treba navesti kao source, jer sadrže potrebne informacije 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 ~]$U mojoj instalaciji još treba dodati jedan mali korak — dodati rutu na kontroleru, jer se mašina s kojom radim nalazi u drugoj mreži. Da bismo to uradili, ući ćemo na control-1 s računom heat-admin i dodati rutu.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Posljednja prijava: Pet Kol 14 09:47:40 2020 od 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.254Sada možete pristupiti horizontalnom sustavu. Sve informacije – adrese, korisničko ime i lozinka – nalaze se u datoteci /home/stack/overcloudrc. Konačna shema izgleda ovako:
Usput, u našoj instalaciji, adrese strojeva dodjeljuju se putem DHCP-a i, kao što vidite, dodjeljuju se "kako god ispada". Možete u predlošku čvrsto odrediti koju adresu koji stroj treba dodijeliti tijekom implementacije, ako vam je to potrebno.
Kako se promet kreće između virtualnih strojeva?
U ovom članku razmotrit ćemo tri opcije prolaska prometa.
- Dva stroja na jednom hipervizoru unutar jedne L2 mreže.
- Dva stroja na različitim hipervizorima unutar jedne L2 mreže.
- Dva stroja unutar različitih mreža (rutiranje između mreža).
Kase s izlazom u vanjski svijet putem vanjske mreže, s korištenjem plovnih adresa, kao i distribuirano rutiranje razmotrit ćemo sljedeći put, za sada ćemo se zaustaviti na unutarnjem prometu.
Za provjeru sastavit ćemo ovakvu shemu:
Imamo četiri virtualne mašine — 3 unutar jedne L2 mreže — net-1, i još 1 unutar mreže net-2.
(overcloud) [stack@undercloud ~]$ nova lista --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Ime | ID stanara | Status | Task State | Power State | Mreže |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVAN | - | Pokreće se | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVAN | - | Pokreće se | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVAN | - | Pokreće se | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVAN | - | Pokreće se | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Pogledajmo na kojim se hipervizorima nalaze stvorene 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 ~]$
Virtualne mašine vm-1 i vm-3 se nalaze na compute-0, a mašine vm-2 i vm-4 se nalaze na node-1.
Osim toga, stvoren je virtualni usmjerivač za omogućavanje usmjeravanja između navedenih mreža:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Usmjerivač ima dva virtualna porta koja djeluju kao prolazi 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 ~]$ No prije nego što pogledamo kako se kreće promet, razmotrite što imamo u ovom trenutku na kontrolnoj nodi (koja je ujedno i network node) i na compute nodi. Počnimo s compute nodom.
[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 na čvoru postoje tri ovs mosta — br-int, br-tun, br-ex. Kao što vidimo, između njih postoji skup sučelja. Radi jednostavnosti, prenijet ćemo sva ta sučelja na shemu i vidjeti što ćemo dobiti.
Na adresama na kojima su podignuti VxLAN tuneli vidljivo je da je jedan tunel podignut na compute-1 (192.168.255.26), a drugi tunel gleda prema control-1 (192.168.255.15). Međutim, najzanimljivije je to što br-ex nema fizičkih sučelja, a ako pogledamo koji su protokoli podešeni, vidljivo je da ovaj most trenutno može samo odbaciti promet.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163 mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Kako se može vidjeti iz ispisa, adresa je direktno vezana na fizičku port, a ne na virtualno mostno sučelje.
[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 dolazi iz porta phy-br-ex potrebno je odbaciti.
U ovom mostu trenutno ne može biti prometa osim iz ovog sučelja (veza s br-int), a sudeći prema odbijanjima, u mostu je već bilo BUM prometa.
To znači da promet s ove čvorne točke može napustiti samo putem VxLAN tunela i nikako drugačije. Međutim, ako uključimo DVR, situacija će se promijeniti, ali tim se bavimo neki drugi put. Kada se koristi izolacija mreža, na primjer, pomoću VLAN-a, imat ćete više L3 sučelja u VLAN-u 0, a ne jedno. Međutim, VxLAN promet će izlaziti iz čvora na isti način, ali također će biti enkapsuliran u neki dodijeljeni VLAN.
S compute čvorom smo završili, prelazimo na control č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 ~]$U suštini, može se reći da je sve isto, međutim IP adresa se više ne nalazi na fizičkom sučelju, već na virtualnom mostu. To je učinjeno jer je ova port povezana s portom putem kojeg će promet izlaziti u vanjski svijet.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Ova port je povezana na most br-ex i budući da nema VLAN oznaka, ta port je trunk port na kojem su svi VLAN-ovi dozvoljeni, trenutno promet izlazi van bez oznake, što ukazuje na vlan-id 0 u gornjem ispisu.
Sve ostalo trenutno je slično compute čvoru — isti mostovi, isti tuneli koji idu na dva compute čvora.
O čvorovima za pohranu u ovom članku nećemo govoriti, ali za razumijevanje potrebno je reći da je mrežni dio tih čvorova dosadno jednostavan. U našem slučaju postoji samo jedna fizička priključna točka (eth0) s dodijeljenom IP adresom. Tu nema nikakvih VxLAN tunela, tunelskih bridževa itd. — općenito, ovdje nema OVS-a jer to nema smisla. Kada koristimo izolaciju mreža — na ovom čvoru bit će dva sučelja (fizičke portove, bodove, ili samo dva VLAN-a — to nije važno — ovisi o tome što želite) — jedan za upravljanje, drugi za promet (upis na disk VM, čitanje s diska itd.).
Razjasnili smo što imamo na čvorovima u odsustvu bilo kakvih usluga. Sada ćemo pokrenuti 4 virtualne mašine i vidjeti kako će se opisani raspored promijeniti — trebali bi se pojaviti portovi, virtualni usmjerivači itd.
Naša mreža trenutno izgleda ovako:
Imamo po dvije virtualne mašine na svakom računalnom čvoru. Na primjeru compute-0 pogledajmo 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 jedno virtualno sučelje — tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Ovo sučelje gleda u Linux bridge:
[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 se može vidjeti iz izlaza, u bridu postoje samo dva sučelja — tap95d96a75-a0 i qvb95d96a75-a0.
Tu se malo treba osvrnuti na tipove virtualnih mrežnih uređaja u OpenStacku:
vtap — virtualno sučelje povezano s instancom (VM)
qbr — Linux bridge
qvb i qvo — vEth par povezan s Linux bridgeom i Open vSwitch bridgeom
br-int, br-tun, br-vlan — Open vSwitch bridževi
patch-, int-br-, phy-br- — Open vSwitch patch-sučeva koja povezuju bridževe
qg, qr, ha, fg, sg — portovi Open vSwitcha koji se koriste za povezivanje virtualnih uređaja s OVS-om
Kako razumijete, ako imamo port qvb95d96a75-a0 u bridge-u koji je vEth par, onda negdje postoji njegova suprotna strana koja bi logično trebala biti nazvana qvo95d96a75-a0. Pogledajmo koji portovi postoje na OVS-u.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kao što vidimo, port se nalazi u br-int. Br-int igra ulogu prekidača koji završava portove virtualnih mašina. Osim qvo95d96a75-a0, u izlazu je vidljiv port qvo5bd37136-47. To je port za drugu virtualnu mašinu. Rezultantna shema sada izgleda ovako:
Pitanje koje bi odmah trebalo zanimati pažljivog čitatelja je - zašto je potrebna linux bridge između porta virtualne mašine i porta OVS-a? Činjenica je da se za zaštitu mašine koriste sigurnosne grupe, koje nisu ništa drugo nego iptables. OVS ne radi s iptables, pa je stvoren takav "zaobilazni put". Međutim, to svoje mesto polako gubi — dolazi mu u zamenu conntrack u novim verzijama.
Dakle, na kraju, shema izgleda ovako:
Dva stroja na jednom hipervizoru unutar jedne L2 mreže.
Budući da se dve VM nalaze u istoj L2 mreži i na istom hipervizoru, logično će promet između njih ići lokalno kroz br-int, jer će oba uređaja 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 ~]$ Dva stroja na različitim hipervizorima unutar jedne L2 mreže.
Sada pogledajmo kako će promet ići između dve mašine u istoj L2 mreži, ali smeštenih na različitim hipervizorima. Da budem iskren, zapravo se ništa značajno neće promeniti, jednostavno će promet između hipervizora ići kroz vxlan tunel. Pogledajmo na primeru.
Adresa virtualnih mašina između kojih ćemo pratiti promet:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Sučelje Tip Izvor Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Pogledajmo tablicu preusmjeravanja u br-int na compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]$Promet bi trebao ići u port 2 — provjerimo 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 ~]$To je patch-tun — dakle, sučelje u br-tun. Pogledajmo što se događa s paketom na br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Paket se upakira u VxLAN i šalje u port 2. Pogledajmo kamo 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 ~]$To 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 pogledajmo što se dalje događa s paketom:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ MAC adresa je u tablici preusmjeravanja br-int na compute-1, i kao što se može vidjeti iz izdanog, vidljiv je kroz port 2, koji je port prema br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46I na kraju, gledamo što ima u br-int na compute-1 gdje se nalazi MAC adresa odredišta:
[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 ~]$ Dakle, primljeni paket će otići u port 3, gdje se već nalazi virtualna mašina instance-00000003.
Savršeno zavarivanje OpenStacka za proučavanje na virtualnoj infrastrukturi je u tome što bez problema možemo uhvatiti promet između hipervizora i vidjeti što se događa s njim. To ćemo sada učiniti, pokrenut ćemo tcpdump na vnet portu prema compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Prvi redak pokazuje da paket s adrese 10.0.1.85 ide na adresu 10.0.1.88 (ICMP promet), pri čemu je omotan u VxLAN paket s vni 22, a paket ide s hosta 192.168.255.19 (compute-0) na host 192.168.255.26 (compute-1). Možemo provjeriti da VNI odgovara onome što je navedeno u ovs.
Vratimo se na ovaj redak actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 — to je vni u heksadecimalnom sustavu. Pretvorimo ovaj broj u decimalni sustav:
16 = 6*16^0+1*16^1 = 6+16 = 22Dakle, vni je u skladu sa stvarnošću.
Drugi redak pokazuje obrnut promet, no nema potrebe objašnjavati, to je i tako jasno.
Dva uređaja u različitim mrežama (routanje između mreža)
Zadnji slučaj za danas — to je routanje između mreža unutar jednog projekta uz korištenje virtualnog usmjerivača. Razmatramo slučaj bez DVR-a (o njemu ćemo govoriti u drugom članku), zato se routanje odvija na network čvoru. U našem slučaju network čvor nije istaknut kao posebna entitet i nalazi se na control čvoru.
Za početak, provjerimo radi li routanje:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msBudući da u ovom slučaju paket treba otići na gateway i tamo biti usmjeren, trebamo znati MAC adresu gatewaya, pa ćemo provjeriti ARP tablicu u instanci:
$ 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 ćemo pogledati kamo bi trebao biti usmjeren promet s 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 kamo 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 jasno, promet odlazi u br-tun. Pogledajmo u koji vxlan tunel će biti upakiran:
[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 kontrolnu nodu:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Promet je stigao do kontrolne node, tako da trebamo preći na nju i pogledati kako će se odvijati usmjeravanje.
Kao što se sjećate, kontrolna nodna iznutra izgledala je identično compute nodi — iste tri mrežne brige, samo što je br-ex imao fizički port preko kojeg je nod mogao slati promet vani. Kreiranje instanci promijenilo je konfiguraciju na compute nodama — dodani su linux bridge, iptables i sučelja u nodama. Kreiranje mreža i virtualnog usmjerivača također je ostavilo svoj trag na konfiguraciji kontrolne node.
Dakle, očito je da MAC adresa gatewaya mora biti u tablici prosljeđivanja br-int na kontrolnoj nodi. Provjerimo ima li je i gdje gleda:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ MAC je vidljiv iz porta qr-0c52b15f-8f. Ako se vratimo na popis virtualnih portova u Openstacku, ovaj tip porta se koristi za povezivanje različitih virtualnih uređaja na OVS. Točnije, qr — je port prema virtualnom usmjerivaču, koji se prikazuje u obliku namespacea.
Pogledajmo koje namespaceove imamo 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 ~]$ Tri instanice. No, s obzirom na imena, može se naslutiti svaka njihova svrha. Na instance s ID-om 0 i 1 vratit ćemo se kasnije, a sada nas zanima namespace 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 ~]$ U ovom namespaceu postoje dva interna interfejsa koja smo ranije kreirali. Oba virtualna porta su dodana u br-int. Provjerimo MAC adresu porta qr-0c52b15f-8f, budući da se, prema odredišnoj MAC adresi, promet upućivao upravo 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 mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Dakle, u ovom slučaju sve funkcioniše prema pravilima standardne rutiranja. Budući da je promet usmjeren prema hostu 10.0.2.8, trebao bi izaći kroz drugi interfejs qr-92fa49b5-54 i otići kroz vxlan tunel na compute nodu:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Sve je logično, bez iznenađenja. Pogledajmo odakle je vidljiv MAC adresa hosta 10.0.2.8 u br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Kao što je i očekivano, promet ide u br-tun, provjerimo u koji će tunel promet ići 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 ~]$ Promet prolazi kroz tunel do compute-1. A na compute-1 je sve jednostavno — iz br-tun paket dolazi do br-int i odatle do sučelja virtualne 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 je li ovo doista ispravno sučelje:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$ Dakle, prošli smo cijeli put paketa. Mislim da ste primijetili da je promet išao kroz različite vxlan tunele i izlazio s različitim VNI-jem. Pogledajmo koji su to VNI-ji, a zatim ćemo prikupiti dump na portu kontrolne čvor i uvjeriti se da promet prolazi onako kako je opisano iznad.
Dakle, tunel do compute-0 ima sljedeći actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Pretvorimo 0x16 u decimalni sustav:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel do compute-1 ima sljedeći VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Pretvorimo 0x63 u decimalni sustav:
0x63 = 3*16^0+6*16^1 = 3+96 = 99I sada pogledajmo 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 s hosta 192.168.255.19 (compute-0) na host 192.168.255.15 (control-1) s vni 22, unutar kojeg je pakiran ICMP paket s hosta 10.0.1.85 na host 10.0.2.8. Kao što smo ranije izračunali, vni odgovara onome što smo vidjeli u izlazima.
Drugi paket je vxlan paket s hosta 192.168.255.15 (control-1) na host 192.168.255.26 (compute-1) s vni 99, unutar kojeg je pakiran ICMP paket s hosta 10.0.1.85 na host 10.0.2.8. Kao što smo ranije izračunali, vni odgovara onome što smo vidjeli u izlazima.
Sljedeća dva paketa predstavljaju povratni promet s 10.0.2.8 na 10.0.1.85.
Dakle, na kraju imamo ovakvu shemu control čvora:
Izgleda da je sve? Zaboravili smo na dva namespace:
[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 ~]$ Kao što smo govorili o arhitekturi oblaka – bilo bi dobro da strojevi automatski dobivaju adrese od DHCP poslužitelja. Ovo su dva DHCP poslužitelja za naše dvije mreže 10.0.1.0/24 i 10.0.2.0/24.
Provjerimo da li je to tako. U ovom namespace-u postoji samo jedna adresa — 10.0.1.1 — adresa samog DHCP poslužitelja, i ona je također uključena u br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163 mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Pogledajmo procese koji u svom nazivu imaju qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 na kontrolnoj nodi:
[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 proces i na temelju informacija prikazanih u prethodnom isječku možemo, na primjer, vidjeti što imamo u najmu trenutno:
[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 ~]$Na kraju, dobivamo ovakav set usluga na kontrolnoj nodi:
I imajte na umu da je ovo samo 4 mašine, 2 unutrašnje mreže i jedan virtuelni ruter… Trenutno nemamo spoljne mreže, hrpu različitih projekata, svaki sa svojim mrežama (koje se preklapaju), a distribuirani ruter nam je isključen, naposljetku, u testnom okruženju je bila samo jedna kontrolna nod, jer za otpornost na greške trebas imati kvorum od tri noda. Logično je da je u komercijalnim uslovima sve "malo" složenije, ali na ovom jednostavnom primjeru razumijemo kako to treba raditi — bilo da imate 3 ili 300 namespace-a, to je naravno važno, ali s gledišta funkcionisanja cijele konstrukcije - ništa se posebnog neće promijeniti... osim ako ne instalirate neki vendor SDN. Ali to je već sasvim druga priča.
Nadam se da je bilo interesantno. Ako imate primjedbe/dopune ili ako sam negdje očigledno lagao (ja sam čovjek i moje mišljenje će uvijek biti subjektivno) — pišite šta treba ispraviti/dodati — sve ćemo ispraviti/dodati.
Na kraju, želio bih reći nekoliko riječi o upoređivanju OpenStack-a (bilo da je standardni ili vendor) s clouds rješenjem kompanije VMWare — previše puta su mi postavljali ovo pitanje u posljednje dvije godine i iskreno sam se već umorio od toga, ali svejedno. Po mom mišljenju, veoma je teško uporediti ova dva rješenja, ali se može nedvosmisleno reći da postoje nedostaci u oba rješenja, i prilikom odabira nekog rješenja treba sagledati sve prednosti i mane.
Ako je OpenStack zajednica vođeno rješenje, VMWare ima pravo raditi samo ono što želi (čitaj — ono što je njima korisno) i to je logično — jer je to komercijalna kompanija koja je navikla zarađivati novac na svojim klijentima. Ali ovdje postoji jedna velika i debela NAPOMENA — možete napustiti OpenStack, na primjer, od Nokie i sa malo truda preći na rješenje od, recimo, Junipera (Contrail Cloud), ali napustiti VMWare teško da će vam uspjeti. Za mene ova dva rješenja izgledaju ovako — OpenStack (vendor) je jednostavna kavez, u kojem vas zatvaraju, ali imate ključ i možete izaći u svakom trenutku. VMWare — to je zlatna kavez, ključ od kaveza je kod vlasnika i koštaće vas veoma skupo.
Ne propagiram nijedan od proizvoda - vi birate ono što vam treba. Ali da sam na tom izboru, izabrao bih oba rješenja - VMWare za IT oblak (mali opterećenja, jednostavno upravljanje), OpenStack od nekog dobavljača (Nokia i Juniper nude prilično dobre paketne rješenja) - za Telekom oblak. Ne bih koristio OpenStack za čist IT - to je kao pucati iz topa na vrabce, no ne vidim drugih prigovora osim nepotrebnosti - iako to je zaista isuviše. Međutim, korištenje VMWare u telekomu - kao nositi šljunak u Ford Raptor - lijepo izgleda, ali vozač mora napraviti 10 odlazaka umjesto jednog.
Po mom mišljenju, najveći nedostatak VMWare-a je njegova potpuna zatvorenost - kompanija neće pružiti nikakve informacije o tome kako je, na primjer, vSAN ili što se nalazi u jezgri hipervizora - to im jednostavno nije isplativo - to znači da nikada nećete postati stručnjak za VMWare - bez podrške dobavljača ste proklet (vrlo često srećem stručnjake za VMWare koji posrću pred banalnim pitanjima). Za mene je VMWare kao kupovina automobila s poklopcem zatvorenim na ključ - da, moguće je da imate stručnjake koji mogu promijeniti spojku, ali samo onaj tko vam je prodao ovo rješenje može otvoriti poklopac. Osobno, ne volim rješenja u koja ne mogu zaviriti. Možda ćete reći da vam možda neće trebati zaviriti pod poklopac. Da, to je moguće, ali gledaću vas kada budete morali sastaviti veliku funkciju u oblaku od 20-30 virtualnih mašina, 40-50 mreža, od kojih polovica želi izaći van, a druga polovina traži SR-IOV ubrzanje inače ćete trebati još nekoliko desetina takvih mašina - inače neće biti dovoljno performansi.
Postoje i druga mišljenja, stoga je samo vama na izbor što odabrati i najvažnije - vi ste odgovorni za svoj izbor. Ovo je samo moje mišljenje - nekoga tko je vidio i dotakao najmanje 4 proizvoda - Nokia, Juniper, Red Hat i VMWare. Dakle, imam s čime usporediti.
Izvor: habr.com
