В forrige utgave Jeg beskrev rammeverket for nettverksautomatisering. Ifølge noen mennesker har selv denne første tilnærmingen til problemet allerede løst noen spørsmål. Og dette gjør meg veldig glad, fordi målet vårt i syklusen ikke er å dekke over Ansible med Python-skript, men å bygge et system.

Det samme rammeverket setter rekkefølgen vi skal behandle spørsmålet i.
Og nettverksvirtualisering, som denne utgaven er dedikert til, passer ikke spesielt inn i ADSM-emnet, hvor vi analyserer automatisering.

Men la oss se på det fra en annen vinkel.

Mange tjenester har brukt samme nettverk i lang tid. For en teleoperatør er dette for eksempel 2G, 3G, LTE, bredbånd og B2B. I tilfelle av en DC: tilkobling for forskjellige klienter, Internett, blokklagring, objektlagring.

Og alle tjenester krever isolasjon fra hverandre. Slik så overleggsnettverk ut.

Og alle tjenester ønsker ikke å vente på at en person skal konfigurere dem manuelt. Slik fremsto orkestratorer og SDN.

Den første tilnærmingen til systematisk automatisering av nettverket, eller rettere sagt en del av det, har lenge blitt tatt og implementert mange steder: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Det er det vi skal forholde oss til i dag.

Innhold

• Årsaker
• terminologi
• Underlag - fysisk nettverk
• Overlegg - virtuelt nettverk
  • Overlegg med ToR
  • Overlegg fra vert
  • Bruke Tungsten Fabric som eksempel
    • Kommunikasjon innenfor en enkelt fysisk maskin
    • Kommunikasjon mellom virtuelle maskiner plassert på forskjellige fysiske maskiner
    • Utgang til omverdenen

• FAQ
• Konklusjon
• Nyttige lenker

Årsaker

Og siden vi snakker om dette, er det verdt å nevne forutsetningene for nettverksvirtualisering. Faktisk startet ikke denne prosessen i går.

Du har sikkert hørt mer enn én gang at nettverket alltid har vært den mest inerte delen av ethvert system. Og dette er sant på alle måter. Nettverket er grunnlaget som alt hviler på, og å gjøre endringer på det er ganske vanskelig - tjenester tolererer det ikke når nettverket er nede. Ofte kan dekommisjonering av en enkelt node ta ned en stor del av applikasjonene og påvirke mange kunder. Dette er delvis grunnen til at nettverksteamet kan motstå enhver endring - for nå fungerer det på en eller annen måte (vi vet kanskje ikke engang hvordan), men her må du konfigurere noe nytt, og det er ukjent hvordan det vil påvirke nettverket.

For ikke å vente på at nettverksbrukere skal sette inn VLAN og ikke registrere noen tjenester på hver nettverksnode, kom folk opp med ideen om å bruke overlegg - overleggsnettverk - som det er et stort utvalg av: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Appellen deres ligger i to enkle ting:

• Bare endenoder er konfigurert – transittnoder trenger ikke å berøres. Dette fremskynder prosessen betydelig, og noen ganger lar deg ekskludere nettverksinfrastrukturavdelingen fullstendig fra prosessen med å introdusere nye tjenester.
• Lasten er skjult dypt inne i overskriftene - transittnoder trenger ikke å vite noe om det, om adressering på vertene, eller om rutene til overleggsnettverket. Dette betyr at du trenger å lagre mindre informasjon i tabeller, noe som betyr å bruke en enklere/billigere enhet.

I denne ikke helt fullverdige utgaven planlegger jeg ikke å analysere alle mulige teknologier, men heller beskrive rammeverket for driften av overleggsnettverk i DC-er.

Hele serien skal beskrive et datasenter som består av rader med identiske rack der det samme serverutstyret er installert.

Dette utstyret kjører virtuelle maskiner/containere/serverløse som implementerer tjenester.

terminologi

I en løkke server Jeg vil navngi et program som implementerer serversiden av klient-server kommunikasjon.

Fysiske maskiner i rack kalles servere no vi vil.

Fysisk maskin — x86-datamaskin installert i et rack. Det mest brukte begrepet host. Det er det vi kaller det "maskin"eller host.

