ProHoster > Blogs > Administrācija > Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Š’ iepriekŔējais numurs Es aprakstÄ«ju tÄ«kla automatizācijas sistēmu. Pēc dažu cilvēku domām, pat Ŕī pirmā pieeja problēmai jau ir atrisinājusi dažus jautājumus. Un tas mani ļoti iepriecina, jo mÅ«su mērÄ·is ciklā nav piesegt Ansible ar Python skriptiem, bet gan izveidot sistēmu.

Tas pats regulējums nosaka kārtību, kādā mēs izskatīsim jautājumu.
Un tÄ«kla virtualizācija, kurai Å”is izdevums ir veltÄ«ts, Ä«paÅ”i neietilpst ADSM tēmā, kurā mēs analizējam automatizāciju.

Bet paskatīsimies uz to no cita leņķa.

Daudzi pakalpojumi jau ilgu laiku ir izmantojuÅ”i vienu un to paÅ”u tÄ«klu. Piemēram, telekomunikāciju operatora gadÄ«jumā tas ir 2G, 3G, LTE, platjosla un B2B. LÄ«dzstrāvas gadÄ«jumā: savienojamÄ«ba dažādiem klientiem, internets, bloku krātuve, objektu krātuve.

Un visiem pakalpojumiem ir nepiecieŔama izolācija vienam no otra. Šādi parādījās pārklājuma tīkli.

Un visi pakalpojumi nevēlas gaidīt, kamēr persona tos manuāli konfigurēs. Tā parādījās orķestranti un SDN.

Pirmā pieeja sistemātiskai tīkla vai drīzāk tā daļas automatizācijai jau sen ir pieņemta un ieviesta daudzās vietās: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Ar to mēs Å”odien nodarbosimies.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

saturs

  • iemesli
  • Vārdu krājums
  • ApakÅ”klājs - fiziskais tÄ«kls
  • Pārklājums - virtuālais tÄ«kls
    • Pārklājums ar ToR
    • Pārklājums no saimniekdatora
    • Kā piemēru izmantojot volframa audumu
      • Komunikācija vienā fiziskā maŔīnā
      • Saziņa starp virtuālajām maŔīnām, kas atrodas dažādās fiziskās iekārtās
      • Izeja uz ārpasauli

  • FAQ
  • Secinājums
  • NoderÄ«gas saites

iemesli

Un, tā kā mēs par to runājam, ir vērts pieminēt tÄ«kla virtualizācijas priekÅ”noteikumus. PatiesÄ«bā Å”is process nesākās vakar.

JÅ«s droÅ”i vien esat dzirdējuÅ”i vairāk nekā vienu reizi, ka tÄ«kls vienmēr ir bijis jebkuras sistēmas inertākā daļa. Un tā ir taisnÄ«ba visās nozÄ«mēs. TÄ«kls ir pamats, uz kura balstās viss, un veikt izmaiņas tajā ir diezgan grÅ«ti - pakalpojumi to nepanes, kad tÄ«kls nedarbojas. Bieži vien viena mezgla ekspluatācijas pārtraukÅ”ana var likvidēt lielu daļu lietojumprogrammu un ietekmēt daudzus klientus. Daļēji tāpēc tÄ«kla komanda var pretoties jebkādām izmaiņām, jo ā€‹ā€‹tagad tā kaut kā darbojas (mēs varbÅ«t pat nezinām, kā), taču Å”eit ir jākonfigurē kaut kas jauns, un nav zināms, kā tas ietekmēs tÄ«klu.

Lai negaidītu, kamēr tīkla veidotāji ievietos VLAN un nereģistrētu nevienu pakalpojumu katrā tīkla mezglā, cilvēki nāca klajā ar ideju izmantot pārklājumus - pārklājuma tīklus -, kuru daudzveidība ir ļoti dažāda: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE utt.

Viņu pievilcÄ«ba slēpjas divās vienkārŔās lietās:

  • Ir konfigurēti tikai gala mezgli ā€” transporta mezgli nav jāpieskaras. Tas ievērojami paātrina procesu un dažreiz ļauj pilnÄ«bā izslēgt tÄ«kla infrastruktÅ«ras nodaļu no jaunu pakalpojumu ievieÅ”anas procesa.
  • Slodze ir paslēpta dziļi galvenēs - tranzÄ«ta mezgliem nekas nav jāzina par to, par adresÄ“Å”anu saimniekos vai par pārklājuma tÄ«kla marÅ”rutiem. Tas nozÄ«mē, ka tabulās jāsaglabā mazāk informācijas, kas nozÄ«mē vienkārŔākas/lētākas ierÄ«ces izmantoÅ”anu.

Šajā ne visai pilnvērtīgajā jautājumā es neplānoju analizēt visas iespējamās tehnoloģijas, bet drīzāk aprakstu pārklājuma tīklu darbības ietvaru DC.

Visa sērija aprakstīs datu centru, kas sastāv no identisku plauktu rindām, kurās ir uzstādīta viena un tā pati servera iekārta.

Šis aprīkojums darbina virtuālās maŔīnas/konteinerus/bez servera, kas ievieŔ pakalpojumus.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Vārdu krājums

Cilpā serveris Es nosaukÅ”u programmu, kas realizē klienta-servera komunikācijas servera pusi.

Plauktos esoŔās fiziskās maŔīnas sauc par serveriem nē mēs bÅ«sim.

