V eelmises väljaandes ma kirjeldasin võrgu automatiseerimise raamistikku. Tagasiside põhjal on paljude jaoks isegi see esimene lähenemine probleemile aidanud küsimusi selgemaks muuta. Ja see teeb mind väga rõõmsaks, sest meie eesmärk selles tsüklis ei ole katta Ansible'i Python'i skriptidega, vaid luua süsteem.

Sama raamistik seab sihi, mille järgi me teemaga tegelema hakkame.
Ja veebivõrgu virtualiseerimine, millele see väljaanne keskendub, ei sobi eriti ADSMi temaatikaga, kus me käsitleme automatiseerimist.

Aga vaatame sellele teisele nurga alt.

Paljud teenused kasutavad juba ammu ühte võrku. Sideoperaatori puhul on need 2G, 3G, LTE, kiudoptiline internet ja B2B, näiteks. Andmekeskuse puhul: ühenduvus erinevatele klientidele, internet, plokkhäiring ja objektihäiring.

Ja kõik teenused vajavad üksteisest isoleerimist. Nii tekkisid kihi võrguühendused.

Ja kõik teenused ei soovi oodata, kuni inimene suudab neid käsitsi seadistada. Nii tekkisid orkestritorid ja SDN.

Esimene samm võrgu süsteemsetesse automatiseerimisse, täpsemalt selle osasse, on ammu astutud ja paljudes kohtades ellu viidud: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Just sellest täna ka räägime.

Sisu

• Põhjused
• Terminoloogia
• Underlay — füüsiline võrk
• Overlay — virtuaalne võrk
  • Overlay ToR’ist
  • Overlay hostist
  • Tungsten Fabric'i näitel
    • Kommunikatsioon ühe füüsilise masina sees
    • Kommunikatsioon erinevates füüsilistes masinates paiknevate VM-ide vahel
    • Välismaailma pääsemine

• KKK
• Kokkuvõte
• Kasulikud lingid

Põhjused

Ja kuna me sellest rääkisime, tasub mainida ka võrgu virtualiseerimise eeltingimusi. Tegelikult algas see protsess mitte eile.

Tõenäoliselt olete kuulnud, et võrk on alati olnud kõige inertsem osa igast süsteemist. Ja see on tõsi igas mõttes. Võrk on alus, millele kõik toetub, ja muudatusi on seal suhteliselt keeruline teha — teenused ei talu, kui võrk on maas. Tihti võib ühe sõlme väljakutsumine kokku varustada suure osa rakendustest ja mõjutada paljusid kliente. Osaliselt seetõttu võivad võrgu meeskonnad igasugustele muudatustele vastu seista — sest praegu töötab see kuidagi (me ei pruugi isegi teada, kuidas)), aga siia tuleb midagi uut seadistada ja pole teada, kuidas see võrku mõjutab.

Kuna ei taha oodata, millal võrgu spetsialistid VLAN-i seadistavad, ja et igasuguseid teenuseid ei peaks iga võrgusõlme peal registreerima, hakkasid inimesed kasutama overlay'sid — kattuvaid võrke — millel on suur mitmekesisus: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE jne.

Nende atraktiivsus seisneb kahes lihtsas asjas:

• Seadistatakse ainult lõpp-punktid — transiidipunkte ei pea muutma. See kiirendab protsessi märkimisväärselt ja mõnikord võimaldab isegi välistada võrgu infrastruktuuri osakonna uute teenuste sisestamise protsessist.
• Koormus on peidetud sügavale pealkirjadesse — transiidipunktidel ei pea olema sellest midagi teadma, hostide aadressimisest, overlay-võrgu marsruutidest. See tähendab, et tuleb hoida vähem teavet tabelites, seega võiks kasutada lihtsamat/odavamat seadet.

Selles mitte täiesti täielikus väljaandes ei plaani ma käsitleda kõiki võimalikke tehnoloogiaid, vaid pigem kirjeldada overlay-võrkude toimimise fookust andmekeskuses.

Kogu sari kirjeldab andmekeskust, mis koosneb ühesugustest rack'idest, kus on paigaldatud samasugune serveritehnika.

Sellel seadmel töötavad virtuaalmasinad/konteinerid/serversioonid, mis rakendavad teenuseid.

Terminoloogia

Tsüklis serveriga kutsun ma programmi, mis rakendab serveripoolset kliendiserveri suhtlust.

Füüsilisi masinaid riiulites nimetame serveriteks ei nii et teeme.

