Sissejuhatus pilveinfrastruktuuri võrku

Pilvearvutamine tungib aina sügavamale meie ellu ja ilmselt ei ole ühtegi inimest, kes ei oleks kunagi kasutanud mõnda pilveteenust. Kuid mis on õieti pilv ja kuidas see töötab, teab enamik inimesi vaid idee tasandil. 5G muutub juba reaalsuseks ning telekommunikatsiooni infrastruktuur hakkab liikuma traditsioonilistelt lahendustelt pilvelahendustele, nagu see toimus üleminekul täielikult füüsilistelt lahendustelt virtuaalsetele "poodidele".

Täna räägime pilve infrastruktuuri sisemaailmast, keskendudes eriti võrgutehnoloogia aluste käsitlemisele.

Mis on pilv? Kas see on lihtsalt virtualiseerimine — vaade külje pealt?

Väga loogiline küsimus. Ei — see ei ole virtualiseerimine, kuigi ilma selleta ei saa. Vaatame kahte määratlust:

Pilvearvutamine (edaspidi Pilv) — see on mudel, mis pakub kasutajasõbralikku juurdepääsu jaotatud arvutusressurssidele, mis tuleb käivitada ja aktiveerida nõudmisel minimaalse viivituse ja minimaalsete kuludega teenusepakkuja poolt.

Virtualiseerimine — see, et võimalus jagada üks füüsiline üksus (näiteks server) mitmeks virtuaalseks, suurendades seeläbi ressursside kasutust (näiteks oli teil 3 serverit, mis töötasid 25-30% ulatuses, pärast virtualiseerimist saate 1 serveri, mis töötab 80-90% ulatuses). Loomulikult kasutab virtualiseerimine osa ressurssidest — peate toitma hüperviisorit, kuid praktika on näidanud, et vaeva tasub end ära. Ideaalne näide virtualiseerimisest on VMWare, mis valmistab virtuaalseid masinaid suurepäraselt, või näiteks KVM, mis mulle rohkem meeldib, kuid see on juba maitse küsimus.

Me kasutame virtualiseerimist, isegi seda märkamatagi, isegi rauavõrgu ruuterid kasutavad juba virtualiseerimist — näiteks viimastel versioonidel JunOS operatsioonisüsteem installitakse virtuaalse masina peale real-time linux distributsiooni (Wind River 9). Kuid virtualiseerimine ei ole pilv, kuid pilv ei saa eksisteerida ilma virtualiseerimiseta.

Virtualiseerimine on üks telliskividest, mille peal pilv ehitatakse.

Pilve loomiseks, lihtsalt kogudes mitu hüperviisorit ühe L2 domeeni alla, lisades paar yaml mängu, et automaatselt määrata VLAN-e mõne Ansible'i kaudu, ja tõmmates selle peale midagi nagu koordineerimissüsteem virtuaalsete masinate automaatseks loomiseks — ei saa. Täpsemalt, see on võimalik, kuid saadud Frankenstein ei ole see pilv, mis meile vajalik on, kuigi võib-olla on see kellegi unistus. Lisaks, kui võtta näiteks OpenStack — see on ka tegelikult üks osa Frankensteinist, aga jätame selle praegu kõrvale.

Aga ma mõistan, et antud määratlusest ei ole täpselt selge, mida tõeliselt pilveks nimetada.

Seetõttu on NIST-i (Rahvuslik Standardite ja Tehnoloogia Instituut) dokumendis välja toodud 5 põhijooned, millega pilvine infrastruktuur peab olema varustatud:

Teenuse pakkumine nõudmisel. Kasutajale peab olema antud vaba juurdepääs eraldatud arvutiressurssidele (nt võrgud, virtuaalsed kettad, mälu, protsessorite tuumad jne), ning need ressursid peavad olema automaatselt kättesaadavad — st ilma teenuse pakkuja sekkumiseta.

Teeninduse laialdane kättesaadavus. Juurdepääs ressurssidele peab olema tagatud standardsete mehhanismide kaudu, et võimaldada kasutamist nii tavaliste PC-de, õhukeste klientide kui ka mobiilsete seadmete poolt.

Ressursside ühisuse loomine. Ressursside ühisused peavad tagama samal ajal ressursside pakkumise mitmele kliendile, tagades klientide isoleerituse ning takistades omavahelist mõju ja ressursside pärast konkureerimist. Ühisused sisaldavad ka võrgustikke, mis tähendab, et on võimalik kasutada kattuvat adresseerimist. Ühisused peavad toetama skaleerimist nõudmise põhja. Ühisuste kasutamine võimaldab tagada vajaliku teenuste katkestusteta kättesaadavuse taseme ja füüsiliste ning virtuaalsete resource'ide abstraktsiooni — teenuse saajale antakse lihtsalt tema soovitud ressursside komplekt (kus need ressursid füüsiliselt asuvad, mitmel serveril ja lülititel — klienti ei huvita). Siiski tuleb arvesse võtta, et teenusepakkuja peab tagama nende ressursside läbipaistva varundamise.

Kiire kohandamine erinevatesse tingimustesse. Teenused peavad olema paindlikud — kiire ressursside pakkumine, nende ümberjaotamine, ressursside lisamine või vähendamine kliendi nõudmisel, samas peab kliendil olema tunne, et pilveressursid on piiramatud. Lihtsuse huvides, näiteks, te ei näe hoiatust selle kohta, et teie Apple iCloudis on osa ketta ruumist kadunud, kuna serveris läks kõvaketas katki, kuid kõvakettad võivad tõepoolest kahjustuda. Lisaks on teie teenuse võimalused praktiliselt piiramatu — kui vajate 2 TB, siis mingeid probleeme ei ole, lihtsalt maksite ja saite. Sarnast näidet on võimalik tuua ka Google Drive’i või Yandex.Diski kohta.

Pakutava teenuse mõõtmise võimalus. Pilvesüsteemid peavad automaatselt jälgima ja optimeerima tarbitavaid ressursse, samas peavad need mehhanismid olema läbipaistvad nii kasutajale kui teenusepakkujale. See tähendab, et teil on alati võimalus kontrollida, kui palju ressursse te ja teie kliendid kasutate.

Oluline on arvestada, et need nõuded on enamikul juhtudel seotud avaliku pilvega. Seetõttu võivad need privaatse pilve (st ettevõtte sisemiste vajaduste jaoks loodud pilve) puhul olla pisut kohandatud. Siiski peavad need olema täidetud, vastasel juhul ei saavuta me kõiki pilveteenuste eeliseid.

Miks me vajame pilve?

Kuid iga uus või juba olemasolev tehnoloogia, iga uus protokoll luuakse millegi jaoks (välja arvatud RIP-ng, loomulikult). Protokoll protokolliks — ei ole kellelegi vajalik (välja arvatud RIP-ng, loomulikult). On loogiline, et pilv luuakse selleks, et pakkuda kasutajale/klientidele mingit teenust. Me kõik oleme tuttavad vähemalt paariga pilveteenusest, näiteks Dropbox või Google.Docs, ja ma usun, et enamus kasutab neid edukalt — näiteks on see artikkel kirjutatud Google.Docsi pilveteenuse kaudu. Kuid tuntud pilveteenused on vaid osa pilve võimalustest — täpsemalt öeldes on need vaid SaaS tüüpi teenused. Pilveteenust võime pakkuda kolme viisi: SaaS, PaaS või IaaS. Millist teenust just teile vaja läheb, sõltub teie soovidest ja võimalustest.

Vaadakem igaüht järjest.

Tarkvara kui teenus (SaaS) — see on täielik teenuse mudel kliendile, näiteks postiteenused nagu Yandex.Mail või Gmail. Sellise teenuse mudeli puhul ei pea te, kliendina, praktiliselt mitte midagi tegema, välja arvatud teenuse kasutamine — see tähendab, et te ei pea muretsema teenuse seadistamise, selle läbisõidutaluvuse või varukoopiate tegemise pärast. Oluline on mitte oma parooli kompromiteerida, kõik muu teeb teie eest teenuse pakkuja. Teenuse pakkujana kannate te täieliku vastutuse kogu teenuse eest — alates serveri riistvarast ja hostimise opsüsteemidest kuni andmebaaside ja tarkvara seadistusteni.

Platform as a Service (PaaS) — antud mudeli kasutamisel pakub teenuseosutaja kliendile teenuse jaoks valmisoleku, näiteks võtame veebiserveri. Teenuseosutaja on kliendile andnud virtuaalse serveri (tegelikult ressursside komplekti, nagu RAM/CPU/Storage/Võrgud jms) ning isegi paigaldanud sellele serverile operatsioonisüsteemi ja vajaliku tarkvara, kuid kogu selle seadistamisega tegeleb klient ise ning vastutab teenuse toimimise eest. Teenuseosutaja vastutab nagu eelnevas näites füüsilise riistvara, hüperviisori, virtuaalmasina enda, selle võrgu kättesaadavuse jms toimimise eest, kuid ise teenuse eest enam ei vastuta.

Infrastructure as a Service (IaaS) — see, this approach is more interesting; essentially, the service provider offers the client a full virtualized infrastructure — meaning a set (pool) of resources such as CPU Cores, RAM, Networks, etc. Everything else is up to the client — what the client wants to do with these resources within the allocated pool (quota) — it’s not particularly important to the provider. Whether the client wants to create their own vEPC or even become a mini-operator and offer communication services — that's not a problem — go ahead. In this scenario, the service provider is responsible for delivering the resources, their redundancy and availability, as well as the OS that allows combining these resources into pools and providing them to the client with the capability to increase or decrease resources upon the client's request at any moment. The client configures all virtual machines and other fluff themselves via the self-service portal and console, including network configuration (except for external networks).

Mis on OpenStack?

Kõigis kolmes variandis vajab teenusepakkuja operatsioonisüsteemi, mis võimaldab luua pilveteenuse infrastruktuuri. Tegelikult vastutab SaaS-i puhul kogu tehnoloogiapaki eest mitte üks osakond — on osakond, mis vastutab infrastruktuuri eest, see tähendab, et see pakub IaaS-i teisele osakonnale, mis omakorda pakub klientidele SaaS-i. OpenStack on üks pilveoperatsioonisüsteemidest, mis võimaldab ühendada hulga lüliteid, servereid ja salvestussüsteeme üheks ressursipooliks, jagada see yhte ressursipool alamressursipoolideks (tenandid) ja pakkuda neid ressursse klientidele võrgus.

OpenStack — on pilveoperatsioonisüsteem, mis võimaldab hallata suuri arvutusressursside, andmesalvestuste ja võrguressursside poolusi, mille tõhustamine ja haldamine toimub üle API kasutades standardseid autentimise mehhanisme.

