В nakaraang isyu Inilarawan ko ang network automation framework. Ayon sa ilang mga tao, kahit na ang unang diskarte sa problema ay naayos na ang ilang mga katanungan. At ito ang nagpapasaya sa akin, dahil ang aming layunin sa cycle ay hindi upang pagtakpan ang Ansible gamit ang mga script ng Python, ngunit upang bumuo ng isang sistema.

Ang parehong balangkas ay nagtatakda ng pagkakasunud-sunod kung saan haharapin natin ang tanong.
At ang virtualization ng network, kung saan nakatuon ang isyung ito, ay hindi partikular na akma sa paksa ng ADSM, kung saan sinusuri namin ang automation.

Ngunit tingnan natin ito sa ibang anggulo.

Maraming mga serbisyo ang gumagamit ng parehong network sa loob ng mahabang panahon. Sa kaso ng isang telecom operator, ito ay 2G, 3G, LTE, broadband at B2B, halimbawa. Sa kaso ng isang DC: pagkakakonekta para sa iba't ibang mga kliyente, Internet, block storage, object storage.

At lahat ng serbisyo ay nangangailangan ng paghihiwalay sa isa't isa. Ganito lumitaw ang mga overlay na network.

At ang lahat ng mga serbisyo ay hindi nais na maghintay para sa isang tao na i-configure ang mga ito nang manu-mano. Ganito lumitaw ang mga orkestra at SDN.

Ang unang diskarte sa sistematikong automation ng network, o sa halip ay bahagi nito, ay matagal nang kinuha at ipinatupad sa maraming lugar: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Iyan ang ating haharapin ngayon.

nilalaman

• Причины
• terminolohiya
• Underlay - pisikal na network
• Overlay - virtual network
  • Overlay sa ToR
  • Overlay mula sa host
  • Paggamit ng Tungsten Fabric bilang isang halimbawa
    • Komunikasyon sa loob ng isang pisikal na makina
    • Komunikasyon sa pagitan ng mga VM na matatagpuan sa iba't ibang pisikal na makina
    • Lumabas sa labas ng mundo

• FAQ
• Konklusyon
• Kapaki-pakinabang na mga link

Причины

At dahil pinag-uusapan natin ito, sulit na banggitin ang mga kinakailangan para sa virtualization ng network. Sa katunayan, ang prosesong ito ay hindi nagsimula kahapon.

Malamang na narinig mo nang higit sa isang beses na ang network ay palaging ang pinaka-inat na bahagi ng anumang system. At ito ay totoo sa lahat ng kahulugan. Ang network ay ang batayan kung saan ang lahat ay nakasalalay, at ang paggawa ng mga pagbabago dito ay medyo mahirap - hindi ito pinahihintulutan ng mga serbisyo kapag ang network ay down. Kadalasan, ang pag-decommission ng isang node ay maaaring magtanggal ng malaking bahagi ng mga application at makakaapekto sa maraming customer. Ito ang bahagyang dahilan kung bakit maaaring labanan ng network team ang anumang pagbabago - dahil ngayon ay gumagana na ito (baka hindi rin natin alam kung paano), ngunit dito kailangan mong mag-configure ng bago, at hindi alam kung paano ito makakaapekto sa network.

Upang hindi maghintay para sa mga networker na magpasok ng mga VLAN at hindi magrehistro ng anumang mga serbisyo sa bawat network node, ang mga tao ay nagkaroon ng ideya ng paggamit ng mga overlay - mga overlay na network - kung saan mayroong isang mahusay na iba't-ibang: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, atbp.

Ang kanilang apela ay nakasalalay sa dalawang simpleng bagay:

• Mga end node lang ang na-configure—hindi kailangang hawakan ang mga transit node. Ito ay makabuluhang nagpapabilis sa proseso, at kung minsan ay nagbibigay-daan sa iyong ganap na ibukod ang network infrastructure department mula sa proseso ng pagpapakilala ng mga bagong serbisyo.
• Ang load ay nakatago nang malalim sa loob ng mga header - ang mga transit node ay hindi kailangang malaman ang anumang bagay tungkol dito, tungkol sa pagtugon sa mga host, o tungkol sa mga ruta ng overlay network. Nangangahulugan ito na kailangan mong mag-imbak ng mas kaunting impormasyon sa mga talahanayan, na nangangahulugang gumamit ng mas simple/mas murang device.

Sa hindi ganap na isyu na ito, hindi ko planong suriin ang lahat ng posibleng teknolohiya, ngunit ilarawan ang balangkas para sa pagpapatakbo ng mga overlay na network sa mga DC.

Ang buong serye ay maglalarawan ng isang data center na binubuo ng mga hilera ng magkatulad na rack kung saan naka-install ang parehong kagamitan sa server.

Ang kagamitang ito ay nagpapatakbo ng mga virtual machine/container/serverless na nagpapatupad ng mga serbisyo.

terminolohiya

Sa isang loop server Papangalanan ko ang isang programa na nagpapatupad ng server side ng komunikasyon ng client-server.

Ang mga pisikal na makina sa mga rack ay tinatawag na mga server hindi gagawin natin.

Pisikal na makina — x86 computer na naka-install sa isang rack. Ang pinakamadalas na ginagamit na termino host. Yan ang itatawag natin dito"makina"O host.

