Uues väljaandel Olen kirjeldanud verkkoautomaatioframeworkia. Joidenkin palautteiden mukaan tämä ensimmäinen lähestymistapa ongelmaan on jo selventänyt joitakin kysymyksiä. Tämä ilahduttaa minua, koska tavoitteemme sykliin ei ole vain peittää Ansiblea Python-skripteillä, vaan rakentaa järjestelmä.

Tämä framework määrittää järjestyksen, jonka mukaan käsittelemme kysymystä.
Ja verkkovirtualisointi, jolle tämä julkaisu on omistettu, ei erityisesti sovi ADSMin aiheeseen, jossa käsittelemme automaatiota.

Mutta katsotaanpa sitä toisesta kulmasta.

Monet palvelut ovat jo pitkään käyttäneet yhtä verkkoa. Esimerkiksi teleoperaattorilla se on 2G, 3G, LTE, laajakaista ja B2B. Datakeskuksissa: yhteydet eri asiakkaille, Internet, lohkotallennus, objektilaatikko.

Ja kaikki palvelut vaativat eristyksen toisistaan. Näin syntyivät overlay-verkot.

Eikä kaikki palvelut halua odottaa, kun ihminen määrittää ne manuaalisesti. Näin syntyivät orkestroijat ja SDN.

Ensimmäinen lähestymistapa verkon järjestelmälliseen automatisointiin, tarkemmin sanottuna sen osan automatisointiin, on pitkään ollut yrittäjänä ja monilla alueilla toteutettu: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Tämän kanssa käymme tänään läpi.

Sisukord

• Syyt
• Terminoloogia
• Underlay — fyysinen verkko
• Overlay — virtuaaliverkko
  • Overlay ToR:sta
  • Overlay isäntäkoneelta
  • Esimerkiksi Tungsten Fabricin osalta
    • Viestintä yhden fyysisen koneen sisällä
    • Viestintä VM:ien välillä, jotka sijaitsevat eri fyysisillä koneilla
    • Ulkomaailmaan ulospääsy

• KKK
• Kokkuvõte
• Kasulikud lingid

Syyt

Ja kun kerran olemme tästä puhuneet, on syytä mainita verkkovirtualisoinnin edellytykset. Itse asiassa tämä prosessi alkoi ei eilen.

Olet luultavasti kuullut useaan otteeseen, että verkko on aina ollut systeemin kaikkein inertialisin osa. Ja tämä on totta kaikessa merkityksessä. Verkko on perusta, johon kaikki perustuu, ja sen muuttaminen on melko vaikeaa — palvelut eivät kestä, kun verkko on alhaalla. Usein yhden solmun poistaminen käytöstä voi kaatua suuren osan sovelluksista ja vaikuttaa moniin asiakkaille. Osittain siksi verkko-tiimi voi vastustaa muutoksia — koska se toimii nyt jotenkin (me emme ehkä tiedä miten), ja nyt on tarpeen määrittää jotain uutta, eikä ole selvää, miten se vaikuttaa verkkoon.

Ette ei peaks ootama, et võrguoperaatorid VLAN-i konfigureerivad ning kõiki teenuseid igas võrgu sõlmes määravad, on inimesed leiutanud kasutada overlay-d — kattuvate võrkude süsteeme, mille mitmekesisus on suur: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE jne.

Nende atraktiivsus seisneb kahes lihtsas asjaolus:

• Configureeritakse ainult lõpp-sõlmed — transit-sõlmedesse puutuda ei ole vaja. See kiirendab oluliselt protsessi ning mõnikord võimaldab täielikult välistada võrguinfrastruktuuri osakonna uute teenuste lisamisest.
• Koormus on peidetud sügavale pealkirjadesse — transit-sõlmed ei pea sellest midagi teadma, ei hostide aadressimisest ega kattuvate võrkude marsruutidest. See tähendab, et tabelites tuleb hoida vähem teavet, seega võib kasutada lihtsamaid/odavamaid seadmeid.

Selles mitte eriti põhjalikus väljaandes ei plaani ma kõiki võimalikke tehnoloogiaid käsitleda, vaid pigem kirjeldada overlay-võrkude töö raamistiku andmekeskuses.

