В tidligere nummer Jeg beskrev netværksautomatiseringsrammen. Ifølge nogle mennesker har selv denne første tilgang til problemet allerede løst nogle spørgsmål. Og det gør mig meget glad, for vores mål i cyklussen er ikke at dække over Ansible med Python-scripts, men at bygge et system.

Den samme ramme sætter den rækkefølge, vi vil behandle spørgsmålet i.
Og netværksvirtualisering, som dette nummer er dedikeret til, passer ikke specielt ind i ADSM-emnet, hvor vi analyserer automatisering.

Men lad os se på det fra en anden vinkel.

Mange tjenester har brugt det samme netværk i lang tid. Er der tale om en teleoperatør, er det for eksempel 2G, 3G, LTE, bredbånd og B2B. I tilfælde af en DC: forbindelse til forskellige klienter, internet, bloklagring, objektlagring.

Og alle tjenester kræver isolation fra hinanden. Sådan fremstod overlejringsnetværk.

Og alle tjenester ønsker ikke at vente på, at en person konfigurerer dem manuelt. Sådan fremstod orkestratorer og SDN.

Den første tilgang til systematisk automatisering af netværket, eller rettere en del af det, er længe blevet taget og implementeret mange steder: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Det er det, vi skal beskæftige os med i dag.

Indhold

• grunde
• terminologi
• Underlag - fysisk netværk
• Overlay - virtuelt netværk
  • Overlay med ToR
  • Overlejring fra vært
  • Brug af Tungsten Fabric som eksempel
    • Kommunikation i en enkelt fysisk maskine
    • Kommunikation mellem VM'er placeret på forskellige fysiske maskiner
    • Udgang til omverdenen

• FAQ
• Konklusion
• Nyttige links

grunde

Og da vi taler om dette, er det værd at nævne forudsætningerne for netværksvirtualisering. Faktisk begyndte denne proces ikke i går.

Du har sikkert hørt mere end én gang, at netværket altid har været den mest inaktive del af ethvert system. Og dette er sandt i enhver forstand. Netværket er grundlaget, hvorpå alt hviler, og at lave ændringer på det er ret svært - tjenester tolererer det ikke, når netværket er nede. Ofte kan nedlukning af en enkelt node fjerne en stor del af applikationerne og påvirke mange kunder. Dette er til dels grunden til, at netværksteamet kan modstå enhver ændring - for nu virker det på en eller anden måde (vi ved måske ikke engang hvordan), men her skal du konfigurere noget nyt, og det er uvist, hvordan det vil påvirke netværket.

For ikke at vente på, at netværksfolk indsætter VLAN'er og ikke registrerer nogen tjenester på hver netværksknude, kom folk op med ideen om at bruge overlejringer - overlejringsnetværk - som der er et stort udvalg af: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE osv.

Deres appel ligger i to simple ting:

• Kun slutnoder er konfigureret – transitknudepunkter behøver ikke at blive rørt. Dette fremskynder processen betydeligt og giver dig nogle gange mulighed for helt at udelukke netværksinfrastrukturafdelingen fra processen med at introducere nye tjenester.
• Belastningen er skjult dybt inde i overskrifterne - transitknudepunkter behøver ikke at vide noget om det, om adressering på værterne eller om ruterne i overlejringsnetværket. Det betyder, at du skal gemme mindre information i tabeller, hvilket betyder, at du bruger en enklere/billigere enhed.

I denne ikke helt fuldendte udgave planlægger jeg ikke at analysere alle mulige teknologier, men derimod beskrive rammerne for driften af ​​overlejringsnetværk i DC'er.

Hele serien vil beskrive et datacenter bestående af rækker af identiske racks, hvor det samme serverudstyr er installeret.

Dette udstyr kører virtuelle maskiner/containere/serverløse, der implementerer tjenester.

terminologi

I en løkke server Jeg vil navngive et program, der implementerer serversiden af ​​klient-server kommunikation.

Fysiske maskiner i racks kaldes servere nej vi vil.

