ProHoster > Blogs > Administrācija > Tīkla audums Cisco ACI datu centram - lai palīdzētu administratoram

Tīkla audums Cisco ACI datu centram - lai palīdzētu administratoram

Tīkla audums Cisco ACI datu centram - lai palīdzētu administratoram
Izmantojot Ŕo maģisko Cisco ACI skripta daļu, varat ātri iestatīt tīklu.

TÄ«kla rÅ«pnÄ«ca Cisco ACI datu centram pastāv jau piecus gadus, bet HabrĆ© par to Ä«sti neko neteica, tāpēc nolēmu to nedaudz labot. Es jums pastāstÄ«Å”u no savas pieredzes, kas tas ir, kam tas ir noderÄ«gs un kur tam ir grābeklis.

Kas tas ir un no kurienes tas nāca?

LÄ«dz brÄ«dim, kad 2013. gadā tika paziņots par ACI (Application Centric Infrastructure), konkurenti attÄ«stÄ«ja tradicionālās pieejas datu centru tÄ«kliem no trim pusēm vienlaikus.

No vienas puses, "pirmās paaudzes" SDN risinājumi, kuru pamatā ir OpenFlow, solÄ«ja tÄ«klus padarÄ«t elastÄ«gākus un vienlaikus lētākus. Ideja bija lēmumu pieņemÅ”anu, ko tradicionāli veic ar patentētu slēdžu programmatÅ«ru, pārvietot uz centrālo kontrolieri.

Šim kontrolierim būtu vienots redzējums par visu, kas notiek, un, pamatojoties uz to, tas programmētu visu slēdžu aparatūru konkrētu plūsmu apstrādes noteikumu līmenī.
No otras puses, pārklājuma tÄ«kla risinājumi ļāva ieviest nepiecieÅ”amās savienojamÄ«bas un droŔības politikas bez izmaiņām fiziskajā tÄ«klā, veidojot programmatÅ«ras tuneļus starp virtualizētajiem resursdatoriem. VispazÄ«stamākais Ŕīs pieejas piemērs bija Nicira, kuru tobrÄ«d VMWare jau bija iegādājies par 1,26 miljardiem USD un kas radÄ«ja paÅ”reizējo VMWare NSX. Dažu pikantu situācijai pieŔķīra fakts, ka Nicira lÄ«dzdibinātāji bija tie paÅ”i cilvēki, kas iepriekÅ” stāvēja pie OpenFlow pirmsākumiem, tagad sakot, ka, lai uzbÅ«vētu datu centra rÅ«pnÄ«cu. OpenFlow nav piemērots.

Un visbeidzot, atvērtajā tirgÅ« pieejamās komutācijas mikroshēmas (ko sauc par tirdzniecÄ«bas silÄ«ciju) ir sasnieguÅ”as tādu brieduma pakāpi, kad tās ir kļuvuÅ”as par reālu draudu tradicionālajiem slēdžu ražotājiem. Ja agrāk katrs pārdevējs patstāvÄ«gi izstrādāja mikroshēmas saviem slēdžiem, tad laika gaitā treÅ”o puÅ”u ražotāju mikroshēmas, galvenokārt no Broadcom, sāka samazināt attālumu no pārdevēja mikroshēmām funkciju ziņā un pārspēja tos cenas / veiktspējas attiecÄ«bas ziņā. Tāpēc daudzi uzskatÄ«ja, ka viņu paÅ”u izstrādāto mikroshēmu ieslēgÅ”anas dienas ir skaitÄ«tas.

ACI ir kļuvusi par Cisco "asimetrisko atbildi" (precÄ«zāk, tā Insieme uzņēmumu, kuru dibināja tā bijuÅ”ie darbinieki) uz visu iepriekÅ” minēto.

Kāda ir atŔķirība no OpenFlow?

