Pilvilaskenta tunkeutuu yhä syvemmälle elämäämme, eikä luultavasti ole ainuttakaan henkilöä, joka ei olisi käyttänyt pilvipalveluita ainakin kerran. Kuitenkin, mitä pilvi tarkalleen ottaen on ja miten se toimii, harva tietää edes idean tasolla. 5G:stä on jo tulossa todellisuutta ja tietoliikenneinfrastruktuuri on alkamassa siirtyä naparatkaisuista pilviratkaisuihin, aivan kuten siirtyi täysin laitteistoratkaisuista virtualisoituihin "pilareihin".
Tänään puhumme pilviinfrastruktuurin sisäisestä maailmasta, erityisesti tarkastelemme verkko-osan perusteita.
Mikä on pilvi? Sama virtualisointi - profiilinäkymä?
Enemmän kuin looginen kysymys. Ei – tämä ei ole virtualisointia, vaikka sitä ei voisi tehdä ilman sitä. Katsotaanpa kahta määritelmää:
Cloud computing (jäljempänä Cloud) on malli, joka tarjoaa käyttäjäystävällisen pääsyn hajautettuihin laskentaresursseihin, jotka on otettava käyttöön ja käynnistettävä pyynnöstä mahdollisimman alhaisella viiveellä ja mahdollisimman pienillä kustannuksilla palveluntarjoajalle.
virtualisointi - tämä on kyky jakaa yksi fyysinen kokonaisuus (esimerkiksi palvelin) useiksi virtuaalisiksi, mikä lisää resurssien käyttöä (esimerkiksi sinulla oli 3 palvelinta ladattuina 25-30 prosentilla, virtualisoinnin jälkeen saat 1 palvelimen ladattuna 80-90 prosenttia). Luonnollisesti virtualisointi syö osan resursseista - sinun täytyy ruokkia hypervisoria, mutta kuten käytäntö on osoittanut, peli on kynttilän arvoinen. Ihanteellinen esimerkki virtualisoinnista on VMWare, joka valmistelee virtuaalikoneita täydellisesti, tai esimerkiksi KVM, josta pidän enemmän, mutta tämä on makuasia.
Käytämme virtualisointia huomaamattamme, ja rautaiset reitittimetkin käyttävät jo virtualisointia - esimerkiksi JunOS:n uusimmassa versiossa käyttöjärjestelmä on asennettu virtuaalikoneena reaaliaikaisen Linux-jakelun (Wind River 9) päälle. Mutta virtualisointi ei ole pilvi, mutta pilvi ei voi olla olemassa ilman virtualisointia.
Virtualisointi on yksi rakennuspalikoista, jolle pilvi rakennetaan.
Pilven tekeminen yksinkertaisesti keräämällä useita hypervisoreita yhdeksi L2-alueelle, lisäämällä pari yaml-pelikirjaa vlanien automaattista rekisteröintiä varten jonkinlaisen ansiblen kautta ja häiritsemällä siihen jotain, kuten orkestrointijärjestelmää virtuaalikoneiden automaattista luomista varten, ei toimi. Se on tarkempi, mutta tuloksena oleva Frankenstein ei ole se pilvi, jota tarvitsemme, vaikka se saattaakin olla lopullinen unelma muille. Lisäksi, jos otat saman Openstackin, se on olennaisesti edelleen Frankenstein, mutta no, älkäämme puhuko siitä nyt.
Mutta ymmärrän, että yllä esitetystä määritelmästä ei ole täysin selvää, mitä voidaan kutsua pilveksi.
Siksi NIST:n (National Institute of Standards and Technology) asiakirja tarjoaa viisi pääominaisuutta, jotka pilviinfrastruktuurilla tulisi olla:
Palvelun tarjoaminen pyynnöstä. Käyttäjälle on annettava vapaa pääsy hänelle allokoituihin tietokoneresursseihin (kuten verkot, virtuaalilevyt, muisti, prosessoriytimet jne.), ja nämä resurssit on tarjottava automaattisesti - eli ilman palveluntarjoajan väliintuloa.
Palvelun laaja saatavuus. Pääsy resursseihin on tarjottava vakiomekanismeilla, jotta voidaan käyttää sekä tavallisia tietokoneita että ohuita asiakkaita ja mobiililaitteita.
Resurssien yhdistäminen pooleiksi. Resurssipoolien on kyettävä tarjoamaan resursseja useille asiakkaille samanaikaisesti varmistaen, että asiakkaat ovat eristyksissä ja vapaita keskinäisestä vaikutuksesta ja kilpailusta resursseista. Myös verkot sisältyvät pooleihin, mikä osoittaa mahdollisuuden käyttää päällekkäisiä osoitteita. Altaat on voitava skaalata kysynnän mukaan. Poolien käyttö mahdollistaa tarvittavan tason resurssien vikasietoisuuden ja fyysisten ja virtuaalisten resurssien poistamisen - palvelun vastaanottajalle tarjotaan yksinkertaisesti hänen pyytämänsä resurssit (missä nämä resurssit sijaitsevat fyysisesti, kuinka monta palvelimet ja kytkimet - sillä ei ole asiakkaalle väliä). Meidän on kuitenkin otettava huomioon, että palveluntarjoajan on varmistettava näiden resurssien avoin varaus.
Nopea sopeutuminen erilaisiin olosuhteisiin. Palveluiden tulee olla joustavia - resurssien nopea tarjonta, niiden uudelleenjako, resurssien lisääminen tai vähentäminen asiakkaan pyynnöstä ja asiakkaan puolelta tulee olla tunne, että pilviresurssit ovat loputtomat. Ymmärtämisen helpottamiseksi et esimerkiksi näe varoitusta siitä, että osa Applen iCloudin levytilasta on kadonnut, koska palvelimen kiintolevy on rikki ja asemat hajoavat. Lisäksi tämän palvelun mahdollisuudet ovat puolestasi lähes rajattomat - tarvitset 2 TB - ei hätää, maksoit ja sait sen. Samanlainen esimerkki voidaan antaa Google.Drive- tai Yandex.Disk-sovelluksella.
Mahdollisuus mitata tarjottua palvelua. Pilvijärjestelmien tulee automaattisesti ohjata ja optimoida kulutettuja resursseja, ja näiden mekanismien tulee olla läpinäkyviä sekä käyttäjälle että palveluntarjoajalle. Eli voit aina tarkistaa, kuinka paljon resursseja sinä ja asiakkaasi kuluttavat.
On syytä ottaa huomioon, että nämä vaatimukset ovat enimmäkseen julkisen pilven vaatimuksia, joten yksityisen pilven (eli yrityksen sisäisiin tarpeisiin lanseeratun pilven) osalta näitä vaatimuksia voidaan hieman muokata. Ne on kuitenkin vielä tehtävä, muuten emme saa kaikkia pilvipalvelun etuja.
Miksi tarvitsemme pilven?
Kuitenkin mikä tahansa uusi tai olemassa oleva tekniikka, mikä tahansa uusi protokolla luodaan jollekin (no, paitsi tietysti RIP-ng). Kukaan ei tarvitse protokollaa protokollan vuoksi (no, paitsi tietysti RIP-ng). On loogista, että pilvi on luotu tarjoamaan jonkinlaista palvelua käyttäjälle/asiakkaalle. Tunnemme kaikki ainakin pari pilvipalvelua, kuten Dropbox tai Google.Docs, ja uskon, että useimmat ihmiset käyttävät niitä menestyksekkäästi – esimerkiksi tämä artikkeli on kirjoitettu Google.Docs-pilvipalvelulla. Mutta tuntemamme pilvipalvelut ovat vain osa pilven ominaisuuksista – tarkemmin sanottuna ne ovat vain SaaS-tyyppisiä palveluita. Voimme tarjota pilvipalvelun kolmella tavalla: SaaS-, PaaS- tai IaaS-muodossa. Mitä palvelua tarvitset, riippuu toiveistasi ja kyvyistäsi.
Katsotaanpa kutakin järjestyksessä:
Ohjelmisto palveluna (SaaS) on malli täyden palvelun tarjoamiseksi asiakkaalle, esimerkiksi sähköpostipalvelu, kuten Yandex.Mail tai Gmail. Tässä palvelun toimitusmallissa sinä asiakkaana ei oikeastaan tee muuta kuin käytät palveluita – eli sinun ei tarvitse miettiä palvelun käyttöönottoa, sen vikasietoisuutta tai redundanssia. Tärkeintä ei ole vaarantaa salasanaasi; tämän palvelun tarjoaja hoitaa loput puolestasi. Palveluntarjoajan näkökulmasta hän on täysin vastuussa koko palvelusta - palvelinlaitteistosta ja isäntäkäyttöjärjestelmistä tietokanta- ja ohjelmistoasetuksiin.
Palvelualusta (PaaS) — tätä mallia käytettäessä palveluntarjoaja toimittaa asiakkaalle työkappaleen palvelua varten, esimerkiksi otetaan Web-palvelin. Palveluntarjoaja toimitti asiakkaalle virtuaalipalvelimen (itse asiassa joukon resursseja, kuten RAM/CPU/Storage/Nets jne.) ja jopa asensi käyttöjärjestelmän ja tarvittavat ohjelmistot tälle palvelimelle, mutta kaiken tämän tekee asiakas itse ja palvelun suorittamiseksi asiakas vastaa. Palveluntarjoaja vastaa edellisen tapauksen tapaan fyysisten laitteiden, hypervisorien, itse virtuaalikoneen toimivuudesta, sen verkon käytettävyydestä jne., mutta itse palvelu ei ole enää sen vastuualueella.
Infrastruktuuri palveluna (IaaS) - Tämä lähestymistapa on jo mielenkiintoisempi, itse asiassa palveluntarjoaja tarjoaa asiakkaalle täydellisen virtualisoidun infrastruktuurin - eli jonkin joukon (pooli) resursseja, kuten CPU Cores, RAM, Networks jne. Kaikki muu on kiinni asiakas - mitä asiakas haluaa tehdä näillä resursseilla allokoidussa poolissa (kiintiö) - se ei ole erityisen tärkeää toimittajalle. Haluaako asiakas luoda oman vEPC:n tai jopa minioperaattorin ja tarjota viestintäpalveluita - ei epäilystäkään - tee se. Tällaisessa tilanteessa palveluntarjoaja on vastuussa resurssien toimittamisesta, niiden vikasietoisuudesta ja saatavuudesta sekä käyttöjärjestelmästä, jonka avulla he voivat yhdistää nämä resurssit ja asettaa ne asiakkaan saataville siten, että he voivat lisätä tai vähentää resursseja milloin tahansa. asiakkaan pyynnöstä. Asiakas konfiguroi kaikki virtuaalikoneet ja muut hopealanka itse itsepalveluportaalin ja -konsolin kautta, mukaan lukien verkkojen asetukset (paitsi ulkoiset verkot).
Mikä on OpenStack?
Kaikissa kolmessa vaihtoehdossa palveluntarjoaja tarvitsee käyttöjärjestelmän, joka mahdollistaa pilviinfrastruktuurin luomisen. Itse asiassa SaaS:ssa useampi kuin yksi divisioona on vastuussa koko teknologiapinosta - on osasto, joka vastaa infrastruktuurista - eli se tarjoaa IaaS:n toiselle divisioonalle, tämä divisioona tarjoaa SaaS-asiakkaalle. OpenStack on yksi pilvikäyttöjärjestelmistä, jonka avulla voit kerätä joukon kytkimiä, palvelimia ja tallennusjärjestelmiä yhdeksi resurssipooliksi, jakaa tämän yhteisen poolin alipooliksi (vuokralaisiksi) ja tarjota nämä resurssit asiakkaille verkon kautta.
OpenStack on pilvikäyttöjärjestelmä, jonka avulla voit hallita suuria laskentaresurssien, tietojen tallennus- ja verkkoresurssien pooleja, jotka on provisioitu ja hallittu API:n kautta käyttämällä tavallisia todennusmekanismeja.
Toisin sanoen tämä on joukko ilmaisia ohjelmistoprojekteja, jotka on suunniteltu luomaan pilvipalveluita (sekä julkisia että yksityisiä) - toisin sanoen joukko työkaluja, joiden avulla voit yhdistää palvelin- ja kytkentälaitteet yhdeksi resurssipooliksi, hallita nämä resurssit, jotka tarjoavat tarvittavan vikasietotason .
Tätä materiaalia kirjoitettaessa OpenStack-rakenne näyttää tältä:
Kuva otettu kohteesta
Jokainen OpenStackin komponentti suorittaa tietyn toiminnon. Tämän hajautetun arkkitehtuurin avulla voit sisällyttää ratkaisuun tarvitsemasi toiminnalliset komponentit. Jotkut komponentit ovat kuitenkin juurikomponentteja ja niiden poistaminen johtaa koko ratkaisun täydelliseen tai osittaiseen toimintakyvyttömyyteen. Nämä komponentit luokitellaan yleensä seuraavasti:
- koontinäyttöön. — Web-pohjainen käyttöliittymä OpenStack-palvelujen hallintaan
- Lakikivi on keskitetty identiteettipalvelu, joka tarjoaa todennus- ja valtuutustoiminnot muille palveluille sekä käyttäjien tunnistetietojen ja roolien hallintaan.
- neutroni - verkkopalvelu, joka tarjoaa liitettävyyden eri OpenStack-palveluiden rajapintojen välille (mukaan lukien liitettävyys virtuaalikoneiden välillä ja niiden pääsy ulkomaailmaan)
- kuona - tarjoaa pääsyn virtuaalikoneiden lohkotallennustilaan
- Nova — virtuaalikoneiden elinkaaren hallinta
- silmäys — virtuaalikoneen kuvien ja tilannekuvien arkisto
- Nopea — tarjoaa pääsyn tallennusobjektiin
- pilvenkorkeusmittari — Palvelu, joka tarjoaa mahdollisuuden kerätä telemetriaa ja mitata käytettävissä olevia ja kulutettuja resursseja
- Lämpö — resurssien automaattista luomista ja tarjoamista varten tarkoitettuihin malleihin perustuva orkestrointi
Täydellinen luettelo kaikista projekteista ja niiden tarkoituksesta on nähtävissä .
Jokainen OpenStack-komponentti on palvelu, joka suorittaa tietyn toiminnon ja tarjoaa API:n toiminnon hallintaan ja vuorovaikutukseen muiden pilvikäyttöjärjestelmäpalvelujen kanssa yhtenäisen infrastruktuurin luomiseksi. Esimerkiksi Nova tarjoaa laskentaresurssien hallinnan ja API:n näiden resurssien määrittämiseen, Glance tarjoaa kuvanhallinnan ja API:n niiden hallintaan, Cinder tarjoaa lohkotallennustilan ja API:n sen hallintaan jne. Kaikki toiminnot ovat hyvin tiiviisti yhteydessä toisiinsa.
Kuitenkin, jos katsot sitä, kaikki OpenStackissa käynnissä olevat palvelut ovat viime kädessä jonkinlainen virtuaalikone (tai kontti), joka on kytketty verkkoon. Herää kysymys - miksi tarvitsemme niin monia elementtejä?
Käydään läpi algoritmi virtuaalikoneen luomiseksi ja sen liittämiseksi verkkoon ja pysyvään tallennustilaan Openstackissa.
- Kun luot koneen luomispyynnön, olipa se sitten pyyntö Horizonin (Dashboard) kautta tai pyyntö CLI:n kautta, ensimmäinen asia, joka tapahtuu, on pyyntösi valtuutus Keystonessa - voitko luoda koneen, onko sillä oikeus käyttää tätä verkkoa, tekee kiintiösi luonnos jne.
- Keystone todentaa pyyntösi ja luo vastausviestiin todennustunnuksen, jota käytetään edelleen. Keystonen vastauksen saatuaan pyyntö lähetetään Novaan (nova api).
- Nova-api tarkistaa pyyntösi oikeellisuuden ottamalla yhteyttä Keystoneen käyttämällä aiemmin luotua todennustunnusta
- Keystone suorittaa todennuksen ja antaa tietoja luvista ja rajoituksista tämän todennustunnuksen perusteella.
- Nova-api luo merkinnän uudelle VM:lle nova-tietokannassa ja välittää koneen luomispyynnön nova-schedulerille.
- Nova-scheduler valitsee määritettyjen parametrien, painojen ja vyöhykkeiden perusteella isännän (tietokonesolmun), johon VM otetaan käyttöön. Tietue tästä ja VM-tunnus kirjoitetaan nova-tietokantaan.
- Seuraavaksi nova-scheduler ottaa yhteyttä nova-computeen ja pyytää ottaa käyttöön ilmentymä. Nova-compute ottaa yhteyttä nova-conductoriin saadakseen tietoja koneparametreista (nova-conductor on nova-elementti, joka toimii välityspalvelimena nova-tietokannan ja nova-computen välillä rajoittaen nova-tietokannan pyyntöjen määrää tietokannan ongelmien välttämiseksi sakeuden kuormituksen vähentäminen).
- Nova-conductor vastaanottaa pyydetyt tiedot nova-tietokannasta ja välittää ne nova-computeille.
- Seuraavaksi nova-compute-kutsut saavat kuvatunnuksen. Glace vahvistaa pyynnön Keystonessa ja palauttaa pyydetyt tiedot.
- Nova-compute ottaa yhteyttä neutroniin saadakseen tietoa verkon parametreista. Samoin kuin vilkaisu, neutroni vahvistaa pyynnön Keystonessa, minkä jälkeen se luo tietokantaan merkinnän (portin tunniste jne.), luo pyynnön portin luomiseksi ja palauttaa pyydetyt tiedot nova-computeille.
- Nova-compute ottaa yhteyttä cinderiin ja pyytää varaamaan tilavuus virtuaalikoneen. Vilkaisun tapaan siideri vahvistaa pyynnön Keystonessa, luo talteenluontipyynnön ja palauttaa pyydetyt tiedot.
- Nova-compute ottaa yhteyttä libvirtiin ja pyytää ottamaan käyttöön virtuaalikoneen määritetyillä parametreilla.
Itse asiassa näennäisen yksinkertainen toimenpide yksinkertaisen virtuaalikoneen luomiseksi muuttuu sellaiseksi API-kutsujen pyörteeksi pilvialustan elementtien välillä. Lisäksi, kuten näet, myös aiemmin nimetyt palvelut koostuvat myös pienempiä komponentteja, joiden välillä tapahtuu vuorovaikutusta. Koneen luominen on vain pieni osa siitä, mitä pilvialustan avulla voit tehdä - on palvelu, joka vastaa liikenteen tasapainottamisesta, palvelu, joka vastaa lohkotallennuksesta, palvelu, joka vastaa DNS-palvelusta, palvelu, joka vastaa paljasmetallipalvelimien provisiosta jne. . Pilven avulla voit käsitellä virtuaalikoneitasi kuin lammaslaumaa (toisin kuin virtualisoinnissa). Jos koneellesi tapahtuu jotain virtuaaliympäristössä - palautat sen varmuuskopioista tms., mutta pilvisovellukset on rakennettu niin, että virtuaalikoneella ei ole niin tärkeää roolia - virtuaalikone "kuoli" - ei hätää - uusi luodaan yksinkertaisesti, ajoneuvo perustuu malliin, ja kuten sanotaan, joukkue ei huomannut hävittäjän menetystä. Luonnollisesti tämä mahdollistaa orkestrointimekanismien olemassaolon - käyttämällä Heat-malleja, voit helposti ottaa käyttöön monimutkaisen toiminnon, joka koostuu kymmenistä verkoista ja virtuaalikoneista.
Aina kannattaa pitää mielessä, ettei pilviinfrastruktuuria ole ilman verkkoa – jokainen elementti tavalla tai toisella on vuorovaikutuksessa muiden elementtien kanssa verkon kautta. Lisäksi pilvessä on täysin ei-staattinen verkko. Luonnollisesti pohjaverkko on enemmän tai vähemmän staattinen - uusia solmuja ja kytkimiä ei lisätä joka päivä, mutta peittokomponentti voi ja tulee väistämättä muuttumaan jatkuvasti - uusia verkkoja lisätään tai poistetaan, uusia virtuaalikoneita ilmestyy ja vanhoja kuolla. Ja kuten artikkelin alussa annetusta pilven määritelmästä muistat, resurssit tulisi allokoida käyttäjälle automaattisesti ja vähimmällä (tai vielä parempaa, ilman) palveluntarjoajan puuttumista asiaan. Toisin sanoen verkkoresurssien tarjoamisen tyyppi, joka on nyt olemassa käyttöliittymän muodossa henkilökohtaisen tilisi muodossa, johon pääsee http/https:n kautta ja päivystävä verkkoinsinööri Vasily taustajärjestelmänä, ei ole pilvi, edes jos Vasililla on kahdeksan kättä.
Neutron tarjoaa verkkopalveluna API:n pilviinfrastruktuurin verkko-osan hallintaan. Palvelu toimii ja hallitsee Openstackin verkko-osaa tarjoamalla abstraktiokerroksen nimeltä Network-as-a-Service (NaaS). Eli verkko on sama virtuaalinen mittausyksikkö kuin esimerkiksi virtuaaliset CPU-ytimet tai RAM-muistin määrä.
Mutta ennen kuin siirrymme OpenStackin verkko-osan arkkitehtuuriin, pohditaan kuinka tämä verkko toimii OpenStackissa ja miksi verkko on tärkeä ja olennainen osa pilveä.
Meillä on siis kaksi RED-asiakas-VM:tä ja kaksi GREEN-asiakas-VM:tä. Oletetaan, että nämä koneet sijaitsevat kahdella hypervisorilla tällä tavalla:
Tällä hetkellä tämä on vain 4 palvelimen virtualisointi eikä mitään muuta, koska tähän mennessä olemme tehneet vain neljän palvelimen virtualisoinnin ja sijoittamisen kahdelle fyysiselle palvelimelle. Ja toistaiseksi niitä ei ole edes kytketty verkkoon.
Pilven luomiseksi meidän on lisättävä useita komponentteja. Ensin virtualisoimme verkko-osan - meidän täytyy yhdistää nämä 4 konetta pareittain, ja asiakkaat haluavat L2-yhteyden. Voit käyttää kytkintä ja määrittää rungon sen suuntaan ja ratkaista kaiken käyttämällä linux-siltaa tai edistyneemmille käyttäjille openvswitchiä (palaamme tähän myöhemmin). Mutta verkkoja voi olla monia, eikä L2:n jatkuva työntäminen kytkimen kautta ole paras idea - siellä on eri osastoja, palvelupiste, kuukausia odottavan hakemuksen valmistumista, viikkoja vianmääritystä - nykymaailmassa tämä lähestymistapa ei enää toimi. Ja mitä nopeammin yritys ymmärtää tämän, sitä helpompi sen on edetä. Siksi valitsemme hypervisorien välillä L3-verkon, jonka kautta virtuaalikoneemme kommunikoivat, ja tämän L3-verkon päälle rakennamme virtuaalisia L2-overlay-verkkoja, joissa virtuaalikoneiden liikenne kulkee. Voit käyttää GRE:tä, Geneveä tai VxLAN:ia kapselointina. Keskitytään nyt jälkimmäiseen, vaikka se ei ole erityisen tärkeä.
Meidän on löydettävä VTEP jostain (toivottavasti kaikki tuntevat VxLAN-terminologian). Koska meillä on L3-verkko, joka tulee suoraan palvelimilta, mikään ei estä meitä sijoittamasta VTEP:tä itse palvelimille, ja OVS (OpenvSwitch) on tässä erinomainen. Tuloksena saimme tämän mallin:
Koska virtuaalikoneiden välinen liikenne on jaettava, virtuaalikoneita kohti olevilla porteilla on eri vlan-numerot. Tunnistenumerolla on rooli vain yhdessä virtuaalikytkimen sisällä, koska VxLANiin kapseloituna voimme helposti poistaa sen, koska meillä on VNI.
Nyt voimme luoda heille koneemme ja virtuaaliverkkomme ilman ongelmia.
Entä jos asiakkaalla on toinen kone, mutta se on eri verkossa? Tarvitsemme juurtumista verkkojen välillä. Tarkastellaan yksinkertaista vaihtoehtoa, kun käytetään keskitettyä reititystä - eli liikenne reititetään erityisten omistettujen verkkosolmujen kautta (no, yleensä ne yhdistetään ohjaussolmuihin, joten meillä on sama asia).
Ei näytä olevan mitään monimutkaista - teemme ohjaussolmuun siltarajapinnan, ohjaamme liikennettä siihen ja sieltä reititämme sen sinne, missä sitä tarvitsemme. Mutta ongelmana on, että RED-asiakas haluaa käyttää 10.0.0.0/24-verkkoa ja GREEN-asiakas haluaa käyttää 10.0.0.0/24-verkkoa. Toisin sanoen alamme leikkaamaan osoiteavaruuksia. Lisäksi asiakkaat eivät halua muiden asiakkaiden reitittävän heidän sisäisiin verkkoihinsa, mikä on järkevää. Jotta verkko- ja asiakastietoliikenne voidaan erottaa toisistaan, varaamme kullekin erillisen nimiavaruuden. Nimiavaruus on itse asiassa kopio Linuxin verkkopinosta, eli nimiavaruuden RED asiakkaat ovat täysin eristettyjä nimiavaruuden VIHREÄN asiakkaista (no, joko reititys näiden asiakasverkkojen välillä on sallittu oletusnimiavaruuden kautta tai ylävirran siirtolaitteissa).
Eli saamme seuraavan kaavion:
L2-tunnelit konvergoivat kaikista laskentasolmuista ohjaussolmuun. solmu, jossa näiden verkkojen L3-liitäntä sijaitsee, kukin omassa nimiavaruudessa eristämistä varten.
Unohdimme kuitenkin tärkeimmän. Virtuaalikoneen tulee tarjota asiakkaalle palvelu, eli sillä on oltava vähintään yksi ulkoinen rajapinta, jonka kautta se on tavoitettavissa. Eli meidän täytyy mennä ulos ulkomaailmaan. Täällä on erilaisia vaihtoehtoja. Tehdään yksinkertaisin vaihtoehto. Lisäämme jokaiseen asiakkaaseen yhden verkon, joka on voimassa palveluntarjoajan verkossa eikä mene päällekkäin muiden verkkojen kanssa. Verkot voivat myös leikata ja tarkastella erilaisia VRF:itä palveluntarjoajan verkon puolella. Verkkotiedot pysyvät myös jokaisen asiakkaan nimiavaruudessa. He kuitenkin menevät ulos ulkomaailmaan yhden fyysisen (tai loogisemman) käyttöliittymän kautta. Asiakasliikenteen erottamiseksi ulkopuolelle menevä liikenne merkitään asiakkaalle allokoidulla VLAN-tunnisteella.
Tuloksena saimme tämän kaavion:
Järkevä kysymys on, miksi ei tehdä yhdyskäytäviä itse laskentasolmuihin? Tämä ei ole suuri ongelma; lisäksi, jos otat käyttöön hajautetun reitittimen (DVR), tämä toimii. Tässä skenaariossa harkitsemme yksinkertaisinta vaihtoehtoa keskitetyllä yhdyskäytävällä, jota käytetään oletuksena Openstackissa. Korkean kuormituksen toiminnoissa he käyttävät sekä hajautettua reititintä että kiihdytystekniikoita, kuten SR-IOV ja Passthrough, mutta kuten he sanovat, se on täysin erilainen tarina. Ensin käsitellään perusosaa ja sitten mennään yksityiskohtiin.
Itse asiassa järjestelmämme on jo toimiva, mutta siinä on pari vivahdetta:
- Meidän on jotenkin suojattava koneitamme, eli laitettava suodatin kytkimen käyttöliittymään asiakasta kohti.
- Anna virtuaalikoneen saada automaattisesti IP-osoite, jotta sinun ei tarvitse joka kerta kirjautua sisään konsolin kautta ja rekisteröidä osoitetta.
Aloitetaan koneen suojauksesta. Tätä varten voit käyttää banaalista iptablesia, miksi ei.
Eli nyt topologiastamme on tullut hieman monimutkaisempi:
Siirrytään eteenpäin. Meidän on lisättävä DHCP-palvelin. Ihanteellisin paikka DHCP-palvelimien paikantamiseen jokaiselle asiakkaalle on jo edellä mainittu ohjaussolmu, jossa nimitilat sijaitsevat:
Pieni ongelma kuitenkin on. Entä jos kaikki käynnistyy uudelleen ja kaikki tiedot osoitteiden vuokraamisesta DHCP:llä katoavat. On loogista, että koneille annetaan uudet osoitteet, mikä ei ole kovin kätevää. Tästä on kaksi ulospääsyä - joko käytä verkkotunnuksia ja lisää DNS-palvelin jokaiselle asiakkaalle, niin osoite ei ole meille erityisen tärkeä (samanlainen kuin k8s:n verkko-osa) - mutta ulkoisissa verkoissa on ongelma, koska osoitteita voidaan antaa myös niissä DHCP:n kautta - tarvitset synkronoinnin pilvialustan DNS-palvelimien ja ulkoisen DNS-palvelimen kanssa, mikä ei mielestäni ole kovin joustavaa, mutta täysin mahdollista. Tai toinen vaihtoehto on käyttää metatietoja - eli tallentaa tiedot koneelle annetusta osoitteesta, jotta DHCP-palvelin tietää, mikä osoite antaa koneelle, jos kone on jo saanut osoitteen. Toinen vaihtoehto on yksinkertaisempi ja joustavampi, koska sen avulla voit tallentaa lisätietoja autosta. Lisätään nyt agentin metatiedot kaavioon:
Toinen keskustelun arvoinen asia on kaikkien asiakkaiden mahdollisuus käyttää yhtä ulkoista verkkoa, koska ulkoiset verkot, jos niiden on oltava voimassa koko verkossa, ovat vaikeita - sinun on jatkuvasti allokoitava ja valvottava näiden verkkojen allokointia. Mahdollisuus käyttää yhtä ulkoista esikonfiguroitua verkkoa kaikille asiakkaille on erittäin hyödyllistä luotaessa julkista pilveä. Tämä helpottaa koneiden käyttöönottoa, koska meidän ei tarvitse etsiä osoitetietokantaa ja valita yksilöllistä osoiteavaruutta kullekin asiakkaan ulkoiselle verkolle. Lisäksi voimme rekisteröidä ulkoisen verkon etukäteen ja käyttöönoton yhteydessä tarvitsemme vain liittää ulkoiset osoitteet asiakaskoneisiin.
Ja tässä NAT tulee avuksemme - annamme asiakkaille vain mahdollisuuden päästä ulkomaailmaan oletusnimiavaruuden kautta käyttämällä NAT-käännöstä. No, tässä on pieni ongelma. Tämä on hyvä, jos asiakaspalvelin toimii asiakkaana eikä palvelimena - eli se aloittaa yhteydet mieluummin kuin hyväksyy. Mutta meille se tulee olemaan päinvastoin. Tässä tapauksessa meidän on tehtävä kohde-NAT, jotta liikennettä vastaanottaessaan ohjaussolmu ymmärtää, että tämä liikenne on tarkoitettu asiakkaan A virtuaalikoneelle A, mikä tarkoittaa, että meidän on tehtävä NAT-käännös ulkoisesta osoitteesta, esimerkiksi 100.1.1.1. .10.0.0.1, sisäiseen osoitteeseen 100. Tässä tapauksessa, vaikka kaikki asiakkaat käyttävät samaa verkkoa, sisäinen eristys säilyy täysin. Eli meidän on tehtävä dNAT ja sNAT ohjaussolmussa. Se, käytetäänkö yhtä verkkoa kelluvilla osoitteilla vai ulkoisia verkkoja vai molempia kerralla, riippuu siitä, mitä haluat tuoda pilveen. Emme lisää kelluvia osoitteita kaavioon, vaan jätämme jo aiemmin lisätyt ulkoiset verkot - jokaisella asiakkaalla on oma ulkoinen verkko (kaaviossa ne on merkitty vlan 200 ja XNUMX ulkoisessa rajapinnassa).
Tuloksena saimme mielenkiintoisen ja samalla hyvin harkitun ratkaisun, jossa on tietty joustavuus, mutta jossa ei vielä ole vikasietomekanismia.
Ensinnäkin meillä on vain yksi ohjaussolmu - sen vika johtaa kaikkien järjestelmien romahtamiseen. Tämän ongelman korjaamiseksi sinun on muodostettava vähintään 3 solmun päätösvaltaisuus. Lisätään tämä kaavioon:
Luonnollisesti kaikki solmut ovat synkronoituja ja kun aktiivinen solmu lähtee, toinen solmu ottaa sen vastuut.
Seuraava ongelma on virtuaalikoneen levyt. Tällä hetkellä ne tallennetaan itse hypervisoreihin, ja jos hypervisorilla on ongelmia, menetämme kaikki tiedot - ja raidin läsnäolo ei auta tässä, jos emme menetä levyä, vaan koko palvelimen. Tätä varten meidän on tehtävä palvelu, joka toimii jonkinlaisen tallennustilan etupäänä. Se, millainen tallennustila siitä tulee, ei ole meille erityisen tärkeää, mutta sen pitäisi suojata tietojamme sekä levyn että solmun ja mahdollisesti koko kaapin vioilta. Tässä on useita vaihtoehtoja - tietysti on olemassa SAN-verkkoja kuitukanavalla, mutta olkaamme rehellisiä - FC on jo jäänne menneisyydestä - E1:n analogi liikenteessä - kyllä, olen samaa mieltä, sitä käytetään edelleen, mutta vain siellä, missä se on täysin mahdotonta ilman sitä. En siis ottaisi vapaaehtoisesti käyttöön FC-verkkoa vuonna 2020, tietäen, että muitakin kiinnostavampia vaihtoehtoja on olemassa. Vaikka jokaiselle omansa, saattaa olla niitä, jotka uskovat, että FC kaikkine rajoitteineen on kaikki mitä tarvitsemme - en kiistä, jokaisella on oma mielipiteensä. Mielenkiintoisin ratkaisu on kuitenkin mielestäni käyttää SDS:ää, kuten Ceph.
Cephin avulla voit rakentaa erittäin saatavilla olevan tiedontallennusratkaisun, jossa on joukko mahdollisia varmuuskopiointivaihtoehtoja, alkaen koodeista, joissa on pariteettitarkistus (analogisesti raid 5:n tai 6:n kanssa) ja päättyen täydelliseen tietojen replikointiin eri levyille, ottaen huomioon levyjen sijainnin palvelimet ja palvelimet kaapeissa jne.
Cephin rakentamiseen tarvitaan vielä 3 solmua. Vuorovaikutus tallennustilan kanssa tapahtuu myös verkon kautta käyttämällä lohko-, objekti- ja tiedostotallennuspalveluita. Lisätään tallennustilaa skeemaan:
Huomaa: voit myös tehdä hyperkonvergoituja laskentasolmuja - tämä on useiden toimintojen yhdistäminen yhdessä solmussa - esimerkiksi tallennus+laskenta - ilman erityisiä solmuja varaamatta Ceph-tallennusta. Saamme saman vikasietoisen järjestelmän - koska SDS varaa tiedot määrittelemällämme varaustasolla. Hyperkonvergoidut solmut ovat kuitenkin aina kompromissi - koska tallennussolmu ei vain lämmitä ilmaa miltä ensi silmäyksellä näyttää (koska siinä ei ole virtuaalikoneita) - se käyttää prosessoriresursseja SDS:n huoltoon (itse asiassa se tekee kaiken replikointi ja palautus solmujen, levyjen jne. vikojen jälkeen). Eli menetät osan laskentasolmun tehosta, jos yhdistät sen tallennustilaan.
Kaikkea tätä asiaa pitää jotenkin hallita - tarvitsemme jotain, jonka kautta voimme luoda koneen, verkon, virtuaalisen reitittimen jne. Tätä varten lisäämme ohjaussolmuun palvelun, joka toimii kojelautana - asiakas voi muodostaa yhteyden tähän portaaliin http/https:n kautta ja tehdä kaiken tarvitsemansa (no, melkein).
Tämän seurauksena meillä on nyt vikasietoinen järjestelmä. Kaikki tämän infrastruktuurin elementit on hallittava jollakin tavalla. Aiemmin kuvattiin, että Openstack on joukko projekteja, joista jokainen tarjoaa tietyn toiminnon. Kuten näemme, on enemmän kuin tarpeeksi elementtejä, jotka on määritettävä ja ohjattava. Tänään puhumme verkko-osasta.
Neutroniarkkitehtuuri
OpenStackissa Neutron on vastuussa virtuaalikoneen porttien yhdistämisestä yhteiseen L2-verkkoon, liikenteen reitittämisen varmistamisesta eri L2-verkoissa sijaitsevien virtuaalikoneiden välillä sekä ulospäin suuntautuvasta reitityksestä tarjoamalla palveluita, kuten NAT, Floating IP, DHCP jne.
Korkealla tasolla verkkopalvelun (perusosan) toimintaa voidaan kuvata seuraavasti.
Kun käynnistät VM:n, verkkopalvelu:
- Luo portin tietylle VM:lle (tai porteille) ja ilmoittaa siitä DHCP-palvelulle;
- Uusi virtuaalinen verkkolaite luodaan (libvirtin kautta);
- Virtuaalinen kone muodostaa yhteyden vaiheessa 1 luotuihin portteihin;
Kummallista kyllä, Neutronin työ perustuu vakiomekanismeihin, jotka ovat tuttuja kaikille Linuxiin koskaan sukeltaneille - nimiavaruille, iptablesille, linux-sillalle, openvswitchille, conntrackille jne.
On heti selvennettävä, että Neutron ei ole SDN-ohjain.
Neutroni koostuu useista toisiinsa liittyvistä komponenteista:
Openstack-neutroni-palvelin on demoni, joka toimii käyttäjien pyyntöjen kanssa API:n kautta. Tämä demoni ei ole mukana minkään verkkoyhteyksien rekisteröimisessä, mutta antaa tätä varten tarvittavat tiedot plugineilleen, jotka sitten määrittävät halutun verkkoelementin. OpenStack-solmujen neutroniagentit rekisteröityvät Neutron-palvelimeen.
Neutron-palvelin on itse asiassa pythonilla kirjoitettu sovellus, joka koostuu kahdesta osasta:
- REST palvelu
- Neutron Plugin (ydin/palvelu)
REST-palvelu on suunniteltu vastaanottamaan API-kutsuja muista komponenteista (esimerkiksi pyyntö antaa tietoja jne.)
Pluginit ovat laajennusohjelmistokomponentteja/moduuleja, joita kutsutaan API-pyyntöjen aikana – eli palvelun antaminen tapahtuu niiden kautta. Pluginit on jaettu kahteen tyyppiin - palvelu ja root. Pääsääntöisesti hevonen-laajennus vastaa pääosin osoiteavaruuden ja L2-yhteyksien hallinnasta VM:ien välillä, ja palvelulaajennukset tarjoavat jo lisätoimintoja, kuten VPN tai FW.
Nykyään saatavilla olevien lisäosien luetteloa voi tarkastella esimerkiksi
Palvelulaajennuksia voi olla useita, mutta hevoslaajennuksia voi olla vain yksi.
openstack-neutron-ml2 on tavallinen Openstack-juurilaajennus. Tällä laajennuksella on modulaarinen arkkitehtuuri (toisin kuin edeltäjänsä) ja se määrittää verkkopalvelun siihen kytkettyjen ohjainten kautta. Tarkastellaan itse laajennusta hieman myöhemmin, koska itse asiassa se antaa joustavuutta, joka OpenStackilla on verkko-osassa. Päälaajennus voidaan korvata (esimerkiksi Contrail Networking tekee tällaisen korvauksen).
RPC-palvelu (rabbitmq-palvelin) — palvelu, joka tarjoaa jononhallintaa ja vuorovaikutusta muiden OpenStack-palvelujen kanssa sekä verkkopalveluagenttien välistä vuorovaikutusta.
Verkkoagentit — agentit, jotka sijaitsevat kussakin solmussa ja joiden kautta verkkopalvelut konfiguroidaan.
Agentteja on useita tyyppejä.
Pääagentti on L2 agentti. Nämä agentit toimivat jokaisessa hypervisorissa, mukaan lukien ohjaussolmut (tarkemmin sanottuna kaikissa solmuissa, jotka tarjoavat mitä tahansa palvelua vuokralaisille), ja niiden päätehtävä on yhdistää virtuaalikoneita yhteiseen L2-verkkoon ja myös luoda hälytyksiä tapahtumien sattuessa ( esimerkiksi poista portti käytöstä/ota käyttöön).
Seuraava, yhtä tärkeä agentti on L3 agentti. Oletuksena tämä agentti toimii yksinomaan verkkosolmussa (usein verkkosolmu on yhdistetty ohjaussolmuun) ja tarjoaa reitityksen vuokralaisverkkojen välillä (sekä sen verkkojen että muiden vuokralaisten verkkojen välillä, ja se on ulkomaailman käytettävissä NAT sekä DHCP-palvelu). Kuitenkin käytettäessä DVR:ää (hajautettua reititintä), L3-liitännäisen tarve näkyy myös laskentasolmuissa.
L3-agentti käyttää Linuxin nimiavaruuksia tarjotakseen jokaiselle vuokralaiselle joukon omia eristettyjä verkkojaan ja virtuaalisten reitittimien toimintoja, jotka reitittävät liikennettä ja tarjoavat yhdyskäytäväpalveluita Layer 2 -verkoille.
tietokanta — tietokanta verkkojen, aliverkkojen, porttien, poolien jne. tunnisteista.
Itse asiassa Neutron hyväksyy API-pyynnöt minkä tahansa verkkoolioiden luomisesta, todentaa pyynnön ja lähettää RPC:n (jos se käyttää jotakin laajennusta tai agenttia) tai REST API:n (jos se kommunikoi SDN:ssä) kautta agenteille (laajennusten kautta) pyydetyn palvelun järjestämiseen tarvittavat ohjeet.
Siirrytään nyt testiasennukseen (miten se otetaan käyttöön ja mitä siihen sisältyy, näemme myöhemmin käytännön osassa) ja katsotaan, missä kukin komponentti sijaitsee:
(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 ~]$
Itse asiassa se on koko neutronin rakenne. Nyt kannattaa viettää aikaa ML2-laajennukseen.
Modulaarinen kerros 2
Kuten edellä mainittiin, laajennus on tavallinen OpenStack-juurilaajennus ja sillä on modulaarinen arkkitehtuuri.
ML2-laajennuksen edeltäjällä oli monoliittinen rakenne, mikä ei mahdollistanut esimerkiksi useiden teknologioiden yhdistelmän käyttämistä yhdessä asennuksessa. Et esimerkiksi voinut käyttää sekä openvswitchiä että linuxbridgeä samanaikaisesti – joko ensimmäistä tai toista. Tästä syystä luotiin ML2-laajennus arkkitehtuuriineen.
ML2:ssa on kaksi komponenttia - kahdentyyppisiä ajureita: tyyppiohjaimet ja mekanismiajurit.
Kirjoita ajurit määrittää tekniikat, joita käytetään verkkoyhteyksien järjestämiseen, esimerkiksi VxLAN, VLAN, GRE. Samalla kuljettaja mahdollistaa erilaisten teknologioiden käytön. Vakiotekniikka on VxLAN-kapselointi overlay-verkkoja ja vlan-ulkoisia verkkoja varten.
Tyyppiohjaimet sisältävät seuraavat verkkotyypit:
Tasainen - verkko ilman merkintää
VLAN - merkitty verkko
paikallinen — erityinen verkko all-in-one-asennuksia varten (tällaisia asennuksia tarvitaan joko kehittäjille tai koulutukseen)
GRE — peittää verkko GRE-tunneleilla
VxLAN — päällekkäinen verkko VxLAN-tunneleilla
Mekanismin ajurit määrittele työkalut, jotka varmistavat tyyppiohjaimessa määritettyjen teknologioiden organisoinnin - esimerkiksi openvswitch, sr-iov, opendaylight, OVN jne.
Tämän ajurin toteutuksesta riippuen käytetään joko Neutronin ohjaamia agentteja tai yhteyksiä ulkoiseen SDN-ohjaimeen, joka hoitaa kaikki L2-verkkojen järjestämiseen, reitittämiseen jne. liittyvät asiat.
Esimerkki: jos käytämme ML2:ta yhdessä OVS:n kanssa, L2-agentti asennetaan jokaiseen OVS:ää hallitsevaan laskentasolmuun. Kuitenkin, jos käytämme esimerkiksi OVN:ää tai OpenDayLightia, niin OVS:n hallinta kuuluu heidän lainkäyttövaltaan - Neutron antaa root-laajennuksen kautta komentoja ohjaimelle, ja se tekee jo sen, mitä sille käskettiin.
Käydään läpi Open vSwitch
Tällä hetkellä yksi OpenStackin avainkomponenteista on Open vSwitch.
Kun asennat OpenStackin ilman ylimääräistä toimittajan SDN:ää, kuten Juniper Contrailia tai Nokia Nuagea, OVS on pilviverkon pääverkkokomponentti ja yhdessä iptablesin, conntrackin ja nimiavaruuksien kanssa mahdollistaa täysimittaisten usean vuokrauksen peittoverkkojen järjestämisen. Luonnollisesti tämä komponentti voidaan korvata esimerkiksi käytettäessä kolmannen osapuolen omistamia (toimittajan) SDN-ratkaisuja.
OVS on avoimen lähdekoodin ohjelmistokytkin, joka on suunniteltu käytettäväksi virtualisoiduissa ympäristöissä virtuaalisena liikenteen välittäjänä.
Tällä hetkellä OVS:ssä on erittäin kunnollinen toiminnallisuus, joka sisältää teknologioita kuten QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK jne.
Huomautus: OVS:ää ei alun perin suunniteltu pehmeäksi kytkimeksi paljon kuormitettuja televiestintätoimintoja varten, ja se oli enemmän suunniteltu vähemmän kaistanleveyttä vaativiin IT-toimintoihin, kuten WEB-palvelimeen tai sähköpostipalvelimeen. OVS:ää kuitenkin kehitetään edelleen ja OVS:n nykyiset toteutukset ovat parantaneet huomattavasti sen suorituskykyä ja ominaisuuksia, mikä mahdollistaa sen käytön teleoperaattoreille, joilla on paljon kuormitettuja toimintoja, esimerkiksi olemassa on OVS-toteutus, joka tukee DPDK-kiihdytystä.
OVS:ssä on kolme tärkeää osaa, jotka sinun tulee olla tietoisia:
- Ytimen moduuli — ydintilassa oleva komponentti, joka käsittelee liikennettä ohjauselementiltä saatujen sääntöjen perusteella;
- vKytkin daemon (ovs-vswitchd) on käyttäjätilaan käynnistetty prosessi, joka on vastuussa ydinmoduulin ohjelmoinnista - eli se edustaa suoraan kytkimen toiminnan logiikkaa
- Tietokantapalvelin - paikallinen tietokanta, joka sijaitsee jokaisessa OVS-palvelimessa ja johon konfiguraatio on tallennettu. SDN-ohjaimet voivat kommunikoida tämän moduulin kautta käyttämällä OVSDB-protokollaa.
Kaikkeen tähän liittyy joukko diagnostiikka- ja hallintaapuohjelmia, kuten ovs-vsctl, ovs-appctl, ovs-ofctl jne.
Tällä hetkellä teleoperaattorit käyttävät Openstackia laajasti verkkotoimintojen, kuten EPC, SBC, HLR jne., siirtämiseen. Jotkut toiminnot voivat toimia ilman ongelmia OVS:n kanssa sellaisenaan, mutta esimerkiksi EPC käsittelee tilaajaliikennettä - sitten se kulkee valtava määrä liikennettä (nyt liikennemäärät saavuttavat useita satoja gigabittejä sekunnissa). Tietenkään tällaisen liikenteen ohjaaminen ydintilan läpi (koska huolitsija sijaitsee oletuksena siellä) ei ole paras idea. Siksi OVS otetaan usein käyttöön kokonaan käyttäjätilassa käyttämällä DPDK-kiihdytystekniikkaa liikenteen välittämiseksi verkkokortista käyttäjätilaan ohittaen ytimen.
Huomautus: tietoliikennetoimintoja varten käytettävässä pilvessä on mahdollista tulostaa liikennettä laskentasolmusta, joka ohittaa OVS:n, suoraan kytkentälaitteisiin. Tähän tarkoitukseen käytetään SR-IOV- ja Passthrough-mekanismeja.
Miten tämä toimii todellisessa ulkoasussa?
No, siirrytään nyt käytännön osaan ja katsotaan kuinka kaikki toimii käytännössä.
Otetaan ensin käyttöön yksinkertainen Openstack-asennus. Koska minulla ei ole käden ulottuvilla palvelinsarjoja kokeiluja varten, kokoamme prototyypin yhdelle fyysiselle palvelimelle virtuaalikoneista. Kyllä, kaupallisiin tarkoituksiin tällainen ratkaisu ei tietenkään sovi, mutta nähdäksesi esimerkin verkon toiminnasta Openstackissa, tällainen asennus riittää silmille. Lisäksi tällainen asennus on vielä mielenkiintoisempi koulutustarkoituksiin - koska voit saada liikennettä jne.
Koska meidän tarvitsee nähdä vain perusosa, emme voi käyttää useita verkkoja, vaan nostaa kaikkea käyttämällä vain kahta verkkoa, ja toista verkkoa tässä asetelmassa käytetään yksinomaan pääsyyn undercloud- ja DNS-palvelimeen. Emme kosketa ulkoisia verkkoja toistaiseksi - tämä on erillisen suuren artikkelin aihe.
Aloitetaan siis järjestyksessä. Ensin vähän teoriaa. Asennamme Openstackin käyttämällä TripleO:ta (Openstack Openstackissa). TripleO:n ydin on, että asennamme Openstackin all-in-one-laitteen (eli yhteen solmuun), jota kutsutaan undercloudiksi, ja käytämme sitten käyttöönotetun Openstackin ominaisuuksia asentaaksemme käyttöön tarkoitetun Openstackin, jota kutsutaan overcloudiksi. Undercloud käyttää luontaista kykyään hallita fyysisiä palvelimia (paljas metalli) - Ironic-projekti - tarjotakseen hypervisoreita, jotka suorittavat laskenta-, ohjaus- ja tallennussolmujen rooleja. Toisin sanoen emme käytä mitään kolmannen osapuolen työkaluja Openstackin käyttöönotossa - otamme Openstackin käyttöön Openstackin avulla. Se selkenee paljon asennuksen edetessä, joten emme pysähdy tähän vaan jatkamme eteenpäin.
Huomautus: Tässä artikkelissa en yksinkertaisuuden vuoksi käyttänyt verkon eristämistä sisäisille Openstack-verkoille, mutta kaikki otetaan käyttöön vain yhdellä verkkolla. Verkkoeristyksen olemassaolo tai puuttuminen ei kuitenkaan vaikuta ratkaisun perustoimintoihin - kaikki toimii täsmälleen samalla tavalla kuin eristystä käytettäessä, mutta liikenne kulkee samassa verkossa. Kaupallisessa asennuksessa on luonnollisesti tarpeen käyttää eristystä käyttämällä erilaisia vlaneja ja rajapintoja. Esimerkiksi ceph-tallennushallinnan liikenne ja itse dataliikenne (konepääsy levyille jne.) käyttävät erillään eri aliverkkoja (Storage management ja Storage) ja tämän avulla voit tehdä ratkaisusta vikasietoisemman esimerkiksi jakamalla tämän liikenteen. , eri porttien yli tai käyttämällä erilaisia QoS-profiileja eri liikenteelle, jotta dataliikenne ei purista pois signalointiliikennettä. Meidän tapauksessamme ne menevät samaan verkkoon, eikä tämä itse asiassa rajoita meitä millään tavalla.
Huomautus: Koska aiomme käyttää virtuaalikoneita virtuaaliympäristössä, joka perustuu virtuaalikoneen, meidän on ensin otettava käyttöön sisäkkäinen virtualisointi.
Voit tarkistaa, onko sisäkkäinen virtualisointi käytössä vai ei, seuraavasti:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Jos näet kirjaimen N, otamme käyttöön sisäkkäisen virtualisoinnin tuen minkä tahansa verkosta löytämäsi oppaan mukaan, esim. .
Meidän on koottava virtuaalikoneista seuraava piiri:
Minun tapauksessani yhdistäessäni virtuaalikoneita, jotka ovat osa tulevaa asennusta (ja minulla oli niitä 7, mutta selviät neljällä, jos sinulla ei ole paljon resursseja), käytin OpenvSwitchiä. Loin yhden ovs-sillan ja liitin siihen virtuaalikoneita porttiryhmien kautta. Tätä varten loin seuraavanlaisen xml-tiedoston:
[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>Täällä ilmoitetaan kolme porttiryhmää - kaksi pääsyä ja yksi runko (jälkimmäinen tarvittiin DNS-palvelimelle, mutta voit tehdä ilman sitä tai asentaa sen isäntäkoneeseen - kumpi on sinulle kätevämpi). Seuraavaksi tämän mallin avulla ilmoitamme omamme virsh net-definen kautta:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nyt muokkaamme hypervisor-portin määrityksiä:
[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 ~]# Huomautus: tässä skenaariossa portin ovs-br1 osoite ei ole käytettävissä, koska siinä ei ole vlan-tunnistetta. Korjataksesi tämän, sinun on annettava komento sudo ovs-vsctl set port ovs-br1 tag=100. Uudelleenkäynnistyksen jälkeen tämä tagi kuitenkin katoaa (jos joku tietää kuinka saada se pysymään paikallaan, olen erittäin kiitollinen). Mutta tämä ei ole niin tärkeää, koska tarvitsemme tämän osoitteen vain asennuksen aikana emmekä tarvitse sitä, kun Openstack on täysin käytössä.
Seuraavaksi luomme pilvikoneen:
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=ttyS0Asennuksen aikana asetat kaikki tarvittavat parametrit, kuten koneen nimen, salasanat, käyttäjät, ntp-palvelimet jne., portit voi heti konfiguroida, mutta minulle henkilökohtaisesti asennuksen jälkeen on helpompi kirjautua sisään koneeseen kautta. konsoliin ja korjaa tarvittavat tiedostot. Jos sinulla on jo valmis kuva, voit käyttää sitä tai tehdä niin kuin minä tein - lataa minimaalinen Centos 7 -kuva ja käytä sitä VM:n asentamiseen.
Onnistuneen asennuksen jälkeen sinulla pitäisi olla virtuaalikone, johon voit asentaa Undercloud-sovelluksen
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningAsenna ensin asennusprosessissa tarvittavat työkalut:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud asennus
Luomme pinon käyttäjän, asetamme salasanan, lisäämme sen sudoeriin ja annamme hänelle mahdollisuuden suorittaa root-komentoja sudon kautta ilman salasanaa:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNyt määritämme koko undercloud-nimen hosts-tiedostossa:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Seuraavaksi lisäämme arkistot ja asennamme tarvitsemamme ohjelmiston:
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-ansibleHuomautus: jos et aio asentaa cephiä, sinun ei tarvitse antaa cephiin liittyviä komentoja. Käytin Queens-julkaisua, mutta voit käyttää mitä tahansa muuta kuin haluat.
Kopioi seuraavaksi undercloud-määritystiedosto käyttäjän kotihakemistopinoon:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNyt meidän on korjattava tämä tiedosto mukauttamalla se asennukseemme.
Sinun on lisättävä seuraavat rivit tiedoston alkuun:
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 = 10Käydään siis asetukset läpi:
undercloud_isäntänimi — Undercloud-palvelimen koko nimen on vastattava DNS-palvelimen merkintää
local_ip — paikallinen alipilviosoite verkon hallintaan
verkkoyhdyskäytävä — sama paikallinen osoite, joka toimii yhdyskäytävänä ulkomaailmaan pääsylle overcloud-solmujen asennuksen aikana, on myös sama kuin paikallisen IP:n
undercloud_public_host — ulkoinen API-osoite, mikä tahansa vapaa osoite hallintaverkosta määritetään
undercloud_admin_host sisäinen API-osoite, kaikki vapaat osoitteet hallintaverkosta määritetään
undercloud_nameservers - DNS-palvelin
gener_service_certificate - tämä rivi on erittäin tärkeä nykyisessä esimerkissä, koska jos et aseta sitä arvoon false, saat virheilmoituksen asennuksen aikana, ongelma on kuvattu Red Hat -virheenseurantaohjelmassa
paikallinen_käyttöliittymä rajapinta verkon provisiointiin. Tämä käyttöliittymä määritetään uudelleen undercloud-asennuksen aikana, joten sinulla on oltava kaksi rajapintaa Undercloudissa - yksi pääsyä varten, toinen hallintaa varten.
local_mtu - MTU. Koska meillä on testilaboratorio ja minulla on MTU 1500 OVS-kytkinporteissa, on tarpeen asettaa se arvoon 1450, jotta VxLANiin kapseloidut paketit pääsevät läpi.
verkko_cidr — provisiointiverkko
naamiaiset — NAT:n käyttö ulkoiseen verkkoon pääsyyn
masquerade_network - verkko, joka on NATed
dhcp_start - osoitevarannon aloitusosoite, josta osoitteet osoitetaan solmuille ylipilven käyttöönoton aikana
dhcp_end — sen osoitevarannon lopullinen osoite, josta osoitteet osoitetaan solmuille ylipilven käyttöönoton aikana
check_iprange — itsetutkiskelua varten tarvittava osoitevalikoima (ei saisi olla päällekkäinen yllä olevan ryhmän kanssa)
scheduler_max_attempts — ylipilven asennusyritysten enimmäismäärä (on oltava suurempi tai yhtä suuri kuin solmujen lukumäärä)
Kun tiedosto on kuvattu, voit antaa komennon ottaa käyttöön undercloud:
openstack undercloud install
Toimenpide kestää 10-30 minuuttia silitysraudoistasi riippuen. Loppujen lopuksi sinun pitäisi nähdä seuraavanlainen tulos:
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.
#############################################################################Tämä tulos sanoo, että olet onnistuneesti asentanut undercloudin ja voit nyt tarkistaa undercloudin tilan ja jatkaa overcloudin asentamista.
Jos katsot ifconfig-tulostusta, näet, että uusi siltakäyttöliittymä on ilmestynyt
[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-käyttöönotto suoritetaan nyt tämän käyttöliittymän kautta.
Alla olevasta tuotosta näet, että meillä on kaikki palvelut yhdessä solmussa:
(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 |
+--------------------------+-----------+----------+Alla on pilviverkon osan kokoonpano:
(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 asennus
Tällä hetkellä meillä on vain alipilvi, eikä meillä ole tarpeeksi solmuja, joista ylipilviä koottaisiin. Siksi ensin otetaan käyttöön tarvitsemamme virtuaalikoneet. Käyttöönoton aikana Undercloud itse asentaa käyttöjärjestelmän ja tarvittavat ohjelmistot overcloud-koneeseen - eli meidän ei tarvitse ottaa konetta käyttöön kokonaan, vaan vain luoda levy (tai levyt) sille ja määrittää sen parametrit - eli , itse asiassa saamme paljaan palvelimen, johon ei ole asennettu käyttöjärjestelmää.
Mennään kansioon virtuaalikoneiden levyillä ja luodaan tarvittavan kokoisia levyjä:
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 160GKoska toimimme pääkäyttäjänä, meidän on vaihdettava näiden levyjen omistaja, jotta oikeuksiin ei tule ongelmia:
[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]# Huomautus: jos et aio asentaa cephiä sen tutkimiseksi, komennot eivät luo vähintään kolmea solmua, joissa on vähintään kaksi levyä, mutta mallissa ilmoitetaan, että käytetään virtuaalisia levyjä vda, vdb jne.
Hienoa, nyt meidän on määriteltävä kaikki nämä koneet:
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 Lopussa on komento -print-xml > /tmp/storage-1.xml, joka luo xml-tiedoston, jossa on kuvaus jokaisesta /tmp/-kansiossa olevasta koneesta; jos et lisää sitä, et ole pystyy tunnistamaan virtuaalikoneita.
Nyt meidän on määritettävä kaikki nämä koneet virshissä:
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 ~]#Nyt pieni vivahde - tripleO käyttää IPMI:tä palvelimien hallintaan asennuksen ja itsetutkiskelun aikana.
Itsetutkiskelu on prosessi, jossa laitteisto tarkastetaan sen parametrien saamiseksi, joita tarvitaan solmujen lisävarustamiseen. Itsetutkiskelu suoritetaan käyttämällä ironiaa, palvelua, joka on suunniteltu toimimaan paljasmetallipalvelimien kanssa.
Mutta tässä on ongelma - vaikka laitteisto-IPMI-palvelimilla on erillinen portti (tai jaettu portti, mutta tämä ei ole tärkeää), virtuaalikoneissa ei ole tällaisia portteja. Tässä vbmc-sauva tulee avuksemme - apuohjelma, jonka avulla voit emuloida IPMI-porttia. Tähän vivahteeseen kannattaa kiinnittää huomiota varsinkin niille, jotka haluavat perustaa tällaisen laboratorion ESXI-hypervisorille - rehellisesti sanottuna en tiedä onko sillä vbmc:n analogia, joten kannattaa ihmetellä tätä ongelmaa ennen kuin ottaa kaiken käyttöön. .
Asenna vbmc:
yum install yum install python2-virtualbmcJos käyttöjärjestelmäsi ei löydä pakettia, lisää arkisto:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNyt asetamme apuohjelman. Kaikki täällä on banaalia häpeään asti. Nyt on loogista, että vbmc-luettelossa ei ole palvelimia
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Jotta ne näkyvät, ne on ilmoitettava manuaalisesti seuraavasti:
[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 ~]#Mielestäni komennon syntaksi on selkeä ilman selitystä. Kuitenkin toistaiseksi kaikki istunnot ovat DOWN-tilassa. Jotta ne voivat siirtyä UP-tilaan, sinun on otettava ne käyttöön:
[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 viimeinen silaus - sinun on korjattava palomuurisäännöt (tai poistettava se kokonaan käytöstä):
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
Siirrytään nyt pilveen ja tarkistetaan, että kaikki toimii. Isäntäkoneen osoite on 192.168.255.200, undercloudissa lisäsimme tarvittavan ipmitool-paketin käyttöönottoa valmisteltaessa:
[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 runningKuten näet, olemme onnistuneesti käynnistäneet ohjaussolmun vbmc:n kautta. Sammuta se nyt ja siirrytään eteenpäin:
[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 ~]#Seuraava askel on itsetutkiskelu solmuihin, joihin overcloud asennetaan. Tätä varten meidän on valmisteltava json-tiedosto, jossa on kuvaus solmuistamme. Huomaa, että toisin kuin asennus paljaille palvelimille, tiedosto osoittaa portin, jossa vbmc on käynnissä jokaisessa koneessa.
[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:27Huomaa: ohjaussolmulla on kaksi liitäntää, mutta tässä tapauksessa tämä ei ole tärkeää, tässä asennuksessa yksi riittää meille.
Nyt valmistelemme json-tiedoston. Meidän on ilmoitettava sen portin poppy-osoite, jonka kautta provisiointi suoritetaan, solmujen parametrit, annettava niille nimet ja ilmoitettava kuinka päästä ipmiin:
{
"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"
}
]
}Nyt meidän on valmisteltava kuvat ironiseen. Voit tehdä tämän lataamalla ne wgetin kautta ja asentamalla:
(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 ~]$Kuvien lataaminen pilveen:
(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 ~]$Tarkistetaan, että kaikki kuvat on ladattu
(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 ~]$Vielä yksi asia - sinun on lisättävä DNS-palvelin:
(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 ~]$Nyt voimme antaa komennon itsetutkiskeluun:
(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 ~]$Kuten tulosteesta näkyy, kaikki suoritettiin ilman virheitä. Tarkistamme, että kaikki solmut ovat käytettävissä olevassa tilassa:
(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 ~]$ Jos solmut ovat eri tilassa, yleensä hallittavissa, jokin meni pieleen ja sinun on katsottava lokia ja selvitettävä, miksi näin tapahtui. Muista, että tässä skenaariossa käytämme virtualisointia ja virtuaalikoneiden tai vbmc:n käyttöön saattaa liittyä virheitä.
Seuraavaksi meidän on ilmoitettava, mikä solmu suorittaa minkä toiminnon - eli ilmoitettava profiili, jolla solmu ottaa käyttöön:
(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ääritä profiili kullekin solmulle:
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-d9afb69d1167Tarkistamme, että teimme kaiken oikein:
(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 ~]$Jos kaikki on oikein, annamme komennon ottaa käyttöön overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuOikeassa asennuksessa käytetään luonnollisesti räätälöityjä malleja, meidän tapauksessamme tämä vaikeuttaa huomattavasti prosessia, koska jokainen mallin muokkaus on selitettävä. Kuten aiemmin kirjoitettiin, yksinkertainenkin asennus riittää, jotta voimme nähdä, kuinka se toimii.
Huomaa: --libvirt-tyyppinen qemu-muuttuja on tässä tapauksessa välttämätön, koska käytämme sisäkkäistä virtualisointia. Muuten et voi käyttää virtuaalikoneita.
Nyt sinulla on noin tunti tai ehkä enemmänkin (laitteiston ominaisuuksista riippuen) ja voit vain toivoa, että tämän ajan kuluttua näet seuraavan viestin:
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 ~]$Nyt sinulla on melkein täysi versio openstackista, jolla voit opiskella, kokeilla jne.
Tarkastetaan, että kaikki toimii oikein. Käyttäjän kotihakemistopinossa on kaksi tiedostoa - yksi stackrc (undercloudin hallintaan) ja toinen overcloudrc (ylipilvien hallintaan). Nämä tiedostot on määritettävä lähteiksi, koska ne sisältävät todentamiseen tarvittavia tietoja.
(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 ~]$Asennus vaatii vielä pienen kosketuksen - reitin lisäämisen ohjaimeen, koska kone, jolla työskentelen, on eri verkossa. Voit tehdä tämän siirtymällä ohjaus-1:een heat-admin-tilin alla ja rekisteröimällä reitti
(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.254No, nyt voit mennä horisonttiin. Kaikki tiedot - osoitteet, käyttäjätunnus ja salasana - ovat tiedostossa /home/stack/overcloudrc. Lopullinen kaavio näyttää tältä:
Muuten, asennuksessamme koneosoitteet annettiin DHCP:n kautta, ja kuten näet, ne annetaan "satunnaisesti". Voit määrittää mallissa tarkasti, mikä osoite mihinkin koneeseen liitetään käyttöönoton aikana, jos tarvitset sitä.
Miten liikenne kulkee virtuaalikoneiden välillä?
Tässä artikkelissa tarkastellaan kolmea vaihtoehtoa ohittavalle liikenteelle
- Kaksi konetta yhdellä hypervisorilla yhdessä L2-verkossa
- Kaksi konetta eri hypervisoreissa samassa L2-verkossa
- Kaksi konetta eri verkoissa (verkkojen välinen juurtuminen)
Tapauksia, joissa pääsy ulkomaailmaan ulkoisen verkon kautta, kelluvien osoitteiden avulla sekä hajautettu reititys, harkitsemme ensi kerralla, toistaiseksi keskitymme sisäiseen liikenteeseen.
Tarkistaaksesi, kootaan seuraava kaavio:
Olemme luoneet 4 virtuaalikonetta - 3 yhteen L2-verkkoon - net-1 ja 1 muuta net-2-verkkoon
(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 ~]$ Katsotaanpa, millä hypervisorilla luodut koneet sijaitsevat:
(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 |
(ylipilvi) [pino@undercloud ~]$
Koneet vm-1 ja vm-3 sijaitsevat laskenta-0:lla, koneet vm-2 ja vm-4 sijaitsevat solmussa compute-1.
Lisäksi on luotu virtuaalinen reititin mahdollistamaan reititys määritettyjen verkkojen välillä:
(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 ~]$ Reitittimessä on kaksi virtuaalista porttia, jotka toimivat verkkojen yhdyskäytävinä:
(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 ~]$ Mutta ennen kuin tarkastelemme liikenteen sujuvuutta, katsotaanpa, mitä meillä on tällä hetkellä ohjaussolmussa (joka on myös verkkosolmu) ja laskentasolmussa. Aloitetaan laskentasolmusta.
[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 ~]$Tällä hetkellä solmussa on kolme ovs-siltaa - br-int, br-tun, br-ex. Niiden välillä, kuten näemme, on joukko rajapintoja. Ymmärtämisen helpottamiseksi piirretään kaikki nämä rajapinnat kaavioon ja katsotaan mitä tapahtuu.
Tarkasteltaessa osoitteita, joihin VxLAN-tunnelit nostetaan, voidaan nähdä, että yksi tunneli on nostettu arvoon compute-1 (192.168.255.26), toinen tunneli näyttää ohjaus-1:lle (192.168.255.15). Mutta mielenkiintoisin asia on, että br-exillä ei ole fyysisiä rajapintoja, ja jos katsot mitä virtoja on määritetty, voit nähdä, että tämä silta voi vain pudottaa liikennettä tällä hetkellä.
[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 ~]$ Kuten lähdöstä näkyy, osoite ruuvataan suoraan fyysiseen porttiin, ei virtuaaliseen siltaliitäntään.
[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 ~]$
Ensimmäisen säännön mukaan kaikki, mikä tuli phy-br-ex-portista, on hävitettävä.
Itse asiassa tällä hetkellä ei ole muuta liikennettä tälle sillalle kuin tästä rajapinnasta (rajapinta br-int:n kanssa), ja pudotuksen perusteella BUM-liikenne on jo lennättänyt sillalle.
Eli liikenne voi poistua tästä solmusta vain VxLAN-tunnelin kautta eikä mitään muuta. Jos kuitenkin kytket DVR:n päälle, tilanne muuttuu, mutta käsittelemme sen toisella kerralla. Käytettäessä verkon eristystä, esimerkiksi vlaneja, sinulla ei ole yhtä L3-liitäntää vlan 0:ssa, vaan useita rajapintoja. VxLAN-liikenne poistuu kuitenkin solmusta samalla tavalla, mutta myös kapseloituna jonkinlaiseen omistettuun vlan-verkkoon.
Olemme selvittäneet laskentasolmun, siirrytään ohjaussolmuun.
[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 ~]$Itse asiassa voimme sanoa, että kaikki on sama, mutta IP-osoite ei ole enää fyysisessä käyttöliittymässä, vaan virtuaalisella sillalla. Tämä tehdään, koska tämä portti on portti, jonka kautta liikenne poistuu ulkomaailmaan.
[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 ~]$ Tämä portti on sidottu br-ex-sillalle ja koska siinä ei ole vlan-tageja, tämä portti on runkoportti, jossa kaikki vlanit ovat sallittuja, nyt liikenne menee ulos ilman tunnistetta, kuten vlan-id 0 osoittaa tulos yllä.
Kaikki muu tällä hetkellä on samanlaista kuin laskentasolmu - samat sillat, samat tunnelit menevät kahteen laskentasolmuun.
Emme käsittele tallennussolmuja tässä artikkelissa, mutta ymmärtämiseksi on tarpeen sanoa, että näiden solmujen verkko-osa on häpeälliseen pisteeseen asti. Meidän tapauksessamme on vain yksi fyysinen portti (eth0), jolle on määritetty IP-osoite, ja siinä se. Ei ole VxLAN-tunneleita, tunnelisiltaja jne. - ei ole ollenkaan ovs-tunneleita, koska siinä ei ole järkeä. Verkkoeristystä käytettäessä tällä solmulla on kaksi liitäntää (fyysiset portit, bodny tai vain kaksi vlania - sillä ei ole väliä - riippuu mitä haluat) - yksi hallintaa varten, toinen liikenteelle (kirjoittaminen VM-levylle , lukeminen levyltä jne.)
Selvitimme, mitä meillä on solmuissa palveluiden puuttuessa. Käynnistetään nyt 4 virtuaalikonetta ja katsotaan kuinka yllä kuvattu malli muuttuu - meillä pitäisi olla portteja, virtuaalisia reitittimiä jne.
Toistaiseksi verkostomme näyttää tältä:
Meillä on kaksi virtuaalikonetta kussakin tietokonesolmussa. Käyttäen esimerkkinä laskenta-0:ta, katsotaan kuinka kaikki on mukana.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Koneessa on vain yksi virtuaalinen käyttöliittymä - 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 ~]$
Tämä käyttöliittymä näyttää Linux-sillalta:
[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 ~]$ Kuten lähdöstä näkyy, sillassa on vain kaksi liitäntää - tap95d96a75-a0 ja qvb95d96a75-a0.
Tässä kannattaa miettiä hieman OpenStackin virtuaalisten verkkolaitteiden tyyppejä:
vtap - ilmentymään liitetty virtuaalinen käyttöliittymä (VM)
qbr - Linux-silta
qvb ja qvo - vEth -pari yhdistetty Linux-sillalle ja Open vSwitch -sillalle
br-int, br-tun, br-vlan — Avaa vSwitch-sillat
patch-, int-br-, phy-br- - Avaa vSwitch-korjausrajapinnat, jotka yhdistävät siltoja
qg, qr, ha, fg, sg - Avaa vSwitch-portit, joita virtuaalilaitteet käyttävät yhteyden muodostamiseen OVS:ään
Kuten ymmärrät, jos meillä on sillassa qvb95d96a75-a0-portti, joka on vEth-pari, niin jossain on sen vastine, jota pitäisi loogisesti kutsua qvo95d96a75-a0. Katsotaanpa mitä portteja OVS:ssä 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 ~]$ Kuten näemme, satama on br-intissä. Br-int toimii kytkimenä, joka päättää virtuaalikoneen portit. Portin qvo95d96a75-a0 lisäksi ulostulossa näkyy portti qvo5bd37136-47. Tämä on portti toiseen virtuaalikoneeseen. Tämän seurauksena kaaviomme näyttää nyt tältä:
Kysymys, jonka pitäisi heti kiinnostaa tarkkaavaista lukijaa - mikä on linux-silta virtuaalikoneen portin ja OVS-portin välillä? Tosiasia on, että koneen suojaamiseksi käytetään suojausryhmiä, jotka eivät ole muuta kuin iptables. OVS ei toimi iptablesin kanssa, joten tämä "sauva" keksittiin. Se on kuitenkin vanhentumassa - se korvataan uusissa julkaisuissa conntrackilla.
Eli kaava näyttää lopulta tältä:
Kaksi konetta yhdellä hypervisorilla yhdessä L2-verkossa
Koska nämä kaksi virtuaalikonetta sijaitsevat samassa L2-verkossa ja samassa hypervisorissa, niiden välinen liikenne kulkee loogisesti paikallisesti br-int:n kautta, koska molemmat koneet ovat samassa VLANissa:
[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 ~]$ Kaksi konetta eri hypervisoreissa samassa L2-verkossa
Katsotaan nyt kuinka liikenne kulkee kahden koneen välillä samassa L2-verkossa, mutta jotka sijaitsevat eri hypervisoreissa. Ollakseni rehellinen, mikään ei muutu paljon, vain liikenne hypervisorien välillä kulkee vxlan-tunnelin läpi. Katsotaanpa esimerkkiä.
Virtuaalikoneiden osoitteet, joiden välistä liikennettä seuraamme:
[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 ~]$ Tarkastelemme edelleenlähetystaulukkoa br-int:ssä compute-0:ssa:
[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 ~]Liikenteen pitäisi mennä porttiin 2 - katsotaan millainen portti se 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 ~]$Tämä on patch-tun - eli käyttöliittymä br-tunissa. Katsotaan mitä tapahtuu paketille br-tunissa:
[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 ~]$ Paketti pakataan VxLANiin ja lähetetään porttiin 2. Katsotaan mihin portti 2 johtaa:
[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 ~]$Tämä on vxlan-tunneli compute-1:ssä:
[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 ~]$Siirrytään laskentaan 1 ja katsotaan mitä paketille tapahtuu seuraavaksi:
[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 br-int-välitystaulukossa compute-1:ssä, ja kuten yllä olevasta lähdöstä näkyy, se näkyy portin 2 kautta, joka on portti br-tuniin:
[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:46No, sitten näemme, että br-int:ssä compute-1:ssä on kohdeunikon kohde:
[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 ~]$ Eli vastaanotettu paketti lentää porttiin 3, jonka takana on jo virtuaalikoneen ilmentymä-00000003.
Openstackin käyttöönoton kauneus virtuaalisen infrastruktuurin oppimiseen on se, että voimme helposti siepata liikennettä hypervisoreiden välillä ja nähdä, mitä sille tapahtuu. Teemme nyt näin: suorita tcpdump vnet-portissa kohti compute-0:aa:
[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*******************Ensimmäinen rivi näyttää, että Patek osoitteesta 10.0.1.85 menee osoitteeseen 10.0.1.88 (ICMP-liikenne), ja se on kääritty VxLAN-pakettiin vni 22:lla ja paketti siirtyy isännästä 192.168.255.19 (compute-0) isäntään 192.168.255.26 .1 ( laske-XNUMX). Voimme tarkistaa, että VNI vastaa ovs:ssa määritettyä.
Palataan tälle riville action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],lähtö:2. 0x16 on vni heksadesimaalilukujärjestelmässä. Muunnetaan tämä luku 16. järjestelmäksi:
16 = 6*16^0+1*16^1 = 6+16 = 22Eli vni vastaa todellisuutta.
Toinen rivi näyttää paluuliikenteen, no, ei ole mitään järkeä selittää sitä, kaikki on selvää siellä.
Kaksi konetta eri verkoissa (verkkojen välinen reititys)
Tämän päivän viimeinen tapaus on reititys verkkojen välillä yhden projektin sisällä virtuaalisen reitittimen avulla. Harkitsemme tapausta ilman DVR:ää (tarkastelemme sitä toisessa artikkelissa), joten reititys tapahtuu verkkosolmussa. Meidän tapauksessamme verkkosolmua ei sijoiteta erilliseen kokonaisuuteen ja se sijaitsee ohjaussolmussa.
Katsotaanpa ensin, että reititys toimii:
$ 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 msKoska tässä tapauksessa paketin on mentävä yhdyskäytävään ja reitittävä sinne, meidän on selvitettävä yhdyskäytävän poppy-osoite, jota varten katsomme esimerkin ARP-taulukkoa:
$ 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 eth0Katsotaan nyt mihin liikenne määränpäänä (10.0.1.254) fa:16:3e:c4:64:70 tulee lähettää:
[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 ~]$ Katsotaanpa mihin portti 2 johtaa:
[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 ~]$ Kaikki on loogista, liikenne kulkee br-tunissa. Katsotaan mihin vxlan-tunneliin se kääritään:
[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 portti on vxlan-tunneli:
[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 ~]$ Joka katsoo ohjaussolmua:
[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 ~]$ Liikenne on saavuttanut ohjaussolmun, joten meidän on mentävä siihen ja katsottava kuinka reititys tapahtuu.
Kuten muistat, sisäinen ohjaussolmu näytti täsmälleen samalta kuin laskentasolmu - samat kolme siltaa, vain br-exissä oli fyysinen portti, jonka kautta solmu saattoi lähettää liikennettä ulos. Instanssien luominen muutti laskentasolmujen konfiguraatiota - solmuihin lisättiin linux-silta, iptables ja rajapinnat. Myös verkkojen ja virtuaalisen reitittimen luominen jätti jälkensä ohjaussolmun konfiguraatioon.
Joten on selvää, että yhdyskäytävän MAC-osoitteen on oltava ohjaussolmun br-int-välitystaulukossa. Tarkistamme, että se on siellä ja mistä se etsii:
[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 näkyy portista qr-0c52b15f-8f. Jos palaamme Openstackin virtuaaliporttien luetteloon, tämän tyyppistä porttia käytetään erilaisten virtuaalisten laitteiden yhdistämiseen OVS:ään. Tarkemmin sanottuna qr on portti virtuaalireitittimeen, joka esitetään nimiavaruudena.
Katsotaanpa, mitä nimiavaruuksia palvelimella on:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Jopa kolme kappaletta. Mutta nimistä päätellen voit arvata jokaisen tarkoituksen. Palaamme myöhemmin ilmentymiin, joiden tunnus on 0 ja 1, nyt olemme kiinnostuneita nimiavaruudesta 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 ~]$ Tämä nimiavaruus sisältää kaksi sisäistä nimiavaruutta, jotka olemme luoneet aiemmin. Molemmat virtuaaliportit on lisätty br-int:iin. Tarkastetaan portin qr-0c52b15f-8f mac-osoite, koska liikenne meni kohdemac-osoitteen perusteella tähän käyttöliittymään.
[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 ~]$ Eli tässä tapauksessa kaikki toimii normaalin reitityksen lakien mukaan. Koska liikenne on suunnattu isännälle 10.0.2.8, sen on poistuttava toisen liitännän qr-92fa49b5-54 kautta ja mentävä vxlan-tunnelin kautta laskentasolmuun:
[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 ~]$ Kaikki on loogista, ei yllätyksiä. Katsotaanpa, missä isännän 10.0.2.8 poppy-osoite näkyy br-int:ssä:
[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 ~]$ Odotetusti liikenne menee br-tuniin, katsotaan mihin tunneliin liikenne menee seuraavaksi:
[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 ~]$ Liikenne menee tunneliin laskemaan-1. No, compute-1:ssä kaikki on yksinkertaista - br-tunista paketti menee br-int:iin ja sieltä virtuaalikoneen käyttöliittymään:
[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 ~]$ Tarkistamme, että tämä on todellakin oikea käyttöliittymä:
[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 ~]$
Itse asiassa kävimme paketin läpi. Luulen, että huomasit, että liikenne kulki eri vxlan-tunneleiden läpi ja poistui eri VNI:illä. Katsotaan, millaisia VNI:itä nämä ovat, minkä jälkeen keräämme kaatopaikan solmun ohjausporttiin ja varmistamme, että liikenne kulkee täsmälleen edellä kuvatulla tavalla.
Joten tunnelissa compute-0 on seuraavat toiminnot=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],lähtö:3. Muunnetaan 0x16 desimaalilukujärjestelmäksi:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunnelilla compute-1 on seuraava VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],lähtö:2. Muunnetaan 0x63 desimaalilukujärjestelmäksi:
0x63 = 3*16^0+6*16^1 = 3+96 = 99No, katsotaan nyt kaatopaikkaa:
[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*******************Ensimmäinen paketti on vxlan-paketti isännästä 192.168.255.19 (compute-0) isäntään 192.168.255.15 (control-1), jossa on vni 22, jonka sisällä on pakattu ICMP-paketti isännästä 10.0.1.85 isäntään 10.0.2.8. Kuten yllä laskettiin, vni vastaa sitä, mitä näimme ulostulossa.
Toinen paketti on vxlan-paketti isännästä 192.168.255.15 (ohjaus-1) isäntään 192.168.255.26 (compute-1) vni 99:llä, jonka sisällä on pakattu ICMP-paketti isännästä 10.0.1.85 isäntään 10.0.2.8. Kuten yllä laskettiin, vni vastaa sitä, mitä näimme ulostulossa.
Seuraavat kaksi pakettia ovat paluuliikennettä 10.0.2.8 ei 10.0.1.85.
Eli lopulta saimme seuraavan ohjaussolmukaavion:
Näyttääkö se siltä? Unohdimme kaksi nimiavaruutta:
[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 ~]$ Kuten puhuimme pilvialustan arkkitehtuurista, olisi hyvä, jos koneet saisivat osoitteet automaattisesti DHCP-palvelimelta. Nämä ovat kaksi DHCP-palvelinta kahdelle verkollemme 10.0.1.0/24 ja 10.0.2.0/24.
Tarkastetaan, onko tämä totta. Tässä nimiavaruudessa on vain yksi osoite - 10.0.1.1 - itse DHCP-palvelimen osoite, ja se sisältyy myös br-int:iin:
[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 0Katsotaan, sisältävätkö prosessit, jotka sisältävät qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 nimessään ohjaussolmussa:
[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 ~]$ Tällainen prosessi on olemassa ja yllä olevassa tuotoksessa esitettyjen tietojen perusteella voimme esimerkiksi katsoa, mitä meillä on tällä hetkellä vuokrattavana:
[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 ~]$Seurauksena on, että ohjaussolmussa on seuraavat palvelut:
No, muista - tämä on vain 4 konetta, 2 sisäistä verkkoa ja yksi virtuaalinen reititin... Meillä ei ole täällä nyt ulkoisia verkkoja, joukko erilaisia projekteja, joista jokaisella on omat verkkonsa (päällekkäiset), ja meillä on hajautettu reititin sammui, ja loppujen lopuksi testipenkissä oli vain yksi ohjaussolmu (vikasietokykyä varten on oltava kolmen solmun päätösvaltaisuus). On loogista, että kaupassa kaikki on "hieman" monimutkaisempaa, mutta tässä yksinkertaisessa esimerkissä ymmärrämme kuinka sen pitäisi toimia - onko sinulla 3 vai 300 nimiavaruutta, on tietysti tärkeää, mutta toiminnan kannalta koko rakennetta, mikään ei muutu paljoa... vaikka et liitä mitään toimittajan SDN:ää. Mutta se on täysin eri tarina.
Toivottavasti oli mielenkiintoista. Jos sinulla on kommentteja/lisäyksiä tai jossain kohtaa olen suoraan valehdellut (olen ihminen ja mielipiteeni on aina subjektiivinen) - kirjoita, mitä pitää korjata/lisätä - korjaamme/lisäämme kaiken.
Lopuksi haluaisin sanoa muutaman sanan Openstackin (sekä vanilja että myyjä) vertaamisesta VMWaren pilviratkaisuun - minulta on kysytty tätä kysymystä liian usein viimeisten parin vuoden aikana, ja suoraan sanottuna olen jo kyllästynyt siihen, mutta silti. Mielestäni näitä kahta ratkaisua on erittäin vaikea verrata, mutta voimme ehdottomasti sanoa, että molemmissa ratkaisuissa on haittoja ja yhtä ratkaisua valittaessa on punnittava etuja ja haittoja.
Jos OpenStack on yhteisölähtöinen ratkaisu, niin VMWarella on oikeus tehdä vain mitä se haluaa (lue - mikä sille on kannattavaa) ja tämä on loogista - koska se on kaupallinen yritys, joka on tottunut tienaamaan asiakkailtaan. Mutta on yksi iso ja lihava MUTTA - OpenStackista pääsee pois esimerkiksi Nokialta ja vähällä kustannuksella vaihtaa ratkaisuun esimerkiksi Juniperista (Contrail Cloud), mutta tuskin pääset pois VMWaresta. . Minulle nämä kaksi ratkaisua näyttävät tältä - Openstack (myyjä) on yksinkertainen häkki, johon sinut laitetaan, mutta sinulla on avain ja voit lähteä milloin tahansa. VMWare on kultainen häkki, omistajalla on häkin avain ja se maksaa sinulle paljon.
En mainosta ensimmäistä tai toista tuotetta - sinä valitset mitä tarvitset. Mutta jos minulla olisi tällainen valinta, valitsisin molemmat ratkaisut - VMWaren IT-pilvelle (pieni kuormitus, helppo hallinta), OpenStack joltakin toimittajalta (Nokia ja Juniper tarjoavat erittäin hyviä avaimet käteen -ratkaisuja) - Telecom-pilveen. En käyttäisi Openstackia puhtaaseen tietotekniikkaan - se on kuin varpusen ampumista tykillä, mutta en näe sen käytölle muita vasta-aiheita kuin redundanssi. VMWaren käyttäminen televiestinnässä on kuitenkin kuin murskan kuljettamista Ford Raptorissa - se on kaunis ulkopuolelta, mutta kuljettajan on tehtävä 10 matkaa yhden sijasta.
VMWaren suurin haittapuoli on mielestäni sen täydellinen sulkeutuminen - yritys ei anna sinulle mitään tietoa miten se toimii, esim. vSAN tai mitä hypervisor-ytimessä on - se ei yksinkertaisesti ole kannattavaa sille - eli saat Älä koskaan tule VMWaren asiantuntijaksi - ilman myyjän tukea olet tuomittu (hyvin usein tapaan VMWare-asiantuntijoita, jotka ovat hämmentyneitä triviaaleista kysymyksistä). Minulle VMWare ostaa auton konepellillä lukittuna - kyllä, sinulla voi olla asiantuntijoita, jotka voivat vaihtaa jakohihnan, mutta vain se, joka myi sinulle tämän ratkaisun, voi avata konepellin. Henkilökohtaisesti en pidä ratkaisuista, joihin en sovi. Sanot, että sinun ei ehkä tarvitse mennä konepellin alle. Kyllä, tämä on mahdollista, mutta katson sinua, kun sinun on koottava pilveen suuri funktio 20-30 virtuaalikoneesta, 40-50 verkosta, joista puolet haluaa mennä ulos ja toinen puoli pyytää SR-IOV-kiihdytys, muuten tarvitset lisää pari tusinaa näitä autoja - muuten suorituskyky ei riitä.
On muitakin näkökulmia, joten vain sinä voit päättää, mitä valitset, ja mikä tärkeintä, olet sitten vastuussa valinnastasi. Tämä on vain minun mielipiteeni - henkilö, joka on nähnyt ja koskettanut vähintään 4 tuotetta - Nokia, Juniper, Red Hat ja VMWare. Eli minulla on jotain, mihin verrata.
Lähde: will.com