Oblačne tehnologije sve više i više prodiru u naše živote i verovatno nema nijedne osobe koja barem jednom nije koristila neke oblačne usluge. Ipak, šta je zapravo oblak i kako on funkcioniše, većina ljudi zna vrlo malo, čak i na osnovnom nivou. 5G postaje stvarnost i telekomunikaciona infrastruktura počinje da prelazi sa klasičnih rešenja na oblačna rešenja, kao što se nekad prelazilo sa potpuno hardverskih rešenja na virtualizovana „stubove“.
Danas ćemo razgovarati o unutrašnjem svetu oblačne infrastrukture, posebno ćemo razmotriti osnove mrežne komponente.
Šta je oblak? Da li je to ista virtualizacija — pogled iz profila?
Više nego logično pitanje. Ne — to nije virtualizacija, iako bez nje nije prošlo. Razmotrićemo dve definicije:
Oblačna računanja (dalje Oblačno) — to je model pružanja jednostavnog pristupa korisnicima distribuiranim računarstvenim resursima, koji moraju biti raspoređeni i pokrenuti na zahtev uz minimalno moguće kašnjenje i minimalne troškove sa strane provajdera usluga.
Virtualizacija — to je mogućnost deljenja jedne fizičke jednice (na primer, servera) na nekoliko virtuelnih, čime se povećava iskorišćenost resursa (na primer, ako ste imali 3 servera, opterećenih sa 25-30 procenata, nakon virtualizacije dobijate 1 server, opterećenog sa 80-90 procenata). Naravno, virtualizacija uzima deo resursa — potrebno je hraniti hipervizor, međutim, kao što pokazuje praksa, igra se isplati. Savršen primer virtualizacije je VMWare, koja odlično priprema virtuelne mašine, ili na primer KVM, koji mi se više dopada, ali to je već stvar ukusa.
Koristimo virtualizaciju a da toga nismo svesni, pa čak i hardverski ruteri već koriste virtualizaciju — na primer, u poslednjim verzijama JunOS operativni sistem se postavlja kao virtuelna mašina iznad real-time Linux distribucije (Wind River 9). Međutim, virtualizacija — to nije oblak, ali oblak ne može postojati bez virtualizacije.
Virtualizacija — to je jedna od komponenti na kojoj se oblak gradi.
Ustvarjanje oblačnega sistema preprosto z združevanjem več hipervizorjev v eno L2 domeno, dodajanjem nekaj yaml skriptov za avtomatsko konfiguracijo VLAN-ov preko Ansible in vključitvijo sistema za orkestracijo za avtomatsko ustvarjanje virtualnih strojev - ne bo delovalo. Natančneje, to bo delovalo, vendar bo nastali Frankenstein - ni tisto oblačno okolje, ki ga potrebujemo, čeprav morda nekaterim ustreza. Če pa pogledamo Openstack - je v osnovi še en Frankenstein, ampak pustimo to za zdaj.
Vendar razumem, da iz zgoraj navedenega opisa ni povsem jasno, kaj dejansko lahko štejemo za oblak.
Zato v dokumentu NIST (Nacionalni inštitut za standarde in tehnologijo) navajajo 5 osnovnih značilnosti, ki jih mora imeti oblačna infrastruktura:
Nuditev storitev po povpraševanju. Uporabniku mora biti omogočen prost dostop do dodeljenih računalniških virov (kot so omrežja, virtualni diski, pomnilnik, procesorska jedra itd.), pri čemer morajo biti ti viri na voljo samodejno - torej brez posredovanja ponudnika storitev.
Široka dostopnost storitve. Dostop do virov mora biti omogočen z standardnimi mehanizmi, kar omogoča uporabo tako standardnih računalnikov kot tankih odjemalcev in mobilnih naprav.
Zagotavljanje virov v bazene. Bazeni virov morajo omogočati hkratno dodeljevanje virov več strankam, zagotavljajoč izolacijo strank in brez medsebojnih vplivov ter konkurence za vire. V bazene so vključena tudi omrežja, kar pomeni možnost uporabe prekrivajoče se naslove. Bazeni morajo podpirati razširjanje na zahtevo. Uporaba bazenov omogoča dosego potrebne ravni odpornosti virov ter abstrahiranje fizičnih in virtualnih virov - prejemnik storitve preprosto dobi zahtevan paket virov (kje so ti viri fizično locirani, na koliko strežnikih in stikalih - to stranka ne zanima). Vendar pa je treba upoštevati dejstvo, da mora ponudnik zagotoviti pregledno rezervacijo teh virov.
Hitro prilagajanje različnim pogojem. Storitve morajo biti fleksibilne — hitro zagotavljanje virov, njihovo prerazporeditev, dodajanje ali zmanjšanje virov na zahtevo stranke, pri čemer mora stranka imeti občutek, da so viri oblakov neskončni. Za lažje razumevanje, na primer, ne vidite opozorila, da vam je v Apple iCloud zmanjkalo delovnega prostora, ker je na strežniku odpovedal trdi disk, trdi diski pa se pokvarijo. Poleg tega so možnosti te storitve z vaše strani praktično neomejene — potrebujete 2 TB — ni problema, plačate in dobite. Podobno lahko navedemo primer z Google Drive ali Yandex Disk.
Možnost merjenja zagotovljene storitve. Oblačni sistemi morajo samodejno nadzorovati in optimizirati porabljene vire, pri čemer morajo biti ti mehanizmi pregledni tako za uporabnika kot tudi za ponudnika storitev. To pomeni, da lahko kadar koli preverite, koliko virov porabite vi in vaši kupci.
Upoštevati je potrebno dejstvo, da so ti zahteve večinoma zahteve za javni oblak, zato se lahko te zahteve za privatni oblak (to je oblak, ki ga za notranje potrebe podjetja zaženejo) nekoliko prilagodijo. Kljub temu morajo biti izpolnjene, drugače ne bomo imeli vseh prednosti oblačnih računalništva.
Zakaj potrebujemo oblak?
Vendar pa je vsaka nova ali že obstoječa tehnologija, vsak nov protokol zasnovan z namenom (razen RIP-ng, seveda). Protokol za protokol — nikomur ni potreben (razen RIP-ng, seveda). Logično je, da je oblak zasnovan za zagotavljanje neke storitve uporabniku/stranki. Vsi smo se srečali vsaj z nekaj oblačnimi storitvami, na primer Dropbox ali Google Docs, in domnevam, da jih večina uspešno uporablja — na primer ta članek je napisan z uporabo oblačne storitve Google Docs. Vendar so znane oblačne storitve le del sposobnosti oblaka — natančneje, to je le storitev tipa SaaS. Oblak lahko zagotovimo na tri načine: v obliki SaaS, PaaS ali IaaS. Kateri servis točno potrebujete, je odvisno od vaših želja in možnosti.
Poglejmo vsakega posebej:
Programska oprema kot storitev (SaaS) — je model zagotavljanja celotne storitve strankam, na primer poštna storitev, kot sta Yandex.Mail ali Gmail. V takšnem modelu zagotavljanja storitve vi, kot stranka, dejansko ne naredite nič drugega, kot da uporabljate storitev — torej vam ni treba razmišljati o nastavitvi storitve, njeni odpornosti na napake ali rezervacijah. Glavno je, da ne kompromitirate svojega gesla, vse ostalo bo poskrbel ponudnik te storitve. Z vidika ponudnika storitve — on je popolnoma odgovoren za celotno storitev — od strežniške opreme in gostiteljskih operacijskih sistemov do nastavitev zbirk podatkov in programske opreme.
Platform as a Service (PaaS) — pri uporabi tega modela ponudnik storitev stranki zagotovi predlogo za storitev, na primer vzemimo spletni strežnik. Ponudnik storitev je stranki zagotovil virtualni strežnik (dejansko nabor virov, kot so RAM/CPU/Storage/Networks itd.) in celo namestil operacijski sistem in potrebno programsko opremo na ta strežnik, vendar mora vse to nastaviti sama stranka in za delovanje storitve je že odgovorna stranka. Ponudnik storitev, kot v prejšnjem primeru, odgovarja za delovanje fizične opreme, hipervizorjev, same virtualne naprave, njeno omrežno dostopnost itd., toda sama storitev je že izven njegove odgovornosti.
Infrastructure as a Service (IaaS) — ta pristop je že zanimivejši, dejansko ponudnik storitev stranki zagotavlja popolno virtualizirano infrastrukturo — torej nek nabor (bazeni) virov, kot so CPU Cores, RAM, Networks itd. Vse ostalo je stvar stranke — kar stranka želi narediti s temi viri v okviru dodeljenega ji bazena (kvote) — ponudnika to ne zanima preveč. Če želi stranka ustvariti svoj lastni vEPC ali pa kar sploh postati mini operater in nuditi telekomunikacijske storitve — ni problema — delaj. V takšnem scenariju ponudnik storitev odgovarja za zagotavljanje virov, njihovo odpornost na napake in dostopnost, kot tudi za operacijski sistem, ki omogoča združitev teh virov v bazene in njihovo zagotavljanje stranki z možnostjo kadar koli povečati ali zmanjšati vire na zahtevo stranke. Vse virtualne naprave in ostalo opremo stranka nastavi sama preko portala samooskrbe in konzole, vključno s konfiguracijo omrežij (razen zunanjih omrežij).
Kaj je OpenStack?
Vsak od treh variant zahteva operacijski sistem, ki omogoča ustvarjanje oblačne infrastrukture. V resnici pa pri SaaS za celoten tehnologijski sklad ne odgovarja ena sama enota — obstaja enota, ki je odgovorna za infrastrukturo — torej zagotavlja IaaS drugi enoti, ta enota pa nato stranki zagotavlja SaaS. OpenStack je eden od oblačnih operacijskih sistemov, ki omogoča združevanje številnih preklopnikov, strežnikov in shramb v enoten vir, delitev tega skupnega vira na podsklope (tenante) ter zagotavljanje teh virov strankam prek omrežja.
OpenStack — je oblačni operacijski sistem, ki omogoča nadzor nad velikimi bazami računalniških virov, podatkovnimi shrambe in omrežnimi viri, katere upravljamo preko API-jev z uporabo standardnih mehanizmov overjanja.
Drugimi besedami, to je niz projektov odprtokodne programske opreme, ki so zasnovani za ustvarjanje oblačnih storitev, (tako javnih kot tudi zasebnih) — torej niz orodij, ki omogočajo združevanje strežniške in preklopne opreme v enoten vir virov, upravljanje teh virov ter zagotavljanje potrebne ravni odpornosti na napake.
Ob časopisu te vsebine ima struktura OpenStack naslednjo obliko:
Slika je bila prevzeta z
Vsaka od komponent, ki sestavljajo OpenStack, opravlja določeno funkcijo. Takšna distribucijska arhitektura omogoča vključitev tistega sklopa funkcionalnih komponent, ki jih potrebujete. Vendar pa je del komponent koreninskih komponent in njihovo odstranjevanje bo povzročilo popolno ali delno nezmožnost delovanja celotne rešitve. Takšne komponente običajno vključujejo:
- Nadzorna plošča — GUI na osnovi spletnega vmesnika za upravljanje OpenStack storitev
- Keystone — centralizirana identifikacijska storitev, ki zagotavlja funkcionalnosti overjanja in avtorizacije za druge storitve ter upravlja uporabniške podatke in njihove vloge.
- Neutron — omrežna storitev, ki zagotavlja povezljivost med vmesniki različnih storitev OpenStack (vključno s povezljivostjo med VM in dostopom do zunanjega sveta)
- Cinder — zagotavlja dostop do blokovnega shranjevanja za virtualne strežnike
- Nova — upravljanje životnim ciklusom virtualnih mašina
- Glance — skladište slika virtualnih mašina i snimaka
- Swift — pruža pristup objektima za skladištenje
- Ceilometer — usluga koja omogućava prikupljanje telemetrije i merenje dostupnih i korišćenih resursa
- Heat — orkestracija zasnovana na šablonima za automatsko kreiranje i pružanje resursa
Potpun spisak svih projekata i njihove namene možete videti .
Svaka od komponenti OpenStack-a je usluga koja je odgovorna za određenu funkciju i omogućava API za upravljanje tom funkcijom i interakciju te usluge s drugim uslugama oblaka, s ciljem stvaranja jedinstvene infrastrukture. Na primer, Nova upravlja računarskim resursima i nudi API za pristup konfiguraciji tih resursa, Glance – upravlja slikama i nudi API za upravljanje njima, Cinder – blok skladište i API za upravljanje njime itd. Sve funkcije su međusobno vrlo usko povezane.
Međutim, ako se razmisli, sve usluge pokrenute u OpenStack-u predstavljaju na kraju neku virtuelnu mašinu (ili kontejner) povezan s mrežom. Postavlja se pitanje — zašto nam je potrebno toliko elemenata?
Hajde da brzo prođemo kroz algoritam za kreiranje virtuelne mašine i povezivanje s mrežom i stalnim skladištem u OpenStack-u.
- Kada zatražite kreiranje mašine, bilo da je to zahtev putem Horizon-a (nadzorna ploča) ili zahtev putem CLI-a, prvo što se dešava — to je autorizacija vašeg zahteva na Keystone-u — da li možete da kreirate mašinu, da li imate pravo da koristite ovu mrežu, da li vam kvota vašeg projekta dozvoljava itd.
- Keystone izvršava autentifikaciju vašeg zahteva i generiše auth-token u odgovor, koji će se koristiti dalje. Nakon što je dobio odgovor od Keystone-a, zahtev se šalje ka Nova (nova API).
- Nova-api proverava validnost vašeg zahteva, obraćajući se Keystone-u, koristeći prethodno generisani auth-token.
- Keystone izvršava autentifikaciju i pruža na osnovu ovog auth-token-a informacije o dozvolama i ograničenjima.
- Nova-api kreira zapis o novoj VM u nova-bazi i prosleđuje zahtev za kreiranje mašine u nova-scheduler.
- Nova-scheduler izbira gostitelja (računalno vozilo), na katerem bo VM nameščen, na podlagi določenih parametrov, teža in con. Podatki o tem in identifikator VM se shranijo v nova-database.
- Nato nova-scheduler pošlje zahtevo nova-compute za namestitev instančne. Nova-compute se obrne na nova-conductor za pridobitev informacij o parametrih naprave (nova-conductor je komponenta nova, ki deluje kot proxy strežnik med nova-database in nova-compute, omejuje število zahtevkov proti nova-database, da se izognemo težavam s konsistentnostjo baze podatkov in zmanjšanju obremenitve).
- Nova-conductor pridobi zahtevane informacije iz nova-database in jih posreduje nova-compute.
- Nato nova-compute kontaktira glance za pridobitev ID slike. Glance izvede validacijo zahteve v Keystone in vrne zahtevane informacije.
- Nova-compute se obrne na neutron za pridobitev informacij o omrežnih parametrih. Tako kot glance, neutron izvede validacijo zahteve v Keystone, nato ustvari zapis v bazi (identifikator vrat itd.), ustvari zahtevo za ustvarjanje vrat in vrne zahtevane informacije nazaj v nova-compute.
- Nova-compute pošlje zahtevo cinder za dodelitev virtualnemu stroju volume. Tako kot glance, cinder izvede validacijo zahteve v Keystone, ustvari zahtevo za ustvarjanje volume in vrne zahtevane informacije.
- Nova-compute kontaktira libvirt z zahtevo za namestitev virtualnega stroja s podanimi parametri.
V praxi se zdá, že vytvoření jednoduchého virtuálního stroje je přímá operace, ale mění se v hurikán API volání mezi prvky cloudové platformy. Jak vidíte, i dříve zmíněné služby se skládají z menších komponentů, mezi kterými probíhá interakce. Vytvoření stroje je jen malou částí toho, co cloudová platforma umožňuje – existuje služba zodpovědná za vyvažování provozu, služba pro blokové úložiště, služba pro DNS, služba na provisioning bare metal serverů atd. Cloud vám umožňuje nahlížet na vaše virtuální stroje jako na stádo ovcí (na rozdíl od virtualizace). Pokud se ve virtuálním prostředí něco stane se strojem, obnovíte ho z backupů atd., cloudové aplikace jsou však navrženy tak, aby virtuální stroje nehráli tak důležitou roli – virtuální stroj „zemřel“ – není to problém – jednoduše se vytvoří nový stroj na základě šablony a, jak se říká, kontejnery si nevšimnou ztráty člena. To samozřejmě vyžaduje mechanismy orchestrace – pomocí Heat šablon můžete bez větších problémů nasadit složitou funkci, která se skládá z desítek sítí a virtuálních strojů.
Je vždy dobré mít na paměti, že cloudová infrastruktura bez sítě neexistuje – každý prvek nějakým způsobem interaguje s jinými prvky prostřednictvím sítě. Kromě toho má cloud naprosto nestatickou síť. Samozřejmě, že podkladová síť je ještě více-méně statická – nové uzly a switche se nepřidávají každý den, nicméně složka overlay může a nevyhnutelně se bude neustále měnit – budou přidávány nebo odstraňovány nové sítě, objevovat se nové virtuální stroje a „umírat“ staré. A jak si pamatujete z definice cloudu uvedené na začátku článku – prostředky by měly být uživatelům přidělovány automaticky a s co nejmenším (a lépe bez) zásahem ze strany poskytovatele služeb. To znamená, že typ poskytování síťových prostředků, který je nyní dostupný ve formě frontendové části vašeho osobního účtu přístupného přes http/https a dozorového síťového inženýra Vasila jako backendu – to není cloud, i s Vasilovými osmi rukama.
Neutron, kot omrežna storitev, zagotavlja API za upravljanje omrežnega dela oblačne infrastrukture. Storitev zagotavlja delovanje in upravljanje omrežnega dela Openstack ter ponuja raven abstrakcije, imenovano Network-as-a-Service (NaaS). To pomeni, da je omrežje prav tako virtualna merljiva enota kot na primer virtualna jedra CPU ali količina RAM.
Preden pa se lotimo arhitekture omrežnega dela OpenStack, se osredotočimo na to, kako to omrežje deluje v OpenStacku in zakaj je omrežje pomemben in neizogiben del oblaka.
Imamo torej dve virtualni napravi stranke RED in dve virtualni napravi stranke GREEN. Predpostavimo, da so te naprave razporejene na dveh hipervizorjih na naslednji način:
Trenutno gre le za virtualizacijo 4 strežnikov in nič več, saj smo zaenkrat le virtualizirali 4 strežnike, ki so razporejeni na dveh fizičnih strežnikih. Pri tem še niso povezani v omrežje.
Da bi dobili oblak, moramo dodati več komponent. Najprej moramo virtualizirati omrežni del — te 4 naprave moramo povezati v parih, pri čemer stranke želijo L2 povezavo. Seveda lahko uporabimo stikalo in nastavimo trunk proti njemu ter vse rešimo z linux bridge, ali pa za bolj izkušene uporabnike openvswitch (do njega se še vrnemo). Vendar pa lahko omrežij postane zelo veliko, in stalno potiskanje L2 skozi stikalo ni najboljša ideja — tako različne enote, servisna pisarna, mesečni časi za obdelavo zahtev, tedni odpravljanja težav — v sodobnem svetu tak pristop ne deluje. Zato bomo med hipervizorji vzpostavili L3 omrežje, preko katerega bodo komunicirale naše virtualne naprave, na to L3 omrežje pa bomo nadgradili virtualizirana L2 (overlay) omrežja, kjer bo potekal promet naših virtualnih naprav. Kot enkapsulacijo lahko uporabimo GRE, Geneve ali VxLAN. Za zdaj se bomo osredotočili na zadnjega, čeprav to ni posebej pomembno.
Potrebujemo nekje postaviti VTEP (upam, da so vsi seznanjeni s terminologijo VxLAN). Ker z strežnikov takoj pride L3 omrežje, nam nič ne preprečuje, da bi postavili VTEP na same strežnike, pri čemer OVS (OpenvSwitch) to odlično obvlada. Tako smo dobili to sestavo:
Ker traffic između VM mora biti razdvojen, portovi prema virtualnim mašinama će imati različite brojeve VLAN-a. Broj oznake igra ulogu samo unutar jednog virtualnog preklopnika, s obzirom na to da prilikom enkapsulacije u VxLAN to možemo lako ukloniti, jer ćemo imati VNI.
Sada možemo slobodno razmnožavati naše mašine i virtualne mreže za njih bez ikakvih problema.
Međutim, šta ako klijent ima još jednu mašinu, ali se nalazi u drugoj mreži? Potrebno nam je rutiranje između mreža. Razmotrićemo jednostavan scenarij kada se koristi centralizovano rutiranje — što znači da se saobraćaj rutira kroz posebne, rezervisane mrežne čvorove (obično su kombinovani sa kontrolnim čvorovima, pa ćemo imati isto to).
Naizgled nije ništa komplikovano — pravimo bridge interfejs na kontrolnom čvoru, šaljemo saobraćaj na njega i odatle ga rutiramo gde nam je potrebno. Ali problem je u tome š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činju nam se preklapati adresni prostori. Štaviše, klijenti ne žele da drugi klijenti mogu da se rutiraju u njihove unutrašnje mreže, što je razumljivo. Da bismo odvojili mreže i saobraćaj podataka klijenata, dodelićemo svakom od njih poseban namespace. Namespace je zapravo kopija mrežnog steka Linux-a, što znači da su klijenti u namespace RED potpuno izolovani od klijenata iz namespace GREEN (ili je rutiranje između tih mreža klijenata dozvoljeno preko default namespace-a ili već na višem transportnom uređaju).
Dakle, dobijamo ovakvu šemu:
L2 tuneli se spajaju iz svih računarskih čvorova na kontrolni čvor, gde se nalazi L3 interfejs za te mreže, svaki u dodeljenom namespace-u za izolaciju.
Vendar smo pozabili na najpomembnejše. Virtualni stroj mora zagotavljati storitev stranki, torej mora imeti vsaj en zunanji vmesnik, preko katerega ga lahko dosežemo. To pomeni, da se moramo povezati z zunanjim svetom. Tukaj imamo različne možnosti. Ustvarimo najprej najpreprostejšo možnost. Dodajmo strankam po eno omrežje, ki bo veljavna v omrežju ponudnika in se ne bo prekrivala z drugimi omrežji. Omrežja so lahko tudi prekrivajoča in gledajo v različne VRF na strani ponudnikovega omrežja. Ta omrežja bodo prav tako živela v imenskem prostoru vsake stranke. Vendar se bodo kljub vsemu povezovala z zunanjim svetom preko enega fizičnega (ali bond, kar je logičnejše) vmesnika. Da razdelimo promet strank, bo promet, ki gre navzven, označen z VLAN oznako, dodeljeno stranki.
Na koncu smo dobili takšno shemo:
Razumen vprašanje — zakaj ne bi naredili prehodov na samih računalniških vozlih? V tem ni velike težave, več kot to, ko je vklopljen porazdeljeni usmerjevalnik (DVR), bo to tako delovalo. V tem scenariju obravnavamo najpreprostejšo možnost s centraliziranim prehodom, ki se v OpenStacku uporablja privzeto. Za visoko obremenjene funkcije bodo uporabljali tako porazdeljeni usmerjevalnik kot tehnologije pospeševanja, kot sta SR-IOV in Passthrough, vendar, kot se pravi, je to že povsem druga zgodba. Najprej si poglejmo osnovni del, nato pa bomo šli v podrobnosti.
Naša shema je že delujoča, vendar obstaja nekaj podrobnosti:
- Moramo zaščiti naše naprave, torej na vmesnik stikala proti stranki namestiti filter.
- Omogočite samodejno pridobivanje IP naslova za virtualni stroj, da nam ne bo treba vsakič vstopati vanj preko konzole in vpisovati naslova.
Začnimo z zaščito naprav. Za to lahko uporabimo preproste iptables, zakaj pa ne.
Torej je naša topologija zdaj nekoliko zapletena:
Poglejmo naprej. Dodati moramo DHCP strežnik. Najbolj idealno mesto za postavitev DHCP strežnikov za vsako stranko bo že omenjena kontrolna vozlišča, kjer so postavljeni imenski prostori:
Vendar pa obstaja ena majhna težava. Kaj če se vse znova zažene in vse informacije o najemih naslovov na DHCP izginejo? Logično je, da bodo računalniki prejeli nove naslove, kar ni ravno priročno. Izhod sta dve možnosti — bodisi uporabiti domena imen in dodati DNS strežnik za vsakega odjemalca, takrat nam naslov ne bo pomemben (po analogiji z omrežjem v k8s) — vendar se tukaj pojavi težava z zunanjimi omrežji, saj lahko tudi tam naslovi pridobijo preko DHCP — potrebna je sinhronizacija z DNS strežniki v oblačni platformi in zunanjim DNS strežnikom, kar se mi zdi ni ravno fleksibilno, vendar povsem možno. Druga možnost je uporaba metapodatkov — torej shranjevanje informacij o podeljenem naslovu napravi, da bi DHCP strežnik vedel, kateri naslov dodeliti napravi, če je naprava že prejela naslov. Druga možnost je preprostejša in bolj fleksibilna, saj omogoča shranjevanje dodatnih informacij o napravi. Zdaj bomo shemi dodali metapodatke agenta:
Še eno vprašanje, ki ga je treba obravnavati — to je možnost, da vse stranke uporabljajo eno zunanje omrežje, saj bo za zunanja omrežja, če morajo biti veljavna v celotnem omrežju, prišlo do težav — vedno je treba dodeljevati in nadzorovati dodelitev teh omrežij. Možnost uporabe enotne zunanje predkonfigurirane mreže za vse stranke bi bila zelo koristna pri ustvarjanju javnega oblaka. To bo poenostavilo uvajanje naprav, saj nam ne bo treba preveriti baze podatkov o naslovih in izbrati unikatni naslovni prostor za zunanje omrežje vsake stranke. Poleg tega lahko zunanje omrežje definiramo vnaprej in ob uvajanju bo potrebno le še povezati zunanje naslove s stranskimi napravami.
In this situation, NAT comes to our aid — we simply enable clients to access the external world through the default namespace using NAT translation. However, there is a small issue. This works well if the client server operates as a client, meaning it initiates rather than receives connections. But in our case, it will be the opposite. In that case, we need to implement destination NAT so that when the control node receives traffic, it understands that this traffic is intended for client A's virtual machine, meaning a NAT translation must occur from the external address, for example, 100.1.1.1, to the internal address 10.0.0.1. In this way, although all clients will be using the same network, internal isolation is fully maintained. Therefore, we need to implement dNAT and sNAT on the control node. Using a single network along with floating address assignments or external networks or a combination of both depends on what you want to pull into the cloud. We will not include floating addresses in the scheme but will keep the already added external networks — each client has their own external network (represented in the scheme as VLANs 100 and 200 on the external interface).
As a result, we have developed an interesting and yet thoughtful solution that possesses certain flexibility but currently lacks mechanisms for fault tolerance.
Firstly, we have only one control node — its failure will lead to the collapse of all systems. To resolve this issue, we need to establish at least a quorum of three nodes. We will add this to the scheme:
Naturally, all nodes synchronize, and in the event of the active node going down, another node will take over its responsibilities.
Naslednja težava so diski virtualnih strojev. Trenutno so shranjeni na samih hipervizorjih in v primeru težav s hipervizorjem izgubimo vse podatke — in prisotnost RAID-a tukaj ne bo pomagala, če izgubimo ne disk, temveč celoten strežnik. Zato potrebujemo storitev, ki bo delovala kot sprednji del za kakršno koli shranjevanje. Kakšno shranjevanje bo to, nam ni posebej pomembno, ampak zaščititi mora naše podatke pred okvaro tako diska kot nod, morda celo cele omare. Možnosti je več — obstajajo seveda SAN omrežja s Fiber Channel, a bodimo iskreni — FC je že preživetje preteklosti — analog E1 v transportu — strinjam se, da se še uporablja, toda samo tam, kjer brez njega res ne gre. Zato se v letu 2020 ne bi odločil za prostovoljno postavitev FC omrežja, ob znanju o drugih bolj zanimivih alternativah. Čeprav vsakemu svoje in morda se najdejo tisti, ki menijo, da je FC z vsemi njegovimi omejitvami vse, kar potrebujemo — ne bom se prepiral, vsak ima svoje mnenje. Vendar se mi zdijo najbolj zanimiva rešitev uporaba SDS, na primer Ceph.
Ceph omogoča izgradnjo visoko dostopne rešitve za shranjevanje podatkov z množico možnosti za varnostno kopiranje, od kodov z napravami za preverjanje parnosti (analog RAID 5 ali 6) do popolne replikacije podatkov na različne diske ob upoštevanju postavitve diskov v strežnikih in strežnikov v omarah itd.
Za sestavo Ceph potrebujemo še 3 node. Interakcija s shranjevanjem bo potekala tudi preko omrežja z uporabo storitev blokovnega, objektnega in datotečnega shranjevanja. Dodajmo v shemo shranjevanje:
Opomba: lahko ustvarimo tudi hiper-konvergente računalniške vozlišča – to je koncept združevanja več funkcij na enem vozlišču – na primer shramba + računalništvo – ne dodeljujemo posebnih vozlišč za ceph shranjevanje. Tako bomo dobili enako shemo z odpornostjo na napake – saj SDS rezervira podatke z vnaprej določenim nivojem rezerve. Kljub temu pa so hiper-konvergente vozlišča vedno kompromis – saj shranjevalno vozlišče ne gre samo za prazno segrevanje zraka, kot se morda zdi na prvi pogled (ker na njem ni virtualnih strojev) – porablja CPU vire za vzdrževanje SDS (dejansko v ozadju izvaja vse replikacije, obnovitve po okvarah vozlišč, diskih itd.). To pomeni, da boste izgubili del zmogljivosti računalniškega vozlišča, če ga združite s shranjevanjem.
Vse to moramo nekako upravljati – potrebujemo nekaj, preko česar lahko ustvarimo stroj, omrežje, virtualni usmerjevalnik itd. Za to bomo na kontrolno vozlišče dodali storitev, ki bo delovala kot nadzorna plošča – stranka se bo lahko povezala s tem portalom preko http/https in naredila vse, kar potrebuje (no, skoraj).
Na koncu zdaj imamo sistem z odpornostjo na napake. Vse elemente te infrastrukture je treba nekako upravljati. Prej je bilo opisano, da je OpenStack nabor projektov, od katerih vsak zagotavlja neko določeno funkcijo. Kot vidimo, je dovolj elementov, ki jih je treba konfigurirati in nadzorovati. Danes se bomo pogovarjali o omrežnem delu.
Arhitektura Neutron
V OpenStacku je Neutron odgovoren za povezovanje portov virtualnih strojev z omrežjem L2, zagotavljanje usmerjanja prometa med VM, ki se nahajajo v različnih omrežjih L2, ter usmerjanje navzven, zagotavljanje storitev, kot so NAT, Floating IP, DHCP itd.
Na visoki ravni lahko delo omrežne storitve (osnovni del) opišemo takole.
Ko se VM zažene, omrežna služba:
- Ustvari port za to VM (ali porte) in o tem obvesti DHCP storitev;
- Ustvari se nova virtualna omrežna naprava (prek libvirt);
- VM se poveže z ustvarjenim portom (porti) v 1. koraku;
Na presenečenje pa temelji delovanje Neutrona na standardnih mehanizmih, katerih se vsi spomnijo, ko so se kdajkoli potopili v Linux – to so namespaces, iptables, Linux mostovi, openvswitch, conntrack itd.
Takoj je treba pojasniti, da Neutron ni SDN krmilnik.
Neutron sestavlja več medsebojno povezanih komponent:
Openstack-neutron-server — to je demon, ki preko API deluje s uporabniškimi zahtevi. Ta demon ne skrbi za nastavljanje kakršnih koli omrežnih povezav, temveč svojim vtičnikom posreduje potrebne informacije, ki nato konfigurirajo ustrezen omrežni element. Neutron agenti na vozlih OpenStack se registrirajo na strežniku Neutron.
Neutron-server je dejansko aplikacija, napisana v pythonu, ki je sestavljena iz dveh delov:
- REST storitev
- Neutron vtičnik (core/service)
REST storitev je namenjena sprejemanju API klicev od drugih komponent (na primer zahteva za posredovanje nekih informacij itd.)
Vtičniki so priključni programski sestavni deli/moduli, ki se aktivirajo pri API klicih — torej se dodajanje določene storitve odvija preko njih. Vtičniki se delijo na dva tipa — servisni in osnovni. Običajno osnovni vtičnik skrbi predvsem za upravljanje naslovnega prostora in L2 povezave med VM, medtem ko servisni vtičniki zagotavljajo dodatno funkcionalnost, na primer VPN ali FW.
Seznam razpoložljivih vtičnikov si lahko ogledate na primer
Servisnih vtičnikov je lahko več, vendar je osnovni vtičnik lahko samo en.
Openstack-neutron-ml2 — to je standardni osnovni vtičnik Openstack. Ta vtičnik ima modularno arhitekturo (v nasprotju s svojim predhodnikom) in preko vtičnih gonilnikov izvaja konfiguracijo omrežne storitve. Samega vtičnika bomo obravnavali nekoliko kasneje, saj dejansko omogoča tisto prilagodljivost, katero ima OpenStack na omrežnem področju. Osnovni vtičnik lahko zamenjamo (na primer Contrail Networking izvaja to zamenjavo).
RPC storitev (rabbitmq-server) — storitev, ki zagotavlja upravljanje z vrsto in sodelovanje z drugimi storitvami OpenStack ter interakcijo med agenti omrežne storitve.
Omrežni agenti — agenci, ki so nameščeni na vsaki vozli, preko katerih se izvaja konfiguracija omrežnih storitev.
Agenti so lahko različnih vrst.
Glavni agent je L2 agent. Ti agenti se zagonijo na vsakem od hipervizorjev, vključno s kontrolnimi vozli (natančneje na vseh vozlih, ki nudijo storitve za najemnike), njihova glavna funkcija pa je povezovanje virtualnih strojev z skupno L2 mrežo ter generiranje obvestil ob pojavnih dogodkih (na primer izklop/uklop porta).
Naslednji, prav tako pomemben agent je L3 agent. Ta agent se po privzetku zagonijo izključno na omrežnem vozlišču (pogosto se omrežno vozlišče kombinira s kontrolnim vozliščem) in zagotavlja usmerjanje med omrežji najemnikov (tako med njegovimi omrežji kot omrežji drugih najemnikov, pa tudi dostopom v zunanji svet, s zagotavljanjem NAT in DHCP storitev). Vendar pa, pri uporabi DVR (porazdeljenega usmerjevalnika) postane potreben tudi L3 vtičnik na računalniških vozliščih.
L3 agent uporablja Linux namespaces za zagotavljanje paketa lastnih izoliranih omrežij za vsakega najemnika ter funkcionalnosti virtualnih usmerjevalnikov, ki usmerjajo promet in zagotavljajo storitve prehodov za Layer 2 omrežja.
Baza podataka — baza podatkov identifikatorjev omrežij, podmrežij, portov, baz in podobno.
V resnici Neutron sprejema API zahteve za ustvarjanje kakršnih koli omrežnih entitet, avtenticira zahtevo in prek RPC (če se sklicuje na katerega koli vtičnika ali agenta) ali REST API (če komunicira v SDN) posreduje agentom (prek vtičnikov) navodila, potrebna za organizacijo zahtevane storitve.
Zdaj se osredotočimo na testno namestitev (kako je nameščena in kaj vsebuje, bomo kasneje pogledali v praktičnem delu) in poglejmo, kje se nahajajo posamezne komponente:
(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 ~]$ 
Вот и вся структура Neutron. Теперь стоит уделить некоторое время плагину ML2.
Модульный уровень 2
Как уже было сказано, этот плагин является стандартным корневым плагином OpenStack и имеет модульную архитектуру.
Предшественник плагина ML2 имел монолитную структуру, что не позволяло использовать, например, комбинацию нескольких технологий в одной установке. Например, вы не могли одновременно использовать и openvswitch, и linuxbridge — нужно было выбирать одно из них. По этой причине был создан плагин ML2 с его архитектурой.
ML2 имеет две составляющие — два типа драйверов: типовые драйверы и механизмы драйверов.
Типовые драйверы определяют технологии, которые будут использоваться для организации сетевых связей, например VxLAN, VLAN, GRE. При этом драйвер позволяет использовать разные технологии. Стандартной технологией является инкапсуляция VxLAN для overlay-сетей и внешних сетей VLAN.
К типовым драйверам относятся следующие типы сетей:
Плоская — сеть без тегирования
VLAN — тегированная сеть
Local — специальный тип сети для установок типа all-in-one (такие установки нужны либо для разработчиков, либо для обучения)
GRE — overlay-сеть, использующая GRE-туннели
VxLAN — overlay-сеть, использующая VxLAN-туннели
Механизмы драйверов opredeljujemo sredstva, ki zagotavljajo organizacijo navedenih tehnologij v type driver — na primer, openvswitch, sr-iov, opendaylight, OVN itd.
Odvisno od implementacije tega gonilnika se bodo uporabili bodisi agenti, ki jih upravlja Neutron, bodisi povezave z zunanjim SDN kontrolerjem, ki prevzema vsa vprašanja glede organizacije L2 omrežij, usmerjanja itd.
Na primer, če uporabljamo ML2 skupaj z OVS, se na vsakem računalniškem vozlišču namesti L2 agent, ki upravlja OVS. Vendar pa, če uporabljamo na primer OVN ali OpenDayLight, nadzor nad OVS preide pod njihovo pristojnost — Neutron prek korenskega vtičnika daje ukaze kontrolerju, ki potem opravi to, kar mu je bilo naročeno.
Osvežimo spomin na Open vSwitch
Trenutno je ena izmed ključnih komponent OpenStacka Open vSwitch.
Pri namestitvi OpenStacka brez kakršnega koli dodatnega prodajnega SDN, kot sta Juniper Contrail ali Nokia Nuage, je OVS glavna mrežna komponenta oblačne mreže in v kombinaciji z iptables, conntrack, namespaces omogoča organizacijo popolnih overlay omrežij z multitenancy. Seveda se ta komponenta lahko nadomesti, na primer pri uporabi zunanjih proprietarnih (prodajnih) SDN rešitev.
OVS je programski stikalo z odprto kodo, ki je namenjeno uporabi v virtualiziranih okoljih kot virtualni posrednik prometa.
Trenutno ima OVS zelo dobro funkcionalnost, ki vključuje tehnologije, kot so QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK itd.
Opomba: prvotno OVS ni bil zasnovan kot programski stikalo za visoko obremenjena telekomunikacijska funkcionalnost, ampak je bil bolj prilagojen manj zahtevnim IT funkcionalnostim, kot so spletni strežniki ali strežniki za e-pošto. Vendar se OVS izboljšuje in trenutne implementacije OVS so močno izboljšale njegovo zmogljivost in funkcionalnosti, kar omogoča njegovo uporabo operaterjem komunikacij z visoko obremenjenimi funkcijami, na primer, obstaja implementacija OVS s podporo za DPDK pospeševanje.
Obstajajo tri pomembne komponente OVS, o katerih je treba vedeti:
- Kernel modul — komponenta, ki se nahaja v kernel prostoru, ki obdeluje promet na podlagi pravil, pridobljenih od nadzornega elementa;
- vSwitch Daemon (ovs-vswitchd) — to je proces, ki teče v uporabniškem prostoru in je odgovoren za programiranje jedrnega modula, kar pomeni, da neposredno predstavlja logiko delovanja stikala.
- Strežnik baze podatkov — lokalna baza podatkov, ki se nahaja na vsakem gostitelju, na katerem teče OVS, v kateri se shranjuje konfiguracija. Ta modul omogoča komunikacijo SDN nadzornikom prek protokola OVSDB.
K temu vsemu se dodaja tudi nabor diagnostičnih in upravljalskih pripomočkov, kot so ovs-vsctl, ovs-appctl, ovs-ofctl itd.
Trenutno se OpenStack široko uporablja pri telekomunikacijskih operaterjih za migracijo omrežnih funkcij, kot so EPC, SBC, HLR itd. Nekatere funkcije lahko brez težav delujejo z OVS v svoji trenutni obliki, vendar pa EPC obdeluje promet naročnikov — torej usmerja ogromne količine prometa (trenutno obsegi prometa dosegajo več sto gigabitov na sekundo). Seveda usmerjanje takšnega prometa prek jedrnega prostora (kot je privzeto, ker je posrednik tam) ni najboljša ideja. Zato se OVS pogosto postavi v celoti v uporabniškem prostoru z uporabo tehnologije pospeševanja DPDK za preusmeritev prometa iz NIC-a v uporabniški prostor, mimo jedra.
Opomba: za oblačno okolje, ki je razporejeno za telekomunikacijske funkcije, je možna različica usmerjanja prometa iz računalniškega vozlišča neposredno v omrežno opremo, mimo OVS. Za to se uporabljajo mehanizmi SR-IOV in Passthrough.
Kako to deluje na pravem maketu?
Zdaj preidimo v praktični del in poglejmo, kako to deluje v praksi.
Najprej bomo postavili preprosto namestitev OpenStack. Ker nimam nabora strežnikov za eksperimentiranje, bomo maketo zgradili na enem fizičnem strežniku iz virtualnih strojev. Da, seveda to rešitev ni mogoče uporabiti za komercialne namene, vendar je za demonstracijo delovanja omrežja v OpenStack taka namestitev povsem dovolj. Ta namestitev je za izobraževalne namene še bolj zanimiva, saj lahko spremljamo promet itd.
Ker potrebujemo samo osnovni del, lahko uporabimo le dve mreži, pri čemer se bo druga mreža v tej maketi uporabljala izključno za dostop do undercloud in DNS strežnika. Zunanjih mrež zaenkrat ne bomo obravnavali — to je tema za ločen večji članek.
Začnemo torej zaporedoma. Najprej nekoliko teorije. OpenStack bomo namestili s pomočjo TripleO (OpenStack na OpenStack). Osnovna ideja TripleO je, da namestimo OpenStack all-in-one (to je na eno vozlišče), imenovano undercloud, in nato uporabimo možnosti razporejenega OpenStacka za namestitev operativnega OpenStacka, imenovanega overcloud. Undercloud bo uporabljal vgrajeno funkcionalnost za upravljanje s fizičnimi strežniki (bare metal) — projekt Ironic — za provizioniranje hipervizorjev, ki bodo izvajali vloge compute, control in storage vozlišč. To pomeni, da ne uporabljamo nobenih zunanjih orodij za razporejanje OpenStacka — OpenStack uvedemo z lastnimi sredstvi. Nadalje, med namestitvijo bo vse postalo jasnejše, zato se ne bomo ustavljali in bomo nadaljevali naprej.
Opomba: V tem članku, da bi poenostavil, nisem uporabil omrežne izolacije za notranja omrežja OpenStack, ampak je vse razporejeno z uporabo samo enega omrežja. Vendar prisotnost ali odsotnost omrežne izolacije ne vpliva na osnovne funkcionalnosti rešitve — vse bo delovalo ravno tako, kot pri uporabi izolacije, le da bo promet tekel v enem omrežju. Pri komercialni namestitvi je seveda potrebno uporabiti izolacijo z različnimi VLAN-i in vmesniki. Na primer, promet za upravljanje Ceph shrambe in promet za podatke (dostopi strojev do diskov itd.) pri izolaciji uporabljata različne podomrežja (Storage management in Storage), kar rešitev naredi bolj odporne na napake, saj ta promet razdelimo po različnih vratih ali uporabimo različne QoS profile za različen promet, tako da podatkovni promet ne nadomesti signalnega prometa. V našem primeru bosta oba potekala v istem omrežju in to nas v resnici ne omejuje.
Opomba: Ker nameravamo zagnati virtualne naprave v virtualnem okolju, ki temelji na virtualnih napravah, moramo najprej omogočiti nested virtualizacijo.
Nested virtualizacijo lahko preverite na naslednji način:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Če vidite črko N, omogočite podporo za nested virtualizacijo po kateri koli smernici, ki jo najdete na spletu, na primer .
Potrebujemo zbrati naslednjo shemo iz virtualnih naprav:
V mojem primeru za povezanost virtualnih strojev, ki so del hodijoče namestitve (imel sem jih 7, vendar bi se dalo izvesti tudi s 4, če imate omejene vire) sem uporabil OpenvSwitch. Ustvaril sem en ovs most in povezoval virtualne stroje preko port-grup. Za to sem ustvaril xml datoteko naslednje oblike:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Tukaj so razglašene tri portne skupine — dve dostop in ena trunk (zadnja je bila potrebna za DNS strežnik, vendar bi se dalo tudi brez njega ali pa ga vzpostaviti na gostiteljskem stroju — kot vam bolj ustreza). Nato z uporabo te predloge razglašamo našo omrežje preko virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Zdaj popravimo konfiguracije portov hipervizorja:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Opomba: v tem scenariju naslov na portu ovs-br1 ne bo dostopen, ker nima vlan oznake. Da to popravite, morate izvesti ukaz sudo ovs-vsctl set port ovs-br1 tag=100. Vendar se bo po ponovnem zagonu ta oznaka izgubila (če ve kdo, kako jo obdržati — bom zelo hvaležen). Vendar to ni tako pomembno, saj bomo ta naslov potrebovali le za čas namestitve in ne bo potreben, ko bo Openstack popolnoma razporejen.
Nato ustvarimo undercloud stroji:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0При установке вы задаете все необходимые параметры, такие как имя машины, пароли, пользователи, ntp-серверы и т. д. Можно сразу настроить и порты, но мне удобнее после установки зайти в машину через консоль и изменить нужные файлы. Если у вас уже есть готовый образ, вы можете использовать его, или, как я, скачать минимальный образ CentOS 7 и использовать его для установки ВМ.
После успешной установки у вас должна появиться виртуальная машина, на которую можно будет установить undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningСначала устанавливаем необходимые инструменты для процесса установки:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Установка Undercloud
Создайте пользователя stack, задайте пароль, добавьте в sudoer и дайте ему возможность выполнять команды root через sudo без ввода пароля:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackТеперь указываем полное имя undercloud в файле hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Далее добавляем репозитории и устанавливаем необходимое программное обеспечение:
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-ansibleПримечание: если вы не планируете устанавливать ceph, не вводите команды, относящиеся к ceph. Я использовал релиз Queens, но вы можете использовать любой другой, который вам понравится.
Теперь копируем файл конфигурации undercloud в домашнюю директорию пользователя stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confТеперь нужно изменить этот файл, адаптировав его к нашей инсталляции.
В начало файла необходимо добавить следующие строки:
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 = 10Итак, давайте рассмотрим настройки:
undercloud_hostname — полное имя сервера undercloud, должно совпадать с записью на DNS-сервере.
local_ip — lokalni naslov undercloud prema mreži za provisioniranje
network_gateway — isti lokalni naslov koji će služiti kao gateway za pristup vanjskom svijetu tijekom instalacije overcloud nodova, također se poklapa s lokalnom IP adresom
undercloud_public_host — adresa vanjskog API-a, dodijeljuje se bilo kojoj slobodnoj adresi iz mreže za provisioniranje
undercloud_admin_host adresa unutarnjeg API-a, dodijeljuje se bilo kojoj slobodnoj adresi iz mreže za provisioniranje
undercloud_nameservers — DNS poslužitelj
generate_service_certificate — ova linija je vrlo važna u ovom primjeru, jer ako je ne postavite na false, dobit ćete grešku tijekom instalacije, problem je opisan na bug trackeru Red Hat
local_interface interface u mreži za provisioniranje. Ovaj interface će biti rekonfiguriran tijekom postavljanja undercloud-a, stoga undercloud mora imati dva interface-a — jedan za pristup, drugi za provisioniranje
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 zapakirani VxLAN paketi
network_cidr — mreža za provisioniranje
masquerade — korištenje NAT-a za pristup vanjskoj mreži
masquerade_network — mreža koja će biti NAT-ana
dhcp_start — početna adresa pool-a adresa, iz kojeg će se dodjeljivati adrese nodovima tijekom deploy-a overcloud
dhcp_end — završna adresa pool-a adresa, iz kojeg će se dodjeljivati adrese nodovima tijekom deploy-a overcloud
inspection_iprange — pool adresa potrebno za provođenje introspekcije (ne smije se preklapati s navedenim pool-om)
scheduler_max_attempts — maksimalan broj pokušaja instalacije overcloud (treba biti veći ili jednak broju nodova)
Nakon što je datoteka opisana, možete dati naredbu za deploy undercloud-a:
openstack undercloud install
Postupak traje od 10 do 30 minuta, ovisno o vašem hardveru. Na kraju biste trebali vidjeti sljedeći 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 je na
/home/stack/undercloud-passwords.conf.
Također postoji 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 se pojavio novi bridge interface
[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 0Теперь через этот интерфейс будет производиться развертывание overcloud.
Из ниже указанного вывода видно, что все сервисы находятся на одной ноде:
(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 |
+--------------------------+-----------+----------+Ниже представлена конфигурация сетевой части undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Установка overcloud
На данный момент у нас есть только undercloud, и нам не хватает нод для формирования overcloud. Поэтому первым делом создадим нужные нам виртуальные машины. В процессе развертывания undercloud установит операционную систему и необходимое ПО на машины overcloud — то есть нам не нужно полностью развертывать машину, а только создать для нее диск (или диски) и определить ее параметры — фактически получаем сервер без установленной ОС.
Перейдем в папку с дисками наших виртуальных машин и создадим диски нужного объема:
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 160GТак как мы действуем от имени рута, нам нужно изменить владельца этих дисков, чтобы избежать проблем с правами:
[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]# Обратите внимание: если вы не собираетесь устанавливать ceph для его изучения, не создавайте минимум 3 узла, у каждого из которых должно быть как минимум два диска, и в шаблоне укажите, что будут использоваться виртуальные диски vda, vdb и т.д.
Отлично, теперь нам нужно определить все эти машины:
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 В конце есть команды —print-xml > \/tmp\/storage-1.xml, которая создает xml файл с описанием каждой машины в папке \/tmp\/, если ее не добавить, то вы не сможете определить виртуальные машины.
Теперь нам нужно определить все эти машины в virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Torej, majhna podrobnost — tripleO uporablja IPMI za upravljanje strežniki med namestitvijo in introspekcijo.
Introspekcija je postopek pregleda strojne opreme za pridobitev njenih parametrov, potrebnih za nadaljnje zagotavljanje virov nod. Introspekcija se izvaja s pomočjo ironic — storitve, namenjene delu z bare metal strežniki.
Ampak tukaj je težava — če imajo fizični strežniki IPMI to ločeno vrata (ali deljena vrata, kar ni bistveno), pa virtualni stroji nimajo takih vrat. Tukaj nam pomaga rešitev z imenom vbmc — orodje, ki omogoča emulacijo IPMI vrat. Na to podrobnost je še posebej treba opozoriti tiste, ki želijo postaviti to laboratorij na ESXI hipervizorju — iskreno, ne vem, ali v njem obstaja analog vbmc, zato se je smiselno osredotočiti na to vprašanje, preden vse postavite.
Namestimo vbmc:
yum install python2-virtualbmcČe vaš operacijski sistem ne more najti paketa, dodajte repozitorij:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSedaj nastavite orodje. Tukaj je vse zelo preprosto. Zdaj je logično, da na seznamu vbmc ni nobenih strežnikov.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Da se pojavijo, jih je treba ročno razglasiti na naslednji 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 ukaza razumljiva brez dodatnih razlag. Vendar pa so trenutno vse naše seje v stanju DOWN. Da preidejo v stanje UP, jih je treba vklopiti:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#In the final touch, it is necessary to adjust the firewall rules (or disable it completely):
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
Now let's access the undercloud and check that everything is working. The address of the host machine is 192.168.255.200, and we added the necessary ipmitool package during the preparation for deployment:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningAs you can see, we successfully started the control node through vbmc. Now let's turn it off and proceed:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#The next step is to introspect the nodes on which the overcloud will be installed. For this, we need to prepare a JSON file describing our nodes. Note that, unlike installing on bare servers, the file specifies the port on which vbmc is running for each machine.
[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 kontrolnoj čvoru postoje dva interfejsa, ali u ovom slučaju to nije važno, za ovu instalaciju dovoljno je i jedan.
Sada pripremamo json datoteku. Moramo navesti MAC adresu porta preko kojeg će se izvršiti provisioning, parametre čvorova, dodeliti im imena 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 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 ~]$Nalaganje slik v undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~\/images\/
Image "overcloud-full-vmlinuz" je bil naložen.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Ime | Disk Format | Velikost | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktivno |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" je bil naložen.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Ime | Disk Format | Velikost | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktivno |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" je bil naložen.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Ime | Disk Format | Velikost | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktivno |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" je bil naložen.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Ime | Disk Format | Velikost | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktivno |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" je bil naložen.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Ime | Disk Format | Velikost | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktivno |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Preverjamo, ali so se vsi slike naložili
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Ime | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktivno |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktivno |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktivno |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktivno |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktivno |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Še en dodatek — potrebno je dodati DNS strežnik:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Now we can give the command for introspection:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Запущен рабочий процесс Mistral tripleo.baremetal.v1.register_or_update. ID выполнения: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Ожидание сообщений в очереди 'tripleo' без времени ожидания.
5 узлов успешно переведены в состояние "управляемый".
Успешно зарегистрирован узел UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Успешно зарегистрирован узел UUID b89a72a3-6bb7-429a-93bc-48393d225838
Успешно зарегистрирован узел UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Успешно зарегистрирован узел UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Успешно зарегистрирован узел UUID 766ab623-464c-423d-a529-d9afb69d1167
Ожидание завершения интроспекции...
Запущен рабочий процесс Mistral tripleo.baremetal.v1.introspect. ID выполнения: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Ожидание сообщений в очереди 'tripleo' без времени ожидания.
Интроспекция узла b89a72a3-6bb7-429a-93bc-48393d225838 завершена. Статус: УСПЕШНО. Ошибки: Нет
Интроспекция узла 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e завершена. Статус: УСПЕШНО. Ошибки: Нет
Интроспекция узла bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 завершена. Статус: УСПЕШНО. Ошибки: Нет
Интроспекция узла 766ab623-464c-423d-a529-d9afb69d1167 завершена. Статус: УСПЕШНО. Ошибки: Нет
Интроспекция узла b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 завершена. Статус: УСПЕШНО. Ошибки: Нет
Успешно выполнено 5 интроспекций узлов.
Запущен рабочий процесс Mistral tripleo.baremetal.v1.provide. ID выполнения: f5594736-edcf-4927-a8a0-2a7bf806a59a
Ожидание сообщений в очереди 'tripleo' без времени ожидания.
5 узлов успешно переведены в состояние "доступный".
(undercloud) [stack@undercloud ~]$Как видно из вывода, все завершилось без ошибок. Проверим, что все узлы в состоянии доступный:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Если узлы будут в другом состоянии, как правило, manageable, значит что-то пошло не так, и нужно проверить логи, чтобы разобраться, в чем проблема. Учтите, что в данном сценарии мы используем виртуализацию, и могут быть ошибки, связанные с использованием виртуальных машин или vbmc.
Далее нам нужно указать, какая нода какую функцию будет выполнять — то есть указать профиль, с которым нода будет разворачиваться:
(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 ~]$Specifying a profile for each node:
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-d9afb69d1167We check that we have done everything correctly:
(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 ~]$Если всё верно, даём команду на деплой overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuВ реальной инсталляции естественно будут использоваться кастомизированные шаблоны, в нашем случае это сильно усложнит процесс, так как необходимо будет объяснить каждую правку в шаблоне. Как было написано ранее — даже простой инсталляции нам будет достаточно, чтобы посмотреть, как это работает.
Примечание: переменная —libvirt-type qemu в данном случае необходима, так как мы будем использовать вложенную виртуализацию. В противном случае у вас не будут запускаться виртуальные машины.
Теперь у вас есть примерно час, а может и больше (зависит от возможностей оборудования), и вам остается надеяться, что по истечении этого времени вы увидите такое сообщение:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Теперь у вас есть почти полноценная версия OpenStack, на которой вы можете учиться, ставить опыты и т.д.
Проверим, чтобы всё нормально работало. В домашней директории пользователя stack есть два файла — один stackrc (для управления undercloud) и второй overcloudrc (для управления overcloud). Эти файлы необходимо указать как source, так как в них содержится необходимая для аутентификации информация.
(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 ~]$V moji namestitvi še potrebujem en majhen dodatek — dodati moram pot na nadzornem računalniku, saj se naprava, s katero delam, nahaja v drugi omrežju. Zato se prijavimo na control-1 kot heat-admin in vpišemo pot.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Zdaj lahko vstopite v horizont. Vse informacije — naslovi, uporabniško ime in geslo — so v datoteki /home/stack/overcloudrc. Končna shema izgleda takole:
Kot zanimivost, v naši namestitvi so naslovi naprav dodeljeni preko DHCP in, kot vidite, so dodeljeni “naključno”. V predlogi lahko natančno določite, kateri naslov kateri napravi pripada med namestitvijo, če je to potrebno.
Kako pa poteka promet med virtualnimi napravami?
V tem članku bomo obravnavali tri možnosti prehoda prometa.
- Dve napravi na enem hipervizorju v eni L2 mreži.
- Dve napravi na različnih hipervizorjih v eni L2 mreži.
- Dve napravi v različnih mrežah (usmerjanje med mrežami).
Primeri z dostopom v zunanji svet prek zunanje mreže, z uporabo plavajočih naslovov, kot tudi porazdeljeno usmerjanje bomo obravnavali naslednjič, zaenkrat pa se osredotočimo na notranji promet.
Za preverjanje bomo zgradili takšno shemo:
Ustvarili smo 4 virtualne naprave — 3 v eni L2 mreži — net-1, in še 1 v mreži net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Poglejmo, na katerih hipervizorjih so nameščene ustvarjene naprave:
(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 ~]$
Stroji vm-1 in vm-3 se nahajajo na compute-0, stroji vm-2 in vm-4 so na nodu compute-1.
Poleg tega je bil ustvarjen virtualni usmerjevalnik za omogočanje usmerjanja med navedenimi omrežji:
(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 ~]$ Usmerjevalnik ima dve virtualni vrata, ki delujeta kot prehodi za omrežja:
(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 ~]$ Preden pogledamo, kako poteka promet, si poglejmo, kaj imamo trenutno na kontrolni nodi (ki je hkrati tudi omrežna noda) in na compute nodi. Začnimo s compute nodo.
[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. Između njih, kao što vidimo, ima skup interfejsa. Za lakše razumevanje, prikazaćemo sve ove interfejse na dijagramu i videti šta dobijamo.
Na adresama na kojima su podignuti VxLAN tuneli, primetno je da je jedan tunel podignut na compute-1 (192.168.255.26), dok drugi tunel gleda na control-1 (192.168.255.15). No, ono što je najzanimljivije je to što br-ex nema fizičkih interfejsa, a ako pogledamo koje su tokove podešene, vidimo da ovaj most trenutno može samo da odbacuje saobraćaj.
[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 ~]$ Iz izlaza se vidi da je adresa direktno povezana na fizički port, a ne na virtuelni most interfejs.
[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 treba odbaciti.
Trenutno, u ovaj most nema drugog izvora saobraćaja osim iz ovog interfejsa (povezivanje sa br-int), a sudeći po odbacivanju, u most je već stigao BUM saobraćaj.
To je, da lahko promet iz te vozlišča zapusti le prek VxLAN tunela in nikakor drugače. Vendar, če omogočite DVR, se bo situacija spremenila, a o tem se bomo pogovorili drugič. Pri uporabi izolacije omrežij, na primer s pomočjo VLAN-ov, ne boste imeli ene L3 naprave v 0. VLAN-u, temveč več naprav. Vendar bo VxLAN promet izhajal iz vozlišča na enak način, le da bo dodatno encapsuliran v nekem dodeljenem VLAN-u.
Ko smo razjasnili compute vozlišče, preidimo na control vozlišče.
[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 ~]$Dejansko lahko rečemo, da je vse enako, vendar je IP naslov zdaj na virtualnem mostu, ne na fizičnem vmesniku. To je narejeno zato, ker je ta vrata tista, preko katere bo promet izhajal v zunanji svet.
[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 ~]$ To vrata je priključena na most br-ex, in ker na njem ni nobenih VLAN oznak, je to vrata za trunk, kjer so vsa VLAN dovoljena, trenutno promet izhaja navzven brez oznake, kar kaže vlan-id 0 v prejšnjem izhodu.
Vse ostalo je trenutno enako compute vozlišču — iste mostovi, isti tuni, ki gredo na dve compute vozlišča.
V tejto článku sa nebudeme zaoberať uzlami úložiska, ale pre pochopenie je potrebné povedať, že sieťová časť týchto uzlov je mimoriadne jednoduchá. V našom prípade existuje len jeden fyzický port (eth0) s priradenou IP adresou a to je všetko. Nie sú tam žiadne VxLAN tunely, tunelové mosty atď. — nie je tam žiadny ovs, pretože to nemá zmysel. Pri použití izolácie sietí bude na tomto uzle dva rozhrania (fyzické porty, bondy, alebo jednoducho dva VLAN-y — na tom nezáleží — závisí to od toho, čo chcete) — jedno pre správu, druhé pre prenos (zápis na disk VM, čítanie z disku atď.).
Teraz, keď sme sa vysporiadali s tým, čo máme na uzloch, v neprítomnosti akýchkoľvek služieb, spustíme 4 virtuálne stroje a pozrieme sa, ako sa zmení vyššie opísaná schéma — mali by sa objaviť porty, virtuálne routery atď.
Zatiaľ naša sieť vyzerá takto:
Na každom počítačovom uzle máme dve virtuálne stroje. Na príklade compute-0 sa pozrieme, ako je všetko zapojené.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Názov Stav
----------------------------------------------------
1 instance-00000001 beží
3 instance-00000003 beží
[heat-admin@overcloud-novacompute-0 ~]$ Stroj má len jedno virtuálne rozhranie — tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Rozhranie Typ Zdroje Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Toto rozhranie smeruje do linux bridge:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
názov mosta id mosta STP povolené rozhrania
docker0 8000.0242904c92a8 nie
qbr5bd37136-47 8000.5e4e05841423 nie qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 nie qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Ako vyplýva z výstupu, v moste sú len dva rozhrania — tap95d96a75-a0 a qvb95d96a75-a0.
Tu by sme sa mali trochu zastaviť a povedať si o typoch virtuálnych sieťových zariadení v OpenStack:
vtap — virtuálne rozhranie pripojené k inštancii (VM)
qbr — Linux bridge
qvb a qvo — vEth pár pripojený k Linux bridge a Open vSwitch bridge
br-int, br-tun, br-vlan — Open vSwitch mosty
patch-, int-br-, phy-br- — Open vSwitch patch-rozhrania spájajúce mosty
qg, qr, ha, fg, sg — porty Open vSwitch používané virtuálnymi zariadeniami na pripojenie k OVS
Kako razumete, ako imamo port qvb95d96a75-a0 u bridu, koji je vEth par, tada negde postoji njegova suprotna strana, koja logično treba da se zove 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 terminira portove virtuelnih mašina. Pored qvo95d96a75-a0 u izlazu se vidi port qvo5bd37136-47. To je port za drugu virtuelnu mašinu. Kao rezultat, naš dijagram sada izgleda ovako:
Pitanje koje bi odmah trebalo zanimati pažljivog čitaoca — kakva je svrha linux brida između porta virtuelne mašine i porta OVS? Poenta je u tome što se za zaštitu mašine koriste security groups, koje su zapravo ništa drugo do iptables. OVS ne radi sa iptables, pa je ovakav 'hack' smišljen. Međutim, to više ne funkcioniše — na njegovom mestu dolazi conntrack u novim izdanjima.
Dakle, na kraju, dijagram izgleda ovako:
Dve napravi na enem hipervizorju v eni L2 mreži.
Budući da se dve VM nalaze u istoj L2 mreži i na istom hipervizoru, logično je da će saobraćaj između njih prolaziti lokalno putem br-int, jer će obe mašine 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 ~]$ Dve napravi na različnih hipervizorjih v eni L2 mreži.
Sada pogledajmo kako će saobraćaj ići između dve mašine u istoj L2 mreži, ali smeštenim na različitim hipervizorima. Ako budemo iskreni, ništa se bitno neće promeniti, jednostavno će saobraćaj između hipervizora ići kroz vxlan tunel. Pogledajmo na primeru.
Naslovi virtualnih strojeva, između kojih ćemo pratiti promet:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Rozhranie Typ Zdroje 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
Interfejs Tip Izvor Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Pogledajmo tablicu preusmjeravanja na 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 treba otići na port 2 — vidimo 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 pakira u VxLAN i šalje na 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 je u tablici preusmjeravanja br-int na compute-1, a kao što se može vidjeti iz gornjeg ispisivanja, 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 promatramo postoje li usmjereni MAC adrese na br-int na compute-1:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ To znači da će primljeni paket otići na port 3, iza kojeg se nalazi virtualni stroj instance-00000003.
Celotna lepota uvajanja Openstack-a na virtualni infrastrukturi je v tem, da lahko brez težav ujameš promet med hipervizorji in vidiš, kaj se dogaja z njim. To bomo sedaj storili, zagnali bomo tcpdump na vnet portu proti compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: poslušanje na vnet3, tip povezave EN10MB (Ethernet), velikost zajema 262144 bajtov
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), dolžina 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), dolžina 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, dolžina 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), dolžina 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), dolžina 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, dolžina 64
*****************omitted*******************Prva vrstica kaže, da paket z naslovom 10.0.1.85 odhaja na naslov 10.0.1.88 (ICMP promet), pri čemer je zavit v VxLAN paket z vni 22 in paket gre iz gostitelja 192.168.255.19 (compute-0) na gostitelja 192.168.255.26 (compute-1). Lahko preverimo, da VNI ustreza tistemu, ki je naveden v ovs.
Vrnimo se k tej vrstici actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 — to je vni v 16-ničeljski sistemu. Pretvorimo to število v deseti sistem:
16 = 6*16^0+1*16^1 = 6+16 = 22Torej, vni ustreza realnosti.
Druga vrstica prikazuje obratni promet, nimamo smisla to razlagati, ker je tam vse jasno.
Dve napravi v različnih omrežjih (usmerjanje med omrežji)
Zadnji primer za danes — usmerjanje med omrežji znotraj enega projekta ob uporabi virtualnega usmerjevalnika. Obravnavamo primer brez DVR (to bomo obravnavali v drugem članku), zato se usmerjanje dogaja na omrežni vozlišču. V našem primeru omrežno vozlišče ni ločeno in se nahaja na nadzornem vozlišču.
Najprej poglejmo, ali usmerjanje deluje:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 podatkovnih bajtov
64 bajtov iz 10.0.2.8: seq=0 ttl=63 čas=7.727 ms
64 bajtov iz 10.0.2.8: seq=1 ttl=63 čas=3.832 ms
^C
--- 10.0.2.8 statistika pinga ---
2 paketi poslani, 2 paketi sprejeti, 0% izguba paketov
čas kroženja min/avg/max = 3.832/5.779/7.727 msKer v tem primeru paket mora iti na prehod in tam biti usmerjen, moramo ugotoviti MAC naslov prehoda, za kar bomo pogledali ARP tabelo v instanci:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] na eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] na eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] na eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] na eth0Poglejmo, kam naj bi promet z naslovom (10.0.1.254) fa:16:3e:c4:64:70 šel.
[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 ~]$ Glejmo, kam vodi vrata 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 ~]$ Vse se zdi logično, promet se usmerja v br-tun. Poglejmo, v kateri vxlan predor bo zavit:
[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 ~]$ Tretja vrata so vxlan predor:
[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 ~]$ Ki gleda na kontrolno vozlišče:
[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 prišel do kontrolne vozlišče, zato moramo preiti nanj in preveriti, kako bo potekalo usmerjanje.
Kot ste morda opazili, je kontrolno vozlišče iz notranje strani izgledalo povsem enako kot izračunsko vozlišče - tri mostove, le da je imel br-ex fizična vrata, preko katerih je vozlišče lahko pošiljalo promet na zunaj. Ustvarjanje instanc je spremenilo konfiguracijo na izračunskih vozliščih - dodani so bili linux bridge, iptables in vmesniki v vozlišča. Ustvarjanje omrežij in virtualnega usmerjevalnika je prav tako pustilo svoj pečat na konfiguraciji kontrolnega vozlišča.
Torej je očitno, da mora biti MAC naslov prehoda v tabeli posredovanja br-int na kontrolnem vozlišču. Preverimo, ali tam je in kam 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 viden iz vrat qr-0c52b15f-8f. Če se vrnemo k seznamu virtualnih vrat v Openstacku, se ta tip vrat uporablja za povezovanje različnih virtualnih naprav z OVS. Natančneje, qr je vrata v smeri virtualnega usmerjevalnika, ki je predstavljena v obliki namespace.
Poglejmo, kateri namespace obstajajo na strežniku:
[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 instance. Vendar pa lahko po imenih sklepamo o namenu vsakega od njih. K instance s ID 0 in 1 se bomo vrnili pozneje, zdaj pa nas zanima prostor qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ V tem prostoru sta dve notranji, ki smo jih ustvarili prej. Obe virtualni vrata sta dodani v br-int. Preverimo MAC naslov vrat qr-0c52b15f-8f, saj se je promet, sodeč po MAC naslovu, usmerjal prav v ta vmesnik.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ To pomeni, da vse deluje po zakonih standardne usmerjanja. Ker je promet namenjen gostitelju 10.0.2.8, mora oditi skozi drugi vmesnik qr-92fa49b5-54 in oditi preko vxlan tunela na računalniško vozlišče:
[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 ~]$ Vse je logično, brez presenečenj. Poglejmo, od kod je dostopen MAC naslov gostitelja 10.0.2.8 v 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 ~]$ Kot se spodobi, promet gre v br-tun, poglejmo, v kateri tunel bo promet nadaljeval:
[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 ~]$ Трафик уходит в тоннель до compute-1. На compute-1 все просто — из br-tun пакет попадает в br-int и оттуда в интерфейс виртуальной машины:
[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 ~]$ Проверим, что это действительно верный интерфейс:
[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 ~]$ Мы проследили весь путь пакета. Думаю, вы заметили, что трафик шел через разные vxlan тоннели и выходил с разными VNI. Давайте посмотрим, какие это VNI, и затем соберем дамп на порту управляющей ноды, удостоверившись, что трафик идет именно так, как описано выше.
Итак, тоннель до compute-0 имеет следующий actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Переведем 0x16 в десятичную систему счисления:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Тоннель до compute-1 имеет следующий VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Переведем 0x63 в десятичную систему счисления:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Теперь посмотрим дамп:
[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 upakiran ICMP paket s hosta 10.0.1.85 na host 10.0.2.8. Kako smo ranije izračunali, vni odgovara onome što smo vidjeli u ispisima.
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 upakiran ICMP paket s hosta 10.0.1.85 na host 10.0.2.8. Kako smo ranije izračunali, vni odgovara onome što smo vidjeli u ispisima.
Dva sljedeća paketa su obratni promet s 10.0.2.8 na 10.0.1.85.
Dakle, na kraju imamo ovu shemu control čvora:
Izgleda da je sve? Zaboravili smo o dva namespace-a:
[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 mašine automatski dobijaju adrese od DHCP servera. To su dva DHCP servera za naše dvije mreže 10.0.1.0/24 i 10.0.2.0/24.
Proverimo da li je to tačno. U ovom namespace-u postoji samo jedna adresa - 10.0.1.1 - adresa samog DHCP servera, 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 0Let's check if there are any processes containing the name qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 on the control node:
[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 ~]$ There is such a process, and based on the information presented in the output above, we can check what we currently have leased:
[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 ~]$As a result, we obtain this set of services on the control node:
Obdržite na pamet, da gre le za 4 naprave, 2 notranji mreži in en virtualni usmerjevalnik ... Trenutno nimamo zunanjih omrežij, kupa različnih projektov, vsak s svojimi (presečnimi) omrežji, in izklopljen imamo porazdeljen usmerjevalnik; v končni fazi je bila v testnem okolju samo ena kontrolna vozlišča (za odpornost mora biti kvorum treh vozlišč). Logično je, da je v komercialnem svetu vse "malo" bolj zapleteno, vendar na tem enostavnem primeru razumemo, kako bi to moralo delovati - ali imate 3 ali 300 namespace-ov, je seveda pomembno, toda z vidika delovanja celotne konstrukcije se pravzaprav ne bo spremenilo ... res je, dokler ne vključite kakšnega pridobljenega SDN. Ampak to je že povsem druga zgodba.
Upam, da je bilo zanimivo. Če imate opombe/dopolnila ali pa sem kje očitno lagal (sem človek in moje mnenje bo vedno subjektivno) - pišite, kaj je treba popraviti/dodati - vse bomo popravili/dodali.
Na koncu bi želel povedati nekaj besed o primerjavi OpenStacka (tako vanilijevega kot vladarnih različic) s storitvijo v oblaku podjetja VMWare - prevečkrat so mi v zadnjih dveh letih postavili to vprašanje in že sem res utrujen od njega, a vseeno. Po mojem mnenju je zelo težko primerjati ta dva rešitvi, a lahko nedvomno rečem, da imata oba rešitve svoje slabosti in pri izbiri ene rešitve je treba pretehtati vse prednosti in slabosti.
Če je OpenStack skupnostno usmerjena rešitev, pa ima VMWare pravico delati samo to, kar želi (beri - kar je zanje dobičkonosno) in to je logično - ker je to komercialno podjetje, ki je navajeno zaslužiti denar na svojih strankah. Toda tu je ena velika in debela PA - lahko se preusmerite z OpenStacka, recimo od Nokie, in z malo truda preidete na rešitev, recimo od Juniperja (Contrail Cloud), vendar se z VMWarejem verjetno ne boste mogli tako enostavno umakniti. Po mojem mnenju ti dve rešitvi izgledata takole - OpenStack (vladar) je preprosta kletka, v katero ste zaprti, imate ključ in lahko kadarkoli izstopite. VMWare je zlata kletka, ključ od kletke je pri lastniku in vas bo stal zelo dosti.
Ne agituojų nei už pirmą produktą, nei už antrą — jūs pasirinkite tai, ko jums reikia. Bet jei man tektų pasirinkti, pasirinktų abu sprendimus — VMWare IT debesų sprendimams (mažoms apkrovoms, patogiam valdymui), OpenStack iš bet kurio tiekėjo (Nokia ir Juniper siūlo labai gerus sprendimus raktas raktui) — Telekomunikacijų debesims. Aš nesirinkčiau Openstack grynai IT — tai kaip šauti iš patrankos į žvirblį, bet aš nematau jokių impedimentų jį naudoti, išskyrus perteklinumą. Tačiau naudoti VMWare telekomunikacijose — tai kaip vežti skaldą „Ford Raptor“ — gražu iš šono, bet vairuotojui tenka daryti 10 reisų vietoje vieno.
Mano nuomone, didžiausias VMWare trūkumas yra jo visiška uždarumas — įmonė jums nesuteiks jokios informacijos apie tai, kaip pas ją veikia pavyzdžiui vSAN arba kas ten hipervizoriaus branduolyje — jai tai paprasčiausiai nenaudinga — tai reiškia, kad jūs niekada netapsite VMWare ekspertu — be tiekėjo paramos esate pasmerkti (labai dažnai sutinku VMWare specialistų, kuriuos užgauna elementarūs klausimai). Man VMWare yra kaip automobilio pirkimas su užrakintu variklio dangčiu — taip, galbūt turite specialistų, kurie gali pakeisti diržą, bet variklio dangtį gali atidaryti tik tas, kuris jums pardavė šį sprendimą. Asmeniškai aš nemėgstu sprendimų, į kuriuos negaliu įlįsti. Pasakysite, kad galbūt jums nereikės lįsti po dangčiu. Taip, tai gali būti tiesa, bet aš pažiūrėsiu į jus, kai jums reikės sukonstruoti didelę funkciją debesyje iš 20-30 virtualių mašinų, 40-50 tinklų, pusė kurių nori išeiti į išorę, o kita pusė prašo SR-IOV pagreitimo, kitaip jums reikės dar poros dešimčių tokių mašinų — kitaip nebus pakankamai našumo.
Yra ir kitų požiūrių, todėl pasirinkti belieka jums, ir svarbiausia — jums reikia atsakyti už savo pasirinkimą. Tai tik mano nuomonė — žmogaus, kuris matė ir aptvėrė rankomis bent keturis produktus — Nokia, Juniper, Red Hat ir VMWare. Tai reiškia, kad turiu su kuo palyginti.
Izvor: habr.com
