Netkerfi fyrir Cisco ACI gagnaverið - til að hjálpa stjórnandanum

Með hjálp þessa töfrandi hluta af Cisco ACI handriti geturðu fljótt sett upp netkerfi.

Netverksmiðjan fyrir Cisco ACI gagnaverið hefur verið til í fimm ár, en Habré sagði í rauninni ekkert um það, svo ég ákvað að laga það aðeins. Ég skal segja þér af eigin reynslu hvað það er, hvaða gagn er af því og hvar það er með hrífu.

Hvað er það og hvaðan kom það?

Þegar tilkynnt var um ACI (Application Centric Infrastructure) árið 2013, voru keppendur að þróast á hefðbundnar aðferðir við netkerfi gagnavera frá þremur hliðum í einu.

Annars vegar lofuðu „fyrstu kynslóðar“ SDN lausnir byggðar á OpenFlow að gera netkerfin sveigjanlegri og ódýrari á sama tíma. Hugmyndin var að færa ákvarðanatöku sem hefðbundið er með sérsniðnum rofahugbúnaði yfir í miðlægan stjórnanda.

Þessi stjórnandi myndi hafa eina sýn á allt sem gerist og, byggt á þessu, myndi forrita vélbúnað allra rofa á stigi reglna um vinnslu tiltekinna flæðis.
Á hinn bóginn gerðu yfirlagnarkerfislausnir mögulegt að innleiða nauðsynlegar tengingar- og öryggisstefnur án nokkurra breytinga á líkamlegu neti yfirhöfuð, og byggðu hugbúnaðargöng á milli sýndargerðar gestgjafa. Þekktasta dæmið um þessa nálgun var Nicira, sem þá hafði þegar verið keypt af VMWare fyrir 1,26 milljarða dollara og gaf tilefni til núverandi VMWare NSX. Nokkuð pirrandi ástandið bættist við af því að stofnendur Nicira voru þeir sömu og áður stóðu að uppruna OpenFlow og sögðu nú að til að byggja gagnaver verksmiðju OpenFlow hentar ekki.

Og að lokum hafa skiptiflögur sem eru fáanlegar á almennum markaði (það sem kallast kaupmannskísil) náð þroskastigi þar sem þeir eru orðnir raunveruleg ógn við hefðbundna rofaframleiðendur. Ef hver söluaðili þróaði sjálfstætt flís fyrir rofa sína fyrr, þá fóru flísar frá þriðju aðila framleiðendum, fyrst og fremst frá Broadcom, að minnka fjarlægðina við söluaðila flísar hvað varðar aðgerðir og fóru fram úr þeim hvað varðar verð / afköst hlutfall. Þess vegna töldu margir að dagar rofa á flísum af eigin hönnun væru taldir.

ACI hefur orðið "ósamhverft svar" Cisco (nánar tiltekið, Insieme fyrirtæki þess, stofnað af fyrrverandi starfsmönnum þess) við öllu ofangreindu.

Hver er munurinn á OpenFlow?

Hvað varðar dreifingu aðgerða er ACI í raun andstæða OpenFlow.
Í OpenFlow arkitektúr er stjórnandinn ábyrgur fyrir að skrifa nákvæmar reglur (flæði)
í vélbúnaði allra rofa, það er að segja í stóru neti, getur það verið ábyrgt fyrir því að viðhalda og, síðast en ekki síst, breyta tugum milljóna skráa á hundruðum staða á netinu, þannig að afköst þess og áreiðanleiki verða flöskuháls í a stór framkvæmd.

ACI notar öfuga nálgun: Auðvitað er líka til stjórnandi, en rofarnir fá yfirlýsandi stefnur á háu stigi frá honum og rofinn sjálfur framkvæmir flutning þeirra í smáatriðum um sérstakar stillingar í vélbúnaðinum. Hægt er að endurræsa stjórnandann eða slökkva á honum að öllu leyti og ekkert slæmt mun gerast á netinu, nema auðvitað skortur á stjórn á þessari stundu. Athyglisvert er að það eru aðstæður í ACI þar sem OpenFlow er enn notað, en staðbundið innan hýsilsins fyrir Open vSwitch forritun.