Füüsiline masin on x86-arvuti, mis on paigaldatud riiulisse. Kõige sagedamini kasutame terminit host. Nii nimetame seda «masin» või host.

Hüpervisor on rakendus, mis töötab füüsilisel masinal ja emuleerib füüsilisi ressursse, millel töötavad virtuaalmasinad. Mõnikord kasutatakse kirjanduses ja veebis sõna «hüpervisor» sünonüümina «hostile».

Virtuaalne masin on operatsioonisüsteem, mis töötab füüsilisel masinal hüpervisori kohal. Meie jaoks käesolevas tsüklis ei ole väga oluline, kas see on tõeliselt virtuaalne masin või lihtsalt konteiner. Nimetame seda «VM«

Tenant on lai mõisted, mille ma selles artiklis defineerin kui eraldi teenuse või eraldi kliendi.

Mitmeüürilisus või multitenantsus — sama rakenduse kasutamine erinevate klientide/teenuste poolt. Sel juhul saavutatakse klientide isoleerimine üksteisest rakenduse arhitektuuri kaudu, mitte eraldi käivitatud eksemplaride.

ToR — Racki ülaosa lüliti — lüliti, mis on paigaldatud riiulisse, kuhu on ühendatud kõik füüsilised masinad.

Lisaks ToR-topoloogiale praktiseerivad erinevad teenusepakkujad End of Row (EoR) või Middle of Row (kuigi viimane on haruldane ja lühendit MoR ma ei ole kohanud).

Alusvõrk või alusvõrk või underlay — füüsiline võrgu infrastruktuur: lülitid, ruuterid, kaablid.

Kihivõrk või kihivõrk või overlay — virtuaalne tunnelivõrk, mis töötab füüsilise üle.

L3-tehas või IP-tehas — inimkonna hämmastav leiutis, mis võimaldab intervjuudes mitte korduda STP ja mitte õppida TRILL. Kontseptsioon, kus kogu võrk kuni juurdepääsu tasemeni on rangelt L3, ilma VLAN-ideta ja seega tohutute ulatuslike levitamisdomaanideta. Kust see sõna „tehas” siia tuleb, arutame järgmises osas.

SDN — Tarkvaradefined Network. Sellel on keeruline tutvustus. See on lähenemine võrguhaldusele, kus võrgumuudatused teostatakse mitte inimese, vaid programmi abil. See tähendab tavaliselt juhtimisplaani viimist lõppvõrgu seadmete piiridest välja kontrollerile.

NFV — Network Function Virtualization — võrguseadmete virtuaaliseerimine, mis eeldab, et osa võrgu funktsioone saab käivitada virtuaalmasinate või konteinerite kujul, et kiirendada uute teenuste juurutamist, korraldada teenuste kettamist ja võimaldada lihtsamat horisontaalset skaleeritavust.

VNF — Virtuaalne Võrgufunktsioon. Konkreetselt virtuaalne seade: marsruuter, lüliti, tulemüür, NAT, IPS/IDS jne.

Ma praegu tahtlikult lihtsustan kirjeldust konkreetse rakenduse tasemele, et mitte lugejat liiga segadusse ajada. Sügavamaks lugemiseks suunan teda jaotisse Lingid. Lisaks lubab Roma Gorge, kes kritiseerib seda artiklit ebatäpsuste tõttu, kirjutada eraldi väljaande serverite ja võrkude virtuaaliseerimise tehnoloogiatest, mis oleks põhjalikum ja detailidele tähelepanelikum.

Enamik tänapäeva võrke saab selgelt jagada kaheks osaks:

Alus — füüsiline võrk stabiilse konfigureerimisega.
Peal — abstraktsioon Underlay üle, et isoleerida rentnikke.

See kehtib nii DC (mida me selles artiklis arutame) kui ka ISP kohta (mida me ei arutata, kuna see on juba kajastatud SDSN). Ettevõttevõrkude puhul on olukord muidugi mõnevõrra erinev.

Pilt, mis keskendub võrgule:

Alus

Underlay on füüsiline võrk: riistvaralised lülitid ja kaablid. Seadmed underlay's teavad, kuidas füüsilistele masinatele ligi pääseda.

See tugineb standardsetele protokollidele ja tehnoloogiatele. Mitte vähem tähtis on see, et riistvaraseadmed töötavad endiselt patenteeritud tarkvaraga, mis ei võimalda ei kiipide programmeerimist ega oma protokollide rakendamist, seega on vajalik koostalitlusvõime teiste tootjatega ja standardimine.

