В aurreko alea Sarearen automatizazio esparrua deskribatu nuen. Zenbaiten ustez, arazoaren lehen hurbilketa honek ere galdera batzuk konpondu ditu jada. Eta horrek asko pozten nau, zikloan gure helburua ez baita Ansible Python scriptekin estaltzea, sistema bat eraikitzea baizik.

Esparru berberak ezartzen du zein ordena landuko dugun galdera.
Eta ale hau dedikatzen den sare birtualizazioa ez dator bat bereziki ADSM gaian, non automatizazioa aztertzen dugun.

Baina ikus dezagun beste angelu batetik.

Zerbitzu askok sare bera erabiltzen dute aspalditik. Telekomunikazio-operadore baten kasuan, hau da 2G, 3G, LTE, banda zabala eta B2B, adibidez. DC baten kasuan: bezero ezberdinentzako konektibitatea, Internet, blokeen biltegiratzea, objektuen biltegiratzea.

Eta zerbitzu guztiek elkarrengandik isolatzea eskatzen dute. Honela agertu ziren gainjarritako sareak.

Eta zerbitzu guztiek ez dute itxaron nahi pertsona batek eskuz konfiguratzeko. Horrela agertu ziren orkestratzaileak eta SDN.

Sarearen automatizazio sistematikorako lehen hurbilketa, edo hobeto esanda, haren zati bat, aspalditik hartu eta ezarri da leku askotan: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Hori da gaur jorratuko duguna.

Edukia

• arrazoi
• terminologia
• Azpikoa - sare fisikoa
• Overlay - sare birtuala
  • ToRrekin gainjartzea
  • Ostalariaren gainjartzea
  • Tungsteno ehuna erabiliz adibide gisa
    • Komunikazioa makina fisiko bakar baten barruan
    • Makina fisiko ezberdinetan kokatutako VM arteko komunikazioa
    • Kanpoko mundura irten

• ohiko galderak
• Ondorioa
• Esteka interesgarriak

arrazoi

Eta honetaz ari garenez, sarearen birtualizaziorako aurrebaldintzak aipatzea komeni da. Izan ere, prozesu hori ez zen atzo hasi.

Seguruenik behin baino gehiagotan entzun izan duzu sarea beti izan dela edozein sistemaren zatirik inerteena. Eta hori egia da zentzu guztietan. Sarea da dena oinarritzen den oinarria, eta horretan aldaketak egitea nahiko zaila da - zerbitzuek ez dute onartzen sarea behera dagoenean. Askotan, nodo bakar bat kentzeak aplikazioen zati handi bat ken dezake eta bezero askotan eragina izan dezake. Horregatik, neurri batean, sareko taldeak edozein aldaketari eutsi diezaioke - orain nolabait funtzionatzen duelako (agian ez dakigu nola), baina hemen zerbait berria konfiguratu behar duzu, eta ez dakigu nola eragingo duen sarean.

Saregileek VLANak txertatzeko eta sareko nodo bakoitzean zerbitzurik ez erregistratzeko zain egon ez dadin, jendeari gainjartzeak - gainjarri-sareak - askotariko gainjartzeak erabiltzea bururatu zitzaion: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etab.

Haien erakargarritasuna bi gauza errazetan datza:

• Amaierako nodoak bakarrik konfiguratzen dira; ez dira garraioko nodoak ukitu behar. Horrek nabarmen bizkortzen du prozesua, eta batzuetan sareko azpiegitura saila zerbitzu berriak sartzeko prozesutik guztiz baztertzeko aukera ematen du.
• Karga goiburuen barruan ezkutatuta dago - garraio-nodoek ez dute ezer jakin behar horri buruz, ostalarien helbideari buruz edo gainjarritako sarearen ibilbideei buruz. Horrek esan nahi du informazio gutxiago gorde behar duzula tauletan, hau da, gailu sinpleagoa/merkeagoa erabiltzea da.

Oso-osorik ez dagoen gai honetan, ez dut teknologia posible guztiak aztertzeko asmorik, DCetan gainjarritako sareen funtzionamenduaren esparrua deskribatzea baizik.

Serie osoak zerbitzari-ekipo bera instalatuta dagoen bastidore berdinen ilaraz osatutako datu-zentro bat deskribatuko du.

Ekipamendu honek zerbitzuak ezartzen dituzten makina birtualak/edukiontzi/zerbitzaririk gabe exekutatzen ditu.

terminologia

Begizta batean zerbitzaria Bezero-zerbitzariaren komunikazioaren zerbitzariaren aldea inplementatzen duen programa bat izendatuko dut.

Rack-eko makina fisikoei zerbitzari deitzen zaie ez egingo dugu.

Makina fisikoa — x86 ordenagailua rack batean instalatuta. Gehien erabiltzen den terminoa ostalari. Horrela deituko diogu”autoa"or ostalari.