Kogu sari kirjeldab andmekeskust, mis koosneb üksteise külge paigutatud identsetest riiulitest, kuhu on paigaldatud sama tüüpi serveriseade.

Sellel varustusel käivitatakse virtuaalsed masinad/konteinerid/serverless, mis rakendavad teenuseid.

Terminoloogia

Tsüklis serverilt nimetan ma programmi, mis rakendab serveri poole kliendi-serveri kommunikatsioonist.

Füüsilisi masinaid riiulites nimetame serveriteks ei meie.

Füüsiline masin on x86-arvuti, mis on paigaldatud riiulisse. Kõige sagedamini kasutatav termin on host. Nii nimetame teda "masin" või host.

Hüperviisor — rakendus, mis on käivitatud füüsilise masina peal ja emuleerib füüsilisi ressursse, millel töötavad Virtuaalsed Masinad. Mõnikord kasutatakse kirjanduses ja võrgus sõna „hüpervisor” sünonüümina „hostile”.

Virtuaalne masin — operatsioonisüsteem, mis on käivitatud füüsilise masina peal hüperviisoril. Meie jaoks ei ole sel tsüklil tegelikult oluline, kas see on tõeline virtuaalne masin või lihtsalt konteiner. Nimetame seda "VM«

Tenant on lai mõisted, mida selles artiklis määratlen kui eraldi teenuse või eraldi kliendi.

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

ToR — Racki ülaosa lüliti — rack switch, to which all physical machines are connected.

Besides ToR topology, different providers practice End of Row (EoR) or Middle of Row (although the latter is a rarely used term and I have not encountered the abbreviation MoR).

Underlay network or underlay network — the physical network infrastructure: switches, routers, cables.

Overlay network or overlay network — a virtual network of tunnels operating over the physical layer.

L3 fabric or IP fabric — an amazing human invention that allows for not repeating STP and not learning TRILL during meetings. A concept where the entire network down to the access level is exclusively L3, without VLAN and consequently huge stretched broadcast domains. We will discuss the origin of the term 'fabric' in the next part.

SDN — Software Defined Network. Hardly needs an introduction. An approach to network management where changes in the network are performed not by a person but by a program. Typically means moving the Control Plane outside the end network devices to a controller.

NFV — Network Function Virtualization — virtualization of network devices that assumes that some network functions can run as virtual machines or containers to accelerate the introduction of new services, organize Service Chaining, and facilitate easier horizontal scalability.

VNF — Virtual Network Function. A specific virtual device: router, switch, firewall, NAT, IPS/IDS, etc.

I am intentionally simplifying the description to a specific implementation to avoid confusing the reader too much. For more thoughtful reading, I refer them to the section Viidatud lingid. Additionally, Roma Gorge, who criticizes this article for inaccuracies, promises to write a separate issue on server and network virtualization technologies, more in-depth and detail-oriented.

Most networks today can clearly be divided into two parts:

Underlay — a physical network with a stable configuration.
Overlay — an abstraction over Underlay for tenant isolation.

This is true for both the case of DC (which we will discuss in this article) and ISP (which we will not cover, as it has already been discussed in SDN). With enterprise networks, of course, the situation is somewhat different.

An image focusing on the network:

Underlay

Underlay on füüsiline võrk: riistvaralised lülitid ja kaablid. Seadmed underlay's teavad, kuidas jõuda füüsiliste masinatega.

See tugineb standardsetele protokollidele ja tehnoloogiatele. Mitte viimase asjana seepärast, et riistvarasesked töötavad siiani patenteeritud tarkvaral, mis ei luba ei kiibi programmeerimist, ei omade protokollide rakendamist; seega on vajalik ühilduvus teiste tarnijatega ja standardimine.

Kuid keegi nagu Google suudab endale lubada oma lülitite arendamist ja tavatäringute protokollidest loobumist. Kuid LAN_DC ei ole Google.

Underlay vahetub suhteliselt harva, sest selle ülesanne on põhivõrgu IP-ühendus füüsiliste masinate vahel. Underlay ei tea midagi tema peal käivitatud teenustest, klientidest, tenantidest — tal on vaja ainult paketti ühest masinast teise edastada.
Underlay võib olla näiteks järgmine:

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

