Pilvandmetöötlus tungib meie ellu üha sügavamale ja ilmselt pole ühtegi inimest, kes poleks vähemalt korra pilveteenust kasutanud. Mis aga täpselt on pilv ja kuidas see toimib, seda teavad vähesed isegi idee tasandil. 5G on juba saamas reaalsuseks ja telekomi infrastruktuur hakkab liikuma sammaslahendustelt pilvelahendustele, täpselt nagu liikus täielikult riistvaralahendustelt virtualiseeritud "sammastele".
Täna räägime pilveinfrastruktuuri sisemaailmast, eelkõige vaatame võrguosa põhitõdesid.
Mis on pilv? Sama virtualiseerimine – profiilivaade?
Rohkem kui loogiline küsimus. Ei – see pole virtualiseerimine, kuigi ilma selleta seda teha ei saaks. Vaatame kahte definitsiooni:
Pilvandmetöötlus (edaspidi pilv) on mudel kasutajasõbraliku juurdepääsu pakkumiseks hajutatud andmetöötlusressurssidele, mis tuleb kasutusele võtta ja käivitada nõudmisel võimalikult madala latentsusajaga ja minimaalsete kuludega teenusepakkujale.
Virtualiseerimine - see on võimalus jagada üks füüsiline olem (näiteks server) mitmeks virtuaalseks, suurendades seeläbi ressursside kasutamist (näiteks 3 serverit oli laaditud 25-30 protsenti, pärast virtualiseerimist laaditakse 1 server 80-90 protsenti). Loomulikult sööb virtualiseerimine osa ressurssidest - peate hüperviisorit toitma, kuid nagu praktika on näidanud, on mäng küünalt väärt. Ideaalne näide virtualiseerimisest on VMWare, mis valmistab suurepäraselt virtuaalmasinaid või näiteks KVM, mida ma eelistan, aga see on maitse asi.
Me kasutame virtualiseerimist, ilma et oleks arugi saanud, ja isegi rauast ruuterid kasutavad juba virtualiseerimist – näiteks JunOS-i uusimas versioonis on operatsioonisüsteem installitud virtuaalmasinana reaalajas Linuxi distributsiooni (Wind River 9) peale. Kuid virtualiseerimine pole pilv, vaid pilv ei saa eksisteerida ilma virtualiseerimiseta.
Virtualiseerimine on üks ehitusplokke, millele pilv on üles ehitatud.
Pilve loomine, kogudes lihtsalt mitu hüperviisorit ühte L2 domeeni, lisades paar yamli esitusraamatut vlanide automaatseks registreerimiseks mingisuguse võimaliku kaudu ja segades sellele kõigele midagi nagu orkestreerimissüsteem virtuaalsete masinate automaatseks loomiseks, ei toimi. See on täpsem, kuid tulemuseks olev Frankenstein ei ole pilv, mida vajame, kuigi see võib olla teiste jaoks ülim unistus. Veelgi enam, kui võtta seesama Openstack, on see sisuliselt ikkagi Frankenstein, aga noh, ärme sellest praegu räägi.
Kuid ma saan aru, et ülaltoodud definitsioonist ei ole päris selge, mida võib tegelikult pilveks nimetada.
Seetõttu pakub NIST (National Institute of Standards and Technology) dokument 5 peamist omadust, mis pilveinfrastruktuuril peaksid olema:
Teenuse pakkumine nõudmisel. Kasutajale tuleb anda tasuta juurdepääs talle eraldatud arvutiressurssidele (nagu võrgud, virtuaalsed kettad, mälu, protsessori tuumad jne) ning need ressursid peavad olema tagatud automaatselt – st ilma teenusepakkuja sekkumiseta.
Teenuse laialdane kättesaadavus. Juurdepääs ressurssidele peab olema tagatud standardsete mehhanismidega, et võimaldada kasutada nii tavalisi personaalarvuteid kui ka õhukesi kliente ja mobiilseadmeid.
Ressursside ühendamine basseinideks. Ressursikogumid peavad suutma pakkuda ressursse korraga mitmele kliendile, tagades, et kliendid on isoleeritud ning vabad vastastikusest mõjust ja konkurentsist ressursside pärast. Kogumitesse on kaasatud ka võrgud, mis viitab võimalusele kasutada kattuvat adresseerimist. Basseine peab saama vastavalt vajadusele laiendada. Puulide kasutamine võimaldab tagada vajalikul tasemel ressursside tõrketaluvuse ning füüsiliste ja virtuaalsete ressursside eraldamise – teenuse saajale antakse lihtsalt tema soovitud ressursside komplekt (kus need ressursid füüsiliselt asuvad, kui palju serverid ja lülitid – see pole kliendi jaoks oluline). Siiski peame arvestama asjaoluga, et pakkuja peab tagama nende ressursside läbipaistva broneerimise.
Kiire kohanemine erinevate tingimustega. Teenused peavad olema paindlikud - ressursside kiire tagamine, nende ümberjagamine, ressursside lisamine või vähendamine kliendi soovil ning kliendi poolt peaks tekkima tunne, et pilveressursse on lõputult. Mõistmise hõlbustamiseks ei kuvata näiteks hoiatust, et osa teie Apple iCloudi kettaruumist on kadunud, kuna serveri kõvaketas on katki ja draivid lähevad katki. Lisaks on teie poolt selle teenuse võimalused peaaegu piiramatud - vajate 2 TB - pole probleemi, maksite ja saite. Sarnase näite võib tuua Google.Drive või Yandex.Disk.
Võimalus mõõta pakutavat teenust. Pilvesüsteemid peavad tarbitud ressursse automaatselt kontrollima ja optimeerima ning need mehhanismid peavad olema läbipaistvad nii kasutajale kui ka teenusepakkujale. See tähendab, et saate alati kontrollida, kui palju ressursse teie ja teie kliendid tarbivad.
Tasub arvestada tõsiasjaga, et need nõuded on enamasti avaliku pilve nõuded, seega privaatpilve (ehk siis ettevõtte sisemisteks vajadusteks käivitatud pilve) puhul saab neid nõudeid veidi korrigeerida. Neid tuleb aga veel teha, muidu ei saa me kõiki pilvandmetöötluse eeliseid kätte.
Miks me vajame pilve?
Iga uus või olemasolev tehnoloogia, iga uus protokoll luuakse aga millegi jaoks (noh, muidugi, välja arvatud RIP-ng). Protokolli pärast pole kellelgi vaja protokolli (no muidugi, välja arvatud RIP-ng). On loogiline, et Pilv on loodud kasutajale/kliendile mingisuguse teenuse pakkumiseks. Oleme kõik tuttavad vähemalt paari pilveteenusega, näiteks Dropbox või Google.Docs, ja usun, et enamik inimesi kasutab neid edukalt – näiteks see artikkel on kirjutatud Google.Docs pilveteenust kasutades. Kuid meile tuntud pilveteenused on vaid osa pilve võimalustest – täpsemalt öeldes on need vaid SaaS-tüüpi teenused. Pilveteenust saame pakkuda kolmel viisil: SaaS-i, PaaS-i või IaaS-i kujul. Millist teenust vajate, sõltub teie soovidest ja võimalustest.
Vaatame kõiki järjekorras:
Tarkvara kui teenus (SaaS) on mudel kliendile täisväärtusliku teenuse pakkumiseks, näiteks e-posti teenus nagu Yandex.Mail või Gmail. Selles teenuse osutamise mudelis ei tee te kliendina tegelikult midagi peale teenuste kasutamise – see tähendab, et te ei pea mõtlema teenuse seadistamisele, selle veataluvusele või liiasusele. Peaasi, et oma parooli ei ohustaks, ülejäänu teeb selle teenuse pakkuja teie eest. Teenusepakkuja seisukohalt vastutab ta täielikult kogu teenuse eest – alates serveri riistvarast ja hosti operatsioonisüsteemidest kuni andmebaasi ja tarkvara seadistusteni.
Platvorm teenusena (PaaS) - selle mudeli kasutamisel annab teenusepakkuja kliendile teenuse jaoks tooriku, näiteks võtame veebiserveri. Teenusepakkuja andis kliendile virtuaalserveri (tegelikult ressursside komplekti, nagu RAM/CPU/Storage/Nets jne) ning isegi installis sellesse serverisse operatsioonisüsteemi ja vajaliku tarkvara, kuid kõik need asjad on kliendi enda tehtud ja teenuse täitmiseks klient vastab. Teenusepakkuja, nagu ka eelmisel juhul, vastutab füüsiliste seadmete, hüperviisorite, virtuaalmasina enda, selle võrgu kättesaadavuse jms eest, kuid teenus ise ei kuulu enam tema vastutusalasse.
Infrastruktuur kui teenus (IaaS) - see lähenemine on juba huvitavam, tegelikult pakub teenusepakkuja kliendile täielikku virtualiseeritud infrastruktuuri - see tähendab teatud ressursside komplekti (kogumit), nagu protsessori tuumad, RAM, võrgud jne. Kõik muu on enda teha klient - mida klient soovib nende ressurssidega eraldatud kogumi (kvoodi) piires teha - see ei ole tarnija jaoks eriti oluline. Ükskõik, kas klient soovib luua oma vEPC või isegi luua minioperaatori ja pakkuda sideteenuseid – pole kahtlust – tehke seda. Sellise stsenaariumi korral vastutab teenusepakkuja ressursside varustamise, nende tõrketaluvuse ja saadavuse ning operatsioonisüsteemi eest, mis võimaldab neil need ressursid koondada ja kliendile kättesaadavaks teha koos võimalusega ressursse igal ajal suurendada või vähendada. kliendi soovil. Klient konfigureerib kõik virtuaalsed masinad ja muu kiiksuga ise läbi iseteenindusportaali ja konsooli, sh seadistab võrke (v.a välisvõrgud).
Mis on OpenStack?
Kõigi kolme variandi puhul vajab teenusepakkuja OS-i, mis võimaldab luua pilveinfrastruktuuri. Tegelikult vastutab SaaS-i puhul rohkem kui üks osakond kogu tehnoloogiate virna eest – on üks osakond, mis vastutab infrastruktuuri eest – see tähendab, et see pakub IaaS-i teisele divisjonile, see osakond pakub kliendile SaaS-i. OpenStack on üks pilveoperatsioonisüsteemidest, mis võimaldab teil koguda hunniku lüliteid, servereid ja salvestussüsteeme ühte ressursikogumisse, jagada see ühine kogum alamkogumiteks (üürnikeks) ja pakkuda neid ressursse klientidele üle võrgu.
OpenStack on pilveoperatsioonisüsteem, mis võimaldab juhtida suuri arvutusressursside, andmesalvestus- ja võrguressursside kogumeid, mis on ette nähtud ja hallatud API kaudu standardsete autentimismehhanismide abil.
Teisisõnu, see on tasuta tarkvaraprojektide komplekt, mis on loodud pilveteenuste (nii avalike kui ka privaatsete) loomiseks - see tähendab tööriistade komplekt, mis võimaldab ühendada serveri ja lülitusseadmed üheks ressursside kogumiks, hallata. need ressursid, pakkudes vajalikul tasemel tõrketaluvust.
Selle materjali kirjutamise ajal nägi OpenStacki struktuur välja järgmine:
Pilt tehtud
Kõik OpenStackis sisalduvad komponendid täidavad teatud funktsiooni. See hajutatud arhitektuur võimaldab teil kaasata lahendusse vajalike funktsionaalsete komponentide komplekti. Mõned komponendid on aga juurkomponendid ja nende eemaldamine toob kaasa lahenduse kui terviku täieliku või osalise töövõimetuse. Need komponendid liigitatakse tavaliselt järgmiselt:
- armatuurlaud — Veebipõhine GUI OpenStacki teenuste haldamiseks
- Keystone on tsentraliseeritud identiteediteenus, mis pakub autentimis- ja autoriseerimisfunktsioone teistele teenustele ning haldab kasutajate mandaate ja nende rolle.
- Neutron - võrguteenus, mis pakub ühenduvust erinevate OpenStacki teenuste liideste vahel (sealhulgas ühenduvus VM-ide vahel ja nende juurdepääs välismaailmale)
- Tuhka - pakub juurdepääsu virtuaalmasinate blokeerimissalvestusele
- Uus — virtuaalmasinate elutsükli haldamine
- Pilk — virtuaalmasina piltide ja hetktõmmiste hoidla
- Kiire — tagab juurdepääsu salvestusobjektile
- Ceilomeeter — teenus, mis võimaldab koguda telemeetriat ning mõõta saadaolevaid ja tarbitud ressursse
- Soojus — ressursside automaatse loomise ja varustamise mallidel põhinev orkestreerimine
Kõigi projektide ja nende eesmärkide täielikku loendit saab vaadata .
Iga OpenStacki komponent on teenus, mis täidab kindlat funktsiooni ja pakub API-d, et hallata seda funktsiooni ja suhelda teiste pilveoperatsioonisüsteemi teenustega, et luua ühtne infrastruktuur. Näiteks Nova pakub arvutusressursside haldust ja API-d nende ressursside konfigureerimiseks, Glance pakub pildihaldust ja API-d nende haldamiseks, Cinder pakub plokkide salvestusruumi ja API-d selle haldamiseks jne. Kõik funktsioonid on omavahel väga tihedalt seotud.
Kui aga vaadata, siis kõik OpenStackis töötavad teenused on lõppkokkuvõttes mingisugune virtuaalne masin (või konteiner), mis on ühendatud võrku. Tekib küsimus – milleks meil nii palju elemente vaja on?
Vaatame läbi algoritmi virtuaalmasina loomiseks ja võrguga ühendamiseks ning Openstackis püsiva salvestusruumiga.
- Kui loote päringu masina loomiseks, olgu see siis taotlus Horizoni (Armatuurlaua) kaudu või päring CLI kaudu, siis esimene asi, mis juhtub, on teie päringu autoriseerimine Keystone'is – kas saate luua masina, kas sellel on õigust seda võrku kasutada, kas teie kvoodi eelnõu jne.
- Keystone autentib teie taotluse ja genereerib vastusesõnumis autentimisloa, mida kasutatakse edaspidi. Pärast Keystone'ilt vastuse saamist saadetakse päring Nova (nova api) poole.
- Nova-api kontrollib teie taotluse kehtivust, võttes ühendust Keystone'iga, kasutades eelnevalt loodud autentimisluba
- Keystone teostab autentimist ja annab teavet lubade ja piirangute kohta selle autentimisloa alusel.
- Nova-api loob uue VM-i jaoks kirje nova-andmebaasis ja edastab masina loomise taotluse nova-schedulerile.
- Nova-scheduler valib määratud parameetrite, kaalude ja tsoonide põhjal hosti (arvutisõlme), millele VM juurutatakse. Selle kirje ja VM-i ID kirjutatakse nova-andmebaasi.
- Järgmisena võtab nova-scheduler ühendust nova-compute'iga eksemplari juurutamise taotlusega. Nova-compute võtab ühendust nova-conductoriga, et saada teavet masina parameetrite kohta (nova-conductor on nova element, mis toimib puhverserverina nova-andmebaasi ja nova-compute'i vahel, piirates nova-andmebaasi päringute arvu, et vältida probleeme andmebaasiga konsistentsi koormuse vähendamine).
- Nova-conductor saab nõutud teabe nova-andmebaasist ja edastab selle nova-compute'ile.
- Järgmisena heidetakse pildi ID saamiseks pilguheit nova-compute kõnedele. Glace kinnitab päringu Keystone'is ja tagastab nõutud teabe.
- Nova-compute võtab ühendust neutroniga, et saada teavet võrgu parameetrite kohta. Sarnaselt pilguga kinnitab neutron päringu Keystone'is, misjärel loob andmebaasi kirje (pordi identifikaator jne), loob pordi loomise taotluse ja tagastab nõutud teabe nova-compute'ile.
- Nova-compute võtab ühendust taotlusega eraldada virtuaalsele masinale maht. Sarnaselt pilguga kinnitab siider päringu Keystone'is, loob köite loomise taotluse ja tagastab nõutud teabe.
- Nova-compute võtab ühendust libvirtiga, paludes juurutada määratud parameetritega virtuaalmasin.
Tegelikult muutub pealtnäha lihtne toiming lihtsa virtuaalmasina loomisel selliseks API-kõnede keeriseks pilveplatvormi elementide vahel. Lisaks, nagu näete, koosnevad isegi varem määratud teenused väiksematest komponentidest, mille vahel toimub suhtlus. Masina loomine on vaid väike osa sellest, mida pilveplatvorm võimaldab teha – seal on teenus, mis vastutab liikluse tasakaalustamise eest, teenus, mis vastutab plokkide salvestamise eest, teenus, mis vastutab DNS-i eest, teenus, mis vastutab metallist serverite varustamise eest jne. Pilv võimaldab teil oma virtuaalseid masinaid käsitleda nagu lambakarja (erinevalt virtualiseerimisest). Kui sinu masinaga virtuaalses keskkonnas midagi juhtub - taastad selle varukoopiatest vms, aga pilverakendused on ehitatud nii, et virtuaalmasin ei mängi nii olulist rolli - virtuaalmasin “suri” – pole probleemi - uus on just loodud, sõiduk põhineb mallil ja nagu öeldakse, ei märganud meeskond võitleja kaotust. Loomulikult näeb see ette orkestreerimismehhanismide olemasolu - Heat mallide abil saate hõlpsasti juurutada kümnetest võrkudest ja virtuaalmasinatest koosneva keeruka funktsiooni.
Alati tasub silmas pidada, et ilma võrguta pole pilvetaristut – iga element ühel või teisel viisil suhtleb teiste elementidega läbi võrgu. Lisaks on pilvel absoluutselt mittestaatiline võrk. Loomulikult on alusvõrk isegi enam-vähem staatiline - uusi sõlmi ja lüliteid ei lisandu iga päev, kuid ülekattekomponent võib ja paratamatult muutub pidevalt - uusi võrke lisandub või kustutatakse, uusi virtuaalmasinaid ilmub ja vanad surema. Ja nagu mäletate kohe artikli alguses antud pilve definitsioonist, tuleks ressursid kasutajale eraldada automaatselt ja minimaalse (või veel parem, ilma) teenusepakkuja sekkumiseta. See tähendab, et võrguressursside pakkumise tüüp, mis on praegu olemas esiotsa kujul teie isikliku konto kujul, millele pääseb juurde http/https kaudu ja taustaprogrammina valves olev võrguinsener Vassili, ei ole pilv, isegi kui Vassilil on kaheksa kätt.
Neutron pakub võrguteenusena API-d pilveinfrastruktuuri võrguosa haldamiseks. Teenus annab volituse ja haldab Openstacki võrguosa, pakkudes abstraktsioonikihti nimega Network-as-a-Service (NaaS). See tähendab, et võrk on samasugune virtuaalne mõõdetav ühik nagu näiteks virtuaalsed protsessori tuumad või RAM-i hulk.
Kuid enne OpenStacki võrguosa arhitektuuri juurde asumist mõelgem, kuidas see võrk OpenStackis töötab ja miks on võrk pilve oluline ja lahutamatu osa.
Seega on meil kaks RED-kliendi VM-i ja kaks ROHELIST kliendi-VM-i. Oletame, et need masinad asuvad kahel hüperviisoril järgmiselt:
Hetkel on see vaid 4 serveri virtualiseerimine ja ei midagi enamat, kuna seni oleme teinud vaid 4 serveri virtualiseerimist, paigutades need kahele füüsilisele serverile. Ja siiani pole nad isegi võrku ühendatud.
Pilve tegemiseks peame lisama mitu komponenti. Esiteks virtualiseerime võrguosa – peame need 4 masinat paarikaupa ühendama ja kliendid tahavad L2 ühendust. Saate kasutada lülitit ja konfigureerida pagasiruumi selle suunas ning lahendada kõik linuxi silla või kogenumate kasutajate jaoks openvswitchi abil (selle juurde tuleme hiljem tagasi). Kuid võrke võib olla palju ja L2 pidev läbi lüliti surumine pole just kõige parem mõte – seal on erinevad osakonnad, teeninduskeskus, kuudepikkune taotluse valmimise ootamine, nädalaid tõrkeotsing – tänapäeva maailmas on see lähenemine enam ei tööta. Ja mida varem ettevõte sellest aru saab, seda lihtsam on tal edasi liikuda. Seetõttu valime hüperviisorite vahel L3 võrgu, mille kaudu meie virtuaalmasinad suhtlevad, ja sellele L3 võrgule ehitame virtuaalsed L2 ülekattevõrgud, kus meie virtuaalmasinate liiklus jookseb. Kapseldusena saate kasutada GRE, Geneve või VxLAN. Keskendume praegu viimasele, kuigi see pole eriti oluline.
Peame kuskilt VTEP-i leidma (ma loodan, et kõik on VxLAN-terminoloogiaga tuttavad). Kuna meil on L3 võrk, mis tuleb otse serveritest, ei takista miski meil VTEP-i serveritele endile paigutamast ja OVS (OpenvSwitch) on selleks suurepärane. Selle tulemusel saime sellise kujunduse:
Kuna VM-ide vahelist liiklust tuleb jagada, on virtuaalmasinatesse suunduvatel pordidel erinevad vlan-numbrid. Sildi number mängib rolli ainult ühes virtuaalses lülitis, kuna VxLAN-i kapseldatuna saame selle hõlpsalt eemaldada, kuna meil on VNI.
Nüüd saame luua nende jaoks oma masinad ja virtuaalsed võrgud probleemideta.
Mis saab aga siis, kui kliendil on teine masin, kuid ta on teises võrgus? Vajame võrkude vahel juurdumist. Tsentraliseeritud marsruutimise kasutamisel vaatleme lihtsat võimalust - see tähendab, et liiklus suunatakse spetsiaalsete spetsiaalsete võrgusõlmede kaudu (noh, reeglina on need ühendatud juhtsõlmedega, nii et meil on sama asi).
Tundub, et pole midagi keerulist - teeme juhtsõlmele sillaliidese, juhime liikluse sinna ja sealt suuname selle sinna, kuhu vaja. Kuid probleem on selles, et RED klient soovib kasutada 10.0.0.0/24 võrku ja ROHELINE klient 10.0.0.0/24 võrku. See tähendab, et hakkame ristuma aadressiruume. Lisaks ei soovi kliendid, et teised kliendid saaksid suunata nende sisevõrkudesse, mis on mõistlik. Võrkude ja kliendi andmeliikluse eraldamiseks eraldame neile igaühe jaoks eraldi nimeruumi. Nimeruum on tegelikult Linuxi võrgupinu koopia, see tähendab, et nimeruumis RED olevad kliendid on nimeruumi GREEN klientidest täielikult isoleeritud (noh, kas nende klientvõrkude vaheline marsruutimine on lubatud vaikimisi nimeruumi kaudu või ülesvoolu transpordiseadmetes).
See tähendab, et saame järgmise diagrammi:
L2 tunnelid koonduvad kõigist arvutussõlmedest juhtsõlme. sõlm, kus asub nende võrkude L3 liides, millest igaüks on eraldamiseks spetsiaalses nimeruumis.
Kõige olulisema unustasime aga ära. Virtuaalmasin peab pakkuma kliendile teenust, see tähendab, et sellel peab olema vähemalt üks väline liides, mille kaudu on võimalik selleni jõuda. See tähendab, et me peame minema välismaailma. Siin on erinevaid võimalusi. Teeme lihtsaima variandi. Lisame igale kliendile ühe võrgu, mis hakkab kehtima pakkuja võrgus ega kattu teiste võrkudega. Võrgud võivad ka ristuda ja vaadata teenusepakkuja võrgu küljel erinevaid VRF-e. Võrguandmed jäävad ka iga kliendi nimeruumi. Kuid nad lähevad siiski välismaailma ühe füüsilise (või sideme, mis on loogilisem) liidese kaudu. Kliendiliikluse eraldamiseks märgistatakse väljapoole liikuv liiklus kliendile eraldatud VLAN-märgisega.
Selle tulemusena saime järgmise diagrammi:
Mõistlik küsimus on, miks mitte teha arvutussõlmedele ise lüüsi? See pole suur probleem; pealegi, kui lülitate sisse hajutatud ruuteri (DVR), siis see töötab. Selle stsenaariumi puhul kaalume lihtsaimat võimalust tsentraliseeritud lüüsiga, mida Openstackis vaikimisi kasutatakse. Suure koormusega funktsioonide jaoks kasutavad nad nii hajutatud ruuterit kui ka kiirendustehnoloogiaid, nagu SR-IOV ja Passthrough, kuid nagu öeldakse, on see täiesti erinev lugu. Kõigepealt käsitleme põhiosa ja seejärel läheme üksikasjadesse.
Tegelikult on meie skeem juba toimiv, kuid sellel on paar nüanssi:
- Peame oma masinaid kuidagi kaitsma, st panema lüliti liidesele kliendi poole filtri.
- Tehke virtuaalmasinale võimalikuks IP-aadressi automaatne hankimine, et te ei peaks iga kord konsooli kaudu sinna sisse logima ja aadressi registreerima.
Alustame masinakaitsega. Selleks võib kasutada banaalseid iptablesi, miks mitte.
See tähendab, et nüüd on meie topoloogia muutunud pisut keerulisemaks:
Liigume edasi. Peame lisama DHCP-serveri. Ideaalseim koht DHCP-serverite leidmiseks iga kliendi jaoks oleks juba eespool mainitud juhtsõlm, kus asuvad nimeruumid:
Siiski on väike probleem. Mis siis, kui kõik taaskäivitub ja kogu teave DHCP-s aadresside rentimise kohta kaob. Loogiline, et masinatele antakse uued aadressid, mis pole kuigi mugav. Siin on kaks väljapääsu - kas kasutage domeeninimesid ja lisage igale kliendile DNS-server, siis pole aadress meile eriti oluline (sarnaselt k8s võrguosaga) - kuid probleem on välisvõrkudega, kuna aadresse saab ka neis DHCP kaudu väljastada - vaja on sünkroonimist pilveplatvormis olevate DNS-serveritega ja välise DNS-serveriga, mis minu meelest pole kuigi paindlik, aga täiesti võimalik. Või teine võimalus on kasutada metaandmeid – ehk salvestada masinale väljastatud aadressi info, et DHCP-server teaks, milline aadress masinale väljastada, kui masin on aadressi juba saanud. Teine võimalus on lihtsam ja paindlikum, kuna võimaldab salvestada lisainfot auto kohta. Nüüd lisame diagrammile agendi metaandmed:
Veel üks teema, mida tasub samuti arutada, on võimalus kasutada ühte välisvõrku kõigil klientidel, kuna välisvõrgud, kui need peavad kehtima kogu võrgus, on keerulised - peate pidevalt neid võrke eraldama ja jaotust kontrollima. Võimalus kasutada kõigi klientide jaoks ühte välist eelkonfigureeritud võrku on avaliku pilve loomisel väga kasulik. See muudab masinate juurutamise lihtsamaks, sest me ei pea otsima aadresside andmebaasi ega valima iga kliendi välisvõrgu jaoks ainulaadset aadressiruumi. Lisaks saame eelnevalt registreerida välise võrgu ja juurutamise ajal peame kliendi masinatega siduma ainult välised aadressid.
Ja siin tuleb meile appi NAT – me lihtsalt võimaldame klientidel NAT-i tõlke abil vaikenimeruumi kaudu välismaailmale juurde pääseda. Noh, siin on väike probleem. See on hea, kui kliendiserver toimib kliendina, mitte serverina – see tähendab, et see pigem algatab kui võtab ühendusi vastu. Aga meie jaoks on see vastupidi. Sel juhul peame tegema sihtkoha NAT-i, et liiklust vastu võttes saaks juhtsõlm aru, et see liiklus on mõeldud kliendi A virtuaalmasinale A, mis tähendab, et peame tegema NAT-i tõlke väliselt aadressilt, näiteks 100.1.1.1. .10.0.0.1, siseaadressile 100. Sel juhul, kuigi kõik kliendid kasutavad sama võrku, on sisemine isolatsioon täielikult säilinud. See tähendab, et peame juhtsõlmes tegema dNAT-i ja sNAT-i. See, kas kasutada ühte ujuvate aadressidega võrku või välisvõrke või mõlemat korraga, sõltub sellest, mida soovite pilve tuua. Me ei lisa skeemile ujuvaid aadresse, vaid jätame juba varem lisatud välisvõrgud - igal kliendil on oma välisvõrk (diagrammil on need välisliidesel märgitud vlan 200 ja XNUMX).
Tulemuseks saime huvitava ja samas läbimõeldud lahenduse, mis on küll teatud paindlikkusega, kuid millel puuduvad veel veataluvusmehhanismid.
Esiteks on meil ainult üks juhtsõlm - selle rike viib kõigi süsteemide kokkuvarisemiseni. Selle probleemi lahendamiseks peate moodustama vähemalt 3 sõlme kvoorumi. Lisame diagrammile selle:
Loomulikult on kõik sõlmed sünkroonitud ja kui aktiivne sõlm lahkub, võtab teine sõlm tema kohustused üle.
Järgmine probleem on virtuaalmasina kettad. Praegu salvestatakse need hüperviisorites endis ja hüperviisoriga seotud probleemide korral kaotame kõik andmed - ja reidi olemasolu ei aita siin, kui kaotame mitte ketta, vaid kogu serveri. Selleks peame looma teenuse, mis toimiks teatud tüüpi salvestusruumi esiotsa. See, milline salvestusruum sellest saab, pole meie jaoks eriti oluline, kuid see peaks kaitsma meie andmeid nii ketta kui ka sõlme ja võib-olla ka kogu korpuse rikke eest. Siin on mitu võimalust - loomulikult on Fibre Channeliga SAN-võrgud, kuid olgem ausad - FC on juba mineviku jäänuk - E1 analoog transpordis - jah, olen nõus, seda kasutatakse endiselt, kuid ainult seal, kus see on täiesti võimatu ilma selleta. Seetõttu ei võtaks ma 2020. aastal vabatahtlikult kasutusele FC-võrku, teades, et on muid huvitavamaid alternatiive. Ehkki igaühele oma, võib olla neid, kes usuvad, et FC kõigi piirangutega on kõik, mida me vajame – ma ei vaidle vastu, igaühel on oma arvamus. Kõige huvitavam lahendus on minu arvates aga kasutada SDS-i, näiteks Ceph.
Ceph võimaldab teil luua väga kättesaadava andmesalvestuslahenduse koos hulga võimalike varundusvõimalustega, alustades paarsuskontrolliga koodidest (analoogselt raid 5 või 6-ga) lõpetades andmete täieliku replikatsiooniga erinevatele ketastele, võttes arvesse ketaste asukohta serverid ja serverid kappides jne.
Cephi ehitamiseks vajate veel 3 sõlme. Salvestustega suhtlemine toimub ka võrgu kaudu, kasutades ploki-, objekti- ja failisalvestusteenuseid. Lisame skeemi salvestusruumi:
Märkus: saate teha ka hüperkonvergeeritud arvutussõlmi – see on kontseptsioon mitme funktsiooni kombineerimiseks ühel sõlmel – näiteks salvestus+arvutamine – ilma tseph-salvestuseks spetsiaalseid sõlmi pühendamata. Saame sama tõrketaluvusega skeemi – kuna SDS reserveerib andmed meie määratud broneeringutasemega. Hüperkonvergeeritud sõlmed on aga alati kompromiss – kuna salvestussõlm ei soojenda ainult õhku, nagu esmapilgul tundub (kuna sellel pole virtuaalmasinaid) – kulutab see protsessori ressursse SDS-i teenindamiseks (tegelikult teeb see kõik replikatsioon ja taastamine pärast sõlmede, ketaste jne tõrkeid). See tähendab, et kui ühendate selle salvestusega, kaotate osa arvutussõlme võimsusest.
Kõike seda kraami tuleb kuidagi hallata – vajame midagi, mille kaudu saaksime luua masina, võrgu, virtuaalse ruuteri jne. Selleks lisame juhtsõlmele teenuse, mis toimib armatuurlauana – klient saab selle portaaliga ühenduse luua http/ https kaudu ja teha kõike, mida ta vajab (noh, peaaegu).
Selle tulemusena on meil nüüd tõrketaluv süsteem. Kõiki selle infrastruktuuri elemente tuleb kuidagi hallata. Eelnevalt kirjeldati, et Openstack on projektide kogum, millest igaüks pakub konkreetset funktsiooni. Nagu näeme, on konfigureerimist ja kontrolli vajavaid elemente enam kui piisavalt. Täna räägime võrguosast.
Neutronite arhitektuur
OpenStackis on Neutron see, kes vastutab virtuaalmasina portide ühendamise eest ühisesse L2 võrku, liikluse marsruutimise tagamiseks erinevates L2 võrkudes asuvate VM-ide vahel, aga ka väljapoole marsruutimise eest, pakkudes teenuseid nagu NAT, Floating IP, DHCP jne.
Kõrgel tasemel saab võrguteenuse (põhiosa) toimimist kirjeldada järgmiselt.
VM-i käivitamisel võrguteenus:
- Loob antud VM-ile (või portidele) pordi ja teavitab sellest DHCP-teenust;
- Luuakse uus virtuaalse võrgu seade (libvirti kaudu);
- VM loob ühenduse 1. sammus loodud pordiga (portidega);
Kummalisel kombel põhineb Neutroni töö tavalistel mehhanismidel, mis on tuttavad kõigile, kes on kunagi Linuxi sukeldunud – nimeruumid, iptables, linuxi sillad, openvswitch, conntrack jne.
Tuleks kohe selgitada, et Neutron ei ole SDN-kontroller.
Neutron koosneb mitmest omavahel ühendatud komponendist:
Openstack-neutron-server on deemon, mis töötab kasutajate päringutega API kaudu. See deemon ei osale võrguühenduste registreerimisel, kuid annab selleks vajaliku teabe oma pluginatele, mis seejärel konfigureerivad soovitud võrguelemendi. OpenStacki sõlmede neutronagendid registreerivad end Neutroni serveris.
Neutron-server on tegelikult pythonis kirjutatud rakendus, mis koosneb kahest osast:
- REST teenus
- Neutron Plugin (tuum/teenus)
Teenus REST on mõeldud API-kõnede vastuvõtmiseks teistelt komponentidelt (nt taotlus teatud teabe edastamiseks jne).
Pluginad on pistikprogrammi komponendid/moodulid, mida kutsutakse välja API päringute ajal – see tähendab, et teenuse omistamine toimub nende kaudu. Pluginad jagunevad kahte tüüpi - teenindus ja juur. Üldjuhul vastutab hobune pistikprogramm peamiselt aadressiruumi ja VM-ide vaheliste L2 ühenduste haldamise eest ning teenusepluginad pakuvad juba lisafunktsioone, nagu VPN või FW.
Näiteks saab vaadata täna saadaolevate pluginate loendit
Teenuse pistikprogramme võib olla mitu, kuid hobuste pistikprogrammi saab olla ainult üks.
openstack-neutron-ml2 on standardne Openstacki juurplugin. Sellel pistikprogrammil on modulaarne arhitektuur (erinevalt eelkäijast) ja see konfigureerib võrguteenuse sellega ühendatud draiverite kaudu. Vaatame pistikprogrammi ennast veidi hiljem, kuna tegelikult annab see paindlikkuse, mis OpenStackil võrguosas on. Juurpluginat saab asendada (näiteks Contrail Networking teeb sellise asendamise).
RPC-teenus (rabbitmq-server) — teenus, mis pakub järjekorrahaldust ja suhtlemist teiste OpenStacki teenustega, samuti suhtlust võrguteenuse agentide vahel.
Võrguagendid — igas sõlmes asuvad agendid, mille kaudu võrguteenused konfigureeritakse.
Agente on mitut tüüpi.
Peamine agent on L2 agent. Need agendid töötavad kõigis hüperviisorites, sealhulgas juhtsõlmedes (täpsemalt kõigis sõlmedes, mis pakuvad rentnikele mis tahes teenust) ja nende peamine ülesanne on ühendada virtuaalsed masinad ühise L2-võrguga ning genereerida ka hoiatusi sündmuste toimumise korral ( näiteks pordi keelamine/lubamine).
Järgmine, mitte vähem oluline agent on L3 agent. Vaikimisi töötab see agent eranditult võrgusõlmes (sageli ühendatakse võrgusõlm juhtsõlmega) ja pakub marsruutimist rentnike võrkude vahel (nii oma võrkude kui ka teiste rentnike võrkude vahel ning on juurdepääsetav välismaailmale, pakkudes NAT, aga ka DHCP teenus). DVR-i (distributed router) kasutamisel ilmneb aga vajadus L3 plugina järele ka arvutussõlmedes.
L3 agent kasutab Linuxi nimeruume, et pakkuda igale rentnikule oma eraldatud võrkude komplekti ja virtuaalsete ruuterite funktsioone, mis suunavad liiklust ja pakuvad 2. kihi võrkude jaoks lüüsiteenuseid.
andmebaas — võrkude, alamvõrkude, portide, kogumite jne identifikaatorite andmebaas.
Tegelikult võtab Neutron vastu API päringuid mis tahes võrguolemite loomisest, autentib päringu ja edastab RPC (kui see pääseb juurde mõnele pistikprogrammile või agendile) või REST API (kui see suhtleb SDN-is) kaudu agentidele (pluginate kaudu) nõutud teenuse korraldamiseks vajalikud juhised.
Nüüd pöördume testinstallimise poole (kuidas see juurutatakse ja mis sellesse kuulub, näeme hiljem praktilises osas) ja vaatame, kus iga komponent asub:
(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 ~]$
Tegelikult on see kogu Neutroni struktuur. Nüüd tasub ML2 pistikprogrammile veidi aega kulutada.
Modulaarne kiht 2
Nagu eespool mainitud, on pistikprogramm standardne OpenStacki juurplugin ja sellel on modulaarne arhitektuur.
ML2 pistikprogrammi eelkäija oli monoliitse struktuuriga, mis ei võimaldanud näiteks ühes installatsioonis kasutada mitme tehnoloogia segu. Näiteks ei saanud korraga kasutada nii openvswitchi kui ka linuxbridge’i – ei esimest ega teist. Sel põhjusel loodi ML2 pistikprogramm koos oma arhitektuuriga.
ML2-l on kaks komponenti – kahte tüüpi draiverid: tüübidraiverid ja mehhanismi draiverid.
Tüüp draiverid määrake võrguühenduste korraldamiseks kasutatavad tehnoloogiad, näiteks VxLAN, VLAN, GRE. Samas võimaldab juht kasutada erinevaid tehnoloogiaid. Standardtehnoloogia on VxLAN-kapseldamine ülekattevõrkude ja vlan-välisvõrkude jaoks.
Tüübidraiverid hõlmavad järgmisi võrgutüüpe:
Korter - võrk ilma sildistamiseta
VLAN - märgistatud võrk
kohalik — spetsiaalne võrk kõik-ühes-paigaldiste jaoks (sellist paigaldust on vaja kas arendajatele või koolituseks)
RKAS — GRE-tunneleid kasutav ülekattevõrk
VxLAN — ülekattevõrk, mis kasutab VxLAN-tunneleid
Mehhanismi draiverid defineerida tööriistad, mis tagavad tüübidraiveris määratud tehnoloogiate organiseerimise - näiteks openvswitch, sr-iov, opendaylight, OVN jne.
Olenevalt selle draiveri juurutusest kasutatakse kas Neutroni poolt juhitavaid agente või ühendusi välise SDN-kontrolleriga, mis hoolitseb kõigi L2 võrkude organiseerimise, marsruutimise jms probleemide eest.
Näide: kui kasutame ML2-d koos OVS-iga, installitakse L2 agent igasse OVS-i haldavasse arvutussõlme. Kui aga kasutada näiteks OVN-i või OpenDayLighti, siis OVS-i juhtimine läheb nende jurisdiktsiooni alla - Neutron annab root-plugina kaudu käsklusi kontrollerile ja juba teebki seda, mida kästi.
Teeme värskenduse Open vSwitchi kohta
Hetkel on OpenStacki üks põhikomponente Open vSwitch.
Kui installite OpenStacki ilma täiendava tarnija SDN-ita, nagu Juniper Contrail või Nokia Nuage, on OVS pilvevõrgu peamine võrgukomponent ja võimaldab koos iptablesi, conntracki ja nimeruumidega korraldada täisväärtuslikke mitme üüripinnaga ülekattevõrke. Loomulikult saab seda komponenti asendada näiteks kolmanda osapoole patenteeritud (müüja) SDN-lahenduste kasutamisel.
OVS on avatud lähtekoodiga tarkvaralüliti, mis on mõeldud kasutamiseks virtualiseeritud keskkondades virtuaalse liikluse edastajana.
Hetkel on OVS-il väga korralik funktsionaalsus, mis sisaldab selliseid tehnoloogiaid nagu QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK jne.
Märkus. OVS-i ei kavandatud algselt pehme lülitina suure koormusega telekommunikatsioonifunktsioonide jaoks ja see oli rohkem mõeldud vähem ribalaiust nõudvate IT-funktsioonide jaoks, nagu veebiserver või meiliserver. OVS-i aga arendatakse edasi ning OVS-i praegused juurutused on selle jõudlust ja võimalusi kõvasti parandanud, mis võimaldab seda kasutada suure koormusega funktsioonidega telekomioperaatoritel, näiteks on olemas OVS-i juurutus, mis toetab DPDK-kiirendust.
OVS-is on kolm olulist komponenti, millest peate teadma:
- Kerneli moodul — tuumaruumis asuv komponent, mis töötleb liiklust juhtelemendilt saadud reeglite alusel;
- vSwitch deemon (ovs-vswitchd) on kasutajaruumis käivitatud protsess, mis vastutab kerneli mooduli programmeerimise eest - see tähendab, et see esindab otseselt lüliti töö loogikat
- Andmebaasi server - igas OVS-i kasutavas hostis paiknev kohalik andmebaas, kuhu konfiguratsioon salvestatakse. SDN-kontrollerid saavad selle mooduli kaudu suhelda, kasutades OVSDB-protokolli.
Selle kõigega kaasneb diagnostika- ja haldusutiliitide komplekt, nagu ovs-vsctl, ovs-appctl, ovs-ofctl jne.
Praegu kasutavad Openstacki telekommunikatsioonioperaatorid laialdaselt võrgufunktsioonide, nagu EPC, SBC, HLR jne, migreerimiseks. Mõned funktsioonid võivad OVS-iga sellisel kujul probleemideta töötada, kuid näiteks EPC töötleb abonendiliiklust – siis läheb see läbi. tohutu liiklus (nüüd ulatuvad liiklusmahud mitmesaja gigabitini sekundis). Sellise liikluse juhtimine läbi kerneli ruumi (kuna ekspediitor asub vaikimisi seal) ei ole loomulikult kõige parem mõte. Seetõttu juurutatakse OVS sageli täielikult kasutajaruumi, kasutades DPDK kiirendustehnoloogiat, et edastada liiklus NIC-ilt kasutajaruumi, mööda tuumast mööda.
Märkus. Telekommunikatsioonifunktsioonide jaoks kasutusele võetud pilve puhul on võimalik OVS-i mööda minnes anda liiklust otse lülitusseadmetesse. Selleks kasutatakse SR-IOV ja Passthrough mehhanisme.
Kuidas see tegeliku paigutuse korral töötab?
Liigume nüüd praktilise poole juurde ja vaatame, kuidas see kõik praktikas toimib.
Esmalt juurutame lihtsa Openstacki installi. Kuna mul pole katsete jaoks serverite komplekti käepärast, paneme prototüübi virtuaalmasinatest kokku ühele füüsilisele serverile. Jah, loomulikult selline lahendus äriliseks otstarbeks ei sobi, aga et näha näidet, kuidas Openstackis võrk toimib, siis sellisest paigaldusest piisab silmadele. Pealegi on selline paigaldus koolituse eesmärgil veelgi huvitavam - kuna saate liiklust jälgida jne.
Kuna me peame nägema ainult põhiosa, ei saa me kasutada mitut võrku, vaid tõsta kõike ainult kahe võrgu abil ja teist võrku selles paigutuses kasutatakse eranditult juurdepääsuks pilve- ja DNS-serverile. Välisvõrke me praegu ei puuduta - see on eraldi suure artikli teema.
Niisiis, alustame järjekorras. Esiteks väike teooria. Installime Openstacki, kasutades TripleO (Openstack on Openstack). TripleO olemus seisneb selles, et installime Openstacki kõik-ühes (st ühele sõlmele), mida nimetatakse undercloudiks, ja seejärel kasutame juurutatud Openstacki võimalusi, et installida tööks mõeldud Openstack, mida nimetatakse overcloudiks. Undercloud kasutab oma loomupärast võimet hallata füüsilisi servereid (paljast metallist) – projekti Ironic –, et pakkuda hüperviisoreid, mis täidavad arvutus-, juhtimis- ja salvestussõlmede rolle. See tähendab, et me ei kasuta Openstacki juurutamiseks kolmanda osapoole tööriistu – juurutame Openstacki Openstacki abil. See muutub installimise edenedes palju selgemaks, nii et me ei peatu sellega ja liigume edasi.
Märkus. Lihtsuse huvides ei kasutanud ma selles artiklis sisemiste Openstacki võrkude jaoks võrguisolatsiooni, vaid kõik on juurutatud ainult ühe võrgu abil. Võrguisolatsiooni olemasolu või puudumine aga ei mõjuta lahenduse põhifunktsionaalsust – kõik toimib täpselt samamoodi nagu isolatsiooni kasutamisel, kuid liiklus liigub samas võrgus. Kaubandusliku paigalduse jaoks on loomulikult vaja kasutada isolatsiooni, kasutades erinevaid vlane ja liideseid. Näiteks ceph-salvestuse haldusliiklus ja andmeliiklus ise (masinajuurdepääs ketastele jne) kasutavad isoleerituna erinevaid alamvõrke (Storage management and Storage) ning see võimaldab muuta lahenduse tõrketaluvamaks, jagades näiteks selle liikluse. , erinevate portide vahel või erinevate QoS-profiilide kasutamine erineva liikluse jaoks, et andmeliiklus ei pigistaks signaaliliiklust välja. Meie puhul lähevad nad samasse võrku ja tegelikult ei piira see meid kuidagi.
Märkus. Kuna kavatseme virtuaalmasinaid käivitada virtuaalses keskkonnas, mis põhineb virtuaalmasinatel, peame esmalt lubama pesastatud virtualiseerimise.
Saate kontrollida, kas pesastatud virtualiseerimine on lubatud või mitte, järgmiselt:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Kui näete tähte N, lubame pesastatud virtualiseerimise toe vastavalt mis tahes võrgust leitud juhendile, näiteks .
Peame virtuaalmasinatest kokku panema järgmise vooluringi:
Minu puhul kasutasin tulevase installi osaks olevate virtuaalmasinate ühendamiseks (ja ma sain neist 7, aga kui teil pole palju ressursse, saate hakkama ka 4-ga), kasutasin OpenvSwitchi. Tegin ühe ovs-silla ja ühendasin sellega virtuaalmasinad port-gruppide kaudu. Selleks lõin sellise xml-faili:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Siin on deklareeritud kolm pordirühma - kaks juurdepääsu ja üks magistraal (viimast oli vaja DNS-serveri jaoks, kuid saate ilma selleta hakkama või installida hosti masinasse - kumb on teile mugavam). Järgmiseks, kasutades seda malli, kuulutame enda oma läbi virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nüüd muudame hüperviisori pordi 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. Selle stsenaariumi korral pole pordi ovs-br1 aadress juurdepääsetav, kuna sellel pole vlan-i silti. Selle parandamiseks tuleb anda käsk sudo ovs-vsctl set port ovs-br1 tag=100. Pärast taaskäivitamist see silt aga kaob (kui keegi teab, kuidas seda paigal hoida, siis olen väga tänulik). Kuid see pole nii oluline, sest me vajame seda aadressi ainult installimise ajal ja ei vaja seda siis, kui Openstack on täielikult juurutatud.
Järgmisena loome pilvealuse 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=ttyS0Installimise käigus paned paika kõik vajalikud parameetrid nagu masina nimi, paroolid, kasutajad, ntp serverid jne, saad kohe pordid seadistada, aga minu jaoks isiklikult on pärast installeerimist lihtsam läbi masinasse sisse logida. konsooli ja parandage vajalikud failid. Kui teil on juba valmis pilt, võite seda kasutada või teha seda, mida mina tegin – laadige alla minimaalne Centos 7 pilt ja kasutage seda VM-i installimiseks.
Pärast edukat installimist peaks teil olema virtuaalne masin, kuhu saate installida pilve all
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningEsmalt installige installiprotsessiks vajalikud tööriistad:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud paigaldus
Loome virna kasutaja, määrame parooli, lisame selle sudoeri ja anname talle võimaluse täita sudo kaudu juurkäske ilma parooli sisestamata:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNüüd määrame hostifailis täieliku allpilve nime:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Järgmisena lisame hoidlad ja installime 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-ansibleMärkus: kui te ei plaani cephi installida, ei pea te cephiga seotud käske sisestama. Ma kasutasin Queensi väljaannet, kuid võite kasutada mis tahes muud, mis teile meeldib.
Järgmisena kopeerige pilvealune konfiguratsioonifail kasutaja kodukataloogi virna:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNüüd peame seda faili parandama, kohandades seda meie installiga.
Peate faili algusesse lisama 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 = 10Niisiis, vaatame seadeid läbi:
undercloud_hostinimi — pilvealuse serveri täisnimi peab ühtima DNS-serveris oleva kirjega
local_ip — kohalik pilveaadress võrgu loomiseks
võrguvärav — sama kohalik aadress, mis toimib pilvesõlmede paigaldamise ajal välismaailmale juurdepääsu väravana, langeb kokku ka kohaliku IP-ga
undercloud_public_host — väline API-aadress, mis tahes vaba aadress varundusvõrgust on määratud
undercloud_admin_host sisemine API-aadress, määratakse mis tahes vaba aadress varundusvõrgust
undercloud_nameservers - DNS-server
genereeri_teenuse_sertifikaat - see rida on praeguses näites väga oluline, sest kui te ei määra seda valeks, saate installimisel veateate, probleemi kirjeldatakse Red Hati veajälgijal
kohalik_liides liides võrgu pakkumisel. See liides konfigureeritakse pilvepõhise juurutamise ajal ümber, nii et teil peab allpilves olema kaks liidest – üks sellele juurdepääsuks, teine ettevalmistamiseks
local_mtu - MTU. Kuna meil on katselabor ja mul on OVS-i kommutaatori portidel MTU 1500, siis on vaja see määrata 1450 peale, et VxLAN-i kapseldatud paketid läbi saaksid
võrgu_tsidr — varustamisvõrk
teesklus — NAT-i kasutamine välisvõrgule juurdepääsuks
masquerade_network - võrk, mis ühendatakse NAT-iga
dhcp_start — aadresside kogumi algusaadress, millest ülepilvepõhise juurutamise ajal sõlmedele aadressid määratakse
dhcp_end — aadresside kogumi lõplik aadress, millest ülepilvepõhise juurutamise ajal sõlmedele aadressid määratakse
ülevaatus_imrange — enesevaatluseks vajalik aadresside kogum (ei tohiks kattuda ülalmainitud kogumiga)
planeerija_max_katsed — ülepilve installimise katsete maksimaalne arv (peab olema sõlmede arvust suurem või sellega võrdne)
Pärast faili kirjeldamist saate anda käsu allpilve juurutamiseks:
openstack undercloud install
Protseduur kestab olenevalt teie triikrauast 10 kuni 30 minutit. Lõppkokkuvõttes 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 ütleb, et olete allpilve edukalt installinud ja nüüd saate kontrollida alampilve olekut ja jätkata overcloudi installimist.
Kui vaatate ifconfigi väljundit, näete, et on ilmunud uus sillaliides
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud juurutamine toimub nüüd selle liidese kaudu.
Allolevast väljundist näete, et meil on kõik teenused ühes sõlmes:
(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 pilvealuse võrgu osa 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 ~]$Overcloud paigaldus
Praegu on meil ainult allpilv ja meil pole piisavalt sõlmpunkte, millest ülepilve kokku panna. Seetõttu juurutame kõigepealt vajalikud virtuaalmasinad. Juurutamise ajal installib Undercloud ise overcloud-masinasse operatsioonisüsteemi ja vajaliku tarkvara - see tähendab, et me ei pea masinat täielikult juurutama, vaid loome selle jaoks ainult ketta (või kettad) ja määrame selle parameetrid - see tähendab , tegelikult saame tühja serveri, millel pole OS-i installitud.
Läheme oma virtuaalmasinate ketastega kausta ja loome vajaliku suurusega 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 160GKuna töötame administraatorina, peame nende ketaste omanikku muutma, et mitte õigustega probleeme tekitada:
[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 selle uurimiseks cephi installida, siis käsud ei loo vähemalt 3 sõlme vähemalt kahe kettaga, vaid mallis näitavad, et kasutatakse virtuaalseid kettaid vda, vdb jne.
Suurepärane, nüüd peame kõik need masinad määratlema:
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 te seda ei lisa, siis seda ei tehta. suudab tuvastada virtuaalseid masinaid.
Nüüd peame määratlema kõik need masinad virshis:
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 väike nüanss – tripleO kasutab IPMI-d serverite haldamiseks installimise ja enesevaatluse ajal.
Introspektsioon on riistvara kontrollimise protsess, et saada selle parameetrid, mis on vajalikud sõlmede edasiseks varundamiseks. Enesevaatlus viiakse läbi kasutades iroonilist teenust, mis on loodud töötama metallist serveritega.
Kuid siin on probleem - kui riistvaralistel IPMI-serveritel on eraldi port (või jagatud port, kuid see pole oluline), siis virtuaalmasinatel selliseid porte pole. Siin tuleb meile appi vbmc-nimeline kark – utiliit, mis võimaldab emuleerida IPMI-porti. Sellele nüansile tasub tähelepanu pöörata eelkõige neil, kes soovivad ESXI hüperviisori peal sellist laborit üles seada – ausalt öeldes ei tea, kas sellel vbmc analoogi on, seega tasub enne kõige juurutamist selle probleemi üle juurelda. .
Installige vbmc:
yum install yum install python2-virtualbmcKui teie OS ei leia paketti, lisage hoidla:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNüüd seadistame utiliidi. Kõik on siin banaalne kuni häbitundeni. Nüüd on loogiline, et vbmc loendis pole servereid
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Nende kuvamiseks tuleb need käsitsi deklareerida järgmiselt:
[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 ilma selgitusteta selge. Praegu on aga kõik meie seansid VÄLJAS. Et nad saaksid liikuda olekusse UP, peate need lubama:
[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 ~]#Ja viimane puudutus - peate tulemüüri reegleid parandama (või selle täielikult keelama):
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 läheme pilve alla ja kontrollime, kas kõik töötab. Hostmasina aadress on 192.168.255.200, pilves lisasime juurutamiseks ettevalmistamisel vajaliku ipmitooli paketi:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningNagu näete, oleme vbmc kaudu juhtsõlme edukalt käivitanud. Nüüd lülitame selle välja ja liigume edasi:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Järgmine samm on sõlmede sisekaemus, millele liigpilv paigaldatakse. Selleks peame ette valmistama json-faili meie sõlmede kirjeldusega. Pange tähele, et erinevalt installimisest tühjadesse serveritesse, näitab fail porti, millel vbmc iga masina jaoks töötab.
[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:27Märkus: juhtsõlmel on kaks liidest, kuid sel juhul pole see oluline, selle installi puhul piisab meile ühest.
Nüüd valmistame ette json-faili. Peame märkima selle pordi popaadressi, mille kaudu varustamine toimub, sõlmede parameetrid, andma neile nimed ja näitama, kuidas ipmi-sse pääseda:
{
"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 ette valmistama pildid irooniliseks. Selleks laadige need alla wgeti kaudu ja installige:
(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 ~]$Piltide üleslaadimine pilve alla:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrollitakse, kas 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 asi - peate lisama DNS-serveri:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nüüd saame anda enesevaatluse käsu:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Nagu väljundist näha, sai kõik tehtud vigadeta. Kontrollime, kas kõik sõlmed on saadaolevas olekus:
(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 sõlmed on erinevas olekus, tavaliselt hallatavad, siis läks midagi valesti ja peate logi vaatama ja välja selgitama, miks see juhtus. Pidage meeles, et selle stsenaariumi korral kasutame virtualiseerimist ja virtuaalsete masinate või vbmc kasutamisega võivad olla seotud vead.
Järgmisena peame näitama, milline sõlm millist funktsiooni täidab - see tähendab, et märkige profiil, millega sõlm juurutab:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Määrake iga sõlme profiil:
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-d9afb69d1167Kontrollime, kas tegime kõik õigesti:
(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 õige, anname käsu overcloud juurutamiseks:
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 qemuPäris installimisel kasutatakse loomulikult kohandatud malle, meie puhul muudab see protsessi oluliselt keerulisemaks, kuna iga malli muudatust tuleb selgitada. Nagu varem kirjutatud, piisab isegi lihtsast installist, et näha, kuidas see töötab.
Märkus: --libvirt-tüüpi qemu muutuja on sel juhul vajalik, kuna kasutame pesastatud virtualiseerimist. Vastasel juhul ei saa te virtuaalmasinaid käivitada.
Nüüd on teil aega umbes tund või võib-olla rohkem (olenevalt riistvara võimalustest) ja võite vaid loota, et selle aja möödudes näete järgmist 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äisväärtuslik openstacki versioon, millel saate uurida, katsetada jne.
Kontrollime, kas kõik töötab korralikult. Kasutaja kodukataloogi virnas on kaks faili – üks stackrc (allapilve haldamiseks) ja teine overcloudrc (ülepilve haldamiseks). Need failid tuleb määrata allikana, kuna need sisaldavad 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 installimine nõuab siiski väikest puudutust - marsruudi lisamist kontrollerile, kuna masin, millega ma töötan, on teises võrgus. Selleks minge heat-admin konto alt kontroll-1 ja registreerige marsruut
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Noh, nüüd võite minna silmapiirile. Kogu teave – aadressid, sisselogimine ja parool – on failis /home/stack/overcloudrc. Lõplik diagramm näeb välja selline:
Muide, meie installis väljastati masinaaadressid DHCP kaudu ja nagu näete, väljastatakse need "juhuslikult". Saate mallis täpselt määratleda, milline aadress millisele masinale juurutamise ajal lisada, kui seda vajate.
Kuidas liiklus virtuaalmasinate vahel liigub?
Selles artiklis vaatleme kolme võimalust möödasõiduks
- Kaks masinat ühel hüperviisoril ühes L2 võrgus
- Kaks masinat erinevatel hüperviisoritel samas L2 võrgus
- Kaks masinat erinevates võrkudes (võrkudeülene juurdumine)
Juhtumeid, kus on juurdepääs välismaailmale välisvõrgu kaudu, ujuvad aadressid, samuti hajutatud marsruutimine, kaalume järgmisel korral, praegu keskendume siseliiklusele.
Kontrollimiseks paneme kokku järgmise diagrammi:
Oleme loonud 4 virtuaalset masinat - 3 ühes 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üperviisoritel 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 arvutus-0, masinad vm-2 ja vm-4 asuvad sõlmes arvutus-1.
Lisaks on loodud virtuaalne ruuter, mis võimaldab marsruutimist määratud 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õrkude lüüsidena:
(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 ~]$ Aga enne kui vaatame, kuidas liiklus liigub, vaatame, mis meil praegu on juhtsõlmel (mis on ühtlasi ka võrgusõlm) ja arvutussõlmel. Alustame arvutussõlmega.
[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 ~]$Hetkel on sõlmel kolm ovs-silda - br-int, br-tun, br-ex. Nagu näeme, on nende vahel rida liideseid. Arusaadavuse hõlbustamiseks joonistame kõik need liidesed diagrammile ja vaatame, mis juhtub.
Vaadates aadresse, kuhu VxLAN tunnelid tõstetakse, on näha, et üks tunnel on tõstetud väärtusele compute-1 (192.168.255.26), teine tunnel vaatab kontroll-1 (192.168.255.15). Kuid kõige huvitavam on see, et br-exil pole füüsilisi liideseid ja kui vaadata, millised vood on seadistatud, siis on näha, et see sild suudab hetkel ainult liiklust kahandada.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Nagu väljundist näha, kruvitakse aadress otse füüsilisse porti, mitte virtuaalsilla liidesesse.
[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 järgi tuleb kõik, mis phy-br-ex pordist tuli, ära visata.
Tegelikult ei ole praegu sellele sillale liiklust mujale peale selle liidese (br-int liides) siseneda ja kukkumiste järgi otsustades on BUM liiklus juba sillale sisse lennanud.
See tähendab, et liiklus saab sellest sõlmest lahkuda ainult läbi VxLAN tunneli ja mitte midagi muud. Kui aga DVR sisse lülitad, siis olukord muutub, aga sellega tegeleme mõni teine kord. Võrgu eraldamise kasutamisel, näiteks vlanide kasutamisel, pole teil Vlan 3-s mitte üks L0 liides, vaid mitu liidest. Kuid VxLAN-liiklus lahkub sõlmest samal viisil, kuid kapseldub ka mingisse spetsiaalsesse vlan-i.
Oleme arvutussõlme välja sorteerinud, liigume edasi juhtsõlme juurde.
[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 ~]$Tegelikult võime öelda, et kõik on sama, kuid IP-aadress pole enam füüsilisel liidesel vaid virtuaalsillal. Seda tehakse seetõttu, et see sadam on sadam, mille kaudu väljub liiklus välismaailma.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ See port on seotud br-ex sillaga ja kuna sellel pole vlan-i silte, on see port magistraalport, millel on lubatud kõik vlanid, nüüd läheb liiklus ilma sildita välja, nagu näitab vlan-id 0 väljund ülalpool.
Kõik muu on hetkel sarnane arvutussõlmega – samad sillad, samad tunnelid, mis lähevad kahte arvutussõlme.
Selles artiklis me salvestussõlmesid ei käsitle, kuid mõistmiseks tuleb öelda, et nende sõlmede võrguosa on häbiväärselt banaalne. Meie puhul on ainult üks füüsiline port (eth0), millele on määratud IP-aadress, ja kõik. Puuduvad VxLAN-tunnelid, tunnelisildad jne - ovs-e pole üldse, kuna sellel pole mõtet. Võrgu eraldamise kasutamisel on sellel sõlmel kaks liidest (füüsilised pordid, bodny või lihtsalt kaks vlani - see pole oluline - see sõltub sellest, mida soovite) - üks haldamiseks, teine liikluse jaoks (kirjutamine VM-i kettale , lugemine kettalt jne)
Arvasime välja, mis meil sõlmedel on, kui teenust polnud. Nüüd käivitame 4 virtuaalset masinat ja vaatame, kuidas ülalkirjeldatud skeem muutub - meil peaksid olema pordid, virtuaalsed ruuterid jne.
Siiani näeb meie võrk välja selline:
Meil on igas arvutisõlmes kaks virtuaalmasinat. Kasutades näitena arvutus-0, vaatame, kuidas kõik on kaasatud.
[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
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
See liides näeb linuxi sillas välja:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Nagu väljundist näha, on sillas vaid kaks liidest - tap95d96a75-a0 ja qvb95d96a75-a0.
Siin tasub veidi peatuda OpenStacki virtuaalse võrgu seadmete tüüpidel:
vtap – eksemplarile (VM) lisatud virtuaalne liides
qbr – Linuxi sild
qvb ja qvo - vEth paar, mis on ühendatud Linuxi silla ja Open vSwitch sillaga
br-int, br-tun, br-vlan — vSwitchi sildade avamine
patch-, int-br-, phy-br- – ava vSwitchi plaastriliidesed, mis ühendavad sildu
qg, qr, ha, fg, sg – avage vSwitchi pordid, mida virtuaalseadmed OVS-iga ühenduse loomiseks kasutavad
Nagu aru saate, kui meil on sillas qvb95d96a75-a0 port, mis on vEth paar, siis kuskil on selle vaste, mida peaks loogiliselt nimetama qvo95d96a75-a0. Vaatame, millised pordid OVS-is on.
[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 ~]$ Nagu näeme, on sadam br-int. Br-int toimib lülitina, mis lõpetab virtuaalmasina pordid. Lisaks qvo95d96a75-a0-le on väljundis nähtav port qvo5bd37136-47. See on teise virtuaalmasina port. Selle tulemusena näeb meie diagramm nüüd välja selline:
Küsimus, mis peaks tähelepanelikku lugejat kohe huvitama – milline on linuxi sild virtuaalmasina pordi ja OVS pordi vahel? Fakt on see, et masina kaitsmiseks kasutatakse turvagruppe, mis pole muud kui iptables. OVS ei tööta iptablesiga, nii et see kark leiutati. See on aga aegumas – uutes väljaannetes asendatakse see conntrackiga.
See tähendab, et skeem näeb lõpuks välja selline:
Kaks masinat ühel hüperviisoril ühes L2 võrgus
Kuna need kaks VM-i asuvad samas L2 võrgus ja samal hüperviisoril, liigub nendevaheline liiklus loogiliselt lokaalselt 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 erinevatel hüperviisoritel samas L2 võrgus
Nüüd vaatame, kuidas toimub liiklus kahe masina vahel samas L2 võrgus, kuid mis asuvad erinevatel hüperviisoritel. Ausalt öeldes ei muutu eriti midagi, lihtsalt liiklus hüperviisorite vahel läheb läbi vxlani tunneli. Vaatame näidet.
Virtuaalsete masinate aadressid, mille vahel liiklust jälgime:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Vaatame br-int edastustabelit arvutus-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Liiklus peaks minema porti 2 – vaatame, mis tüüpi port see 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 – see tähendab br-tun liides. Vaatame, mis juhtub br-tun paketiga:
[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 vxlani tunnel arvutis 1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Läheme compute-1 juurde ja vaatame, mis paketiga edasi saab:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac on arvutus-1 br-int edasisuunamistabelis ja nagu ülaltoodud väljundist näha, on see nähtav pordi 2 kaudu, mis on br-tun-i suund:
[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:46Noh, siis näeme, et br-int compute-1-s on sihtkoha poppy:
[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 vastuvõetud pakett lendab porti 3, mille taga on juba virtuaalmasina eksemplar-00000003.
Openstacki juurutamise ilu virtuaalses infrastruktuuris õppimiseks seisneb selles, et saame hõlpsasti jäädvustada hüperviisorite vahelist liiklust ja näha, mis sellega toimub. Teeme nüüd seda, käivitage tcpdump vnet-pordis compute-0 suunas:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Esimene rida näitab, et Patek aadressilt 10.0.1.85 läheb aadressile 10.0.1.88 (ICMP liiklus) ja see on mähitud VxLAN paketti vni 22-ga ja pakett läheb hostilt 192.168.255.19 (arvuta-0) hostile 192.168.255.26. .1 ( arvuta-XNUMX). Saame kontrollida, kas VNI ühtib ovsis määratletuga.
Naaseme sellele reale action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],väljund:2. 0x16 on vni kuueteistkümnendsüsteemis. Teisendame selle arvu 16. süsteemiks:
16 = 6*16^0+1*16^1 = 6+16 = 22St vni vastab tegelikkusele.
Teine rida näitab tagasiliiklust, noh, pole mõtet seletada, seal on kõik selge.
Kaks masinat erinevates võrkudes (võrkudevaheline marsruutimine)
Tänase päeva viimane juhtum on võrkude vaheline marsruutimine ühe projekti raames virtuaalse ruuteri abil. Kaalume juhtumit ilma DVR-ita (vaatame seda teises artiklis), nii et marsruutimine toimub võrgusõlmes. Meie puhul ei paigutata võrgusõlm eraldi olemisse ja asub juhtsõlmel.
Esiteks vaatame, kas marsruutimine töötab:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msKuna sel juhul peab pakett minema lüüsi ja olema seal marsruutseeritud, peame välja selgitama lüüsi MAC-aadressi, mille jaoks vaatame eksemplari ARP-tabelit:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Nüüd vaatame, kuhu suunatakse liiklus sihtkohaga (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 port 2 viib:
[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 läheb br-tun. Vaatame, millisesse vxlani tunnelisse see mähitakse:
[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 vxlani 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 juhtsõlme:
[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 on jõudnud juhtsõlmeni, seega peame sinna minema ja vaatama, kuidas marsruutimine toimub.
Nagu mäletate, nägi sees olev juhtsõlm välja täpselt samasugune kui arvutussõlm – samad kolm silda, ainult br-exil oli füüsiline port, mille kaudu sai sõlm liiklust väljapoole saata. Eksemplaride loomisega muudeti arvutussõlmede konfiguratsiooni – sõlmedele lisati linuxi sild, iptables ja liidesed. Võrkude ja virtuaalse ruuteri loomine jättis oma jälje ka juhtsõlme konfiguratsioonile.
Seega on ilmne, et lüüsi MAC-aadress peab olema juhtsõlme br-int edastamistabelis. Kontrollime, kas see on seal ja kust see otsib:
[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 pordist qr-0c52b15f-8f. Kui minna tagasi Openstacki virtuaalsete portide loendi juurde, siis seda tüüpi porti kasutatakse erinevate virtuaalsete seadmete ühendamiseks OVS-iga. Täpsemalt on qr virtuaalse ruuteri port, mis on esitatud nimeruumina.
Vaatame, millised nimeruumid serveris asuvad:
[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 ~]$ Koguni kolm eksemplari. Kuid nimede järgi otsustades võite arvata igaühe eesmärgi. Naaseme ID 0 ja 1 eksemplaride juurde hiljem, nüüd oleme huvitatud nimeruumist 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 ~]$ See nimeruum sisaldab kahte sisemist, mille me varem lõime. Mõlemad virtuaalsed pordid on lisatud br-int. Kontrollime pordi qr-0c52b15f-8f Mac-aadressi, kuna liiklus, otsustades sihtkoha mac-aadressi järgi, läks 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<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ See tähendab, et antud juhul töötab kõik vastavalt standardse marsruutimise seadustele. Kuna liiklus on mõeldud hostile 10.0.2.8, peab see väljuma läbi teise liidese qr-92fa49b5-54 ja minema läbi vxlani tunneli arvutussõ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 pole. Vaatame, kus on br-int-is nähtav hosti 10.0.2.8 popaadress:
[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 ~]$ Ootuspäraselt kulgeb liiklus br-tun, vaatame, millisesse tunnelisse liiklus järgmisena suundub:
[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 läheb tunnelisse, et arvutada-1. Noh, compute-1 puhul on kõik lihtne - br-tunist läheb pakett br-int ja sealt 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õesti õ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 ~]$
Tegelikult käisime kogu paki läbi. Arvan, et märkasite, et liiklus käis läbi erinevate vxlani tunnelite ja väljus erinevate VNI-dega. Vaatame, mis VNI-d need on, misjärel kogume sõlme juhtimisporti prügimäed ja veendume, et liiklus kulgeb täpselt nii, nagu ülalpool kirjeldatud.
Seega on tunnelil arvutamiseks-0 järgmised toimingud=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],väljund:3. Teisendame 0x16 kümnendarvude süsteemiks:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunnelil arvutamiseks-1 on järgmine VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],väljund:2. Teisendame 0x63 kümnendarvude süsteemiks:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Noh, vaatame nüüd prügimäge:
[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 pakett on vxlani pakett hostist 192.168.255.19 (arvuta-0) hostini 192.168.255.15 (kontroll-1) koos vni 22-ga, mille sees pakitakse ICMP-pakett hostist 10.0.1.85 hostini 10.0.2.8. Nagu eespool arvutasime, vastab vni väljundis nähtule.
Teine pakett on vxlani pakett hostist 192.168.255.15 (kontroll-1) hostini 192.168.255.26 (arvuta-1) koos vni 99-ga, mille sees pakitakse ICMP-pakett hostist 10.0.1.85 hostile 10.0.2.8. Nagu eespool arvutasime, vastab vni väljundis nähtule.
Järgmised kaks paketti on tagasiliiklus alates 10.0.2.8, mitte 10.0.1.85.
See tähendab, et lõpuks saime järgmise juhtsõlme skeemi:
Näib, et see on see? Unustasime kaks nimeruumi:
[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 ~]$ Kuna me rääkisime pilveplatvormi arhitektuurist, siis oleks hea, kui masinad saaksid aadressid automaatselt DHCP serverist. Need on kaks DHCP-serverit meie kahe võrgu jaoks 10.0.1.0/24 ja 10.0.2.0/24.
Kontrollime, kas see on tõsi. Selles nimeruumis on ainult üks aadress - 10.0.1.1 - DHCP-serveri enda aadress ja see sisaldub ka br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Vaatame, kas protsessid, mis sisaldavad oma nimes juhtsõlmes qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2:
[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 ~]$ Selline protsess on olemas ja ülaltoodud väljundis toodud info põhjal saame näiteks vaadata, mis meil hetkel üürida on:
[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 ~]$Selle tulemusel saame juhtsõlmes järgmised teenused:
Noh, pidage meeles – see on vaid 4 masinat, 2 sisevõrku ja üks virtuaalne ruuter... Meil ei ole praegu siin välisvõrke, hunnik erinevaid projekte, millest igaühel on oma võrgud (kattuvad) ja meil on hajutatud ruuter lülitus välja ja lõpuks oli katsestendis ju ainult üks kontrollsõlm (tõrketaluvuseks peab olema kvoorum kolmest sõlmest). Loogiline, et kaubanduses on kõik “natuke” keerulisem, kuid selle lihtsa näite puhul saame aru, kuidas see peaks toimima – see, kas sul on 3 või 300 nimeruumi, on muidugi oluline, aga kogu nimeruumi toimimise seisukohalt. struktuur, ei muutu midagi palju... kuigi enne, kui te mõne müüja SDN-i ei ühenda. Aga see on hoopis teine lugu.
Loodan, et oli huvitav. Kui teil on kommentaare/täiendusi või kuskil ma otse valetasin (olen inimene ja mu arvamus jääb alati subjektiivseks) - kirjutage, mis vajab parandamist/lisamist - me parandame/lisame kõik.
Kokkuvõtteks tahaksin öelda paar sõna Openstacki (nii vanilje kui ka müüja) võrdlemise kohta VMWare'i pilvelahendusega – seda küsimust on minult viimase paari aasta jooksul liiga sageli küsitud ja ausalt öeldes olen ma juba tüdinenud, aga siiski. Minu arvates on neid kahte lahendust väga raske võrrelda, kuid kindlasti võib öelda, et mõlemal lahendusel on omad miinused ning ühe lahenduse valikul tuleb kaaluda plusse ja miinuseid.
Kui OpenStack on kogukonna juhitud lahendus, siis VMWare'il on õigus teha ainult seda, mida ta tahab (loe - mis on tema jaoks kasumlik) ja see on loogiline - kuna tegemist on äriettevõttega, mis on harjunud oma klientidelt raha teenima. Kuid on üks suur ja paks AGA - OpenStackist saab lahti näiteks Nokiast ja väikese kuluga lülituda näiteks Juniperi (Contrail Cloud) lahendusele, kuid VMWare'ist tõenäoliselt ei saa. . Minu jaoks näevad need kaks lahendust välja nii - Openstack (vendor) on lihtne puur, kuhu sind pannakse, aga sul on võti ja võid sealt igal ajal lahkuda. VMWare on kuldne puur, omanikul on puuri võti ja see läheb sulle kalliks maksma.
Ma ei reklaami ei esimest ega teist toodet – valite, mida vajate. Aga kui mul oleks selline valik, siis valiksin mõlemad lahendused - VMWare IT-pilve jaoks (madalad koormused, lihtne haldus), OpenStack mõnelt tootjalt (Nokia ja Juniper pakuvad väga häid võtmed kätte lahendusi) - Telecomi pilve jaoks. Ma ei kasutaks Openstacki puhta IT jaoks – see on nagu kahurist varblaste laskmine, kuid ma ei näe selle kasutamisel muid vastunäidustusi peale koondamise. VMWare'i kasutamine telekommunikatsioonis on aga nagu killustiku vedamine Ford Raptoriga – see on väljast ilus, kuid juht peab ühe sõidu asemel tegema kümme.
Minu arvates on VMWare'i suurim miinus selle täielik suletus - ettevõte ei anna teile teavet selle kohta, kuidas see töötab, näiteks vSAN või mis on hüperviisori tuumas - see pole talle lihtsalt kasumlik - see tähendab, et saate Ärge kunagi saage VMWare'i eksperdiks – ilma tarnija toetuseta olete hukule määratud (väga sageli kohtan VMWare'i eksperte, kes on triviaalsete küsimuste pärast hämmeldunud). Minu jaoks ostab VMWare lukustatud kapotiga auto - jah, sul võivad olla spetsialistid, kes saavad hammasrihma vahetada, aga kapoti saab avada vaid see, kes sulle selle lahenduse müüs. Mulle isiklikult ei meeldi lahendused, millesse ma ei mahu. Ütlete, et võib-olla ei pea te kapoti alla minema. Jah, see on võimalik, aga ma vaatan teid siis, kui teil on vaja pilves kokku panna suur funktsioon 20-30 virtuaalmasinast, 40-50 võrgust, millest pooled tahavad väljas käia ja teine pool nõuab SR-IOV kiirendus, vastasel juhul vajate neid autosid veel paarkümmend - vastasel juhul ei piisa jõudlusest.
On ka teisi seisukohti, nii et ainult teie saate otsustada, mida valida, ja mis kõige tähtsam, vastutate siis oma valiku eest. See on vaid minu arvamus - inimene, kes on näinud ja katsunud vähemalt 4 toodet - Nokia, Juniper, Red Hat ja VMWare. See tähendab, et mul on, millega võrrelda.
Allikas: www.habr.com