ACI er byggt að öllu leyti á VXLAN-undirstaða yfirlagsflutninga, en inniheldur undirliggjandi IP-flutning sem hluta af einni lausn. Cisco kallaði þetta "samþætt yfirlag" hugtakið. Sem endapunktur fyrir yfirlög í ACI eru í flestum tilfellum notaðir verksmiðjurofar (þeir gera þetta á tengihraða). Gestgjafar þurfa ekki að vita neitt um verksmiðjuna, hjúpun o.s.frv., en í sumum tilfellum (til dæmis til að tengja OpenStack vélar) er hægt að koma VXLAN umferð til þeirra.

Yfirlög eru notuð í ACI, ekki aðeins til að veita sveigjanlega tengingu í gegnum flutningsnetið, heldur einnig til að flytja lýsiupplýsingar (það er til dæmis notað til að beita öryggisstefnu).

Flísar frá Broadcom voru áður notaðir af Cisco í rofa úr Nexus 3000. Í Nexus 9000 fjölskyldunni, sem var sérstaklega gefin út til að styðja ACI, var upphaflega útfært tvinnlíkan sem var kallað Merchant +. Rofinn notaði samtímis bæði nýja Broadcom Trident 2 flísinn og viðbótarflögu þróað af Cisco, sem útfærir alla töfra ACI. Svo virðist sem þetta hafi gert það mögulegt að flýta fyrir útgáfu vörunnar og lækka verðmiðann á rofanum niður á það stig sem er nálægt módelum sem byggðust einfaldlega á Trident 2. Þessi nálgun var nóg fyrir fyrstu tvö eða þrjú árin af ACI afhendingu. Á þessum tíma þróaði Cisco og setti á markað næstu kynslóð Nexus 9000 á eigin flísum með meiri afköstum og eiginleikum, en á sama verðlagi. Ytri forskriftir hvað varðar samspil í verksmiðjunni eru algjörlega varðveittar. Á sama tíma hefur innri fyllingin gjörbreyst: eitthvað eins og refactoring, en fyrir járn.

Hvernig Cisco ACI arkitektúrinn virkar

Í einfaldasta tilfellinu er ACI byggt á staðfræði Klose netsins, eða eins og þeir segja oft, Spine-Leaf. Rofar á hryggjarstigi geta verið frá tveimur (eða einum, ef okkur er sama um bilanaþol) upp í sex. Í samræmi við það, því fleiri sem eru, því hærra er bilunarþolið (því minni bandbreidd og áreiðanleikaminnkun ef slys verður eða viðhald á einum hrygg) og heildarafköst. Allar ytri tengingar fara í rofa á laufstigi: þetta eru netþjónar og tengikví við ytri netkerfi í gegnum L2 eða L3 og tengja APIC stýringar. Almennt séð, með ACI, ekki aðeins uppsetningu, heldur einnig tölfræðisöfnun, bilanaeftirlit og svo framvegis - allt er gert í gegnum viðmót stýringa, þar af eru þrír í staðlaðri útfærslu.

Þú þarft aldrei að tengjast rofanum með stjórnborðinu, jafnvel til að ræsa netið: stjórnandinn sjálfur skynjar rofana og setur saman verksmiðju úr þeim, þar á meðal stillingar allra þjónustusamskiptareglna, þess vegna er mjög mikilvægt að skrifaðu niður raðnúmer búnaðarins sem verið er að setja upp við uppsetningu, svo að seinna þurfi ekki að giska á hvaða rofi er í hvaða rekki er staðsettur. Fyrir bilanaleit, ef nauðsyn krefur, geturðu tengst rofanum í gegnum SSH: þeir endurskapa venjulegar Cisco sýningarskipanir nokkuð vandlega.

