В föregående nummer Jag beskrev ramverket för nätverksautomatisering. Enligt vissa människor har även denna första inställning till problemet redan löst vissa frågor. Och detta gör mig väldigt glad, eftersom vårt mål i cykeln inte är att täcka över Ansible med Python-skript, utan att bygga ett system.

Samma ram anger i vilken ordning vi kommer att behandla frågan.
Och nätverksvirtualisering, som det här numret är tillägnat, passar inte särskilt in i ADSM-ämnet, där vi analyserar automatisering.

Men låt oss titta på det från en annan vinkel.

Många tjänster har använt samma nätverk under lång tid. När det gäller en teleoperatör är det till exempel 2G, 3G, LTE, bredband och B2B. I fallet med en DC: anslutning för olika klienter, Internet, blocklagring, objektlagring.

Och alla tjänster kräver isolering från varandra. Så här såg överlagringsnätverk ut.

Och alla tjänster vill inte vänta på att en person ska konfigurera dem manuellt. Så här framstod orkestratorer och SDN.

Det första tillvägagångssättet för systematisk automatisering av nätverket, eller snarare en del av det, har länge tagits och implementerats på många ställen: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Det är vad vi kommer att ta itu med idag.

Innehåll

• Причины
• terminologi
• Underlägg - fysiskt nätverk
• Overlay - virtuellt nätverk
  • Överlägg med ToR
  • Överlagring från värd
  • Med Tungsten Fabric som exempel
    • Kommunikation inom en enda fysisk maskin
    • Kommunikation mellan virtuella datorer placerade på olika fysiska maskiner
    • Utgång till omvärlden

• FAQ
• Slutsats
• Användbara länkar

Причины

Och eftersom vi pratar om detta är det värt att nämna förutsättningarna för nätverksvirtualisering. Faktum är att denna process inte började igår.

Du har säkert hört mer än en gång att nätverket alltid har varit den mest inerta delen av alla system. Och detta är sant i alla avseenden. Nätverket är grunden på vilken allt vilar, och att göra ändringar på det är ganska svårt - tjänster tolererar det inte när nätverket är nere. Ofta kan avveckling av en enda nod ta ner en stor del av applikationerna och påverka många kunder. Det är delvis därför nätverksteamet kan motstå alla förändringar - för nu fungerar det på något sätt (vi kanske inte ens vet hur), men här måste du konfigurera något nytt, och det är okänt hur det kommer att påverka nätverket.

För att inte vänta på att nätverkare ska infoga VLAN och inte registrera några tjänster på varje nätverksnod, kom folk på idén att använda överlagringar - överläggsnätverk - som det finns en stor variation av: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Deras överklagande ligger i två enkla saker:

• Endast ändnoder är konfigurerade – transitnoder behöver inte vidröras. Detta påskyndar processen avsevärt och ibland låter dig helt utesluta nätverksinfrastrukturavdelningen från processen att introducera nya tjänster.
• Belastningen är gömd djupt inne i rubrikerna - transitnoder behöver inte veta något om det, om adressering på värdarna eller om rutter för överlagringsnätverket. Det betyder att du behöver lagra mindre information i tabeller, vilket innebär att du använder en enklare/billigare enhet.

I denna inte helt fullfjädrade fråga planerar jag inte att analysera alla möjliga teknologier, utan snarare beskriva ramverket för driften av överlagringsnätverk i DC.

Hela serien kommer att beskriva ett datacenter som består av rader av identiska rack där samma serverutrustning är installerad.

Denna utrustning kör virtuella maskiner/behållare/serverlösa som implementerar tjänster.

terminologi

I en cykel server Jag kommer att namnge ett program som implementerar serversidan av klient-serverkommunikation.

Fysiska maskiner i rack kallas servrar ingen vi ska.

Fysisk maskin — x86-dator installerad i ett rack. Den mest använda termen värd. Det är vad vi kommer att kalla det "maskin"eller värd.

Hypervisor - en applikation som körs på en fysisk maskin som emulerar de fysiska resurserna som virtuella maskiner körs på. Ibland i litteraturen och på Internet används ordet "hypervisor" som en synonym för "värd".