Hypervisor - isang application na tumatakbo sa isang pisikal na makina na tumutulad sa mga pisikal na mapagkukunan kung saan tumatakbo ang mga Virtual Machine. Minsan sa panitikan at sa Internet ang salitang "hypervisor" ay ginagamit bilang isang kasingkahulugan para sa "host".

Virtual na makina - isang operating system na tumatakbo sa isang pisikal na makina sa ibabaw ng isang hypervisor. Para sa amin sa cycle na ito, hindi mahalaga kung ito ay talagang isang virtual machine o isang lalagyan lamang. Tawagan natin"ВМ«

Nangungupahan ay isang malawak na konsepto na tutukuyin ko sa artikulong ito bilang isang hiwalay na serbisyo o isang hiwalay na kliyente.

Multi-tenancy o multitenancy - ang paggamit ng parehong application ng iba't ibang kliyente/serbisyo. Kasabay nito, ang paghihiwalay ng mga kliyente mula sa isa't isa ay nakakamit salamat sa arkitektura ng application, at hindi sa pamamagitan ng magkahiwalay na pagtakbo ng mga pagkakataon.

ToR — Itaas ng switch ng Rack - isang switch na naka-install sa isang rack kung saan konektado ang lahat ng pisikal na makina.

Bilang karagdagan sa topology ng ToR, nagsasanay ang iba't ibang provider ng End of Row (EoR) o Middle of Row (bagama't ang huli ay pambihira at hindi ko nakita ang pagdadaglat ng MoR).

Underlay na network o ang pinagbabatayan na network o underlay ay ang pisikal na imprastraktura ng network: mga switch, router, cable.

Overlay na network o overlay na network o overlay - isang virtual na network ng mga tunnel na tumatakbo sa ibabaw ng pisikal.

L3 tela o IP tela - isang kamangha-manghang imbensyon ng sangkatauhan na nagbibigay-daan sa iyo upang maiwasan ang paulit-ulit na STP at pag-aaral ng TRILL para sa mga panayam. Isang konsepto kung saan ang buong network hanggang sa antas ng pag-access ay eksklusibong L3, walang mga VLAN at, nang naaayon, malalaking pinalawak na mga domain ng broadcast. Titingnan natin kung saan nagmula ang salitang "pabrika" sa susunod na bahagi.

SDN - Software Defined Network. Halos hindi nangangailangan ng pagpapakilala. Isang diskarte sa pamamahala ng network kung saan ang mga pagbabago sa network ay hindi ginawa ng isang tao, ngunit ng isang programa. Karaniwang nangangahulugan ng paglipat ng Control Plane sa kabila ng mga end network device patungo sa controller.

NFV — Network Function Virtualization — virtualization ng mga network device, na nagmumungkahi na ang ilang mga function ng network ay maaaring patakbuhin sa anyo ng mga virtual machine o container upang mapabilis ang pagpapatupad ng mga bagong serbisyo, ayusin ang Service Chaining at mas simpleng horizontal scalability.

VNF - Pag-andar ng Virtual Network. Partikular na virtual device: router, switch, firewall, NAT, IPS/ID, atbp.

Sinasadya ko na ngayong pinasimple ang paglalarawan sa isang tiyak na pagpapatupad, upang hindi masyadong malito ang mambabasa. Para sa mas maalalahaning pagbabasa, tinutukoy ko siya sa seksyon sanggunian. Bilang karagdagan, ang Roma Gorge, na pumupuna sa artikulong ito para sa mga kamalian, ay nangangako na magsulat ng isang hiwalay na isyu tungkol sa mga teknolohiya ng virtualization ng server at network, mas malalim at matulungin sa detalye.

Karamihan sa mga network ngayon ay malinaw na nahahati sa dalawang bahagi:

Underlay — isang pisikal na network na may matatag na pagsasaayos.
Maglatag — abstraction sa Underlay para sa paghihiwalay ng mga nangungupahan.

Ito ay totoo kapwa para sa kaso ng DC (na susuriin natin sa artikulong ito) at para sa ISP (na hindi natin susuriin, dahil ito ay naging SDSM). Sa mga network ng negosyo, siyempre, ang sitwasyon ay medyo naiiba.

Larawan na nakatutok sa network:

Underlay

Ang underlay ay isang pisikal na network: mga switch at cable ng hardware. Alam ng mga device sa ilalim ng lupa kung paano maabot ang mga pisikal na makina.

Umaasa ito sa mga karaniwang protocol at teknolohiya. Hindi bababa sa dahil ang mga hardware device hanggang ngayon ay tumatakbo sa pagmamay-ari na software na hindi pinapayagan ang alinman sa pagprograma ng chip o pagpapatupad ng sarili nitong mga protocol; nang naaayon, kailangan ang pagiging tugma sa iba pang mga vendor at standardisasyon.

Ngunit ang isang tulad ng Google ay kayang gumawa ng sarili nilang mga switch at abandunahin ang mga karaniwang tinatanggap na protocol. Ngunit ang LAN_DC ay hindi Google.