Fiziskā maŔīna ā€” x86 dators uzstādÄ«ts statÄ«vā. Visbiežāk lietotais termins uzņēmēja. Tā mēs to sauksim "maŔīna"Or uzņēmēja.

Hipervizors - lietojumprogramma, kas darbojas fiziskā iekārtā, kas emulē fiziskos resursus, kuros darbojas virtuālās maŔīnas. Dažreiz literatÅ«rā un internetā vārds ā€œhipervizorsā€ tiek lietots kā ā€œsaimniekaā€ sinonÄ«ms.

Virtuālā iekārta - operētājsistēma, kas darbojas fiziskā maŔīnā hipervizora augÅ”pusē. Mums Å”ajā ciklā nav Ä«sti svarÄ«gi, vai tā patiesÄ«bā ir virtuālā maŔīna vai tikai konteiners. Sauksim to"VMĀ«

ÄŖrnieks ir plaÅ”s jēdziens, ko Å”ajā rakstā definÄ“Å”u kā atseviŔķu pakalpojumu vai atseviŔķu klientu.

Daudzkārtēja Ä«re vai multiÄ«re - vienas un tās paÅ”as lietojumprogrammas izmantoÅ”ana dažādiem klientiem/pakalpojumiem. Tajā paŔā laikā klientu izolÄ“Å”ana viens no otra tiek panākta, pateicoties lietojumprogrammu arhitektÅ«rai, nevis ar atseviŔķi darbināmiem gadÄ«jumiem.

ToR ā€” slēdža augÅ”daļa - statÄ«vā uzstādÄ«ts slēdzis, kuram ir pievienotas visas fiziskās iekārtas.

Papildus ToR topoloÄ£ijai dažādi pakalpojumu sniedzēji praktizē End of Row (EoR) vai Middle of Row (lai gan pēdējais ir nievājoÅ”s retums, un es neesmu redzējis MoR saÄ«sinājumu).

ApakÅ”klājuma tÄ«kls vai pamatā esoÅ”ais tÄ«kls vai apakÅ”klājs ir fiziskā tÄ«kla infrastruktÅ«ra: slēdži, marÅ”rutētāji, kabeļi.

Pārklājuma tīkls vai pārklājuma tīkls vai pārklājums - virtuāls tuneļu tīkls, kas darbojas virs fiziskā.

L3 audums vai IP audums - pārsteidzoÅ”s cilvēces izgudrojums, kas ļauj izvairÄ«ties no STP atkārtoÅ”anas un TRILL mācÄ«Å”anās intervijām. Koncepcija, kurā viss tÄ«kls lÄ«dz piekļuves lÄ«menim ir tikai L3, bez VLAN un attiecÄ«gi milzÄ«giem paplaÅ”inātiem apraides domēniem. Nākamajā daļā apskatÄ«sim, no kurienes nāk vārds ā€œrÅ«pnÄ«caā€.

SDN - ProgrammatÅ«ras definēts tÄ«kls. Diez vai nepiecieÅ”ams ievads. TÄ«kla pārvaldÄ«bas pieeja, kur izmaiņas tÄ«klā veic nevis cilvēks, bet gan programma. Parasti tas nozÄ«mē vadÄ«bas plaknes pārvietoÅ”anu ārpus gala tÄ«kla ierÄ«cēm uz kontrolieri.

NFV ā€” TÄ«kla funkciju virtualizācija ā€” tÄ«kla ierīču virtualizācija, kas liecina, ka dažas tÄ«kla funkcijas var palaist virtuālo maŔīnu vai konteineru veidā, lai paātrinātu jaunu pakalpojumu ievieÅ”anu, organizētu pakalpojumu ķēdi un vienkārŔāku horizontālo mērogojamÄ«bu.

VNF - Virtuālā tÄ«kla funkcija. Konkrēta virtuālā ierÄ«ce: marÅ”rutētājs, slēdzis, ugunsmÅ«ris, NAT, IPS/IDS utt.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tagad es apzināti vienkārÅ”oju aprakstu lÄ«dz konkrētai realizācijai, lai pārāk nesamulsinātu lasÄ«tāju. Lai lasÄ«tu vairāk pārdomātu, es aicinu viņu uz sadaļu atsauces. Turklāt Roma Gorge, kurÅ” kritizē Å”o rakstu par neprecizitātēm, sola uzrakstÄ«t atseviŔķu numuru par serveru un tÄ«kla virtualizācijas tehnoloÄ£ijām, padziļinātāku un uzmanÄ«gāku pret detaļām.

Lielāko daļu tīklu mūsdienās var skaidri iedalīt divās daļās:

ApakÅ”klājs ā€” fizisks tÄ«kls ar stabilu konfigurāciju.
Pārklāt ā€” abstrakcija virs apakÅ”klāja Ä«rnieku izolÄ“Å”anai.

Tas attiecas gan uz lÄ«dzstrāvas gadÄ«jumu (ko mēs analizēsim Å”ajā rakstā), gan uz ISP (kuru mēs neanalizēsim, jo ā€‹ā€‹tas jau ir bijis SDSM). Protams, ar uzņēmumu tÄ«kliem situācija ir nedaudz atŔķirÄ«ga.

Attēls ar fokusu uz tīklu:

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

ApakŔklājs