Virtuell maskin - ett operativsystem som körs på en fysisk maskin ovanpå en hypervisor. För oss i denna cykel spelar det ingen roll om det faktiskt är en virtuell maskin eller bara en behållare. Låt oss kalla det "ВМ«

Hyresgäst är ett brett begrepp som jag kommer att definiera i den här artikeln som en separat tjänst eller en separat klient.

Flerbostadsrätt eller multitenancy - användningen av samma applikation av olika klienter/tjänster. Samtidigt uppnås isolering av klienter från varandra tack vare applikationsarkitekturen, och inte genom separat körande instanser.

ToR — Överst på Rack-omkopplaren - en strömbrytare installerad i ett rack som alla fysiska maskiner är anslutna till.

Förutom ToR-topologin, utövar olika leverantörer End of Row (EoR) eller Middle of Row (även om det senare är en nedsättande sällsynthet och jag har inte sett MoR-förkortningen).

Underläggsnätverk eller det underliggande nätverket eller underlaget är den fysiska nätverksinfrastrukturen: switchar, routrar, kablar.

Överlägg nätverk eller overlay nätverk eller overlay - ett virtuellt nätverk av tunnlar som körs ovanpå den fysiska.

L3-tyg eller IP-tyg - en fantastisk uppfinning av mänskligheten som låter dig undvika att upprepa STP och lära dig TRILL för intervjuer. Ett koncept där hela nätverket upp till accessnivån är uteslutande L3, utan VLAN och följaktligen enorma utökade broadcast-domäner. Vi kommer att undersöka var ordet "fabrik" kommer ifrån i nästa del.

SDN - Mjukvarudefinierat nätverk. Behöver knappast en introduktion. Ett tillvägagångssätt för nätverkshantering där ändringar i nätverket inte görs av en person, utan av ett program. Betyder vanligtvis att man flyttar kontrollplanet bortom slutnätverksenheterna till styrenheten.

NFV — Nätverksfunktionsvirtualisering — virtualisering av nätverksenheter, vilket tyder på att vissa nätverksfunktioner kan köras i form av virtuella maskiner eller behållare för att påskynda implementeringen av nya tjänster, organisera Service Chaining och enklare horisontell skalbarhet.

VNF - Virtuell nätverksfunktion. Specifik virtuell enhet: router, switch, brandvägg, NAT, IPS/IDS, etc.

Jag förenklar nu medvetet beskrivningen till en specifik implementering, för att inte förvirra läsaren för mycket. För mer eftertänksam läsning hänvisar jag honom till avsnittet referenser. Dessutom lovar Roma Gorge, som kritiserar den här artikeln för felaktigheter, att skriva ett separat nummer om server- och nätverksvirtualiseringsteknologier, mer djupgående och uppmärksam på detaljer.

De flesta nätverk idag kan tydligt delas upp i två delar:

Underlag — ett fysiskt nätverk med en stabil konfiguration.
Täcka över — Abstraktion över Underlag för att isolera hyresgäster.

Detta gäller både för DC (som vi kommer att analysera i den här artikeln) och för ISP (som vi inte kommer att analysera, eftersom det redan har varit SDSM). Med företagsnätverk är situationen förstås något annorlunda.

Bild med fokus på nätverket:

Underlag

Underlag är ett fysiskt nätverk: hårdvaruväxlar och kablar. Enheter i tunnelbanan vet hur man når fysiska maskiner.

Den förlitar sig på standardprotokoll och -tekniker. Inte minst för att hårdvaruenheter till denna dag fungerar på proprietär mjukvara som inte tillåter vare sig programmering av chipet eller implementering av sina egna protokoll, därför behövs kompatibilitet med andra leverantörer och standardisering.

Men någon som Google har råd att utveckla sina egna switchar och överge allmänt accepterade protokoll. Men LAN_DC är inte Google.