Funkciju sadalījuma ziņā ACI faktiski ir pretējs OpenFlow.
OpenFlow arhitektÅ«rā kontrolieris ir atbildÄ«gs par detalizētu noteikumu (plÅ«smu) rakstÄ«Å”anu.
visu slēdžu aparatÅ«rā, tas ir, lielā tÄ«klā, tas var bÅ«t atbildÄ«gs par desmitiem miljonu ierakstu uzturÄ“Å”anu un, pats galvenais, mainÄ«Å”anu simtiem tÄ«kla punktu, tāpēc tā veiktspēja un uzticamÄ«ba kļūst par vājo vietu liela Ä«stenoÅ”ana.

ACI izmanto apgriezto pieeju: protams, ir arÄ« kontrolieris, taču slēdži no tā saņem augsta lÄ«meņa deklaratÄ«vās politikas, un pats slēdzis veic to atveidoÅ”anu konkrētu aparatÅ«ras iestatÄ«jumu detaļās. Kontrolieri var pārstartēt vai vispār izslēgt, un tÄ«klam nekas slikts nenotiks, izņemot, protams, kontroles trÅ«kumu Å”ajā brÄ«dÄ«. Interesanti, ka ACI ir situācijas, kurās OpenFlow joprojām tiek izmantots, bet lokāli resursdatorā Open vSwitch programmÄ“Å”anai.

ACI ir pilnÄ«bā veidota uz VXLAN balstÄ«ta pārklājuma transporta, bet ietver pamatā esoÅ”o IP transportÄ“Å”anu kā daļu no viena risinājuma. Cisco to sauca par "integrētā pārklājuma" terminu. Kā ACI pārklājumu beigu punkts vairumā gadÄ«jumu tiek izmantoti rÅ«pnÄ«cas slēdži (tie to dara ar saites ātrumu). Hostiem nekas nav jāzina par rÅ«pnÄ«cu, iekapsulÄ“Å”anu utt., tomēr atseviŔķos gadÄ«jumos (piemēram, lai savienotu OpenStack resursdatorus) uz tiem var atvest VXLAN trafiku.

Pārklājumus ACI izmanto ne tikai elastÄ«gas savienojamÄ«bas nodroÅ”ināŔanai caur transporta tÄ«klu, bet arÄ« metainformācijas pārsÅ«tÄ«Å”anai (to izmanto, piemēram, droŔības politiku piemēroÅ”anai).

Cisco mikroshēmas no Broadcom iepriekÅ” izmantoja Nexus 3000. sērijas slēdžos. Nexus 9000 saimē, kas Ä«paÅ”i izlaista ACI atbalstam, sākotnēji tika ieviests hibrÄ«da modelis, ko sauca par Merchant+. Slēdzis vienlaikus izmantoja gan jauno Broadcom Trident 2 mikroshēmu, gan Cisco izstrādāto papildu mikroshēmu, kas Ä«steno visu ACI burvÄ«bu. AcÄ«mredzot tas ļāva paātrināt produkta izlaiÅ”anu un samazināt slēdža cenu lÄ«dz lÄ«menim, kas tuvu modeļiem, kas vienkārÅ”i balstÄ«ti uz Trident 2. Ar Å”o pieeju pietika pirmajiem diviem vai trim ACI piegādes gadiem. Å ajā laikā Cisco izstrādāja un laida klajā nākamās paaudzes Nexus 9000 ar savām mikroshēmām ar lielāku veiktspēju un funkciju komplektu, taču tajā paŔā cenu lÄ«menÄ«. Ārējās specifikācijas attiecÄ«bā uz mijiedarbÄ«bu rÅ«pnÄ«cā ir pilnÄ«bā saglabātas. Tajā paŔā laikā ir pilnÄ«bā mainÄ«jies iekŔējais pildÄ«jums: kaut kas lÄ«dzÄ«gs pārstrukturÄ“Å”anai, bet aparatÅ«rai.

Kā darbojas Cisco ACI arhitektūra

