В edellinen numero Kuvasin verkon automaatiokehystä. Joidenkin ihmisten mukaan jo tämä ensimmäinen lähestymistapa ongelmaan on jo ratkaissut joitain kysymyksiä. Ja tämä tekee minut erittäin iloiseksi, koska syklin tavoitteena ei ole peittää Ansiblea Python-skripteillä, vaan rakentaa järjestelmä.

Sama kehys määrittää järjestyksen, jossa käsittelemme kysymystä.
Ja verkon virtualisointi, jolle tämä numero on omistettu, ei sovi erityisesti ADSM-aiheeseen, jossa analysoimme automaatiota.

Mutta katsotaan asiaa toisesta näkökulmasta.

Monet palvelut ovat käyttäneet samaa verkkoa pitkään. Teleoperaattorin tapauksessa tämä on esimerkiksi 2G, 3G, LTE, laajakaista ja B2B. DC:n tapauksessa: liitettävyys eri asiakkaille, Internet, lohkotallennus, objektin tallennus.

Ja kaikki palvelut vaativat eristäytymistä toisistaan. Näin peittoverkot ilmestyivät.

Ja kaikki palvelut eivät halua odottaa, että henkilö määrittää ne manuaalisesti. Näin orkesterit ja SDN ilmestyivät.

Ensimmäinen lähestymistapa verkon tai pikemminkin sen osan systemaattiseen automatisointiin on otettu ja otettu käyttöön jo pitkään monissa paikoissa: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Sitä käsittelemme tänään.

Pitoisuus

• Syyt
• terminologia
• Underlay - fyysinen verkko
• Overlay - virtuaalinen verkko
  • Peitto ToR:lla
  • Peittokuva isännältä
  • Esimerkkinä käytetään volframikangasta
    • Viestintä yhdessä fyysisessä koneessa
    • Viestintä eri fyysisille koneille sijaitsevien virtuaalikoneiden välillä
    • Poistuminen ulkomaailmaan

• FAQ
• Johtopäätös
• Hyödyllisiä linkkejä

Syyt

Ja koska puhumme tästä, on syytä mainita verkon virtualisoinnin edellytykset. Itse asiassa tämä prosessi ei alkanut eilen.

Olet luultavasti kuullut useammin kuin kerran, että verkko on aina ollut järjestelmän inertein osa. Ja tämä on totta kaikin puolin. Verkko on perusta, jolla kaikki lepää, ja siihen muutosten tekeminen on melko vaikeaa - palvelut eivät siedä sitä verkon ollessa poissa. Usein yhden solmun käytöstä poistaminen voi kaataa suuren osan sovelluksista ja vaikuttaa moniin asiakkaisiin. Osittain tästä syystä verkkotiimi voi vastustaa muutoksia - koska nyt se jotenkin toimii (emme ehkä edes tiedä miten), mutta tässä sinun on määritettävä jotain uutta, eikä tiedetä, kuinka se vaikuttaa verkkoon.

Jotta verkkokäyttäjät eivät odottaisi lisäämään VLAN-verkkoja eivätkä rekisteröiisi palveluita jokaisessa verkkosolmussa, ihmiset keksivät käyttää peittokuvia - overlay-verkkoja - joita on monia erilaisia: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE jne.

Heidän vetovoimansa piilee kahdessa yksinkertaisessa asiassa:

• Vain päätesolmut on määritetty – kuljetussolmuja ei tarvitse koskea. Tämä nopeuttaa huomattavasti prosessia ja joskus mahdollistaa verkkoinfrastruktuuriosaston kokonaan sulkemisen uusien palveluiden käyttöönoton prosessista.
• Kuorma on piilotettu syvälle otsikoiden sisään - siirtosolmujen ei tarvitse tietää siitä mitään, isännissä olevista osoitteista tai overlay-verkon reiteistä. Tämä tarkoittaa, että sinun täytyy tallentaa vähemmän tietoa taulukoihin, mikä tarkoittaa yksinkertaisemman/halvemman laitteen käyttöä.

Tässä ei täysin täysimittaisessa numerossa en aio analysoida kaikkia mahdollisia teknologioita, vaan kuvaan pikemminkin kehysten peittoverkkojen toiminnan DC:issä.

Koko sarja kuvaa palvelinkeskusta, joka koostuu riveistä identtisiä telineitä, joihin on asennettu samat palvelinlaitteet.

Tämä laite käyttää virtuaalikoneita/säilöjä/palvelimettomia, jotka toteuttavat palveluita.

terminologia

Syklissä palvelin Nimeän ohjelman, joka toteuttaa asiakas-palvelin-viestinnän palvelinpuolen.

Telineissä olevia fyysisiä koneita kutsutaan palvelimiksi ei me teemme.

Fyysinen kone — x86-tietokone asennettuna telineeseen. Useimmin käytetty termi isäntä. niin kutsumme sitä"auto"tai isäntä.

