В antaŭa numero Mi priskribis la retan aŭtomatigan kadron. Laŭ iuj homoj, eĉ ĉi tiu unua alproksimiĝo al la problemo jam solvis kelkajn demandojn. Kaj ĉi tio tre ĝojigas min, ĉar nia celo en la ciklo estas ne kovri la Ansible per Python-skriptoj, sed konstrui sistemon.

La sama kadro fiksas la ordon en kiu ni traktos la demandon.
Kaj retvirtualigo, al kiu ĉi tiu numero estas dediĉita, ne precipe taŭgas en la ADSM-temo, kie ni analizas aŭtomatigon.

Sed ni rigardu ĝin el alia angulo.

Multaj servoj uzas la saman reton dum longa tempo. En la kazo de teleentreprenisto, ĉi tio estas ekzemple 2G, 3G, LTE, larĝa bando kaj B2B. En la kazo de PK: konektebleco por malsamaj klientoj, Interreto, bloka stokado, objektostokado.

Kaj ĉiuj servoj postulas izolitecon unu de la alia. Tiel aperis supermetitaj retoj.

Kaj ĉiuj servoj ne volas atendi ke persono agordu ilin permane. Tiel aperis orkestrantoj kaj SDN.

La unua aliro al sistema aŭtomatigo de la reto, aŭ pli ĝuste parto de ĝi, estas delonge prenita kaj efektivigita en multaj lokoj: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Jen kion ni traktos hodiaŭ.

Enhavo

• kialoj
• Terminologio
• Underlay - fizika reto
• Overlay - virtuala reto
  • Tegu per ToR
  • Tegu de gastiganto
  • Uzante Tungsten Fabric kiel ekzemplon
    • Komunikado ene de ununura fizika maŝino
    • Komunikado inter VM-oj situantaj sur malsamaj fizikaj maŝinoj
    • Eliro al la ekstera mondo

• Oftaj Demandoj
• konkludo
• utilaj ligoj

kialoj

Kaj ĉar ni parolas pri ĉi tio, indas mencii la antaŭkondiĉojn por reto virtualigo. Fakte, ĉi tiu procezo ne komenciĝis hieraŭ.

Vi verŝajne aŭdis pli ol unu fojon, ke la reto ĉiam estis la plej inerta parto de iu ajn sistemo. Kaj ĉi tio estas vera en ĉiu signifo. La reto estas la bazo sur kiu ĉio ripozas, kaj fari ŝanĝojn sur ĝi estas sufiĉe malfacila - servoj ne toleras ĝin kiam la reto estas malfunkcia. Ofte, malmendinta ununuran nodon povas forigi grandan parton de aplikoj kaj efiki multajn klientojn. Pro tio parte la reta teamo povas rezisti ajnan ŝanĝon - ĉar nun ĝi iel funkcias (ni eble eĉ ne scias kiel), sed ĉi tie vi devas agordi ion novan, kaj oni ne scias, kiel ĝi influos la reton.

Por ne atendi, ke retoj enigu VLAN-ojn kaj ne registri iujn servojn sur ĉiu reta nodo, homoj elpensis la ideon uzi superkovraĵojn - overlay retojn - el kiuj estas granda vario: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ktp.

Ilia allogo kuŝas en du simplaj aferoj:

• Nur finnodoj estas agorditaj - transitnodoj ne bezonas esti tuŝitaj. Ĉi tio signife plirapidigas la procezon, kaj foje permesas vin tute ekskludi la retan infrastrukturan fakon de la procezo de enkonduko de novaj servoj.
• La ŝarĝo estas kaŝita profunde en la kaplinioj - transitnodoj ne bezonas scii ion pri ĝi, pri adreso sur la gastigantoj, aŭ pri la itineroj de la superkovra reto. Ĉi tio signifas, ke vi devas konservi malpli da informoj en tabeloj, kio signifas uzi pli simplan/malkaran aparaton.

En ĉi tiu ne tute plentaŭga temo, mi ne planas analizi ĉiujn eblajn teknologiojn, sed prefere priskribi la kadron por la funkciado de supermetitaj retoj en DC-oj.

La tuta serio priskribos datumcentron konsistantan el vicoj da identaj rakoj en kiuj la sama servila ekipaĵo estas instalita.

Ĉi tiu ekipaĵo funkcias virtualajn maŝinojn/ujojn/senservilojn, kiuj efektivigas servojn.

Terminologio

En buklo servilo Mi nomos programon kiu efektivigas la servilan flankon de kliento-servila komunikado.

Fizikaj maŝinoj en rako estas nomitaj serviloj ne ni faros.

Fizika maŝino — komputilo x86 instalita en rako. La plej ofte uzata termino gastiganto. Tiel ni nomos ĝin "машина"aŭ gastiganto.