Fysisk maskine — x86-computer installeret i et rack. Det mest brugte udtryk vært. Det vil vi kalde det"maskine"eller vært.

Hypervisor - et program, der kører på en fysisk maskine, der emulerer de fysiske ressourcer, som virtuelle maskiner kører på. Nogle gange i litteraturen og internettet bruges ordet "hypervisor" som et synonym for "vært".

Virtuel maskine - et operativsystem, der kører på en fysisk maskine oven på en hypervisor. For os i denne cyklus er det lige meget, om det faktisk er en virtuel maskine eller bare en container. Lad os kalde det "VM«

Lejer er et bredt begreb, som jeg i denne artikel vil definere som en separat service eller en separat klient.

Multi lejemål eller multitenancy - brugen af ​​den samme applikation af forskellige klienter/tjenester. Samtidig opnås isolering af klienter fra hinanden takket være applikationsarkitekturen og ikke gennem separat kørende instanser.

ToR — Top of the Rack switch - en switch installeret i et rack, hvortil alle fysiske maskiner er tilsluttet.

Ud over ToR-topologien praktiserer forskellige udbydere End of Row (EoR) eller Middle of Row (selvom sidstnævnte er en nedsættende sjældenhed, og jeg ikke har set MoR-forkortelsen).

Underlag netværk eller det underliggende netværk eller underlag er den fysiske netværksinfrastruktur: switche, routere, kabler.

Overlay netværk eller overlay netværk eller overlay - et virtuelt netværk af tunneler, der kører oven på den fysiske.

L3 stof eller IP stof - en fantastisk opfindelse af menneskeheden, der giver dig mulighed for at undgå at gentage STP og lære TRILL til interviews. Et koncept, hvor hele netværket op til adgangsniveauet udelukkende er L3, uden VLAN og dermed store udvidede broadcast-domæner. Vi vil se nærmere på, hvor ordet "fabrik" kommer fra i næste del.

SDN - Softwaredefineret netværk. Behøver næppe en introduktion. En tilgang til netværksstyring, hvor ændringer i netværket ikke foretages af en person, men af ​​et program. Betyder normalt at flytte kontrolplanet ud over slutnetværksenhederne til controlleren.

NFV - Network Function Virtualization - virtualisering af netværksenheder, hvilket tyder på, at nogle netværksfunktioner kan køres i form af virtuelle maskiner eller containere for at fremskynde implementeringen af ​​nye tjenester, organisere Service Chaining og enklere horisontal skalerbarhed.

VNF - Virtuel netværksfunktion. Specifik virtuel enhed: router, switch, firewall, NAT, IPS/IDS osv.

Jeg forenkler nu bevidst beskrivelsen til en specifik implementering, for ikke at forvirre læseren for meget. For mere tankevækkende læsning henviser jeg ham til afsnittet RЎSЃS <P "RєRё. Derudover lover Roma Gorge, som kritiserer denne artikel for unøjagtigheder, at skrive en separat udgave om server- og netværksvirtualiseringsteknologier, mere dybdegående og opmærksom på detaljer.

De fleste netværk i dag kan klart opdeles i to dele:

underlag — et fysisk netværk med en stabil konfiguration.
Overlay — abstraktion over underlag til isolering af lejere.

Dette gælder både for DC (som vi vil analysere i denne artikel) og for ISP (som vi ikke vil analysere, fordi det allerede er blevet SDSM). Med virksomhedsnetværk er situationen naturligvis noget anderledes.

Billede med fokus på netværket:

underlag

Underlag er et fysisk netværk: hardware-switches og kabler. Enheder i undergrunden ved, hvordan man når fysiske maskiner.

Den er afhængig af standardprotokoller og -teknologier. Ikke mindst fordi hardwareenheder den dag i dag opererer på proprietær software, der hverken tillader programmering af chippen eller implementering af dens egne protokoller, og derfor er der behov for kompatibilitet med andre leverandører og standardisering.

Men en person som Google har råd til at udvikle deres egne switches og opgive generelt accepterede protokoller. Men LAN_DC er ikke Google.