Aga keegi nagu Google võib endale lubada oma lülitite arendamist ja üleüldiselt kehtivatest protokollidest loobumist. Aga LAN_DC ei ole Google.

Underlay muutub võrreldes harva, kuna selle ülesanne on baasil IP-ühenduvus füüsiliste masinate vahel. Underlay ei tea midagi teenustest, klientidest või rentnikest, mis selle peal töötavad — see peab lihtsalt toimetama paketi ühest masinast teise.
Underlay võib olla näiteks selline:

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

Underlay võrgustik seadistatakse klassikaliselt: CLI/GUI/NETCONF.

Käe otsas, skriptide abil, patentidega utiliitide kaudu.

Järgmine artikkel tsüklist keskendub Underlay’le põhjalikumalt.

Peal

Overlay — virtuaalne tunnelite võrk, mis on venitatud üle Underlay, võimaldab ühel kliendil olevatel VM-del omavahel suhelda, samas tagades isolatsiooni teiste klientide eest.

Kliendi andmed kapseldatakse mingitesse tunnelite pealkirjadesse, et edastada neid ühise võrgu kaudu.

Seega saavad ühe kliendi (ühe teenuse) VM-d omavahel suhelda läbi Overlay, isegi mitte aimates, millist teed pakett tegelikult läbib.

Overlay võib näiteks olla selline, nagu juba varem mainisin:

• GRE-tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVE

Overlay’ne võrk seadistatakse ja hallatakse tavaliselt keskse kontrolleri kaudu. Sealt edastatakse konfiguratsioon, Control Plane ja Data Plane seadmetele, mis tegelevad klientide liikluse marsruutimise ja kapseldamisega. Natuke allpool kahelt näidiselt lahkame seda.

Jah, see on puhtaim SDN.

On kaks põhimõtteliselt erinevat lähenemist Overlay-võrgu korraldamiseks:

1. Overlay ToR’ist
2. Overlay hostist

Overlay ToR’ist

Overlay võib alata juurdepääsu lülitilt (ToR), mis asub rack'is, nagu näiteks VXLAN-fabriku puhul.

See on aja jooksul tõestatud mehhanism ISP-võrkudes ning kõik võrguvarustuse tarnijad toetavad seda.

Kuid sel juhul peab ToR-lüliti suutma eristada erinevaid teenuseid, mistõttu peab võrguadministraator teatud määral koostööd tegema virtuaalmasinate administraatoritega ning tegema seadmete konfiguratsioonis muudatusi (kuigi automaatselt).

Siin suunan lugeja artikli juurde VxLAN Habrisse meie vanale sõbrale @bormoglotx.
Selles ENOG esitlus kus on põhjalikult kirjeldatud andmekeskuse võrgu ehitamise lähenemisviise EVPN VXLAN fabriku abil.

Ja põhjalikumaks sukeldumiseks reaalsusesse, võib lugeda Ciscose raamatut A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Tähendan, et VXLAN on vaid kapseldamismeetod ja tunnelite terminatsioon võib toimuda mitte ToR'il, vaid hostis, nagu näiteks OpenStacki puhul.

Siiski, VXLAN-fabrika, kus overlay algab ToR'il, on üks rajatud ooperiverkko disainide seas.

Overlay hostist

Teine lähenemine on alustada ja terminiseerida tunnelid lõpp-hostidel.
Sel juhul jääb võrk (Underlay) võimalikult lihtsaks ja statiiliseks.
Ja host teeb kõik vajalikud kapseldamised ise.

Selleks tuleb kindlasti käivitada spetsiaalne rakendus hostides, kuid see on seda väärt.

Esiteks on kliendi käivitamine Linuxi masinas lihtsam või, ütleme nii, — tegelikult võimalik — samas, kui lülitil tuleb tõenäoliselt veel kasutada patentitud SDN-lahendusi, mis rikub mitme müüja ideed.

Teiseks saab ToR-lüliti jätta sel juhul maksimaalselt lihtsaks, nii Control Plane’i kui ka Data Plane’i vaatenurgast. Tõepoolest — SDN-kontrolleriga ei pea ta siis suhtlema, ja kõikide ühendatud klientide võrgud/ARP-d hoidmine ei ole samuti vajalik — piisab füüsilise masina IP-aadressist, mis lihtsustab märkimisväärselt teeliste jaotustabelit.