VienkārŔākajā gadÄ«jumā ACI ir veidota uz Klose tÄ«kla topoloÄ£ijas jeb, kā mēdz teikt, Spine-Leaf. Mugurkaula lÄ«meņa slēdži var bÅ«t no diviem (vai viens, ja mums nerÅ«p kļūdu tolerance) lÄ«dz seÅ”iem. AttiecÄ«gi, jo vairāk to, jo augstāka ir kļūdu tolerance (jo mazāks ir joslas platums un uzticamÄ«bas samazināŔanās avārijas vai viena mugurkaula apkopes gadÄ«jumā) un kopējā veiktspēja. Visi ārējie savienojumi tiek novirzÄ«ti uz lapu lÄ«meņa slēdžiem: tie ir serveri un dokstacijas ar ārējiem tÄ«kliem, izmantojot L2 vai L3, un savienojoÅ”ie APIC kontrolleri. Kopumā ar ACI tiek veikta ne tikai konfigurācija, bet arÄ« statistikas apkopoÅ”ana, kļūmju uzraudzÄ«ba un tā tālāk - viss tiek darÄ«ts caur kontrolieru saskarni, kuru standarta izmēra implementācijās ir trÄ«s.

Jums nekad nav jāpieslēdzas pie slēdžiem ar konsoli, pat lai palaistu tÄ«klu: kontrolieris pats nosaka slēdžus un saliek no tiem rÅ«pnÄ«cu, ieskaitot visu servisa protokolu iestatÄ«jumus, tāpēc, starp citu, ir ļoti svarÄ«gi uzstādÄ«Å”anas laikā pierakstiet uzstādāmās iekārtas sērijas numurus, lai vēlāk nebÅ«tu jāmin, kurÅ” slēdzis kurā statÄ«vā atrodas. Problēmu novērÅ”anai, ja nepiecieÅ”ams, varat izveidot savienojumu ar slēdžiem, izmantojot SSH: tie diezgan rÅ«pÄ«gi atveido parastās Cisco show komandas.

RÅ«pnÄ«cā iekŔēji tiek izmantots IP transports, tāpēc tajā nav Spanning Tree un citu pagātnes Å”ausmu: ir iesaistÄ«tas visas saites, un konverÄ£ence kļūmju gadÄ«jumā notiek ļoti ātri. Satiksme audumā tiek pārraidÄ«ta caur tuneļiem, kuru pamatā ir VXLAN. PrecÄ«zāk, pats Cisco sauc par iVXLAN iekapsulāciju, un tas atŔķiras no parastā VXLAN ar to, ka tÄ«kla galvenē rezervētie lauki tiek izmantoti pakalpojumu informācijas pārsÅ«tÄ«Å”anai, galvenokārt par trafika saistÄ«bu ar EPG grupu. Tas ļauj iekārtā ieviest noteikumus par mijiedarbÄ«bu starp grupām, izmantojot to numurus tāpat kā adreses tiek izmantotas parastajos piekļuves sarakstos.

Tuneļi ļauj izstiept gan L2 segmentus, gan L3 segmentus (t.i., VRF), izmantojot iekŔējo IP transportu. Å ajā gadÄ«jumā tiek izplatÄ«ta noklusējuma vārteja. Tas nozÄ«mē, ka katrs slēdzis ir atbildÄ«gs par audumā ienākoŔās satiksmes novirzÄ«Å”anu. Satiksmes plÅ«smas loÄ£ikas ziņā ACI ir lÄ«dzÄ«gs VXLAN/EVPN audumam.

Ja jā, kādas ir atŔķirÄ«bas? Viss pārējais!

Galvenā atŔķirÄ«ba, ar kuru jÅ«s saskaraties ar ACI, ir tas, kā serveri tiek savienoti ar tÄ«klu. Tradicionālajos tÄ«klos gan fizisko serveru, gan virtuālo maŔīnu iekļauÅ”ana iet uz VLAN, un viss pārējais dejo no tiem: savienojamÄ«ba, droŔība utt. ACI tiek izmantots dizains, ko Cisco sauc par EPG (End-point Group), no kura nav kur aizmukt. Vai ir iespējams to pielÄ«dzināt VLAN? Jā, bet Å”ajā gadÄ«jumā pastāv iespēja zaudēt lielāko daļu no tā, ko ACI dod.