Hypervisor - aplikaĵo funkcianta sur fizika maŝino, kiu imitas la fizikajn rimedojn, sur kiuj funkcias Virtualaj Maŝinoj. Foje en literaturo kaj interreto la vorto "hipervisor" estas uzata kiel sinonimo de "gastiganto".

Virtuala maŝino - operaciumo funkcianta sur fizika maŝino super hiperviziero. Por ni en ĉi tiu ciklo, ne vere gravas ĉu ĝi estas fakte virtuala maŝino aŭ nur ujo. Ni nomu ĝin "VM«

Luanto estas larĝa koncepto, kiun mi difinos en ĉi tiu artikolo kiel apartan servon aŭ apartan klienton.

Plur-luado aŭ plurtenado - la uzo de la sama aplikaĵo fare de malsamaj klientoj/servoj. Samtempe, izolado de klientoj unu de la alia estas atingita danke al la aplikaĵa arkitekturo, kaj ne per aparte kurantaj petskriboj.

ToR — Supro de la Rack-ŝaltilo - ŝaltilo instalita en rako, al kiu ĉiuj fizikaj maŝinoj estas konektitaj.

Krom la ToR-topologio, diversaj provizantoj praktikas End of Row (EoR) aŭ Middle of Row (kvankam ĉi-lasta estas malestima maloftaĵo kaj mi ne vidis la MoR-mallongigon).

Submeta reto aŭ la subesta reto aŭ subtavolo estas la fizika reto-infrastrukturo: ŝaltiloj, enkursigiloj, kabloj.

Overlay reto aŭ overlay network aŭ overlay - virtuala reto de tuneloj kurantaj super la fizika.

L3-ŝtofo aŭ IP-ŝtofo - mirinda invento de la homaro, kiu ebligas al vi eviti ripeti STP kaj lerni TRILL por intervjuoj. Koncepto en kiu la tuta reto ĝis la alirnivelo estas ekskluzive L3, sen VLAN-oj kaj, sekve, grandegaj etenditaj elsendaj domajnoj. Ni rigardos de kie venas la vorto "fabriko" en la sekva parto.

SDN - Programaro Difinita Reto. Apenaŭ bezonas enkondukon. Aliro al retadministrado kie ŝanĝoj al la reto estas faritaj ne de persono, sed de programo. Kutime signifas movi la Kontrolaviadilon preter la finaj retaj aparatoj al la regilo.

NFV — Reta Funkcia Virtualigo — virtualigo de retaj aparatoj, sugestante, ke iuj retaj funkcioj povas esti rulitaj en la formo de virtualaj maŝinoj aŭ ujoj por akceli la efektivigon de novaj servoj, organizi Servoĉenadon kaj pli simplan horizontalan skaleblon.

VNF - Virtuala Reta Funkcio. Specifa virtuala aparato: enkursigilo, ŝaltilo, fajroŝirmilo, NAT, IPS/IDS, ktp.

Mi nun intence simpligas la priskribon al specifa efektivigo, por ne tro konfuzi la leganton. Por pli pripensa legado, mi raportas lin al la sekcio referencoj. Krome, Roma Gorge, kiu kritikas ĉi tiun artikolon pro malprecizecoj, promesas skribi apartan numeron pri serviloj kaj retaj virtualaj teknologioj, pli profunde kaj atentema al detaloj.

Plej multaj retoj hodiaŭ povas esti klare dividitaj en du partojn:

Subkovro — fizika reto kun stabila agordo.
tegu — abstraktado super Underlay por izolado de luantoj.

Tio validas kaj por la kazo de DC (kiun ni analizos en ĉi tiu artikolo) kaj por ISP (kiun ni ne analizos, ĉar ĝi jam estis SDSM). Kun entreprenaj retoj, kompreneble, la situacio estas iom malsama.

Bildo kun fokuso sur la reto:

Subkovro

Underlay estas fizika reto: aparataj ŝaltiloj kaj kabloj. Aparatoj en la subtera scias kiel atingi fizikajn maŝinojn.

Ĝi dependas de normaj protokoloj kaj teknologioj. Ne laste ĉar hardvaraparatoj ĝis hodiaŭ funkcias per proprieta softvaro kiu ne permesas aŭ programi la peceton aŭ efektivigi siajn proprajn protokolojn; sekve, kongruo kun aliaj vendistoj kaj normigado estas necesaj.

Sed iu kiel Guglo povas pagi evoluigi siajn proprajn ŝaltilojn kaj forlasi ĝenerale akceptitajn protokolojn. Sed LAN_DC ne estas Guglo.