Medyo bihira ang mga pagbabago sa underlay dahil ang trabaho nito ay pangunahing koneksyon ng IP sa pagitan ng mga pisikal na makina. Walang alam si Underlay tungkol sa mga serbisyo, kliyente, o nangungupahan na tumatakbo sa ibabaw nito - kailangan lang nitong ihatid ang package mula sa isang makina patungo sa isa pa.
Ang underlay ay maaaring ganito:

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

Ang network ng Underlay ay na-configure sa klasikong paraan: CLI/GUI/NETCONF.

Manu-manong, mga script, pagmamay-ari na mga kagamitan.

Ang susunod na artikulo sa serye ay iuukol sa underlay nang mas detalyado.

Maglatag

Ang Overlay ay isang virtual na network ng mga tunnel na nakaunat sa ibabaw ng Underlay, binibigyang-daan nito ang mga VM ng isang kliyente na makipag-ugnayan sa isa't isa, habang nagbibigay ng paghihiwalay mula sa ibang mga kliyente.

Ang data ng kliyente ay naka-encapsulate sa ilang tunneling header para sa paghahatid sa pampublikong network.

Kaya't ang mga VM ng isang kliyente (isang serbisyo) ay maaaring makipag-usap sa isa't isa sa pamamagitan ng Overlay, nang hindi man lang alam kung anong landas ang aktwal na tinatahak ng packet.

Ang overlay ay maaaring, halimbawa, tulad ng nabanggit ko sa itaas:

• GRE tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVE

Ang isang overlay na network ay karaniwang naka-configure at pinapanatili sa pamamagitan ng isang sentral na controller. Mula dito, ang configuration, Control Plane at Data Plane ay inihahatid sa mga device na nagruruta at nag-encapsulate ng trapiko ng kliyente. Medyo sa ibaba Tingnan natin ito sa mga halimbawa.

Oo, ito ang SDN sa pinakadalisay nitong anyo.

Mayroong dalawang pangunahing magkaibang mga diskarte sa pag-aayos ng isang Overlay network:

1. Overlay sa ToR
2. Overlay mula sa host

Overlay sa ToR

Maaaring magsimula ang overlay sa access switch (ToR) na nakatayo sa rack, gaya ng nangyayari, halimbawa, sa kaso ng isang VXLAN fabric.

Ito ay isang mekanismong sinubok sa oras sa mga network ng ISP at sinusuportahan ito ng lahat ng nagtitinda ng kagamitan sa network.

Gayunpaman, sa kasong ito, ang switch ng ToR ay dapat na mapaghihiwalay ang iba't ibang mga serbisyo, ayon sa pagkakabanggit, at ang administrator ng network ay dapat, sa isang tiyak na lawak, makipagtulungan sa mga administrator ng virtual machine at gumawa ng mga pagbabago (kahit na awtomatiko) sa pagsasaayos ng mga device. .

Dito ko ire-refer ang mambabasa sa isang artikulo tungkol sa VxLAN sa Habré ang dati nating kaibigan @bormoglotx.
Dito sa mga presentasyon kasama si ENOG Ang mga diskarte sa pagbuo ng isang DC network na may tela ng EVPN VXLAN ay inilarawan nang detalyado.

At para sa mas kumpletong pagsasawsaw sa katotohanan, maaari mong basahin ang aklat ni Tsiska Isang Moderno, Bukas, at Nasusukat na Tela: VXLAN EVPN.

Tandaan ko na ang VXLAN ay isang paraan lamang ng encapsulation at ang pagwawakas ng mga tunnel ay maaaring mangyari hindi sa ToR, ngunit sa host, tulad ng nangyayari sa kaso ng OpenStack, halimbawa.

Gayunpaman, ang tela ng VXLAN, kung saan nagsisimula ang overlay sa ToR, ay isa sa mga naitatag na disenyo ng overlay na network.

Overlay mula sa host

Ang isa pang diskarte ay ang simulan at wakasan ang mga tunnel sa dulong host.
Sa kasong ito, ang network (Underlay) ay nananatiling simple at static hangga't maaari.
At ang host mismo ang gumagawa ng lahat ng kinakailangang encapsulation.

Siyempre, kakailanganin nito ang pagpapatakbo ng isang espesyal na aplikasyon sa mga host, ngunit sulit ito.

Una, ang pagpapatakbo ng isang kliyente sa isang Linux machine ay mas madali o, sabihin nating, kahit na posible, habang nasa isang switch ay malamang na kailangan mong bumaling sa pagmamay-ari na mga solusyon sa SDN, na pumapatay sa ideya ng multi-vendor.

Pangalawa, ang switch ng ToR sa kasong ito ay maaaring iwanang simple hangga't maaari, parehong mula sa punto ng view ng Control Plane at Data Plane. Sa katunayan, kung gayon hindi nito kailangang makipag-usap sa controller ng SDN, at hindi rin nito kailangang mag-imbak ng mga network/ARP ng lahat ng konektadong kliyente - sapat na upang malaman ang IP address ng pisikal na makina, na lubos na nagpapadali sa paglipat/ mga routing table.

Sa serye ng ADSM, pinili ko ang overlay na diskarte mula sa host - pagkatapos ay pinag-uusapan lang namin ito at hindi kami babalik sa pabrika ng VXLAN.