Underlag ändras relativt sällan eftersom dess uppgift är grundläggande IP-anslutning mellan fysiska maskiner. Underlay vet ingenting om tjänsterna, kunderna eller hyresgästerna som kör ovanpå det - det behöver bara leverera paketet från en maskin till en annan.
Underlag kan vara så här:

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

Underläggsnätverket är konfigurerat på det klassiska sättet: CLI/GUI/NETCONF.

Manuellt, skript, proprietära verktyg.

Nästa artikel i serien kommer att ägnas mer detaljerat åt underlaget.

Täcka över

Overlay är ett virtuellt nätverk av tunnlar som sträcker sig ovanpå Underlay, det gör att virtuella datorer från en klient kan kommunicera med varandra, samtidigt som det isoleras från andra klienter.

Klientdata är inkapslade i vissa tunnlingshuvuden för överföring över det publika nätet.

Så virtuella datorer för en klient (en tjänst) kan kommunicera med varandra genom Overlay, utan att ens veta vilken väg paketet faktiskt tar.

Överlagring kan till exempel vara som jag nämnde ovan:

• GRE-tunneln
• VXLAN
• EVPN
• L3VPN
• GENEVE

Ett överläggsnätverk konfigureras och underhålls vanligtvis via en central styrenhet. Från den levereras konfigurationen, kontrollplanet och dataplanet till enheter som dirigerar och kapslar in klienttrafik. Lite nedan Låt oss titta på detta med exempel.

Ja, det här är SDN i sin renaste form.

Det finns två fundamentalt olika tillvägagångssätt för att organisera ett Overlay-nätverk:

1. Överlägg med ToR
2. Överlagring från värd

Överlägg med ToR

Overlay kan börja vid åtkomstbrytaren (ToR) som står i racket, vilket till exempel händer i fallet med ett VXLAN-tyg.

Detta är en beprövad mekanism på ISP-nätverk och alla leverantörer av nätverksutrustning stödjer den.

Men i det här fallet måste ToR-switchen kunna separera de olika tjänsterna respektive, och nätverksadministratören måste i viss mån samarbeta med administratörerna för virtuella maskiner och göra ändringar (om än automatiskt) i konfigurationen av enheterna .

Här kommer jag att hänvisa läsaren till en artikel om VxLAN på Habré vår gamla vän @bormoglotx.
I denna presentationer med ENOG metoder för att bygga ett DC-nätverk med ett EVPN VXLAN-tyg beskrivs i detalj.

Och för en mer fullständig fördjupning i verkligheten kan du läsa Tsiskas bok Ett modernt, öppet och skalbart tyg: VXLAN EVPN.

Jag noterar att VXLAN endast är en inkapslingsmetod och avslutning av tunnlar kan inte ske på ToR, utan på värden, som till exempel händer i fallet med OpenStack.

VXLAN-tyget, där överlägget börjar vid ToR, är dock en av de etablerade överläggsnätverksdesignerna.

Överlagring från värd

Ett annat tillvägagångssätt är att starta och avsluta tunnlar på ändvärdarna.
I detta fall förblir nätverket (Underlay) så enkelt och statiskt som möjligt.
Och värden själv gör all nödvändig inkapsling.

Detta kommer naturligtvis att kräva att en speciell applikation körs på värdarna, men det är värt det.

För det första är det lättare att köra en klient på en Linux-maskin eller, låt oss säga, till och med möjligt, medan på en switch kommer du troligen att behöva vända dig till proprietära SDN-lösningar, vilket dödar idén om flera leverantörer.

För det andra kan ToR-omkopplaren i detta fall lämnas så enkel som möjligt, både ur kontrollplanets och dataplanets synvinkel. I själva verket behöver den inte kommunicera med SDN-styrenheten, och den behöver inte heller lagra nätverken/ARP:erna för alla anslutna klienter - det räcker att känna till IP-adressen för den fysiska maskinen, vilket avsevärt förenklar bytet/ rutttabeller.

I ADSM-serien väljer jag överlagringsmetoden från värden - då pratar vi bara om det och vi kommer inte tillbaka till VXLAN-fabriken.