Subtagaĵo ŝanĝiĝas relative malofte ĉar ĝia laboro estas baza IP-konektebleco inter fizikaj maŝinoj. Underlay nenion scias pri la servoj, klientoj aŭ luantoj, kiuj funkcias sur ĝi - ĝi nur bezonas liveri la pakaĵon de unu maŝino al alia.
Submetaĵo povus esti tia:

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

La Underlay-reto estas agordita laŭ la klasika maniero: CLI/GUI/NETCONF.

Mane, skriptoj, proprietaj utilecoj.

La sekva artikolo en la serio estos dediĉita al la subtavolo pli detale.

tegu

Overlay estas virtuala reto de tuneloj etenditaj supre de Underlay, ĝi permesas al VM-oj de unu kliento komuniki unu kun la alia, dum ili provizas izolitecon de aliaj klientoj.

La klientdatenoj estas enkapsuligitaj en kelkaj tunelaj kaplinioj por dissendo tra la publika reto.

Do VMs de unu kliento (unu servo) povas komuniki unu kun la alia per Overlay, eĉ sen scii kian vojon efektive prenas la pakaĵo.

Overlay povus esti, ekzemple, kiel mi menciis supre:

• GRE tunelo
• VXLAN
• EVPN
• L3VPN
• GENEVE

Superkovra reto estas tipe agordita kaj konservita tra centra regilo. De ĝi, la agordo, Kontrola Aviadilo kaj Datuma Aviadilo estas liveritaj al aparatoj kiuj direktas kaj enkapsuligas klienttrafikon. Iom sube Ni rigardu ĉi tion kun ekzemploj.

Jes, ĉi tio estas SDN en sia plej pura formo.

Ekzistas du fundamente malsamaj aliroj al organizado de Overlay-reto:

1. Tegu per ToR
2. Tegu de gastiganto

Tegu per ToR

Overlay povas komenci ĉe la alirŝaltilo (ToR) staranta en la rako, kiel okazas, ekzemple, en la kazo de VXLAN-ŝtofo.

Ĉi tio estas tempelprovita mekanismo sur ISP-retoj kaj ĉiuj retaj ekipaĵoj subtenas ĝin.

Tamen, en ĉi tiu kazo, la ToR-ŝaltilo devas povi apartigi la diversajn servojn, respektive, kaj la retadministranto devas, certagrade, kunlabori kun la virtualaj maŝinadministrantoj kaj fari ŝanĝojn (kvankam aŭtomate) al la agordo de la aparatoj. .

Ĉi tie mi raportos la leganton al artikolo pri VxLAN sur Habré nia malnova amiko @bormoglotx.
En tio ĉi prezentoj kun ENOG aliroj al konstruado de DC-reto kun EVPN VXLAN-ŝtofo estas priskribitaj detale.

Kaj por pli kompleta mergo en la realo, vi povas legi la libron de Tsiska Moderna, Malferma kaj Skalebla Ŝtofo: VXLAN EVPN.

Mi rimarkas, ke VXLAN estas nur enkapsuliga metodo kaj ĉesigo de tuneloj povas okazi ne sur ToR, sed sur la gastiganto, kiel okazas en la kazo de OpenStack, ekzemple.

Tamen, VXLAN-ŝtofo, kie la tegaĵo komenciĝas ĉe ToR, estas unu el la establitaj tegmentaj retdezajnoj.

Tegu de gastiganto

Alia aliro estas komenci kaj fini tunelojn sur la finaj gastigantoj.
En ĉi tiu kazo, la reto (Underlay) restas kiel eble plej simpla kaj statika.
Kaj la gastiganto mem faras la tutan necesan enkapsuligon.

Ĉi tio kompreneble postulos ruli specialan aplikaĵon sur la gastigantoj, sed ĝi valoras ĝin.

Unue, ruli klienton sur Linukso-maŝino estas pli facila aŭ, ni diru, eĉ ebla, dum sur ŝaltilo vi plej verŝajne devos turni sin al proprietaj SDN-solvoj, kio mortigas la ideon de plurvendisto.

Due, la ToR-ŝaltilo en ĉi tiu kazo povas esti lasita kiel eble plej simpla, ambaŭ de la vidpunkto de la Kontrola Ebeno kaj la Datuma Ebeno. Efektive, tiam ĝi ne bezonas komuniki kun la SDN-regilo, kaj ĝi ankaŭ ne bezonas stoki la retojn/ARP-ojn de ĉiuj konektitaj klientoj - sufiĉas scii la IP-adreson de la fizika maŝino, kio multe simpligas la ŝanĝadon/ vojtabloj.

En la serio ADSM, mi elektas la tegmentan aliron de la gastiganto - tiam ni nur parolas pri ĝi kaj ni ne revenos al la VXLAN-fabriko.