Ito ay pinakamadaling tumingin sa mga halimbawa. At bilang isang paksa ng pagsubok ay kukuha kami ng OpenSource SDN platform na OpenContrail, na kilala ngayon bilang Tela ng Tungsten.

Sa dulo ng artikulo ay magbibigay ako ng ilang mga saloobin sa pagkakatulad sa OpenFlow at OpenvSwitch.

Paggamit ng Tungsten Fabric bilang isang halimbawa

Ang bawat pisikal na makina ay mayroon vRouter - isang virtual na router na nakakaalam tungkol sa mga network na konektado dito at kung aling mga kliyente sila nabibilang - mahalagang isang PE router. Para sa bawat kliyente, nagpapanatili ito ng nakahiwalay na routing table (basahin ang VRF). At talagang ginagawa ng vRouter ang Overlay tunneling.

Ang kaunti pa tungkol sa vRouter ay nasa dulo ng artikulo.

Ang bawat VM na matatagpuan sa hypervisor ay konektado sa vRouter ng makina na ito sa pamamagitan ng TAP interface.

Tapikin - Terminal Access Point - isang virtual na interface sa Linux kernel na nagpapahintulot sa pakikipag-ugnayan sa network.

Kung mayroong ilang mga network sa likod ng vRouter, pagkatapos ay isang virtual na interface ay nilikha para sa bawat isa sa kanila, kung saan ang isang IP address ay itinalaga - ito ang magiging default na gateway address.
Ang lahat ng mga network ng isang kliyente ay inilalagay sa isa VRF (isang mesa), iba-iba - sa iba't ibang mga.
Gagawa ako ng disclaimer dito na hindi lahat ay napakasimple, at ipapadala ko ang matanong na mambabasa sa dulo ng artikulo.

Upang ang mga vRouter ay maaaring makipag-usap sa isa't isa, at naaayon ang mga VM na matatagpuan sa likod nila, nagpapalitan sila ng impormasyon sa pagruruta sa pamamagitan ng SDN controller.

Upang makalabas sa labas ng mundo, mayroong exit point mula sa matrix - isang virtual network gateway VNGW — Virtual Network GateWay (aking termino).

Ngayon tingnan natin ang mga halimbawa ng mga komunikasyon - at magkakaroon ng kalinawan.

Komunikasyon sa loob ng isang pisikal na makina

Nais ng VM0 na magpadala ng isang packet sa VM2. Ipagpalagay natin sa ngayon na ito ay isang solong client VM.

Data Plane

1. Ang VM-0 ay may default na ruta sa eth0 na interface nito. Ang pakete ay ipinadala doon.
   Ang interface na ito eth0 ay aktwal na konektado sa virtual na router vRouter sa pamamagitan ng TAP interface tap0.
2. Sinusuri ng vRouter kung saang interface napunta ang packet, ibig sabihin, kung saang client (VRF) ito kabilang, at sinusuri ang address ng tatanggap sa routing table ng client na ito.
3. Dahil natukoy na ang tatanggap sa parehong makina ay nasa ibang port, ipinapadala lang ng vRouter ang packet dito nang walang karagdagang mga header - para sa kasong ito, ang vRouter ay mayroon nang ARP record.

Sa kasong ito, ang packet ay hindi pumapasok sa pisikal na network - ito ay iruruta sa loob ng vRouter.

Pagkontrol ng Plane

Kapag nagsimula ang virtual machine, sasabihin ito ng hypervisor:

• Ang kanyang sariling IP address.
• Ang default na ruta ay sa pamamagitan ng IP address ng vRouter sa network na ito.

Ang hypervisor ay nag-uulat sa vRouter sa pamamagitan ng isang espesyal na API:

• Ano ang kailangan mo upang lumikha ng isang virtual na interface.
• Anong uri ng virtual network ang kailangan nitong (VM) na gawin?
• Aling VRF (VN) ang isailalim nito.
• Isang static na entry ng ARP para sa VM na ito - kung aling interface ang nasa likod ng IP address nito at kung saang MAC address ito nauugnay.

Muli, ang aktwal na pamamaraan ng pakikipag-ugnayan ay pinasimple para sa kapakanan ng pag-unawa sa konsepto.

Kaya, nakikita ng vRouter ang lahat ng VM ng isang kliyente sa isang partikular na makina bilang mga direktang konektadong network at maaaring mag-ruta sa pagitan ng mga ito mismo.

Ngunit ang VM0 at VM1 ay nabibilang sa iba't ibang mga kliyente at, nang naaayon, ay nasa iba't ibang mga talahanayan ng vRouter.

Kung maaari silang makipag-usap nang direkta sa isa't isa ay depende sa mga setting ng vRouter at disenyo ng network.
Halimbawa, kung ang mga VM ng parehong kliyente ay gumagamit ng mga pampublikong address, o ang NAT ay nangyayari sa vRouter mismo, pagkatapos ay maaaring gawin ang direktang pagruruta sa vRouter.

Sa kabaligtaran na sitwasyon, posibleng tumawid sa mga puwang ng address - kailangan mong dumaan sa isang NAT server upang makakuha ng pampublikong address - ito ay katulad ng pag-access sa mga panlabas na network, na tinatalakay sa ibaba.

Komunikasyon sa pagitan ng mga VM na matatagpuan sa iba't ibang pisikal na makina