Underlay võrk seadistatakse klassikalisel viisil: CLI/G/NETCONF.

Käsitsi, skriptide, patenteeritud tööriistade kaudu.

Underlay’le pühendatakse järgmises artiklis rohkem tähelepanu.

Overlay

Overlay on virtuaalne tunneli võrk, mis on üle Underlay's, see võimaldab ühe kliendi VM-del omavahel suhelda, samal ajal tagades isolatsiooni teiste klientide eest.

Kliendi andmed kapseldatakse mingitesse tunneliseerimispealkirjadesse, et edastada neid ühisesse võrku.

Nii võivad ühe kliendi VM-id (ühe teenuse) omavahel suhelda läbi Overlay, isegi teadmata, mis tegelikult tee su paketid järgivad.

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

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

Overlay võrk seadistatakse ja toetatakse tavaliselt keskse kontrolleri kaudu. Sealt edastatakse konfiguratsioon, Control Plane ja Data Plane seadmetele, mis tegelevad klienditrafiku marsruutimise ja kapseldamisega. Veidi allpool küll arutame seda näidete abil.

Jah, see on puhas SDN.

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

1. Overlay ToR:sta
2. Overlay isäntäkoneelta

Overlay ToR:sta

Overlay võib alata juurdepääsuswitch'ilt (ToR), mis on seadistatud rack'i, nagu see juhtub näiteks VXLAN tehases.

See on ajaproovile vastu pidanud mehhanism ISP võrkudes ja kõik võrgu riistvaratootjad toetavad seda.

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

Siinkohal suunan lugeja artikli juurde VxLAN Habr'is meie vana sõbra @bormoglotx.
Selles esitlusele ENOG on põhjalikult kirjeldatud lähenemisviise andmekeskuse võrgu ehitamiseks EVPN VXLAN-fabriku abil.

Kuna teemasse süvenemiseks võib lugeda Ciscolt raamatut A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Tõin välja, et VXLAN on ainult kapseldamismeetod ja tunnelite lõpetamine võib toimuda mitte ToR-is, vaid masina peal, nagu toimub näiteks OpenStackis.

Kuid VXLAN-fabrika, kus overlay algab ToR-ist, on üks juurdunud ülekattevõrgu disaine.

Overlay isäntäkoneelta

Teine lähenemine on tunnelite alustamine ja lõpetamine lõppmasinates.
Sellisel juhul jääb võrk (Underlay) maksimaalselt lihtsaks ja staatiliseks.
Ja masin teeb kõik vajalikud kapseldamised ise.

Selleks on muidugi vaja käivitada spetsiaalne rakendus masinatel, kuid see on seda väärt.

Esiteks, kliendi käivitamine linux-masinal on lihtsam või, ütleme, — üldse võimalik — samas kui lülitil tuleb tõenäoliselt veel kasutada omandi SDN-lahendusi, mis tapab mitme tarnija idee.

Teiseks, ToR-lülitit saab jätta maksimaalselt lihtsaks nii Control Plane'i kui ka Data Plane'i seisukohalt. Tõepoolest — SDN-kontrolleriga suhtlemiseks pole tal siis vaja, ja kõigi ühendatud klientide võrke/ARP-sid hoidma ei pea — piisab, kui teada füüsilise masina IP-aadressi, mis kergendab märkimisväärselt kommutatsiooni/routing tabelite haldamist.

ADSMi seerias valin lähenemise, kus overlay tuleb masinast — edasine arutelu keskendub ainult sellele ja VXLAN-fabriku juurde me ei naase enam.

Lihtsaim on vaadata näidete kaudu. Ja katseobjektiks võtame OpenSource SDN platvormi OpenContrail, mis on tuntud kui Tungsten Fabric.

Artikli lõpus toon välja mõned mõtted OpenFlow ja OpenvSwitch'i sarnasuse teemal.

Esimerkiksi Tungsten Fabricin osalta

Igal füüsilisel masinal on vRouter — virtuaalne marsruuter, mis teab, millised võrgud on sellega ühendatud ja kellele need kuuluvad — sisuliselt PE-marsruuter. Iga kliendi jaoks toetab see isoleeritud marsruutimistabelit (loe: VRF). Ja vRouter teostab Overlay tunneldamise.