Underlaget ændres relativt sjældent, fordi dets opgave er grundlæggende IP-forbindelse mellem fysiske maskiner. Underlay ved intet om de tjenester, kunder eller lejere, der kører oven på det - det behøver kun at levere pakken fra en maskine til en anden.
Underlaget kunne være sådan her:

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

Underlay-netværket er konfigureret på den klassiske måde: CLI/GUI/NETCONF.

Manuelt, scripts, proprietære hjælpeprogrammer.

Den næste artikel i serien vil blive afsat til underlaget mere detaljeret.

Overlay

Overlay er et virtuelt netværk af tunneler strakt oven på Underlay, det giver VM'er fra én klient mulighed for at kommunikere med hinanden, samtidig med at det giver isolation fra andre klienter.

Klientdataene er indkapslet i nogle tunneloverskrifter til transmission over det offentlige netværk.

Så VM'er fra én klient (én tjeneste) kan kommunikere med hinanden gennem Overlay, uden overhovedet at vide, hvilken vej pakken faktisk tager.

Overlejring kunne for eksempel være, som jeg nævnte ovenfor:

• GRE tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVE

Et overlejringsnetværk konfigureres og vedligeholdes typisk via en central controller. Fra den leveres konfigurationen, kontrolplanet og dataplanet til enheder, der ruter og indkapsler klienttrafik. En lille nedenfor Lad os se på dette med eksempler.

Ja, dette er SDN i sin reneste form.

Der er to fundamentalt forskellige tilgange til at organisere et Overlay-netværk:

1. Overlay med ToR
2. Overlejring fra vært

Overlay med ToR

Overlay kan starte ved adgangskontakten (ToR), der står i racket, som det for eksempel sker i tilfælde af et VXLAN-stof.

Dette er en gennemtestet mekanisme på ISP-netværk, og alle leverandører af netværksudstyr understøtter den.

Men i dette tilfælde skal ToR-switchen kunne adskille henholdsvis de forskellige tjenester, og netværksadministratoren skal i et vist omfang samarbejde med de virtuelle maskine-administratorer og foretage ændringer (omend automatisk) i enhedernes konfiguration. .

Her vil jeg henvise læseren til en artikel om VxLAN på Habré vores gamle ven @bormoglotx.
Heri præsentationer med ENOG tilgange til at bygge et DC-netværk med et EVPN VXLAN-stof er beskrevet i detaljer.

Og for en mere fuldstændig fordybelse i virkeligheden kan du læse Tsiskas bog Et moderne, åbent og skalerbart stof: VXLAN EVPN.

Jeg bemærker, at VXLAN kun er en indkapslingsmetode, og terminering af tunneler kan ikke forekomme på ToR, men på værten, som det for eksempel sker i tilfældet med OpenStack.

VXLAN-stof, hvor overlayet starter ved ToR, er dog et af de etablerede overlay-netværksdesign.

Overlejring fra vært

En anden fremgangsmåde er at starte og afslutte tunneler på endeværterne.
I dette tilfælde forbliver netværket (Underlay) så enkelt og statisk som muligt.
Og værten selv laver al den nødvendige indkapsling.

Dette kræver selvfølgelig at køre en speciel applikation på værterne, men det er det værd.

For det første er det nemmere at køre en klient på en Linux-maskine eller, lad os sige, endda muligt, mens du på en switch højst sandsynligt bliver nødt til at vende dig til proprietære SDN-løsninger, hvilket dræber ideen om multi-leverandør.

For det andet kan ToR-switchen i dette tilfælde efterlades så simpel som muligt, både set fra kontrolplanet og dataplanet. Faktisk behøver den ikke at kommunikere med SDN-controlleren, og den behøver heller ikke at gemme netværkene/ARP'erne for alle tilsluttede klienter - det er nok at kende IP-adressen på den fysiske maskine, hvilket i høj grad forenkler omskiftningen/ rutetabeller.

I ADSM-serien vælger jeg overlay-tilgangen fra værten - så snakker vi kun om det, og vi vender ikke tilbage til VXLAN-fabrikken.