Innbyrðis notar verksmiðjan IP-flutning, þannig að það er ekkert Spanning Tree og önnur hryllingur fortíðar í henni: allir tenglar taka þátt og samleitni ef bilanir eru mjög hröð. Umferðin í efninu er send í gegnum göng byggð á VXLAN. Nánar tiltekið kallar Cisco sjálft iVXLAN encapsulation og það er frábrugðið venjulegu VXLAN að því leyti að fráteknu reitirnir í nethausnum eru notaðir til að senda þjónustuupplýsingar, fyrst og fremst um tengsl umferðar við EPG hópinn. Þetta gerir þér kleift að innleiða reglur um samskipti milli hópa í búnaðinum, nota númer þeirra á sama hátt og heimilisföng eru notuð í venjulegum aðgangslistum.

Göng gera kleift að teygja bæði L2 hluta og L3 hluta (þ.e. VRF) í gegnum innri IP flutning. Í þessu tilviki er sjálfgefna gáttin dreift. Þetta þýðir að hver rofi er ábyrgur fyrir því að beina umferðinni inn í efnið. Hvað varðar rökfræði umferðarflæðis er ACI svipað og VXLAN/EVPN efni.

Ef svo er, hver er munurinn? Allt annað!

Munurinn númer eitt sem þú lendir í með ACI er hvernig netþjónar eru tengdir við netið. Í hefðbundnum netkerfum fer innlimun bæði líkamlegra netþjóna og sýndarvéla í VLAN og allt annað dansar af þeim: tengingar, öryggi o.s.frv. Í ACI er notuð hönnun sem Cisco kallar EPG (End-point Group), þaðan sem það er hvergi hægt að komast undan. Hvort það sé hægt að jafna það við VLAN? Já, en í þessu tilfelli er möguleiki á að tapa mestu af því sem ACI gefur.

Með tilliti til EPG eru allar aðgangsreglur mótaðar og í ACI er „white list“ meginreglan sjálfgefið notuð, það er að segja að aðeins umferð er leyfð, sem er beinlínis leyfð. Það er að segja, við getum búið til "Web" og "MySQL" EPG hópana og skilgreint reglu sem leyfir samskipti á milli þeirra aðeins á port 3306. Þetta mun virka án þess að vera bundið við netföng og jafnvel innan sama undirnets!

Við höfum viðskiptavini sem hafa valið ACI einmitt vegna þessa eiginleika, þar sem það gerir þér kleift að takmarka aðgang á milli netþjóna (sýndur eða líkamlegur - það skiptir ekki máli) án þess að draga þá á milli undirneta, sem þýðir án þess að snerta heimilisfangið. Já, já, við vitum að enginn ávísar IP tölum í forritastillingum með höndunum, ekki satt?

Umferðarreglur í ACI eru kallaðar samningar. Í slíkum samningi verða einn eða fleiri hópar eða stig í fjölþættu forriti þjónustuveitandi (td gagnagrunnsþjónusta), aðrir verða neytendur. Samningurinn getur einfaldlega framhjá umferð, eða hann getur gert eitthvað erfiðara, til dæmis, beint því að eldvegg eða jafnvægistæki, og einnig breytt QoS gildinu.

Hvernig komast netþjónar inn í þessa hópa? Ef þetta eru líkamlegir netþjónar eða eitthvað sem er innifalið í núverandi neti sem við bjuggum til VLAN trunk inn í, til að setja þá í EPG þarftu að benda á skiptitengi og VLAN sem notað er á því. Eins og þú sérð birtast VLAN þar sem þú getur ekki verið án þeirra.

Ef netþjónarnir eru sýndarvélar, þá er nóg að vísa til tengda sýndarvæðingarumhverfisins, og þá mun allt gerast af sjálfu sér: hafnarhópur verður stofnaður (í skilmálar af VMWare) til að tengja VM, nauðsynleg VLAN eða VXLAN munu verða úthlutað, þeir verða skráðir á nauðsynlegar rofatengi o.s.frv. Svo, þó að ACI sé byggt í kringum líkamlegt net, líta tengingar fyrir sýndarþjóna miklu einfaldari út en fyrir líkamlega. ACI hefur nú þegar innbyggða tengingu við VMWare og MS Hyper-V, sem og stuðning fyrir OpenStack og RedHat sýndarvæðingu. Frá einhverjum tímapunkti hefur einnig birst innbyggður stuðningur fyrir gámapalla: Kubernetes, OpenShift, Cloud Foundry, á meðan það varðar bæði beitingu stefnu og eftirlit, það er að netkerfisstjórinn getur strax séð hvaða hýsingar sem belg vinna á og í hvaða hópa þeir falla.