Hipervisor — Makina fisiko batean exekutatzen den aplikazio bat, Makina Birtualak exekutatzen dituzten baliabide fisikoak emulatzen dituena. Batzuetan literaturan eta Interneten “hipervisor” hitza “host”-en sinonimo gisa erabiltzen da.

Makina birtuala - Hipervisor baten gainean makina fisiko batean exekutatzen den sistema eragilea. Ziklo honetan guretzat, ez du axola benetan makina birtuala edo edukiontzi bat den. Dei diezaiogun "VM«

Maizterrak artikulu honetan zerbitzu bereizi edo bezero bereizi gisa definituko dudan kontzeptu zabala da.

Alokairu anitzekoa edo maiztasun anitzeko - bezero/zerbitzu ezberdinek aplikazio bera erabiltzea. Aldi berean, bezeroak elkarrengandik isolatzea aplikazioen arkitekturari esker lortzen da, eta ez bereizita exekutatzen diren instantzien bidez.

ToR — Rack-eko etengailuaren goiko aldea - makina fisiko guztiak konektatuta dauden rack batean instalatutako etengailua.

ToR topologiaz gain, hainbat hornitzailek End of Row (EoR) edo Middle of Row lantzen dute (nahiz eta azken hau gutxiespena den eta ez dudan MoR laburdura ikusi).

Azpiko sarea edo azpiko sarea edo azpikoa sare fisikoaren azpiegitura da: etengailuak, bideratzaileak, kableak.

Gainjarri sarea or overlay network or overlay - fisikoaren gainean ibiltzen den tunelen sare birtuala.

L3 ehuna edo IP ehuna - Gizateriaren asmakizun harrigarria, STP errepikatzea eta elkarrizketetarako TRILL ikastea saihesteko aukera ematen duena. Sarbide mailara arte sare osoa L3 baino ez den kontzeptua, VLANrik gabe eta, horrenbestez, hedatutako broadcast domeinu handirik gabe. "Fabrika" hitza nondik datorren aztertuko dugu hurrengo zatian.

SDN - Software Definitutako Sarea. Ia ez du aurkezpenik behar. Sarearen kudeaketaren ikuspegia, non sarean aldaketak ez diren pertsona batek egiten, programa batek baizik. Normalean, Kontrol Hegazkina amaierako sareko gailuetatik haratago kontrolagailura eramatea esan nahi du.

NFV - Sareko Funtzioen Birtualizazioa - sareko gailuen birtualizazioa, sareko funtzio batzuk makina birtualen edo edukiontzien moduan exekutatu daitezkeela iradokitzen du, zerbitzu berrien ezarpena bizkortzeko, Zerbitzuen kateatzea eta eskalagarritasun horizontal sinpleagoa antolatzeko.

VNF - Sare birtualaren funtzioa. Gailu birtual espezifikoa: bideratzailea, switch, suebakia, NAT, IPS/IDS, etab.

Orain nahita sinplifikatzen ari naiz deskribapena ezarpen zehatz batera, irakurlea gehiegi nahasteko. Irakurketa sakonagorako, atala aipatzen dut Erreferentziak. Horrez gain, Roma Gorge-k, artikulu hau zehaztasunik gabekoengatik kritikatzen duenak, zerbitzari eta sare birtualizazio teknologiei buruzko aparteko ale bat idatziko duela agintzen du, sakonagoa eta xehetasunei adi.

Gaur egungo sare gehienak argi eta garbi bi zatitan bana daitezke:

azpiazal — konfigurazio egonkorra duen sare fisikoa.
Gainjarri — Underlay-ren gaineko abstrakzioa, maizterrak isolatzeko.

Hori egia da bai DCren kasuan (artikulu honetan aztertuko duguna) bai ISPren kasuan (aztertuko ez duguna, dagoeneko izan baita). SDSM). Enpresa-sareekin, noski, egoera zertxobait ezberdina da.

Argazkia sarean arreta jarrita:

azpiazal

Underlay sare fisiko bat da: hardware-etengailuak eta kableak. Lurpeko gailuek badakite makina fisikoetara iristen.

Protokolo eta teknologi estandarretan oinarritzen da. Ez da behintzat hardware-gailuek gaur egunera arte txipa programatzen edo protokolo propioak ezartzen uzten ez duten software jabedunarekin funtzionatzen dutelako; horrenbestez, beste saltzaile batzuekin bateragarritasuna eta estandarizazioa behar dira.

Baina Google bezalako norbaitek bere etengailuak garatu eta orokorrean onartutako protokoloak alde batera utzi ditzake. Baina LAN_DC ez da Google.