Det er nemmest at se på eksempler. Og som testperson vil vi tage OpenSource SDN-platformen OpenContrail, nu kendt som Wolfram stof.

I slutningen af ​​artiklen vil jeg komme med nogle tanker om analogien med OpenFlow og OpenvSwitch.

Brug af Tungsten Fabric som eksempel

Hver fysisk maskine har vRouter - en virtuel router, der kender til de netværk, der er forbundet til den, og hvilke klienter de tilhører - i det væsentlige en PE-router. For hver klient vedligeholder den en isoleret routingtabel (læs VRF). Og vRouter udfører faktisk Overlay-tunneling.

Lidt mere om vRouter er i slutningen af ​​artiklen.

Hver VM, der er placeret på hypervisoren, er forbundet til denne maskines vRouter via TAP interface.

TAP - Terminal Access Point - en virtuel grænseflade i Linux-kernen, der tillader netværksinteraktion.

Hvis der er flere netværk bag vRouteren, så oprettes der en virtuel grænseflade til hver af dem, som tildeles en IP-adresse - det vil være standard gateway-adressen.
Alle netværk af én klient er placeret i én VRF forlængelse (et bord), forskellige - til forskellige.
Jeg vil her gøre en ansvarsfraskrivelse om, at ikke alt er så simpelt, og jeg sender den nysgerrige læser til slutningen af ​​artiklen.

For at vRouters kan kommunikere med hinanden, og dermed de VM'er, der er placeret bag dem, udveksler de ruteinformation via SDN controller.

For at komme ud i omverdenen er der et udgangspunkt fra matrixen – en virtuel netværksgateway VNGW - Virtual Network GateWay (min periode).

Lad os nu se på eksempler på kommunikation - og der vil være klarhed.

Kommunikation i en enkelt fysisk maskine

VM0 ønsker at sende en pakke til VM2. Lad os nu antage, at dette er en VM med en enkelt klient.

Datafly

1. VM-0 har en standardrute til sin eth0-grænseflade. Pakken sendes dertil.
   Denne grænseflade eth0 er faktisk forbundet virtuelt til den virtuelle router vRouter gennem TAP-grænsefladen tap0.
2. vRouter analyserer, hvilken grænseflade pakken kom til, det vil sige hvilken klient (VRF) den tilhører, og tjekker modtagerens adresse med denne klients routingtabel.
3. Efter at have opdaget, at modtageren på den samme maskine er på en anden port, sender vRouter simpelthen pakken til den uden yderligere overskrifter - i dette tilfælde har vRouter allerede en ARP-indgang.

I dette tilfælde kommer pakken ikke ind i det fysiske netværk - den routes inde i vRouteren.

Kontrolplan

Når den virtuelle maskine starter, fortæller hypervisoren det:

• Hendes egen IP-adresse.
• Standardruten er gennem vRouterens IP-adresse på dette netværk.

Hypervisoren rapporterer til vRouter gennem en speciel API:

• Hvad du skal bruge for at skabe en virtuel grænseflade.
• Hvilken slags virtuelt netværk skal den (VM) oprette?
• Hvilken VRF (VN) den skal bindes til.
• En statisk ARP-indgang for denne VM - hvilken grænseflade er bag dens IP-adresse, og hvilken MAC-adresse den er knyttet til.

Igen er selve interaktionsproceduren forenklet for at forstå konceptet.

Således ser vRouter alle VM'er fra én klient på en given maskine som direkte forbundne netværk og kan selv rute mellem dem.

Men VM0 og VM1 tilhører forskellige klienter og er derfor i forskellige vRouter-tabeller.

Om de kan kommunikere direkte med hinanden afhænger af vRouter-indstillingerne og netværksdesignet.
For eksempel, hvis begge klienters VM'er bruger offentlige adresser, eller NAT forekommer på selve vRouteren, så kan direkte routing til vRouteren udføres.

I den modsatte situation er det muligt at krydse adresserum - du skal gennem en NAT-server for at få en offentlig adresse - det svarer til at få adgang til eksterne netværk, som omtales nedenfor.

Kommunikation mellem VM'er placeret på forskellige fysiske maskiner