Natuke lähemalt vRouterist — artikli lõpus.

Iga VM, mis asub hüperviisoril, ühendatakse selle masina vRouteriga läbi TAP-liidese.

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

Kui vRouteri taga on mitu võrku, siis igale neist luuakse virtuaalne liides, millele määratakse IP-aadress — see on vaikimisi marsruutija aadress.
Kõik ühe kliendi võrgud paigutatakse ühte VRF (ühes tabelis), erinevad — erinevatesse.
Teen seda siin märkuse, et asjad ei ole nii lihtsad, ja saadan uudishimuliku lugeja artikli lõppu..

Kuna vRouterid peavad omavahel suhtlema ja seega ka neile väljasolevad VM-id, vahetavad nad marsruuditeavet läbi SDN-kontrolleri.

Välismaailma pääsemiseks on olemas väljapääs, mis on virtuaalne võrgu värav VNGW — Virtuaalne Võrgu Värav (see termin on minu enda.).

Nüüd vaatame suhtluse näiteid — ja asi saab selgeks.

Viestintä yhden fyysisen koneen sisällä

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

Andmeplaan

1. VM-0-l on vaikimisi marsruut oma liideses eth0. Pakett saadetakse sinna.
   See liides eth0 on tegelikult virtuaalselt ühendatud virtuaalse marsruutija vRouteriga läbi TAP-liidese tap0.
2. vRouter analüüsib, millisele liidesele pakett tuli, st kellele (VRF) see kuulub, ja võrdleb saaja aadressi kliendi marsruutimistabeliga.
3. Tuvastades, et saaja on sellel samal masinal teisel pordil, saadab vRouter paketi lihtsalt sinna ilma igasuguste lisapealkirjadeta — sellisel juhul on vRouteris juba olemas ARP-kirje.

Pakett ei jõua sellisel juhul füüsilisse võrku — see marsruutis end vRouteris.

Kontrollplaan

Hüperviisor teavitab virtuaalmasina käivitamisel seda:

• tema enda IP-aadress.
• Vaikimisi marsruut — läbi vRouteri IP-aadressi selles võrgus.

vRouterile edastab hüperviisor läbi erilise API:

• et virtuaalne liides tuleb luua.
• Mida peab (VM) looma virtuaalne võrk.
• Kellele VRF-i tema (VN) siduda.
• Statistiline ARP-kirje selle VM jaoks - millise liidese taga on selle IP-aadress ja millise MAC-aadressiga see on seotud.

Ja taas on tegelik suhtlemisprotseduur lihtsustatud arusaamaks kontseptsiooni.

Seega näeb kõiki ühe kliendi VM-e antud seadmes vRouter otse ühendatud võrkudena ja suudab nende vahel marsruuti suunata.

Kuid VM0 ja VM1 kuuluvad erinevatele klientidele, seega on nad erinevates vRouter’i tabelites.

Kas nad saavad omavahel otse suhelda, sõltub vRouter’i seadetest ja võrgu kujundusest.
Näiteks, kui mõlema kliendi VM-id kasutavad avalikke aadresse, või NAT toimub vRouter’il, siis saab teha ka otsemarsruutimist vRouter’is.

Teisel juhul võib aadressiruumide kattumine esineda - tuleb minna NAT-serverisse, et saada avalik aadress - see on sarnane välisse обслуживала, millest allpool.

Viestintä VM:ien välillä, jotka sijaitsevat eri fyysisillä koneilla

Andmeplaan

1. Algus on täpselt sama: VM-0 saadab paketi adressaadile VM-7 (172.17.3.2) oma vaikimisi kaudu.
2. vRouter saab selle ja seekord näeb, et adressaat asub teisel seadmel ja on saadaval Tunnel0 kaudu.
3. Esmalt lisab ta MPLS-i sildi, mis tuvastab kaugliidese, et vastaspoolel vRouter saaks määrata, kuhu see paket paigutada ilma lisateedeta.

   