Azpikoa oso gutxitan aldatzen da bere helburua makina fisikoen arteko oinarrizko IP konexioa delako. Underlay-k ez daki ezer haren gainean exekutatzen diren zerbitzuei, bezeroei edo maizterrei buruz - paketea makina batetik bestera entregatu besterik ez du behar.
Azpikoa honelakoa izan daiteke:

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

Underlay sarea modu klasikoan konfiguratuta dago: CLI/GUI/NETCONF.

Eskuz, scriptak, jabedun utilitateak.

Serieko hurrengo artikulua xehetasun gehiagorekin emango zaio azpiko geruzari.

Gainjarri

Overlay Underlay-ren gainean luzatutako tunel sare birtual bat da, bezero baten VM-ak elkarren artean komunikatzeko aukera ematen du, beste bezeroengandik isolatuta dagoen bitartean.

Bezeroaren datuak tunelaren goiburu batzuetan biltzen dira sare publikoan transmititzeko.

Beraz, bezero baten (zerbitzu bateko) VM-ak elkarren artean komunika daitezke Overlay bidez, paketeak benetan zer bide hartzen duen jakin gabe.

Gainjartzea, adibidez, goian aipatu dudan bezala izan daiteke:

• GRE tunela
• VXLAN
• EVPN
• L3VPN
• Geneve

Gainjartze-sare bat kontrolagailu zentral baten bidez konfiguratu eta mantentzen da normalean. Bertatik, konfigurazioa, Kontrol Hegazkina eta Datu Plana bezeroen trafikoa bideratzen eta kapsulatzen duten gailuetara bidaltzen dira. Txikia azpitik Ikus dezagun hau adibideekin.

Bai, hau SDN da bere forma garbienean.

Oinarrizko bi ikuspegi desberdin daude Overlay sare bat antolatzeko:

1. ToRrekin gainjartzea
2. Ostalariaren gainjartzea

ToRrekin gainjartzea

Gainjartzea sarbide etengailuan (ToR) abiaraztean abia daiteke, adibidez, VXLAN ehun baten kasuan gertatzen den bezala.

Hau denboraz probatutako mekanismoa da ISP sareetan eta sareko ekipoen saltzaile guztiek onartzen dute.

Hala ere, kasu honetan, ToR etengailuak zerbitzu ezberdinak bereizteko gai izan behar du, hurrenez hurren, eta sareko administratzaileak, neurri batean, makina birtualeko administratzaileekin lankidetzan aritu behar du eta gailuen konfigurazioan aldaketak egin (automatikoki bada ere). .

Hemen irakurlea honi buruzko artikulu batera bideratuko dut VxLAN Habré-n gure lagun zaharra @bormoglotx.
Honetan aurkezpenak ENOGrekin EVPN VXLAN ehun batekin DC sare bat eraikitzeko planteamenduak xehetasunez deskribatzen dira.

Eta errealitatean erabat murgiltzeko, Tsiskaren liburua irakur dezakezu Ehun moderno, ireki eta eskalagarria: VXLAN EVPN.

Kontuan izan dut VXLAN kapsulatze metodo bat baino ez dela eta tunelen amaiera ez ToR-en gerta daitekeela, ostalarian baizik, OpenStack-en kasuan gertatzen den bezala, adibidez.

Hala ere, VXLAN ehuna, gainjartzea ToR-n hasten den gainjarri-sare-diseinuetako bat da.

Ostalariaren gainjartzea

Beste ikuspegi bat amaierako ostalarietan tunelak hastea eta amaitzea da.
Kasu honetan, sarea (Underlay) ahalik eta sinpleena eta estatikoena izaten jarraitzen du.
Eta ostalariak berak egiten ditu beharrezko kapsulatze guztiak.

Honek, noski, ostalarietan aplikazio berezi bat exekutatu beharko du, baina merezi du.

Lehenik eta behin, bezero bat Linux makina batean exekutatu errazagoa da edo, demagun, posible ere bada, etengailu batean dagoen bitartean, ziurrenik SDN soluzio jabedunetara jo beharko duzu, eta horrek saltzaile anitzeko ideia hiltzen du.

Bigarrenik, kasu honetan ToR etengailua ahalik eta sinpleena utz daiteke, bai Kontrol Planoaren ikuspuntutik, bai Datu Planaren ikuspuntutik. Izan ere, orduan ez du SDN kontrolagailuarekin komunikatu behar, eta, gainera, ez du zertan konektatutako bezero guztien sareak/ARPak gordetzea - ​​nahikoa da makina fisikoaren IP helbidea jakitea, eta horrek asko errazten du aldaketa/ bideratze-taulak.

ADSM seriean, ostalariaren gainjartze-ikuspegia aukeratzen dut; orduan horretaz bakarrik hitz egiten dugu eta ez gara VXLAN fabrikara itzuliko.