Det är lättast att titta på exempel. Och som testperson kommer vi att ta OpenSource SDN-plattformen OpenContrail, nu känd som Tungsten tyg.

I slutet av artikeln kommer jag att ge några tankar om analogin med OpenFlow och OpenvSwitch.

Med Tungsten Fabric som exempel

Varje fysisk maskin har vRouter - en virtuell router som känner till de nätverk som är anslutna till den och vilka klienter de tillhör - i huvudsak en PE-router. För varje klient upprätthåller den en isolerad routingtabell (läs VRF). Och vRouter utför faktiskt Overlay-tunneling.

Lite mer om vRouter finns i slutet av artikeln.

Varje virtuell dator som finns på hypervisorn är ansluten till den här maskinens vRouter via TAP-gränssnitt.

KLAPP - Terminal Access Point - ett virtuellt gränssnitt i Linux-kärnan som tillåter nätverksinteraktion.

Om det finns flera nätverk bakom vRouter, skapas ett virtuellt gränssnitt för var och en av dem, till vilken en IP-adress tilldelas - det kommer att vara standardgateway-adressen.
Alla nätverk för en klient är placerade i ett VRF-förlängning (ett bord), olika - till olika.
Jag ska göra en friskrivning här att allt inte är så enkelt, och jag skickar den nyfikna läsaren till slutet av artikeln.

Så att vRouters kan kommunicera med varandra, och följaktligen de virtuella datorerna bakom dem, utbyter de routinginformation via SDN-kontroller.

För att komma ut i omvärlden finns det en utgångspunkt från matrisen – en virtuell nätverksport VNGW - Virtual Network GateWay (min mandatperiod).

Låt oss nu titta på exempel på kommunikation - och det kommer att bli klarhet.

Kommunikation inom en enda fysisk maskin

VM0 vill skicka ett paket till VM2. Låt oss för närvarande anta att detta är en virtuell dator med en enda klient.

Dataplan

1. VM-0 har en standardväg till sitt eth0-gränssnitt. Paketet skickas dit.
   Detta gränssnitt eth0 är faktiskt anslutet virtuellt till den virtuella routern vRouter genom TAP-gränssnittet tap0.
2. vRouter analyserar vilket gränssnitt paketet kom till, det vill säga vilken klient (VRF) det tillhör, och kontrollerar mottagarens adress med routingtabellen för denna klient.
3. Efter att ha upptäckt att mottagaren på samma maskin är på en annan port, skickar vRouter helt enkelt paketet till den utan några ytterligare rubriker - i det här fallet har vRouter redan en ARP-post.

I det här fallet kommer paketet inte in i det fysiska nätverket - det dirigeras inuti vRouter.

Kontrollplan

När den virtuella maskinen startar säger hypervisorn till det:

• Hennes egen IP-adress.
• Standardrutten är via vRouterns IP-adress på detta nätverk.

Hypervisorn rapporterar till vRouter genom ett speciellt API:

• Vad du behöver för att skapa ett virtuellt gränssnitt.
• Vilken typ av virtuellt nätverk behöver den (VM) skapa?
• Vilken VRF (VN) den ska bindas till.
• En statisk ARP-post för denna virtuella dator - vilket gränssnitt som ligger bakom dess IP-adress och vilken MAC-adress det är associerat med.

Återigen är själva interaktionsproceduren förenklad för att förstå konceptet.

Således ser vRouter alla virtuella datorer för en klient på en given maskin som direktanslutna nätverk och kan själv dirigera mellan dem.

Men VM0 och VM1 tillhör olika klienter och är följaktligen i olika vRouter-tabeller.

Huruvida de kan kommunicera med varandra direkt beror på vRouter-inställningarna och nätverksdesignen.
Till exempel, om båda klienternas virtuella datorer använder allmänna adresser, eller NAT inträffar på själva vRoutern, kan direkt routning till vRouter göras.

I den motsatta situationen är det möjligt att korsa adressutrymmen - du måste gå igenom en NAT-server för att få en offentlig adress - detta liknar att komma åt externa nätverk, som diskuteras nedan.