ADSMi seerias valin hostist lähtuva overlay lähenemise — edaspidi räägime ainult sellest ja ei naase VXLAN-fabriku juurde.

Kõige lihtsam on vaadata näidete kaudu. Ja katsealuseks võtame OpenSource SDN platvormi OpenContrail, mis on nüüd tuntud kui Tungsten Fabric.

Artikulu lõpus jagan mõningaid mõtteid OpenFlow'i ja OpenvSwitch'i analoogia kohta.

Tungsten Fabric'i näitel

Igal füüsilisel masinal on vRouter — virtuaalne marsruuter, mis teab sellest, millised võrgud on sellele ühendatud ja kellele need kuuluvad — põhimõtteliselt PE-marsruuter. Iga kliendi jaoks haldab ta isoleeritud marsruutimistabelit (loe: VRF). Ja just vRouter teeb Overlay tunnelimise.

Täpsemalt vRouter'i kohta — artikli lõpus.

Iga VM, mis asub hüpervisoril, ühendub selle masina vRouter'iga läbi TAP-liidese.

TAP — Terminal Access Point — virtuaalne liides Linux'i tuumas, mis võimaldab võrguside loomist.

Kui vRouter'i taga on mitu võrku, siis igale neist luuakse virtuaalne liides, millele määratakse IP-aadress — see on vaikimisi värava aadress.
Kõik ühe kliendi võrgud paigutatakse ühte VRF (üks tabel), erinevad — erinevatesse.
Tee siia täiendav märkus, et kõik pole nii lihtne, ja suunan uudishimu teatav lugeja artikli lõppu..

Kuna vRouter’id saaksid omavahel suhelda ning seega ka nende taga olevad VM’id, vahetavad nad marsruudiinfot läbi SDN-kontroller.

Et välja maailmale pääseda, on olemas väljumispunkt - virtuaalvõrgu värav VNGW — Virtuaalvõrgu värav (termin mu käes).

Vaadakem nüüd suhtluse näiteid — ja siis on kõik selge.

Kommunikatsioon ühe füüsilise masina sees

VM0 soovib saata paketti VM2-le. Eeldame, et need on ühe kliendi VM-id.

Andmeplaneet

1. VM-0-l on määratud vaike marsruut oma liidesele eth0. Pakett saadetakse sinna.
   See liides eth0 on tegelikult virtuaalselt ühendatud virtuaalruuteriga vRouter TAP-liidese tap0 kaudu.
2. vRouter analüüsib, millisele liidesele pakett saabus, s.t. kellele (VRF) see kuulub, ja kontrollib saaja aadressi selle kliendi marsruuditabelist.
3. Leides, et saaja on samal masinal teisel pordil, saadab vRouter paketi sinna ilma täiendavate pealkirjadeta — selle jaoks on vRouter’il juba olemas ARP-kirje.

Sel juhul ei jõua pakett füüsilisse võrku — see marsruutitakse vRouter’i sees.

Kontrolli küngas

Hüperviisor teatab virtuaalmasinale selle käivitamisel:

• Tema oma IP-aadress.
• Vaikimisi marsruut on läbi vRouteri IP-aadressi selles võrgus.

vRouterile edastab hüperviisor spetsiaalse API kaudu:

• Et luua virtuaalne liides.
• Millist Virtuaalset Võrku tuleb tal (VM) luua.
• Millise VRF-iga selle (VN) seondada.
• Statiline ARP-kirje selle VM-i jaoks — millise liidese taga on tema IP-aadress ja millisele MAC-aadressile see on seotud.

Ja taas, tegelik interaktsiooni protseduur on lihtsustatud, et mõista kontseptsiooni.

Nii näeb kõikide kliendi VM-id sama masina vRouteris otseselt ühendatud võrkudena ning saab ise nende vahel marsruuti muuta.

Kuid VM0 ja VM1 kuuluvad erinevatele klientidele, seega on need erinevates vRouteri tabelites.

Kas nad saavad omavahel otse suhelda, sõltub vRouteri seadistustest ja võrgu disainist.
Näiteks, kui mõlemad kliendi VM-id kasutavad avalikke aadresse, või NAT toimub vRouteril endal, on võimalik teha ka otsene marsruutimine vRouterile.

Teises olukorras võib aadressiruumi ülekandumine juhtuda — on vajalik minna NAT-serveri kaudu, et saada avalik aadress — see sarnaneb välistele võrkudele, millele allpool viidatakse.