Data Plane

1. Ang simula ay eksaktong pareho: Nagpapadala ang VM-0 ng isang packet na may patutunguhan na VM-7 (172.17.3.2) sa default nito.
2. Natanggap ito ng vRouter at sa pagkakataong ito ay makikita na ang destinasyon ay nasa ibang makina at naa-access sa pamamagitan ng Tunnel0.
3. Una, nagsabit ito ng label ng MPLS na nagpapakilala sa malayong interface, upang sa reverse side ay matukoy ng vRouter kung saan ilalagay ang packet na ito nang walang karagdagang mga paghahanap.

   

4. Ang Tunnel0 ay may pinagmulan 10.0.0.2, patutunguhan: 10.0.1.2.
   Nagdaragdag ang vRouter ng mga header ng GRE (o UDP) at isang bagong IP sa orihinal na packet.
5. Ang vRouter routing table ay may default na ruta sa pamamagitan ng ToR1 address 10.0.0.1. Doon niya ipinapadala.

   
   

6. Ang ToR1, bilang miyembro ng Underlay network, ay alam (halimbawa, sa pamamagitan ng OSPF) kung paano makarating sa 10.0.1.2 at ipapadala ang packet sa ruta. Tandaan na ang ECMP ay pinagana dito. Mayroong dalawang nexthop sa ilustrasyon, at iba't ibang mga thread ang pag-uuri-uriin sa kanila ayon sa hash. Sa kaso ng isang tunay na pabrika, magkakaroon ng mas malamang na 4 na nexthop.

   Kasabay nito, hindi niya kailangang malaman kung ano ang nasa ilalim ng panlabas na header ng IP. Iyon ay, sa katunayan, sa ilalim ng IP maaaring mayroong isang sandwich ng IPv6 sa ibabaw ng MPLS sa ibabaw ng Ethernet sa paglipas ng sa MPLS sa paglipas ng sa GRE sa paglipas ng sa Griyego.

7. Alinsunod dito, sa panig ng pagtanggap, inalis ng vRouter ang GRE at, gamit ang tag ng MPLS, nauunawaan kung saang interface dapat ipadala ang packet na ito, i-strip ito at ipadala ito sa orihinal nitong anyo sa tatanggap.

Pagkontrol ng Plane

Kapag sinimulan mo ang kotse, ang parehong bagay ay nangyayari tulad ng inilarawan sa itaas.

At kasama ang mga sumusunod:

• Para sa bawat kliyente, naglalaan ang vRouter ng MPLS tag. Ito ang label ng serbisyo ng L3VPN, kung saan paghihiwalayin ang mga kliyente sa loob ng parehong pisikal na makina.
  

  Sa katunayan, ang MPLS tag ay palaging inilalaan nang walang kondisyon ng vRouter - pagkatapos ng lahat, hindi alam nang maaga na ang makina ay makikipag-ugnayan lamang sa iba pang mga makina sa likod ng parehong vRouter at ito ay malamang na hindi totoo.

• Ang vRouter ay nagtatatag ng isang koneksyon sa SDN controller gamit ang BGP protocol (o katulad nito - sa kaso ng TF, ito ay XMPP 0_o).
• Sa pamamagitan ng session na ito, ang vRouter ay nag-uulat ng mga ruta sa mga konektadong network sa SDN controller:
  • Address ng network
  • Paraan ng encapsulation (MPLSoGRE, MPLSoUDP, VXLAN)
  • Tag ng kliyente ng MPLS
  • Ang iyong IP address bilang nexthop

• Ang SDN controller ay tumatanggap ng mga ganoong ruta mula sa lahat ng konektadong vRouter at ipinapakita ang mga ito sa iba. Iyon ay, ito ay gumaganap bilang isang Reflector ng Ruta.

Ang parehong bagay ay nangyayari sa kabaligtaran ng direksyon.

Maaaring magbago ang overlay kahit man lang bawat minuto. Ito ay halos kung ano ang nangyayari sa mga pampublikong ulap, kung saan ang mga kliyente ay regular na nagsisimula at nagsasara ng kanilang mga virtual machine.

Pinangangasiwaan ng central controller ang lahat ng pagiging kumplikado ng pagpapanatili ng configuration at pagsubaybay sa mga switching/routing table sa vRouter.

Sa halos pagsasalita, ang controller ay nakikipag-ugnayan sa lahat ng vRouters sa pamamagitan ng BGP (o isang katulad na protocol) at nagpapadala lamang ng impormasyon sa pagruruta. Ang BGP, halimbawa, ay mayroon nang Address-Family para ihatid ang paraan ng encapsulation MPLS-in-GRE o MPLS-in-UDP.

Kasabay nito, ang pagsasaayos ng network ng Underlay ay hindi nagbabago sa anumang paraan, na, sa pamamagitan ng paraan, ay mas mahirap na i-automate, at mas madaling masira sa isang mahirap na paggalaw.

Lumabas sa labas ng mundo

Sa isang lugar ang simulation ay dapat magtapos, at kailangan mong lumabas sa virtual na mundo patungo sa tunay. At kailangan mo ng gateway ng payphone.

Dalawang diskarte ang ginagawa:

1. Naka-install ang isang hardware router.
2. Inilunsad ang isang appliance na nagpapatupad ng mga function ng isang router (oo, kasunod ng SDN, nakatagpo din kami ng VNF). Tawagin natin itong isang virtual na gateway.

Ang bentahe ng pangalawang diskarte ay murang pahalang na scalability - walang sapat na kapangyarihan - naglunsad kami ng isa pang virtual machine na may gateway. Sa anumang pisikal na makina, nang hindi kinakailangang maghanap ng mga libreng rack, unit, power output, bilhin ang mismong hardware, i-transport ito, i-install ito, i-switch ito, i-configure ito, at pagkatapos ay baguhin din ang mga sira na bahagi dito.

Ang mga disadvantages ng isang virtual gateway ay ang isang unit ng isang pisikal na router ay mas malakas pa rin kaysa sa isang multi-core virtual machine, at ang software nito, na iniayon sa sarili nitong hardware base, ay gumagana nang mas matatag (hindi). Mahirap ding tanggihan ang katotohanang gumagana lang ang hardware at software complex, na nangangailangan lamang ng configuration, habang ang paglulunsad at pagpapanatili ng virtual gateway ay isang gawain para sa malalakas na inhinyero.

Sa isang paa, ang gateway ay tumitingin sa Overlay virtual network, tulad ng isang regular na Virtual Machine, at maaaring makipag-ugnayan sa lahat ng iba pang VM. Kasabay nito, maaari nitong wakasan ang mga network ng lahat ng mga kliyente at, nang naaayon, magsagawa ng pagruruta sa pagitan nila.

Sa kabilang paa nito, tumitingin ang gateway sa backbone network at alam kung paano makapunta sa Internet.

Data Plane

Ibig sabihin, ganito ang proseso:

1. Ang VM-0, na nag-default sa parehong vRouter, ay nagpapadala ng isang packet na may patutunguhan sa labas ng mundo (185.147.83.177) sa interface ng eth0.
2. Natanggap ng vRouter ang packet na ito at hinahanap ang patutunguhang address sa routing table - hinahanap ang default na ruta sa pamamagitan ng VNGW1 gateway sa pamamagitan ng Tunnel 1.
   Nakikita rin niya na ito ay isang GRE tunnel na may SIP 10.0.0.2 at DIP 10.0.255.2, at kailangan din niyang ilakip muna ang MPLS label ng kliyenteng ito, na inaasahan ng VNGW1.
3. Ang vRouter ay nag-pack ng paunang pakete na may MPLS, GRE at mga bagong IP header at ipinapadala ito sa ToR1 10.0.0.1 bilang default.
4. Ang pinagbabatayan na network ay naghahatid ng packet sa gateway na VNGW1.
5. Ang VNGW1 gateway ay nag-aalis ng GRE at MPLS tunneling header, nakikita ang patutunguhang address, kumunsulta sa routing table nito at nauunawaan na ito ay nakadirekta sa Internet - iyon ay, sa pamamagitan ng Full View o Default. Kung kinakailangan, nagsasagawa ng pagsasalin ng NAT.
6. Maaaring mayroong isang regular na network ng IP mula sa VNGW hanggang sa hangganan, na hindi malamang.
   Maaaring mayroong isang klasikong MPLS network (IGP+LDP/RSVP TE), maaaring mayroong back fabric na may BGP LU o isang GRE tunnel mula sa VNGW hanggang sa hangganan sa pamamagitan ng isang IP network.
   Magkagayunman, ginagawa ng VNGW1 ang mga kinakailangang encapsulation at ipinapadala ang paunang pakete patungo sa hangganan.

Ang trapiko sa kabilang direksyon ay dumadaan sa parehong mga hakbang sa kabaligtaran na pagkakasunud-sunod.

1. Ibinababa ng hangganan ang packet sa VNGW1
2. Hinubaran niya ito, tinitingnan ang address ng tatanggap at nakitang naa-access siya sa pamamagitan ng Tunnel1 tunnel (MPLSoGRE o MPLSoUDP).
3. Alinsunod dito, nag-attach ito ng MPLS label, isang GRE/UDP header at isang bagong IP at ipinapadala ito sa ToR3 10.0.255.1 nito.
   Ang tunnel destination address ay ang IP address ng vRouter kung saan matatagpuan ang target na VM - 10.0.0.2.
4. Ang pinagbabatayan na network ay naghahatid ng packet sa nais na vRouter.
5. Ang target na vRouter ay nagbabasa ng GRE/UDP, kinikilala ang interface gamit ang MPLS label at nagpapadala ng hubad na IP packet sa TAP interface nito na nauugnay sa eth0 ng VM.

Pagkontrol ng Plane

Ang VNGW1 ay nagtatatag ng isang BGP na kapitbahayan na may isang controller ng SDN, kung saan natatanggap nito ang lahat ng impormasyon sa pagruruta tungkol sa mga kliyente: kung aling IP address (vRouter) ang nasa likod ng kung aling kliyente, at kung aling label ng MPLS ang natukoy nito.

Katulad nito, siya mismo ang nagpapaalam sa SDN controller ng default na ruta na may label ng kliyenteng ito, na nagpapahiwatig ng kanyang sarili bilang nexthop. At pagkatapos ang default na ito ay dumating sa vRouters.