Estas plej facile rigardi ekzemplojn. Kaj kiel provon ni prenos la OpenSource SDN-platformon OpenContrail, nun konata kiel Tungsteno Ŝtofo.

Fine de la artikolo mi donos kelkajn pensojn pri la analogio kun OpenFlow kaj OpenvSwitch.

Uzante Tungsten Fabric kiel ekzemplon

Ĉiu fizika maŝino havas vRouter - virtuala enkursigilo, kiu scias pri la retoj konektitaj al ĝi kaj al kiuj klientoj ili apartenas - esence PE-enkursigilo. Por ĉiu kliento, ĝi konservas izolitan vojigtabelon (legu VRF). Kaj vRouter efektive faras Overlay-tuneladon.

Iom pli pri vRouter estas ĉe la fino de la artikolo.

Ĉiu VM situanta sur la hiperviziero estas konektita al la vRouter de ĉi tiu maŝino pere TAP-interfaco.

TAP - Terminal Access Point - virtuala interfaco en la Linukso-kerno kiu permesas retan interagon.

Se estas pluraj retoj malantaŭ la vRouter, tiam virtuala interfaco estas kreita por ĉiu el ili, al kiu IP-adreso estas asignita - ĝi estos la defaŭlta enirejo-adreso.
Ĉiuj retoj de unu kliento estas metitaj en unu VRF (one table), different ones - into different ones.
Mi faros malrespondecon ĉi tie, ke ne ĉio estas tiel simpla, kaj mi sendos la scivoleman leganton al la fino de la artikolo..

Por ke vRouters povas komuniki unu kun la alia, kaj sekve la VM-oj situantaj malantaŭ ili, ili interŝanĝas vojinformojn per SDN-regilo.

Por eliri en la eksteran mondon, estas elirpunkto de la matrico - virtuala reto-pordejo VNGW — Virtuala Reta Enirejo (mia termino).

Nun ni rigardu ekzemplojn de komunikado - kaj estos klareco.

Komunikado ene de ununura fizika maŝino

VM0 volas sendi pakaĵon al VM2. Ni supozu nuntempe, ke ĉi tio estas ununura klienta VM.

Datuma Aviadilo

1. VM-0 havas defaŭltan itineron al sia eth0-interfaco. La pakaĵo estas sendita tien.
   Ĉi tiu interfaco eth0 estas fakte konektita preskaŭ al la virtuala enkursigilo vRouter per la TAP-interfaco tap0.
2. vRouter analizas al kiu interfaco venis la pakaĵo, tio estas, al kiu kliento (VRF) ĝi apartenas, kaj kontrolas la adreson de la ricevanto kun la vojtabelo de ĉi tiu kliento.
3. Detektante, ke la ricevanto sur la sama maŝino estas sur malsama haveno, vRouter simple sendas la pakaĵon al ĝi sen aldonaj kaplinioj - por ĉi tiu kazo, vRouter jam havas ARP-rekordon.

En ĉi tiu kazo, la pako ne eniras la fizikan reton - ĝi estas direktita ene de la vRouter.

Kontrola Ebeno

Kiam la virtuala maŝino komenciĝas, la hiperviziero diras al ĝi:

• Ŝia propra IP-adreso.
• La defaŭlta itinero estas tra la IP-adreso de la vRouter en ĉi tiu reto.

La hiperviziero raportas al vRouter per speciala API:

• Kion vi bezonas por krei virtualan interfacon.
• Kian virtualan reton ĝi (VM) bezonas krei?
• Al kiu VRF (VN) ligi ĝin.
• Senmoka ARP-eniro por ĉi tiu VM - kiu interfaco estas malantaŭ sia IP-adreso kaj al kiu MAC-adreso ĝi estas asociita.

Denove, la fakta interaga proceduro estas simpligita por kompreni la koncepton.

Tiel, vRouter vidas ĉiujn VMs de unu kliento sur antaŭfiksita maŝino kiel rekte ligitaj retoj kaj povas direkti inter ili mem.

Sed VM0 kaj VM1 apartenas al malsamaj klientoj kaj, sekve, estas en malsamaj vRouter-tabloj.

Ĉu ili povas komuniki inter si rekte dependas de la agordoj de vRouter kaj reto-dezajno.
Ekzemple, se ambaŭ klientoj VMs uzas publikajn adresojn, aŭ NAT okazas sur la vRouter mem, tiam rekta vojigo al la vRouter povas esti farita.

En la kontraŭa situacio, eblas transiri adresspacojn - vi devas trairi NAT-servilon por ricevi publikan adreson - tio similas al aliro al eksteraj retoj, kiuj estas diskutitaj sube.