Kommunikatsioon erinevates füüsilistes masinates paiknevate VM-ide vahel

Andmeplaneet

1. Algus on sama: VM-0 saadab paketi adressaadile VM-7 (172.17.3.2) oma vaikeseade kaudu.
2. vRouter saab selle ja näeb, et adressaat asub teisel masinal ning on saadaval Tunnel0 kaudu.
3. Esmalt kätkeb ta MPLS-märki, mis identifitseerib kaugliidese, et vRouter saaks vastaspoolel määrata, kuhu see pakett paigutada, ilma täiendavate väänamisteta.

   

4. Tunnel0-l on allikaaadress 10.0.0.2 ja sihtkoht: 10.0.1.2.
   vRouter lisab algsele paketile GRE (või UDP) päised ja uue IP.
5. vRouteri marsruutimistabelis on vaike marsruut ToR1 aadressi kaudu 10.0.0.1. Just sinna ta saadab.

   
   

6. ToR1, kui Underlay võrgu osaleja, teab (näiteks OSPF-i kaudu), kuidas jõuda aadressini 10.0.1.2, ja saadab paketi marsruudile. Pange tähele, et siin aktiveeritakse ECMP. Illustratsioonil on kaks järgmise hüppena, ja erinevad vood jaotuvad nendesse vastavalt häkkimisele. Tõelise tehase puhul oleks siin pigem 4 järgmise hüppena.

   Samas ei pea ta teadma, mis asub välise IP-pealkirja all. Tegelikult võib IP all olla segu IPv6-st MPLS-i kaudu Ethernet'i kaudu MPLS-i kaudu GRE kaudu.

7. Seega vastuvõtupooles vRouter eemaldab GRE ja MPLS-märgistuse põhjal mõistab, millisele liidesele see pakett suunata, eraldab selle ja saadab algses vormis adressaadile.

Kontrolli küngas

Masina töötamise käivitamisel toimub kõik see, mis on eelnevalt kirjeldatud.

Ja lisaks veel järgmine:

• Iga kliendi jaoks eraldab vRouter MPLS-märgistuse. See on L3VPN teenusmärgis, mille alusel kliendid jagunetakse ühe füüsilise masina piires.
  

  Tegelikult eraldab vRouter MPLS-märgistuse alati — kuna ei ole ette teada, et masin suhtleb ainult teiste masinatega sama vRouter'i taga ning tõenäoliselt see ei olegi nii.

• vRouter loob ühenduse SDN-kontrolleriga BGP protokolli (või samalaadse — TF korral on see XMPP 0_o) kaudu.
• Selle sessiooni kaudu edastab vRouter SDN-kontrollerile marsruudid ühendatud võrkudeni:
  • Võrgu aadress
  • Inkaptsuleerimismeetod (MPLSoGRE, MPLSoUDP, VXLAN)
  • Kliendi MPLS-märgistus
  • Oma IP-aadress nexthop'ina

• SDN-kontroller saab sellised marsruudid kõigilt ühendatud vRouter'itelt ja peegeldab need teistele. Teisisõnu toimib ta Route Reflector'ina.

Sama toimub ka vastupidises suunas.

Overlay võib muutuda iga minuti järel. Just nii see avalikes pilvkeskkondades toimub, kui kliendid pidevalt oma virtuaalseid masinaid sisse ja välja lülitavad.

Keskne kontroller võtab enda kanda kõik configuuri ja switching/routing tabelite haldamise keerukused vRouteris.

Rääkides jämedalt, siis kontroller suhtleb kõigi vRouteritega BGP (või sarnase protokolli) kaudu ja edastab lihtsalt marsruutimise teavet. BGP-l on näiteks juba olemas Address-Family, et edastada kapseldusmeetodi. MPLS-in-GRE või MPLS-in-UDP.

Sellega ei muutu kuidagi Underlay-võrgu konfiguratsioon, mida muide on automatiseerida oluliselt keerulisem ning purustada on lihtsam vale liigutusega.

Välismaailma pääsemine

Kusagil peab simulatsioon lõppema ja virtuaalsest maailmast tuleb astuda reaalsesse. Ja vajalik on telefonigateway.

Kasutatakse kahte lähenemist:

1. Paigaldatakse riistvararuuter.
2. Käivitakse mõni seade, mis rakendab ruuteri funktsioone (jah, jah, koos SDN-iga kohtasime me ka VNF-i). Nimetame seda virtuaalseks gateway'ks.