Sa VNGW, karaniwang nangyayari ang pagsasama-sama ng ruta o pagsasalin ng NAT.

At sa kabilang direksyon, eksaktong ipinapadala nito ang pinagsama-samang rutang ito sa session na may mga hangganan o Ruta Reflectors. At mula sa kanila natatanggap nito ang default na ruta o Full-View, o iba pa.

Sa mga tuntunin ng encapsulation at palitan ng trapiko, ang VNGW ay hindi naiiba sa vRouter.
Kung palawakin mo nang kaunti ang saklaw, maaari kang magdagdag ng iba pang network device sa mga VNGW at vRouter, gaya ng mga firewall, paglilinis ng trapiko o mga enrichment farm, IPS, at iba pa.

At sa tulong ng sunud-sunod na paglikha ng mga VRF at tamang anunsyo ng mga ruta, maaari mong pilitin ang trapiko na mag-loop sa paraang gusto mo, na tinatawag na Service Chaining.

Ibig sabihin, dito rin kumikilos ang controller ng SDN bilang Ruta-Reflector sa pagitan ng mga VNGW, vRouter at iba pang network device.

Ngunit sa katunayan, ang controller ay naglalabas din ng impormasyon tungkol sa ACL at PBR (Policy Based Routing), na nagiging sanhi ng mga indibidwal na daloy ng trapiko upang pumunta nang iba kaysa sa sinasabi sa kanila ng ruta.

FAQ

Bakit mo patuloy na ginagawa ang GRE/UDP remark?

Well, sa pangkalahatan, ito ay masasabing tiyak sa Tungsten Fabric - hindi mo na kailangang isaalang-alang ito.

Ngunit kung kukunin natin ito, ang TF mismo, habang OpenContrail pa rin, ay sumusuporta sa parehong mga encapsulation: MPLS sa GRE at MPLS sa UDP.

Maganda ang UDP dahil sa Source Port napakadaling mag-encode ng hash function mula sa orihinal na IP+Proto+Port sa header nito, na magbibigay-daan sa iyong gawin ang pagbabalanse.

Sa kaso ng GRE, sayang, mayroon lamang mga panlabas na IP at GRE header, na pareho para sa lahat ng naka-encapsulated na trapiko at walang pag-uusap tungkol sa pagbabalanse - ilang mga tao ang maaaring tumingin nang napakalalim sa loob ng packet.

Hanggang sa ilang panahon, ang mga router, kung alam nila kung paano gumamit ng mga dynamic na tunnel, ay ginawa lamang ito sa MPLSoGRE, at kamakailan lamang ay natutunan nilang gumamit ng MPLSoUDP. Samakatuwid, palagi kaming kailangang gumawa ng tala tungkol sa posibilidad ng dalawang magkaibang encapsulation.

In fairness, ito ay nagkakahalaga ng noting na ang TF ay ganap na sumusuporta sa L2 connectivity gamit ang VXLAN.

Nangako kang gumuhit ng mga parallel sa OpenFlow.
Talagang hinihiling nila ito. Ang vSwitch sa parehong OpenStack ay gumagawa ng halos katulad na mga bagay, gamit ang VXLAN, na, sa pamamagitan ng paraan, ay mayroon ding UDP header.

Sa Data Plane gumagana ang mga ito nang halos pareho; ang Control Plane ay malaki ang pagkakaiba. Gumagamit ang Tungsten Fabric ng XMPP upang maghatid ng impormasyon sa pagruruta sa vRouter, habang ang OpenStack ay nagpapatakbo ng Openflow.

Maaari mo bang sabihin sa akin ng kaunti pa tungkol sa vRouter?
Ito ay nahahati sa dalawang bahagi: vRouter Agent at vRouter Forwarder.

Ang una ay tumatakbo sa User Space ng host OS at nakikipag-ugnayan sa SDN controller, na nagpapalitan ng impormasyon tungkol sa mga ruta, VRF at ACL.

Ang pangalawa ay nagpapatupad ng Data Plane - kadalasan sa Kernel Space, ngunit maaari ding tumakbo sa SmartNICs - mga network card na may CPU at isang hiwalay na programmable switching chip, na nagbibigay-daan sa iyong alisin ang load mula sa CPU ng host machine, at gawing mas mabilis at higit pa ang network. mahuhulaan.

Ang isa pang posibleng senaryo ay ang vRouter ay isang DPDK application sa User Space.

Nagpapadala ang vRouter Agent ng mga setting sa vRouter Forwarder.

Ano ang isang Virtual Network?
Nabanggit ko sa simula ng artikulo tungkol sa VRF na ang bawat nangungupahan ay nakatali sa kanyang sariling VRF. At kung ito ay sapat na para sa isang mababaw na pag-unawa sa pagpapatakbo ng overlay na network, pagkatapos ay sa susunod na pag-ulit kinakailangan na gumawa ng mga paglilinaw.