Adibideak ikustea da errazena. Eta proba-gai gisa OpenSource SDN plataforma OpenContrail hartuko dugu, gaur egun izenez ezagutzen dena Tungsteno ehuna.

Artikuluaren amaieran OpenFlow eta OpenvSwitch-en analogiari buruzko gogoeta batzuk emango ditut.

Tungsteno ehuna erabiliz adibide gisa

Makina fisiko bakoitzak dauka vRouter - bideratzaile birtual bat, harekin konektatuta dauden sareak eta zein bezerotakoak diren ezagutzen dituena - funtsean PE bideratzailea. Bezero bakoitzeko, bideratze-taula isolatu bat mantentzen du (irakurri VRF). Eta vRouter-ek Overlay tunelak egiten ditu.

vRouter-i buruz apur bat gehiago artikuluaren amaieran dago.

Hipervisorean kokatutako VM bakoitza makina honen vRouter-era konektatzen da bidez TAP interfazea.

TAP - Terminal Access Point - sareko interakzioa ahalbidetzen duen Linux nukleoko interfaze birtuala.

vRouter-aren atzean hainbat sare badaude, haietako bakoitzarentzat interfaze birtual bat sortzen da, eta horri IP helbide bat esleitzen zaio - atebide-helbide lehenetsia izango da.
Bezero baten sare guztiak batean kokatzen dira VRF (mahai bat), desberdinak - ezberdinetan.
Hemen dena ez dela hain sinplea egingo dut, eta irakurle jakintsua artikuluaren amaierara bidaliko dut.

vRouters elkarren artean komunikatu ahal izateko, eta horren atzean kokatutako VM-ek, bideratze-informazioa trukatzen dute bidez. SDN kontrolagailua.

Kanpoko mundura ateratzeko, matrizetik irteera puntu bat dago - sare birtualaren atebide bat VNGW - Sare birtuala GateWay (nire terminoa).

Ikus ditzagun orain komunikazioen adibideak, eta argitasuna egongo da.

Komunikazioa makina fisiko bakar baten barruan

VM0-k pakete bat bidali nahi du VM2-ra. Demagun oraingoz bezero bakarreko VM bat dela.

Datuen planoa

1. VM-0-k bide lehenetsi bat du bere eth0 interfazera. Paketea hara bidaltzen da.
   Eth0 interfaze hau ia bideratzaile birtualera konektatzen da vRouter TAP interfazearen tap0 bidez.
2. vRouter-ek paketea zein interfazera iritsi den aztertzen du, hau da, zein bezerori (VRF) dagokion, eta hartzailearen helbidea egiaztatzen du bezero honen bideratze-taularekin.
3. Makina bereko hartzailea beste portu batean dagoela detektatu ondoren, vRouter-ek paketea hara bidaltzen dio goiburu gehigarririk gabe; kasu honetan, vRouter-ek ARP erregistro bat du dagoeneko.

Kasu honetan, paketea ez da sare fisikora sartzen; vRouter-en barruan bideratzen da.

Kontrol-hegazkina

Makina birtuala abiarazten denean, hipervisoreak esaten dio:

• Bere IP helbidea.
• Ibilbide lehenetsia sare honetako vRouter-en IP helbidearen bidezkoa da.

Hipervisoria vRouter-i API berezi baten bidez jakinaraziko dio:

• Interfaze birtual bat sortzeko behar duzuna.
• Nolako sare birtuala (VM) sortu behar du?
• Zein VRF (VN) lotu.
• VM honetarako ARP sarrera estatiko bat: zein interfazetan dagoen bere IP helbidea eta zer MAC helbidera lotzen den.

Berriz ere, benetako interakzio prozedura sinplifikatu egiten da kontzeptua ulertzeko.

Horrela, vRouter-ek makina jakin bateko bezero baten VM guztiak zuzenean konektatutako sare gisa ikusten ditu eta haien artean bideratu ditzake.

Baina VM0 eta VM1 bezero ezberdinetakoak dira eta, horren arabera, vRouter taula ezberdinetan daude.

Elkarrekin zuzenean komunikatu daitezkeen ala ez vRouter ezarpenen eta sarearen diseinuaren araberakoa da.
Adibidez, bi bezeroen VM-ek helbide publikoak erabiltzen badituzte edo NAT vRouter-ean bertan gertatzen bada, vRouter-era bideratze zuzena egin daiteke.

Alderantzizko egoeran, posible da helbide-espazioak zeharkatzea - ​​NAT zerbitzari batetik pasa behar duzu helbide publiko bat lortzeko - behean eztabaidatzen diren kanpoko sareetara sartzearen antzekoa da.

Makina fisiko ezberdinetan kokatutako VM arteko komunikazioa

Datuen planoa