ApakÅ”klājums ir fizisks tÄ«kls: aparatÅ«ras slēdži un kabeļi. IerÄ«ces pazemē zina, kā sasniegt fiziskās maŔīnas.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tas balstās uz standarta protokoliem un tehnoloÄ£ijām. Ne tikai tāpēc, ka aparatÅ«ras ierÄ«ces lÄ«dz mÅ«sdienām darbojas ar patentētu programmatÅ«ru, kas neļauj ne programmēt mikroshēmu, ne ieviest savus protokolus; attiecÄ«gi ir nepiecieÅ”ama saderÄ«ba ar citiem piegādātājiem un standartizācija.

Bet kāds, piemēram, Google, var atļauties izstrādāt savus slēdžus un atteikties no vispārpieņemtiem protokoliem. Bet LAN_DC nav Google.

ApakÅ”klājums mainās salÄ«dzinoÅ”i reti, jo tā mērÄ·is ir pamata IP savienojamÄ«ba starp fiziskām iekārtām. ApakÅ”klājs neko nezina par pakalpojumiem, klientiem vai nomniekiem, kas darbojas uz tā ā€” tai tikai jānogādā pakotne no vienas iekārtas uz otru.
ApakÅ”klājs varētu bÅ«t Ŕāds:

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

ApakÅ”klājuma tÄ«kls ir konfigurēts klasiskā veidā: CLI/GUI/NETCONF.

Manuāli, skripti, patentētas utilītas.

Nākamais sērijas raksts bÅ«s sÄ«kāk veltÄ«ts apakÅ”klājam.

Pārklāt

Pārklājums ir virtuāls tuneļu tīkls, kas izstiepts virs apakŔklāja, un tas ļauj viena klienta virtuālajām maŔīnām sazināties savā starpā, vienlaikus nodroŔinot izolāciju no citiem klientiem.

Klienta dati ir iekapsulēti dažās tunelÄ“Å”anas galvenēs, lai tos pārraidÄ«tu publiskajā tÄ«klā.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tātad viena klienta (viena pakalpojuma) virtuālās maŔīnas var sazināties savā starpā, izmantojot pārklājumu, pat nezinot, kādu ceļu pakete patiesībā izmanto.

Pārklājums varētu bÅ«t, piemēram, tāds, kādu minēju iepriekÅ”:

  • GRE tunelis
  • VXLAN
  • EVPN
  • L3VPN
  • ŽENĒVE

Pārklājuma tÄ«kls parasti tiek konfigurēts un uzturēts, izmantojot centrālo kontrolleri. No tā konfigurācija, vadÄ«bas plakne un datu plakne tiek piegādāta ierÄ«cēm, kas marÅ”rutē un iekapsulē klienta trafiku. Mazliet zemāk ApskatÄ«sim to ar piemēriem.

Jā, tas ir SDN tīrākajā formā.

Pārklājuma tÄ«kla organizÄ“Å”anai ir divas principiāli atŔķirÄ«gas pieejas:

  1. Pārklājums ar ToR
  2. Pārklājums no saimniekdatora

Pārklājums ar ToR

Pārklājums var sākties no piekļuves slēdža (ToR), kas stāv plauktā, kā tas notiek, piemēram, VXLAN auduma gadījumā.

Šis ir laika pārbaudīts mehānisms ISP tīklos, un visi tīkla iekārtu pārdevēji to atbalsta.

Taču Å”ajā gadÄ«jumā ToR slēdzim jāspēj attiecÄ«gi nodalÄ«t dažādus pakalpojumus un tÄ«kla administratoram zināmā mērā jāsadarbojas ar virtuālās maŔīnas administratoriem un jāveic izmaiņas (kaut arÄ« automātiski) ierīču konfigurācijā. .

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Å eit es atsaukÅ”u lasÄ«tāju uz rakstu par VxLAN vietnē HabrĆ© mÅ«su vecais draugs @bormoglotx.
Šajā prezentācijas ar ENOG ir detalizēti aprakstītas pieejas līdzstrāvas tīkla izveidei ar EVPN VXLAN audumu.

Un, lai pilnīgāk iedziļinātos realitātē, varat izlasīt Tsiskas grāmatu Mūsdienīgs, atvērts un mērogojams audums: VXLAN EVPN.

Es atzÄ«mēju, ka VXLAN ir tikai iekapsulÄ“Å”anas metode, un tuneļu pārtraukÅ”ana var notikt nevis ToR, bet gan resursdatorā, kā tas notiek, piemēram, OpenStack gadÄ«jumā.

Tomēr VXLAN audums, kur pārklājums sākas ar ToR, ir viens no izveidotajiem pārklājuma tīkla dizainiem.

Pārklājums no saimniekdatora

Vēl viena pieeja ir sākt un pārtraukt tuneļus gala saimniekiem.
Å ajā gadÄ«jumā tÄ«kls (apakÅ”klājs) paliek pēc iespējas vienkārŔāks un statiskāks.
Un pats saimnieks veic visu nepiecieŔamo iekapsulēŔanu.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tas, protams, prasÄ«s saimniekdatoros palaist Ä«paÅ”u lietojumprogrammu, taču tas ir tā vērts.

Pirmkārt, klienta palaiÅ”ana Linux datorā ir vienkārŔāka vai, teiksim, pat iespējama, savukārt pārslēdzot, visticamāk, bÅ«s jāgriežas pie patentētiem SDN risinājumiem, kas nogalina ideju par vairākiem piegādātājiem.