Karaniwan, sa mga mekanismo ng virtualization, ang entidad ng Virtual Network (maaari mong isaalang-alang ito bilang isang wastong pangngalan) ay ipinakilala nang hiwalay mula sa mga kliyente/nangungupahan/virtual na makina - isang ganap na independiyenteng bagay. At ang Virtual Network na ito ay maaari nang konektado sa pamamagitan ng mga interface sa isang nangungupahan, sa isa pa, sa dalawa, o kahit saan. Kaya, halimbawa, ipinapatupad ang Service Chaining kapag kailangang dumaan ang trapiko sa ilang partikular na node sa kinakailangang pagkakasunud-sunod, sa pamamagitan lamang ng paggawa at pagkonekta ng mga Virtual Network sa tamang pagkakasunod-sunod.

Samakatuwid, dahil dito, walang direktang pagsusulatan sa pagitan ng Virtual Network at ng nangungupahan.

Konklusyon

Ito ay isang napakababaw na paglalarawan ng pagpapatakbo ng isang virtual network na may overlay mula sa host at isang controller ng SDN. Ngunit kahit anong virtualization platform ang pipiliin mo ngayon, gagana ito sa katulad na paraan, maging ito VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric o Juniper Contrail. Mag-iiba ang mga ito sa mga uri ng mga encapsulation at header, mga protocol para sa paghahatid ng impormasyon sa mga end network device, ngunit ang prinsipyo ng isang software-configurable overlay network na tumatakbo sa ibabaw ng medyo simple at static na underlay na network ay mananatiling pareho.
Masasabi nating ngayon ang SDN batay sa isang overlay na network ay nanalo sa larangan ng paglikha ng pribadong ulap. Gayunpaman, hindi ito nangangahulugan na ang Openflow ay walang lugar sa modernong mundo - ginagamit ito sa OpenStacke at sa parehong VMWare NSX, sa pagkakaalam ko, ginagamit ito ng Google upang i-set up ang underground na network.

Sa ibaba ay nagbigay ako ng mga link sa mas detalyadong materyal kung gusto mong pag-aralan ang isyu nang mas malalim.

At paano ang ating Underlay?

Ngunit sa pangkalahatan, wala. Hindi siya nagbago sa buong paraan. Ang kailangan lang niyang gawin sa kaso ng isang overlay mula sa host ay ang mga ruta ng pag-update at mga ARP habang lumalabas at nawawala ang vRouter/VNGW at nagdadala ng mga packet sa pagitan nila.

Bumuo tayo ng listahan ng mga kinakailangan para sa Underlay network.

1. Magagawang gumamit ng ilang uri ng routing protocol, sa aming sitwasyon - BGP.
2. Magkaroon ng malawak na bandwidth, mas mabuti nang walang oversubscription, upang ang mga packet ay hindi mawala dahil sa labis na karga.
3. Ang pagsuporta sa ECMP ay isang mahalagang bahagi ng tela.
4. Makapagbigay ng QoS, kabilang ang mga nakakalito na bagay tulad ng ECN.
5. Ang pagsuporta sa NETCONF ay isang pundasyon para sa hinaharap.

Naglaan ako ng napakakaunting oras dito sa gawain ng Underlay network mismo. Ito ay dahil mamaya sa serye ay pagtutuunan ko ito ng pansin, at ang Overlay na lang ang ating idadaan sa pagpasa.

Malinaw, mahigpit kong nililimitahan tayong lahat sa pamamagitan ng paggamit bilang halimbawa ng isang DC network na binuo sa isang Cloz factory na may purong IP routing at isang overlay mula sa host.

Gayunpaman, tiwala ako na ang anumang network na may disenyo ay maaaring ilarawan sa mga pormal na termino at awtomatiko. Ang layunin ko lang dito ay maunawaan ang mga diskarte sa automation, at hindi malito ang lahat sa pamamagitan ng paglutas ng problema sa isang pangkalahatang anyo.

Bilang bahagi ng ADSM, pinaplano namin ni Roman Gorge na mag-publish ng isang hiwalay na isyu tungkol sa virtualization ng computing power at ang pakikipag-ugnayan nito sa network virtualization. Manatiling nakikipag-ugnayan.

Kapaki-pakinabang na mga link

• Tungsten Fabric Archvitecture.
• tungkol sa:cloud. 6 na oras tungkol sa Yandex.Cloud, na sumasaklaw din sa virtual network sa TF.
• Ano ang Open vSwitch?
• Panimula sa VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Isang Framework para sa Pag-overlay ng Virtualized Layer 2 Networks sa Layer 3 Networks.
  
• Scaleway approach sa VXLAN EVPN Fabric. Pinag-uusapan nito ang tungkol sa buong network ng DC, kabilang ang Underlay, Overlay, mga diskarte sa multi-homing at pamamahala.

Salamat

• Roman Gorga - dating host ng linkmeup podcast at ngayon ay isang eksperto sa larangan ng mga cloud platform. Para sa mga komento at pag-edit. Well, naghihintay kami para sa kanyang mas malalim na artikulo sa virtualization sa malapit na hinaharap.
• Alexander Shalimov - aking kasamahan at dalubhasa sa larangan ng virtual network development. Para sa mga komento at pag-edit.
• Valentin Sinitsyn - aking kasamahan at dalubhasa sa larangan ng Tungsten Fabric. Para sa mga komento at pag-edit.
• Artyom Chernobay - ilustrador linkmeup. Para sa KDPV.
• Alexander Limonov. Para sa "automato" na meme.

Pinagmulan: www.habr.com