В Ech beschriwwen den Netzautomatiséierungs Kader. Laut e puer Leit, och dës éischt Approche fir de Problem huet schonn e puer Froen zortéiert. An dat mécht mech ganz frou, well eist Zil am Zyklus ass net d'Ansible mat Python Scripten ofzedecken, mee e System ze bauen.
Dee selwechte Kader setzt d'Uerdnung an an där mir d'Fro behandelen.
An d'Netzvirtualiséierung, déi dëst Thema gewidmet ass, passt net besonnesch an d'ADSM Thema, wou mir d'Automatisatioun analyséieren.
Mä loosst eis et aus engem anere Wénkel kucken.
Vill Servicer hunn datselwecht Netzwierk fir eng laang Zäit benotzt. Am Fall vun engem Telekomoperateur ass dat zum Beispill 2G, 3G, LTE, Breetband a B2B. Am Fall vun engem DC: Konnektivitéit fir verschidde Clienten, Internet, Blocklagerung, Objektlagerung.
An all Servicer erfuerderen Isolatioun vuneneen. Dëst ass wéi Overlay Netzwierker erschéngen.
An all Servicer wëllen net op eng Persoun waarden fir se manuell ze konfiguréieren. Dëst ass wéi Orchestrateuren an SDN erschéngen.
Déi éischt Approche fir systematesch Automatisatioun vum Netz, oder éischter en Deel dovun, gouf laang op ville Plazen geholl an ëmgesat: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Dat ass wat mir haut beschäftegen.
Inhalt
- Grënn
- Terminologie
- Ënnerlag - kierperlecht Netzwierk
- Iwwerlagerung - virtuellt Netzwierk
- Iwwerlagerung mat ToR
- Iwwerlagerung vum Host
- Benotzt Wolfram Stoff als Beispill
- Kommunikatioun bannent enger eenzeger kierperlecher Maschinn
- Kommunikatioun tëscht VMs op verschiddene kierperleche Maschinnen
- Sortie op d'Äussewelt
- FAQ
- Konklusioun
- Nëtzlech Adressen
Grënn
A well mir iwwer dëst schwätzen, ass et derwäert d'Viraussetzunge fir d'Netzvirtualiséierung ze ernimmen. Tatsächlech huet dëse Prozess net gëschter ugefaang.
Dir hutt wahrscheinlech méi wéi eemol héieren datt d'Netzwierk ëmmer den inertsten Deel vun all System war. An dat stëmmt an all Sënn. D'Netz ass d'Basis op där alles riicht, an et ass zimmlech schwéier Ännerungen ze maachen - Servicer toleréieren et net wann de Reseau erof ass. Dacks kann d'Entféierung vun engem eenzegen Node e groussen Deel vun Uwendungen erofhuelen a vill Clienten beaflossen. Dëst ass deelweis firwat d'Netzwierkteam all Ännerung widderstoen kann - well elo funktionnéiert et iergendwéi (mir wësse vläicht net emol wéi), awer hei musst Dir eppes Neies konfiguréieren, an et ass onbekannt wéi et d'Netzwierk beaflosst.
Fir net op d'Netzwierker ze waarden fir VLANs anzeginn an keng Servicer op all Netzknuet ze registréieren, sinn d'Leit op d'Iddi komm fir Overlays ze benotzen - Overlay Netzwierker - vun deenen et eng grouss Varietéit gëtt: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.
Hir Appel läit an zwee einfache Saachen:
- Nëmmen Enn Wirbelen sinn konfiguréiert-Transit Wirbelen brauchen net beréiert ginn. Dëst beschleunegt de Prozess wesentlech, an heiansdo erlaabt Iech d'Netzinfrastruktur Departement komplett aus dem Prozess vun der Aféierung vun neie Servicer auszeschléissen.
- D'Laascht ass déif an den Header verstoppt - Transitknoten brauchen näischt doriwwer ze wëssen, iwwer d'Adress op de Hosten oder iwwer d'Strecken vum Overlay-Netzwierk. Dëst bedeit datt Dir manner Informatioun an Dëscher späichere musst, dat heescht datt Dir e méi einfachen / méi bëllegen Apparat benotzt.
An dësem net ganz vollwäertege Problem plangen ech net all méiglech Technologien ze analyséieren, mä éischter de Kader fir d'Operatioun vun Overlay Netzwierker an DCs beschreiwen.
Déi ganz Serie wäert en Datenzenter beschreiwen, deen aus Reihen vun identesche Racken besteet, an deenen déiselwecht Serverausrüstung installéiert ass.
Dës Ausrüstung leeft virtuell Maschinnen / Container / Serverlos déi Servicer implementéieren.
Terminologie
An enger Loop Server Ech wäert e Programm nennen deen d'Serversäit vun der Client-Server Kommunikatioun implementéiert.
Kierperlech Maschinnen an Racken sinn Serveren genannt Net mir wäerten.
Kierperlech Maschinn - x86 Computer an engem Rack installéiert. Am meeschte benotzt Begrëff Provider. Dat ass wat mir et nennen "машина"oder Provider.
Hypervisor - eng Applikatioun déi op enger physescher Maschinn leeft déi kierperlech Ressourcen emuléiert op deenen virtuelle Maschinnen lafen. Heiansdo gëtt an der Literatur an am Internet d'Wuert "Hypervisor" als Synonym fir "Host" benotzt.
Virtuell Maschinn - e Betribssystem deen op enger kierperlecher Maschinn uewen op engem Hypervisor leeft. Fir eis an dësem Zyklus ass et net wierklech egal ob et tatsächlech eng virtuell Maschinn ass oder just e Container. Loosst eis et nennen "VM«
Locataire ass e breet Konzept dat ech an dësem Artikel als separat Service oder separat Client definéieren.
Multi-Locatioun oder Multitenancy - d'Benotzung vun der selwechter Applikatioun vu verschiddene Clienten / Servicer. Zur selwechter Zäit gëtt d'Isolatioun vu Cliente vuneneen erreecht duerch d'Applikatiounsarchitektur, an net duerch separat Lafen Instanzen.
ToR - Top of the Rack Switch - e Schalter, deen an engem Rack installéiert ass, mat deem all kierperlech Maschinnen verbonne sinn.
Zousätzlech zu der ToR-Topologie, üben verschidde Fournisseuren End of Row (EoR) oder Middle of Row (obwuel déi lescht eng disparaging Raritéit ass an ech hunn d'MoR Ofkierzung net gesinn).
Ënnerlag Netzwierk oder dat Basisdaten Netzwierk oder Ënnerlag ass déi kierperlech Netzwierkinfrastruktur: Schalter, Router, Kabelen.
Overlay Reseau oder Iwwerlagerungsnetz oder Iwwerlagerung - e virtuellt Netzwierk vun Tunnelen déi uewen op der kierperlecher lafen.
L3 Stoff oder IP Stoff - eng erstaunlech Erfindung vun der Mënschheet déi Iech erlaabt STP ze vermeiden an TRILL fir Interviewen ze léieren. E Konzept an deem de ganzen Netz bis zum Zougangsniveau exklusiv L3 ass, ouni VLANs an deementspriechend enorm erweidert Broadcast Domains. Mir kucken wou d'Wuert "Fabréck" hierkënnt am nächsten Deel.
SDN - Software definéiert Netzwierk. Et brauch kaum eng Aféierung. Eng Approche fir d'Netzwierkverwaltung wou Ännerungen am Netz net vun enger Persoun gemaach ginn, mee vun engem Programm. Normalerweis heescht d'Kontrollplane iwwer d'Ennnetzgeräter op de Controller bewegen.
NFV - Network Function Virtualization - Virtualiséierung vun Netzgeräter, suggeréiert datt e puer Netzwierkfunktiounen a Form vu virtuelle Maschinnen oder Container kënne lafen fir d'Ëmsetzung vun neie Servicer ze beschleunegen, Service Chaining a méi einfacher horizontaler Skalierbarkeet ze organiséieren.
VNF - Virtuell Netzwierk Funktioun. Spezifesch virtuell Apparat: Router, Schalter, Firewall, NAT, IPS / IDS, etc.
Ech vereinfachen elo bewosst d'Beschreiwung op eng spezifesch Ëmsetzung, fir de Lieser net zevill duercherneen ze bréngen. Fir méi nodenklech Liesen, verweisen ech hien op d'Sektioun . Ausserdeem versprécht Roma Gorge, deen dësen Artikel fir Ongenauegkeeten kritiséiert, eng separat Ausgab iwwer Server- an Netzwierkvirtualiséierungstechnologien ze schreiwen, méi am-Déift an opmierksam op Detailer.
Déi meescht Netzwierker haut kënne kloer an zwee Deeler opgedeelt ginn:
Ënnerlag - e kierperlecht Netzwierk mat enger stabiler Konfiguratioun.
Overlay - Abstraktioun iwwer Underlay fir Locataire ze isoléieren.
Dëst ass wouer souwuel fir de Fall vun DC (déi mir an dësem Artikel analyséieren) a fir ISP (déi mir net analyséieren, well et scho war ). Mat Enterprise Netzwierker ass d'Situatioun natierlech e bëssen anescht.
Bild mat Fokus am Netz:
Ënnerlag
Underlay ass e kierperlecht Netzwierk: Hardwareschalter a Kabelen. Apparater am Ënnergrond wëssen wéi kierperlech Maschinnen ze erreechen.
Et hänkt op Standardprotokollen an Technologien of. Net zulescht well Hardware Geräter bis haut op propriétaire Software funktionnéieren déi et net erlaabt den Chip ze programméieren oder seng eege Protokoller ëmzesetzen; deementspriechend sinn Kompatibilitéit mat anere Verkeefer a Standardiséierung gebraucht.
Awer een wéi Google ka sech leeschten hir eege Schalter z'entwéckelen an allgemeng akzeptéiert Protokoller opzeginn. Awer LAN_DC ass net Google.
Ënnerlag ännert sech relativ selten well seng Aarbecht Basis IP Konnektivitéit tëscht kierperleche Maschinnen ass. Underlay weess näischt iwwer d'Servicer, Clienten oder Locataire déi drop lafen - et brauch nëmmen de Package vun enger Maschinn op déi aner ze liwweren.
Ënnerlag kéint esou sinn:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Den Underlay Netzwierk ass op déi klassesch Manéier konfiguréiert: CLI/GUI/NETCONF.
Manuell, Scripten, propriétaire Utilities.
Den nächsten Artikel an der Serie wäert méi detailléiert dem Ënnerlag gewidmet ginn.
Overlay
Overlay ass e virtuellt Netzwierk vun Tunnelen, déi uewen um Underlay gestreckt sinn, et erlaabt VMs vun engem Client mateneen ze kommunizéieren, wärend Isolatioun vun anere Clienten ubitt.
D'Clientdaten sinn an e puer Tunneling Header verschlësselt fir d'Transmissioun iwwer den ëffentlechen Netzwierk.
Also VMs vun engem Client (e Service) kënne matenee kommunizéieren duerch Overlay, ouni iwwerhaapt ze wëssen wéi ee Wee de Paket tatsächlech hëlt.
Overlay kéint zum Beispill sinn wéi ech hei uewen erwähnt hunn:
- GRE Tunnel
- VXLAN
- EVPN
- L3VPN
- GENEVE
En Iwwerlagernetz gëtt typesch duerch en zentrale Controller konfiguréiert an ënnerhal. Vun et gëtt d'Konfiguratioun, d'Kontrollplane an d'Dateplane op Apparater geliwwert, déi de Client Traffic route an kapselen. E bëssen Loosst eis dëst mat Beispiller kucken.
Jo, dëst ass SDN a senger purster Form.
Et ginn zwou grondsätzlech ënnerschiddlech Approche fir en Overlay Netzwierk z'organiséieren:
- Iwwerlagerung mat ToR
- Iwwerlagerung vum Host
Iwwerlagerung mat ToR
Iwwerlagerung kann um Zougang schalt ugefaangen (ToR) am Zännstaang stoung, wéi geschitt, zum Beispill, am Fall vun engem VXLAN Stoff.
Dëst ass en Zäit-getest Mechanismus op ISP Netzwierker an all Netzwierkausrüstungsverkeefer ënnerstëtzen et.
Allerdéngs muss an dësem Fall den ToR-Schalter fäeg sinn déi verschidde Servicer ze trennen, respektiv, an den Netzadministrator muss zu engem gewëssen Mooss mat de virtuelle Maschinnen Administrateuren kooperéieren an Ännerungen (och wann automatesch) un der Konfiguratioun vun den Apparater maachen .
Hei wäert ech de Lieser op en Artikel iwwer eisen ale Frënd .
An dësem Approche fir en DC Netz mat engem EVPN VXLAN Stoff ze bauen ginn am Detail beschriwwen.
A fir eng méi komplett Tauche an der Realitéit kënnt Dir dem Tsiska säi Buch liesen .
Ech bemierken datt VXLAN nëmmen eng Enkapsulatiounsmethod ass an d'Ennung vun Tunnelen kann net op ToR geschéien, mee um Host, wéi zum Beispill am Fall vun OpenStack geschitt.
Wéi och ëmmer, VXLAN Stoff, wou d'Iwwerlagerung bei ToR ufänkt, ass ee vun den etabléierten Overlay Netzwierkdesignen.
Iwwerlagerung vum Host
Eng aner Approche ass Tunnel op den Ennhosten unzefänken an ofzeschléissen.
An dësem Fall bleift de Reseau (Underlay) esou einfach a statesch wéi méiglech.
An de Host selwer mécht all déi néideg Encapsulatioun.
Dëst erfuerdert selbstverständlech eng speziell Applikatioun op de Hosten ze lafen, awer et ass et wäert.
Als éischt, e Client op enger Linux Maschinn ze lafen ass méi einfach oder, loosst eis soen, souguer méiglech, wärend op engem Schalter musst Dir héchstwahrscheinlech op propriétaire SDN-Léisungen wenden, wat d'Iddi vu Multi-Verkeefer ëmbréngt.
Zweetens kann de ToR-Schalter an dësem Fall sou einfach wéi méiglech gelooss ginn, souwuel aus der Siicht vum Kontrollplane wéi och vum Dataplane. Tatsächlech brauch et net mat dem SDN Controller ze kommunizéieren, an et brauch och net d'Netzwierker / ARPs vun all verbonne Clienten ze späicheren - et ass genuch fir d'IP Adress vun der kierperlecher Maschinn ze kennen, wat de Wiessel staark vereinfacht / Routing Dëscher.
An der ADSM-Serie wielen ech d'Overlay-Approche vum Host - da schwätze mir nëmmen doriwwer a mir ginn net zréck an d'VXLAN-Fabréck.
Et ass am einfachsten Beispiller ze kucken. An als Test Thema wäerte mir d'OpenSource SDN Plattform OpenContrail huelen, elo bekannt als .
Um Enn vum Artikel ginn ech e puer Gedanken iwwer d'Analogie mat OpenFlow an OpenvSwitch.
Benotzt Wolfram Stoff als Beispill
All kierperlech Maschinn huet vRouter - e virtuelle Router dee weess iwwer d'Netzwierker déi domat verbonne sinn a wéi eng Clientë si gehéieren - am Wesentlechen e PE Router. Fir all Client hält et eng isoléiert Routing-Tabelle (liesen VRF). A vRouter mécht tatsächlech Overlay Tunneling.
E bësse méi iwwer vRouter ass um Enn vum Artikel.
All VM, deen um Hypervisor läit, ass mat dem vRouter vun dëser Maschinn via .
TAP - Terminal Access Point - eng virtuell Interface am Linux Kernel deen Netzwierkinteraktioun erlaabt.
Wann et e puer Netzwierker hannert dem vRouter sinn, gëtt eng virtuell Interface fir jidderee vun hinnen erstallt, un déi eng IP Adress zougewisen ass - et ass d'Standard Gateway Adress.
All Netzwierker vun engem Client sinn an engem gesat VRF (een Dësch), verschidden - an verschidden.
Ech maachen hei en Verzichterklärung datt net alles sou einfach ass, an ech schécken de virwëtzeg Lieser um Enn vum Artikel.
Fir vRouters mateneen ze kommunizéieren, an deementspriechend d'VMs hannert hinnen, tauschen se Routinginformatioun iwwer SDN Controller.
Fir an d'Äussewelt erauszekommen, gëtt et en Ausgangspunkt vun der Matrix - e virtuelle Netzwierkpaart VNGW - Virtuell Netzwierk GateWay (meng Begrëff).
Loosst eis elo Beispiller vu Kommunikatioun kucken - an et gëtt Kloerheet.
Kommunikatioun bannent enger eenzeger kierperlecher Maschinn
VM0 wëll e Paket op VM2 schécken. Loosst eis elo unhuelen datt dëst en eenzege Client VM ass.
Daten Fliger
- VM-0 huet e Standardroute op seng eth0 Interface. De Pak gëtt dohinner geschéckt.
Dësen Interface eth0 ass tatsächlech virtuell mam virtuelle Router vRouter duerch den TAP Interface tap0 verbonnen. - vRouter analyséiert op wéi eng Interface de Paket koum, dat heescht, wéi engem Client (VRF) et gehéiert, a kontrolléiert d'Adress vum Empfänger mat der Routingtabelle vun dësem Client.
- Nodeems Dir festgestallt hutt datt den Empfänger op der selwechter Maschinn op engem aneren Hafen ass, schéckt vRouter de Paket einfach ouni zousätzlech Header - fir dëse Fall huet vRouter schonn eng ARP Entrée.
An dësem Fall geet de Paket net an de kierperlecht Netzwierk - et gëtt am vRouter geréckelt.
Kontroll Fliger
Wann déi virtuell Maschinn ufänkt, seet den Hypervisor et:
- Hir eege IP Adress.
- De Standardroute ass duerch d'IP Adress vum vRouter op dësem Netzwierk.
Den Hypervisor mellt dem vRouter duerch eng speziell API:
- Wat Dir braucht fir eng virtuell Interface ze kreéieren.
- Wéi eng virtuell Netzwierk muss et (VM) erstellen?
- Wéi eng VRF (VN) fir et ze binden.
- Eng statesch ARP Entrée fir dëse VM - op wéi eng Interface ass seng IP Adress op a wéi eng MAC Adress ass et gebonnen.
Nach eng Kéier ass déi aktuell Interaktiounsprozedur vereinfacht fir d'Konzept ze verstoen.
Also, vRouter gesäit all VMs vun engem Client op enger bestëmmter Maschinn als direkt verbonne Netzwierker a kann tëscht hinnen selwer route.
Awer VM0 a VM1 gehéieren zu verschiddene Clienten an sinn deementspriechend a verschiddene vRouter Dëscher.
Ob se direkt matenee kommunizéieren kënnen hänkt vun de vRouter-Astellungen an dem Netzdesign of.
Zum Beispill, wa béid Clienten hir VMs ëffentlech Adresse benotzen, oder NAT geschitt um vRouter selwer, da kann direkt Routing op de vRouter gemaach ginn.
An der Géigendeel Situatioun ass et méiglech Adressraim ze Kräiz - Dir musst duerch en NAT Server goen fir eng ëffentlech Adress ze kréien - dat ass ähnlech wéi Zougang zu externen Netzwierker, déi hei ënnen diskutéiert ginn.
Kommunikatioun tëscht VMs op verschiddene kierperleche Maschinnen
Daten Fliger
- Den Ufank ass genau d'selwecht: VM-0 schéckt e Paket mat der Destinatioun VM-7 (172.17.3.2) op seng Default.
- vRouter kritt et an dës Kéier gesäit datt d'Destinatioun op enger anerer Maschinn ass an duerch Tunnel0 zougänglech ass.
- Als éischt hänkt et en MPLS-Label deen d'Fern-Interface identifizéiert, sou datt op der Récksäit vRouter ka bestëmmen wou dëse Paket ouni zousätzlech Lookups placéiert gëtt.
- Tunnel0 huet Quelltext 10.0.0.2, Destinatioun: 10.0.1.2.
vRouter füügt GRE (oder UDP) Header an eng nei IP un den originale Paket. - De vRouter Routing-Tabelle huet e Standardroute duerch d'ToR1 Adress 10.0.0.1. Do schéckt hien et.
- ToR1, als Member vum Underlay Netzwierk, weess (zum Beispill iwwer OSPF) wéi een op 10.0.1.2 kënnt a schéckt de Paket laanscht de Wee. Notéiert datt ECMP hei ageschalt ass. Et ginn zwee Nexthops an der Illustratioun, a verschidde Threads ginn no Hash an hinnen zortéiert. Am Fall vun enger realer Fabréck gëtt et méi wahrscheinlech 4 Nexthops.
Zur selwechter Zäit brauch hien net ze wëssen wat ënner dem externen IP Header steet. Dat ass, tatsächlech, ënner IP kann et e Sandwich vun IPv6 iwwer MPLS iwwer Ethernet iwwer MPLS iwwer GRE iwwer iwwer Griichesch sinn.
- Deementspriechend, op der Empfangssäit, läscht vRouter GRE a benotzt den MPLS Tag, versteet op wéi eng Interface dëse Paket soll geschéckt ginn, stript et a schéckt et a senger ursprénglecher Form un den Empfänger.
Kontroll Fliger
Wann Dir den Auto starten, geschitt datselwecht wéi uewen beschriwwen.
A plus déi folgend:
- Fir all Client verdeelt vRouter en MPLS Tag. Dëst ass de L3VPN Service Label, mat deem Clienten an der selwechter kierperlecher Maschinn getrennt ginn.
Tatsächlech gëtt den MPLS Tag ëmmer bedingungslos vum vRouter zougewisen - schliisslech ass et am Viraus net bekannt datt d'Maschinn nëmme mat anere Maschinnen hannert deemselwechte vRouter interagéiert an dat ass héchstwahrscheinlech net emol wouer.
- vRouter etabléiert eng Verbindung mam SDN Controller mam BGP Protokoll (oder ähnlech - am Fall vun TF, dëst ass XMPP 0_o).
- Duerch dës Sessioun bericht vRouter Strecken op verbonne Netzwierker un den SDN Controller:
- Netzwierk Adress
- Encapsulation Method (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS Client Tag
- Är IP Adress als nexthop
- Den SDN Controller kritt esou Strecken vun all verbonne vRouters a reflektéiert se op anerer. Dat ass, et handelt als Route Reflector.
Datselwecht geschitt an der Géigendeel Richtung.
Overlay kann op d'mannst all Minutt änneren. Dëst ass ongeféier wat an ëffentleche Wolleken geschitt, wou Cliente regelméisseg hir virtuell Maschinnen ufänken an ausschalten.
Den zentrale Controller këmmert sech ëm all d'Komplexitéit fir d'Konfiguratioun z'erhalen an d'Iwwerwaachung vun de Switching / Routing Dëscher op der vRouter.
Grof geschwat, de Controller kommunizéiert mat all vRouters iwwer BGP (oder en ähnleche Protokoll) an iwwerdréit einfach Routinginformatioun. BGP, zum Beispill, huet schonn Adress-Famill fir d'Verkapselungsmethod ze vermëttelen oder .
Zur selwechter Zäit ännert sech d'Konfiguratioun vum Underlay-Netz op kee Fall, wat iwwregens vill méi schwéier ass ze automatiséieren a méi einfach mat enger schweier Bewegung ze briechen.
Sortie op d'Äussewelt
Iergendwou muss d'Simulatioun ophalen, an Dir musst aus der virtueller Welt an déi richteg erausgoen. An Dir braucht e Payphone Paart.
Zwee Approche ginn praktizéiert:
- En Hardware Router ass installéiert.
- En Apparat gëtt gestart, deen d'Funktioune vun engem Router implementéiert (jo, no SDN, hu mir och VNF begéint). Loosst eis et e virtuelle Paart nennen.
De Virdeel vun der zweeter Approche ass bëlleg horizontal Skalierbarkeet - et gëtt net genuch Kraaft - mir hunn eng aner virtuell Maschinn mat engem Paart gestart. Op all physesch Maschinn, ouni gratis Racken, Eenheeten, Stroumausgang ze sichen, d'Hardware selwer kafen, transportéieren, installéieren, wiesselen, konfiguréieren an dann och falsch Komponenten änneren.
D'Nodeeler vun engem virtuelle Paart sinn datt eng Eenheet vun engem kierperleche Router nach ëmmer Uerdere vun der Gréisst méi mächteg ass wéi eng Multi-Core virtuell Maschinn, a seng Software, op seng eegen Hardwarebasis ugepasst, funktionnéiert vill méi stabil (kee). Et ass och schwéier d'Tatsaach ze verleegnen datt d'Hardware- a Softwarekomplex einfach funktionnéiert, nëmmen Konfiguratioun erfuerdert, wärend e virtuelle Paart starten an erhalen ass eng Aufgab fir staark Ingenieuren.
Mat engem Fouss kuckt de Paart an den Overlay virtuelle Netzwierk, wéi eng regulär Virtuell Maschinn, a ka mat all anere VMs interagéieren. Zur selwechter Zäit kann et d'Netzwierker vun alle Clienten ofschléissen an deementspriechend Routing tëscht hinnen ausféieren.
Mat sengem anere Fouss kuckt de Paart an de Backbone-Netz a weess wéi een op den Internet kënnt.
Daten Fliger
Dat ass, de Prozess gesäit esou aus:
- VM-0, deen op deeselwechte vRouter ausgefall ass, schéckt e Paket mat enger Destinatioun an der Äussewelt (185.147.83.177) op d'eth0 Interface.
- vRouter kritt dëse Paket a kuckt d'Destinatiounsadress an der Routingtabelle op - fënnt de Standardroute duerch de VNGW1 Paart duerch Tunnel 1.
Hie gesäit och, datt dëst e GRE Tunnel mat SIP 10.0.0.2 an DIP 10.0.255.2 ass, an hien muss och éischt de MPLS Label vun dësem Client befestegt, déi VNGW1 erwaart. - vRouter packt den initialen Paket mat MPLS, GRE an neien IP Header a schéckt se als Standard op ToR1 10.0.0.1.
- De Basisdaten Netzwierk liwwert de Paket un de Paart VNGW1.
- D'VNGW1 Paart läscht d'GRE an MPLS Tunneling Header, gesäit d'Destinatiounsadress, konsultéiert seng Routingtabelle a versteet datt et op den Internet geleet gëtt - dat heescht duerch Full View oder Default. Wann néideg, mécht NAT Iwwersetzung.
- Et kéint e reegelméissegen IP Netz vu VNGW op d'Grenz sinn, wat onwahrscheinlech ass.
Et kann eng klassesch MPLS Reseau ginn (IGP + LDP / RSVP TE), et kann e Réck Stoff mat BGP LU oder engem GRE Tunnel aus VNGW op d'Grenz iwwer eng IP Reseau ginn.
Sief dat, VNGW1 mécht déi néideg Encapsulatiounen a schéckt den initialen Paket op d'Grenz.
Verkéier an der Géigendeel Richtung geet duerch déi selwecht Schrëtt am Géigendeel Uerdnung.
- D'Grenz fällt de Paket op VNGW1
- Hien kleedt hien aus, kuckt op d'Adress vum Empfänger a gesäit datt hien duerch den Tunnel1 Tunnel (MPLSoGRE oder MPLSoUDP) zougänglech ass.
- Deementspriechend befestegt et en MPLS Label, e GRE / UDP Header an en neien IP a schéckt et op säin ToR3 10.0.255.1.
D'Tunnel Destinatiounsadress ass d'IP Adress vum vRouter hannert deem den Zil-VM läit - 10.0.0.2. - De Basisdaten Netzwierk liwwert de Paket un de gewënschten vRouter.
- Den Zil-vRouter liest GRE / UDP, identifizéiert d'Interface mam MPLS Label a schéckt e bloe IP Paket op seng TAP Interface verbonne mat eth0 vum VM.
Kontroll Fliger
VNGW1 etabléiert e BGP Quartier mat engem SDN Controller, aus deem et all Routinginformatioun iwwer Clienten kritt: wéi eng IP Adress (vRouter) hannert deem Client ass, a wéi engem MPLS Label et identifizéiert gëtt.
Ähnlech informéiert hien selwer den SDN Controller vun der Standardroute mam Label vun dësem Client, a weist sech selwer als Nexthop. An dann kënnt dësen Default bei vRouters.
Op VNGW geschitt normalerweis Route Aggregatioun oder NAT Iwwersetzung.
An an déi aner Richtung schéckt et genee dës aggregéiert Streck an d'Sessioun mat Grenzen oder Route Reflectors. A vun hinnen kritt et de Standardroute oder Full-View, oder soss eppes.
Wat d'Verkapselung an den Trafficaustausch ugeet, ass VNGW net anescht wéi vRouter.
Wann Dir den Ëmfang e bëssen erweidert, da kënnt Dir aner Netzwierkapparater op VNGWs a vRouters addéieren, wéi Firewalls, Verkéierreinigung oder Beräicherungsfarm, IPS, a sou weider.
A mat der Hëllef vu sequenzielle Kreatioun vu VRFs a korrekt Ukënnegung vu Strecken, kënnt Dir de Traffic forcéieren fir ze schleifen wéi Dir wëllt, wat Service Chaining genannt gëtt.
Dat ass, och hei handelt den SDN Controller als Route-Reflector tëscht VNGWs, vRouters an aner Netzwierkapparater.
Awer tatsächlech leckt de Controller och Informatioun iwwer ACL a PBR (Policy Based Routing), sou datt eenzel Trafficfloss anescht goen wéi d'Streck seet hinnen.
FAQ
Firwat maacht Dir ëmmer d'GRE / UDP Bemierkung?
Gutt, am Allgemengen, kann dëst gesot ginn spezifesch fir Wolfram Stoff ze sinn - Dir musst et guer net berücksichtegen.
Awer wa mir et huelen, dann huet TF selwer, wärend nach OpenContrail, béid Encapsulations ënnerstëtzt: MPLS am GRE an MPLS an UDP.
UDP ass gutt well am Source Port et ganz einfach ass eng Hashfunktioun vum Original IP + Proto + Port a sengem Header ze codéieren, wat Iech erlaabt ze balancéieren.
Am Fall vu GRE, leider, ginn et nëmmen extern IP- a GRE-Header, déi d'selwecht sinn fir all verschlësselte Verkéier an et gëtt keng Ried vu Balance - wéineg Leit kënne sou déif am Pak kucken.
Bis eng Zäit hunn d'Router, wa se fäeg sinn dynamesch Tunnelen ze benotzen, dat nëmmen am MPLSoGRE gemaach, an eréischt viru kuerzem hunn se geléiert MPLSoUDP ze benotzen. Dofir musse mir ëmmer eng Notiz iwwer d'Méiglechkeet vun zwou verschiddene Encapsulatiounen maachen.
An Fairness ass et derwäert ze notéieren datt TF voll L2 Konnektivitéit mat VXLAN ënnerstëtzt.
Dir hutt versprach Parallelen mat OpenFlow ze zéien.
Si froen et wierklech. vSwitch am selwechten OpenStack mécht ganz ähnlech Saachen, mat VXLAN, deen iwwregens och en UDP Header huet.
Am Data Plane funktionéiere se ongeféier d'selwecht; de Kontrollplan ënnerscheet sech wesentlech. Tungsten Fabric benotzt XMPP fir Routinginformatioun op vRouter ze liwweren, während OpenStack Openflow leeft.
Kënnt Dir mir e bësse méi iwwer vRouter soen?
Et ass an zwee Deeler opgedeelt: vRouter Agent an vRouter Forwarder.
Déi éischt leeft am User Space vum Host OS a kommunizéiert mam SDN Controller, austauscht Informatiounen iwwer Strecken, VRFs an ACLs.
Déi zweet implementéiert Data Plane - normalerweis am Kernel Space, awer kann och op SmartNICs lafen - Netzwierkkaarte mat enger CPU an engem separaten programméierbare Schaltchip, wat Iech erlaabt d'Laascht vun der CPU vum Hostmaschinn ze läschen, an d'Netzwierk méi séier a méi ze maachen prévisibel.
En anere méigleche Szenario ass datt vRouter eng DPDK Applikatioun am User Space ass.
vRouter Agent schéckt Astellungen op vRouter Forwarder.
Wat ass e virtuellt Netzwierk?
Ech hunn am Ufank vum Artikel iwwer VRF ernimmt datt all Mieter un säin eegene VRF gebonnen ass. A wann dëst genuch war fir en iwwerflächlecht Verständnis vun der Operatioun vum Overlay-Netzwierk, dann ass et op der nächster Iteratioun néideg fir Klärungen ze maachen.
Typesch, a Virtualiséierungsmechanismen, gëtt d'Virtual Network Entity (Dir kënnt dat als eegent Substantiv betruechten) getrennt vu Clienten / Locataire / virtuelle Maschinnen agefouert - eng komplett onofhängeg Saach. An dëst virtuellt Netzwierk ka schonn iwwer Schnëttplazen mat engem Locataire verbonne sinn, mat engem aneren, mat zwee oder iwwerall. Also, zum Beispill, Service Chaining gëtt implementéiert wann de Traffic duerch gewësse Noden an der erfuerderter Sequenz muss passéiert ginn, einfach andeems Dir virtuell Netzwierker an der korrekter Sequenz erstellt a verbënnt.
Dofir, als solch, gëtt et keng direkt Korrespondenz tëscht dem virtuelle Netzwierk an dem Mieter.
Konklusioun
Dëst ass eng ganz iwwerflächlech Beschreiwung vun der Operatioun vun engem virtuellen Netzwierk mat engem Overlay vum Host an engem SDN Controller. Awer egal wéi eng Virtualiséierungsplattform Dir haut wielt, et funktionnéiert op eng ähnlech Manéier, sief et VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric oder Juniper Contrail. Si ënnerscheeden sech an den Typen vun Verschlësselungen an Header, Protokoller fir d'Informatioun un d'Ennnetzgeräter ze liwweren, awer de Prinzip vun engem Software-konfiguréierbare Overlay-Netzwierk, deen uewen op engem relativ einfachen a statesche Underlay-Netzwierk funktionnéiert, bleift d'selwecht.
Mir kënne soen datt haut SDN baséiert op engem Overlay Netz d'Feld gewonnen huet fir eng privat Wollek ze kreéieren. Wéi och ëmmer, dat heescht net datt Openflow keng Plaz an der moderner Welt huet - et gëtt an OpenStacke benotzt an an der selwechter VMWare NSX, souwäit ech weess, benotzt Google et fir den ënnerierdesche Netzwierk opzestellen.
Hei ënnen hunn ech Linken op méi detailléiert Materialien geliwwert wann Dir d'Thema méi déif wëllt studéieren.
A wéi ass et mat eisem Underlay?
Mee am Allgemengen näischt. Hien huet de ganze Wee net geännert. Alles wat hien am Fall vun enger Iwwerlagerung vum Host muss maachen ass d'Strecken an d'ARPs ze aktualiséieren wéi vRouter / VNGW erschéngen a verschwannen a Päckchen tëscht hinnen droen.
Loosst eis eng Lëscht vun Ufuerderunge fir den Underlay Netzwierk formuléieren.
- Kënnen eng Zort Routingprotokoll benotzen, an eiser Situatioun - BGP.
- Hutt eng breet Bandbreedung, am léifsten ouni Iwwerabonnement, sou datt Päckchen net duerch Iwwerlaascht verluer ginn.
- ECMP ënnerstëtzen ass en integralen Deel vum Stoff.
- Kënnen QoS ubidden, dorënner komplizéiert Saachen wéi ECN.
- NETCONF ënnerstëtzen ass e Fundament fir d'Zukunft.
Ech hunn hei ganz wéineg Zäit fir d'Aarbecht vum Underlay Netzwierk selwer gewidmet. Dëst ass well ech méi spéit an der Serie op et fokusséiere wäerten, a mir wäerten nëmmen op Overlay beréieren.
Selbstverständlech limitéieren ech eis all schwéier andeems ech als Beispill en DC-Netzwierk benotzen, deen an enger Cloz-Fabréck gebaut gouf mat purem IP-Routing an engem Iwwerlager vum Host.
Wéi och ëmmer, ech sinn zouversiichtlech datt all Netzwierk deen en Design huet a formelle Begrëffer an automatiséiert ka beschriwwe ginn. Et ass just datt mäi Zil hei ass Approche fir d'Automatiséierung ze verstoen, an net jiddereen duercherneen ze bréngen andeems de Problem an enger allgemenger Form léist.
Als Deel vun ADSM plangen de Roman Gorge an ech eng separat Ausgab iwwer d'Virtualiséierung vun der Rechenkraaft a seng Interaktioun mat der Netzvirtualiséierung ze publizéieren. A Kontakt bleiwen.
Nëtzlech Adressen
- .
- . 6 Stonnen iwwer Yandex.Cloud, déi och de virtuelle Netzwierk op TF deckt.
- .
- . Et schwätzt iwwer de ganze DC Netz, dorënner Underlay, Overlay, Approche fir Multi-Homing a Management.
Merci
- - fréiere Host vum Linkmeup Podcast an elo en Expert am Beräich vun de Cloud Plattformen. Fir Kommentaren an Ännerungen. Gutt, mir waarden op säi méi am-Déift Artikel iwwer Virtualiséierung an der nächster Zukunft.
- - mäi Kolleg an Expert am Beräich vun der virtueller Netzwierkentwécklung. Fir Kommentaren an Ännerungen.
- - mäi Kolleg an Expert am Beräich vun Wolfram Stoff. Fir Kommentaren an Ännerungen.
- - Illustrator linkmeup. Fir KDPV.
- Alexander Limonov. Fir den "Automato" Meme.
Source: will.com