Teisena, see on avatud lähtekoodiga projektide komplekt, mis on mõeldud pilveteenuste, nii avalike kui ka privaatsete, loomiseks - see tähendab tööriistade kogumit, mis võimaldab serveri- ja lülitusvarasid ühendada ühte ressursipooli, hallata neid ning tagada vajalik tase rikke taluvust.

Käesoleva teksti kirjutamise hetkel näeb OpenStacki struktuur välja järgmine:

Pilt on võetud aadressilt openstack.org

Iga OpenStacki komponente täidab mingisugust kindlat funktsiooni. Selline hajutatud arhitektuur võimaldab lisada lahendusse just need funktsionaalsed komponendid, mis on vajalikud. Siiski on osa komponente põhikomponendid ja nende eemaldamine toob kaasa lahenduse täieliku või osalise mittetoimimise. Selliste komponentide hulka kuuluvad:

• Armatuurlauale — Webipõhine GUI OpenStacki teenuste haldamiseks
• Keystone — keskne identifitseerimise teenus, mis pakub autentimise ja autoriseerimise funktsionaalsust teistele teenustele ning haldab kasutajate mandaate ja nende rolle.
• Neutron — võrgu teenus, mis tagab ühenduse erinevate OpenStacki teenuste liidesete vahel (sealhulgas ühenduse VM-ide vahel ja nende juurdepääsu välismaailmale)
• Cinder — võimaldab juurdepääsu plokkhoidlatele virtuaalmasinatele
• Nova — haldab virtuaalmasinate elutsüklit
• Glance — virtuaalmasinate ja hetkevõtete piltide hoidla
• Swift — võimaldab juurdepääsu objektide hoidlatele
• Ceilometer — teenus, mis võimaldab koguda telemeetriat ja mõõta olemasolevaid ja tarbitavaid ressursse
• Heat — malle põhine orkestreerimine ressursside automaatseks loomiseks ja proviisioonimiseks

Kogu projektide nimekiri ja nende määrangud on vaadatavad siin.

Iga OpenStacki koostisosa on teenus, mis vastutab kindla funktsiooni eest ja pakub API-d selle funktsiooni haldamiseks ning selle teenuse koostoimeks teiste pilveteenuste operatsioonisüsteemis, eesmärgiga luua ühtne infrastruktuur. Näiteks Nova tagab arvutusressursside haldamise ja API nende ressursside seadistamiseks, Glance – pildihalduse ja API nende haldamiseks, Cinder – plokkhällide haldamise ja API nende üle ning nii edasi. Kõik funktsioonid on omavahel tihedalt seotud.

Kuid kui mõelda, et kõik OpenStackis töötavad teenused esindavad lõpuks mingit virtuaalmasinat (või konteinerit), mis on ühendatud võrku. Tekib küsimus — miks meil on nii palju komponente?

Vaatame läbi virtuaalmasina loomise ja selle ühendamise protsessi võrku ja püsivasse salvestusse OpenStackis.

1. Kui loote masina loomiseks päringu, olgu see siis päring Horizonis (armatuurlaud) või CLI kaudu, toimub kõigepealt teie päringu autoriseerimine Keystone'is — kas teil on õigus masinat luua, kas teil on õigus kasutada antud võrku, kas teie projektil on piisavalt kvooti jne.
2. Keystone autentib teie päringu ja genereerib vastusena auth-tokeni, mida kasutatakse hiljem. Pärast vastuse saamist Keystone'ilt saadetakse päring edasi Nova (nova api) poole.
3. Nova-api kontrollib teie päringu kehtivust, pöördudes tagasi Keystone'i poole, kasutades eelnevalt genereeritud auth-tokenit.
4. Keystone teeb autentimise ja annab selle auth-tokeni põhjal teavet lubade ja piirangute kohta.
5. Nova-api loob nova-andmebaasis uue VM-i salvestuse ja edastab masina loomise päringu nova-scheduler'ile.
6. Nova-scheduler valib hosti (arvuti sõlme), kus VM hakatakse määrama vastavalt antud parameetritele, kaaludele ja tsoonidele. Teave selle ja VM-i identifikaatori kohta salvestatakse nova-andmebaasi.
7. See further, nova-scheduler connects to nova-compute with a request to deploy an instance. Nova-compute calls nova-conductor to retrieve machine parameter information (nova-conductor acts as a proxy server between nova-database and nova-compute, limiting the number of requests made to nova-database to avoid database consistency issues and reduce load).
8. Nova-conductor retrieves the requested information from nova-database and forwards it to nova-compute.
9. Next, nova-compute requests the image ID from glance. Glance validates the request in Keystone and returns the requested information.
10. Nova-compute queries neutron for network parameter information. Similarly to glance, neutron validates the request in Keystone, creates an entry in the database (port identifier, etc.), initiates a port creation request, and returns the requested information to nova-compute.
11. Nova-compute sends a request to cinder to allocate a volume for the virtual machine. Like glance, cinder validates the request in Keystone, starts the volume creation request, and sends back the requested information.
12. Nova-compute kutsub libvirt'i, et teostada virtuaalmasina juurutamist antud parameetritega.

Tegemist on näiliselt lihtsa operatsiooniga lihtsa virtuaalmasina loomisel, mis muutub pilveplatvormi elementide vaheliste API-kõnede keerukaks keeriseks. Nagu näete, koosnevad isegi varem nimetatud teenused väiksematest komponentidest, mille vahel toimub suhtlemine. Masina loomine on vaid väike osa sellest, mida pilveplatvorm võimaldab – on teenus, mis vastutab liikluse koormuse tasakaalustamise eest, teenus, mis vastutab plokkide salvestamise eest, teenus, mis vastutab DNS-i, teenus, mis vastutab bare metal serverite vahendamise eest jne. Pilv võimaldab teil suhelda oma virtuaalmasinatega kui lambakarjaga (erinevalt virtualiseerimisest). Kui virtuaalses keskkonnas juhtub masinaga miski – taastate selle varundustest jne, siis pilve rakendused on üles ehitatud nii, et virtuaalmasin ei mängi nii suurt rolli – kui virtuaalmasin "suri" – pole muret – lihtsalt luuakse uus masin malendi põhjal ja, nagu öeldakse, rühm ei märganud kaotatud võitlejat. Loomulikult eeldab see orkestreerimise mehhanismide olemasolu – kasutades Heat šabloone, saate hõlpsasti juurutada keerulisi funktsioone, mis koosnevad kümnetest võrgudest ja virtuaalmasinatest.

On alati oluline meeles pidada, et pilveinfrastruktuuri ei eksisteeri ilma võrguta — iga element mõjutab teisi elemente võrgu kaudu. Veelgi enam, pilv ei ole sugugi staatiline. Loomulikult on aluseks olev võrk rohkem-vähem staatiline — uute sõlmede ja lülitite lisamine ei toimu iga päev, kuid overlay komponent võib pidevalt muutuda — uued võrgud võivad tekkida või kaduda, uued virtuaalmasinad ilmuvad ja vanad surevad. Ja nagu te mäletate, on pilve määratlemise kohaselt ressursid automaatselt kasutajale kergest (veel parem, ilma) teenusepakkuja sekkumiseta eraldatud. Seega, see võrguteenuse pakkumise tüüp, mida praegu teie isikliku kabineti ees on http/https kaudu ja valves oleva võrguinseneri Vasili tagapool — see ei ole pilv, isegi kui Vasili on kaheksa kät.

Neutron, olles võrgu teenus, pakub API-d pilve infrastruktuuri võrguosa haldamiseks. Teenus tagab OpenStacki võrguosa töökindluse ja halduse, pakkudes abstraktsioonitaset, mida nimetatakse Network-as-a-Service (NaaS). St, võrguosa on sama virtuaalne mõõdetav element nagu näiteks virtuaalsed CPU tuumad või RAMi maht.

Kuid enne, kui liigume OpenStacki võrguosa arhitektuuri juurde, vaatame, kuidas see võrguosa OpenStackis toimib ja miks see on oluline ja lahutamatu osa pilvest.

Nii et meil on kaks kliendi virtuaalmasinat RED ja kaks kliendi virtuaalmasinat GREEN. Oletame, et need masinad on paigutatud kahe hüperviisori peale selliselt:

Praegu on see lihtsalt nelja serveri virtualiseerimine ja mitte rohkem, kuna seni oleme virtualiseerinud neli serverit, paigutades need kahe füüsilise serveri peale. Veel pole nad isegi võrku ühendatud.

Kuna pilve loomiseks on meil vaja lisada mitu komponenti. Esiteks virtualiseerime võrguosa — me peame need 4 masinat paarikaupa ühendama ning kliendid soovivad just L2 ühendust. Loomulikult võib kasutada lülitit ja seadistada selle poole trunk ning lahendada kõik Linuxi silla kaudu, või arenenumate kasutajate jaoks openvswitch (selle juurde me veel naaseme). Kuid võrgud võivad olla väga palju, ja pidevalt L2 lüliti kaudu suruma — ei ole just parim idee — see toob erinevate osakondade, teeninduskeskuse, kuud kestnud taotluste täitmise ootamise ja nädalate kaupa tõrkeotsingu. Kaasaegses maailmas ei tööta selline lähenemine enam. Mida varem ettevõte seda mõistab, seda lihtsam on tal edasi liikuda. Seetõttu eraldame hüperviisorite vahel L3 võrgu, mille kaudu meie virtuaalmasinad suhtlevad, ja selle L3 võrgu peale ehitame virtuaalsed pealiskihilised L2 (overlay) võrgud, kus liigub meie virtuaalmasinate liiklus. Inkaptsuleerimiseks võib kasutada GRE, Geneve või VxLAN. Peame praegu peatuma viimase peal, kuigi see pole eriti oluline.

Meil tuleb kuhugi paigutada VTEP (loodan, et kõik tunnevad VxLANi terminoloogiat). Kuna meie serveritest väljub kohe L3 võrk, ei takista see meid VTEP-i paigutamast otse serveritesse, kus OVS (OpenvSwitch) oskab seda suurepäraselt teha. Tulemusena saime sellise konstruktsiooni:

Kuna liiklus virtuaalsete masinate vahel peab olema eristatav, on portide numbrid virtuaalsete masinate suunas erinevad VLAN-i numbrid. Tagi number mängib rolli ainult ühe virtuaalse lüliti piires, kuna VxLAN-isse kapseldamise korral saame selle probleemideta eemaldada, kuna meil on olemas VNI.

Nüüd saame luua meie seadmeid ja nende jaoks virtuaalseid võrke ilma igasuguste probleemideta.