Hypervisor - en applikasjon som kjører på en fysisk maskin som emulerer de fysiske ressursene som virtuelle maskiner kjører på. Noen ganger i litteratur og Internett brukes ordet "hypervisor" som et synonym for "vert".

Virtuell maskin - et operativsystem som kjører på en fysisk maskin på toppen av en hypervisor. For oss i denne syklusen spiller det ingen rolle om det faktisk er en virtuell maskin eller bare en beholder. La oss kalle det "VM«

Leietaker er et vidt begrep som jeg i denne artikkelen vil definere som en egen tjeneste eller en egen klient.

Flerleieforhold eller multitenancy - bruk av samme applikasjon av forskjellige klienter/tjenester. Samtidig oppnås isolasjon av klienter fra hverandre takket være applikasjonsarkitekturen, og ikke gjennom separat kjørende instanser.

ToR — Top of the Rack-bryter - en bryter installert i et stativ som alle fysiske maskiner er koblet til.

I tillegg til ToR-topologien, praktiserer ulike leverandører End of Row (EoR) eller Middle of Row (selv om sistnevnte er en nedsettende sjeldenhet og jeg ikke har sett MoR-forkortelsen).

Underlagsnettverk eller det underliggende nettverket eller underlaget er den fysiske nettverksinfrastrukturen: brytere, rutere, kabler.

Overlegg nettverk eller overleggsnettverk eller overlegg - et virtuelt nettverk av tunneler som kjører på toppen av den fysiske.

L3-stoff eller IP-stoff - en fantastisk oppfinnelse av menneskeheten som lar deg unngå å gjenta STP og lære TRILL for intervjuer. Et konsept der hele nettverket opp til tilgangsnivået er utelukkende L3, uten VLAN og følgelig enorme utvidede kringkastingsdomener. Vi skal se på hvor ordet "fabrikk" kommer fra i neste del.

SDN - Programvaredefinert nettverk. Trenger neppe en introduksjon. En tilnærming til nettverksadministrasjon der endringer i nettverket ikke gjøres av en person, men av et program. Betyr vanligvis å flytte kontrollplanet utover sluttnettverksenhetene til kontrolleren.

NFV — Nettverksfunksjonsvirtualisering — virtualisering av nettverksenheter, noe som antyder at noen nettverksfunksjoner kan kjøres i form av virtuelle maskiner eller containere for å fremskynde implementeringen av nye tjenester, organisere tjenestekjeding og enklere horisontal skalerbarhet.

VNF - Virtuell nettverksfunksjon. Spesifikk virtuell enhet: ruter, svitsj, brannmur, NAT, IPS/IDS, etc.

Jeg forenkler nå med vilje beskrivelsen til en spesifikk implementering, for ikke å forvirre leseren for mye. For mer gjennomtenkt lesing henviser jeg ham til avsnittet referanser. I tillegg lover Roma Gorge, som kritiserer denne artikkelen for unøyaktigheter, å skrive en egen utgave om server- og nettverksvirtualiseringsteknologier, mer dyptgående og oppmerksom på detaljer.

De fleste nettverk i dag kan tydelig deles inn i to deler:

underlag — et fysisk nettverk med stabil konfigurasjon.
overlay — abstraksjon over underlag for isolering av leietakere.

Dette gjelder både for DC (som vi vil analysere i denne artikkelen) og for ISP (som vi ikke vil analysere, fordi det allerede har vært SDSM). Med bedriftsnettverk er situasjonen selvfølgelig noe annerledes.

Bilde med fokus på nettverket:

underlag

Underlag er et fysisk nettverk: maskinvarebrytere og kabler. Enheter i undergrunnen vet hvordan de skal nå fysiske maskiner.

Den er avhengig av standard protokoller og teknologier. Ikke minst fordi maskinvareenheter den dag i dag opererer på proprietær programvare som verken tillater programmering av brikken eller implementering av egne protokoller, og derfor er det nødvendig med kompatibilitet med andre leverandører og standardisering.

Men noen som Google har råd til å utvikle sine egne brytere og forlate allment aksepterte protokoller. Men LAN_DC er ikke Google.