4. Tunnel0 allikas on 10.0.0.2, saaja: 10.0.1.2.
   vRouter lisab algsele paketile GRE (või UDP) pealkirjad ja uue IP.
5. vRouter’i marsruudi tabelis on vaikimisi marsruut aadressi ToR1 10.0.0.1 kaudu. Sinna see saadetakse.

   
   

6. ToR1, kui Underlay võrgu osaline, teab (nt OSPF-i kaudu), kuidas jõuda 10.0.1.2 ni ja saadab paketi marsruudi kaudu. Märkus: siin rakendatakse ECMP-d. Illustratsioonil on kaks next hop ja erinevad voolud jagunevad nende vahel häshtimisel. Tõelise tehasemudeli puhul oleks siin tõenäoliselt 4 next hop.

   Samuti ei pea ta teadma, mis asub välist IP-pealkirja all. Tõeliselt võib IP all olla kihiline struktuur IPv6 üle MPLS üle Ethernet üle MPLS üle GRE üle üle GRE.

7. Seega eemaldab vastuvõtva poole vRouter GRE ja MPLS-i sildi järgi mõistab ta, millisele liidesele see pakett edastada, vabastab selle ja saadab algses vormis adressaadile.

Kontrollplaan

Masina käivitamisel toimub kõik sama, nagu eespool kirjeldatud.

Ja lisaks veel järgmine:

• Iga kliendi jaoks määrab vRouter MPLS-sildi. See on teenusesilt L3VPN, mille alusel jagatakse kliente ühe füüsilise masina piires.
  

  Tegelikult määratakse MPLS-silt vRouter'i poolt alati, kuna ei ole ette teada, et masin suhtleb ainult teiste masinatega sama vRouter'i taga, ja see on tõenäoliselt isegi nii.

• vRouter loob ühenduse SDN-kontrolleriga BGP protokolli (või sarnase protokolli abil — TF puhul on see XMPP 0_o).
• Selle seansi kaudu teatab vRouter SDN-kontrollerile marsruudid ühendatud võrkudeni:
  • Võrgu aadress
  • Inkapseldusmeetod (MPLSoGRE, MPLSoUDP, VXLAN)
  • Kliendi MPLS-silt
  • Oma IP-aadress nexthop'ina

• SDN-kontroller saab selliseid marsruute kõigilt ühendatud vRouter'itelt ja edastab need teistele. Seega toimib ta marsruudi peegeldujana.

Sama toimub ka vastupidises suunas.

Overlay võib muutuda iga minuti tagant. Just nii see toimib avalikes pilvetes, kui kliendid käivitatakse ja väljastatakse oma virtuaalmasinaid regulaarselt.

Keskne kontroller võtab endale kõik keerukused konfiguratsiooni säilitamisel ja marsruudimis-/kommutatsioonitabelite kontrollimisel vRouter'il.

Rohkem täiustatud viisil öeldes ühendub kontroller kõigi vRouter'itega BGP (või sarnase protokolli) kaudu ja edastab lihtsalt marsruutinfot. BGP-l on näiteks juba Address-Family inkapseldusmeetodi edastamiseks. MPLS-in-GRE või MPLS-in-UDP.

Samuti ei muutu kuidagi Underlay-võrgu konfiguratsioon, mis on muide automaatikas oluliselt keerulisem, samas kui ülesande vale teostamine on lihtne.

Ulkomaailmaan ulospääsy

Kusagil peab simuleerimine lõppema ja virtuaalsest maailmast peab välja minema reaalsesse. Ja on vaja taksofoniga gateway'd.

Praktiseeritakse kahte lähenemist:

1. Paigaldatakse riistvaraline marsruuter.
2. Käivitatakse mõni appliance, mis teostab marsruutimise funktsioone (jah, järgides SDN-i, oleme ka VNF-iga silmitsi selle saanud). Kutsume seda virtuaalseks väravaks.

Teise lähenemise eelis odava horisontaalse skaleeritavuse osas — kui võimsus on puudulik, käivitasime veel ühe virtuaalmasina väravaga. Iga füüsilise masina peal, ilma vajaduseta otsida vabu racke, üksusi, toiteallikaid, osta ise riistvara, transportida, paigaldada, ühendada, seadistada, ja siis veel vahetada rikki läinud komponente.

