В Ik beskreau it netwurk automatisearring ramt. Neffens guon minsken, sels dizze earste oanpak fan it probleem hat al sortearre út guon fragen. En dit makket my tige bliid, om't ús doel yn 'e syklus net is om de Ansible te bedekken mei Python-skripts, mar om in systeem te bouwen.
Itselde ramt jout de folchoarder wêryn't wy mei de fraach omgean sille.
En netwurkvirtualisaasje, dêr't dit probleem oan wijd is, past net benammen yn it ADSM-ûnderwerp, wêr't wy automatisearring analysearje.
Mar lit ús it út in oare hoeke sjen.
In protte tsjinsten hawwe in lange tiid itselde netwurk brûkt. Yn it gefal fan in telekomoperator is dit bygelyks 2G, 3G, LTE, breedbân en B2B. Yn it gefal fan in DC: ferbining foar ferskate kliïnten, ynternet, blok opslach, objekt opslach.
En alle tsjinsten fereaskje isolaasje fan elkoar. Dit is hoe't overlay netwurken ferskynden.
En alle tsjinsten wolle net wachtsje op in persoan om se manuell te konfigurearjen. Dit is hoe't orkestrators en SDN ferskynden.
De earste oanpak fan systematyske automatisearring fan it netwurk, of leaver in diel dêrfan, is lang nommen en ymplementearre op in protte plakken: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Dêr sille wy hjoed mei dwaande hâlde.
Ynhâld
- redenen
- Terminology
- Underlay - fysyk netwurk
- Overlay - firtuele netwurk
- Overlay mei ToR
- Overlay fan host
- Mei Tungsten Fabric as foarbyld
- Kommunikaasje binnen ien fysike masine
- Kommunikaasje tusken VM's op ferskate fysike masines
- Útgong nei de bûtenwrâld
- FAQ
- konklúzje
- Nuttige keppelings
redenen
En om't wy it oer dit hawwe, is it de muoite wurdich om de betingsten foar netwurkvirtualisaasje te neamen. Eins is dit proses juster net begûn.
Jo hawwe wierskynlik mear as ien kear heard dat it netwurk altyd it meast inerte diel fan elk systeem west hat. En dit is wier yn alle opsichten. It netwurk is de basis dêr't alles op rêst, en it meitsjen fan feroaringen op it is hiel lestich - tsjinsten net tolerearje as it netwurk is del. Faak kin it ûntmanteljen fan in inkeld knooppunt in grut part fan applikaasjes ôfnimme en in protte klanten beynfloedzje. Dit is foar in part de reden dat it netwurkteam elke feroaring ferset kin - want no wurket it op ien of oare manier (wy meie net iens witte hoe), mar hjir moatte jo wat nijs konfigurearje, en it is ûnbekend hoe't it sil beynfloedzje it netwurk.
Om net te wachtsjen op netwurkers om VLAN's yn te foegjen en gjin tsjinsten te registrearjen op elke netwurkknooppunt, kamen minsken op it idee om overlays te brûken - overlay-netwurken - wêrfan d'r in grut ferskaat is: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ensfh.
Har berop leit yn twa ienfâldige dingen:
- Allinich einknooppunten binne konfigureare - transitknooppunten hoege net te wurde oanrekke. Dit fersnelt it proses signifikant, en soms kinne jo de ôfdieling netwurkynfrastruktuer folslein útslute fan it proses fan ynfiering fan nije tsjinsten.
- De lading is djip yn 'e kopteksten ferburgen - transitknooppunten hoege der neat oer te witten, oer adressen op 'e hosts, of oer de rûtes fan it overlay-netwurk. Dit betsjut dat jo minder ynformaasje yn tabellen opslaan moatte, wat betsjut dat jo in ienfâldiger / goedkeaper apparaat brûke.
Yn dit net folslein folweardige probleem bin ik net fan plan om alle mooglike technologyen te analysearjen, mar leaver it ramt te beskriuwen foar de eksploitaasje fan overlay-netwurken yn DC's.
De hiele rige sil beskriuwe in data sintrum besteande út rigen fan identike rekken dêr't deselde server apparatuer is ynstallearre.
Dizze apparatuer rint firtuele masines / konteners / serverless dy't tsjinsten implementearje.
Terminology
Yn in loop tsjinner Ik sil in programma neame dat de tsjinnerkant fan kliïnt-tsjinner kommunikaasje ymplementearret.
Fysike masines yn rekken wurde neamd tsjinners net wy sille.
Fysike masine - x86 kompjûter ynstallearre yn in rek. De meast brûkte term host. Dat sille wy it neame"машина"of host.
Hypervisor - in applikaasje dy't rint op in fysike masine dy't de fysike boarnen emulearret wêrop firtuele masines rinne. Soms wurdt yn literatuer en ynternet it wurd "hypervisor" brûkt as synonym foar "host".
Firtuele masine - in bestjoeringssysteem dat rint op in fysike masine boppe op in hypervisor. Foar ús yn dizze syklus makket it net echt út oft it eins in firtuele masine is as gewoan in kontener. litte wy it neame"VM«
Hierder is in breed konsept dat ik yn dit artikel sil definiearje as in aparte tsjinst as in aparte klant.
Multi-tenancy of multitenancy - it brûken fan deselde applikaasje troch ferskate kliïnten / tsjinsten. Tagelyk wurdt isolaasje fan kliïnten fan elkoar berikt troch de applikaasje-arsjitektuer, en net troch apart rinnende eksimplaren.
ToR - Top of the Rack switch - in switch ynstallearre yn in rek dêr't alle fysike masines binne ferbûn.
Njonken de ToR-topology oefenje ferskate providers End of Row (EoR) of Middle of Row (hoewol't de lêste in disparating seldsumheid is en ik haw de MoR-ôfkoarting net sjoen).
Underlay netwurk of it ûnderlizzende netwurk of ûnderlizzende is de fysike netwurkynfrastruktuer: switches, routers, kabels.
Overlay netwurk of overlay netwurk of overlay - in firtuele netwurk fan tunnels rinne boppe op 'e fysike.
L3 stof of IP stof - in geweldige útfining fan it minskdom wêrtroch jo STP kinne foarkomme en TRILL learje foar ynterviews. In konsept wêryn it heule netwurk oant it tagongsnivo eksklusyf L3 is, sûnder VLAN's en, dus, enoarme útwreide útstjoerdomeinen. Wy sille yn it folgjende diel besjen wêr't it wurd "fabryk" weikomt.
SDN - Software Defined Network. Hast gjin ynlieding nedich. In oanpak foar netwurkbehear wêrby't feroaringen yn it netwurk net troch in persoan makke wurde, mar troch in programma. Meastal betsjut it ferpleatsen fan de Control Plane foarby de ein netwurk apparaten oan de controller.
NFV - Virtualisearring fan netwurkfunksjes - virtualisaasje fan netwurkapparaten, wat suggerearret dat guon netwurkfunksjes kinne wurde útfierd yn 'e foarm fan firtuele masines as konteners om de ymplemintaasje fan nije tsjinsten te rapperjen, Service Chaining te organisearjen en ienfâldiger horizontale skalberens.
VNF - Firtuele netwurkfunksje. Spesifyk firtuele apparaat: router, switch, firewall, NAT, IPS / IDS, ensfh.
Ik ferienfâldigje de beskriuwing no mei opsetsin ta in spesifike ymplemintaasje, om de lêzer net tefolle yn betizing te bringen. Foar mear yntinsyf lêzen ferwize ik him nei de seksje . Dêrnjonken belooft Roma Gorge, dy't dit artikel bekritisearret foar ûnkrektens, in apart probleem te skriuwen oer server- en netwurkvirtualisaasjetechnologyen, mear yngeande en oandachtich foar detail.
De measte netwurken hjoed kinne dúdlik wurde ferdield yn twa dielen:
Underlay - in fysyk netwurk mei in stabile konfiguraasje.
Overlay - abstraksje oer Underlay foar isolearjen fan hierders.
Dit is wier sawol foar it gefal fan DC (dy't wy sille analysearje yn dit artikel) en foar ISP (dy't wy sille net analysearje, om't it is al west ). Mei ûndernimmingsnetwurken is de situaasje fansels wat oars.
Ofbylding mei fokus op it netwurk:
Underlay
Underlay is in fysyk netwurk: hardware switches en kabels. Apparaten yn 'e ûndergrûn witte hoe te berikken fysike masines.
It fertrout op standert protokollen en technologyen. Net it minst om't hardware-apparaten oant hjoed de dei wurkje op proprietêre software dy't de chip net programmearje of har eigen protokollen ymplementearje; dêrom binne kompatibiliteit mei oare leveransiers en standerdisearring nedich.
Mar immen lykas Google kin it betelje om har eigen skeakels te ûntwikkeljen en algemien akseptearre protokollen te ferlitten. Mar LAN_DC is net Google.
Underlay feroaret relatyf komselden, om't syn baan basis IP-ferbining is tusken fysike masines. Underlay wit neat oer de tsjinsten, kliïnten of hierders dy't derop rinne - it hoecht allinich it pakket fan de iene masine nei de oare te leverjen.
Underlay kin sa wêze:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
It Underlay-netwurk is konfigureare op 'e klassike manier: CLI / GUI / NETCONF.
Hânmjittich, skripts, proprietêre nutsbedriuwen.
It folgjende artikel yn 'e searje sil yn mear detail wurde wijd oan' e ûnderlaach.
Overlay
Overlay is in firtuele netwurk fan tunnels útwreide boppe op Underlay, it lit VM's fan ien kliïnt mei-inoar kommunisearje, wylst se isolaasje leverje fan oare kliïnten.
De kliïntgegevens binne ynkapsele yn guon tunnelingkoppen foar oerdracht oer it iepenbiere netwurk.
Dat VM's fan ien kliïnt (ien tsjinst) kinne mei-inoar kommunisearje fia Overlay, sûnder sels te witten hokker paad it pakket eins nimt.
Overlay kin bygelyks wêze lykas ik hjirboppe neamde:
- GRE tunnel
- VXLAN
- EVPN
- L3VPN
- GENEVE
In overlay netwurk wurdt typysk konfigurearre en ûnderhâlden fia in sintrale controller. Dêrfan wurde de konfiguraasje, Control Plane en Data Plane levere oan apparaten dy't it kliïntferkear rûte en ynkapselje. In bytsje Litte wy dit sjen mei foarbylden.
Ja, dit is SDN yn syn suverste foarm.
D'r binne twa fûneminteel ferskillende oanpak foar it organisearjen fan in Overlay-netwurk:
- Overlay mei ToR
- Overlay fan host
Overlay mei ToR
Overlay kin begjinne by de tagong switch (ToR) steande yn it rek, lykas bart, bygelyks, yn it gefal fan in VXLAN stof.
Dit is in tiid-testen meganisme op ISP-netwurken en alle leveransiers fan netwurkapparatuer stypje it.
Yn dit gefal moat de ToR-skeakel lykwols yn steat wêze om respektivelik de ferskate tsjinsten te skieden, en de netwurkbehearder moat, yn in bepaalde mate, gearwurkje mei de behearders fan firtuele masines en wizigingen meitsje (hoewol automatysk) yn 'e konfiguraasje fan' e apparaten .
Hjir sil ik de lêzer ferwize nei in artikel oer ús âlde freon .
Hjiryn oanpakken foar it bouwen fan in DC netwurk mei in EVPN VXLAN stof wurde beskreaun yn detail.
En foar in folsleine ûnderdompeling yn 'e realiteit kinne jo it boek fan Tsiska lêze .
Ik konstatearje dat VXLAN is allinnich in ynkapseling metoade en beëiniging fan tunnels kin foarkomme net op ToR, mar op de host, lykas bart yn it gefal fan OpenStack, bygelyks.
VXLAN-stof, wêr't de overlay begjint by ToR, is lykwols ien fan 'e fêststelde oerlay-netwurkûntwerpen.
Overlay fan host
In oare oanpak is om tunnels op 'e einhosts te begjinnen en te beëinigjen.
Yn dit gefal bliuwt it netwurk (Underlay) sa ienfâldich en statysk mooglik.
En de host sels docht alle nedige ynkapseling.
Dit sil fansels in spesjale applikaasje op 'e hosts útfiere, mar it is it wurdich.
As earste, it útfieren fan in kliïnt op in Linux-masine is makliker as, litte wy sizze, sels mooglik, wylst jo op in switch nei alle gedachten sille moatte wikselje nei proprietêre SDN-oplossingen, dy't it idee fan multi-ferkeaper deadet.
Twadder kin de ToR-skeakel yn dit gefal sa ienfâldich mooglik wurde litten, sawol út it eachpunt fan it Control Plane as it Data Plane. Yndied, dan hoecht it net te kommunisearjen mei de SDN-controller, en it hoecht ek net de netwurken / ARP's fan alle ferbûne kliïnten op te slaan - it is genôch om it IP-adres fan 'e fysike masine te witten, wat it wikseljen / sterk simplifiest routing tabellen.
Yn 'e ADSM-searje kies ik de overlay-oanpak fan' e host - dan prate wy der allinich oer en sille wy net weromkomme nei it VXLAN-fabryk.
It is it maklikst om nei foarbylden te sjen. En as testûnderwerp sille wy it OpenSource SDN-platfoarm OpenContrail nimme, no bekend as .
Oan 'e ein fan it artikel sil ik wat gedachten jaan oer de analogy mei OpenFlow en OpenvSwitch.
Mei Tungsten Fabric as foarbyld
Eltse fysike masine hat vRouter - in firtuele router dy't wit oer de netwurken dy't dêrmei ferbûn binne en hokker kliïnten se hearre - yn wêzen in PE-router. Foar elke klant ûnderhâldt it in isolearre routingtabel (lês VRF). En vRouter docht eins Overlay-tunneling.
In bytsje mear oer vRouter is oan 'e ein fan it artikel.
Eltse VM leit op de hypervisor is ferbûn mei de vRouter fan dizze masine fia .
TAP - Terminal Access Point - in firtuele ynterface yn 'e Linux kernel dy't netwurk ynteraksje mooglik makket.
As d'r ferskate netwurken efter de vRouter binne, dan wurdt in firtuele ynterface foar elk fan har makke, wêryn in IP-adres wurdt tawiisd - it sil it standert gateway-adres wêze.
Alle netwurken fan ien kliïnt wurde yn ien pleatst VRF (ien tafel), ferskillende - yn ferskate.
Ik sil hjir in disclaimer meitsje dat net alles sa ienfâldich is, en ik sil de nijsgjirrige lêzer nei it ein fan it artikel stjoere.
Sadat vRouters mei-inoar kinne kommunisearje, en dus de VM's dy't der efter sitte, wikselje se routing-ynformaasje út fia SDN controller.
Om de bûtenwrâld út te kommen, is d'r in útgongspunt fan 'e matrix - in firtuele netwurkpoarte VNGW - Virtual Network GateWay (myn term).
Litte wy no nei foarbylden fan kommunikaasje sjen - en d'r sil dúdlikens wêze.
Kommunikaasje binnen ien fysike masine
VM0 wol in pakket nei VM2 stjoere. Lit ús foarearst oannimme dat dit in VM mei ien klant is.
data fleanmasine
- VM-0 hat in standert rûte nei syn eth0 ynterface. It pakket wurdt derhinne stjoerd.
Dizze ynterface eth0 is feitlik ferbûn mei de firtuele router vRouter fia de TAP-ynterface tap0. - vRouter analysearret hokker ynterface it pakket kaam ta, dat is, hokker client (VRF) it heart by, en kontrolearret it adres fan de ûntfanger mei de routing tabel fan dizze client.
- Nei't ûntdutsen is dat de ûntfanger op deselde masine op in oare poarte is, stjoert vRouter it pakket der gewoan nei sûnder ekstra kopteksten - foar dit gefal hat vRouter al in ARP-record.
Yn dit gefal komt it pakket net yn it fysike netwurk - it wurdt trochstjoerd binnen de vRouter.
Kontrole fleanmasine
As de firtuele masine begjint, fertelt de hypervisor it:
- Har eigen IP-adres.
- De standertrûte is fia it IP-adres fan de vRouter op dit netwurk.
De hypervisor rapportearret oan vRouter fia in spesjale API:
- Wat jo nedich hawwe om in firtuele ynterface te meitsjen.
- Hokker soarte firtuele netwurk moat it (VM) oanmeitsje?
- Hokker VRF (VN) om it oan te binen.
- In statyske ARP-yngong foar dizze VM - hokker ynterface efter it IP-adres sit en mei hokker MAC-adres it is assosjearre.
Nochris wurdt de eigentlike ynteraksjeproseduere ferienfâldige om it begryp te begripen.
Sa sjocht vRouter alle VM's fan ien kliïnt op in opjûne masine as direkt ferbûne netwurken en kin se sels rûte tusken har.
Mar VM0 en VM1 hearre ta ferskate kliïnten en, neffens, binne yn ferskillende vRouter tabellen.
Oft se kinne kommunisearje mei elkoar direkt hinget ôf fan de vRouter ynstellings en netwurk design.
Bygelyks, as de VM's fan beide kliïnten iepenbiere adressen brûke, of NAT op 'e vRouter sels komt, dan kin direkte routing nei de vRouter dien wurde.
Yn 'e tsjinoerstelde situaasje is it mooglik om adresromten oer te stekken - jo moatte troch in NAT-tsjinner gean om in iepenbier adres te krijen - dit is gelyk oan tagong ta eksterne netwurken, dy't hjirûnder besprutsen wurde.
Kommunikaasje tusken VM's op ferskate fysike masines
data fleanmasine
- It begjin is krekt itselde: VM-0 stjoert in pakket mei de bestimming VM-7 (172.17.3.2) op syn standert.
- vRouter ûntfangt it en sjocht dizze kear dat de bestimming op in oare masine is en tagonklik is fia Tunnel0.
- Earst hinget it in MPLS-label dy't de ynterface op ôfstân identifisearret, sadat op 'e efterkant vRouter kin bepale wêr't dit pakket moat pleatse sûnder ekstra opsykjen.
- Tunnel0 hat boarne 10.0.0.2, bestimming: 10.0.1.2.
vRouter foeget GRE (as UDP) headers en in nije IP ta oan it orizjinele pakket. - De vRouter-routingtabel hat in standertrûte troch it ToR1-adres 10.0.0.1. Dêr stjoert er it.
- ToR1, as lid fan it Underlay-netwurk, wit (bygelyks fia OSPF) hoe't jo nei 10.0.1.2 komme en stjoert it pakket lâns de rûte. Tink derom dat ECMP hjir ynskeakele is. D'r binne twa nexthops yn 'e yllustraasje, en ferskate triedden sille yn har wurde sorteare troch hash. Yn it gefal fan in echte fabryk sille d'r wierskynliker 4 nexthops wêze.
Tagelyk hoecht hy net te witten wat der ûnder de eksterne IP-header stiet. Dat is, yn feite, ûnder IP kin d'r in sandwich wêze fan IPv6 oer MPLS oer Ethernet oer MPLS oer GRE oer oer Gryksk.
- Dêrtroch, oan 'e ûntfangende kant, ferwideret vRouter GRE en, mei help fan de MPLS-tag, begrypt hokker ynterface dit pakket moat wurde stjoerd nei, stript it en stjoert it yn syn oarspronklike foarm nei de ûntfanger.
Kontrole fleanmasine
As jo de auto begjinne, bart itselde as hjirboppe beskreaun.
En plus it folgjende:
- Foar elke kliïnt jout vRouter in MPLS-tag ta. Dit is it L3VPN-tsjinstlabel, wêrmei kliïnten wurde skieden binnen deselde fysike masine.
Yn feite wurdt de MPLS-tag altyd sûnder betingsten tawiisd troch de vRouter - it is ommers net fan tefoaren bekend dat de masine allinich ynteraksje sil mei oare masines efter deselde vRouter en dit is nei alle gedachten net iens wier.
- vRouter stelt in ferbining mei de SDN-controller mei it BGP-protokol (of fergelykber mei it - yn it gefal fan TF, dit is XMPP 0_o).
- Troch dizze sesje rapportearret vRouter rûtes nei ferbûne netwurken oan de SDN-controller:
- Netwurk adres
- Ynkapsulaasjemetoade (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS client tag
- Jo IP-adres as nexthop
- De SDN-controller ûntfangt sokke rûtes fan alle ferbûne vRouters en reflektearret se nei oaren. Dat is, it fungearret as in Route Reflector.
Itselde bart yn 'e tsjinoerstelde rjochting.
Overlay kin op syn minst elke minút feroarje. Dit is sawat wat bart yn iepenbiere wolken, wêr't kliïnten har firtuele masines regelmjittich begjinne en ôfslute.
De sintrale kontrôler soarget foar alle kompleksiteit fan it behâld fan de konfiguraasje en it kontrolearjen fan de wiksel- / routingtabellen op 'e vRouter.
Rûchwei sprutsen, de controller kommunisearret mei alle vRouters fia BGP (as in ferlykber protokol) en gewoan stjoert routing ynformaasje. BGP hat bygelyks al Adres-Famylje om de ynkapselingsmetoade oer te bringen of .
Tagelyk feroaret de konfiguraasje fan it Underlay-netwurk op gjin inkelde manier, wat, trouwens, folle dreger is om te automatisearjen, en makliker te brekken mei in ûnhandige beweging.
Útgong nei de bûtenwrâld
Earne moat de simulaasje einigje, en jo moatte de firtuele wrâld ferlitte yn 'e echte. En jo moatte in payphone gateway.
Twa oanpak wurde praktisearre:
- In hardware router is ynstallearre.
- In apparaat wurdt lansearre dat de funksjes fan in router ymplementearret (ja, nei SDN, hawwe wy ek VNF tsjinkaam). Litte wy it in firtuele poarte neame.
It foardiel fan 'e twadde oanpak is goedkeap horizontale skalberens - d'r is net genôch krêft - wy lansearre in oare firtuele masine mei in poarte. Op elke fysike masine, sûnder te sykjen nei fergese rekken, ienheden, krêftútfier, keapje de hardware sels, ferfiere it, ynstallearje it, wikselje it, konfigurearje it, en feroarje der dan ek defekte komponinten yn.
De neidielen fan in firtuele gateway binne dat in ienheid fan in fysike router noch machtiger is as in multi-core firtuele masine, en syn software, ôfstimd op har eigen hardwarebasis, wurket folle stabiler (gjin). It is ek lestich om it feit te ûntkenne dat it hardware- en softwarekompleks gewoan wurket, allinich konfiguraasje fereasket, wylst it starten en ûnderhâlden fan in firtuele poarte in taak is foar sterke yngenieurs.
Mei ien foet sjocht de poarte yn it Overlay firtuele netwurk, lykas in gewoane firtuele masine, en kin ynteraksje mei alle oare VM's. Tagelyk kin it de netwurken fan alle kliïnten beëinigje en dêrtroch routing tusken har útfiere.
Mei syn oare foet sjocht de poarte yn it eftergrûnnetwurk en wit hoe't se op it ynternet komme.
data fleanmasine
Dat is, it proses sjocht der sa út:
- VM-0, dy't standert is op deselde vRouter, stjoert in pakket mei in bestimming yn 'e bûtenwrâld (185.147.83.177) nei de eth0-ynterface.
- vRouter ûntfangt dit pakket en siket it bestimmingsadres op yn 'e routingtabel - fynt de standertrûte troch de VNGW1-poarte troch Tunnel 1.
Hy sjocht ek dat dit in GRE-tunnel is mei SIP 10.0.0.2 en DIP 10.0.255.2, en hy moat ek earst it MPLS-label fan dizze kliïnt taheakje, wat VNGW1 ferwachtet. - vRouter pakt it earste pakket mei MPLS, GRE en nije IP-koppen en stjoert it standert nei ToR1 10.0.0.1.
- It ûnderlizzende netwurk leveret it pakket oan 'e gateway VNGW1.
- De VNGW1-gateway ferwideret de GRE- en MPLS-tunnelingkoppen, sjocht it bestimmingsadres, rieplachtet syn routingtabel en begrypt dat it is rjochte op it ynternet - dat is fia Folsleine werjefte of Standert. As it nedich is, fiert NAT-oersetting.
- D'r kin in gewoan IP-netwurk wêze fan VNGW nei de grins, wat net wierskynlik is.
Der kin in klassike MPLS netwurk (IGP + LDP / RSVP TE), der kin in werom stof mei BGP LU of in GRE tunnel út VNGW oan 'e grins fia in IP netwurk.
Hoe dan ek, VNGW1 fiert de nedige ynkapselings en stjoert it earste pakket nei de grins.
Ferkear yn 'e tsjinoerstelde rjochting giet troch deselde stappen yn' e tsjinoerstelde folchoarder.
- De grins sakket it pakket nei VNGW1
- Hy kleedt him út, sjocht nei it adres fan de ûntfanger en sjocht dat er tagonklik is fia de Tunnel1-tunnel (MPLSoGRE of MPLSoUDP).
- Dêrnjonken hechtet it in MPLS-label, in GRE / UDP-header en in nije IP oan en stjoert it nei syn ToR3 10.0.255.1.
It tunnelbestimmingsadres is it IP-adres fan 'e vRouter wêrachter de doel-VM leit - 10.0.0.2. - It ûnderlizzende netwurk leveret it pakket oan de winske vRouter.
- De doel vRouter lêst GRE / UDP, identifisearret de ynterface mei it MPLS-label en stjoert in bleat IP-pakket nei syn TAP-ynterface ferbûn mei eth0 fan 'e VM.
Kontrole fleanmasine
VNGW1 stelt in BGP-wyk fêst mei in SDN-controller, wêrfan it alle routing-ynformaasje oer kliïnten ûntfangt: hokker IP-adres (vRouter) efter hokker kliïnt sit, en troch hokker MPLS-label it wurdt identifisearre.
Op deselde manier ynformearret hy sels de SDN-kontrôler fan 'e standertrûte mei it label fan dizze kliïnt, dy't himsels oanjout as de nexthop. En dan komt dizze standert by vRouters.
Op VNGW komt rûteaggregaasje of NAT-oersetting gewoanlik foar.
En yn 'e oare rjochting stjoert it krekt dizze aggregearre rûte nei de sesje mei grinzen of Route Reflectors. En fan harren ûntfangt it de standertrûte of Full-View, of wat oars.
Yn termen fan ynkapseling en ferkearsútwikseling is VNGW net oars fan vRouter.
As jo de omfang in bytsje útwreidzje, dan kinne jo oare netwurkapparaten tafoegje oan VNGW's en vRouters, lykas firewalls, ferkearsreiniging of ferrikingsbuorkerijen, IPS, ensfh.
En mei help fan opienfolgjende oanmeitsjen fan VRF's en korrekte oankundiging fan rûtes, kinne jo ferkear twinge om te loopen lykas jo wolle, dat hjit Service Chaining.
Dat is, ek hjir fungearret de SDN-controller as in Route-Reflector tusken VNGW's, vRouters en oare netwurkapparaten.
Mar yn feite jout de controller ek ynformaasje oer ACL en PBR (Policy Based Routing), wêrtroch't yndividuele ferkearsstreamen oars geane as de rûte har fertelt.
FAQ
Wêrom meitsje jo altyd de GRE / UDP-opmerking?
No, yn 't algemien kin sein wurde dat dit spesifyk is foar Tungsten Fabric - jo hoege it hielendal net te rekkenjen.
Mar as wy it nimme, stipe TF sels, wylst noch OpenContrail, beide ynkapselings: MPLS yn GRE en MPLS yn UDP.
UDP is goed, om't it yn 'e Boarnepoarte heul maklik is om in hashfunksje te kodearjen fan' e orizjinele IP + Proto + Port yn 'e koptekst, wêrtroch jo balâns kinne dwaan.
Yn it gefal fan GRE, helaas, binne d'r allinich eksterne IP- en GRE-koppen, dy't itselde binne foar alle ynkapsulearre ferkear en der is gjin sprake fan balânsjen - in pear minsken kinne sa djip yn it pakket sjen.
Oant in skoft diene routers, as se wisten hoe't se dynamyske tunnels koenen brûke, dat allinich yn MPLSoGRE, en pas heul koartlyn learden se MPLSoUDP te brûken. Dêrom moatte wy altyd in notysje meitsje oer de mooglikheid fan twa ferskillende ynkapselings.
Earlikens is it de muoite wurdich op te merken dat TF L2-ferbining folslein stipet mei VXLAN.
Jo hawwe tasein parallellen te tekenjen mei OpenFlow.
Se freegje der echt om. vSwitch yn deselde OpenStack docht heul ferlykbere dingen, mei VXLAN, dy't trouwens ek in UDP-header hat.
Yn it Data Plane wurkje se sawat itselde; it Control Plane ferskilt signifikant. Tungsten Fabric brûkt XMPP om routingynformaasje te leverjen oan vRouter, wylst OpenStack Openflow rint.
Kinne jo my in bytsje mear fertelle oer vRouter?
It is ferdield yn twa dielen: vRouter Agent en vRouter Forwarder.
De earste rint yn 'e brûkersromte fan' e host OS en kommunisearret mei de SDN-controller, en wikselet ynformaasje oer rûtes, VRF's en ACL's.
De twadde ymplementearret Data Plane - meastentiids yn Kernel Space, mar kin ek rinne op SmartNICs - netwurk kaarten mei in CPU en in aparte programmabele switching chip, dat kinne jo fuortsmite de lading fan de host masine syn CPU, en meitsje it netwurk flugger en mear foarsisber.
In oar mooglik senario is dat vRouter in DPDK-applikaasje is yn User Space.
vRouter Agent stjoert ynstellings nei vRouter Forwarder.
Wat is in firtuele netwurk?
Ik neamde oan it begjin fan it artikel oer VRF dat elke hierder is bûn oan syn eigen VRF. En as dit genôch wie foar in oerflakkich begryp fan 'e wurking fan it overlay-netwurk, dan is it nedich om dúdlikens te meitsjen by de folgjende iteraasje.
Typysk, yn virtualisaasjemeganismen, wurdt de Virtual Network-entiteit (jo kinne dit in eigen haadwurd beskôgje) apart yntrodusearre fan kliïnten / hierders / firtuele masines - in folslein ûnôfhinklik ding. En dit firtuele netwurk kin al ferbûn wurde fia ynterfaces oan ien hierder, nei in oare, mei twa, of oeral. Sa, bygelyks, Service Chaining wurdt ymplementearre as ferkear moat wurde trochjûn troch bepaalde knopen yn de fereaske folchoarder, gewoan troch it meitsjen en ferbinen firtuele netwurken yn de juste folchoarder.
Dêrom is d'r as sadanich gjin direkte korrespondinsje tusken it firtuele netwurk en de hierder.
konklúzje
Dit is in heul oerflakkige beskriuwing fan 'e wurking fan in firtuele netwurk mei in overlay fan' e host en in SDN-controller. Mar hokker virtualisaasjeplatfoarm jo hjoed kieze, sil it op in fergelykbere manier wurkje, of it no VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric of Juniper Contrail is. Se sille ferskille yn 'e soarten ynkapsulaasjes en kopteksten, protokollen foar it leverjen fan ynformaasje oan' e ein fan netwurkapparaten, mar it prinsipe fan in software-konfigurearber overlay-netwurk dat boppe op in relatyf ienfâldige en statyske ûnderlizzende netwurk wurket, sil itselde bliuwe.
Wy kinne sizze dat hjoed SDN basearre op in overlay netwurk hat wûn it fjild fan it meitsjen fan in privee wolk. Dit betsjut lykwols net dat Openflow gjin plak hat yn 'e moderne wrâld - it wurdt brûkt yn OpenStacke en yn deselde VMWare NSX, sa fier as ik wit, brûkt Google it om it ûndergrûnske netwurk op te stellen.
Hjirûnder haw ik keppelings levere nei mear detaillearre materialen as jo it probleem djipper wolle studearje.
En hoe sit it mei ús Underlay?
Mar yn it algemien, neat. Hy feroare de hiele wei net. Alles wat hy hoecht te dwaan yn it gefal fan in overlay fan 'e host is rûtes en ARP's te fernijen as vRouter / VNGW ferskine en ferdwine en pakketten tusken har drage.
Litte wy in list formulearje mei easken foar it Underlay-netwurk.
- Kin in soarte fan routingprotokol brûke, yn ús situaasje - BGP.
- Hawwe in brede bânbreedte, leafst sûnder oerabonnemint, sadat pakketten net ferlern gean troch oerlêst.
- Stypjen fan ECMP is in yntegraal diel fan 'e stof.
- Kin QoS leverje, ynklusyf lestige dingen lykas ECN.
- It stypjen fan NETCONF is in stifting foar de takomst.
Ik wijd hjir heul min tiid oan it wurk fan it Underlay-netwurk sels. Dit is om't ik letter yn 'e searje derop sil konsintrearje, en wy sille allinich Overlay yn it foarbygean oanreitsje.
Fansels behein ik ús allegear serieus troch as foarbyld in DC-netwurk te brûken boud yn in Cloz-fabryk mei pure IP-routing en in overlay fan 'e host.
Ik bin lykwols wis dat elk netwurk dat in ûntwerp hat yn formele termen beskreaun en automatisearre wurde kin. It is gewoan dat myn doel hjir is om oanpak fan automatisearring te begripen, en net elkenien te betiizjen troch it probleem yn in algemiene foarm op te lossen.
As ûnderdiel fan ADSM binne Roman Gorge en ik fan plan om in apart probleem te publisearjen oer de virtualisaasje fan kompjûterkrêft en har ynteraksje mei netwurkvirtualisaasje. Bliuw yn kontakt.
Nuttige keppelings
- .
- . 6 oeren oer Yandex.Cloud, dy't ek it firtuele netwurk op TF beslacht.
- .
- . It praat oer it heule DC-netwurk, ynklusyf Underlay, Overlay, oanpak foar multi-homing en behear.
Dankewol
- - earder gasthear fan de linkmeup podcast en no in ekspert op it mêd fan wolkplatfoarms. Foar opmerkings en bewurkings. No, wy wachtsje op syn mear yngeande artikel oer virtualisaasje yn 'e heine takomst.
- - myn kollega en ekspert op it mêd fan firtuele netwurkûntwikkeling. Foar opmerkings en bewurkings.
- - myn kollega en ekspert op it mêd fan Tungsten Fabric. Foar opmerkings en bewurkings.
- - yllustrator linkmeup. Foar KDPV.
- Alexander Limonov. Foar de "automato" meme.
Boarne: www.habr.com