Underlag endres relativt sjelden fordi jobben er grunnleggende IP-tilkobling mellom fysiske maskiner. Underlay vet ingenting om tjenestene, klientene eller leietakerne som kjører på toppen av det - det trenger bare å levere pakken fra en maskin til en annen.
Underlaget kan være slik:

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

Underlagsnettverket er konfigurert på klassisk måte: CLI/GUI/NETCONF.

Manuelt, skript, proprietære verktøy.

Den neste artikkelen i serien vil bli viet underlaget mer detaljert.

overlay

Overlay er et virtuelt nettverk av tunneler strukket på toppen av Underlay, det lar VM-er til én klient kommunisere med hverandre, samtidig som det gir isolasjon fra andre klienter.

Klientdataene er innkapslet i noen tunneloverskrifter for overføring over det offentlige nettverket.

Så VM-er til én klient (én tjeneste) kan kommunisere med hverandre gjennom Overlay, uten engang å vite hvilken vei pakken faktisk tar.

Overlegg kan for eksempel være som jeg nevnte ovenfor:

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

Et overleggsnettverk konfigureres og vedlikeholdes vanligvis gjennom en sentral kontroller. Fra den leveres konfigurasjonen, kontrollplanet og dataplanet til enheter som ruter og innkapsler klienttrafikk. Litt under La oss se på dette med eksempler.

Ja, dette er SDN i sin reneste form.

Det er to fundamentalt forskjellige tilnærminger til å organisere et overleggsnettverk:

1. Overlegg med ToR
2. Overlegg fra vert

Overlegg med ToR

Overlegg kan starte ved tilgangsbryteren (ToR) som står i stativet, slik det for eksempel skjer ved et VXLAN-stoff.

Dette er en tidstestet mekanisme på ISP-nettverk og alle leverandører av nettverksutstyr støtter den.

Men i dette tilfellet må ToR-svitsjen kunne skille henholdsvis de ulike tjenestene, og nettverksadministratoren må til en viss grad samarbeide med de virtuelle maskinadministratorene og gjøre endringer (om enn automatisk) i konfigurasjonen av enhetene .

Her vil jeg henvise leseren til en artikkel om VxLAN på Habré vår gamle venn @bormoglotx.
I dette presentasjoner med ENOG tilnærminger til å bygge et DC-nettverk med et EVPN VXLAN-stoff er beskrevet i detalj.

Og for en mer fullstendig fordypning i virkeligheten, kan du lese Tsiskas bok Et moderne, åpent og skalerbart stoff: VXLAN EVPN.

Jeg legger merke til at VXLAN kun er en innkapslingsmetode og terminering av tunneler kan ikke skje på ToR, men på verten, slik det for eksempel skjer i tilfellet med OpenStack.

Imidlertid er VXLAN-stoff, der overlegget starter ved ToR, en av de etablerte overleggsnettverksdesignene.

Overlegg fra vert

En annen tilnærming er å starte og avslutte tunneler på endevertene.
I dette tilfellet forblir nettverket (Underlag) så enkelt og statisk som mulig.
Og verten selv gjør all nødvendig innkapsling.

Dette vil selvfølgelig kreve å kjøre en spesiell applikasjon på vertene, men det er verdt det.

For det første er det enklere å kjøre en klient på en Linux-maskin, eller, la oss si, til og med mulig, mens du på en svitsj vil mest sannsynlig måtte vende deg til proprietære SDN-løsninger, som dreper ideen om multileverandør.

For det andre kan ToR-bryteren i dette tilfellet etterlates så enkel som mulig, både fra kontrollplanet og dataplanet. Da trenger den faktisk ikke å kommunisere med SDN-kontrolleren, og den trenger heller ikke å lagre nettverkene/ARP-ene til alle tilkoblede klienter - det er nok å kjenne IP-adressen til den fysiske maskinen, noe som i stor grad forenkler vekslingen/ rutetabeller.

I ADSM-serien velger jeg overleggstilnærmingen fra verten - da snakker vi bare om det og vi kommer ikke tilbake til VXLAN-fabrikken.