Virtuaalsel väraval on siiski miinuseid, kuna füüsiline ruuter on palju võimsam kui palju südamikke omav virtuaalmasin ning tema tarkvara, mis on kohandatud vastavasse riistvarasse, töötab oluliselt stabiiliumalt (ei). Raskem on eitada ka seda fakti, et tarkvara-riistvara kompleks lihtsalt töötab, nõudes vaid seadistamist, samas kui virtuaalse värava käivitamine ja hooldamine on tugevate inseneride tegevus.

Ühe jalaga vaatab värav virtuaalsesse Overlay-võrku nagu tavaline virtuaalmasin ning võib suhelda kõigi teiste VM-idega. Samuti võib ta klientide võrke enda pead terminida ja seega teostada nende vahel marsruutimist.

Teise jalaga vaatab värav juba peavõrku ja teab, kuidas internetti pääseda.

Andmeplaan

Protsess näeb välja järgmine:

1. VM-0, omades vaikimisi vRouterit, saadab paketi aadressaatidega välismaailmasse (185.147.83.177) eth0 liidesesse.
2. vRouter saab selle paki ja otsib sihtaadressi marsruudist tabelis — leiab vaikimisi marsruudi VNGW1 värava kaudu Tunnel 1.
   Samuti näeb ta, et see on GRE tunnel SIP-iga 10.0.0.2 ja DIP-iga 10.0.255.2, ja tal on enne vaja panna MPLS-märgis sellele kliendile, mida VNGW1 ootab.
3. vRouter pakendab algse paki MPLS, GRE ja uue IP päiste alla ning saadab selle aadressile ToR1 10.0.0.1 vaikimisi.
4. Alamvõrk toimetab paki VNGW1 väravasse.
5. VNGW1 värav eemaldab GRE ja MPLS tunnelduspead, näeb sihtaadressi, konsulteerib oma marsruuditabeliga ja mõistab, et see suundub internetti — see tähendab, et läbi Full View või Default. Vajadusel teostatakse NAT-muundamine.
6. VNGW ja piirdele võib olla tavaline IP-võrk, mis on vähe tõenäoline.
   See võib olla klassikaline MPLS-võrk (IGP+LDP/RSP TE), võib olla tagasi tagavabrik BGP LU-ga või GRE tunnel VNGW-st piirdeni IP-võrgu kaudu.
   Igatahes VNGW1 sooritab vajalikud kapseldamised ja saadab algse paki piirde suunas.

Tagasi suunduv liiklus läbib samu samme vastupidises järjestuses.

1. Piirde toimetab paki VNGW1-le
2. VNGW1 eemaldab selle, vaatab saaja aadressile ja tuvastab, et see on saadaval Tunnel1 (MPLSoGRE või MPLSoUDP) kaudu.
3. Seega kinnitab ta MPLS-märgi, GRE/UDP päise ja uue IP ning saadab selle oma ToR3 10.0.255.1-le.
   Tunnel'i sihtkoht on vRouter'i IP-aadress, mille taga on siht-VM — 10.0.0.2.
4. Andmeedastusvõrk toob paketi vajaliku vRouter'ini.
5. Siht-vRouter eemaldab GRE/UDP, määrab MPLS-sildi alusel liidese ja saadab tavalise IP-paketi oma TAP-liidese kaudu, mis on seotud eth0 VM-iga.

Kontrollplaan

VNGW1 loob BGP-naabruse SDN-kontrolleriga, kellelt ta saab kogu marsruutimise teabe klientide kohta: millise IP-aadressi (vRouter) taga asub milline klient ja millise MPLS-sildi põhjal ta identifitseeritakse.

Sarnaselt edastab ta SDN-kontrollerile vaikesuuna koos selle kliendi sildiga, märkides end järgmise hüppena. Jätkusuunamine jõuab siis vRouter'itesse.

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

Ja vastassuunas edastab ta eelkõige selle agregeeritud marsruudi seansiga piiride või Route Reflector'itega. Nendelt saab ta marsruudi vaikesuuna, Full-View'i või midagi muud.