Otrkārt, ToR slēdzi Å”ajā gadÄ«jumā var atstāt pēc iespējas vienkārÅ”u gan no vadÄ«bas plaknes, gan no datu plaknes viedokļa. PatieŔām, tad tam nav jāsazinās ar SDN kontrolieri, kā arÄ« nav jāuzglabā visu savienoto klientu tÄ«kli/ARP - pietiek zināt fiziskās maŔīnas IP adresi, kas ievērojami vienkārÅ”o pārslēgÅ”anu/ marÅ”rutÄ“Å”anas tabulas.

ADSM sērijā es izvēlos overlay pieeju no hosta - tad mēs tikai par to runājam un mēs neatgriezīsimies VXLAN rūpnīcā.

Visvieglāk ir aplÅ«kot piemērus. Un kā testa priekÅ”metu mēs izmantosim OpenSource SDN platformu OpenContrail, kas tagad pazÄ«stama kā Volframa audums.

Raksta beigās es sniegŔu dažas domas par analoģiju ar OpenFlow un OpenvSwitch.

Kā piemēru izmantojot volframa audumu

Katrai fiziskajai maŔīnai ir vRouter - virtuāls marÅ”rutētājs, kas zina par tam pievienotajiem tÄ«kliem un kuriem klientiem tie pieder - bÅ«tÄ«bā PE marÅ”rutētājs. Katram klientam tā uztur izolētu marÅ”rutÄ“Å”anas tabulu (lasÄ«t VRF). Un vRouter faktiski veic pārklājuma tunelÄ“Å”anu.

Nedaudz vairāk par vRouter ir raksta beigās.

Katra VM, kas atrodas hipervizorā, ir savienota ar Ŕīs iekārtas vRouter, izmantojot TAP interfeiss.

TAP - Termināļa piekļuves punkts - virtuāls interfeiss Linux kodolā, kas nodroŔina tīkla mijiedarbību.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Ja aiz vRouter ir vairāki tÄ«kli, tad katram no tiem tiek izveidots virtuālais interfeiss, kuram tiek pieŔķirta IP adrese - tā bÅ«s noklusējuma vārtejas adrese.
Visi viena klienta tīkli ir ievietoti vienā VRF (viens galds), dažādas - dažādās.
Å eit es izdarÄ«Å”u atrunu, ka ne viss ir tik vienkārÅ”i, un ziņkārÄ«go lasÄ«tāju nosÅ«tÄ«Å”u uz raksta beigām.

Lai vRouteri varētu sazināties savā starpā un attiecÄ«gi virtuālās maŔīnas, kas atrodas aiz tiem, viņi apmainās ar marÅ”rutÄ“Å”anas informāciju, izmantojot SDN kontrolieris.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Lai izkļūtu ārpasaulē, ir izejas punkts no matricas - virtuālā tÄ«kla vārteja VNGW ā€” virtuālā tÄ«kla vārteja (mans termiņŔ).

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tagad apskatīsim komunikāciju piemērus - un būs skaidrība.

Komunikācija vienā fiziskā maŔīnā

VM0 vēlas nosÅ«tÄ«t paketi uz VM2. Pagaidām pieņemsim, ka Ŕī ir viena klienta virtuālā maŔīna.

Datu plakne

  1. VM-0 ir noklusējuma marÅ”ruts uz eth0 saskarni. Paciņa tiek nosÅ«tÄ«ta tur.
    Å Ä« saskarne eth0 faktiski ir virtuāli savienota ar virtuālo marÅ”rutētāju vRouter, izmantojot TAP saskarni tap0.
  2. vRouter analizē, uz kuru saskarni pakete nonāca, tas ir, kuram klientam (VRF) tā pieder, un pārbauda adresāta adresi, izmantojot Ŕī klienta marÅ”rutÄ“Å”anas tabulu.
  3. Konstatējis, ka adresāts tajā paŔā maŔīnā atrodas citā portā, vRouter vienkārÅ”i nosÅ«ta paketi uz to bez papildu galvenēm - Å”ajā gadÄ«jumā vRouter jau ir ARP ieraksts.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Å ajā gadÄ«jumā pakete neienāk fiziskajā tÄ«klā - tā tiek marÅ”rutēta vRouter iekÅ”pusē.

Vadības plakne

Kad virtuālā maŔīna tiek startēta, hipervizors tai paziņo:

  • Viņas paÅ”as IP adrese.
  • Noklusējuma marÅ”ruts ir caur vRouter IP adresi Å”ajā tÄ«klā.

Hipervizors ziņo vRouter, izmantojot Ä«paÅ”u API:

  • Kas jums nepiecieÅ”ams, lai izveidotu virtuālo saskarni.
  • Kāda veida virtuālais tÄ«kls tam (VM) ir jāizveido?
  • Kuram VRF (VN) to saistÄ«t.
  • Statisks ARP ieraksts Å”ai virtuālajai maŔīnai ā€” kura saskarne atrodas aiz tās IP adreses un ar kuru MAC adresi tā ir saistÄ«ta.

Atkal, faktiskā mijiedarbÄ«bas procedÅ«ra ir vienkārÅ”ota, lai saprastu jēdzienu.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Tādējādi vRouter visas viena klienta virtuālās maŔīnas konkrētajā maŔīnā redz kā tieÅ”i savienotus tÄ«klus un pats var izveidot marÅ”rutu starp tiem.

Bet VM0 un VM1 pieder dažādiem klientiem un attiecīgi atrodas dažādās vRouter tabulās.

