Undanfarin ár hefur Cisco verið virkur að kynna nýjan arkitektúr til að byggja upp gagnaflutningsnet í gagnaverinu - Application Centric Infrastructure (eða ACI). Sumir kannast nú þegar við það. Og sumum tókst jafnvel að innleiða það í fyrirtækjum sínum, þar á meðal í Rússlandi. Hins vegar, fyrir flesta upplýsingatæknifræðinga og upplýsingatæknistjóra, er ACI enn annað hvort óljós skammstöfun eða bara hugleiðing um framtíðina.
Í þessari grein munum við reyna að færa þessa framtíð nær. Til að gera þetta munum við tala um helstu byggingarhluta ACI og einnig sýna hvernig hægt er að nota það í reynd. Að auki munum við á næstunni skipuleggja sjónræna sýningu á ACI, sem allir áhugasamir upplýsingatæknisérfræðingar geta skráð sig á.
Þú getur lært meira um nýja netarkitektúrinn í St. Pétursborg í maí 2019. Allar upplýsingar eru inni . Skráðu þig!
Forsaga
Hefðbundna og vinsælasta netbyggingarlíkanið er þriggja stiga stigveldislíkan: kjarni -> dreifing (samsöfnun) -> aðgangur. Í mörg ár var þetta líkan staðalinn; framleiðendur framleiddu ýmis nettæki með viðeigandi virkni fyrir það.
Áður fyrr, þegar upplýsingatækni var eins konar nauðsynlegur (og satt að segja, ekki alltaf æskilegur) viðauki við viðskipti, var þetta líkan þægilegt, mjög kyrrstætt og áreiðanlegt. Hins vegar, nú þegar upplýsingatækni er einn af drifkraftum viðskiptaþróunar, og í mörgum tilfellum fyrirtækisins sjálfs, er kyrrstæða eðli þessa líkans farið að valda miklum vandamálum.
Nútímaviðskipti búa til fjölda mismunandi flókinna krafna fyrir netinnviði. Árangur fyrirtækisins veltur beint á tímasetningu innleiðingar þessara krafna. Seinkun á slíkum aðstæðum er óviðunandi og klassískt líkan af netbyggingu gerir oft ekki kleift að mæta öllum viðskiptaþörfum tímanlega.
Til dæmis, tilkoma nýs flókins viðskiptaforrits krefst þess að netstjórnendur framkvæmi fjölda svipaðra venjubundinna aðgerða á fjölda mismunandi nettækja á mismunandi stigum. Auk þess að vera tímafrekt eykur það einnig hættuna á mistökum sem geta leitt til alvarlegs niðurtíma upplýsingatækniþjónustu og þar af leiðandi fjárhagstjóns.
Rót vandans er ekki einu sinni frestarnir sjálfir eða hversu flóknar kröfurnar eru. Staðreyndin er sú að þessar kröfur þarf að „þýða“ úr tungumáli viðskiptaforrita yfir á tungumál netinnviða. Eins og þú veist er hvaða þýðing sem er alltaf að missa merkingu að hluta. Þegar eigandi forritsins talar um rökfræði umsóknar sinnar, skilur netkerfisstjóri safn VLAN, aðgangslista á tugum tækja sem þarf að styðja, uppfæra og skjalfesta.
Uppsöfnuð reynsla og stöðug samskipti við viðskiptavini gerði Cisco kleift að hanna og innleiða nýjar reglur til að byggja upp gagnaflutningsnet gagnavera sem uppfyllir nútíma strauma og byggir fyrst og fremst á rökfræði viðskiptaforrita. Þess vegna nafnið - Application Centric Infrastructure.
ACI arkitektúr.
Það er réttast að líta á ACI arkitektúrinn ekki frá líkamlegu hliðinni, heldur frá rökréttu hliðinni. Það er byggt á líkani sjálfvirkrar stefnu, en hlutum þeirra á efsta stigi má skipta í eftirfarandi þætti:
- Net byggt á Nexus rofum.
- APIC stjórnandi þyrping;
- Umsóknarsnið;
Við skulum skoða hvert stig nánar - og við munum fara frá einföldu yfir í flókið.
Net byggt á Nexus rofum
Netið í ACI verksmiðju er svipað og hefðbundið stigveldislíkan, en það er miklu einfaldara að byggja upp. Leaf-Spine líkanið er notað til að skipuleggja netið, sem er orðið almennt viðurkennd nálgun við innleiðingu næstu kynslóðar neta. Þetta líkan samanstendur af tveimur stigum: hrygg og lauf, í sömu röð.
Hryggjastigið ber aðeins ábyrgð á frammistöðu. Heildarafköst hryggrofa eru jöfn frammistöðu alls efnisins, þannig að rofa með 40G eða hærri tengi ætti að nota á þessu stigi.
Hryggrofar tengjast öllum rofum á næsta stigi: Laufarofar, sem endahýslar eru tengdir við. Meginhlutverk Leaf rofa er hafnargeta.
Þannig eru stærðarvandamál auðveldlega leyst: ef við þurfum að auka afköst efnisins, bætum við Spine rofum við, og ef við þurfum að auka hafnargetu, bætum við Leaf við.
Fyrir bæði stigin eru Cisco Nexus 9000 röð rofar notaðir, sem fyrir Cisco eru aðal tólið til að byggja upp gagnaver kerfi, óháð arkitektúr þeirra. Fyrir hryggjalagið eru Nexus 9300 eða Nexus 9500 rofar notaðir og aðeins fyrir Leaf Nexus 9300.
Módelúrval Nexus rofa sem eru notaðir í ACI verksmiðjunni er sýnt á myndinni hér að neðan.
APIC (Application Policy Infrastructure Controller) Controller Cluster
APIC stýringar eru sérhæfðir líkamlegir netþjónar, en fyrir litlar útfærslur er hægt að nota þyrping af einum líkamlegum APIC stjórnandi og tveimur sýndarstýringum.
APIC stýringar veita eftirlits- og eftirlitsaðgerðir. Það sem skiptir máli er að stýringar taka aldrei þátt í gagnaflutningi, það er, jafnvel þó að allir klasastýringar bregðist, mun þetta alls ekki hafa áhrif á stöðugleika netsins. Það skal líka tekið fram að með hjálp APICs stjórnar stjórnandinn algjörlega öllum líkamlegum og rökréttum auðlindum verksmiðjunnar og til að gera einhverjar breytingar er ekki lengur þörf á að tengjast tilteknu tæki, þar sem ACI notar einn stjórnunarstaður.
Nú skulum við halda áfram að einum af aðalþáttum ACI - umsóknarsnið.
Forritsnetsnið er rökréttur grundvöllur ACI. Það eru forritasnið sem skilgreina samskiptastefnu milli allra nethluta og lýsa nethlutunum sjálfum. ANP gerir þér kleift að draga úr efnislega laginu og í raun ímynda þér hvernig þú þarft að skipuleggja samskipti milli mismunandi nethluta frá sjónarhóli notkunar.
Forritssnið samanstendur af tengihópum (Endapunktahópar - EPG). Tengihópur er rökréttur hópur gestgjafa (sýndarvélar, líkamlegir netþjónar, gámar osfrv.) sem eru staðsettir í sama öryggishluta (ekki netkerfi, heldur öryggi). Hægt er að ákvarða lokahýsingar sem tilheyra tilteknu EPG út frá miklum fjölda viðmiða. Eftirfarandi er almennt notað:
- Líkamleg höfn
- Rökrétt tengi (gáttarhópur á sýndarrofanum)
- VLAN ID eða VXLAN
- IP tölu eða IP undirnet
- Eignir miðlara (nafn, staðsetning, stýrikerfisútgáfa osfrv.)
Fyrir samspil mismunandi EPGs er eining sem kallast samningar veitt. Samningurinn skilgreinir tengslin milli mismunandi EPG. Með öðrum orðum, samningurinn skilgreinir hvaða þjónustu einn EPG veitir öðrum EPG. Til dæmis búum við til samning sem gerir umferð kleift að flæða yfir HTTPS samskiptareglur. Næst tengjum við þessum samningi, til dæmis, EPG Web (hópur vefþjóna) og EPG App (hópur forritaþjóna), eftir það geta þessir tveir útstöðvarhópar skipt um umferð í gegnum HTTPS samskiptareglur.
Myndin hér að neðan lýsir dæmi um að setja upp samskipti milli mismunandi EPGs með samningum innan sama ANP.
Það getur verið hvaða fjöldi forritasniða sem er innan ACI verksmiðju. Að auki eru samningar ekki bundnir við ákveðna umsóknarsnið; þeir geta (og ættu) að vera notaðir til að tengja EPG í mismunandi ANPs.
Reyndar er hverju forriti sem krefst netkerfis á einu eða öðru formi lýst með eigin prófíl. Til dæmis sýnir skýringarmyndin hér að ofan staðlaðan arkitektúr þriggja þrepa forrits, sem samanstendur af N fjölda ytri aðgangsþjóna (vef), forritaþjóna (App) og DBMS netþjóna (DB), og lýsir einnig reglum um samskipti milli þeim. Í hefðbundnum netinnviðum væri þetta sett af reglum sem skrifaðar eru yfir hin ýmsu tæki í innviðunum. Í ACI arkitektúrnum lýsum við þessum reglum innan eins forritssniðs. ACI, með því að nota forritasnið, gerir það miklu auðveldara að búa til fjölda stillinga á mismunandi tækjum með því að flokka þær allar í eitt snið.
Myndin hér að neðan sýnir raunhæfara dæmi. Microsoft Exchange forritasnið gert úr mörgum EPG og samningum.
Miðstýring, sjálfvirkni og eftirlit er einn af helstu kostum ACI. ACI Factory leysir stjórnendur undan þeirri leiðinlegu vinnu að búa til fjölda reglna um ýmsa rofa, beina og eldveggi (á meðan hin klassíska handvirka stillingaraðferð er leyfð og hægt að nota). Stillingar fyrir forritasnið og aðra ACI hluti eru sjálfkrafa beittar um allt ACI efni. Jafnvel þegar þú skiptir líkamlega yfir netþjóna yfir í önnur tengi á efnisrofanum, þá er engin þörf á að afrita stillingar frá gömlum rofum yfir í nýja og hreinsa út óþarfa reglur. Byggt á EPG-aðildarskilyrðum gestgjafans mun verksmiðjan gera þessar stillingar sjálfkrafa og hreinsa sjálfkrafa upp ónotaðar reglur.
Innbyggðar ACI öryggisstefnur eru útfærðar sem hvítlistar, sem þýðir að það sem er ekki beinlínis leyfilegt er bannað sjálfgefið. Samhliða sjálfvirkri uppfærslu á stillingum netbúnaðar (fjarlægja „gleymdar“ ónotaðar reglur og heimildir), eykur þessi nálgun verulega heildarstig netöryggis og þrengir yfirborð hugsanlegrar árásar.
ACI gerir þér kleift að skipuleggja netsamskipti ekki aðeins sýndarvéla og gáma, heldur einnig líkamlegra netþjóna, vélbúnaðareldveggi og netbúnaðar þriðja aðila, sem gerir ACI að einstaka lausn í augnablikinu.
Ný aðferð Cisco til að byggja upp gagnanet byggt á rökfræði forrita snýst ekki aðeins um sjálfvirkni, öryggi og miðstýrða stjórnun. Það er líka nútímalegt lárétt skalanlegt net sem uppfyllir allar kröfur nútíma viðskipta.
Innleiðing netkerfis sem byggir á ACI gerir öllum deildum fyrirtækisins kleift að tala sama tungumálið. Stjórnandinn hefur aðeins rökfræði forritsins að leiðarljósi, sem lýsir nauðsynlegum reglum og tengingum. Auk rökfræði forritsins hafa eigendur og þróunaraðilar forritsins, upplýsingaöryggisþjónustuna, hagfræðinga og fyrirtækjaeigendur að leiðarljósi.
Þannig er Cisco að innleiða hugmyndina um næstu kynslóðar gagnaveranet. Viltu sjá þetta sjálfur? Komdu á sýninguna Application Centric Infrastructure í Pétursborg og vinna með gagnaveranet framtíðarinnar núna.
Hægt er að skrá sig á viðburðinn .
Heimild: www.habr.com