Datafly

1. Begyndelsen er nøjagtig den samme: VM-0 sender en pakke med destinationen VM-7 (172.17.3.2) som standard.
2. vRouter modtager det og ser denne gang, at destinationen er på en anden maskine og er tilgængelig via Tunnel0.
3. For det første hænger den en MPLS-etiket, der identificerer fjerngrænsefladen, så vRouter på bagsiden kan bestemme, hvor denne pakke skal placeres uden yderligere opslag.

   

4. Tunnel0 har kilde 10.0.0.2, destination: 10.0.1.2.
   vRouter tilføjer GRE (eller UDP) headere og en ny IP til den originale pakke.
5. vRouter-routingtabellen har en standardrute gennem ToR1-adressen 10.0.0.1. Det er der, han sender det.

   
   

6. ToR1, som medlem af Underlay-netværket, ved (for eksempel via OSPF), hvordan man kommer til 10.0.1.2 og sender pakken langs ruten. Bemærk, at ECMP er aktiveret her. Der er to nexthops i illustrationen, og forskellige tråde vil blive sorteret i dem efter hash. I tilfælde af en rigtig fabrik vil der være mere sandsynligt 4 nexthops.

   Samtidig behøver han ikke at vide, hvad der er under den eksterne IP-header. Det vil sige, at der faktisk under IP kan være en sandwich af IPv6 over MPLS over Ethernet over MPLS over GRE over over græsk.

7. På den modtagende side fjerner vRouter derfor GRE og forstår ved hjælp af MPLS-tagget, hvilken grænseflade denne pakke skal sendes til, fjerner den og sender den i sin oprindelige form til modtageren.

Kontrolplan

Når du starter bilen, sker det samme som beskrevet ovenfor.

Og plus følgende:

• For hver klient tildeler vRouter et MPLS-tag. Dette er L3VPN-serviceetiketten, hvormed klienter vil blive adskilt i den samme fysiske maskine.
  

  Faktisk tildeles MPLS-tagget altid ubetinget af vRouteren - det er trods alt ikke kendt på forhånd, at maskinen kun vil interagere med andre maskiner bag den samme vRouter, og det er højst sandsynligt ikke engang sandt.

