Viimastel aastatel on Cisco aktiivselt edendanud uut andmesidevõrgu arhitektuuri andmekeskustes — Rakenduskeskne infrastruktuur (või ACI), millest mõned on juba tuttavad. On ka neid, kes on jõudnud seda oma ettevõtetes rakendada, sealhulgas Venemaal. Kuid enamikule IT-spetsialistidest ja IT-juhtidest on ACI kas arusaamatu akronüüm või lihtsalt arutelu tuleviku üle.
Selles artiklis üritame seda tulevikku lähemale tuua. Selleks räägime ACI põhikomponentidest ning illustreerime, kuidas seda praktikas rakendada. Lisaks korraldame peagi visuaalse demonstreerimise ACI töötamisest, kuhu saab registreeruda iga huvitatud IT-spetsialist.
Uue võrgu arhitektuuri kohta saab rohkem teada Saint-Peterburis mai 2019. aastal. Kõik üksikasjad on . Registreeruge!
Eellugu
Traditsiooniline ja kõige populaarsem võrguline mudel on kolmetasandiline hierarhiline mudel: tuum -> jaotamine (agregatsioon) -> juurdepääs. Aastaid on see mudel olnud ideaal, mille järgi tootjad on välja töötanud erinevaid võrguseadmeid vastava funktsionaalsusega.
Varem, kui infotehnoloogia oli mingil määral vajalik (ja, olgem ausad, mitte alati soovitud) lisand äritegevusele, oli see mudel mugav, üsna staatiline ja usaldusväärne. Kuid nüüd, kui IT on muutunud üheks äriarenduse juhiks ja paljude juhtude puhul ka äritegevuseks endaks, on selle mudeli staatilisus tekitanud suuri probleeme.
Kaasaegne äri genereerib suure hulga erinevaid keerulisi nõudmisi võrgu infrastruktuurile. Nende nõudmiste täitmise ajast sõltub otse ettevõtte edukus. Viivitamine sellistes olukordades on vastuvõetamatu ning klassikaline võrgu mudel ei suuda sageli õigel ajal rahuldada kõiki äri vajadusi.
Näiteks uue keerulise äriteabe rakenduse ilmumine eeldab võrguadministraatorite poolt suurt hulka ühesuguseid rutiinseid toiminguid paljudes erinevates võrgu seadmetes erinevatel tasemetel. Pealegi võtab see aega ja suurendab ohtu teha viga, mis võib viia tõsise IT-teenuste seiskumiseni ja seega rahaliste kahjudeni.
Probleemi juured ei seisne isegi mitte tähtaegades või nõuete keerukuses. Asi on selles, et neid nõudeid on vaja "tõlkida" äriteabe rakenduste keelest võrgu infrastruktuuri keelde. Nagu teada, toob iga tõlge alati kaasa osalise tähenduse kaotuse. Kui rakenduse omanik räägib oma rakenduse töölogikast, mõistab võrguadministraator kümnete seadmete VLANide ja Access listide kogumit, mida on vaja hallata, ajakohastada ja dokumenteerida.
Kogutud kogemus ja pidev suhtlemine klientidega on võimaldanud Cisco-l projekteerida ja rakendada uusi põhimõtteid andmeedastusvõrgu ehitamiseks, mis vastavad kaasaegsetele suundumustele ja põhinevad peamiselt äriteabe rakenduste loogikal. Seetõttu nimetatakse seda Application Centric Infrastructure'iks.
ACI arhitektuur.
ACI arhitektuuri tuleks kõige paremini käsitleda mitte füüsiliselt, vaid loogiliselt. See põhineb automatiseeritud poliitikate mudelil, mille objektiid on kõrgel tasemel jagatavad järgmisteks komponentideks:
- Nexus-lülititel põhinev võrk.
- APIC-i kontrollerite klaster;
- Rakenduse profilid;
Vaatleme iga taset üksikasjalikumalt – liikudes lihtsast keeruliseni.
Nexus-lülititel põhinev võrk
ACI tehases asuv võrk sarnaneb traditsioonilisele hierarhilisele mudelile, kuid seda ehitatakse oluliselt lihtsamalt. Võrgu korraldamiseks kasutatakse Leaf-Spine mudelit, mis on saanud uue põlvkonna võrkude rakendamisel üldiselt aktsepteeritud lähenemisviisiks. See mudel koosneb kahest tasemest: Spine ja Leaf, vastavalt.
Spine-tase vastutab ainult jõudluse eest. Spine-lülitite kogujõudlus on kogu tehase jõudluse summa, seega tuleks sellel tasemel kasutada lüliteid, mille portide kiirus on 40G või rohkem.
Spine-lülitid ühenduvad kõigi järgmise taseme lülititega: Leaf-lülititega, millele on ühendatud lõpp-hostid. Leaf-lülitite peamine roll on portide maht.
Seega on lihtne lahendada skaleerimise küsimusi: kui me vajame tehase läbilaskevõime suurendamist, lisame Spine-lüliteid, ja kui me vajame portide mahu suurendamist – Leaf.
Mõlema taseme jaoks kasutatakse Cisco Nexus 9000 seeria lüliteid, mis on Cisco põhivahend andmekeskuste (DC) võrkude loomisel sõltumata nende arhitektuurist. Spine-taseme jaoks kasutatakse Nexus 9300 või Nexus 9500 lüliteid, Leaf-taseme jaoks ainult Nexus 9300.
ACI tehases kasutatavate Nexus-lülite seeria on esitatud alloleval joonisel.
APIC (Application Policy Infrastructure Controller) juhtrühma klaster
APIC-juhtimisseadmed on spetsialiseeritud füüsilised serverid, samas väikeste rakenduste puhul on lubatud kasutada ühte füüsilist APIC-juhtimisseadet ja kahte virtuaalset.
APIC-juhtimisseadmed täidavad haldus- ja jälgimisfunktsioone. Oluline on see, et juhtrühmad ei osale kunagi andmete edastamises, see tähendab, et isegi kui kõik klastris olevad juhtrühmad ebaõnnestuvad, ei mõjuta see võrgu stabiilsust. Samuti tuleb märkida, et APIC-ide abil haldab administraator kõiki füüsilisi ja loogilisi tehase ressursse, ning et muudatuste tegemiseks ei ole vajalik enam seadmele otse juurde pääseda, kuna ACI-s kasutatakse ühtset juhtimispunkti.
Nüüd liigume ühe ACI peamise komponente juurde – rakenduse profiilide juurde.
Rakenduse profiil (Application Network Profile) on ACI loogiline alus. Just rakenduse profiilid määravad poliitikad, mille kaudu kõik võrgu segmendid suhtlevad, ja kirjeldavad otse neid võrgu segmente. ANP võimaldab eristada füüsilisest tasemest ja põhimõtteliselt kujutada, kuidas korraldada suhtlemist erinevate võrgu segmentide vahel rakenduse vaatenurgast.
Rakenduse profiil koosneb ühenduste rühmadest (End-point groups – EPG). Ühenduste rühm on loogiline hostide (virtuaalmasinate, füüsiliste serverite, konteinerite jne) grupp, mis asub samas turvasegmendis (mitte võrgus, vaid täpselt turvalisuses). Lõppühendid, mis kuuluvad teatud EPG-sse, võivad olla määratud suure hulga kriteeriumitega. Tavaliselt kasutatakse järgmisi:
- Füüsiline port
- Loogiline port (port-rühm virtuaalses lülitajas)
- VLAN ID või VXLAN
- IP-aadress või IP-alamvõrk
- Serveri atribuudid (nimi, asukoht, OS versioon jne)
Erinevate EPG-de vaheline suhtlemine on reguleeritud olemuse kaudu, mida nimetatakse lepinguteks. Leping määratleb suhted erinevate EPG-de vahel. Teisisõnu, leping määrab, millist teenust üks EPG teisele EPG-le pakub. Näiteks loome lepingu, mis lubab liiklusel kulgeda HTTPS-protokolli kaudu. Seejärel ühendame selle lepinguga näiteks EPG Web (veebiserverite rühm) ja EPG App (rakenduste serverite rühm), mille tulemusena saavad need kaks lõppgruppi omavahel vahetada liiklust HTTPS-protokolli kaudu.
Alloleval joonisel on välja toodud erinevate EPG-de ühendamise seadistuse näide lepingute kaudu ühe ANP raames.
ACI-fabriku raames võib olla suvaline hulk rakenduse profiile. Lisaks ei ole lepingud seotud konkreetse rakenduse profiiliga, neid võib (ja tuleks) kasutada EPG-de ühendamiseks erinevates ANP-des.
Sisuliselt on iga rakendus, millel on mingil moel vaja võrku, kirjeldatud oma profiili kaudu. Näiteks on ülaltoodud skeemil näidatud klassikalise kolme kihiga rakenduse standardarhitektuur, mis koosneb N-arvust väljuva juurdepääsu serveritest (Web), rakenduste serveritest (App) ja andmebaasi serveritest (DB), samuti on kirjeldatud nendevahelisi suhtlemisreegleid. Traditsioonilises võrguinfrastruktuuris oleks see komplekt reegleid, mis on määratletud erinevates seadmetes infrastruktuuris. ACI arhitektuuris kirjeldame neid reegleid ühe rakenduse profiili raames. ACI võimaldab rakenduse profiili kaudu oluliselt lihtsustada suure hulga seadistuste loomist erinevates seadmetes, grupeerides need kõik ühte profiili.
Alloleval joonisel on näidatud elulähedasem näide. Microsoft Exchange'i rakenduse profiil, mis koosneb mitmest EPG-st ja lepingust.
Keskne haldus, automatiseerimine ja jälgimine on ACI üheks võtmeeeliseks. ACI tehas vabastab administraatorid rutiinsest tööst, mis on seotud suure hulga reeglite loomisega erinevates lülitites, marsruuterites ja tulemüürides (samal ajal on klassikaline käsitsi seadistamine lubatud ja seda saab kasutada). Rakenduste profiilide ja teiste ACI objektide seadistused kehtivad automaatselt kogu ACI tehases. Isegi füüsilise serveri vahetamisel tehase lülitite teistes portides ei ole vaja vanade lülitite seadistusi uutele dubleerida ja eemaldada mittevajalikke reegleid. Vali hosti kuuluvuse alusel EPG-le, teeb tehas need seadistused automaatselt ja puhastab automaatselt kasutamata reeglid.
Integreeritud ACI turvapoliitikad on ellu viidud valgete nimekirjade põhimõttel, st mis on selgelt keelatud, on vaikimisi keelatud. Koos võrgu seadmete konfigureerimise automaatse värskendamisega (kasutamata reeglite ja lubade eemaldamine) tõstab see lähenemine oluliselt üldist võrgu turvalisuse taset ja vähendab potentsiaalsete rünnakupindade suurust.
ACI võimaldab korraldada võrguside mitte ainult virtuaalsete masinate ja konteinerite, vaid ka füüsiliste serverite, riistvaraliste äriprotsesside ja kolmandate osapoolte võrgu seadmete vahel, muutes ACI hetkel ainulaadseks lahenduseks.
Cisco uus lähenemine andmesidevõrgu loomisele rakenduste loogika alusel ei ole mitte ainult automatiseerimine, turvalisus ja keskne haldus. See on ka kaasaegne horisontaalselt skaleeritav võrk, mis vastab tänapäeva ärinõuetele.
ACI-põhise võrgu infrastruktuuri rakendamine võimaldab kõikidel ettevõtte osakondadel rääkida ühte keelt. Administraator juhindub ainult rakenduse tööloogikast, milles on kirjas vajalikud reeglid ja sidemed. Samuti järgivad rakenduse omanikud ja arendajad, infotehnoloogia teenistuse, ökonomistid ja äriomanikud rakenduse tööloogikat.
Nii et, ettevõte Cisco toob tegelikult ellu järgmise põlvkonna andmekeskuse võrgu kontseptsiooni. Kas soovite ise veenduda? Tulge vaatama näidist. Rakendusele keskenduv infrastruktuur Peterburis ja töötage tuleviku andmekeskuse võrgu kallal juba täna.
Sündmustele saab registreeruda .
Allikas: habr.com