AttiecÄ«bā uz EPG ir formulēti visi piekļuves noteikumi, un ACI pēc noklusējuma tiek izmantots ā€œbaltā sarakstaā€ princips, tas ir, ir atļauta tikai trafika, kuras caurlaide ir skaidri atļauta. Tas nozÄ«mē, ka mēs varam izveidot EPG grupas "Web" un "MySQL" un definēt noteikumu, kas ļauj sazināties starp tām tikai 3306. portā. Tas darbosies bez piesaistes tÄ«kla adresēm un pat tajā paŔā apakÅ”tÄ«klā!

Mums ir klienti, kuri ir izvēlējuÅ”ies ACI tieÅ”i Ŕīs funkcijas dēļ, jo tas ļauj ierobežot piekļuvi starp serveriem (virtuālo vai fizisko - tas nav svarÄ«gi), nevelkot tos starp apakÅ”tÄ«kliem, tas nozÄ«mē, nepieskaroties adresācijai. Jā, jā, mēs zinām, ka neviens ar roku nenosaka IP adreses lietojumprogrammu konfigurācijās, vai ne?

Satiksmes noteikumus ACI sauc par lÄ«gumiem. Šādā lÄ«gumā viena vai vairākas grupas vai lÄ«meņi daudzlÄ«meņu lietojumprogrammā kļūst par pakalpojumu sniedzēju (teiksim, datu bāzes pakalpojumu), citi kļūst par patērētāju. LÄ«gums var vienkārÅ”i nodot trafiku vai veikt kaut ko sarežģītāku, piemēram, novirzÄ«t to uz ugunsmÅ«ri vai balansētāju, kā arÄ« mainÄ«t QoS vērtÄ«bu.

Kā serveri nokļūst Å”ajās grupās? Ja tie ir fiziski serveri vai kaut kas iekļauts esoÅ”ajā tÄ«klā, kurā mēs izveidojām VLAN maÄ£istrāli, tad, lai tos ievietotu EPG, jums bÅ«s jānorāda uz slēdža portu un tajā izmantoto VLAN. Kā redzat, VLAN parādās tur, kur bez tiem nevar iztikt.

Ja serveri ir virtuālās maŔīnas, tad pietiek atsaukties uz pieslēgto virtualizācijas vidi, un tad viss notiks pats no sevis: tiks izveidota portu grupa (VMWare ziņā), lai savienotu VM, tiks izveidoti nepiecieÅ”amie VLAN jeb VXLAN. Ja tie tiks pieŔķirti, tie tiks reÄ£istrēti nepiecieÅ”amajos slēdžu portos utt. Tātad, lai gan ACI ir veidots ap fizisku tÄ«klu, savienojumi virtuālajiem serveriem izskatās daudz vienkārŔāki nekā fiziskajiem. ACI jau ir iebÅ«vēta savienojamÄ«ba ar VMWare un MS Hyper-V, kā arÄ« OpenStack un RedHat virtualizācijas atbalsts. No kāda brīža ir parādÄ«jies arÄ« iebÅ«vēts atbalsts konteineru platformām: Kubernetes, OpenShift, Cloud Foundry, savukārt tas attiecas gan uz politiku piemēroÅ”anu, gan uzraudzÄ«bu, tas ir, tÄ«kla administrators var uzreiz redzēt, uz kuriem resursdatoriem kuri podi darbojas un kādās grupās tās ietilpst.

Papildus tam, ka virtuālie serveri tiek iekļauti noteiktā portu grupā, tiem ir papildu rekvizÄ«ti: nosaukums, atribÅ«ti utt., kurus var izmantot kā kritērijus to pārsÅ«tÄ«Å”anai uz citu grupu, piemēram, ja tiek pārdēvēta VM vai tajā parādās papildu tags. to. Cisco to sauc par mikrosegmentācijas grupām, lai gan kopumā pats dizains ar iespēju tajā paŔā apakÅ”tÄ«klā izveidot daudzus droŔības segmentus EPG formātā arÄ« ir diezgan mikrosegmentācija. Nu, pārdevējs zina labāk.