Tas, vai viņi var sazināties viens ar otru, ir tieÅ”i atkarÄ«gs no vRouter iestatÄ«jumiem un tÄ«kla dizaina.
Piemēram, ja abu klientu virtuālās maŔīnas izmanto publiskās adreses vai NAT notiek paŔā vRouter, tad var veikt tieÅ”u marÅ”rutÄ“Å”anu uz vRouter.

Pretējā situācijā ir iespējams Ŕķērsot adreÅ”u telpas - jums ir jāiet caur NAT serveri, lai iegÅ«tu publisku adresi - tas ir lÄ«dzÄ«gi kā piekļūt ārējiem tÄ«kliem, par kuriem mēs runāsim tālāk.

Saziņa starp virtuālajām maŔīnām, kas atrodas dažādās fiziskās iekārtās

Datu plakne

  1. Sākums ir tieÅ”i tāds pats: VM-0 nosÅ«ta paketi ar galamērÄ·i VM-7 (172.17.3.2) pēc noklusējuma.
  2. vRouter to saņem un Å”oreiz redz, ka galamērÄ·is atrodas citā maŔīnā un ir pieejams caur Tunnel0.
  3. Pirmkārt, tas uzkarina MPLS etiÄ·eti, kas identificē attālo interfeisu, lai otrā pusē vRouter varētu noteikt, kur ievietot Å”o paketi bez papildu uzmeklÄ“Å”anas.

    Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

  4. Tunnel0 ir avots 10.0.0.2, galamērķis: 10.0.1.2.
    vRouter pievieno GRE (vai UDP) galvenes un jaunu IP oriģinālajai paketei.
  5. VRouter marÅ”rutÄ“Å”anas tabulai ir noklusējuma marÅ”ruts caur ToR1 adresi 10.0.0.1. Tur viņŔ to sÅ«ta.

    Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

  6. ToR1 kā Underlay tÄ«kla dalÄ«bnieks zina (piemēram, caur OSPF) kā nokļūt lÄ«dz 10.0.1.2 un nosÅ«ta paketi pa marÅ”rutu. Ņemiet vērā, ka Å”eit ir iespējots ECMP. Ilustrācijā ir divi nexthops, un dažādi pavedieni tiks sakārtoti tajos pēc jaukÅ”anas. ÄŖstas rÅ«pnÄ«cas gadÄ«jumā, visticamāk, bÅ«s 4 nākamie hopi.

    Tajā paŔā laikā viņam nav jāzina, kas atrodas zem ārējās IP galvenes. Tas ir, faktiski, izmantojot IP, var bÅ«t IPv6 sviestmaize, izmantojot MPLS, izmantojot Ethernet, MPLS, GRE un grieÄ·u valoda.

  7. AttiecÄ«gi no saņēmēja puses vRouter noņem GRE un, izmantojot MPLS tagu, saprot, uz kuru interfeisu Ŕī pakete jānosÅ«ta, noņem to un nosÅ«ta adresātam sākotnējā formā.

Vadības plakne

Iedarbinot automaŔīnu, notiek tas pats, kas aprakstīts iepriekŔ.

Un plus:

  • Katram klientam vRouter pieŔķir MPLS tagu. Å Ä« ir L3VPN pakalpojuma etiÄ·ete, ar kuras palÄ«dzÄ«bu klienti tiks atdalÄ«ti vienā un tajā paŔā fiziskajā maŔīnā.

    Faktiski MPLS tagu vienmēr bez nosacÄ«jumiem pieŔķir vRouter - galu galā nav iepriekÅ” zināms, ka iekārta mijiedarbosies tikai ar citām maŔīnām, kas atrodas aiz tā paÅ”a vRouter, un tas, visticamāk, pat nav taisnÄ«ba.

  • vRouter izveido savienojumu ar SDN kontrolleri, izmantojot BGP protokolu (vai lÄ«dzÄ«gu tam - TF gadÄ«jumā tas ir XMPP 0_o).
  • Å Ä«s sesijas laikā vRouter ziņo SDN kontrollerim par marÅ”rutiem uz savienotajiem tÄ«kliem:
    • TÄ«kla adrese
    • IekapsulÄ“Å”anas metode (MPLSoGRE, MPLSoUDP, VXLAN)
    • MPLS klienta tags
    • JÅ«su IP adrese kā nexthop

  • SDN kontrolleris saņem Ŕādus marÅ”rutus no visiem pievienotajiem vRouteriem un atspoguļo tos citiem. Tas nozÄ«mē, ka tas darbojas kā marÅ”ruta atstarotājs.

Tas pats notiek pretējā virzienā.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Pārklājums var mainÄ«ties vismaz katru minÅ«ti. Tas ir aptuveni tas, kas notiek publiskajos mākoņos, kur klienti regulāri palaiž un izslēdz savas virtuālās maŔīnas.

Centrālais kontrolleris rÅ«pējas par visu sarežģītÄ«bu, kas saistÄ«ta ar konfigurācijas uzturÄ“Å”anu un komutācijas/marÅ”rutÄ“Å”anas tabulu uzraudzÄ«bu vRouter.

Aptuveni runājot, kontrolieris sazinās ar visiem vRouter, izmantojot BGP (vai lÄ«dzÄ«gu protokolu) un vienkārÅ”i pārsÅ«ta marÅ”rutÄ“Å”anas informāciju. Piemēram, BGP jau ir Address-Family, lai nodotu iekapsulÄ“Å”anas metodi MPLS GRE vai MPLS-UDP.