Inkubatsiooni ja liikluse vahetuse osas ei erine VNGW milleski vRouter'ist.
Kui natuke laiendada valdkonda, siis saab VNGW ja vRouter'ite hulka lisada muid võrgu seadmeid, nagu tulemüürid, liikluse puhastus- või rikastamisfarmid, IPS jms.

Ja VRF-i järjestikulise loomise ning õigete marsruutide kuulutamisega saab liiklust suunata nii, nagu soovite, mida kutsutakse Service Chaining'uks.

See tähendab, et ka siin mängib SDN-kontroller Route-Reflector'i rolli VNGW, vRouter'ite ja teiste võrgu seadmete vahel.

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

KKK

Miks sa pidevalt mainid GRE/UDP?

Noh, tegelikult on see Tungsten Fabric'i jaoks eriline — seda saab üldse mitte arvesse võtta.

Kuid kui arvestada, siis isegi olles OpenContrail, toetas TF mõlemat inkapsuleerimisviisi: MPLS GRE-s ja MPLS UDP-s.

UDP on hea selle poolest, et selle päises oleva Source Port'i kaudu on väga lihtne kodeerida algsete IP+Proto+Port'i häshefunktsiooni, mis võimaldab tasakaalustamist.

GRE puhul on kahjuks ainult välised IP ja GRE päised, mis on ühesugused kogu inkapsuleeritud liikluse jaoks ja tasakaalustamisest ei saa rääkida — harva, kui keegi suudab nii sügavale paketti vaadata.

Mõningal ajal oskasid ruuterid dünaamiliste tunnelite alal ainult MPLSoGRE'it, ja vaid hiljuti on nad õppinud ka MPLSoUDP-d kasutama. Seetõttu on alati vajalik märkida kahe erineva kapseldamise võimaluse olemasolu.

Õigluse nimel tuleks märkida, et TF toetab ka L2 seotust VXLANi abil.

Sa lubasid võrrelda OpenFlow'iga.
Need tõesti sätivad ennast kohale. vSwitch samas OpenStackis teeb sarnaseid asju, kasutades VXLANi, millel on muide samuti UDP-pealkiri.

Andmeplaanis töötavad nad enam-vähem võrdselt, kuid haldusplaanis on olulisi erinevusi. Tungsten Fabric kasutab teabe edastamiseks vRouterile XMPP, samas kui OpenStackis töötas OpenFlow.

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

Esimene töötab host-süsteemi kasutusruumis ja suhtleb SDN-kontrolleriga, vahetades teavet marsruutide, VRF-i ja ACL-i kohta.

Teine teostab andmeplaani - tavaliselt tuumaruumi, kuid see võib töötada ka SmartNIC-ides - võrguadapterites, millel on CPU ja eraldi programmeeritav lülitussüsteem, mis võimaldab vähendada hostmasina CPU koormust ja muuta võrgu kiiremaks ja ennustatavamaks.

On võimalik ka stsenaarium, kus vRouter on DPDK rakendus kasutusruumis.

vRouter Agent edastab seadistusi vRouter Forwarderile.

Mis on virtuaalne võrk?
Mainisin artikli alguses VRF-i, et iga üürnik seondub oma VRF-iga. Ja kui selleks, et mõista ülejäänud võrgu tööd, oli seda piisavalt, siis järgmise sammu jaoks on vajalik täpsustusi teha.

Tavaliselt virtualiseerimise mehhanismides tutvustatakse virtuaalset võrku (selle võib pidada kaubamärgiks) eraldi klientidest/üürnikest/virtuaalmasinatest - täiesti iseseisev asi. Ja see virtuaalne võrk saab liidestega seonduda ühte, teise või isegi kahte üürnikku, kuhu iganes soovite. Näiteks реализируется teenuste ahel, kui tuleb liiklust edastada kindlate sõlmede kaudu õigesjärjekorras, lihtsalt luues ja seondudes virtuaalsete võrkudega õiges järjekorras.

Seetõttu pole virtuaalse võrgu ja üürniku vahel otsest vastavust.

Kokkuvõte