hypervisor - fyysisellä koneella toimiva sovellus, joka emuloi fyysisiä resursseja, joissa virtuaalikoneita käytetään. Joskus kirjallisuudessa ja Internetissä sanaa "hypervisor" käytetään synonyyminä "isäntälle".

Virtuaalikone - käyttöjärjestelmä, joka toimii fyysisessä koneessa hypervisorin päällä. Meille tässä syklissä ei ole oikeastaan ​​väliä, onko se itse asiassa virtuaalikone vai vain kontti. Kutsutaan sitä "VM«

Vuokralainen on laaja käsite, jonka määrittelen tässä artikkelissa erilliseksi palveluksi tai erilliseksi asiakkaaksi.

Monivuokraus tai monivuokraus - saman sovelluksen käyttö eri asiakkaiden/palveluiden toimesta. Samaan aikaan asiakkaiden eristäminen toisistaan ​​saavutetaan sovellusarkkitehtuurin ansiosta, ei erikseen suoritettavien esiintymien kautta.

ToR — Telinekytkimen yläosa - telineeseen asennettu kytkin, johon kaikki fyysiset koneet on kytketty.

ToR-topologian lisäksi useat palveluntarjoajat harjoittavat End of Row (EoR) tai Middle of Row (tosin jälkimmäinen on halventava harvinaisuus, enkä ole nähnyt MoR-lyhennettä).

Pohjaverkko tai taustalla oleva verkko tai pohja on fyysinen verkkoinfrastruktuuri: kytkimet, reitittimet, kaapelit.

Peittoverkko tai peittoverkko tai peittokuva - virtuaalinen tunneliverkko, joka kulkee fyysisen tunnelin päällä.

L3-kangas tai IP-kangas - Ihmiskunnan hämmästyttävä keksintö, jonka avulla voit välttää STP:n toistamisen ja TRILLin oppimisen haastatteluja varten. Konsepti, jossa koko verkko käyttöoikeustasoon asti on yksinomaan L3, ilman VLAN-verkkoja ja vastaavasti valtavia laajennettuja lähetysalueita. Tarkastellaan seuraavassa osassa, mistä sana "tehdas" tulee.

SDN - Ohjelmiston määrittämä verkko. Tuskin esittelyä kaipaa. Verkonhallinnan lähestymistapa, jossa muutoksia verkkoon ei tee ihminen vaan ohjelma. Yleensä tarkoittaa ohjaustason siirtämistä pääverkkolaitteiden ulkopuolelle ohjaimeen.

NFV — Verkkotoimintojen virtualisointi — verkkolaitteiden virtualisointi, mikä viittaa siihen, että joitain verkkotoimintoja voidaan ajaa virtuaalikoneiden tai säiliöiden muodossa uusien palveluiden käyttöönoton nopeuttamiseksi, palveluketjun järjestämiseksi ja yksinkertaisemman horisontaalisen skaalautuvuuden avulla.

VNF - Virtuaaliverkkotoiminto. Tietty virtuaalinen laite: reititin, kytkin, palomuuri, NAT, IPS/IDS jne.

Yksinkertaistan nyt tarkoituksella kuvauksen tiettyyn toteutukseen, jotta en hämmennä lukijaa liikaa. Ajattelevampaa lukemista varten suosittelen häntä osioon viittaukset. Lisäksi Roma Gorge, joka arvostelee tätä artikkelia epätarkkuuksista, lupaa kirjoittaa erillisen numeron palvelin- ja verkkovirtualisointiteknologioista, syvällisemmin ja tarkkaavaisempana.

Useimmat nykyiset verkot voidaan selvästi jakaa kahteen osaan:

aluspaperi — fyysinen verkko, jonka kokoonpano on vakaa.
Päällys — vedenotto aluskatteen päälle vuokralaisten eristämiseksi.

Tämä pätee sekä DC:n tapaukseen (jota analysoimme tässä artikkelissa) että ISP:n tapauksessa (jota emme analysoi, koska se on jo tehty SDSM). Yritysverkostojen kohdalla tilanne on tietysti hieman erilainen.

Kuva keskittyen verkkoon:

aluspaperi

Underlay on fyysinen verkko: laitteistokytkimet ja kaapelit. Maanalaisissa laitteet osaavat saavuttaa fyysiset koneet.

Se perustuu standardiprotokolliin ja -tekniikoihin. Ei vähiten siksi, että laitteistot toimivat tähän päivään saakka patentoiduilla ohjelmistoilla, jotka eivät salli sirun ohjelmointia tai omien protokollien toteuttamista, joten yhteensopivuutta muiden valmistajien kanssa ja standardointia tarvitaan.

Mutta Googlen kaltaisella henkilöllä on varaa kehittää omia kytkimiään ja luopua yleisesti hyväksytyistä protokollista. Mutta LAN_DC ei ole Google.