Tajā paŔā laikā nekādi nemainās Underlay tÄ«kla konfigurācija, kuru, starp citu, ir daudz grÅ«tāk automatizēt un vieglāk salauzt ar neveiklu kustÄ«bu.

Izeja uz ārpasauli

Kaut kur simulācijai ir jābeidzas, un jums ir jāiziet no virtuālās pasaules reālajā pasaulē. Un jums ir nepiecieÅ”ama taksofona vārteja.

Tiek praktizētas divas pieejas:

  1. Ir instalēts aparatÅ«ras marÅ”rutētājs.
  2. Tiek palaists aparāts, kas realizē marÅ”rutētāja funkcijas (jā, pēc SDN mēs saskārāmies arÄ« ar VNF). Sauksim to par virtuālo vārteju.

Otrās pieejas priekÅ”rocÄ«ba ir lēta horizontālā mērogojamÄ«ba - nepietiek jaudas - mēs palaižam citu virtuālo maŔīnu ar vārteju. Uz jebkuras fiziskas maŔīnas, nemeklējot brÄ«vus statÄ«vus, blokus, jaudu, iegādājieties paÅ”u aparatÅ«ru, transportējiet to, uzstādiet, pārslēdziet, konfigurējiet un pēc tam arÄ« nomainiet tajā bojātos komponentus.

Virtuālās vārtejas trÅ«kumi ir tādi, ka fiziskā marÅ”rutētāja vienÄ«ba joprojām ir daudz jaudÄ«gāka nekā daudzkodolu virtuālā maŔīna, un tās programmatÅ«ra, kas pielāgota savai aparatÅ«ras bāzei, darbojas daudz stabilāk (nē). Ir arÄ« grÅ«ti noliegt faktu, ka aparatÅ«ras un programmatÅ«ras komplekss vienkārÅ”i darbojas, prasot tikai konfigurāciju, savukārt virtuālās vārtejas palaiÅ”ana un uzturÄ“Å”ana ir spēcÄ«gu inženieru uzdevums.

Ar vienu kāju vārteja aplÅ«ko Overlay virtuālo tÄ«klu, tāpat kā parastā virtuālā maŔīna, un var mijiedarboties ar visām pārējām virtuālajām maŔīnām. Tajā paŔā laikā tas var pārtraukt visu klientu tÄ«klus un attiecÄ«gi veikt marÅ”rutÄ“Å”anu starp tiem.

Ar otru kāju vārteja ieskatās mugurkaula tīklā un zina, kā piekļūt internetam.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Datu plakne

Tas ir, process izskatās Ŕādi:

  1. VM-0, pēc noklusējuma uz to paÅ”u vRouter, nosÅ«ta paketi ar galamērÄ·i ārpasaulē (185.147.83.177) uz eth0 interfeisu.
  2. vRouter saņem Å”o paketi un marÅ”rutÄ“Å”anas tabulā atrod galamērÄ·a adresi ā€” atrod noklusējuma marÅ”rutu caur VNGW1 vārteju caur 1. tuneli.
    ViņŔ arÄ« redz, ka Å”is ir GRE tunelis ar SIP 10.0.0.2 un DIP 10.0.255.2, un viņam arÄ« vispirms jāpievieno Ŕī klienta MPLS etiÄ·ete, ko sagaida VNGW1.
  3. vRouter iesaiņo sākotnējo paketi ar MPLS, GRE un jaunām IP galvenēm un pēc noklusējuma nosūta to uz ToR1 adresi 10.0.0.1.
  4. Pamattīkls piegādā paketi vārtejai VNGW1.
  5. VNGW1 vārteja noņem GRE un MPLS tunelÄ“Å”anas galvenes, redz galamērÄ·a adresi, apskata tās marÅ”rutÄ“Å”anas tabulu un saprot, ka tā ir novirzÄ«ta uz internetu ā€” tas ir, izmantojot pilno skatu vai noklusējuma iestatÄ«jumu. Ja nepiecieÅ”ams, veic NAT tulkojumu.
  6. Varētu būt parasts IP tīkls no VNGW līdz robežai, kas ir maz ticams.
    Var būt klasisks MPLS tīkls (IGP+LDP/RSVP TE), var būt aizmugurējais audums ar BGP LU vai GRE tunelis no VNGW līdz robežai caur IP tīklu.
    Lai kā arÄ« bÅ«tu, VNGW1 veic nepiecieÅ”amās iekapsulācijas un nosÅ«ta sākotnējo paketi robežas virzienā.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Satiksme pretējā virzienā iet cauri tiem paÅ”iem soļiem pretējā secÄ«bā.

  1. Robeža nolaiž paketi uz VNGW1
  2. ViņŔ viņu izģērbj, apskata adresāta adresi un redz, ka viņam var piekļūt caur Tunnel1 tuneli (MPLSoGRE vai MPLSoUDP).
  3. Attiecīgi tas pievieno MPLS etiķeti, GRE/UDP galveni un jaunu IP un nosūta to uz savu ToR3 10.0.255.1.
    Tuneļa galamērÄ·a adrese ir vRouter IP adrese, aiz kuras atrodas mērÄ·a VM ā€” 10.0.0.2.
  4. Pamattīkls piegādā paketi vajadzīgajam vRouter.
  5. MērÄ·a vRouter nolasa GRE/UDP, identificē interfeisu, izmantojot MPLS etiÄ·eti, un nosÅ«ta tukÅ”u IP paketi uz savu TAP interfeisu, kas saistÄ«ts ar VM eth0.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