PaÅ”as EPG ir tÄ«ri loÄ£iskas konstrukcijas, kas nav piesaistÄ«tas konkrētiem slēdžiem, serveriem utt., tāpēc ar tiem un uz tiem balstÄ«tām konstrukcijām (lietojumprogrammām un nomniekiem) var veikt lietas, kuras ir grÅ«ti izdarÄ«t parastos tÄ«klos, piemēram, klonÄ“Å”anu. Rezultātā pieņemsim, ka ir ļoti vienkārÅ”i klonēt ražoÅ”anas vidi, lai iegÅ«tu testa vidi, kas garantēti ir identiska ražoÅ”anas videi. To var izdarÄ«t manuāli, taču tas ir labāk (un vienkārŔāk), izmantojot API.

Kopumā ACI vadības loģika nepavisam nav līdzīga tai, ko jūs parasti izmantojat
tradicionālajos tÄ«klos no tā paÅ”a Cisco: programmatÅ«ras interfeiss ir primārais, un GUI vai CLI ir sekundāri, jo tie darbojas, izmantojot to paÅ”u API. Tāpēc gandrÄ«z visi, kas iesaistÄ«ti ACI, pēc kāda laika sāk orientēties pārvaldÄ«Å”anai izmantotajā objekta modelÄ« un automatizēt kaut ko, lai tas atbilstu savām vajadzÄ«bām. VienkārŔākais veids, kā to izdarÄ«t, ir no Python: tam ir ērti gatavi rÄ«ki.

Solīts grābeklis

Galvenā problēma ir tā, ka daudzas lietas ACI tiek veiktas atŔķirÄ«gi. Lai sāktu ar to normāli strādāt, ir jāpārkvalificējas. Tas jo Ä«paÅ”i attiecas uz tÄ«kla operāciju komandām lielos klientus, kur inženieri gadiem ilgi pēc pieprasÄ«juma ir izrakstÄ«juÅ”i VLAN. Fakts, ka tagad VLAN vairs nav VLAN un jums nav manuāli jāizveido VLAN, lai izveidotu jaunus tÄ«klus virtualizētos saimniekdatoros, pilnÄ«bā nojauc tradicionālos tÄ«klu veidotājus un liek tiem pieÄ·erties pazÄ«stamām pieejām. Jāpiebilst, ka Cisco mēģināja nedaudz saldināt tableti un pievienoja kontrolierim ā€œNXOS lÄ«dzÄ«guā€ CLI, kas ļauj veikt konfigurāciju no tradicionālajiem slēdžiem lÄ«dzÄ«ga interfeisa. Bet tomēr, lai sāktu normāli lietot ACI, jums ir jāsaprot, kā tas darbojas.

Cenas ziņā lielos un vidējos mērogos ACI tÄ«kli faktiski neatŔķiras no tradicionālajiem tÄ«kliem Cisco iekārtās, jo to veidoÅ”anai tiek izmantoti tie paÅ”i slēdži (Nexus 9000 var darboties ACI un tradicionālajā režīmā un tagad ir kļuvuÅ”i par galvenajiem "darba zirgs" jauniem datu centru projektiem). Bet divu slēdžu datu centriem kontrolieru klātbÅ«tne un Spine-Leaf arhitektÅ«ra, protams, liek par sevi manÄ«t. Nesen parādÄ«jās Mini ACI rÅ«pnÄ«ca, kurā divi no trim kontrolieriem ir aizstāti ar virtuālajām maŔīnām. Tas samazina izmaksu starpÄ«bu, taču tā joprojām saglabājas. Tātad klientam izvēli nosaka tas, cik ļoti viņu interesē droŔības lÄ«dzekļi, integrācija ar virtualizāciju, viens kontroles punkts utt.

Avots: www.habr.com

Pievieno komentāru