Alusta vaihtuu suhteellisen harvoin, koska sen tehtävänä on perus-IP-yhteys fyysisten koneiden välillä. Underlay ei tiedä mitään sen päällä olevista palveluista, asiakkaista tai vuokralaisista - sen tarvitsee vain toimittaa paketti koneelta toiselle.
Aluskate voisi olla tällainen:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Underlay-verkko konfiguroidaan perinteisellä tavalla: CLI/GUI/NETCONF.

Manuaalisesti komentosarjat, omat apuohjelmat.

Sarjan seuraava artikkeli on omistettu aluskatteelle yksityiskohtaisemmin.

Päällys

Overlay on Underlayn päälle venytetty virtuaalinen tunneliverkko, jonka avulla yhden asiakkaan virtuaalikoneet voivat kommunikoida keskenään ja samalla eristää muista asiakkaista.

Asiakastiedot on kapseloitu joihinkin tunnelointiotsikoihin lähetettäväksi julkisen verkon kautta.

Joten yhden asiakkaan (yksi palvelun) VM:t voivat kommunikoida toistensa kanssa Overlayn kautta tietämättä edes mitä reittiä paketti todella kulkee.

Peittokuva voi olla esimerkiksi kuten edellä mainitsin:

• GRE tunneli
• VXLAN
• EVPN
• L3VPN
• GENEVE

Päällekkäinen verkko määritetään ja sitä ylläpidetään yleensä keskusohjaimen kautta. Siitä konfiguraatio, ohjaustaso ja datataso toimitetaan laitteille, jotka reitittävät ja kapseloivat asiakasliikenteen. Vähän alla Katsotaanpa tätä esimerkkien avulla.

Kyllä, tämä on SDN puhtaimmassa muodossaan.

Overlay-verkoston järjestämiseen on kaksi pohjimmiltaan erilaista lähestymistapaa:

1. Peitto ToR:lla
2. Peittokuva isännältä

Peitto ToR:lla

Päällystys voi alkaa telineessä olevasta pääsykytkimestä (ToR), kuten tapahtuu esimerkiksi VXLAN-kankaan tapauksessa.

Tämä on aika-testattu mekanismi ISP-verkoissa, ja kaikki verkkolaitteiden toimittajat tukevat sitä.

Tässä tapauksessa ToR-kytkimen on kuitenkin kyettävä erottamaan eri palvelut toisistaan, ja verkonvalvojan on tehtävä jossain määrin yhteistyötä virtuaalikoneen ylläpitäjien kanssa ja tehtävä muutoksia (tosin automaattisesti) laitteiden kokoonpanoon. .

Ohjaan tässä lukijan artikkeliin aiheesta VxLAN Habréssa vanha ystävämme @bormoglotx.
Tässä esityksiä ENOGin kanssa Lähestymistavat DC-verkon rakentamiseen EVPN VXLAN -kankaalla kuvataan yksityiskohtaisesti.

Ja täydellisempään todellisuuteen uppoutumiseen voit lukea Tsiskan kirjan Moderni, avoin ja skaalautuva kangas: VXLAN EVPN.

Huomaan, että VXLAN on vain kapselointimenetelmä ja tunneleiden päättäminen voi tapahtua ei ToR:ssä vaan isännässä, kuten tapahtuu esimerkiksi OpenStackin tapauksessa.

Kuitenkin VXLAN-kangas, jossa peittokuva alkaa ToR:stä, on yksi vakiintuneista peittoverkkosuunnitelmista.

Peittokuva isännältä

Toinen lähestymistapa on aloittaa ja lopettaa tunneleita pääteisännissä.
Tässä tapauksessa verkko (Underlay) pysyy mahdollisimman yksinkertaisena ja staattisena.
Ja isäntä itse tekee kaiken tarvittavan kapseloinnin.

Tämä vaatii tietysti erityisen sovelluksen käyttämisen isännissä, mutta se on sen arvoista.

Ensinnäkin asiakkaan käyttäminen Linux-koneella on helpompaa tai, sanotaanko, jopa mahdollista, kun taas kytkimessä joudut todennäköisesti kääntymään omien SDN-ratkaisujen puoleen, mikä tappaa ajatuksen monen toimittajan toiminnasta.

Toiseksi, ToR-kytkin voidaan tässä tapauksessa jättää mahdollisimman yksinkertaiseksi sekä ohjaustason että datatason näkökulmasta. Silloin sen ei todellakaan tarvitse kommunikoida SDN-ohjaimen kanssa, eikä sen tarvitse myöskään tallentaa kaikkien kytkettyjen asiakkaiden verkkoja/ARP:ita - riittää, kun tietää fyysisen koneen IP-osoitteen, mikä yksinkertaistaa huomattavasti vaihtamista/ reititystaulukot.

ADSM-sarjassa valitsen overlay-lähestymistavan isännältä - silloin puhumme vain siitä, emmekä palaa VXLAN-tehtaalle.