See on üsna pinnapealne kirjeldus virtuaalsete võrkude toimimisest ülekattega hostilt ja SDN-kontrollerilt. Kuid ükskõik millist virtualiseerimisplatvormi te täna võtate, töötab see sarnasel viisil, olgu selleks VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric või Juniper Contrail. Need eristuvad kapseldus- ja pealkirjavormingutest, andmete edastamise protokollidest lõpp-punktide võrke, kuid programmiga seadistatava ülekatte võrgu põhimõte, mis töötab suhteliselt lihtsa ja staatilise aluse võrgu kohal, jääb samaks.
Võib öelda, et privaatsuse pilve loomise valdkondades on tänapäev SDN, mis põhineb ülekatte võrgul, domineeriv. Kuid see ei tähenda, et Openflow'l ei oleks tänapäevases maailmas kohta - seda kasutatakse OpenStackis ja samas VMWare NSX-is, seda kasutab, kui ma õigesti mäletan, Google oma aluse võrgu seadistamiseks.

Allpool olen toonud lingid põhjalikematele materjalidele, kui soovite teemat sügavamalt uurida.

Aga kuidas on meie Underlay'ga?

Tegelikult ei ole seal suurt midagi. See on kogu aeg muutumatu. Kõik, mida tal on vaja teha ülekattega hosti korral, on marsruutide ja ARP-de värskendamine vRouteri/VNGW ilmumise ja kadumise ajal ning pakettide edasiviimine nende vahel.

Formuleerime nõudmiste loetelu Underlay-võrgule.

1. Toetada mõnda marsruutimise protokolli, meie olukorras - BGP.
2. Omada laiat ribalaiust, eelistatavalt ilma üleallkirjastamiseta, et pakette ei kaoks ülemäärase koormuse tõttu.
3. Toetada ECMP-d - see on vajalik osa tehases.
4. Tagada QoS, sealhulgas keeruked asjad, nagu ECN.
5. Toetada NETCONF-i - tuleviku suunised.

Olen siin pühendanud Underlay-võrgu toimimisele vaid vähe aega. See on sellepärast, et edaspidi keskendun ma just sellele, samas kui Overlayd käsitleme vaid möödaminnes.

Ilmselgelt piirangustan ennast, kasutades näitena DC-võrku, mis on üles ehitatud Close'i tehase puhtale IP-marsruutimisele ja ülekattele hostilt.

Kuid olen kindel, et iga võrk, millel on disain, saab vormalsetes tingimustes kirjeldada ja automatiseerida. Lihtsalt minu siht on siin mõista automatiseerimise lähenemisi, mitte segadusse ajada kõiki, lahendades probleemi üldiselt.

ADSMi raames plaanime Roman Gorgiga avaldada eriväljaande arvutite võimsuse virtualiseerimisest ja selle suhtlemisest võrgu virtualiseerimisega. Jätkake jälgimist.

Kasulikud lingid

• Tungsten Fabric Arhitektuur.
• about:cloud. 6 tundi Yandex.Cloudist, sealhulgas ka TF-i virtuaalne võrk.
• Mis on Open vSwitch?
• Sissejuhatus VxLANi.
• RFC 7348. Virtuaalne Laiendatav Kohalik Võrk (VXLAN): Raamistik virtuaalsete II taseme võrkude ülekandmiseks III taseme võrkude kaudu.
  
• Scaleway lähenemine VXLAN EVPN Fabricile. Siin räägitakse kogu andmekeskuse võrgust, sealhulgas Underlay, Overlay, lähenemisviisidest multi-homing'ule ja haldusharjumustele.

Aitäh

• Roman Gorge — endine linkmeup'i podcasti juht, nüüdseks ekspert pilveplatvormide alal. Tänud kommentaaride ja paranduste eest. Ootame peagi ka tema süvitsi minevat artiklit virtualiseerimise kohta.
• Aleksandr Shalimov — minu kolleeg ja virtuaalsete võrkude arendamise ekspert. Tänud kommentaaride ja paranduste eest.
• Valentin Sinitsyn — minu kolleeg ja Tungsten Fabric'i ekspert. Tänud kommentaaride ja paranduste eest.
• Artyom Chernobay — linkmeup'i illustraator. Tänud KDPV eest.
• Aleksandr Limonov. Tänud meem „automato“ eest.

Allikas: habr.com