Teise lähenemise eelis on odav horisontaalne skaleeritavus — jõudlusest puudus — käivitasime veel ühe virtuaalmasina värava. Igas füüsilises masinas, ilma vajaduseta otsida vabu riiuleid, ühikuid, toiteühendusi, osta rauda, toimetada see kohale, paigaldada, ühendada, seadistada ning seejärel veel ka rikkis komponente vahetada.

Kuid virtuaalse värava miinused on need, et füüsilise ruuteri võimekus on märkimisväärselt suurem kui mitme südamiku virtuaalsel masinal, ja selle tarkvara, mis on kohandatud enda riistvara alusele, töötab oluliselt stabiilsemalt (ei). Raskesti on vaielda ka asjaolu üle, et tarkvaraliselt-riistvaraline kompleks töötab lihtsalt, nõudes vaid seadistamist, samas kui virtuaalse värava käivitamine ja hooldamine on tugevate inseneride töö.

Ühe jala abil vaatab värav virtuaalvõrku Overlay nagu tavaline virtuaalmasin ja saab suhelda kõigi teiste virtuaalmasinatega. Samal ajal võib see klientide võrke enda peal lõpetada ning seega teostada ka nende vahel marsruutimist.

Teise jalaga vaadata, kuidas pääs veebivõrku ja teab, kuidas Internetti pääseda.

Andmeplaneet

Protsess näeb välja järgmine:

1. VM-0, millel on vaikimisi kõik sama vRouter, saadab paketi välismaailma (185.147.83.177) eth0 liidese kaudu.
2. vRouter saab selle paketi ja teeb sihtadressi otsingu marsruutimistabelis — leiab vaikimisi marsruudi läbi VNGW1 läbi Tunnel 1.
   Samuti näeb ta, et tegemist on GRE tunneliga, mille SIP on 10.0.0.2 ja DIP 10.0.255.2, ning peab kõigepealt andma hoolduseks MPLS-märgi, mida VNGW1 ootab.
3. vRouter paneb algse paketi MPLS, GRE ja uue IP pealkirjade alla ning saadab selle aadressile ToR1 10.0.0.1 vaikimisi.
4. Alusvõrk toimetab paketi VNGW1 pääsule.
5. VNGW1 pääs eemaldab GRE ja MPLS tunneli päised, näeb sihtaadressi, konsulteerib oma marsruutimistabeliga ja mõistab, et see on suunatud Internetti — seega Full View või Default kaudu. Kui on vajalik, teeb NAT-muundamise.
6. VNGW ja piiri vahel võib olla tavapärane IP-võrk, mis on ebatõenäoline.
   Võib olla klassikaline MPLS-võrk (IGP+LDP/Rsvp TE), võib olla ka tagasitehas BGP LU või GRE tunnel VNGW-st piirini üle IP-võrgu.
   VNGW1 teostab vajalikud kapseldamised ja saadab algse paketi suunas piirile.

Tagasipöörduv liiklus läbib samu samme vastupidises järjekorras.

1. Piir toimetab paketi VNGW1 juurde.
2. See avab selle, vaatab sihtaadressi ja näeb, et see on kergesti ligipääsetav Tunnel1 (MPLSoGRE või MPLSoUDP) kaudu.
3. Seetõttu lisab ta MPLS-märgi, GRE/UDP päise ja uue IP-aadressi ning saadab selle oma ToR3 10.0.255.1.
   Tunnelite sihtaadress on vRouteri IP-aadress, mis toetab siht-VM-i — 10.0.0.2.
4. Alusvõrk toimetab paketi vajaliku vRouterini.
5. Siht-vRouter eemaldab GRE/UDP, määrab MPLS-märgi järgi liidest ja saadab toore IP-paketi oma TAP-liidese kaudu, mis on ühendatud eth0 VM-iga.

Kontrolli küngas

VNGW1 loob BGP-systeemisuhte SDN-kontrolleriga, kellelt ta saab kogu marsruutimise teabe klientide kohta: millise IP-aadressi (vRouteriga) taga milline klient asub ja millise MPLS-märgiga ta tuvastatakse.

Sarnaselt edastab ta SDN-kontrollerile vaikimisi marsruudi selle kliendi märgiga, määrates end järgmise hüppena. Edasi jõuab see vaikimisi marsruut vRouteritesse.

VNGW-s toimub tavaliselt marsruutide kogumine või NAT-muundamine.

Ja teises suunas, koos piiride või Route Reflector’itega, edastab ta just selle koondatud marsruudi. Ning nendelt saab ta kas vaikimisi marsruudi või Full-View, või midagi muud.