Auk þess að vera innifalinn í tilteknum hafnarhópi hafa sýndarþjónar viðbótareiginleika: nafn, eiginleika o.s.frv., sem hægt er að nota sem viðmið til að flytja þá yfir í annan hóp, td þegar VM er endurnefnt eða viðbótarmerki birtist í það. Cisco kallar þetta örflokkunarhópa, þó að hönnunin sjálf með getu til að búa til marga öryggishluta í formi EPGs á sama undirneti sé í stórum dráttum líka talsverð örskipting. Jæja, seljandinn veit betur.

EPGs sjálfir eru eingöngu rökrétt smíðar, ekki bundnar við ákveðna rofa, netþjóna o.s.frv., svo þú getur gert hluti með þeim og smíðar út frá þeim (forrit og leigjendur) sem erfitt er að gera í venjulegum netum, eins og klónun. Þar af leiðandi skulum við segja að það sé mjög auðvelt að klóna framleiðsluumhverfi til að fá prófumhverfi sem er tryggt að sé eins og framleiðsluumhverfið. Þú getur gert það handvirkt, en það er betra (og auðveldara) í gegnum API.

Almennt séð er stjórnunarrökfræðin í ACI alls ekki svipuð því sem þú hittir venjulega
í hefðbundnum netkerfum frá sama Cisco: hugbúnaðarviðmótið er aðal og GUI eða CLI eru aukaatriði, þar sem þau vinna í gegnum sama API. Þess vegna byrja næstum allir sem taka þátt í ACI, eftir smá stund, að vafra um hlutlíkanið sem notað er við stjórnun og gera eitthvað sjálfvirkt til að passa þarfir þeirra. Auðveldasta leiðin til að gera þetta er frá Python: það eru þægileg tilbúin verkfæri fyrir það.

Lofaði hrífu

Helsta vandamálið er að margt í ACI er gert öðruvísi. Til að byrja að vinna með það venjulega þarftu að endurmennta þig. Þetta á sérstaklega við um netrekstrarteymi hjá stórum viðskiptavinum, þar sem verkfræðingar hafa „ávísað VLAN“ í mörg ár að beiðni. Sú staðreynd að nú eru VLAN ekki lengur VLAN og þú þarft ekki að búa til VLAN með höndunum til að leggja ný netkerfi í sýndarhýsa, sprengir algjörlega þakið af hefðbundnum netkerfum og fær þá til að loða við kunnuglegar aðferðir. Það skal tekið fram að Cisco reyndi að blekkja pilluna aðeins og bætti „NXOS-líku“ CLI við stjórnandann, sem gerir þér kleift að gera stillingar frá viðmóti svipað hefðbundnum rofum. En samt, til að byrja að nota ACI venjulega, verður þú að skilja hvernig það virkar.

Hvað varðar verð, á stórum og meðalstórum mælikvarða, eru ACI net í raun ekki frábrugðin hefðbundnum netkerfum á Cisco búnaði, þar sem sömu rofar eru notaðir til að byggja þau (Nexus 9000 getur virkað í ACI og í hefðbundnum ham og eru nú orðin aðal „vinnuhestur“ fyrir ný gagnaver verkefni). En fyrir gagnaver með tveimur rofum gerir nærvera stjórnenda og Spine-Leaf arkitektúr auðvitað vart við sig. Nýlega hefur komið fram Mini ACI verksmiðja, þar sem sýndarvélum er skipt út fyrir tvo af þremur stjórnendum. Þetta minnkar muninn á kostnaði, en hann er samt áfram. Þannig að fyrir viðskiptavininn ræðst valið af því hversu mikinn áhuga hann hefur á öryggiseiginleikum, samþættingu við sýndarvæðingu, einum stjórnunarstað og svo framvegis.

Heimild: www.habr.com