Vadības plakne

VNGW1 izveido BGP apkaimi ar SDN kontrolieri, no kura tas saņem visu marÅ”rutÄ“Å”anas informāciju par klientiem: kura IP adrese (vRouter) atrodas aiz kura klienta un ar kādu MPLS etiÄ·eti to identificē.

Tāpat viņŔ pats informē SDN kontrolieri par noklusējuma marÅ”rutu ar Ŕī klienta etiÄ·eti, norādot sevi kā nexthop. Un tad Å”is noklusējums nonāk pie vRouters.

Uz VNGW parasti notiek marŔruta apkopoŔana vai NAT tulkoŔana.

Un otrā virzienā tas nosÅ«ta tieÅ”i Å”o apkopoto marÅ”rutu uz sesiju ar apmalēm vai marÅ”ruta atspoguļotājiem. Un no viņiem tas saņem noklusējuma marÅ”rutu vai Full-View, vai kaut ko citu.

IekapsulÄ“Å”anas un trafika apmaiņas ziņā VNGW neatŔķiras no vRouter.
Ja nedaudz paplaÅ”inat darbÄ«bas jomu, varat pievienot citas tÄ«kla ierÄ«ces VNGW un vRouters, piemēram, ugunsmÅ«rus, satiksmes tÄ«rÄ«Å”anas vai bagātināŔanas fermas, IPS utt.

Un, izmantojot secÄ«gu VRF izveidi un pareizu marÅ”rutu izziņoÅ”anu, jÅ«s varat piespiest satiksmi virzÄ«t cilpu sev vēlamajā veidā, ko sauc par pakalpojumu ķēdi.

Tas nozÄ«mē, ka arÄ« Å”eit SDN kontrolleris darbojas kā marÅ”ruta atspoguļotājs starp VNGW, vRouters un citām tÄ«kla ierÄ«cēm.

Bet patiesÄ«bā kontrolieris arÄ« izdod informāciju par ACL un PBR (politiku balstÄ«tu marÅ”rutÄ“Å”anu), izraisot atseviŔķu satiksmes plÅ«smu atŔķirÄ«gumu, nekā norādÄ«ts marÅ”rutā.

Automatizācija paÅ”iem mazākajiem. Pirmā daļa (kas ir pēc nulles). TÄ«kla virtualizācija

FAQ

Kāpēc jūs vienmēr izsakāt GRE/UDP piezīmi?

Kopumā var teikt, ka tas attiecas uz volframa audumu - jums tas vispār nav jāņem vērā.

Bet, ja mēs to ņemam, tad pati TF, vēl būdama OpenContrail, atbalstīja abas iekapsulācijas: MPLS GRE un MPLS UDP.

UDP ir labs, jo Source Port ir ļoti vienkārÅ”i savā galvenē iekodēt hash funkciju no oriÄ£inālā IP+Proto+Port, kas ļaus veikt balansÄ“Å”anu.

GRE gadÄ«jumā diemžēl ir tikai ārējās IP un GRE galvenes, kas ir vienādas visai iekapsulētajai trafikai un nav runas par balansÄ“Å”anu - reti kurÅ” spēj ieskatÄ«ties tik dziļi paketē.

LÄ«dz kādu laiku marÅ”rutētāji, ja viņi prata izmantot dinamiskos tuneļus, to darÄ«ja tikai MPLSoGRE, un tikai pavisam nesen viņi iemācÄ«jās izmantot MPLSoUDP. Tāpēc mums vienmēr ir jāatzÄ«mē divu dažādu iekapsulāciju iespēja.

Godīgi sakot, ir vērts atzīmēt, ka TF pilnībā atbalsta L2 savienojumu, izmantojot VXLAN.

Jūs solījāt vilkt paralēles ar OpenFlow.
Viņi patieŔām to lÅ«dz. vSwitch tajā paŔā OpenStack dara ļoti lÄ«dzÄ«gas lietas, izmantojot VXLAN, kuram, starp citu, ir arÄ« UDP galvene.

Datu plaknē tie darbojas aptuveni vienādi, vadÄ«bas plakne ievērojami atŔķiras. Tungsten Fabric izmanto XMPP, lai piegādātu marÅ”rutÄ“Å”anas informāciju vRouter, savukārt OpenStack darbojas Openflow.

Vai varat pastāstīt man mazliet vairāk par vRouter?
Tas ir sadalīts divās daļās: vRouter Agent un vRouter Forwarder.

Pirmais darbojas resursdatora OS lietotāja telpā un sazinās ar SDN kontrolleri, apmainoties ar informāciju par marŔrutiem, VRF un ACL.

Otrais realizē Data Plane - parasti Kernel Space, bet var darboties arÄ« ar SmartNIC - tÄ«kla kartēm ar centrālo procesoru un atseviŔķu programmējamu komutācijas mikroshēmu, kas ļauj noņemt slodzi no resursdatora CPU un padarÄ«t tÄ«klu ātrāku un vairāk. paredzams.

Vēl viens iespējamais scenārijs ir tāds, ka vRouter ir DPDK lietojumprogramma User Space.

vRouter Agent nosūta iestatījumus vRouter Forwarder.

Kas ir virtuālais tīkls?
Raksta sākumā par VRF minēju, ka katrs īrnieks ir piesaistīts savam VRF. Un, ja ar to pietika, lai virspusēja izpratne par pārklājuma tīkla darbību, tad nākamajā atkārtojumā ir jāveic precizējumi.