1. Hasiera berdina da: VM-0-k pakete bat bidaltzen du VM-7 helmuga (172.17.3.2) bere lehenetsiarekin.
2. vRouter-ek jasotzen du eta oraingoan ikusten du helmuga beste makina batean dagoela eta Tunnel0 bidez eskura daitekeela.
3. Lehenik eta behin, urruneko interfazea identifikatzen duen MPLS etiketa bat zintzilikatzen du, beraz, atzeko aldean vRouter-ek pakete hau non kokatu behar den zehaztu dezake bilaketa gehigarririk gabe.

   

4. Tunnel0 iturburua 10.0.0.2 du, helmuga: 10.0.1.2.
   vRouter-ek GRE (edo UDP) goiburuak eta IP berri bat gehitzen dizkio jatorrizko paketeari.
5. vRouter bideratze-taulak ibilbide lehenetsi bat du ToR1 helbidetik 10.0.0.1. Hara non bidaltzen du.

   
   

6. ToR1ek, Underlay sareko kide gisa, badaki (adibidez, OSPF bidez) 10.0.1.2ra nola iritsi eta paketea ibilbidean zehar bidaltzen du. Kontuan izan ECMP gaituta dagoela hemen. Ilustrazioan bi nexthop daude, eta hari desberdinak hash bidez ordenatuko dira. Benetako fabrika baten kasuan, litekeena da 4 nexthops egotea.

   Aldi berean, ez du jakin behar zer dagoen kanpoko IP goiburuaren azpian. Hau da, hain zuzen ere, IP azpian IPv6-ren ogitarteko bat egon daiteke MPLS-ren bidez Ethernet-en MPLS-ren gainean GRE-ren gainean greziarren gainean.

7. Horren arabera, hartzailearen aldetik, vRouter-ek GRE kentzen du eta, MPLS etiketa erabiliz, pakete hori zein interfazera bidali behar den ulertzen du, kendu eta bere jatorrizko forman bidaltzen dio hartzaileari.

Kontrol-hegazkina

Autoa martxan jartzen duzunean, goian deskribatutako gauza bera gertatzen da.

Eta gainera honako hauek:

• Bezero bakoitzeko, vRouter-ek MPLS etiketa bat esleitzen du. Hau L3VPN zerbitzuaren etiketa da, zeinaren bidez bezeroak makina fisiko berean bereiziko dira.
  

  Izan ere, MPLS etiketa beti esleitzen du vRouter-ek baldintzarik gabe; azken finean, ez da aldez aurretik jakitea makinak vRouter beraren atzean dauden beste makina batzuekin bakarrik elkarreragiten duenik eta ziurrenik hori ez da egia.