Komunikado inter VM-oj situantaj sur malsamaj fizikaj maŝinoj

Datuma Aviadilo

1. La komenco estas ekzakte la sama: VM-0 sendas paketon kun la celo VM-7 (172.17.3.2) defaŭlte.
2. vRouter ricevas ĝin kaj ĉi-foje vidas, ke la celo estas sur malsama maŝino kaj estas alirebla per Tunnel0.
3. Unue, ĝi pendigas MPLS-etikedon identigantan la foran interfacon, tiel ke sur la dorsa flanko vRouter povas determini kie meti ĉi tiun pakaĵeton sen pliaj serĉoj.

   

4. Tunnel0 havas fonton 10.0.0.2, celon: 10.0.1.2.
   vRouter aldonas GRE (aŭ UDP) titolojn kaj novan IP al la originala pako.
5. La vRouter-vojigtabelo havas defaŭltan itineron tra la ToR1-adreso 10.0.0.1. Tie li sendas ĝin.

   
   

6. ToR1, kiel membro de la Underlay-reto, scias (ekzemple, per OSPF) kiel atingi 10.0.1.2 kaj sendas la pakaĵon laŭ la itinero. Notu, ke ECMP estas ebligita ĉi tie. Estas du nexthops en la ilustraĵo, kaj malsamaj fadenoj estos ordigitaj en ili per haŝiŝo. En la kazo de vera fabriko, estos pli verŝajne 4 venontaj saltoj.

   Samtempe, li ne bezonas scii kio estas sub la ekstera IP-kapo. Tio estas, fakte, sub IP povas esti sandviĉo de IPv6 super MPLS super Ethernet super MPLS super GRE super super greka.

7. Sekve, ĉe la riceva flanko, vRouter forigas GRE kaj, uzante la MPLS-etikedon, komprenas al kiu interfaco ĉi tiu pako devas esti sendita, nudigas ĝin kaj sendas ĝin en sia originala formo al la ricevanto.

Kontrola Ebeno

Kiam vi ekfunkciigas la aŭton, okazas la sama afero kiel priskribite supre.

Kaj krome la jenaj:

• Por ĉiu kliento, vRouter asignas MPLS-etikedon. Ĉi tio estas la serva etikedo L3VPN, per kiu klientoj estos apartigitaj ene de la sama fizika maŝino.
  

  Fakte, la etikedo MPLS ĉiam estas asignita senkondiĉe de la vRouter - finfine oni ne scias anticipe, ke la maŝino nur interagos kun aliaj maŝinoj malantaŭ la sama vRouter kaj tio plej verŝajne eĉ ne veras.