Kommunikation mellan virtuella datorer placerade på olika fysiska maskiner

Dataplan

1. Början är exakt densamma: VM-0 skickar ett paket med destination VM-7 (172.17.3.2) som standard.
2. vRouter tar emot det och ser denna gång att destinationen är på en annan dator och är tillgänglig via Tunnel0.
3. Först hänger den en MPLS-etikett som identifierar fjärrgränssnittet, så att vRouter på baksidan kan bestämma var detta paket ska placeras utan ytterligare uppslag.

   

4. Tunnel0 har källa 10.0.0.2, destination: 10.0.1.2.
   vRouter lägger till GRE (eller UDP)-rubriker och en ny IP till originalpaketet.
5. Routningstabellen vRouter har en standardrutt genom ToR1-adressen 10.0.0.1. Det är dit han skickar det.

   
   

6. ToR1, som medlem i Underlay-nätverket, vet (till exempel via OSPF) hur man tar sig till 10.0.1.2 och skickar paketet längs rutten. Observera att ECMP är aktiverat här. Det finns två nexthops i illustrationen, och olika trådar kommer att sorteras i dem med hash. I fallet med en riktig fabrik kommer det att finnas mer sannolikt 4 nexthops.

   Samtidigt behöver han inte veta vad som finns under den externa IP-huvudet. Det vill säga, i själva verket under IP kan det finnas en sandwich av IPv6 över MPLS över Ethernet över MPLS över GRE över över grekiska.

7. Följaktligen, på den mottagande sidan, tar vRouter bort GRE och, med hjälp av MPLS-taggen, förstår vilket gränssnitt detta paket ska skickas till, strippar det och skickar det i sin ursprungliga form till mottagaren.

Kontrollplan

När du startar bilen händer samma sak som beskrivs ovan.

Och plus följande:

• För varje klient tilldelar vRouter en MPLS-tagg. Detta är L3VPN-tjänsteetiketten, genom vilken klienter kommer att separeras inom samma fysiska dator.
  

  Faktum är att MPLS-taggen alltid allokeras ovillkorligt av vRouter - trots allt är det inte känt på förhand att maskinen bara kommer att interagera med andra maskiner bakom samma vRouter och detta är med största sannolikhet inte ens sant.