Ent mis juhtub, kui kliendil on veel üks masin, kuid see asub teises võrgus? Me vajame võrkude vahel ruteerimist. Vaatame lihtsat varianti, kus kasutatakse tsentraliseeritud ruteerimist - see tähendab, et liiklus ruteeritakse spetsiaalsete pühendatud võrgu sõlmede kaudu (tavaliselt on need kombineeritud juhtimissõlmedega, seega meil on sama).

Tundub, et pole midagi keerulist — loome sillaliidese kontrollpunktis, suuname sinna liiklust ja sealt marsruutime selle sinna, kuhu meil on vaja. Kuid probleem on selles, et klient RED soovib kasutada võrku 10.0.0.0/24 ja klient GREEN soovib kasutada võrku 10.0.0.0/24. See tähendab, et meie aadressiruumid hakkavad kattuma. Lisaks ei soovi kliendid, et teised kliendid saaksid marsruutida nende sisevõrkudesse, mis on loogiline. Klientide võrkude ja andmeliikluse eraldamiseks määrame igaühele eraldi namespaces. Namespace on sisuliselt Linuxi võrgu stack'i koopia, see tähendab, et RED namespace'is olevad kliendid on täielikult isoleeritud GREEN namespace'i klientidest (kui marsruutimine nende klientide vahel on lubatud, toimub see läbi default namespace'i või juba kõrgema taseme transpordiseadmetes).

Seega saame sellise skeemi:

L2 tunnelid kogunevad kõigist arvutusnode'dest kontrollpunkti, kus asub L3 liides nende andmesidevõrkude jaoks, igaüks eraldi namespace'is isoleerimise tagamiseks.

Kuid me unustasime kõige olulisema. Virtuaalne masin peab pakkuma klientidele teenust, mis tähendab, et sellel peab olema vähemalt üks väline liides, mille kaudu on võimalik ühendust saada. See tähendab, et peame välja minema välismaailma. Siin on erinevaid võimalusi. Teeme kõige lihtsama variandi. Lisame igale kliendile ühe võrgu, mis on valideeritud teenusepakkujas ja ei kattu teiste võrkudega. Võrgud võivad samuti üksteisega kattuda ja vaadata erinevatesse VRF-desse teenusepakkuja võrgus. Need võrgud elavad samuti iga kliendi nimede ruumis. Kuid nad peavad ikkagi välja minema välismaailma läbi ühe füüsilise (või loogilise, mis on mõistlikum) liidese. Klientide liikluse eristamiseks toimub väljastatud liikluse tagamine VLAN-täitega, mis on määratud kliendile.

Lõpuks saime sellise skeemi:

Tõsine küsimus on, miks mitte luua väravaid otse compute sõlmedes? Suurt probleemi selles ei ole, isegi rohkem, kui aktiveerida jaotatud ruuter (DVR), hakkab see nii ka toimima. Antud stsenaariumis vaatleme kõige lihtsamat varianti kesksete väravate puhul, mida OpenStack kasutab vaikimisi. Suure koormusega funktsioonide puhul kasutatakse nii jaotatud ruuterit kui ka kiirendustehnologiaid nagu SR-IOV ja Passthrough, kuid nagu öeldakse, see on juba hoopis teine lugu. Kõigepealt vaatame põhiosa, seejärel sukeldume detailidesse.

Tegelikult on meie skeem juba toimiv, kuid on paar nüanssi:

• Peame kuidagi kaitsma meie masinad, see tähendab, et peame kliendi poole suunatud lüliti liidesele filtrid panema.
• Luua võimalus, et virtuaalne masin saaks automaatselt IP-aadressi, et ei peaks iga kord konsooli kaudu sisse logima ja aadressi sisestama.

Alustame masinate kaitsmisest. Selleks võib kasutada tavalisi iptables, miks mitte.

See tähendab, et nüüd on meie topoloogia juba veidi keerulisem:

Jätkame. Me peame lisama DHCP serveri. Iga kliendi jaoks oleks ideaalne koht DHCP serverite paigutamiseks juba mainitud kontrollida, kus asuvad nimed:

Kuid on väike probleem. Mis juhtub, kui kõik taaskäivitatakse ja kogu DHCP aadresside rentimise info kaob? Loogiliselt peaks masinatele olema määratud uued aadressid, mis ei ole kuigi mugav. Väljapääse on kaks — kas kasutada domeeninimesid ja lisada DNS server iga kliendi jaoks, siis ei ole aadress eriti oluline (sarnaselt k8s võrguosale) — kuid siin on probleem välistes võrkudes, kuna seal võivad aadresse samuti määrata DHCP — on vajalik sünkroonimine pilveteenuste DNS serverite ja väliste DNS serverite vahel, mis minu arvates ei ole väga paindlik, kuid täiesti võimalik. Teine variant on kasutada metaandmeid — see tähendab, et salvestada teave määratud masina aadressi kohta, et DHCP server teaks, millist aadressi masinale määrata, kui masin on juba aadressi saanud. Teine variant on lihtsam ja paindlikum, kuna see võimaldab säilitada lisainfot masina kohta. Nüüd lisame skeemile metadata agendi:

Veel küsitakse, kas kõik kliendid saavad kasutada ühte välist võrku. Kui välised võrgud peavad olema kehtivad kogu võrgu ulatuses, võivad tekkida raskused – tuleb pidevalt eraldada ja kontrollida nende võrkude eraldamist. Kõikide klientide jaoks ühise eelhäälestatud välist võrgu kasutamise võimalus oleks avaliku pilve loomisel väga kasulik. See lihtsustab masinate käivitamist, kuna meil ei oleks vaja võrrelda aadresside andmebaasi ja valida iga kliendi välist võrku unikaalne aadressiruum. Lisaks saame välist võrku ette määrata ja käivitamise hetkel tuleb vaid seostada välishaadressid kliendi masinatega.

Siin tuleb meile appi NAT — võimaldame klientidel väljuda välismaailma läbi vaikimisi namespace'i, kasutades NAT-i tõlget. Siin on väike probleem. See on hea, kui kliendi server töötab kui klient, mitte server — st algatab, mitte ei võta ühendusi vastu. Kuid meil on vastupidi. Sellises olukorras peame tegema sihtkoha NAT-i, et kontrollpunkt mõistaks, et see liiklus on mõeldud kliendi A virtuaalmasinale, mis tähendab, et peame tegema NAT-i tõlke välisest aadressist, näiteks 100.1.1.1, siseadressiks 10.0.0.1. Sel juhul, kuigi kõik kliendid kasutavad sama võrku, säilib sisemine isoleeritus täielikult. See tähendab, et meil peab olema kontrollpunktis dNAT ja sNAT. Ühtse võrgu kasutamine koos ujuvate aadresside ja väliste võrkude või mõlema samaaegse kasutamisega sõltub sellest, mida soovite pilve tõmmata. Me ei lisa skeemile veel ujuvaid aadresse, vaid jätame alles juba varem lisatud välised võrgud — igal kliendil on oma väline võrk (skeemil on tähistatud kui VLAN 100 ja 200 välisel liidesel).

Kokkuvõttes saime huvitava ja samas läbimõeldud lahenduse, millel on teatud paindlikkus, kuid millel puuduvad veel tõrketaluvuse mehhanismid.

Esiteks on meil ainult üks kontrollsõlm — selle rike toob kaasa kõigi süsteemide kokkuvarisemise. Selle probleemi lahendamiseks on vajalik luua vähemalt 3-sõlme kvoorum. Lisame selle skeemile:

Muidugi sünkroniseeruvad kõik sõlmed ja aktiivse sõlme rikete korral võtab teise sõlme kohustused enda peale.

Järgmine probleem on virtuaalmasinate kettad. Praegu salvestatakse need hüperviisorites ja hüperviisori probleemide korral kaotame kõik andmed - ja RAID ei aita siin, kui me kaotame mitte ketta, vaid terve serveri. Selleks vajame teenust, mis toimiks mõne ladustamise esirinnana. Milline ladustamine see on, pole meile oluline, kuid see peab kaitsma meie andmeid kettast, sõlmedest ja võib-olla isegi tervest kapist ebaõnnestumise eest. Siin on mitu võimalust - loomulikult on olemas SAN-võrgud Fiber Channeliga, kuid olgem ausad - FC on juba minevik, nagu E1 transpordis - jah, nõustun, et seda veel kasutatakse, kuid ainult seal, kus ilma selleta ei saa. Seetõttu ma ei sooviks vabatahtlikult 2020. aastal FC-võrku rajada, teades, et on olemas teisi huvitavamaid alternatiive. Kuigi igal ühel on oma eelistused ja võib-olla leidub neid, kes arvavad, et FC koos kõigi oma piirangutega on kõik, mida vajame - ma ei vaidle, igalühel on oma arvamus. Kuid kõige huvitavam lahendus, minu arvates, on SDS-i kasutamine, näiteks Ceph.

Ceph võimaldab luua kõrge kättesaadavusega andmete salvestamise lahenduse, millel on palju võimalusi varundamiseks, alates pariteedi koodidest (sarnased RAID 5 või 6) kuni andmete täieliku replikatsioonini erinevatesse ketastesse, arvestades ketaste asukohti serverites ja serverite asukohti kappides jne.

Ceph'i koostamiseks on veel vaja kolme sõlme. Salvestusse suheldakse samuti võrgu kaudu, kasutades plokk-, objekt- ja failihaldusteenuseid. Lisame skeemile salvestuse:

Märkus: hüperkonvergente compute nodid on samuti võimalikud — see on kontseptsioon, mis ühendab mitmeid funktsioone ühel nodil — näiteks storage+compute — mitte eraldada spetsiaalseid node'e ceph storage'ile. Saame sama taseme talitlushäirete taluvuse, kuna SDS broneerib andmed soovitud broneerimise tasemega. Kuid hüperkonvergente node'id on alati kompromiss, kuna storage node ei lihtsalt „sooja õhku” nagu esmapilgul tundub (kuna sellel ei ole virtuaalmasinaid) — see kulutab CPU ressursse SDS hooldamiseks (tegelikult teeb ta taustal kõik replikatsioonid, taastumised node’ide ja ketaste riketest jne). See tähendab, et kaotate osaliselt compute node'i võimsuse, kui kombineerite selle storage'iga.

Kogu selle heaoluga peab kuidagi toime tulema — vajame midagi, mille kaudu saame luua masina, võrgu, virtuaalse marsruuteri jne. Selleks lisame kontrollnodile teenuse, mis täidab dashboard'i rolli — klient saab sellele portaalile http/https kaudu juurde pääseda ja teha kõike, mida ta vajab (peaaegu).