Helpoin on katsoa esimerkkejä. Ja koekohteena otamme OpenSource SDN -alustan OpenContrail, joka tunnetaan nyt nimellä Volframi kangas.

Artikkelin lopussa annan joitakin ajatuksia analogiasta OpenFlow'n ja OpenvSwitchin kanssa.

Esimerkkinä käytetään volframikangasta

Jokaisella fyysisellä koneella on vRouter - virtuaalinen reititin, joka tietää siihen liitetyistä verkoista ja mihin asiakkaisiin ne kuuluvat - olennaisesti PE-reititin. Jokaiselle asiakkaalle se ylläpitää eristettyä reititystaulukkoa (lue VRF). Ja vRouter todella tekee Overlay-tunneloinnin.

Hieman lisää vRouterista on artikkelin lopussa.

Jokainen hypervisorissa sijaitseva virtuaalikone on yhdistetty tämän koneen vRouteriin kautta TAP-käyttöliittymä.

TAP - Terminal Access Point - Linux-ytimen virtuaalinen käyttöliittymä, joka mahdollistaa verkkovuorovaikutuksen.

Jos vRouterin takana on useita verkkoja, jokaiselle luodaan virtuaalinen rajapinta, jolle määritetään IP-osoite - se on oletusyhdyskäytävän osoite.
Kaikki yhden asiakkaan verkot on sijoitettu yhteen VRF laajennus (yksi pöytä), eri - erilaisiksi.
Teen tähän vastuuvapauslausekkeen, että kaikki ei ole niin yksinkertaista, ja lähetän uteliaan lukijan artikkelin loppuun.

Jotta vRouterit voivat kommunikoida keskenään ja vastaavasti niiden takana sijaitsevat virtuaalikoneet, he vaihtavat reititystietoja SDN-ohjain.

Ulospäin ulkomaailmaan pääsemiseksi matriisista on poistumispiste - virtuaalinen verkkoyhdyskäytävä VNGW - Virtual Network GateWay (minun termi).

Katsotaanpa nyt esimerkkejä viestinnästä - ja siitä tulee selkeyttä.

Viestintä yhdessä fyysisessä koneessa

VM0 haluaa lähettää paketin VM2:lle. Oletetaan nyt, että tämä on yksi asiakas-VM.

Datataso

1. VM-0:lla on oletusreitti eth0-liittymäänsä. Paketti lähetetään sinne.
   Tämä liitäntä eth0 on itse asiassa kytketty virtuaalisesti virtuaaliseen reitittimeen vRouter TAP-liitännän tap0 kautta.
2. vRouter analysoi, mihin rajapintaan paketti tuli, eli mihin asiakkaaseen (VRF) se kuuluu, ja tarkistaa vastaanottajan osoitteen tämän asiakkaan reititystaulukosta.
3. Havaittuaan, että saman koneen vastaanottaja on eri portissa, vRouter yksinkertaisesti lähettää paketin sille ilman lisäotsikoita - tässä tapauksessa vRouterilla on jo ARP-merkintä.

Tässä tapauksessa paketti ei pääse fyysiseen verkkoon - se reititetään vRouterin sisällä.

Ohjaustaso

Kun virtuaalikone käynnistyy, hypervisor kertoo sille:

• Oma IP-osoite.
• Oletusreitti kulkee vRouterin IP-osoitteen kautta tässä verkossa.

Hypervisor raportoi vRouterille erityisen API:n kautta:

• Mitä tarvitset virtuaalisen käyttöliittymän luomiseen.
• Millaisen virtuaalisen verkon sen (VM) tarvitsee luoda?
• Mihin VRF:iin (VN) se tulee sitoa.
• Staattinen ARP-merkintä tälle VM:lle - mikä liitäntä on sen IP-osoitteen takana ja mihin MAC-osoitteeseen se liittyy.

Jälleen varsinaista vuorovaikutusmenettelyä on yksinkertaistettu käsitteen ymmärtämisen vuoksi.

Siten vRouter näkee kaikki tietyn koneen yhden asiakkaan VM:t suoraan yhdistettyinä verkkoina ja voi itse reitittää niiden välillä.

Mutta VM0 ja VM1 kuuluvat eri asiakkaille ja ovat vastaavasti eri vRouter-taulukoissa.

Se, pystyvätkö ne kommunikoimaan keskenään, riippuu suoraan vRouterin asetuksista ja verkon suunnittelusta.
Jos esimerkiksi molempien asiakkaiden virtuaalikoneet käyttävät julkisia osoitteita tai NAT esiintyy itse vRouterissa, suora reititys vRouteriin voidaan tehdä.

Päinvastaisessa tilanteessa on mahdollista ylittää osoiteavaruudet - sinun täytyy käydä NAT-palvelimen läpi saadaksesi julkisen osoitteen - tämä on samanlainen kuin ulkoisten verkkojen käyttäminen, joita käsitellään alla.