Parasti virtualizācijas mehānismos Virtuālā tÄ«kla entÄ«tija (jÅ«s varat to uzskatÄ«t par Ä«paÅ”vārdu) tiek ieviesta atseviŔķi no klientiem/Ä«rniekiem/virtuālajām maŔīnām - pilnÄ«gi neatkarÄ«ga lieta. Un Å”o virtuālo tÄ«klu jau var pieslēgt caur interfeisiem vienam nomniekam, citam, diviem vai jebkur. Tā, piemēram, pakalpojumu ķēde tiek ieviesta, kad satiksme ir jānodod caur noteiktiem mezgliem vajadzÄ«gajā secÄ«bā, vienkārÅ”i izveidojot un savienojot virtuālos tÄ«klus pareizajā secÄ«bā.

Tāpēc starp Virtuālo tÄ«klu un nomnieku nav tieÅ”as sarakstes.

Secinājums

Å is ir ļoti virspusējs virtuālā tÄ«kla darbÄ«bas apraksts ar pārklājumu no resursdatora un SDN kontrollera. Bet neatkarÄ«gi no tā, kādu virtualizācijas platformu jÅ«s Å”odien izvēlaties, tā darbosies lÄ«dzÄ«gi, vai tā bÅ«tu VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric vai Juniper Contrail. Tie atŔķirsies pēc iekapsulÄ“Å”anas un galvenes veidiem, protokoliem informācijas nogādāŔanai gala tÄ«kla ierÄ«cēs, taču programmatÅ«ras konfigurējama pārklājuma tÄ«kla princips, kas darbojas virs salÄ«dzinoÅ”i vienkārÅ”a un statiska apakÅ”tÄ«kla, paliks nemainÄ«gs.
Var teikt, ka Å”odien SDN, kas balstÄ«ts uz pārklājuma tÄ«klu, ir uzvarējis privātā mākoņa izveides jomā. Tomēr tas nenozÄ«mē, ka Openflow nav vietas mÅ«sdienu pasaulē ā€“ tas tiek izmantots OpenStacke un tajā paŔā VMWare NSX, cik man zināms, Google to izmanto, lai izveidotu pazemes tÄ«klu.

Zemāk esmu sniedzis saites uz detalizētākiem materiāliem, ja vēlaties Å”o jautājumu izpētÄ«t dziļāk.

Un kā ar mūsu apakŔklāju?

Bet kopumā nekas. ViņŔ nemainÄ«jās visu ceļu. Viss, kas viņam jādara resursdatora pārklājuma gadÄ«jumā, ir jāatjaunina marÅ”ruti un ARP, kad parādās un pazÅ«d vRouter/VNGW un pārnēsā paketes starp tām.

Formulēsim apakÅ”klāja tÄ«kla prasÄ«bu sarakstu.

  1. Jāprot izmantot kaut kādu marÅ”rutÄ“Å”anas protokolu, mÅ«su situācijā - BGP.
  2. JābÅ«t plaÅ”am joslas platumam, vēlams bez pārrakstÄ«Å”anās, lai paketes netiktu zaudētas pārslodzes dēļ.
  3. ECMP atbalsts ir auduma neatņemama sastāvdaļa.
  4. Jāspēj nodroÅ”ināt QoS, tostarp tādas sarežģītas lietas kā ECN.
  5. NETCONF atbalsts ir nākotnes pamats.

Es Å”eit veltÄ«ju ļoti maz laika paÅ”a Underlay tÄ«kla darbam. Tas ir tāpēc, ka vēlāk sērijā es pievērsÄ«Å”os tam, un pārklājumam pieskarsimies tikai garāmejot.

AcÄ«mredzot es ļoti ierobežoju mÅ«s visus, kā piemēru izmantojot Clos rÅ«pnÄ«cā iebÅ«vētu lÄ«dzstrāvas tÄ«klu ar tÄ«ru IP marÅ”rutÄ“Å”anu un resursdatora pārklājumu.

Tomēr esmu pārliecināts, ka jebkuru tÄ«klu, kuram ir dizains, var aprakstÄ«t formāli un automatizēt. VienkārÅ”i mans mērÄ·is Å”eit ir izprast automatizācijas pieejas un nemulsināt visus, risinot problēmu vispārÄ«gā veidā.

ADSM ietvaros Romāns Gorge un es plānojam publicēt atseviŔķu izdevumu par skaitļoÅ”anas jaudas virtualizāciju un tās mijiedarbÄ«bu ar tÄ«kla virtualizāciju. Uzturēt kontaktus.

Noderīgas saites

Paldies

  • Romāns Gorga - bijuÅ”ais linkmeup aplādes vadÄ«tājs un tagad eksperts mākoņu platformu jomā. Komentāriem un labojumiem. Nu ko, tuvākajā laikā gaidām viņa padziļinātāku rakstu par virtualizāciju.
  • Aleksandrs Å alimovs - mans kolēģis un eksperts virtuālo tÄ«klu attÄ«stÄ«bas jomā. Komentāriem un labojumiem.
  • ValentÄ«ns Siņicins - mans kolēģis un eksperts volframa auduma jomā. Komentāriem un labojumiem.
  • Artjoms Černobajs ā€” ilustrators linkmeup. Par KDPV.
  • Aleksandrs Ä»imonovs. Par "automāta" mēmu.

Avots: www.habr.com

Pievieno komentāru