Det er lettest å se på eksempler. Og som testperson vil vi ta OpenSource SDN-plattformen OpenContrail, nå kjent som Tungsten stoff.

På slutten av artikkelen vil jeg gi noen tanker om analogien med OpenFlow og OpenvSwitch.

Bruke Tungsten Fabric som eksempel

Hver fysisk maskin har vRouter - en virtuell ruter som vet om nettverkene som er koblet til den og hvilke klienter de tilhører - i hovedsak en PE-ruter. For hver klient opprettholder den en isolert rutingtabell (les VRF). Og vRouter utfører faktisk Overlay-tunneling.

Litt mer om vRouter er på slutten av artikkelen.

Hver VM som ligger på hypervisoren er koblet til vRouteren til denne maskinen via TAP-grensesnitt.

TAP - Terminal Access Point - et virtuelt grensesnitt i Linux-kjernen som tillater nettverksinteraksjon.

Hvis det er flere nettverk bak vRouteren, opprettes et virtuelt grensesnitt for hver av dem, som en IP-adresse er tildelt - det vil være standard gateway-adresse.
Alle nettverk til én klient er plassert i ett VRF utvidelse (ett bord), forskjellige - til forskjellige.
Jeg kommer med en ansvarsfraskrivelse her om at ikke alt er så enkelt, og jeg sender den nysgjerrige leseren til slutten av artikkelen.

For at vRoutere skal kommunisere med hverandre, og følgelig VM-ene som ligger bak dem, utveksler de rutinginformasjon via SDN-kontroller.

For å komme ut i omverdenen er det et utgangspunkt fra matrisen – en virtuell nettverksport VNGW - Virtual Network GateWay (min periode).

La oss nå se på eksempler på kommunikasjon – og det blir klarhet.

Kommunikasjon innenfor en enkelt fysisk maskin

VM0 ønsker å sende en pakke til VM2. La oss foreløpig anta at dette er en VM med én klient.

Dataplan

1. VM-0 har en standardrute til eth0-grensesnittet. Pakken sendes dit.
   Dette grensesnittet eth0 er faktisk koblet virtuelt til den virtuelle ruteren vRouter gjennom TAP-grensesnittet tap0.
2. vRouter analyserer hvilket grensesnitt pakken kom til, det vil si hvilken klient (VRF) den tilhører, og sjekker mottakerens adresse med rutetabellen til denne klienten.
3. Etter å ha oppdaget at mottakeren på samme maskin er på en annen port, sender vRouter ganske enkelt pakken til den uten ekstra overskrifter - for dette tilfellet har vRouter allerede en ARP-oppføring.

I dette tilfellet kommer ikke pakken inn i det fysiske nettverket - den rutes inne i vRouteren.

Kontrollplan

Når den virtuelle maskinen starter, forteller hypervisoren:

• Hennes egen IP-adresse.
• Standardruten er gjennom vRouterens IP-adresse på dette nettverket.

Hypervisoren rapporterer til vRouter gjennom en spesiell API:

• Hva du trenger for å lage et virtuelt grensesnitt.
• Hva slags virtuelt nettverk trenger den (VM) for å lage?
• Hvilken VRF (VN) den skal bindes til.
• En statisk ARP-oppføring for denne VM-en - hvilket grensesnitt som ligger bak IP-adressen og hvilken MAC-adresse den er knyttet til.

Igjen er selve interaksjonsprosedyren forenklet for å forstå konseptet.

Dermed ser vRouter alle VM-er til én klient på en gitt maskin som direkte tilkoblede nettverk og kan rute mellom dem selv.

Men VM0 og VM1 tilhører forskjellige klienter og er følgelig i forskjellige vRouter-tabeller.

Hvorvidt de kan kommunisere med hverandre direkte, avhenger av vRouter-innstillingene og nettverksdesign.
For eksempel, hvis begge klientenes VM-er bruker offentlige adresser, eller NAT forekommer på selve vRouteren, kan direkte ruting til vRouteren gjøres.

I motsatt situasjon er det mulig å krysse adresserom - du må gå gjennom en NAT-server for å få en offentlig adresse - dette ligner på tilgang til eksterne nettverk, som diskuteres nedenfor.