• vRouter establas konekton kun la SDN-regilo uzante la BGP-protokolon (aŭ similan al ĝi - en la kazo de TF, ĉi tio estas XMPP 0_o).
• Tra ĉi tiu sesio, vRouter raportas itinerojn al konektitaj retoj al la SDN-regilo:
  • Reta adreso
  • Enkapsuliga metodo (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-kliento-etikedo
  • Via IP-adreso kiel nexthop

• La SDN-regilo ricevas tiajn itinerojn de ĉiuj konektitaj vRouters kaj reflektas ilin al aliaj. Tio estas, ĝi funkcias kiel Route Reflector.

La sama afero okazas en la kontraŭa direkto.

Overlay povas ŝanĝi almenaŭ ĉiun minuton. Ĉi tio estas proksimume kio okazas en publikaj nuboj, kie klientoj regule komencas kaj malŝaltas siajn virtualajn maŝinojn.

La centra regilo prizorgas la tutan kompleksecon de konservado de la agordo kaj monitorado de la ŝalti/vojaj tabloj sur la vRouter.

Malglate parolante, la regilo komunikas kun ĉiuj vRouters per BGP (aŭ simila protokolo) kaj simple elsendas vojinformojn. BGP, ekzemple, jam havas Adreso-Familion por transdoni la enkapsulan metodon MPLS-en-GRE aŭ MPLS-en-UDP.

Samtempe, la agordo de la Underlay-reto neniel ŝanĝiĝas, kio, cetere, estas multe pli malfacile aŭtomatigebla kaj pli facile rompi kun mallerta movado.

Eliro al la ekstera mondo

Ie la simulado devas finiĝi, kaj vi devas eliri la virtualan mondon en la realan. Kaj vi bezonas pagtelefonan enirejon.

Du aliroj estas praktikataj:

1. Hardvara enkursigilo estas instalita.
2. Iu aparato estas lanĉita, kiu efektivigas la funkciojn de enkursigilo (jes, sekvante SDN, ni ankaŭ renkontis VNF). Ni nomu ĝin virtuala enirejo.

La avantaĝo de la dua aliro estas malmultekosta horizontala skaleblo - ne estas sufiĉe da potenco - ni lanĉis alian virtualan maŝinon kun enirejo. En iu ajn fizika maŝino, sen devi serĉi senpagajn rakojn, unuojn, potencon, aĉeti la aparataron mem, transporti ĝin, instali ĝin, ŝanĝi ĝin, agordi ĝin, kaj poste ankaŭ ŝanĝi misajn komponantojn en ĝi.

La malavantaĝoj de virtuala enirejo estas ke unuo de fizika enkursigilo daŭre estas ordoj de grandeco pli potenca ol plurkerna virtuala maŝino, kaj ĝia programaro, adaptita al sia propra aparatara bazo, funkcias multe pli stabile (neniu). Estas ankaŭ malfacile nei la fakton, ke la aparataro kaj programaro komplekso simple funkcias, postulante nur agordon, dum lanĉi kaj konservi virtualan enirejon estas tasko por fortaj inĝenieroj.

Per unu piedo, la enirejo rigardas en la virtualan reton Overlay, kiel regula Virtuala Maŝino, kaj povas interagi kun ĉiuj aliaj VM-oj. Samtempe, ĝi povas ĉesigi la retojn de ĉiuj klientoj kaj, sekve, efektivigi vojigon inter ili.

Per sia alia piedo, la enirejo rigardas en la spinan reton kaj scias kiel eniri la Interreton.

Datuma Aviadilo

Tio estas, la procezo aspektas jene:

1. VM-0, defaŭlte al la sama vRouter, sendas paketon kun celloko en la ekstera mondo (185.147.83.177) al la interfaco eth0.
2. vRouter ricevas ĉi tiun pakaĵon kaj serĉas la cel-adreson en la vojtabelo - trovas la defaŭltan itineron tra la VNGW1-enirejo tra Tunelo 1.
   Li ankaŭ vidas, ke ĉi tio estas GRE-tunelo kun SIP 10.0.0.2 kaj DIP 10.0.255.2, kaj li ankaŭ bezonas unue ligi la MPLS-etikedon de ĉi tiu kliento, kiun VNGW1 atendas.
3. vRouter pakas la komencan pakaĵon kun MPLS, GRE kaj novaj IP-kapoj kaj sendas ĝin al ToR1 10.0.0.1 defaŭlte.
4. La subesta reto liveras la pakaĵon al la enirejo VNGW1.
5. La VNGW1-enirejo forigas la GRE- kaj MPLS-tunelajn kapliniojn, vidas la cel-adreson, konsultas sian vojigtabelon kaj komprenas, ke ĝi estas direktita al la Interreto - tio estas, tra Plena Vido aŭ Defaŭlta. Se necese, plenumas NAT-tradukon.
6. Povus ekzisti regula IP-reto de VNGW ĝis la limo, kio estas neverŝajna.
   Povas ekzisti klasika MPLS-reto (IGP+LDP/RSVP TE), povas ekzisti malantaŭa ŝtofo kun BGP LU aŭ GRE-tunelo de VNGW ĝis la limo per IP-reto.
   Estu kiel ajn, VNGW1 elfaras la necesajn enkapsulaĵojn kaj sendas la komencan pakaĵon al la limo.

Trafiko en la kontraŭa direkto iras tra la samaj paŝoj en la kontraŭa ordo.

1. La limo faligas la pakaĵon al VNGW1
2. Li senvestigas lin, rigardas la adreson de la ricevanto kaj vidas, ke li estas alirebla per la tunelo Tunnel1 (MPLSoGRE aŭ MPLSoUDP).
3. Sekve, ĝi aldonas MPLS-etikedon, GRE/UDP-kapon kaj novan IP kaj sendas ĝin al sia ToR3 10.0.255.1.
   La tunela cel-adreso estas la IP-adreso de la vRouter malantaŭ kiu la cela VM situas - 10.0.0.2.
4. La subesta reto liveras la pakaĵon al la dezirata vRouter.
5. La celo vRouter legas GRE/UDP, identigas la interfacon uzante la MPLS-etikedon kaj sendas nudan IP-pakaĵeton al sia TAP-interfaco asociita kun eth0 de la VM.

Kontrola Ebeno

VNGW1 establas BGP-najbarecon kun SDN-regilo, de kiu ĝi ricevas ĉiujn vojinformojn pri klientoj: kiu IP-adreso (vRouter) estas malantaŭ kiu kliento, kaj per kiu MPLS-etikedo ĝi estas identigita.

Simile, li mem informas la SDN-regilon pri la defaŭlta itinero kun la etikedo de ĉi tiu kliento, indikante sin kiel la sekva salto. Kaj tiam ĉi tiu defaŭlto alvenas ĉe vRouters.

Sur VNGW, itineragregado aŭ NAT-traduko kutime okazas.

Kaj en la alia direkto, ĝi sendas ĝuste ĉi tiun kunigitan itineron al la sesio kun limoj aŭ Itineraj Reflectors. Kaj de ili ĝi ricevas la defaŭltan itineron aŭ Full-View, aŭ ion alian.

Koncerne enkapsuligon kaj trafikinterŝanĝon, VNGW ne diferencas de vRouter.
Se vi iomete pligrandigas la amplekson, tiam vi povas aldoni aliajn retajn aparatojn al VNGW-oj kaj vRouters, kiel fajroŝirmiloj, trafikpurigado aŭ riĉigaj bienoj, IPS, ktp.

Kaj kun la helpo de sinsekva kreado de VRF-oj kaj ĝusta anonco de itineroj, vi povas devigi trafikon al buklo kiel vi volas, kiu nomiĝas Servoĉenado.

Tio estas, ankaŭ ĉi tie la SDN-regilo funkcias kiel Itinero-Reflector inter VNGW-oj, vRouters kaj aliaj retaj aparatoj.

Sed fakte, la regilo ankaŭ publikigas informojn pri ACL kaj PBR (Policy Based Routing), kaŭzante individuajn trafikfluojn iri malsame ol la itinero diras al ili.

Oftaj Demandoj

Kial vi daŭre faras la rimarkon de GRE/UDP?

Nu, ĝenerale, oni povas diri, ke ĉi tio estas specifa por Tungsten Fabric - vi tute ne devas konsideri ĝin.

Sed se ni prenas ĝin, TF mem, kvankam ankoraŭ OpenContrail, subtenis ambaŭ enkapsulaĵojn: MPLS en GRE kaj MPLS en UDP.

UDP estas bona ĉar en la Fonta Haveno estas tre facile kodi hash-funkcion de la originala IP+Proto+Port en ĝia kaplinio, kio permesos al vi fari ekvilibron.

En la kazo de GRE, ve, ekzistas nur eksteraj IP kaj GRE-kapoj, kiuj estas la samaj por ĉiu enkapsuligita trafiko kaj oni ne parolas pri ekvilibro - malmultaj homoj povas rigardi tiel profunde en la pako.

Ĝis iom da tempo, enkursigiloj, se ili sciis uzi dinamikajn tunelojn, faris tion nur en MPLSoGRE, kaj nur tre lastatempe ili lernis uzi MPLSoUDP. Tial, ni ĉiam devas fari noton pri la ebleco de du malsamaj enkapsulaĵoj.

En justeco, indas noti, ke TF plene subtenas L2-konektecon uzante VXLAN.

Vi promesis fari paralelojn kun OpenFlow.
Ili vere petas ĝin. vSwitch en la sama OpenStack faras tre similajn aferojn, uzante VXLAN, kiu, cetere, ankaŭ havas UDP-kapon.

En la Datenplano ili funkcias proksimume same; la Kontrolebeno signife malsamas. Tungsten Fabric uzas XMPP por liveri vojinformojn al vRouter, dum OpenStack funkcias Openflow.

Ĉu vi povas diri al mi iom pli pri vRouter?
Ĝi estas dividita en du partojn: vRouter Agent kaj vRouter Forwarder.

La unua funkcias en la Uzanto-Spaco de la gastiga OS kaj komunikas kun la SDN-regilo, interŝanĝante informojn pri itineroj, VRF-oj kaj ACL-oj.

La dua efektivigas Data Plane - kutime en Kernel-Spaco, sed ankaŭ povas funkcii per SmartNICs - retaj kartoj kun CPU kaj aparta programebla ŝaltila blato, kiu ebligas forigi la ŝarĝon de la CPU de la gastiga maŝino, kaj fari la reton pli rapida kaj pli. antaŭvidebla.

Alia ebla scenaro estas ke vRouter estas DPDK-aplikaĵo en Uzantspaco.

vRouter Agent sendas agordojn al vRouter Forwarder.

Kio estas Virtuala Reto?
Mi menciis komence de la artikolo pri VRF, ke ĉiu luanto estas ligita al sia propra VRF. Kaj se tio sufiĉis por supraĵa kompreno de la funkciado de la superkovra reto, tiam ĉe la sekva ripeto necesas fari klarigojn.

Tipe, en virtualigmekanismoj, la Virtuala Reto ento (vi povas konsideri tion propra substantivo) estas enkondukita aparte de klientoj/luantoj/virtualaj maŝinoj - tute sendependa afero. Kaj ĉi tiu Virtuala Reto jam povas esti konektita per interfacoj al unu luanto, al alia, al du, aŭ ie ajn. Do, ekzemple, Servoĉenado estas efektivigita kiam trafiko devas esti pasita tra certaj nodoj en la postulata sekvenco, simple kreante kaj konektante Virtualajn Retojn en la ĝusta sekvenco.

Tial, kiel tia, ne ekzistas rekta korespondado inter la Virtuala Reto kaj la luanto.

konkludo

Ĉi tio estas tre supraĵa priskribo de la funkciado de virtuala reto kun superkovraĵo de la gastiganto kaj SDN-regilo. Sed negrave kian virtualigplatformon vi elektas hodiaŭ, ĝi funkcios en simila maniero, ĉu ĝi estas VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric aŭ Juniper Contrail. Ili diferencas en la specoj de enkapsulaĵoj kaj kaplinioj, protokoloj por liverado de informoj al finaj retaj aparatoj, sed la principo de programar-agordebla surmeta reto laboranta sur relative simpla kaj senmova submeta reto restos la sama.
Ni povas diri, ke hodiaŭ SDN bazita sur overlay reto gajnis la kampon de kreado de privata nubo. Tamen tio ne signifas, ke Openflow ne havas lokon en la moderna mondo - ĝi estas uzata en OpenStacke kaj en la sama VMWare NSX, laŭ mia scio, Guglo uzas ĝin por starigi la subteran reton.

Malsupre mi disponigis ligilojn al pli detalaj materialoj se vi volas studi la aferon pli profunde.

Kaj kio pri nia Underlay?

Sed ĝenerale, nenio. Li ne ŝanĝis la tutan vojon. Ĉio, kion li devas fari en la kazo de superkovraĵo de la gastiganto, estas ĝisdatigi itinerojn kaj ARP-ojn kiam vRouter/VNGW aperas kaj malaperas kaj portas pakaĵojn inter ili.

Ni formulu liston de postuloj por la Underlay-reto.

1. Estu kapabla uzi iun specon de vojprotokolo, en nia situacio - BGP.
2. Havu larĝan bendolarĝon, prefere sen troabono, por ke pakaĵoj ne perdiĝu pro troŝarĝoj.
3. Subteni ECMP estas integra parto de la ŝtofo.
4. Povu provizi QoS, inkluzive de malfacilaj aferoj kiel ECN.
5. Subteni NETCONF estas fundamento por la estonteco.

Mi dediĉis tre malmulte da tempo ĉi tie al la laboro de la Underlay reto mem. Ĉi tio estas ĉar poste en la serio mi koncentriĝos pri ĝi, kaj ni nur preterpase tuŝos Overlay.

Evidente, mi severe limigas nin ĉiujn uzante kiel ekzemplon DC-reton konstruitan en Cloz-fabriko kun pura IP-vojigo kaj superkovraĵo de la gastiganto.

Tamen mi certas, ke ĉiu reto, kiu havas dezajnon, povas esti priskribita en formalaj terminoj kaj aŭtomatigita. Estas nur, ke mia celo ĉi tie estas kompreni alirojn al aŭtomatigo, kaj ne konfuzi ĉiujn solvante la problemon en ĝenerala formo.

Kadre de ADSM, Roman Gorge kaj mi planas publikigi apartan numeron pri la virtualigo de komputika potenco kaj ĝia interago kun reto-virtualigo. Daŭrigi la kontakton.

utilaj ligoj

• Tungsteno-Ŝtofo Arkitekturo.
• pri:nubo. 6 horoj pri Yandex.Cloud, kiu ankaŭ kovras la virtualan reton en TF.
• Kio Estas Open vSwitch?
• Enkonduko al VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Kadro por Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.
  
• Scaleway alproksimiĝo al VXLAN EVPN Fabric. Ĝi parolas pri la tuta DC-reto, inkluzive de Underlay, Overlay, aliroj al multi-homing kaj administrado.

Dankon

• Roman Gorga - iama gastiganto de la podkasto linkmeup kaj nun spertulo pri la kampo de nubaj platformoj. Por komentoj kaj redaktoj. Nu, ni atendas lian pli profundan artikolon pri virtualigo baldaŭ.
• Aleksandro Ŝalimov - mia kolego kaj fakulo en la kampo de virtuala reto-disvolviĝo. Por komentoj kaj redaktoj.
• Valentin Sinitsyn - mia kolego kaj fakulo pri la fako de Tungsteno-Ŝtofo. Por komentoj kaj redaktoj.
• Artjom Ĉernobajo - ilustristo linkmeup. Por KDPV.
• Aleksandro Limonov. Por la "aŭtomata" memeo.

fonto: www.habr.com