Viestintä eri fyysisille koneille sijaitsevien virtuaalikoneiden välillä

Datataso

1. Alku on täsmälleen sama: VM-0 lähettää paketin, jonka oletusarvo on VM-7 (172.17.3.2).
2. vRouter vastaanottaa sen ja näkee tällä kertaa, että kohde on eri koneessa ja siihen pääsee Tunnel0:n kautta.
3. Ensinnäkin se ripustaa MPLS-tarran, joka tunnistaa etäliittymän, jotta vRouter voi kääntöpuolelle määrittää, mihin tämä paketti sijoitetaan ilman lisähakuja.

   

4. Tunnel0:n lähde on 10.0.0.2, kohde: 10.0.1.2.
   vRouter lisää GRE (tai UDP) otsikot ja uuden IP:n alkuperäiseen pakettiin.
5. vRouter-reititystaulukossa on oletusreitti ToR1-osoitteen 10.0.0.1 kautta. Sinne hän sen lähettää.

   
   

6. ToR1 Underlay-verkon jäsenenä tietää (esimerkiksi OSPF:n kautta) kuinka päästä 10.0.1.2:een ja lähettää paketin reitin varrella. Huomaa, että ECMP on käytössä täällä. Kuvassa on kaksi nexthopia, joihin eri säikeet lajitellaan hashin mukaan. Todellisen tehtaan tapauksessa tulee todennäköisemmin 4 nexthopia.

   Samaan aikaan hänen ei tarvitse tietää, mitä ulkoisen IP-otsikon alla on. Toisin sanoen IP:n alla voi olla IPv6:n kerros MPLS:n yli Ethernetin yli MPLS:n yli GRE:n yli Kreikan yli.

7. Vastaanottavalta puolelta vRouter poistaa GRE:n ja MPLS-tunnisteen avulla ymmärtää, mihin rajapintaan tämä paketti tulee lähettää, poistaa sen ja lähettää sen alkuperäisessä muodossaan vastaanottajalle.

Ohjaustaso

Kun käynnistät auton, tapahtuu sama asia kuin edellä on kuvattu.

Ja lisäksi seuraavat:

• Jokaiselle asiakkaalle vRouter varaa MPLS-tunnisteen. Tämä on L3VPN-palvelutarra, jolla asiakkaat erotetaan samassa fyysisessä koneessa.
  

  Itse asiassa vRouter varaa MPLS-tunnisteen aina ehdoitta - eihän sitä etukäteen tiedetä, että kone on vuorovaikutuksessa vain muiden saman vRouterin takana olevien koneiden kanssa, eikä tämä todennäköisesti ole edes totta.