Inkubatsiooni ja liikluse vahetamise osas ei erine VNGW vRouterist.
Kui veidi laiemalt mõelda, siis VNGW ja vRouter’itega saab lisada ka teisi võrgu seadmeid, nagu tulemüürid, liikluse puhastuse või rikastamise farmid, IPS, jne.

Ja järjestikuste VRF-ide loomise ning marsruutide õige avaldamisega saab liiklust sundida keerlema just nii, nagu soovite, mida nimetatakse teenuse ahelaks.

Seega, ka siin toimib SDN-kontroller Route Reflector’ina VNGW, vRouter’ite ja teiste võrgu seadmete vahel.

Kuid tegelikult edastab kontroller ka informatsiooni ACL-i ja PBR-i (Policy Based Routing) kohta, sundides eri liiklusvooge liikuma mitte nii, nagu marsruut ette näeb.

KKK

Miks sa pidevalt teed märkuse GRE/UDP kohta?

Tegelikult on see, võiks öelda, spetsiifiline Tungsten Fabric’i jaoks — sellest võib isegi mitte rääkida.

Aga kui rääkida, siis TF, olles veel OpenContrail, toetas mõlemat inkapsuleerimist: MPLS in GRE ja MPLS in UDP.

UDP on hea, et Source Port'i tema pealkirjas on väga lihtne kodeerida hash-funktsioon algsetest IP+Proto+Port kombinatsioonidest, mis võimaldab tõhusat koormuse jaotamist.

GRE puhul, kahjuks, on ainult välised IP ja GRE pealkirjad, mis on kõikide kapseldatud andmete jaoks ühesugused, seega koormuse jaotamisest rääkida ei saa — vähe inimesi suudab nii sügavale paketti sisse vaadata.

Teatud aja jooksul suudsid ruuterid, kui nad üldse oskasid dünaamilisi tunnelite teha, vaid MPLSoGRE kaudu ja alles hiljuti õppisid nad MPLSoUDP-d kasutama. Seetõttu on alati vajalik märkus kahe erineva kapseldamise võimaluse kohta.

Õiguse nimel tuleb märkida, et TF toetab täiesti L2-ühenduvust VXLAN-i kaudu.

Sa lubasid siduda paralleele OpenFlow'ga.
Need tõepoolest mõjuvad. vSwitch samas OpenStack'is teeb väga sarnaseid asju, kasutades VXLAN-i, millel, muide, on samuti UDP pealkiri.

Andmekihis töötavad nad umbkaudu ühtemoodi, kuid juhtimiskihis on oluliselt erinevusi. Tungsten Fabric kasutab marsruutide teabe edastamiseks XMPP-d, samas kui OpenStack'is toimib OpenFlow.

Kas sa saaksid rääkida rohkem vRouter'ist?
See jaguneb kaheks osaks: vRouter Agent ja vRouter Forwarder.

Esimene töötab User Space'i host-operatsioonisüsteemis ja suhtleb SDN-kontrolleriga, vahetades teavet marsruutide, VRF-i ja ACL-i kohta.

Teine rakendab Data Plane'i — tavaliselt Kernel Space'is, kuid võib töötada ka SmartNIC-ides — võrgukaartides, millel on CPU ja eraldi programmeeritav lülitusiip, mis võimaldab kanda koormust host-masina CPU-lt ära ning muudab võrgu kiiremaks ja prognoositavamaks.

On ka võimalus, et vRouter on DPDK-rakendus User Space'is.

vRouter Agent edastab seaded vRouter Forwarderile.

Mis on Virtuaalne Võrk?
Mainisin artikli alguses VRF-i, et iga üürnik on seotud oma VRF-iga. Ja kuigi selleks, et mõista ülekattevõrgu toimimist, oli see piisav, tuleb juba järgmises iteratsioonis selgitusi anda.

Tavaliselt virtuaalmasinate virtualiseerimise mehhanismides tuuakse Virtual Network (seda võib pidada omaette nimeks) eraldi klientidest/tenantidest/virtuaalmasinatest — see on täiesti iseseisev element. Ja seda Virtual Network'i saab liidestuse kaudu ühendada ühte tenant'i, teise, kahega, jah, kuhu iganes. Näiteks teostatakse Service Chaining'i, kui liiklust tuleb suunata läbi kindlate node'ide soovitud järjekorras, lihtsalt loomise ja Virtual Network'ide õige järjekorra sidumisega.