Kommunikasjon mellom virtuelle maskiner plassert på forskjellige fysiske maskiner

Dataplan

1. Begynnelsen er nøyaktig den samme: VM-0 sender en pakke med destinasjonen VM-7 (172.17.3.2) som standard.
2. vRouter mottar den og ser denne gangen at destinasjonen er på en annen maskin og er tilgjengelig gjennom Tunnel0.
3. Først henger den en MPLS-etikett som identifiserer det eksterne grensesnittet, slik at vRouter på baksiden kan bestemme hvor denne pakken skal plasseres uten ytterligere oppslag.

   

4. Tunnel0 har kilde 10.0.0.2, destinasjon: 10.0.1.2.
   vRouter legger til GRE (eller UDP) overskrifter og en ny IP til den originale pakken.
5. vRouter-rutingstabellen har en standardrute gjennom ToR1-adressen 10.0.0.1. Det er dit han sender det.

   
   

6. ToR1, som medlem av Underlay-nettverket, vet (for eksempel via OSPF) hvordan man kommer til 10.0.1.2 og sender pakken langs ruten. Merk at ECMP er aktivert her. Det er to nexthops i illustrasjonen, og forskjellige tråder vil bli sortert inn i dem etter hash. I tilfelle av en ekte fabrikk, vil det være mer sannsynlig 4 nexthops.

   Samtidig trenger han ikke å vite hva som ligger under den eksterne IP-headeren. Det vil si at under IP kan det være en sandwich av IPv6 over MPLS over Ethernet over MPLS over GRE over over gresk.

7. Følgelig, på mottakersiden, fjerner vRouter GRE og forstår ved hjelp av MPLS-taggen hvilket grensesnitt denne pakken skal sendes til, fjerner den og sender den i sin opprinnelige form til mottakeren.

Kontrollplan

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

Og pluss følgende:

• For hver klient tildeler vRouter en MPLS-tag. Dette er L3VPN-tjenesteetiketten, hvor klienter vil bli separert innenfor den samme fysiske maskinen.
  

  Faktisk tildeles MPLS-taggen alltid ubetinget av vRouteren - tross alt er det ikke kjent på forhånd at maskinen kun vil samhandle med andre maskiner bak samme vRouter, og dette er mest sannsynlig ikke engang sant.