• vRouter upprättar en anslutning med SDN-styrenheten med hjälp av BGP-protokollet (eller liknande det - i fallet med TF är detta XMPP 0_o).
• Genom denna session rapporterar vRouter rutter till anslutna nätverk till SDN-styrenheten:
  • Nätverksadress
  • Inkapslingsmetod (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS klienttagg
  • Din IP-adress som nexthop

• SDN-styrenheten tar emot sådana rutter från alla anslutna vRouters och reflekterar dem till andra. Det vill säga, den fungerar som en vägreflektor.

Samma sak händer i motsatt riktning.

Överlagring kan ändras minst varje minut. Detta är ungefär vad som händer i offentliga moln, där klienter regelbundet startar och stänger av sina virtuella maskiner.

Den centrala styrenheten tar hand om all komplexitet med att underhålla konfigurationen och övervaka switching/routing-tabellerna på vRouter.

Grovt sett kommunicerar styrenheten med alla vRouters via BGP (eller liknande protokoll) och överför helt enkelt routinginformation. BGP har till exempel redan Address-Family för att förmedla inkapslingsmetoden MPLS-i-GRE eller MPLS-i-UDP.

Samtidigt ändras inte konfigurationen av Underlay-nätverket på något sätt, vilket förresten är mycket svårare att automatisera och lättare att bryta med en besvärlig rörelse.

Utgång till omvärlden

Någonstans måste simuleringen sluta och du måste lämna den virtuella världen till den verkliga. Och du behöver en telefonautomat.

Två tillvägagångssätt tillämpas:

1. En hårdvarurouter är installerad.
2. En apparat lanseras som implementerar funktionerna hos en router (ja, efter SDN stötte vi också på VNF). Låt oss kalla det en virtuell gateway.

Fördelen med det andra tillvägagångssättet är billig horisontell skalbarhet - det finns inte tillräckligt med kraft - vi lanserade en annan virtuell maskin med en gateway. På vilken fysisk maskin som helst, utan att behöva leta efter gratis rack, enheter, effektuttag, köpa själva hårdvaran, transportera den, installera den, byta den, konfigurera den och sedan även ändra felaktiga komponenter i den.

Nackdelarna med en virtuell gateway är att en enhet av en fysisk router fortfarande är storleksordningar mer kraftfull än en multi-core virtuell maskin, och dess mjukvara, skräddarsydd för sin egen hårdvarubas, fungerar mycket mer stabil (ingen). Det är också svårt att förneka det faktum att hårdvaru- och mjukvarukomplexet helt enkelt fungerar, kräver bara konfiguration, samtidigt som att starta och underhålla en virtuell gateway är en uppgift för starka ingenjörer.

Med en fot ser gatewayen in i det virtuella Overlay-nätverket, som en vanlig virtuell maskin, och kan interagera med alla andra virtuella datorer. Samtidigt kan den avsluta alla klienters nätverk och följaktligen utföra routing mellan dem.

Med sin andra fot tittar gatewayen in i stamnätet och vet hur man kommer in på Internet.

Dataplan

Det vill säga, processen ser ut så här:

1. VM-0, som har förinställt samma vRouter, skickar ett paket med en destination i omvärlden (185.147.83.177) till eth0-gränssnittet.
2. vRouter tar emot detta paket och letar upp destinationsadressen i routingtabellen - hittar standardrutten genom VNGW1-gatewayen genom Tunnel 1.
   Han ser också att detta är en GRE-tunnel med SIP 10.0.0.2 och DIP 10.0.255.2, och han måste också först fästa MPLS-etiketten för denna klient, vilket VNGW1 förväntar sig.
3. vRouter packar det initiala paketet med MPLS, GRE och nya IP-huvuden och skickar det till ToR1 10.0.0.1 som standard.
4. Det underliggande nätverket levererar paketet till gatewayen VNGW1.
5. VNGW1-gatewayen tar bort GRE- och MPLS-tunnlingshuvudena, ser destinationsadressen, konsulterar dess routingtabell och förstår att den är riktad till Internet - det vill säga genom Full View eller Default. Utför NAT-översättning vid behov.
6. Det kan finnas ett vanligt IP-nätverk från VNGW till gränsen, vilket är osannolikt.
   Det kan finnas ett klassiskt MPLS-nätverk (IGP+LDP/RSVP TE), det kan finnas en backväv med BGP LU eller en GRE-tunnel från VNGW till gränsen via ett IP-nätverk.
   Hur som helst, VNGW1 utför de nödvändiga inkapslingarna och skickar det initiala paketet mot gränsen.

Trafiken i motsatt riktning går igenom samma steg i motsatt ordning.

1. Gränsen släpper paketet till VNGW1
2. Han klär av honom, tittar på mottagarens adress och ser att han är tillgänglig genom Tunnel1-tunneln (MPLSoGRE eller MPLSoUDP).
3. Följaktligen fäster den en MPLS-etikett, en GRE/UDP-header och en ny IP och skickar den till sin ToR3 10.0.255.1.
   Tunneldestinationsadressen är IP-adressen för vRoutern bakom vilken mål-VM finns - 10.0.0.2.
4. Det underliggande nätverket levererar paketet till önskad vRouter.
5. Mål-vRoutern läser GRE/UDP, bestämmer gränssnittet med MPLS-etiketten och skickar ett blott IP-paket till dess TAP-gränssnitt som är associerat med eth0 för den virtuella datorn.

Kontrollplan

VNGW1 upprättar ett BGP-område med en SDN-kontroller, från vilken den tar emot all routinginformation om klienter: vilken IP-adress (vRouter) som ligger bakom vilken klient, och vilken MPLS-etikett den identifieras av.

På samma sätt informerar han själv SDN-kontrollern om standardrutten med etiketten för denna klient, och indikerar sig själv som nexthop. Och sedan kommer denna standard till vRouters.

På VNGW sker vanligtvis ruttaggregation eller NAT-översättning.

Och åt andra hållet skickar den exakt denna aggregerade rutt till sessionen med gränser eller Route Reflectors. Och från dem får den standardrutten eller Full-View, eller något annat.

När det gäller inkapsling och trafikutbyte skiljer sig VNGW inte från vRouter.
Om du utökar omfattningen lite kan du lägga till andra nätverksenheter till VNGW:er och vRouters, såsom brandväggar, trafikrensning eller anrikningsfarmar, IPS och så vidare.

Och med hjälp av sekventiellt skapande av VRF:er och korrekt annonsering av rutter kan du tvinga trafik att loopa på det sätt du vill, vilket kallas Service Chaining.

Det vill säga, även här fungerar SDN-styrenheten som en ruttreflektor mellan VNGW:er, vRouters och andra nätverksenheter.

Men i själva verket släpper styrenheten också information om ACL och PBR (Policy Based Routing), vilket gör att enskilda trafikflöden går annorlunda än rutten säger åt dem att göra.

FAQ

Varför gör du alltid GRE/UDP-anmärkningen?

Tja, i allmänhet kan detta sägas vara specifikt för Tungsten Fabric - du behöver inte ta hänsyn till det alls.

Men om vi tar det, så stödde TF själv, medan fortfarande OpenContrail, båda inkapslingarna: MPLS i GRE och MPLS i UDP.

UDP är bra eftersom det i källporten är väldigt enkelt att koda en hashfunktion från den ursprungliga IP+Proto+Porten i dess header, vilket gör att du kan balansera.

När det gäller GRE, tyvärr, så finns det bara externa IP- och GRE-headers, som är lika för all inkapslad trafik och det är inget snack om balansering – få människor kan titta så djupt inne i paketet.

Fram till en tid gjorde routrar, om de visste hur man använder dynamiska tunnlar, det bara i MPLSoGRE, och först mycket nyligen lärde de sig att använda MPLSoUDP. Därför måste vi alltid göra en anteckning om möjligheten till två olika inkapslingar.

I rättvisans namn är det värt att notera att TF fullt ut stöder L2-anslutning med VXLAN.

Du lovade att dra paralleller med OpenFlow.
De efterfrågar verkligen det. vSwitch i samma OpenStack gör mycket liknande saker, med hjälp av VXLAN, som för övrigt också har en UDP-header.

I dataplanet fungerar de ungefär likadant, kontrollplanet skiljer sig markant. Tungsten Fabric använder XMPP för att leverera routinginformation till vRouter, medan OpenStack kör Openflow.

Kan du berätta lite mer om vRouter?
Den är uppdelad i två delar: vRouter Agent och vRouter Forwarder.

Den första körs i värdoperativsystemets användarutrymme och kommunicerar med SDN-styrenheten och utbyter information om rutter, VRF:er och ACL:er.

Den andra implementerar Data Plane - vanligtvis i Kernel Space, men kan också köras på SmartNICs - nätverkskort med en CPU och ett separat programmerbart switch-chip, vilket gör att du kan ta bort belastningen från värdmaskinens CPU, och göra nätverket snabbare och mer förutsägbar.

Ett annat möjligt scenario är att vRouter är en DPDK-applikation i User Space.

vRouter Agent skickar inställningar till vRouter Forwarder.

Vad är ett virtuellt nätverk?
Jag nämnde i början av artikeln om VRF att varje hyresgäst är bunden till sin egen VRF. Och om detta var tillräckligt för en ytlig förståelse av driften av överlagringsnätverket, är det vid nästa iteration nödvändigt att göra förtydliganden.

Vanligtvis, i virtualiseringsmekanismer, introduceras Virtual Network-entiteten (du kan betrakta detta som ett egennamn) separat från klienter/hyresgäster/virtuella maskiner - en helt oberoende sak. Och detta virtuella nätverk kan redan anslutas via gränssnitt till en hyresgäst, till en annan, till två eller var som helst. Så till exempel implementeras Service Chaining när trafik behöver passeras genom vissa noder i önskad sekvens, helt enkelt genom att skapa och ansluta virtuella nätverk i rätt sekvens.

Därför finns det som sådan ingen direkt korrespondens mellan det virtuella nätverket och hyresgästen.

Slutsats

Detta är en mycket ytlig beskrivning av driften av ett virtuellt nätverk med en överlagring från värden och en SDN-kontroller. Men oavsett vilken virtualiseringsplattform du väljer idag kommer den att fungera på liknande sätt, vare sig det är VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric eller Juniper Contrail. De kommer att skilja sig åt i typer av inkapslingar och rubriker, protokoll för att leverera information till slutnätverksenheter, men principen för ett mjukvarukonfigurerbart överlagringsnätverk som fungerar ovanpå ett relativt enkelt och statiskt underläggsnätverk kommer att förbli densamma.
Vi kan säga att idag har SDN baserat på ett överläggsnätverk vunnit området för att skapa ett privat moln. Detta betyder dock inte att Openflow inte har någon plats i den moderna världen – det används i OpenStacke och i samma VMWare NSX, så vitt jag vet använder Google det för att sätta upp det underjordiska nätverket.

Nedan har jag lämnat länkar till mer detaljerat material om du vill studera frågan djupare.

Och hur är det med vårt underlägg?

Men i allmänhet ingenting. Han ändrade sig inte hela vägen. Allt han behöver göra i fallet med en överlagring från värden är att uppdatera rutter och ARP när vRouter/VNGW dyker upp och försvinner och bär paket mellan dem.

Låt oss formulera en lista med krav för underlagsnätverket.

1. Kunna använda något slags routingprotokoll, i vår situation - BGP.
2. Ha en bred bandbredd, gärna utan överabonnemang, så att paket inte går förlorade på grund av överbelastning.
3. Att stödja ECMP är en integrerad del av tyget.
4. Kunna tillhandahålla QoS, inklusive knepiga saker som ECN.
5. Att stödja NETCONF är en grund för framtiden.

Jag ägnade väldigt lite tid här åt arbetet med själva Underlay-nätverket. Detta beror på att jag senare i serien kommer att fokusera på det, och vi kommer bara att beröra Overlay i förbigående.

Uppenbarligen begränsar jag oss alla kraftigt genom att som exempel använda ett DC-nätverk byggt i en Cloz-fabrik med ren IP-routing och en överlagring från värden.

Jag är dock säker på att alla nätverk som har en design kan beskrivas i formella termer och automatiseras. Det är bara det att mitt mål här är att förstå metoder för automatisering och att inte förvirra alla genom att lösa problemet i en allmän form.

Som en del av ADSM planerar Roman Gorge och jag att publicera ett separat nummer om virtualisering av datorkraft och dess interaktion med nätverksvirtualisering. Hålla kontakten.

Användbara länkar

• Tungsten Fabric Archvitecture.
• about:cloud. 6 timmar om Yandex.Cloud, som även täcker det virtuella nätverket på TF.
• Vad är Open vSwitch?
• Introduktion till VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Ett ramverk för överlagring av virtualiserade lager 2-nätverk över lager 3-nätverk.
  
• Scaleway tillvägagångssätt till VXLAN EVPN Fabric. Den talar om hela DC-nätverket, inklusive Underlay, Overlay, tillvägagångssätt för multi-homing och hantering.

Tack

• Roman Gorga - tidigare värd för linkmeup-podden och nu en expert inom området molnplattformar. För kommentarer och redigeringar. Tja, vi väntar på hans mer djupgående artikel om virtualisering inom en snar framtid.
• Alexander Shalimov - min kollega och expert inom området virtuell nätverksutveckling. För kommentarer och redigeringar.
• Valentin Sinitsyn - min kollega och expert inom området Tungsten Fabric. För kommentarer och redigeringar.
• Artyom Chernobay — illustratör linkmeup. För KDPV.
• Alexander Limonov. För "automato" meme.

Källa: will.com