Seetõttu ei ole Virtual Network'i ja tenant'i vahel otsest vastavust.

Kokkuvõte

See on üsna pinnapealne kirjeldus virtuaalse võrgu töö kohta overlay's hostilt ja SDN-kontrollerilt. Kuid sõltumata sellest, millist virtualiseerimisplatvormi te täna kasutate, töötab see sarnasel viisil, olgu see siis VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric või Juniper Contrail. Need eristuvad kapseldatuse ja päiste tüüpide, lõppvõrguseadmete teabe edastamise protokollide poolest, kuid programmiga juhitava overlay-võrguharu põhimõte, mis töötab suhteliselt lihtsa ja staatilise allvõrgu kohal, jääb samaks.
Võib öelda, et tänapäevases privaatse pilve loomise valdkonnas on overlay-võrgupõhine SDN võitnud. See ei tähenda siiski, et OpenFlow ei leiduks tänapäeva maailmas — seda kasutatakse OpenStackis ning ka VMWare NSX-is, ning nii palju kui ma tean, kasutab seda Google oma all-juhitud võrgu seadistamiseks.

Allpool leiate lingid üksikasjalikumatele materjalidele, kui soovite teemat sügavamalt uurida.

Aga mis meie all-kihis toimub?

Ega seal suurt midagi ei toimu. See on kogu aeg muutumatu. Kõik, mida tal on vaja teha overlay puhul, on uuendada marsruute ja ARP-e vastavalt vRouteri/VNGW de olemasolule ja kadumisele ning edastada pakette nende vahel.

Käime läbi nõudmiste loetelu all-kihi võrgule.

1. Tuleb osata mingit marsruutimisprotokolli, meie olukorras — BGP.
2. Omada suurt läbilaskevõimet, eelistatult ilma ülealustamiseta, et pakette ei kaduks ülekoormuse tõttu.
3. Toetada ECMP-d — see on lahenduse lahutamatu osa.
4. Osata pakkuda QoS-i, sealhulgas keerulisi asju, nagu ECN.
5. Toetada NETCONF-i — tuleviku tarbeks.

Underlay-võrgu tööle olen siin väga vähe aega pühendanud. See on sellepärast, et edasisetes osades keskendun ma just sellele, samas kui Overlay'd puudutame vaid põgusalt.

Ilmselt piirangud, mida ma kõigile seades rakendan, tulenevad tõsiasjast, et kasutame näitena Clozi tehases ehitatud DC-võrku, millel on puhas IP-routed ja overlay hostilt.

Kuid ma olen kindel, et igasugust võrku, millel on disain, saab kirjeldada formaalsetes terminites ja automatiseerida. Lihtsalt ma püüan siin mõista automatiseerimisviise, mitte segadusse ajada, lahendades ülesande üldiselt.

ADSMe raames kavatseme koos Roman Gorgiga avaldada eriväljaanne arvutusvõimsuse virtualiseerimise ja selle koostöö kohta võrgu virtualiseerimisega. Jälgige meid.

Kasulikud lingid

• Tungsten Fabric Arhitektuur.
• about:cloud. 6 tundi Yandex.Cloudi kohta, kus puudutatakse ka virtuaalvõrku TF-is.
• Mis on Open vSwitch?
• Sissejuhatus VxLAN-i.
• RFC 7348. Virtuaalne eXtensible Kohalik Ala-Võrk (VXLAN): Raamistik virtualiseeritud 2. taseme võrkude katmiseks 3. taseme võrkude üle.
  
• Scaleway lähenemine VXLAN EVPN Fabric'ile. Siin räägitakse kogu DC-võrgust, sealhulgas Underlay'st, Overlay'st, multi-homing lähenemistest ja haldamisest.

Aitäh

• Roman Gorgile — endine linkmeup'i podkasti juht, praegu pilvetehnoloogia ekspert. Kommentaaride ja paranduste eest. Ootame varsti tema põhjalikumat artiklit virtualiseerimisest.
• Aleksandr Šalimov — minu kolleeg ja virtuaalsete võrkude arendamise ekspert. Kommentaaride ja paranduste eest.
• Valentin Sinitsyn — minu kolleeg ja Tungsten Fabrici ekspert. Kommentaaride ja paranduste eest.
• Artiom Tšernobai — linkmeup'i illustraator. KDPV eest.
• Aleksandr Limonov. Memi «automato» eest.

Allikas: habr.com