Kokkuvõttes on meil nüüd kõrgelt kergesti juurutatav süsteem. Kõiki selle infrastruktuuri komponente tuleb kuidagi hallata. Varem on mainitud, et Openstack on projektide kogum, millest igaühel on oma spetsiifiline funktsioon. Nagu näeme, on elemente, mida tuleb konfigureerida ja kontrollida, piisavalt. Täna räägime võrguosast.

Neutrone arhitektuur

OpenStackis vastutab Neutron virtuaalmasinate portide ühendamise eest ühise L2 võrgu kaudu, tagades liikluse marsruutimise erinevates L2 võrkudes asuvate VM-ide vahel ning tagapool marsruutimise, pakkudes selliseid teenuseid nagu NAT, Floating IP, DHCP jne.

Võrguteenuse kõrgema taseme töö (põhiosa) saab kirjeldada järgmiselt.

Virtuaalmasina käivitamisel võrguteenusega:

1. Loo port selle VM-i jaoks (või portide jaoks) ja teata sellest DHCP teenusele;
2. Loo uus virtuaalne võrgu seadmed (libvirt'i kaudu);
3. VM ühendatakse 1. sammus loodud portidega;

Kuid üllatavalt, Neutrone toimimise põhielemendid põhinevad standardsetel mehhanismidel, mis on tuttavad kõigile, kes on kunagi Linuxiga kokku puutunud — need on nimelt nimed, iptables, Linuxi sillad, openvswitch, conntrack jne.

On tuleb kohe märkida, et Neutron ei ole SDN kontroller.

Neutron koosneb mitmest omavahel seotud komponendist:

Openstack-neutron-server on demon, mis töötleb API kaudu kasutaja päringuid. See demon ei kirjuta mingisuguseid võrgukonfiguratsioone, vaid edastab vajaliku teabe oma pluginatele, mis seejärel konfigureerivad vajaliku võrguelemendi. Neutron-agentid OpenStacki sõlmedes registreeruvad Neutron-serveris.

Neutron-server on tegelikult rakendus, mis on kirjutatud pythonis ja koosneb kahest osast:

• REST teenus
• Neutron Plugin (core/service)

REST teenus on mõeldud API kutsungite vastuvõtmiseks teistelt komponentidelt (näiteks mingi teabe edastamise päring jne).

Pluginaid on sisseehitatud tarkvarakomponendid/moduulid, mis kutsutakse välja API päringute ajal – see tähendab, et mingi teenuse lisamine toimub nende kaudu. Pluginaid jagatakse kaheks: teenuse ja põhijagu. Reeglina vastutab põhijagu peamiselt aadressiruumi haldamise ja L2 ühenduste eest VMide vahel, samas kui teenuse pluginaid pakuvad täiendavaid funktsioone, näiteks VPN või FW.

Saadaval olevate pluginade nimekirja saab vaadata näiteks siin

Teenuse pluginaid võib olla mitmeid, kuid peamine plugin on ainult üks.

Openstack-neutron-ml2 on Openstacki standardne juurpugli. See plugin omab modulaarset arhitektuuri (erinevalt oma eelkäijast) ning konfigureerib võrgu teenuseid, kasutades oma külge ühendatavaid draivereid. Selle plugina kohta räägime hiljem, kuna just tema pakub OpenStacki võrguosas vajalikku paindlikkust. Juurpugli võib asendada (näiteks Contrail Networking teeb sellise asenduse).

RPC teenus (rabbitmq-server) on teenus, mis haldab järjekordi ning suhtleb teiste OpenStacki teenustega ning ka võrguteenuse agentidega.

Võrguagendid on agendid, mis asuvad igas sõlmes, läbi mille konfigureeritakse võrgu teenuseid.

Agente on mitut tüüpi.

Peamine agent on L2 agent. Need not be written on the hypervisors including and controlling nodes (more precisely, on all nodes that provide any services for tenants) and their main function is to connect virtual machines to a common L2 network, as well as generate alerts when any events occur (for example, port disconnections/connections).

The next, equally important agent is L3 agent. By default, this agent runs exclusively on the network node (often the network node is combined with the control node) and provides routing between tenant networks (both between its networks and the networks of other tenants, as well as access to the outside world, providing NAT and DHCP service). However, when using DVR (distributed router), there is a need for the L3 plugin even on compute nodes.

The L3 agent uses Linux namespaces to provide each tenant with a set of their own isolated networks and the functionality of virtual routers that route traffic and provide gateway services for Layer 2 networks.

Andmebaas — a database of identifiers for networks, subnets, ports, pools, etc.

Tegelikult Neutron võtab API päringud võrguelementide loomiseks, autentib päringu ja edastab arendajatele (kas läbi pluginate või agentide) vajalikud juhised, et korraldada soovitud teenust, kasutades RPC-d (kui suheldakse plugina või agendiga) või REST API-d (kui suheldakse SDN-iga).

Nüüd vaatame testinstallatsiooni (milline see on ja mis osad on seal, vaatame hiljem praktikas) ning uurime, kus asub iga komponent:

(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 ~]$ 

Ja, see on kogu Neutroni struktuur. Nüüd tasub veidi aega ML2 plugina peale mõelda.

Modulaarne Kiht 2

Nagu juba eespool mainitud, on pistikprogramm OpenStacki standardne juurpistikprogramm, mis omab modulaarset arhitektuuri.

ML2 pistikprogrammi eelkäijal oli monoliitne struktuur, mis ei võimaldanud näiteks kasutada mitut tehnoloogiat ühes installatsioonis. Näiteks ei saanud te kasutada nii openvswitch'i kui ka linuxbridge'i samaaegselt — kas esimest või teist. Sellepärast loodi ML2 pistikprogramm koos oma arhitektuuriga.

ML2-l on kaks koostisosad — kaks tüüpi draivereid: Type drivers ja Mechanism drivers.

Type drivers määratlevad tehnoloogiad, mida kasutatakse võrguühenduste korraldamiseks, nagu VxLAN, VLAN, GRE. Samas võimaldab draiver kasutada erinevaid tehnoloogiaid. Standardtehnoloogia on VxLAN-i kapseldamine overlay-võrkude jaoks ja vlan väliste võrkude jaoks.

Type drivers alla kuuluvad järgmised võrgu tüübid:

Flat — võrk ilma tähiseta
VLAN — tähistatud võrk
Lokaalne — eriline võrk, mis on mõeldud all-in-one tüüpi installatsioonide jaoks (sellised installatsioonid on vajalikud kas arendajatele või koolituseks)
GRE — overlay-võrk, mis kasutab GRE tunnelit
VxLAN — overlay-võrk, mis kasutab VxLAN tunnelit

Mechanism drivers määravad vahendid, mis tagavad tooted, mis on kokku lepitud type driver tehnoloogiate osas — näiteks openvswitch, sr-iov, opendaylight, OVN jne.

Sõltuvalt konkreetse draiveri teostusest kasutatakse kas Neutroni haldatavaid agente või luuakse ühendusi välist SDN kontrolleriga, mis võtab enda peale kõik L2 võrkude korraldamise, suunamise jne küsimused.

Näiteks, kui kasutame ML2 koos OVS-iga, installitakse igasse arvutusnode'sse L2 agent, mis haldab OVS-i. Kuid kui kasutame näiteks OVN-i või OpenDayLight'i, siis OVS-i haldamine läheb nende jurisdiktsiooni — Neutron annab aukplugin'i kaudu käsklusi kontrollerile, ja see teeb siis, mida tal on kästud.

Kordame üle Open vSwitch

Praeguseks on üks OpenStacki peamisi komponente Open vSwitch.
OpenStacki installimise korral ilma igasuguste lisavendorite SDN lahendusteta nagu Juniper Contrail või Nokia Nuage on OVS peamine võrgu komponent pilvevõrgus. Koos iptables, conntrack ja namespaces'iga võimaldab see luua täisfunktsionaalset ovareksemist ja multitenantsust. Loomulikult võib seda komponenti asendada, näiteks kolmandate osapoolte privaatsed (vendor) SDN lahendustega.

OVS on avatud lähtekoodiga tarkvaral põhinev lüliti, mis on mõeldud kasutamiseks virtualiseeritud keskkondades kui virtuaalne liikluse edastaja.

Praegu on OVS-l väga tugev funktsionaalsus, kuhu kuuluvad sellised tehnoloogiad nagu QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK jne.

Märkus: algselt ei olnud OVS mõeldud kõrgkoormuslike telekomifunktsioonide jaoks programmikommutaatorina, vaid pigem vähem nõudlikeks IT-funktsioonideks nagu veebiserver või meiliserver. Siiski on OVS-i arendatud ja praegused rakendused on oluliselt parandanud selle jõudlust ja võimalusi, mis võimaldab operaatoritel kasutada seda kõrgkoormuslike funktsioonide puhul; näiteks on olemas OVS-i rakendus, mis toetab DPDK kiirendust.

On kolm olulist OVS-i komponenti, millest tuleb teada:

• Kernel module — komponent, mis asub kernel space'is ja teostab liikluse töötlemist vastavalt juhtseadmest saadud reeglitele;
• vSwitch daemon (ovs-vswitchd) — see on user space'is töötav protsess, mis vastutab kernel-mooduli programmeerimise eest — see esindab otseselt kommutaatori töö loogikat.
• Database server — lokaalne andmebaas, mis asub igas hostis, kus OVS töötab, ja kus hoitakse konfiguratsiooni. Selle mooduli kaudu saavad SDN-kontrollerid omavahel kommunikatsiooni pidada OVSDB protokolli kaudu.

Selle kõigega kaasneb ka komplekt diagnostikast ja haldustööriistu, nagu ovs-vsctl, ovs-appctl, ovs-ofctl jne.

Praegu kasutatakse OpenStacki laialdaselt telekommunikatsioonifirmade poolt, et migreerida võrgu funktsioone nagu EPC, SBC, HLR jne. Mõned funktsioonid saavad probleemideta töötada OVS-i olemasolevas vormis, kuid näiteks EPC töötleb abonentide liiklust – see tähendab, et see laseb läbi tohutul hulgal liiklust (praeguseks ulatub liiklusmaht mitme sajani gigabitini sekundis). Loomulikult ei ole parim idee suunata sellist liiklust kernel'sse (kuna vaike seadistuse kohaselt asub edastaja seal). Seetõttu paigutatakse OVS sageli täielikult kasutaja ruumi, rakendades DPDK tehnoloogiat, et suunata liiklus NIC-ist kasutaja ruumi mööda kernel'it.

Märkus: pilves, mis on üles seatud telekommunikatsioonifunktsioonide jaoks, on võimalik suunata liiklust compute noodist mööda OVS-i otse kommutatsiooniseadmetesse. Selleks kasutatakse SR-IOV ja Passthrough mehhanisme.

Kuidas see töötab reaalsetes makettides?

Nüüd liikume praktilise osa juurde ja vaatame, kuidas see kõik praktikas töötab.

Alustuseks loome lihtsa OpenStack'i paigalduse. Kuna mul ei ole eksperimentide jaoks käepärast serverite komplekti, siis kogume maketi ühe füüsilise serveri peale virtuaalmasinatest. Jah, loomulikult ei sobi selline lahendus ärilistel eesmärkidel, kuid et näha, kuidas OpenStack'is võrgu töötab, piisab sellisest paigaldusest. Selline paigaldus on isegi õppimise eesmärgil huvitavam — sest saa jälgida liiklust ja nii edasi.

Kuna peame nägema vaid põhiosad, siis ei pea me kasutama mitut võrku, vaid saame kõik üles tõsta kaht võrku kasutades, kusjuures teine võrgu sel maketil on järgnevalt mõeldud ainult undercloud ja DNS serverile ligipääsuks. Väliseid võrke me hetkel puudutame — see on teema eraldi suure artikli jaoks.

Nii et, alustame järjekorras. Esmalt veidi teooriat. Paigaldame OpenStacki TripleO abil (OpenStack OpenStacki peal). TripleO mõte on, et me installime OpenStacki all-in-one (st ühele sõlmele), mida nimetatakse undercloudiks, ja seejärel kasutame loodud OpenStacki võimalusi, et paigaldada tootmiseks mõeldud OpenStack, mida nimetatakse overcloudiks. Undercloud kasutab oma sisse ehitatud võimet hallata füüsilisi servereid (bare metal) — projekt Ironic — hüperviisorite varustamiseks, mis täidavad compute, control ja storage sõlme rolle. Seega, me ei kasuta OpenStacki käivitamiseks mingeid kolmandate osapoolte vahendeid — paigaldame OpenStacki OpenStacki enda jõududega. Edasi minnes muutub see palju arusaadavamaks, seega ei peatu sel teemal, vaid liigume edasi.

Märkus: Käesolevas artiklis lihtsustamise eesmärgil ei kasutanud ma OpenStacki siseteenuste võrgu isoleerimist, vaid kõik on seadistatud ainult ühe võrgu kasutamisega. Siiski ei mõjuta võrgu isoleerimise olemasolu või puudumine lahenduse põhifunktsionaalsust - kõik töötab täpselt nii, nagu võrgus on isoleerimine, kuid liiklus liigub ühes võrgus. Kaubandusliku paigaldamise puhul on loomulikult vajalik kasutada erinevaid VLAN-e ja liideseid isoleerimise jaoks. Näiteks haldamise liiklus Ceph salvestamisse ja andmete liiklus (nt masinate juurdepääs kettale jne) kasutavad isoleerimise korral erinevaid alamvõrke (Storage management ja Storage), mis muudab lahenduse paindlikumaks, jagades seda liiklust näiteks erinevate portide kaudu või kasutades erinevaid QoS-profiile erineva liikluse jaoks, et andmeliiklus ei segaks juhtimisliiklust. Meie juhul kulgevad need siiski ühes ja samas võrgus ning see ei piira meid mingil moel.

Märkus: Kuna plaanime käivitada virtuaalmasinaid virtuaalses keskkonnas, mis põhineb virtuaalmasinatel, tuleb esmalt lubada pesad (nested) virtualiseerimist.

Kontrollimiseks, kas pesad virtualiseerimine on lubatud või mitte, saate teha järgmist:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

Kui näete tähte N, siis lubage pesade virtualiseerimise tugi igasuguste juhendite järgi, mida leidsite veebis, näiteks selline .

Peame koguma järgmise skeemi virtuaalmasinatest:

Minu puhul, et saavutada virtuaalmasinate ühenduvus, mis kuuluvad tulevasse installatsiooni (olen nende koguarvuks saanud 7, kuid kui teil pole palju ressursse, piisab ka 4) kasutasin OpenvSwitch'i. Loodasin ühe ovs sillaga ja ühendasin sellele virtuaalmasinad läbi port-gruppide. Selleks lõin järgmise vorminguga xml faili:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        

  ovs-network-1
  7a2e7de7-fc16-4e00-b1ed-4d190133af67

Siin on kolm portgruppi — kaks access ja üks trunk (viimane oli vajalik DNS-serveri jaoks, kuid selle saab ka vahele jätta või käivitada selle hostmasinas — kuidas soovite). Edasi määrame selle šablooni abil oma võrgu virsh net-define kaudu:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

Nüüd muudame hüperviisori portide konfiguratsioone:

[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 ~]# 

Märkus: antud stsenaariumis ei ole aadress porti ovs-br1 saadaval, kuna sel ei ole VLAN-i sildi. Selle parandamiseks tuleb anda käsk sudo ovs-vsctl set port ovs-br1 tag=100. Kuid pärast taaskäivitamist kaob see silt (kui keegi teab, kuidas seda säilitada, oleksin väga tänulik). Kuid see ei ole nii oluline, kuna see aadress on vajalik ainult installatsiooni ajal ja pole vajalik, kui OpenStack on täielikult paigaldatud.

Järgmiseks loome undercloud masina:

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

Paigaldamise käigus seadistage kõik vajalikud parameetrid, nagu masina nimi, paroolid, kasutajad, ntp-serverid jne, portsid saab ka kohe seadistada, kuid mulle isiklikult on pärast paigaldamist lihtsalt mugavam masinasse konsooli kaudu sisse logida ja vajalikud failid korda teha. Kui teil on juba valmis pilt, võite seda kasutada või käituda nagu mina - laadige alla minimaalne CentOS 7 pilt ja kasutage seda VM paigaldamiseks.

Pärast edukat paigaldamist peaks teil olema virtuaalne masin, kuhu saab installida undercloud.

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     jooksvalt
 62    undercloud                     jooksvalt

Esmalt paigaldame vajalikud tööriistad installatsiooni protsessi jaoks:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

Undercloudi paigaldamine

Loome kasutaja stack, määrame parooli, lisame selle sudoerisse ja anname talle õiguse täita root-käske sudo kaudu ilma parooli sissetoomiseta:

useradd stack
passwd stack

echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

Nüüd määrame hosts-failis undercloudi täisnime:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Seejärel lisame রিপოზიტोoriumid ja paigaldame vajaliku tarkvara:

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

Märkusele: kui te ei plaani ceph'i installimist, siis ceph'iga seotud käsud pole vajalikud. Kasutasin versiooni Queens, kuid võite valida mõne muu, mis teile meeldib.

Seejärel kopeerime undercloudi konfiguratsioonifaili kasutaja stack koduõigusesse:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

Nüüd on vajalik seda faili kohandada vastavalt meie installatsioonile.

Faili algusesse tuleb lisada järgmised read:

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

Nii et, vaatame seadistusi:

undercloud_hostname — undercloud serveri täielik nimi, see peab vastama DNS serveris olevale rekordile

local_ip — undercloud'i kohalik aadress proviisorvõrgu suunas

network_gateway — see sama kohalik aadress, mis toimib väravana välismaailma juurdepääsuks overcloudi node'ide paigaldamise ajal, peab samuti olema sama, mis kohalik ip

undercloud_public_host — väline API aadress, määratud olek võrgu proviisorilt vaba aadress

undercloud_admin_host sisemise API aadress, määratud olek võrgu proviisorilt vaba aadress

undercloud_nameservers — DNS server

generate_service_certificate — see rida on praeguses näites väga oluline, kuna kui seda ei seadistata väärtusele false, siis tekib teil installimise ajal viga, probleem on kirjas Red Hat'i viga jälgimisregister

local_interface proviseerimise võrgu liides. See liides konfigureeritakse ümber undercloudi paigaldamise ajal, seega peab undercloudil olema kaks liidest — üks selle juurde pääsemiseks, teine proviisorimiseks

local_mtu — MTU. Kuna meil on testlabor ja MTU on 1500 OVS lüliti portides, siis peab olema seadistatud väärtusele 1450, et VxLAN pakettidesse püütud pakettidest aru saada

network_cidr — proviseeringuvõrk

masquerade — NAT kasutamine juurdepääsuks välisseele

masquerade_network — võrk, mille parameetreid NAT-itatakse

dhcp_start — algne aadressipool, millest määratakse aadressid node'idele overcloud'i paigaldamise ajal

dhcp_end — lõppaadressipool, millest määratakse aadressid node'idele overcloud'i paigaldamise ajal

inspection_iprange — IP-aadresside vahemik, mida on vaja introspektsiooniks (ei tohi kattuda ülaltoodud vahemikuga)

scheduler_max_attempts — maksimaalne katsete arv overcloudi seadistamiseks (peab olema suurem või vähemalt võrdne nodede arvuga)

Pärast faili kirjeldamist saab anda käsu undercloudi paigaldamiseks:

openstack undercloud install

Protsess kestab 10 kuni 30 minutit, sõltuvalt teie riistvarast. Lõpuks peaksite nägema sellist väljundit:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

See väljund näitab, et olete edukalt installinud undercloudi ning nüüd saab kontrollida undercloudi olekut ja jätkata overcloudi seadistamist.

Kui vaatate väljundit ifconfig, näete, et on ilmunud uus sildliides.

[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

Selle liidese kaudu toimub nüüd üle pilve ülesehitamine.

Allpool olevast väljundist on näha, et kõik teenused on ühel sõlmel:

(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     |
+--------------------------+-----------+----------+

Allpool on näidatud undercloudi võrgu konfiguratsioon:

(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 ~]$

Overcloudi installimine

Praegu on meil ainult undercloud ja meil puuduvad nodid, millest overcloud koosneb. Seetõttu alustame virtuaalmasinate käivitamisest, mis on vajalikud. Undercloud paigaldab operatsioonisüsteemi ja vajaliku tarkvara overcloudi masinatele – meil ei ole vaja täielikult masinat käivitada, vaid lihtsalt luua sellele ketas (või kettad) ja määrata selle parameetrid – sisuliselt saame aluse serveri, millel operatsioonisüsteem ei ole paigaldatud.

Liigume virtuaalmasinate ketaste kausta ja loome vajaliku mahuga kettad:

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

Kuna tegutseme rootina, peame muutma nende ketaste omaniku, et vältida õiguste probleeme:

[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]# 

Märkus: kui te ei plaani Ceph'i õppimise eesmärgil installida, siis ärge looge vähemalt kolme node'iga, millest igaühel on vähemalt kaks ketast. Templis märkige, et kasutatakse virtuaalseid kettaid vda, vdb jne.

Suurepärane, nüüd peame kõik need masinad määrama:

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 

Lõpus on käsk —print-xml > /tmp/storage-1.xml, mis loob xml-faili iga masina kirjeldusega kaustas /tmp/, kui seda ei lisata, siis ei saa te virtuaalseid masinaid määratleda.

Nüüd peame kõik need masinad virshis määratlema:

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 ~]#

Nüüd on väikene nüanss — tripleO kasutab serverite haldamiseks paigaldamise ja introspektsiooni ajal IPMI-d.

Introspektsioon on riistvara inspektsiooni protsess, et saada vajalikud parameetrid edasiseks node-ide varustamiseks. Introspektsiooni teostab ironic — teenus, mis on mõeldud bare metal serveritega töötamiseks.

Aga siin on probleem – kui füüsilistel serveritel on IPMI jaoks eraldi port (või jagatud port, aga see ei ole oluline), siis virtuaalmasinatel selliseid porte ei ole. Siin tuleb meile appi lahendus nimega vbmc – tööriist, mis võimaldab IPMI porti emuleerida. Sellele nüansile tasub tähelepanu pöörata eriti neil, kes tahavad sellist laboratooriumi käivitada ESXi hüperviisoril – ma ei tea, kas seal on vbmc analooge, seega tasub sellele küsimusele mõelda, enne kui kõik üles seada.

Paigaldame vbmc:

yum install python2-virtualbmc

Kui teie operatsioonisüsteem ei leia paketti, lisage hoidla:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

Nüüd seadistame tööriista. Siin on kõik tõeliselt lihtne. Hetkel on loogiline, et vbmc nimekirjas ei ole mingeid servereid.

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

Kuna need ilmuksid, tuleb need käsitsi näiteks nii registreerida:

[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 ~]#

Arvan, et käsu süntaks on arusaadav ka ilma selgitusteta. Siiski on praegu kõik meie seansid seisundis DOWN. Et need muutuksid UP-iks, tuleb need sisse lülitada:

[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 ~]#

Viimane samm — tuleks kohandada tulemüürireegleid (või vajadusel täiesti välja lülitada):

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

Nüüd siseneme undercloudi ja kontrollime, kas kõik töötab. Peremeesmasina aadress on 192.168.255.200, undercloudis oleme installinud vajaliku paketi ipmitool enne juurutamise ettevalmistamist:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Korpus on
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Korpus Power Control: Üles/Käib
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Nimi                           Oleku
----------------------------------------------------
 6     dns-server                     töötab
 64    undercloud                     töötab
 65    control-1                      töötab

Nagu näete, oleme edukalt käivitanud kontrollnoodi läbi vbmc. Nüüd lülitame selle välja ja läheme edasi:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Korpus Power Control: Alla/Väljas
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Korpus on
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Nimi                           Oleku
----------------------------------------------------
 6     dns-server                     töötab
 64    undercloud                     töötab
 -     compute-1                      välja lülitatud
 -     compute-2                      välja lülitatud
 -     control-1                      välja lülitatud
 -     storage-1                      välja lülitatud
 -     storage-2                      välja lülitatud

[root@hp-gen9 ~]#

Järgmine samm on node'ide introspektsioon, kuhu overcloud paigaldatakse. Selleks peame ette valmistama json-faili, mis sisaldab kirjeldust meie node'dest. Pange tähele, et erinevalt puhaste serverite paigaldamisest sisaldab fail iga masina vbmc käivitamiseks vajalikku porti.

[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:27

Märkus: kontrollnõl on kaks liidest, kuid antud juhul ei ole see oluline, selle paigalduse jaoks piisab meile ühest.

Nüüd valmistame json faili. Peame näitama porti MAC-aadressi, mille kaudu toimub provisjoneerimine, node'ide parameetrid, andma neile nimed ja määrama, kuidas pääseda ipmi-le:

{
    "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"
        }
    ]
}

Nüüd peame valmistama ette pildid ironic jaoks. Selleks laeme need alla wget kaudu ja installime:

(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 ~]$

Laeme pildid undercloudi:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Pilt "overcloud-full-vmlinuz" on üles laaditud.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Nimi          | Ketta formaat |   Suurus  | Staatus |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | aktiivne |
+--------------------------------------+------------------------+-------------+---------+--------+
Pilt "overcloud-full-initrd" on üles laaditud.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Nimi         | Ketta formaat |   Suurus   | Staatus |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | aktiivne |
+--------------------------------------+-----------------------+-------------+----------+--------+
Pilt "overcloud-full" on üles laaditud.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Nimi      | Ketta formaat |    Suurus    | Staatus |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | aktiivne |
+--------------------------------------+----------------+-------------+------------+--------+
Pilt "bm-deploy-kernel" on üles laaditud.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Nimi       | Ketta formaat |   Suurus  | Staatus |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | aktiivne |
+--------------------------------------+------------------+-------------+---------+--------+
Pilt "bm-deploy-ramdisk" on üles laaditud.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Nimi       | Ketta formaat |    Suurus   | Staatus |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | aktiivne |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

Kontrollime, et kõik pildid on laaditud

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

Veel üks detail — tuleb lisada DNS-server:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Nimi            | Võrk                                 | Alamvõrk        |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| 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
+-------------------+-----------------------------------------------------------+
| Välja             | Väärtus                                                   |
+-------------------+-----------------------------------------------------------+
| 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       | sihtkoht='169.254.169.254/32', värav='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 on keelatakse ja see eemaldatakse tulevikus. Kasutage selle asemel openstack CLI-d.
Uuendatud alamvõrk: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

Nüüd saame anda käsu introspektsiooniks:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Alustati Mistral töövoogu tripleo.baremetal.v1.register_or_update. Täitmise ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Ootame sõnumeid järjekorras 'tripleo' ilma aegumise ajata.


5 sõlme on edukalt asetatud "hallatavale" olekule.
Sõlme UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 on edukalt registreeritud
Sõlme UUID b89a72a3-6bb7-429a-93bc-48393d225838 on edukalt registreeritud
Sõlme UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e on edukalt registreeritud
Sõlme UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 on edukalt registreeritud
Sõlme UUID 766ab623-464c-423d-a529-d9afb69d1167 on edukalt registreeritud
Ootame introspektsiooni lõpetamist...
Alustati Mistral töövoogu tripleo.baremetal.v1.introspect. Täitmise ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Ootame sõnumeid järjekorras 'tripleo' ilma aegumise ajata.
Sõlme b89a72a3-6bb7-429a-93bc-48393d225838 introspektsioon on lõpule viidud. Oleku: EDUKAS. Vead: Puuduvad
Sõlme 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e introspektsioon on lõppenud. Oleku: EDUKAS. Vead: Puuduvad
Sõlme bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 introspektsioon on lõppenud. Oleku: EDUKAS. Vead: Puuduvad
Sõlme 766ab623-464c-423d-a529-d9afb69d1167 introspektsioon on lõppenud. Oleku: EDUKAS. Vead: Puuduvad
Sõlme b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 introspektsioon on lõppenud. Oleku: EDUKAS. Vead: Puuduvad
5 sõlme on edukalt introspektsioonitud.
Alustati Mistral töövoogu tripleo.baremetal.v1.provide. Täitmise ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Ootame sõnumeid järjekorras 'tripleo' ilma aegumise ajata.
5 sõlme on edukalt asetatud "saadaval" olekule.
(undercloud) [stack@undercloud ~]$

Kuidas näha, on kõik läinud ilma vigadeta. Kontrollime, et kõik sõlmed oleksid seisundis saadaval:

(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 ~]$ 

Kui node'id on mõnes muus, enamasti hallatav, olekus, siis on midagi valesti ning tuleb vaadata logi, et selgitada välja, miks see nii on. Pidage meeles, et selles stsenaariumis kasutame virtualiseerimist ja võivad olla vead, mis on seotud virtuaalmasinate või vbmc kasutamisega.

Seejärel peame näitama, milline node millist funktsiooni täidab — see tähendab profiili määramist, millega node paigaldatakse:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | saadaval        | Puudub          |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | saadaval        | Puudub          |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | saadaval        | Puudub          |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | saadaval        | Puudub          |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | saadaval        | Puudub          |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(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 | Tõsi      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | Tõsi      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | Tõsi      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | Tõsi      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | Tõsi      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | Tõsi      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

Määrame iga sõlme profiili:

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-d9afb69d1167

Kontrollime, et kõik on õigesti tehtud:

(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 ~]$

Kui kõik on korrektne, anname käsu overcloudi deployimiseks:

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

Tõelises installatsioonis kasutatakse loomulikult kohandatud malli, kuid meie puhul muudab see protsessi oluliselt keerulisemaks, kuna tuleb selgitada iga muudatust šablonis. Nagu eelnevalt mainitud, piisab isegi lihtsast installatsioonist, et näha, kuidas see töötab.

Märkus: muutuja --libvirt-type qemu on antud juhul vajalik, kuna kasutame pesakonnasisest virtualiseerimist. Vastasel juhul ei käivitu teie virtuaalsed masinad.

Nüüd on teil umbes tund või isegi rohkem (sõltub riistvara võimetest) ja teil jääb vaid loota, et selle aja möödudes näete sellist teadet:

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 ~]$

Nüüd on teil peaaegu täielik OpenStack'i versioon, millega saate õppida, katsetada jne.

Kontrollime, et kõik toimib korralikult. Kasutaja stack kodukaustas on kaks faili – üks on stackrc (undercloud'i haldamiseks) ja teine overcloudrc (overcloud'i haldamiseks). Need failid tuleb määrata source'ina, kuna need sisaldavad vajalikku autentimiseks vajalikku teavet.

(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 ~]$

Minu paigalduses on veel üks väike detail, milleks on marsruudi lisamine kontrolleris, kuna masin, millega töötan, asub teises võrgus. Selleks logime sisse control-1 kasutajanimega heat-admin ja lisame marsruudi.

(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15         
Viimane sisselogimine: Reede Aug 14 09:47:40 2020, masinat 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.254

Nüüd saate minna horisontaali. Kõik vajalikud andmed — aadressid, sisselogimine ja parool — asuvad failis /home/stack/overcloudrc. Lõplik skeem näeb välja järgmiselt:

Muide, meie paigalduses anti masinatele aadresse DHCP kaudu ja nagu näete, antakse neid „kuidas juhtub“. Kui soovite, saate šabloonis kindlalt määrata, milline aadress millisele masinale tuleks juurutamise ajal kinnitada.

Kuidas liigub liiklus virtuaalsete masinate vahel?

Selles artiklis vaatame kolme varianti liikluse edastamiseks

• Kaks masinat ühel hüperviisoril ühes L2 võrgus
• Kaks masinat erinevates hüperviisorites ühes L2 võrgus
• Kaks masinat erinevates võrkudes (marsruutimine võrkude vahel)

Järgmises osas vaatame juhtumeid, kus ühendus välismaailmaga toimub external võrgu kaudu, kasutades ujuvaid aadresse ja paremat marsruutimist. Praegu keskendume sisetrafikule.

Kontrollimiseks kogume sellise skeemi:

Meil on loodud 4 virtuaalset masinat — 3 ühises L2 võrgus — net-1, ja veel 1 võrgus 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 ~]$ 

Vaatame, millistel hüpervisoritel loodud masinad asuvad:

(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 ~]$
Masinad vm-1 ja vm-3 asuvad compute-0-l, masinad vm-2 ja vm-4 asuvad nodis compute-1.

Lisaks on loodud virtuaalne ruuter, et võimaldada marsruutimist toodud võrkude vahel:

(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 ~]$ 

Ruuteril on kaks virtuaalset porti, mis toimivad väravatena võrkudele:

(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 ~]$ 

Kuid enne, kui vaatame, kuidas liiklus toimub, vaatame, mida me hetkel kontrollnodos (mis on samas ka võrgunode) ja arvutusnodes omame. Alustame arvutusnodest.

[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 ~]$

Praegu node'il on kolm OVS silda — br-int, br-tun ja br-ex. Nende vahel, nagu me näeme, on erinevad liidesed. Lihtsuse huvides joonistame kõik need liidesed skeemile ja vaatame, mis välja tuleb.

VxLAN tunnelite aadresside põhjal näeme, et üks tunnel on seadistatud compute-1 (192.168.255.26) ja teine tunnel vaatab control-1 (192.168.255.15). Kuid kõige huvitavam on see, et br-ex-l ei ole füüsilisi liideseid, ja kui vaadata, millised voogud on seadistatud, siis on selge, et see sild suudab hetkel vaid liiklust blokeerida.

[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 ~]$ 

Kohas, nähtub, et aadress on otse füüsilisele portile kinnitatud, mitte virtuaalse sildliidesele.

[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 ~]$ 

Esimese reegli kohaselt tuleb kõik, mis tuli porti phy-br-ex, kõrvaldada.
Selles sillas ei saa praegu muud liiklust tekkida kui antud liidese kaudu (ühendus br-int'iga), ja arvestades sillale tulevat BUM liiklust, tundub, et see on juba olnud.

See, from this node, the traffic can only exit via a VxLAN tunnel and no other way. However, if DVR is enabled, the situation will change, but we will deal with that another time. When using network isolation, for example with VLANs, you will have more than one L3 interface in the 0 VLAN, but VxLAN traffic will still exit from the node in the same way, encapsulated within a dedicated VLAN.

Now that we've dealt with the compute node, let's move on to the control node.

[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 ~]$

In fact, it can be said that everything is the same, however, the IP address is no longer on the physical interface but on a virtual bridge. This is because this port is the one through which the traffic will exit to the outside world.

[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 ~]$ 

See port is connected to bridge br-ex and since there are no VLAN tags on it, this port is a trunk port where all VLANs are allowed; currently, traffic is leaving without a tag, indicated by the vlan-id 0 in the output above.

Everything else at this moment is similar to the compute node — the same bridges, the same tunnels going to the two compute nodes.

Säilitusnode me ei käsitle selles artiklis, kuid arusaamiseks on vajalik öelda, et nende node'ide võrguosa on ülimalt lihtne. Meie puhul on seal ainult üks füüsiline port (eth0) koos sellele määratud IP-aadressiga ja kõik. Seal ei ole mingeid VxLAN tunnelite, tunnelibridge'e jms — seal pole üldse ovs, kuna see pole mõttekas. Võrkude eraldamise kasutamisel on sellel node'il kaks liidest (füüsilised portid, bodny või lihtsalt kaks VLAN-i — see pole oluline — sõltub sellest, mida soovite) — üks halduseks, teine liikluseks (VM-i kettale kirjutamine, ketaselt lugemine jne).

Selgitasime, mida meil on node'ides, ilma igasuguste teenusteta. Nüüd käivitame 4 virtuaalset masinat ja vaatame, kuidas ülaltoodud skeem muutub — meil peavad ilmuma pordid, virtuaalsed ruuterid jne.

Praegu näeb meie võrgu struktuur välja järgmine:

Meil on igas computernode'is kaks virtuaalset masinat. Vaata näite põhjal compute-0, kuidas kõik on ühendatud.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

Masinal on ainult üks virtuaalne liides — tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Liides  Tüüp       Allikas     Modell       MAC
-------------------------------------------------------
tap95d96a75-a0 sild       qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

See liides vaatab Linux silda:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
silla nimi     silla id               STP lubatud     liidesed
docker0         8000.0242904c92a8       ei
qbr5bd37136-47          8000.5e4e05841423       ei              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       ei              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

Nagu on välja toodud sillast, on seal kokku kaks liidest — tap95d96a75-a0 ja qvb95d96a75-a0.

Siin tasub peatuda OpenStackis kasutatavate virtuaalsete võrgu seadmete tüüpide juures:
vtap — virtuaalne liides, mis on seotud instantsiga (VM)
qbr — Linux sild
qvb ja qvo — vEth paar, mis on ühendatud Linux silla ja Open vSwitch silla juurde
br-int, br-tun, br-vlan — Open vSwitch sillad
patch-, int-br-, phy-br- — Open vSwitchi patch-liidesed, mis ühendavad sildu
qg, qr, ha, fg, sg — Open vSwitchi pordid, mida virtuaalsed seadmed kasutavad OVS-iga ühendamiseks

Kuidas te mõistate, kui meie brügges on qvb95d96a75-a0 port, mis on vEth paar, siis kusagil peab olema selle vastaspool, mida loogiliselt tuleks nimetada qvo95d96a75-a0. Vaadake, millised pordid on OVS-il.

[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 ~]$ 

Kuidas me näeme, et port asub br-int. Br-int täidab funktsiooni, toimides virtuaalmasinate portide terminaatorina. Lisaks qvo95d96a75-a0 on väljundis nähtaval port qvo5bd37136-47. Lõpuks näeb meie skeem nüüd välja järgmine:

Küsimus, mis peaks kohe köitma tähelepanelikku lugejat — miks on vajalik Linuxi sild virtuaalmasina ja OVS-i porta vahel? Asi on selles, et masina kaitsmiseks kasutatakse turvagrupe, mis ei ole midagi muud kui iptables. OVS ei toimi iptablesiga, seega on selline "konditsioneer" leiutatud. Kuid see on oma aja ära elanud — uutes versioonides asendab seda conntrack.

Seega näeb skeem kokkuvõttes välja nii:

Kaks masinat ühel hüperviisoril ühes L2 võrgus

Kuna need kaks VM-i asuvad samas L2 võrgus ja samas hüperviisoril, siis liiklus nende vahel liigub loogiliselt kohalikult läbi br-int, kuna mõlemad masinad on samas VLAN-is:

[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 ~]$ 

Kaks masinat erinevates hüperviisorites ühes L2 võrgus

Vaadake nüüd, kuidas läheb liiklus kahe masina vahel ühes L2 võrgus, kuid erinevatel hüpervideerijatel. Kui olla aus, siis ei muutu eriti midagi, lihtsalt liiklus hüpervideerijate vahel läheb vxlan tunnelite kaudu. Vaadake näidet.

Virtuaalsete masinate aadressid, mille vahel liiklust vaatame:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Liides  Tüüp       Allikas     Modell       MAC
-------------------------------------------------------
tap95d96a75-a0 sild       qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

Vaadake edastustabelit br-int-s compute-0-s:

[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 ~]

Liiklus peaks minema pessa 2 — vaatame, mis see pesa on:

[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 ~]$

See on patch-tun — ehk siis liides br-tun-is. Vaadake, mis toimub paketiga br-tun-is:

[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 ~]$ 

Pakett pakitakse VxLAN-i ja saadetakse porti 2. Vaatame, kuhu port 2 viib:

[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 ~]$

See on vxlan tunnel compute-1-l.

[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 ~]$

Liigume compute-1 ja vaatame, mis juhtuda võib paketiga:

[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 ~]$ 

Maks on olemas br-int-i edastus tabelis compute-1, ja nagu näha ülaltoodud väljundist, on ta nähtav läbi port 2, mis on br-tun-i suunas:

[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

Ja jätkame ja vaatame, et br-int-i peal compute-1-s on sihtkoht:

[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 ~]$ 

See tähendab, et saadetud pakett läheb porti 3, mille taga on juba virtuaalne masin instance-00000003.

OpenStacki juurutamise suurim eelis virtuaalses infrastuktuuris on see, et saame probleemideta jälgida hüperviisorite vahel liikuvat liiklust ja vaadata, mis temaga juhtub. Täpselt seda me praegu teeme, käivitame tcpdump vnet porti peal suunaga compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: kuulamine vnet3, link-tüüp EN10MB (Ethernet), haaramissuurus 262144 bait

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

Esimene rida näitab, et pakett, mille aadress on 10.0.1.85, suundub aadressile 10.0.1.88 (ICMP liiklus), olles samas pakitud VxLAN paketti, mille vni on 22, ja pakett tuleb hostilt 192.168.255.19 (compute-0) hostile 192.168.255.26 (compute-1). Saame kontrollida, et VNI vastab sellele, mis on näidatud ovs-is.

Naaseme selle rea juurde actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 on vni 16-süsteemis. Muudame selle numbri kümnendsüsteemi:

16 = 6*16^0+1*16^1 = 6+16 = 22

See tähendab, et vni vastab tõele.

Teine rida näitab vastupidist liiklust, aga selle selgitamisel pole mõtet, seal on nii selge.

Kaks masinat erinevates võrkudes (marsruutimine võrkude vahel)

Viimane juhtum täna — see on marsruutimine võrkude vahel ühe projekti raames virtuaalse marsruuteri kasutamine. Vaadeldav juhtum on ilma DVR-ita (keda käsitleme teises artiklis), seega toimub marsruutimine network node'is. Meie juhul ei ole network node eraldi entiteedina välja toodud ja asub control node'is.

Esmalt vaatame, et marsruutimine töötab:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 andmeid
64 baiti aadressilt 10.0.2.8: seq=0 ttl=63 aeg=7.727 ms
64 baiti aadressilt 10.0.2.8: seq=1 ttl=63 aeg=3.832 ms
^C
--- 10.0.2.8 ping statistika ---
2 paketti saadetud, 2 paketti vastu võetud, 0% paketi kadu
ring-reis min/avg/max = 3.832/5.779/7.727 ms

Kuna antud juhul peab paket minema väravasse ja seal marsruuditama, peame välja selgitama värava MAC-aadressi, selleks vaatame ARP tabelit instantsis:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  eth0-l
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  eth0-l
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  eth0-l
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  eth0-l

Nüüd vaatame, kuhu peaks liiklus suunatakse (10.0.1.254) fa:16:3e:c4:64:70:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

Vaatame, kuhu viib port 2:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

Kõik on loogiline, liiklus suundub br-tun'i. Vaatame, millises vxlan tunnelis see ümber suunatakse:

[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 ~]$ 

Kolmas port on vxlan tunnel:

[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 ~]$ 

Mis vaatab control node'i:

[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 ~]$ 

Trafik jõudis control node'i, seega peame sellele üle minema ja vaatama, kuidas marsruutimine toimub.

Kuidas te mäletate, nägi control node välja täpselt sama nagu compute node — kolm sama silda, kuid br-ex'il oli füüsiline port, mille kaudu node sai suunata liiklust välja. Instantside loomine muutis compute node'ide konfiguratsiooni — lisandusid linux bridge, iptables ja liidesed node'idesse. Võrkude ja virtuaalse marsruuteri loomine jättis samuti jälje control node'i konfiguratsioonile.

Nii et on ilmne, et gateway MAC-aadress peaks olema br-int'i edasiandmis tabelis control node'is. Kontrollime, kas see seal on ja kuhu see vaatab:

[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 on nähtav qr-0c52b15f-8f pordist. Kui naasta tagasi Openstackis virtuaalportide loendisse, siis kasutatakse seda tüüpi porti OVS-i erinevate virtuaalsete seadmete ühendamiseks. Täpsemalt, qr on port virtuaalsesse marsruuterisse, mis esindab enda namespace'i.

Vaadakem, millised namespace'id serveris on:

[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 ~]$ 

Kokku on kolm instantsi. Kuid nimedest võib järeldada igaühe määratlust. Instantsidega, mille ID on 0 ja 1, pöördume tagasi hiljem, praegu huvitab meid namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

Selles namespace'is on kaks sisemist, mis loodi varem. Mõlemad virtuaalsed portid on lisatud br-int. Kontrollime porta адреса qr-0c52b15f-8f, kuna liiklus, nagu näha sihtaadressi MAC-aadressist, suundus just sellele liidesele.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

Seega käitub kõik antud juhul tavalise marsruutimise seadustega. Kuna liiklus on suunatud hostile 10.0.2.8, peab see väljuma läbi teise liidese qr-92fa49b5-54 ja liikuma läbi vxlan tunnel'i compute sõlme:

[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 ~]$ 

Kõik on loogiline, üllatusi ei ole. Vaatame, kust on nähtav hosti MAC-aadress 10.0.2.8 br-int-s:

[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 ~]$ 

Nagu ette nähtud, liiklus läheb br-tun-i, vaatame, millises tunnelis liiklus edasi läheb:

[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 ~]$ 

Liiklus suundub tunnelisse kuni compute-1. Ja compute-1-s on kõik lihtne — br-tunist jõuab pakk br-int-i ja sealt edasi virtuaalmasina liidesesse:

[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 ~]$ 

Kontrollime, kas see on tõepoolest õige liides:

[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 ~]$

Nii, me oleme läbinud kogu paketi teekonna. Arvan, et olete juba märganud, et liiklus liikus erinevate vxlan tunnelite kaudu ja väljumine toimus erinevate VNI-dega. Vaadakem, millised need VNI-d on, seejärel kogume dumi kontrollsõlme pordilt ja veendume, et liiklus liigub just nii, nagu ülal kirjeldatud.
Seega, tunnel compute-0-ks on järgmised actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Tõlgime 0x16 kümnendsüsteemi:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

Tunnel compute-1-ks on järgmine VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Tõlgime 0x63 kümnendsüsteemi:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

Nüüd vaatame dumi:

[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*******************

Esimene pakk on vxlan pakk, mis saadetakse hostilt 192.168.255.19 (compute-0) hostile 192.168.255.15 (control-1) vni 22, mille sees on ICMP pakk hostilt 10.0.1.85 hostile 10.0.2.8. Nagu me eelnevalt arvestasime, vastab vni sellele, mida me väljundites nägime.

Teine pakett on vxlan pakett hostilt 192.168.255.15 (control-1) hostile 192.168.255.26 (compute-1) vni 99, mille sees on ICMP pakett hostilt 10.0.1.85 hostile 10.0.2.8. Nagu me eelnevalt arvestasime, vastab vni sellele, mida nägime väljundites.

Kaks järgmist paketti on tagasivool 10.0.2.8-sse mitte 10.0.1.85-sse.

Seega on meil lõpuks tekkinud selline skeem control noodist:

Paistab, et kõik on korras? Unustasime kaks namespace'i:

[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 ~]$ 

Nagu me rääkisime pilveplatvormi arhitektuurist — oleks hea, kui masinad saaksid automaatselt aadresse DHCP serverilt. Need on kaks DHCP serverit meie kahel võrgul 10.0.1.0/24 ja 10.0.2.0/24.

Kontrollime, kas see on tõsi. Antud namespace'is on ainult üks aadress — 10.0.1.1 — DHCP serveri enda aadress, ja see on samuti br-int-sse kaasatud:

[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 0

Vaatame, kas protsessid, mille nimedes on qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 control moodulis:

[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 ~]$ 

Sellest protsessist lähtuvalt ja ülaltoodud väljundi põhjal saame näiteks vaadata, mis meil praegu üüritakse:

[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 ~]$

Kokkuvõtteks saame sellise teenuste komplekti kontrollimoodulis:

Pea meeles, et see on vaid 4 masinat, 2 sisevõrku ja üks virtuaalne ruuter… Meil ei ole praegu väliseid võrke, erinevaid projekte, igaühel oma (ristuva) võrguga, ja meil on väljalülitatud hajutatud ruuter, jah, lõpuks oli testkeskkonnas vaid üks juhtnodo (klienditeenindus peab koosnema kolmest nodost, et tagada töökindlus). On loogiline, et kaubanduses on kõik “veidi” keerulisem, kuid selle lihtsa näite kaudu mõistame, kuidas see peaks toimima — olgu teil 3 või 300 nimiruumi, on selle süsteemi töö seisukohalt erilisi muutusi… tõsi, kuni te ei kasuta mingit müügipartneri SDN-i. Kuid see on juba hoopis teine lugu.

Loodan, et oli huvitav. Kui teil on märkusi / täiendusi või kui ma kuskil avatud maneeriga eksisin (ma olen inimene ja minu arvamus on alati subjektiivne) — kirjutage, mida peaks parandama / lisama — kõik parandame / lisame.

Kokkuvõttes tahaksin öelda paar sõna OpenStacki (nii puhta kui ka edasimüüja versioonide) ja VMWare'ilt pärit pilvelahenduse võrdlemisest — viimase paar aasta jooksul on mitmed inimesed seda küsimust minult küsinud ja ausalt öeldes olen sellest juba väsinud, aga siiski. Minu arvates on nende kahe lahenduse võrdlemine väga keeruline, kuid ühes on kindel — mõlemas lahenduses on omad miinused ning valides ühe või teise tuleb hoolikalt kaaluda kõiki plusse ja miinuseid.

Kui OpenStack on kogukonna juhitud lahendus, siis VMWare'il on õigus teha ainult seda, mida nad soovivad (loe — mida neile kasulik) ja see on loogiline — nad on kommertsfirma, mis on harjunud teenima oma klientidelt raha. Kuid siin on üks suur ja rasvane "KUID" — te saate näiteks Nokia OpenStackist lahti, liikuda vähese vaevaga Juniperi (Contrail Cloud) lahendusele, kuid VMWare'lt lahti saada on teil tõenäoliselt keeruline. Minu silmis näevad need kaks lahendust välja nii — OpenStack (edasimüüja versioon) on lihtne puuri, kuhu teid suletakse, kuid teil on võti ja te saate igal ajal välja minna. VMWare on aga kuldne puuri, mille võti kuulub peremeestele ja see maksab teile väga kalliks.

Ma ei toeta ei esimest toodet ega teist — valite ise, mis teile sobib. Kuid kui ma peaksin sellist valikut tegema, valiksin ma mõlemad lahendused — VMWare IT pilve jaoks (madalad koormused, mugav haldamine) ja OpenStack mõnelt tarnijalt (Nokia ja Juniper pakuvad väga head võtmed-kätte lahendust) Telekomi pilve jaoks. Ma ei kasutaks OpenStacki puhtas IT-s — see on nagu püssist sõnade tulistamine, kuid vastunäidustusi selle kasutamiseks, välja arvatud liig, ma ei näe. Kuid VMWare kasutamine telekomis — nagu peenel Ford Raptoril kruusa vedamine, ilus vaadata, aga juhil tuleb teha 10 reisi ühe asemel.

Minu arvates on VMWare kõige suurem puudus selle täielik suletus — ettevõte ei jagada teile mingit teavet selle kohta, kuidas näiteks vSAN või hüperviisori süda töötab — see pole neile lihtsalt kasulik — see tähendab, et te ei saa kunagi VMWare ekspertiks — ilma tootja toeta olete hukule määratud (väga sageli kohtan eksperte VMWare, keda hämmastavad juba kõige lihtsamad küsimused). Minu jaoks on VMWare nagu auto ostmine kinnise kapotiga — jah, võib-olla on teil spetsialiste, kes saavad vahetada hammasrihma, kuid kapoti avada suudab ainult see, kes teile selle lahenduse müüs. Isiklikult ei meeldi mulle lahendused, kuhu ma ei saa sisse vaadata. Te ütlete, et võib-olla ei pea te kapoti alla ronima. Jah, see on võimalik, kuid ma vaatan teid, kui peate pilootima suure funktsiooni 20-30 virtuaalmasinaga pilves, 40-50 võrguga, millest pooled tahavad välja pääseda ja teine pool palub SR-IOV kiirendust, vastasel juhul peate hankima veel paar tosinat sellist masinat — vastasel juhul ei piisa jõudlusest.

On neid ka teisi arvamusi, seega on see ainult teie otsus, mida valida, ja kõige tähtsam — te vastutate oma valikute eest. See on lihtsalt minu arvamus — inimese oma, kes on kogenud ja käega katsunud vähemalt nelja toodet — Nokia, Juniper, Red Hat ja VMWare. Seega on mul millegiga võrrelda.

Allikas: habr.com