• vRouter muodostaa yhteyden SDN-ohjaimeen käyttämällä BGP-protokollaa (tai vastaavaa - TF:n tapauksessa tämä on XMPP 0_o).
• Tämän istunnon aikana vRouter raportoi reitit yhdistettyihin verkkoihin SDN-ohjaimelle:
  • Verkko-osoite
  • Kapselointimenetelmä (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-asiakastunniste
  • IP-osoitteesi nexthopina

• SDN-ohjain vastaanottaa tällaiset reitit kaikilta kytketyiltä vRouterilta ja heijastaa ne muille. Eli se toimii reittiheijastajana.

Sama tapahtuu vastakkaiseen suuntaan.

Peittokuva voi vaihtua vähintään minuutin välein. Näin tapahtuu suunnilleen julkisissa pilvissä, joissa asiakkaat käynnistävät ja sammuttavat virtuaalikoneensa säännöllisesti.

Keskusohjain hoitaa kaiken monimutkaisen konfiguroinnin ylläpidon ja vRouterin kytkentä-/reititystaulukoiden valvonnan.

Karkeasti sanottuna ohjain kommunikoi kaikkien vRouterien kanssa BGP:n (tai vastaavan protokollan) kautta ja yksinkertaisesti lähettää reititystiedot. Esimerkiksi BGP:llä on jo Address-Family, joka välittää kapselointimenetelmän MPLS-in-GRE tai MPLS-UDP:ssä.

Samaan aikaan Underlay-verkon konfiguraatio ei muutu millään tavalla, mikä on muuten paljon vaikeampaa automatisoida ja helpompi rikkoa hankalalla liikkeellä.

Poistuminen ulkomaailmaan

Jossain simulaation on loputtava, ja sinun on poistuttava virtuaalimaailmasta todelliseen maailmaan. Ja tarvitset yleisöpuhelinyhdyskäytävän.

Käytössä on kaksi lähestymistapaa:

1. Laitteistoreititin on asennettu.
2. Lanseerataan laite, joka toteuttaa reitittimen toiminnot (kyllä, SDN:n jälkeen kohtasimme myös VNF:n). Kutsutaan sitä virtuaaliyhdyskäytäväksi.

Toisen lähestymistavan etuna on halpa vaakasuuntainen skaalautuvuus - tehoa ei ole tarpeeksi - julkaisimme toisen virtuaalikoneen yhdyskäytävällä. Millä tahansa fyysisellä koneella, ilman, että sinun tarvitsee etsiä ilmaisia ​​telineitä, yksiköitä, tehoa, ostaa itse laitteisto, kuljettaa, asentaa, vaihtaa, konfiguroida ja sitten myös vaihtaa viallisia komponentteja.

Virtuaaliyhdyskäytävän huonoina puolina on, että fyysisen reitittimen yksikkö on silti suuruusluokkaa tehokkaampi kuin moniytiminen virtuaalikone ja sen omaan laitteistopohjaansa räätälöity ohjelmisto toimii paljon vakaammin (ei). On myös vaikea kiistää sitä tosiasiaa, että laitteisto- ja ohjelmistokompleksi yksinkertaisesti toimii ja vaatii vain konfigurointia, kun taas virtuaalisen yhdyskäytävän käynnistäminen ja ylläpito on vahvojen insinöörien tehtävä.

Yhdyskäytävä katsoo yhdellä jalalla Overlay-virtuaaliverkkoon, kuten tavallinen virtuaalikone, ja voi olla vuorovaikutuksessa kaikkien muiden virtuaalikoneiden kanssa. Samalla se voi katkaista kaikkien asiakkaiden verkot ja vastaavasti suorittaa reitityksen niiden välillä.

Toisella jalallaan yhdyskäytävä katsoo runkoverkkoon ja tietää kuinka päästä Internetiin.

Datataso

Eli prosessi näyttää tältä:

1. VM-0, oletuksena sama vRouter, lähettää paketin, jonka kohde on ulkomaailmassa (185.147.83.177) eth0-liittymään.
2. vRouter vastaanottaa tämän paketin ja etsii kohdeosoitteen reititystaulukosta - löytää oletusreitin VNGW1-yhdyskäytävän kautta tunnelin 1 kautta.
   Hän näkee myös, että tämä on GRE-tunneli, jossa on SIP 10.0.0.2 ja DIP 10.0.255.2, ja hänen on myös ensin liitettävä tämän asiakkaan MPLS-tunniste, jota VNGW1 odottaa.
3. vRouter pakkaa alkuperäisen paketin MPLS:llä, GRE:llä ja uusilla IP-otsikoilla ja lähettää sen oletuksena ToR1 10.0.0.1:een.
4. Taustalla oleva verkko toimittaa paketin yhdyskäytävälle VNGW1.
5. VNGW1-yhdyskäytävä poistaa GRE- ja MPLS-tunnelointiotsikot, näkee kohdeosoitteen, tarkastelee reititystaulukkoa ja ymmärtää, että se on ohjattu Internetiin - eli koko näkymän tai oletusnäkymän kautta. Suorittaa tarvittaessa NAT-käännöksen.
6. VNGW:stä rajalle voi olla tavallinen IP-verkko, mikä on epätodennäköistä.
   Voi olla klassinen MPLS-verkko (IGP+LDP/RSVP TE), taustakangas BGP LU:lla tai GRE-tunneli VNGW:stä rajalle IP-verkon kautta.
   Oli miten oli, VNGW1 suorittaa tarvittavat kapseloinnit ja lähettää alkupaketin kohti rajaa.

Vastakkaiseen suuntaan kulkeva liikenne kulkee samojen portaiden läpi päinvastaisessa järjestyksessä.

1. Raja pudottaa paketin VNGW1:een
2. Hän riisuu hänet, katsoo vastaanottajan osoitetta ja näkee, että hän on tavoitettavissa Tunnel1-tunnelin (MPLSoGRE tai MPLSoUDP) kautta.
3. Vastaavasti se liittää MPLS-tunnisteen, GRE/UDP-otsikon ja uuden IP-osoitteen ja lähettää sen ToR3 10.0.255.1:een.
   Tunnelin kohdeosoite on vRouterin IP-osoite, jonka takana kohde-VM sijaitsee - 10.0.0.2.
4. Taustalla oleva verkko toimittaa paketin haluttuun vRouteriin.
5. Kohde-vRouter lukee GRE/UDP:n, määrittää liitännän MPLS-tunnisteen avulla ja lähettää paljaan IP-paketin TAP-liitäntäänsä, joka liittyy VM:n eth0:aan.

Ohjaustaso

VNGW1 perustaa BGP-naapuruuden SDN-ohjaimen kanssa, josta se saa kaikki reititystiedot asiakkaista: mikä IP-osoite (vRouter) on minkä asiakkaan takana ja millä MPLS-tunnisteella se tunnistetaan.

Samoin hän itse ilmoittaa SDN-ohjaimelle oletusreitin tämän asiakkaan tunnisteella ja ilmoittaa itsensä nexthopiksi. Ja sitten tämä oletusarvo saapuu vRoutersiin.

VNGW:llä tapahtuu yleensä reittien yhdistäminen tai NAT-käännös.

Ja toiseen suuntaan se lähettää täsmälleen tämän kootun reitin istuntoon reunoilla tai reittiheijastimilla. Ja heiltä se saa oletusreitin tai Full-View'n tai jotain muuta.

Kapseloinnin ja liikenteen vaihdon suhteen VNGW ei eroa vRouterista.
Jos laajennat hieman, voit lisätä muita verkkolaitteita VNGW- ja vRoutereihin, kuten palomuurit, liikenteen puhdistus- tai rikastustilat, IPS ja niin edelleen.

Ja peräkkäisen VRF:n luomisen ja oikean reittien ilmoittamisen avulla voit pakottaa liikenteen kiertämään haluamallasi tavalla, jota kutsutaan palveluketjuksi.

Eli tässäkin SDN-ohjain toimii Route-Reflektorina VNGW:iden, vRouterien ja muiden verkkolaitteiden välillä.

Mutta itse asiassa ohjain julkaisee myös tietoja ACL:stä ja PBR:stä (Policy Based Routing), jolloin yksittäiset liikennevirrat kulkevat eri tavalla kuin reitti kertoo.

FAQ

Miksi teet aina GRE/UDP-huomautuksen?

No, yleisesti ottaen tämän voidaan sanoa olevan ominaista Tungsten Fabricille - sinun ei tarvitse ottaa sitä ollenkaan huomioon.

Mutta jos otamme sen, TF itse, ollessaan vielä OpenContrail, tuki molempia kapselointeja: MPLS GRE:ssä ja MPLS UDP:ssä.

UDP on hyvä, koska Source Portissa on erittäin helppo koodata sen otsikkoon hajautusfunktio alkuperäisestä IP+Proto+Portista, jonka avulla voit tehdä tasapainotuksen.

GRE:n tapauksessa valitettavasti on vain ulkoiset IP- ja GRE-otsikot, jotka ovat samat kaikessa kapseloidussa liikenteessä, eikä tasapainotuksesta puhuta - harvat voivat katsoa niin syvälle paketin sisään.

Kunnes jonkin aikaa reitittimet, jos he osasivat käyttää dynaamisia tunneleita, tekivät niin vain MPLSoGRE:ssä, ja vasta aivan äskettäin he oppivat käyttämään MPLSoUDP:tä. Siksi meidän on aina tehtävä huomautus kahden erilaisen kapseloinnin mahdollisuudesta.

Rehellisyyden nimissä on syytä huomata, että TF tukee täysin L2-liitettävyyttä VXLANin avulla.

Lupasit vetää yhtäläisyyksiä OpenFlow'n kanssa.
He todella pyytävät sitä. vSwitch samassa OpenStackissa tekee hyvin samankaltaisia ​​asioita käyttämällä VXLANia, jossa muuten on myös UDP-otsikko.

Datatasossa ne toimivat suunnilleen samalla tavalla, ohjaustaso eroaa merkittävästi. Tungsten Fabric käyttää XMPP:tä reititystietojen toimittamiseen vRouteriin, kun taas OpenStack käyttää Openflowa.

Voitko kertoa minulle hieman enemmän vRouterista?
Se on jaettu kahteen osaan: vRouter Agent ja vRouter Forwarder.

Ensimmäinen toimii isäntäkäyttöjärjestelmän käyttäjätilassa ja kommunikoi SDN-ohjaimen kanssa vaihtaen tietoja reiteistä, VRF:istä ja ACL:istä.

Toinen toteuttaa Data Planen - yleensä Kernel Spacessa, mutta voi toimia myös SmartNIC:illä - verkkokortteja, joissa on prosessori ja erillinen ohjelmoitava kytkentäsiru, jonka avulla voit poistaa kuormituksen isäntäkoneen prosessorista ja tehdä verkosta nopeamman ja enemmän. ennustettavissa.

Toinen mahdollinen skenaario on, että vRouter on DPDK-sovellus User Spacessa.

vRouter Agent lähettää asetukset vRouter Forwarderille.

Mikä on virtuaaliverkko?
Mainitsin VRF-artikkelin alussa, että jokainen vuokralainen on sidottu omaan VRF:ään. Ja jos tämä riitti pintaverkon toiminnan ymmärtämiseen, niin seuraavassa iteraatiossa on tehtävä selvennykset.

Tyypillisesti virtualisointimekanismeissa Virtual Network entiteetti (voit pitää tätä oikeana substantiivina) esitellään erillään asiakkaista/vuokralaisista/virtuaalisista koneista - täysin itsenäinen asia. Ja tämä virtuaaliverkko voidaan jo liittää rajapintojen kautta yhteen vuokralaiseen, toiseen, kahteen tai mihin tahansa. Joten esimerkiksi palveluketjutus toteutetaan, kun liikenne on ohjattava tiettyjen solmujen läpi vaaditussa järjestyksessä, yksinkertaisesti luomalla ja yhdistämällä Virtuaaliverkkoja oikeassa järjestyksessä.

Näin ollen virtuaaliverkon ja vuokralaisen välillä ei ole suoraa kirjeenvaihtoa.

Johtopäätös

Tämä on hyvin pinnallinen kuvaus virtuaaliverkon toiminnasta, jossa on peitto isännästä ja SDN-ohjaimesta. Mutta riippumatta siitä, minkä virtualisointialustan valitset tänään, se toimii samalla tavalla, oli se sitten VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric tai Juniper Contrail. Ne eroavat toisistaan ​​kapselointi- ja otsikkotyypeissä, protokollissa tiedon välittämiseksi pääteverkkolaitteisiin, mutta periaate ohjelmistokonfiguroitavasta peittoverkosta, joka toimii suhteellisen yksinkertaisen ja staattisen pohjaverkon päällä, säilyy samana.
Voimme sanoa, että nykyään peittoverkkoon perustuva SDN on voittanut yksityisen pilven luomisen. Tämä ei kuitenkaan tarkoita, etteikö Openflow:lla olisi sijaa nykymaailmassa - sitä käytetään OpenStackessa ja samassa VMWare NSX:ssä, tietääkseni Google käyttää sitä maanalaisen verkon perustamiseen.

Alla olen antanut linkkejä tarkempiin materiaaleihin, jos haluat perehtyä asiaan tarkemmin.

Entä meidän aluskate?

Mutta yleisesti ottaen ei mitään. Hän ei muuttanut koko tietä. Hänen tarvitsee vain päivittää reitit ja ARP:t isännästä tulevan peiton tapauksessa, kun vRouter/VNGW ilmestyy ja katoaa ja kuljettaa paketteja niiden välillä.

Muodostetaan luettelo vaatimuksista Underlay-verkolle.

1. Osaa käyttää jonkinlaista reititysprotokollaa, meidän tilanteessamme - BGP.
2. Laaja kaistanleveys, mieluiten ilman ylitilausta, jotta paketit eivät katoa ylikuormituksen takia.
3. ECMP:n tuki on olennainen osa kangasta.
4. Pystyä tarjoamaan QoS, mukaan lukien hankalat asiat, kuten ECN.
5. NETCONFin tukeminen on perusta tulevaisuudelle.

Käytin täällä hyvin vähän aikaa itse Underlay-verkoston työhön. Tämä johtuu siitä, että myöhemmin sarjassa keskityn siihen, ja käsittelemme Overlaya vain ohimennen.

Ilmeisesti rajoitan vakavasti meitä kaikkia käyttämällä esimerkkinä Clozin tehtaaseen rakennettua DC-verkkoa, jossa on puhdas IP-reititys ja isäntäpäällystys.

Olen kuitenkin varma, että mikä tahansa verkko, jolla on suunnittelu, voidaan kuvata muodollisesti ja automatisoida. Tavoitteeni on vain ymmärtää lähestymistapoja automaatioon, eikä hämmentää kaikkia ratkaisemalla ongelman yleisessä muodossa.

Osana ADSM:ää Roman Gorge ja minä suunnittelemme julkaisevamme erillisen numeron laskentatehon virtualisoinnista ja sen vuorovaikutuksesta verkon virtualisoinnin kanssa. Pysyä yhteydessä.

Hyödyllisiä linkkejä

• Volframikangasarkkitehtuuri.
• Tietoja:pilvi. 6 tuntia Yandex.Cloudista, joka kattaa myös TF:n virtuaalisen verkon.
• Mikä on Open vSwitch?
• Johdatus VxLANiin.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Kehys virtualisoitujen kerroksen 2 verkkojen päällekkäisyyteen Layer 3 verkkojen yli.
  
• Scaleway lähestymistapa VXLAN EVPN -kankaaseen. Se puhuu koko DC-verkosta, mukaan lukien Underlay, Overlay, lähestymistavat useisiin kohteisiin ja hallintaan.

Kiitos

• Roman Gorga - Linkmeup podcastin entinen isäntä ja nyt pilvialustojen asiantuntija. Kommentteja ja muokkauksia varten. No, odotamme hänen syvällisempää artikkelia virtualisoinnista lähitulevaisuudessa.
• Aleksanteri Šalimov - kollegani ja virtuaaliverkkojen kehittämisen asiantuntija. Kommentteja ja muokkauksia varten.
• Valentin Sinitsyn - kollegani ja volframikankaan asiantuntija. Kommentteja ja muokkauksia varten.
• Artjom Tšernobay — kuvittaja linkmeup. KDPV:lle.
• Aleksanteri Limonov. "Automaatti"-meemille.

Lähde: will.com