• vRouter oppretter en forbindelse med SDN-kontrolleren ved å bruke BGP-protokollen (eller lignende - i tilfelle TF er dette XMPP 0_o).
• Gjennom denne økten rapporterer vRouter ruter til tilkoblede nettverk til SDN-kontrolleren:
  • Nettverksadresse
  • Innkapslingsmetode (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS klient tag
  • Din IP-adresse som nexthop

• SDN-kontrolleren mottar slike ruter fra alle tilkoblede vRouters og reflekterer dem til andre. Det vil si at den fungerer som en rutereflektor.

Det samme skjer i motsatt retning.

Overlegg kan endres minst hvert minutt. Dette er omtrent det som skjer i offentlige skyer, der klienter regelmessig starter og slår av sine virtuelle maskiner.

Den sentrale kontrolleren tar seg av all kompleksiteten med å vedlikeholde konfigurasjonen og overvåke svitsje-/rutingstabellene på vRouteren.

Grovt sett kommuniserer kontrolleren med alle vRouters via BGP (eller en lignende protokoll) og overfører rett og slett rutinginformasjon. BGP har for eksempel allerede Address-Family for å formidle innkapslingsmetoden MPLS-i-GRE eller MPLS-i-UDP.

Samtidig endres ikke konfigurasjonen av Underlay-nettverket på noen måte, noe som forresten er mye vanskeligere å automatisere, og lettere å bryte med en vanskelig bevegelse.

Utgang til omverdenen

Et sted må simuleringen ende, og du må gå ut av den virtuelle verden til den virkelige. Og du trenger en betalingstelefongateway.

To tilnærminger praktiseres:

1. En maskinvareruter er installert.
2. En enhet lanseres som implementerer funksjonene til en ruter (ja, etter SDN, møtte vi også VNF). La oss kalle det en virtuell gateway.

Fordelen med den andre tilnærmingen er billig horisontal skalerbarhet - det er ikke nok kraft - vi lanserte en annen virtuell maskin med en gateway. På en hvilken som helst fysisk maskin, uten å måtte lete etter gratis stativer, enheter, strømuttak, kjøpe selve maskinvaren, transportere den, installere den, bytte den, konfigurere den og deretter også endre defekte komponenter i den.

Ulempene med en virtuell gateway er at en enhet av en fysisk ruter fortsatt er størrelsesordener kraftigere enn en multi-core virtuell maskin, og programvaren, skreddersydd til sin egen maskinvarebase, fungerer mye mer stabil (ikke). Det er også vanskelig å benekte det faktum at maskinvare- og programvarekomplekset ganske enkelt fungerer, og krever kun konfigurasjon, mens lansering og vedlikehold av en virtuell gateway er en oppgave for sterke ingeniører.

Med én fot ser gatewayen inn i det virtuelle Overlay-nettverket, som en vanlig virtuell maskin, og kan samhandle med alle andre VM-er. Samtidig kan den avslutte nettverkene til alle klienter og følgelig utføre ruting mellom dem.

Med den andre foten ser gatewayen inn i ryggradsnettverket og vet hvordan den skal komme seg inn på Internett.

Dataplan

Det vil si at prosessen ser slik ut:

1. VM-0, etter å ha brukt samme vRouter som standard, sender en pakke med en destinasjon i omverdenen (185.147.83.177) til eth0-grensesnittet.
2. vRouter mottar denne pakken og slår opp destinasjonsadressen i rutingtabellen – finner standardruten gjennom VNGW1-gatewayen gjennom 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 må også først feste MPLS-etiketten til denne klienten, som VNGW1 forventer.
3. vRouter pakker den første pakken med MPLS, GRE og nye IP-hoder og sender den til ToR1 10.0.0.1 som standard.
4. Det underliggende nettverket leverer pakken til gatewayen VNGW1.
5. VNGW1-gatewayen fjerner GRE- og MPLS-tunnelhodene, ser destinasjonsadressen, konsulterer rutetabellen og forstår at den er dirigert til Internett - det vil si gjennom Full View eller Default. Utfører om nødvendig NAT-oversettelse.
6. Det kan være et vanlig IP-nettverk fra VNGW til grensen, noe som er usannsynlig.
   Det kan være et klassisk MPLS-nettverk (IGP+LDP/RSVP TE), det kan være et bakstoff med BGP LU eller en GRE-tunnel fra VNGW til grensen via et IP-nettverk.
   Uansett, VNGW1 utfører de nødvendige innkapslingene og sender den første pakken mot grensen.

Trafikk i motsatt retning går gjennom de samme trinnene i motsatt rekkefølge.

1. Grensen slipper pakken til VNGW1
2. Han kler av ham, ser på mottakerens adresse og ser at han er tilgjengelig gjennom Tunnel1-tunnelen (MPLSoGRE eller MPLSoUDP).
3. Følgelig fester den en MPLS-etikett, en GRE/UDP-header og en ny IP og sender den til ToR3 10.0.255.1.
   Tunneldestinasjonsadressen er IP-adressen til vRouteren bak mål-VM er plassert - 10.0.0.2.
4. Det underliggende nettverket leverer pakken til ønsket vRouter.
5. Mål-vRouteren leser GRE/UDP, identifiserer grensesnittet ved hjelp av MPLS-etiketten og sender en bare IP-pakke til TAP-grensesnittet assosiert med eth0 til VM.

Kontrollplan

VNGW1 etablerer et BGP-område med en SDN-kontroller, hvorfra den mottar all rutinginformasjon om klienter: hvilken IP-adresse (vRouter) er bak hvilken klient, og hvilken MPLS-etikett identifiserer den.

På samme måte informerer han selv SDN-kontrolleren om standardruten med etiketten til denne klienten, og indikerer seg selv som nexthop. Og så kommer denne standarden til vRouters.

På VNGW forekommer vanligvis ruteaggregering eller NAT-oversettelse.

Og i den andre retningen sender han akkurat denne aggregerte ruten til økten med grenser eller rutereflektorer. Og fra dem mottar den standardruten eller Full-View, eller noe annet.

Når det gjelder innkapsling og trafikkutveksling, er ikke VNGW forskjellig fra vRouter.
Hvis du utvider omfanget litt, kan du legge til andre nettverksenheter til VNGW-er og vRouters, for eksempel brannmurer, trafikkrensing eller anrikningsfarmer, IPS og så videre.

Og ved hjelp av sekvensiell oppretting av VRF-er og korrekt kunngjøring av ruter, kan du tvinge trafikken til å sløyfe slik du ønsker, som kalles Service Chaining.

Det vil si at også her fungerer SDN-kontrolleren som en rutereflektor mellom VNGW-er, vRouters og andre nettverksenheter.

Men faktisk frigjør kontrolleren også informasjon om ACL og PBR (Policy Based Routing), noe som får individuelle trafikkstrømmer til å gå annerledes enn ruten forteller dem om.

FAQ

Hvorfor fortsetter du med GRE/UDP-bemerkningen?

Vel, generelt kan dette sies å være spesifikt for Tungsten Fabric - du trenger ikke å ta hensyn til det i det hele tatt.

Men hvis vi tar det, støttet TF selv, mens fortsatt OpenContrail, begge innkapslingene: MPLS i GRE og MPLS i UDP.

UDP er bra fordi i kildeporten er det veldig enkelt å kode en hash-funksjon fra den originale IP+Proto+Porten i overskriften, som lar deg gjøre balansering.

Når det gjelder GRE, dessverre, er det kun eksterne IP- og GRE-headere, som er like for all innkapslet trafikk og det er ikke snakk om balansering - få mennesker kan se så dypt inni pakken.

Inntil en tid gjorde rutere, hvis de visste hvordan de skulle bruke dynamiske tunneler, det bare i MPLSoGRE, og først helt nylig lærte de å bruke MPLSoUDP. Derfor må vi alltid notere oss om muligheten for to forskjellige innkapslinger.

For rettferdighetens skyld er det verdt å merke seg at TF fullt ut støtter L2-tilkobling ved bruk av VXLAN.

Du lovet å trekke paralleller med OpenFlow.
De ber virkelig om det. vSwitch i samme OpenStack gjør veldig lignende ting, ved å bruke VXLAN, som forresten også har en UDP-header.

I dataplanet fungerer de omtrent likt; kontrollplanet er betydelig forskjellig. Tungsten Fabric bruker XMPP for å levere rutinginformasjon til vRouter, mens OpenStack kjører Openflow.

Kan du fortelle meg litt mer om vRouter?
Den er delt inn i to deler: vRouter Agent og vRouter Forwarder.

Den første kjører i brukerområdet til vertsoperativsystemet og kommuniserer med SDN-kontrolleren, og utveksler informasjon om ruter, VRF-er og ACL-er.

Den andre implementerer Data Plane - vanligvis i Kernel Space, men kan også kjøres på SmartNICs - nettverkskort med en CPU og en separat programmerbar svitsjebrikke, som lar deg fjerne belastningen fra vertsmaskinens CPU, og gjøre nettverket raskere og mer forutsigbar.

Et annet mulig scenario er at vRouter er en DPDK-applikasjon i User Space.

vRouter Agent sender innstillinger til vRouter Forwarder.

Hva er et virtuelt nettverk?
Jeg nevnte i begynnelsen av artikkelen om VRF at hver leietaker er knyttet til sin egen VRF. Og hvis dette var nok for en overfladisk forståelse av driften av overleggsnettverket, er det ved neste iterasjon nødvendig å gjøre avklaringer.

Vanligvis, i virtualiseringsmekanismer, introduseres Virtual Network-enheten (du kan betrakte dette som et egennavn) separat fra klienter/leietakere/virtuelle maskiner - en helt uavhengig ting. Og dette virtuelle nettverket kan allerede kobles til via grensesnitt til én leietaker, til en annen, til to eller hvor som helst. Så, for eksempel, er Service Chaining implementert når trafikk må sendes gjennom bestemte noder i den nødvendige sekvensen, ganske enkelt ved å opprette og koble til virtuelle nettverk i riktig sekvens.

Derfor er det som sådan ingen direkte korrespondanse mellom det virtuelle nettverket og leietakeren.

Konklusjon

Dette er en veldig overfladisk beskrivelse av driften av et virtuelt nettverk med et overlegg fra verten og en SDN-kontroller. Men uansett hvilken virtualiseringsplattform du velger i dag, vil den fungere på lignende måte, det være seg VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric eller Juniper Contrail. De vil være forskjellige i typene innkapslinger og overskrifter, protokoller for å levere informasjon til sluttnettverksenheter, men prinsippet om et programvarekonfigurerbart overleggsnettverk som opererer på toppen av et relativt enkelt og statisk underlagsnettverk vil forbli det samme.
Vi kan si at i dag har SDN basert på et overleggsnettverk vunnet feltet for å lage en privat sky. Dette betyr imidlertid ikke at Openflow ikke har noen plass i den moderne verden – den brukes i OpenStacke og i samme VMWare NSX, så vidt jeg vet bruker Google den til å sette opp det underjordiske nettverket.

Nedenfor har jeg gitt lenker til mer detaljert materiale hvis du ønsker å studere problemet dypere.

Og hva med underlaget vårt?

Men generelt, ingenting. Han forandret seg ikke hele veien. Alt han trenger å gjøre i tilfelle et overlegg fra verten er å oppdatere ruter og ARP-er når vRouter/VNGW vises og forsvinner og bærer pakker mellom dem.

La oss formulere en liste over krav til underlagsnettverket.

1. Kunne bruke en slags rutingprotokoll, i vår situasjon - BGP.
2. Ha bred båndbredde, gjerne uten overabonnement, slik at pakker ikke går tapt på grunn av overbelastning.
3. Støtte for ECMP er en integrert del av stoffet.
4. Kunne gi QoS, inkludert vanskelige ting som ECN.
5. Å støtte NETCONF er et grunnlag for fremtiden.

Jeg viet veldig lite tid her til arbeidet med selve Underlay-nettverket. Dette er fordi jeg senere i serien vil fokusere på det, og vi skal bare berøre Overlay i forbifarten.

Det er klart at jeg begrenser oss alle sterkt ved å bruke som et eksempel et DC-nettverk bygget i en Cloz-fabrikk med ren IP-ruting og et overlegg fra verten.

Jeg er imidlertid sikker på at ethvert nettverk som har et design kan beskrives i formelle termer og automatiseres. Det er bare det at målet mitt her er å forstå tilnærminger til automatisering, og ikke å forvirre alle ved å løse problemet i en generell form.

Som en del av ADSM planlegger Roman Gorge og jeg å publisere en egen utgave om virtualisering av datakraft og dens interaksjon med nettverksvirtualisering. Holde kontakten.

Nyttige lenker

• Tungsten Fabric Archvitecture.
• about:cloud. 6 timer om Yandex.Cloud, som også dekker det virtuelle nettverket på TF.
• Hva er Open vSwitch?
• Introduksjon til VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Et rammeverk for å overlegge virtualiserte lag 2-nettverk over lag 3-nettverk.
  
• Scaleway-tilnærming til VXLAN EVPN Fabric. Den snakker om hele DC-nettverket, inkludert Underlay, Overlay, tilnærminger til multi-homing og administrasjon.

Takk skal du ha

• Roman Gorga - tidligere vert for linkmeup-podcasten og nå ekspert innen skyplattformer. For kommentarer og redigeringer. Vel, vi venter på hans mer dyptgående artikkel om virtualisering i nær fremtid.
• Alexander Shalimov - min kollega og ekspert innen utvikling av virtuelle nettverk. For kommentarer og redigeringer.
• Valentin Sinitsyn - min kollega og ekspert innen Tungsten Fabric. For kommentarer og redigeringer.
• Artyom Chernobay — illustratør linkmeup. For KDPV.
• Alexander Limonov. For "automato" meme.

Kilde: www.habr.com