• vRouter-ek konexio bat ezartzen du SDN kontrolagailuarekin BGP protokoloa erabiliz (edo antzekoa - TF kasuan, XMPP 0_o da).
• Saio honen bidez, vRouter-ek konektatutako sareetarako ibilbideak ematen dizkio SDN kontrolatzaileari:
  • Sareko helbidea
  • Kapsulatzeko metodoa (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS bezeroaren etiketa
  • Zure IP helbidea nexthop gisa

• SDN kontrolatzaileak konektatutako vRouter guztiengandik halako ibilbideak jasotzen ditu eta besteengan islatzen ditu. Hau da, Ibilbidearen islatzaile gisa jokatzen du.

Gauza bera gertatzen da kontrako norabidean.

Gainjartzea minuturo gutxienez alda daiteke. Hori da gutxi gorabehera hodei publikoetan gertatzen dena, non bezeroek beren makina birtualak aldian-aldian hasten eta itzaltzen dituzten.

Kontrolagailu zentralak konfigurazioa mantentzeko eta vRouter-en aldatzeko/bideratze-taulak kontrolatzeko konplexutasun guztiaz arduratzen da.

Gutxi gorabehera, kontrolagailua vRouter guztiekin komunikatzen da BGP (edo antzeko protokolo baten bidez) eta bideratze-informazioa transmititzen du. BGP-k, adibidez, dagoeneko badu Helbidea-Familia kapsulatzeko metodoa transmititzeko MPLS-in-GRE edo MPLS-en-UDP.

Aldi berean, Underlay sarearen konfigurazioa ez da inola ere aldatzen, eta hori, bide batez, askoz zailagoa da automatizatzea, eta errazago apurtzea mugimendu baldar batekin.

Kanpoko mundura irten

Nonbait simulazioa amaitu behar da, eta mundu birtualetik irten behar duzu benetakora. Eta telefono publikoko atebide bat behar duzu.

Bi ikuspegi lantzen dira:

1. Hardware bideratzailea instalatuta dago.
2. Bideratzaile baten funtzioak ezartzen dituen tresna bat abiarazten da (bai, SDN jarraituz, VNF ere topatu dugu). Dei diezaiogun atebide birtuala.

Bigarren ikuspegiaren abantaila eskalagarritasun horizontal merkea da - ez dago nahikoa potentzia - beste makina birtual bat abiarazi genuen atebide batekin. Edozein makina fisikotan, doako bastidoreak, unitateak, potentzia-irteera bilatu beharrik gabe, hardwarea bera erosi, garraiatu, instalatu, aldatu, konfiguratu eta, ondoren, akastun diren osagaiak ere aldatu.

Atebide birtual baten desabantailak dira bideratzaile fisiko baten unitate bat nukleo anitzeko makina birtual bat baino askoz ere ahaltsuagoa dela eta bere softwareak, bere hardware-oinarrira egokituta, askoz egonkorrago funtzionatzen duela (нет). Hardware eta software konplexuak besterik gabe funtzionatzen duela ere zaila da ukatzea, konfigurazioa bakarrik eskatzen duela, atebide birtual bat abiarazi eta mantentzea ingeniari sendoen zeregina den bitartean.

Oin batekin, atebideak Overlay sare birtualera begiratzen du, ohiko Makina Birtual bat bezala, eta beste VM guztiekin elkarreragin dezake. Aldi berean, bezero guztien sareak amai ditzake eta, horren arabera, haien arteko bideratzea egin dezake.

Beste oinarekin, ateak bizkarrezurreko sarera begiratzen du eta Internetera nola sartzen daki.

Datuen planoa

Hau da, prozesua honelakoa da:

1. VM-0-k, vRouter bera lehenetsita, kanpoko munduan helmuga duen pakete bat bidaltzen du (185.147.83.177) eth0 interfazera.
2. vRouter-ek pakete hau jasotzen du eta helmuga helbidea bilatzen du bideratze-taulan - bide lehenetsia aurkitzen du VNGW1 atebidetik 1. tunelaren bidez.
   SIP 10.0.0.2 eta DIP 10.0.255.2 dituen GRE tunel bat dela ere ikusten du, eta bezero honen MPLS etiketa ere erantsi behar du lehenik, VNGW1ek espero duena.
3. vRouter-ek hasierako paketea MPLS, GRE eta IP goiburu berriekin biltzen du eta lehenespenez ToR1 10.0.0.1 helbidera bidaltzen du.
4. Azpiko sareak paketea VNGW1 atebidera entregatzen du.
5. VNGW1 atebideak GRE eta MPLS tunelen goiburuak kentzen ditu, helmuga helbidea ikusten du, bere bideratze-taula kontsultatzen du eta Internetera zuzentzen dela ulertzen du, hau da, Ikuspegi osoa edo Lehenetsiaren bidez. Beharrezkoa bada, NAT itzulpena egiten du.
6. VNGWtik mugaraino IP sare arrunt bat egon liteke, hori nekez.
   MPLS sare klasiko bat egon daiteke (IGP+LDP/RSVP TE), atzealdeko ehun bat egon daiteke BGP LUrekin edo GRE tunel bat VNGWtik mugaraino IP sare baten bidez.
   Dena den, VNGW1-ek beharrezko enkapsulazioak egiten ditu eta hasierako paketea mugarantz bidaltzen du.

Kontrako noranzkoan dagoen trafikoa urrats berberak egiten ditu kontrako ordenan.

1. Ertzak paketea VNGW1era erortzen du
2. Biluzten du, hartzailearen helbidea begiratu eta Tunnel1 tuneletik (MPLSoGRE edo MPLSoUDP) eskura dagoela ikusten du.
3. Horren arabera, MPLS etiketa, GRE/UDP goiburua eta IP berri bat eransten ditu eta bere ToR3 10.0.255.1ra bidaltzen du.
   Tunelaren helmuga helbidea xede VM kokatzen den vRouter-aren IP helbidea da - 10.0.0.2.
4. Azpiko sareak paketea nahi duzun vRouter-era bidaltzen du.
5. Helburuko vRouter-ek GRE/UDP irakurtzen du, MPLS etiketa erabiliz interfazea identifikatzen du eta IP pakete huts bat bidaltzen du VM-ko eth0-rekin lotutako TAP interfazera.

Kontrol-hegazkina

VNGW1-ek BGP auzo bat ezartzen du SDN kontrolagailu batekin, eta bertatik bezeroei buruzko bideratze-informazio guztia jasotzen du: zein IP helbide (vRouter) dagoen zein bezeroren atzean, eta zein MPLS etiketarekin identifikatzen den.

Era berean, berak bezero honen etiketarekin bide lehenetsiaren berri ematen dio SDN kontrolatzaileari, hurrengo salto gisa adieraziz. Eta gero lehenetsi hau vRouters-era iristen da.

VNGW-n, ibilbideen agregazioa edo NAT itzulpena gertatzen da normalean.

Eta beste noranzkoan, ibilbide bateratu hori zehatz-mehatz bidaltzen du ertzekin edo Ibilbide-erreflektorea duten saiora. Eta haiengandik ibilbide lehenetsia edo Full-View, edo beste zerbait jasotzen du.

Kapsulatze eta trafiko-trukeari dagokionez, VNGW ez da vRouter-en desberdina.
Eremua apur bat zabaltzen baduzu, beste sare gailu batzuk gehi ditzakezu VNGW eta vRouter-etara, hala nola suebakiak, trafikoa garbitzeko edo aberasteko ustiategiak, IPS eta abar.

Eta VRF-ak sekuentzialki sortzearen eta ibilbideen iragarpen zuzenaren laguntzaz, trafikoa nahi duzun moduan ibiltzera behartu dezakezu, hau da, Service Chaining deitzen dena.

Hau da, hemen ere SDN kontrolagailuak VNGW, vRouter eta sareko beste gailu batzuen artean Ibilbide-Islatzaile gisa jokatzen du.

Baina, hain zuzen ere, kontrolatzaileak ACL eta PBR (Policy Based Routing) buruzko informazioa ere kaleratzen du, eta zirkulazio-fluxu indibidualak ibilbideak esaten duenaren modu ezberdinean joango dira.

ohiko galderak

Zergatik egiten duzu beti GRE/UDP oharra?

Beno, oro har, hau Tungsteno ehunaren espezifikoa dela esan daiteke - ez duzu batere kontuan hartu beharrik.

Baina hartzen badugu, orduan TFk berak, OpenContrail oraindik ere, bi enkapsulazio onartzen zituen: MPLS GREn eta MPLS UDPn.

UDP ona da Iturburu Portuan oso erraza baita jatorrizko IP+Proto+Portetik hash funtzio bat kodetzea bere goiburuan, eta horrek oreka egiteko aukera emango dizu.

GREren kasuan, tamalez, kanpoko IP eta GRE goiburuak baino ez daude, kapsulatutako trafiko guztiarentzat berdinak eta ez da orekaz hitz egiten - jende gutxik begiratu dezake hain sakona paketearen barruan.

Aspaldi arte, bideratzaileek, tunel dinamikoak erabiltzen bazekiten, MPLSoGREn bakarrik egiten zuten, eta duela gutxi ikasi zuten MPLSoUDP erabiltzen. Hori dela eta, beti egin behar dugu ohar bat bi enkapsulazio ezberdinen aukerari buruz.

Egia esanda, nabarmentzekoa da TF-k L2 konexioa guztiz onartzen duela VXLAN erabiliz.

OpenFlow-ekin paralelismoak egingo dituzula agindu zenuen.
Benetan eskatzen ari dira. OpenStack berean vSwitch-ek oso antzekoak egiten ditu, VXLAN erabiliz, eta horrek, bide batez, UDP goiburua ere badu.

Datu-planoan gutxi gorabehera berdin funtzionatzen dute; Kontrol-planoa nabarmen desberdina da. Tungsten Fabric-ek XMPP erabiltzen du bideratze-informazioa vRouter-i emateko, eta OpenStack-ek Openflow exekutatzen duen bitartean.

Esango al didazu pixka bat gehiago vRouter-i buruz?
Bi zatitan banatzen da: vRouter Agent eta vRouter Forwarder.

Lehenengoa OS ostalariaren Erabiltzaile Espazioan exekutatzen da eta SDN kontrolagailuarekin komunikatzen da, ibilbideei, VRFei eta ACLei buruzko informazioa trukatuz.

Bigarrenak Data Plane inplementatzen du - normalean Kernel Space-n, baina SmartNIC-etan ere exekutatu daiteke - CPU bat eta aparteko kommutazio-txip programagarri bat duten sare-txartelak, makina ostalariaren CPUtik karga kentzeko eta sarea azkarrago eta gehiago egiteko aukera ematen duena. aurreikusteko.

Beste eszenatoki posible bat da vRouter Erabiltzaile-espazioko DPDK aplikazio bat dela.

vRouter Agent-ek ezarpenak bidaltzen dizkio vRouter Forwarder-era.

Zer da Sare Birtuala?
VRFri buruzko artikuluaren hasieran maizter bakoitza bere VRFari lotuta dagoela aipatu nuen. Eta gainjarri sarearen funtzionamendua azaleko ulertzeko nahikoa bazen, hurrengo errepikapenean argibideak egin behar dira.

Normalean, birtualizazio-mekanismoetan, Sare Birtuala entitatea (hau izen propiotzat har dezakezu) bezero/errente/makina birtualetatik bereizita sartzen da - gauza guztiz independentea. Eta Sare Birtual hau dagoeneko konekta daiteke interfazeen bidez maizter bati, beste bati, biri edo edonon. Beraz, adibidez, Zerbitzuen kateatzea inplementatzen da trafikoa behar den sekuentzian nodo batzuetatik igaro behar denean, Sare Birtualak sekuentzia egokian sortuz eta konektatuz.

Beraz, beraz, ez dago zuzeneko korrespondentziarik Sare Birtualaren eta maizterraren artean.

Ondorioa

Sare birtual baten funtzionamenduaren deskribapen oso azaleko bat da, ostalariaren gainjarriarekin eta SDN kontrolagailu batekin. Baina gaur egun aukeratzen duzun birtualizazio plataforma edozein dela ere, antzera funtzionatuko du, izan VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric edo Juniper Contrail. Kapsulatze eta goiburu motak desberdinak izango dira, azken sareko gailuetara informazioa emateko protokoloetan, baina software-konfiguragarria den gainjarri sare baten printzipioa azpiko sare nahiko sinple eta estatiko baten gainean lan egiten duenaren printzipioa berdina izango da.
Esan dezakegu gaur egun gainjarritako sare batean oinarritutako SDNk irabazi duela hodei pribatu bat sortzeko eremua. Hala ere, horrek ez du esan nahi Openflow-ek lekurik ez duenik mundu modernoan - OpenStacke-n eta VMWare NSX berean erabiltzen da, nik dakidala, Google-k lurpeko sarea konfiguratzeko erabiltzen du.

Jarraian material zehatzagoetarako estekak eman ditut gaia sakonago aztertu nahi baduzu.

Eta zer gertatzen da gure Underlay?

Baina, oro har, ezer ez. Ez zuen bide osoa aldatu. Ostalariaren gainjartze baten kasuan egin behar duen guztia ibilbideak eta ARPak eguneratzea da, vRouter/VNGW agertu eta desagertzen diren heinean eta paketeak haien artean eraman.

Formulatu dezagun Underlay sarerako eskakizunen zerrenda.

1. Bideratze-protokoloren bat erabiltzeko gai izatea, gure egoeran - BGP.
2. Banda zabalera zabala izatea, ahal dela gehiegizko harpidetzarik gabe, gainkargak direla eta paketeak gal ez daitezen.
3. ECMP laguntzea ehunaren zati bat da.
4. QoS eskaintzeko gai izan, ECN bezalako gauza delikatuak barne.
5. NETCONF laguntzea etorkizunerako oinarri bat da.

Hemen oso denbora gutxi eskaini nion Underlay sarearen beraren lanari. Hau da, seriean aurrerago horretan zentratuko naizelako, eta gainjartzea baino ez dugu ukituko.

Jakina, denok asko mugatzen ari naiz, adibide gisa Cloz fabrika batean eraikitako DC sare bat erabiliz IP bideratze hutsarekin eta ostalariaren gainjartze batekin.

Hala ere, ziur nago diseinua duen edozein sare termino formaletan eta automatizatuta deskriba daitekeela. Nire helburua hemen automatizazioaren planteamenduak ulertzea da, eta denak ez nahastea arazoa forma orokor batean konponduz.

ADSMren baitan, Roman Gorge-k eta biok aparteko ale bat argitaratzeko asmoa dugu konputazio-potentziaren birtualizazioari eta sarearen birtualizazioarekin duen elkarrekintzari buruz. Harremanetan jarraitu.

Esteka interesgarriak

• Tungsteno ehuneko artxibetura.
• buruz:hodeia. 6 ordu Yandex.Cloud-i buruz, TF-ko sare birtuala ere hartzen duena.
• Zer da Open vSwitch?
• VxLAN-en sarrera.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Birtualizatutako 2. geruzako sareak 3. geruzako sareen gainean gainjartzeko esparrua.
  
• VXLAN EVPN ehunaren ikuspegi eskalagarria. DC sare osoari buruz hitz egiten du, Underlay, Overlay, multi-homing eta kudeaketaren ikuspegiak barne.

Eskerrik asko

• Roman Gorga - linkmeup podcast-aren ostalari ohia eta gaur egun hodeiko plataformen arloan aditua. Iruzkinak eta aldaketak egiteko. Bada, etorkizun hurbilean birtualizazioari buruzko bere artikulu sakonagoaren zain gaude.
• Alexander Shalimov - Nire lankidea eta sare birtualen garapenaren arloan aditua. Iruzkinak eta aldaketak egiteko.
• Valentin Sinitsyn - nire lankidea eta tungsteno ehunaren arloan aditua. Iruzkinak eta aldaketak egiteko.
• Artyom Txernobaia - linkmeup ilustratzailea. KDPVrako.
• Alexander Limonov. "Automatiko" memeagatik.

Iturria: www.habr.com