• vRouter etablerer en forbindelse med SDN-controlleren ved hjælp af BGP-protokollen (eller lignende - i tilfælde af TF er dette XMPP 0_o).
• Gennem denne session rapporterer vRouter ruter til tilsluttede netværk til SDN-controlleren:
  • Netværksadresse
  • Indkapslingsmetode (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS klient tag
  • Din IP-adresse som nexthop

• SDN-controlleren modtager sådanne ruter fra alle tilsluttede vRouters og afspejler dem til andre. Det vil sige, at den fungerer som en rutereflektor.

Det samme sker i den modsatte retning.

Overlejring kan ændres mindst hvert minut. Det er nogenlunde det, der sker i offentlige skyer, hvor klienter regelmæssigt starter og lukker deres virtuelle maskiner.

Den centrale controller tager sig af al kompleksiteten i at vedligeholde konfigurationen og overvåge switching/routing-tabellerne på vRouteren.

Groft sagt kommunikerer controlleren med alle vRouters via BGP (eller en lignende protokol) og transmitterer blot routinginformation. BGP har for eksempel allerede Address-Family til at formidle indkapslingsmetoden MPLS-i-GRE eller MPLS-i-UDP.

Samtidig ændres konfigurationen af ​​Underlay-netværket ikke på nogen måde, hvilket i øvrigt er meget sværere at automatisere og lettere at bryde med en akavet bevægelse.

Udgang til omverdenen

Et eller andet sted skal simuleringen slutte, og du skal forlade den virtuelle verden til den virkelige. Og du har brug for en betalingstelefongateway.

Der praktiseres to tilgange:

1. En hardware-router er installeret.
2. Der lanceres et apparat, der implementerer funktionerne i en router (ja, efter SDN stødte vi også på VNF). Lad os kalde det en virtuel gateway.

Fordelen ved den anden tilgang er billig horisontal skalerbarhed - der er ikke nok strøm - vi lancerede endnu en virtuel maskine med en gateway. På enhver fysisk maskine, uden at skulle lede efter gratis stativer, enheder, strømudgang, købe selve hardwaren, transportere den, installere den, skifte den, konfigurere den og derefter også ændre defekte komponenter i den.

Ulemperne ved en virtuel gateway er, at en enhed af en fysisk router stadig er størrelsesordener mere kraftfuld end en multi-core virtuel maskine, og dens software, skræddersyet til sin egen hardwarebase, fungerer meget mere stabilt (ingen). Det er også svært at benægte det faktum, at hardware- og softwarekomplekset simpelthen fungerer og kun kræver konfiguration, mens lancering og vedligeholdelse af en virtuel gateway er en opgave for stærke ingeniører.

Med én fod ser gatewayen ind i det virtuelle Overlay-netværk, som en almindelig virtuel maskine, og kan interagere med alle andre VM'er. Samtidig kan den afslutte alle klienters netværk og følgelig udføre routing mellem dem.

Med sin anden fod kigger gatewayen ind i backbone-netværket og ved, hvordan man kommer ind på internettet.

Datafly

Det vil sige, at processen ser sådan ud:

1. VM-0, der har valgt den samme vRouter som standard, sender en pakke med en destination i omverdenen (185.147.83.177) til eth0-grænsefladen.
2. vRouter modtager denne pakke og slår destinationsadressen op i routingtabellen - finder standardruten gennem VNGW1-gatewayen gennem Tunnel 1.
   Han ser også, at dette er en GRE-tunnel med SIP 10.0.0.2 og DIP 10.0.255.2, og han skal også først vedhæfte MPLS-mærket for denne klient, som VNGW1 forventer.
3. vRouter pakker den indledende pakke med MPLS, GRE og nye IP-headere og sender den til ToR1-adressen 10.0.0.1 som standard.
4. Det underliggende netværk leverer pakken til gatewayen VNGW1.
5. VNGW1-gatewayen fjerner GRE- og MPLS-tunneloverskrifterne, ser destinationsadressen, konsulterer dens routingtabel og forstår, at den er dirigeret til internettet - det vil sige gennem fuld visning eller standard. Udfører om nødvendigt NAT-oversættelse.
6. Der kan være et almindeligt IP-netværk fra VNGW til grænsen, hvilket er usandsynligt.
   Der kan være et klassisk MPLS-netværk (IGP+LDP/RSVP TE), der kan være et bagstof med BGP LU eller en GRE-tunnel fra VNGW til grænsen via et IP-netværk.
   Uanset hvad, udfører VNGW1 de nødvendige indkapslinger og sender den indledende pakke mod grænsen.

Trafikken i den modsatte retning går gennem de samme trin i den modsatte rækkefølge.

1. Grænsen dropper pakken til VNGW1
2. Han klæder ham af, ser på modtagerens adresse og ser, at han er tilgængelig gennem Tunnel1-tunnelen (MPLSoGRE eller MPLSoUDP).
3. Følgelig vedhæfter den en MPLS-etiket, en GRE/UDP-header og en ny IP og sender den til sin ToR3 10.0.255.1.
   Tunneldestinationsadressen er IP-adressen på den vRouter, bagved hvilken VM'en er placeret - 10.0.0.2.
4. Det underliggende netværk leverer pakken til den ønskede vRouter.
5. Mål-vRouteren læser GRE/UDP, identificerer grænsefladen ved hjælp af MPLS-etiketten og sender en blottet IP-pakke til dens TAP-grænseflade, der er forbundet med VM'ens eth0.

Kontrolplan

VNGW1 etablerer et BGP-kvarter med en SDN-controller, hvorfra den modtager al routing-information om klienter: hvilken IP-adresse (vRouter) er bag hvilken klient, og hvilken MPLS-etiket den er identificeret med.

På samme måde informerer han selv SDN-controlleren om standardruten med denne klients label, og angiver sig selv som nexthop. Og så kommer denne standard til vRouters.

På VNGW forekommer ruteaggregation eller NAT-oversættelse normalt.

Og i den anden retning sender den præcis denne aggregerede rute til sessionen med grænser eller rutereflektorer. Og fra dem modtager den standardruten eller Full-View eller noget andet.

Med hensyn til indkapsling og trafikudveksling er VNGW ikke anderledes end vRouter.
Hvis du udvider omfanget lidt, så kan du tilføje andre netværksenheder til VNGW'er og vRouters, såsom firewalls, trafikrensning eller berigelsesfarme, IPS og så videre.

Og ved hjælp af sekventiel oprettelse af VRF'er og korrekt annoncering af ruter, kan du tvinge trafikken til at sløjfe, som du ønsker, hvilket kaldes Service Chaining.

Det vil sige, at SDN-controlleren også her fungerer som en rutereflektor mellem VNGW'er, vRouters og andre netværksenheder.

Men faktisk frigiver controlleren også information om ACL og PBR (Policy Based Routing), hvilket får individuelle trafikstrømme til at gå anderledes, end ruten fortæller dem.

FAQ

Hvorfor bliver du ved med at komme med GRE/UDP-bemærkningen?

Tja, generelt kan dette siges at være specifikt for Tungsten Fabric - du behøver slet ikke tage højde for det.

Men hvis vi tager det, så understøttede TF selv, mens stadig OpenContrail, begge indkapslinger: MPLS i GRE og MPLS i UDP.

UDP er godt, fordi det i kildeporten er meget nemt at kode en hash-funktion fra den originale IP+Proto+Port i dens header, hvilket giver dig mulighed for at lave balancering.

I tilfældet GRE er der desværre kun eksterne IP- og GRE-headere, som er ens for al indkapslet trafik, og der er ikke tale om balancering - de færreste kan kigge så dybt inde i pakken.

Indtil nogen tid gjorde routere, hvis de vidste, hvordan man bruger dynamiske tunneler, det kun i MPLSoGRE, og først for ganske nylig lærte de at bruge MPLSoUDP. Derfor skal vi altid notere os om muligheden for to forskellige indkapslinger.

Retfærdigvis er det værd at bemærke, at TF fuldt ud understøtter L2-forbindelse ved hjælp af VXLAN.

Du lovede at drage paralleller med OpenFlow.
De beder virkelig om det. vSwitch i samme OpenStack gør meget lignende ting ved at bruge VXLAN, som i øvrigt også har en UDP-header.

I dataplanet fungerer de omtrent det samme; kontrolplanet adskiller sig væsentligt. Tungsten Fabric bruger XMPP til at levere routinginformation til vRouter, mens OpenStack kører Openflow.

Kan du fortælle mig lidt mere om vRouter?
Den er opdelt i to dele: vRouter Agent og vRouter Forwarder.

Den første kører i brugerområdet på værtsoperativsystemet og kommunikerer med SDN-controlleren og udveksler oplysninger om ruter, VRF'er og ACL'er.

Den anden implementerer Data Plane - normalt i Kernel Space, men kan også køre på SmartNICs - netværkskort med en CPU og en separat programmerbar switching-chip, som giver dig mulighed for at fjerne belastningen fra værtsmaskinens CPU, og gøre netværket hurtigere og mere forudsigelig.

Et andet muligt scenario er, at vRouter er en DPDK-applikation i User Space.

vRouter Agent sender indstillinger til vRouter Forwarder.

Hvad er et virtuelt netværk?
Jeg nævnte i begyndelsen af ​​artiklen om VRF, at hver lejer er bundet til sin egen VRF. Og hvis dette var nok til en overfladisk forståelse af driften af ​​overlejringsnetværket, så er det ved næste iteration nødvendigt at foretage afklaringer.

Typisk, i virtualiseringsmekanismer, introduceres Virtual Network-entiteten (du kan betragte dette som et egennavn) separat fra klienter/lejere/virtuelle maskiner - en fuldstændig uafhængig ting. Og dette virtuelle netværk kan allerede forbindes via grænseflader til en lejer, til en anden, til to eller hvor som helst. Så for eksempel implementeres Service Chaining, når trafik skal passeres gennem bestemte noder i den påkrævede rækkefølge, blot ved at oprette og forbinde virtuelle netværk i den korrekte rækkefølge.

Derfor er der som sådan ingen direkte korrespondance mellem det virtuelle netværk og lejeren.

Konklusion

Dette er en meget overfladisk beskrivelse af driften af ​​et virtuelt netværk med et overlay fra værten og en SDN-controller. Men uanset hvilken virtualiseringsplatform du vælger i dag, vil den fungere på lignende måde, det være sig VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric eller Juniper Contrail. De vil adskille sig i typerne af indkapslinger og headere, protokoller til levering af information til slutnetværksenheder, men princippet om et software-konfigurerbart overlay-netværk, der arbejder oven på et relativt simpelt og statisk underlay-netværk, vil forblive det samme.
Vi kan sige, at i dag har SDN baseret på et overlay-netværk vundet området med at skabe en privat sky. Det betyder dog ikke, at Openflow ikke har nogen plads i den moderne verden – det bruges i OpenStacke og i samme VMWare NSX, så vidt jeg ved, bruger Google det til at sætte det underjordiske netværk op.

Nedenfor har jeg givet links til mere detaljerede materialer, hvis du ønsker at studere spørgsmålet dybere.

Og hvad med vores underlag?

Men generelt ingenting. Han ændrede sig ikke hele vejen. Alt, hvad han skal gøre i tilfælde af en overlejring fra værten, er at opdatere ruter og ARP'er, når vRouter/VNGW vises og forsvinder og bærer pakker mellem dem.

Lad os formulere en liste over krav til Underlay-netværket.

1. Være i stand til at bruge en form for routingprotokol, i vores situation - BGP.
2. Hav en bred båndbredde, gerne uden overabonnement, så pakker ikke går tabt på grund af overbelastning.
3. Støtte til ECMP er en integreret del af stoffet.
4. Være i stand til at levere QoS, herunder vanskelige ting som ECN.
5. At støtte NETCONF er et fundament for fremtiden.

Jeg viede meget lidt tid her til arbejdet i selve Underlay-netværket. Det skyldes, at jeg senere i serien vil fokusere på det, og vi vil kun berøre Overlay i flæng.

Det er klart, jeg begrænser os alle alvorligt ved at bruge som eksempel et DC-netværk bygget på en Cloz-fabrik med ren IP-routing og et overlay fra værten.

Jeg er dog overbevist om, at ethvert netværk, der har et design, kan beskrives i formelle termer og automatiseres. Det er bare, at mit mål her er at forstå tilgange til automatisering, og ikke at forvirre alle ved at løse problemet i en generel form.

Som en del af ADSM planlægger Roman Gorge og jeg at udgive et separat nummer om virtualisering af computerkraft og dens interaktion med netværksvirtualisering. Holde kontakt.

Nyttige links

• Tungsten Fabric Archvitecture.
• om:sky. 6 timer om Yandex.Cloud, som også dækker det virtuelle netværk på TF.
• Hvad er Open vSwitch?
• Introduktion til VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): En ramme til overlejring af virtualiserede lag 2-netværk over lag 3-netværk.
  
• Scaleway tilgang til VXLAN EVPN Fabric. Den taler om hele DC-netværket, inklusive Underlay, Overlay, tilgange til multi-homing og management.

Tak

• Roman Gorga - tidligere vært for linkmeup-podcasten og nu ekspert inden for cloud-platforme. For kommentarer og redigeringer. Nå, vi venter på hans mere dybdegående artikel om virtualisering i den nærmeste fremtid.
• Alexander Shalimov - min kollega og ekspert inden for udvikling af virtuelt netværk. For kommentarer og redigeringer.
• Valentin Sinitsyn - min kollega og ekspert inden for Tungsten Fabric. For kommentarer og redigeringer.
• Artyom Chernobay — illustrator linkmeup. For KDPV.
• Alexander Limonov. Til "automato" meme.

Kilde: www.habr.com