Viimastel aastatel on Cisco aktiivselt edendanud uut andmesidevõrgu arhitektuuri andmekeskustes — Rakendusele keskenduv infrastruktuur (ehk ACI). Mõned on sellega juba tutvunud. Teised on isegi saanud selle oma ettevõtetesse rakendada, sealhulgas Venemaal. Siiski on ACI enamusele IT-spetsialistidest ja IT-juhtidest veel kas arusaamatu lühend või lihtsalt jutt tulevikust.
Selles artiklis proovime seda tulevikku lähemale tuua. Selle eesmärgi nimel räägime ACI põhikomponentidest ning illustreerime, kuidas seda praktikas rakendada. Lisaks korraldame varsti ACI toimimise näidisdemo, kuhu saab registreeruda iga huviline IT-spetsialist.
Uue andmesidevõrgu arhitektuuri kohta saab rohkem teada 2019. aasta mais Peterburis. Kõik üksikasjad – aadressil . Registreerige end!
Eelalugu
Traditsiooniline ja kõige populaarsem võrgustruktuuri mudeleid on kolme taseme hierarhiline mudel: tuum > jaotamine (agregatsioon) > juurdepääs. Aastate jooksul on see mudel olnud standard, mille järgi tootjad on välja andnud erinevaid võrgu seadmeid, mis vastavad sellele funktsionaalsusele.
Kunagi, kui infotehnoloogia oli omamoodi hädavajalik (ja, peab ütlema, mitte alati soovitav) lisand äri juurde, oli see mudel mugav, üsna staatiline ja usaldusväärne. Kuid nüüd, kui IT on muutunud üheks äriarengu mootoriks ja paljuski isegi äri enda osaks, on selle mudeli staatilisus hakanud tekitama suuri probleeme.
Kaasaegne äri genereerib suurt hulka erinevaid keerulisi nõudmisi võrguinfrastruktuurile. Nõudmiste täitmise ajad sõltuvad otseselt äri edust. Viivitamine sellistes tingimustes on vastuvõetamatu ning klassikaline võrgumudel ei suuda tihti õigel ajal rahuldada kõiki äri vajadusi.
Näiteks toob uue keerulise äritarkvara ilmumine kaasa suurte administraatorite vajaduse teha palju sarnaseid rutiinseid operatsioone paljudes erinevates võrgu seadmetes erinevatel tasanditel. Lisaks sellele, et see võtab palju aega, suurendab see ka riski teha viga, mis võib põhjustada tõsiseid katkestusi IT-teenustes ja seega ka rahalisikahjusid.
Probleemi juureks ei ole isegi mitte tähtajad või nõuete keerukus. Asi on selles, et neid nõudeid tuleb 'tõlkida' äritarkvarast võrgu infrastruktuuri keelde. Nagu teada, tähendab iga tõlge alati osa tähenduse kaotust. Kui rakenduse omanik räägib oma rakenduse töölogikast, mõistab võrguadministraator hulka VLAN-e, Access List-e, mida tuleb toeks hoida, ajakohastada ja dokumenteerida.
Kogutud kogemus ja pidev suhtlemine klientidega on võimaldanud Cisco-l projekteerida ja rakendada uusi andmekeskuse andmeedastusvõrgu loomise põhimõtteid, mis vastavad kaasaegsetele suundumustele ja põhinevad peamiselt äri rakenduste loogikal. Seetõttu ka nimi — Rakendusele Keskenduv Infrastruktur.
ACI arhitektuur.
ACI arhitektuuri on kõige õigem vaadelda mitte füüsilisest küljest, vaid loogilisest. See põhineb automatiseeritud poliitikate mudelil, mille objekte saab kõrgel tasemel jagada järgmistesse komponentidesse:
- Nexus lülitite põhine võrk.
- APIC-kontrollerite klaster;
- Rakenduse profiilid;
Vaatame iga taset lähemalt – liikudes kergemalt keerulisemaks.
Nexus lülitite põhine võrk
ACI-fabriku võrk sarnaneb traditsioonilise hierarhilise mudeliga, kuid seda on oluliselt lihtsam üles ehitada. Võrgu korraldamiseks kasutatakse Leaf-Spine mudelit, mis on muutunud uue põlvkonna võrkude rakendamiseks üldiselt aktsepteeritud lähenemisviisiks. See mudel koosneb kahest tasemest: Spine ja Leaf, vastavalt.
Spine-tasandi vastutab ainult jõudluse eest. Spine-lülitite kogujõudlus on võrgu kogu jõudlus, mistõttu tuleb sellel tasemel kasutada 40G või kõrgemat kiirete lülititega.
Spine-lülitid on ühendatud kõigi järgmise taseme lülititega: Leaf-lülititega, millega on ühendatud lõpp-teenindajad. Leaf-lülitite peamine roll on portide mahutavus.
Seega on skaleerimise küsimused lihtsad: kui me peame suurendama tehase läbilaskevõimet, lisame Spine-lülitid, ja kui me peame suurendama portide mahutavust – Leaf-lülitid.
Mõlemal tasemel kasutatakse Cisco Nexus 9000 seeria lüliteid, mis on Cisco põhivahend andmekeskuse võrkude ehitamiseks sõltumata arhitektuurist. Spine-taseme jaoks kasutatakse Nexus 9300 või Nexus 9500 lüliteid, Leaf-taseme jaoks ainult Nexus 9300.
Nexus-lülitite mudelid, mida kasutatakse ACI tehases, on toodud alloleval joonisel.
APIC (Application Policy Infrastructure Controller) klaster.
APIC-kontrollerid on spetsialiseeritud füüsilised serverid, samas lubatakse väiksemate rakenduste puhul kasutada ühte füüsilist APIC-kontrollerit ja kahte virtuaalset.
APIC-kontrollerid täidavad haldus- ja jälgimisfunktsioone. Oluline on, et kontrollerid ei osale kunagi andmete edastamises, seega, isegi kui kõik klastrite kontrollerid ebaõnnestuvad, ei mõjuta see võrgu stabiilsust absoluutselt. Samuti tuleb märkida, et APIC-ide abil haldab administraator kõiki füüsilisi ja loogilisi ressursse tehases, ja et muudatuste tegemiseks ei ole vaja enam ühendust võtta üksikute seadmetega, kuna ACI-s kasutatakse ühte halduspunkte.
Nüüd liigume edasi ühe ACI peamise komponendi juurde – rakenduste profiilide juurde.
Rakenduse profiil (Application Network Profile) – see on ACI loogiline alus. Just rakendusprofiilid määravad poliitikad, kuidas kõikide võrgu segmentide vahel suhelda, ja kirjeldavad otse võrgu segmente. ANP võimaldab abstraktiseerida füüsiliselt tasemelt ja esindab, kuidas korraldada erinevate võrgu segmente interaktsiooni rakenduse vaatenurgast.
Rakendusprofiil koosneb ühendusgruppidest (End-point groups – EPG). Ühendusgrupp on loogiline grupp hoste (virtuaalmasinad, füüsilised serverid, konteinerid jne), mis asuvad ühes turvasegmentis (mitte võrgus, vaid just turvalisuse mõttes). Lõpuhostid, mis kuuluvad teatud EPG-sse, võivad olla määratletud paljude kriteeriumide alusel. Tavalised on järgmised:
- Füüsiline port
- Loogiline port (port-grupp virtuaalses lülituses)
- VLAN ID või VXLAN
- IP-aadress või IP-alamvõrk
- Serveri atribuudid (nimi, asukoht, operatsioonisüsteemi versioon jne)
Erinevate EPG-de koostööks on ette nähtud objekt, mida nimetatakse lepinguteks. Leping määratleb suhted erinevate EPG-de vahel. Teisisõnu, leping määrab, millist teenust üks EPG osutab teisele EPG-le. Näiteks loome lepingu, mis lubab liikluse edastamist HTTPS-protokolli kaudu. Seejärel ühendame selle lepingu, näiteks, EPG Web (veebiserverite rühm) ja EPG App (rakenduste serverite rühm), mistõttu saavad need kaks lõppgruppi vahetada liiklust HTTPS-protokolli kaudu.
Alloleval joonisel on toodud näide erinevate EPG-de ühenduse seadistamisest lepingute kaudu ühe ANP raames.
ACI-tehases võib olla piiramatu hulk rakenduste profiile. Samuti ei ole lepingud seotud konkreetse rakenduste profiiliga, neid saab (ja tuleb) kasutada EPG-de ühendamiseks erinevates ANP-des.
Iga rakendus, mis vajab võrku, on esindatud oma profiiliga. Näiteks on ülaltoodud skeemil kujutatud kolmekihilise rakenduse standardne arhitektuur, mis koosneb N arvust väljuvatest veebiserveritest (Web), rakenduste serveritest (App) ja andmebaasiserveritest (DB), samuti on kirjeldatud nende vahelise suhtluse reegleid. Traditsioonilises võrguinfrastruktuuris oleks see rida reegleid, mis on kirja pandud erinevates seadmetes. ACI arhitektuuris kirjeldame neid reegleid ühes rakenduse profiilis. ACI rakenduse profiili kaudu on võimalik märkimisväärselt lihtsustada paljude seadistuste loomist erinevates seadmetes, koondades need kõik ühte profiili.
Alloleval joonisel on toodud elukohasem pelzisaade. Microsoft Exchange'i rakenduse profiil, mis koosneb mitmest EPG-st ja lepingust.
Keskne juhtimine, automatiseerimine ja jälgimine on ACI üks peamisi eeliseid. ACI tehas vabastab administraatorid igapäevastest ülesannetest, mis on seotud suure hulga reeglite koostamisega erinevates lülitites, marsruutijates ja tulemüürides (samal ajal on klassikaline käsitsi seadistamise meetod lubatud ja seda saab kasutada). Rakenduste profiilide ja teiste ACI objektide seaded rakendatakse automaatselt kogu ACI tehases. Isegi kui serverid füüsiliselt lülitatakse lülitite teistesse portidesse, ei ole vajalik vanade lülitite seadeid uutele dubleerida ja mittefunktsionaalseid reegleid kustutada. Vastavalt hosti kuuluvuse kriteeriumidele EPG-s, tehas rakendab neid seadeid automaatselt ja puhastab automaatselt kasutamata reeglid.
ACI integreeritud turvapoliitikad on rakendatud valge nimekirja põhimõtte järgi, mis tähendab, et kõik, mis ei ole selgesõnaliselt lubatud, on vaikimisi keelatud. Koos võrguseadmete konfigureerimise automaatse ajakohastamisega (kasutamata reeglite ja lubade eemaldamine) suurendab see lähenemine oluliselt võrgu koguturvalisust ning kitsendab potentsiaalse rünnaku pinda.
ACI võimaldab korraldada võrgu suhtlemist mitte ainult virtuaalsete masinate ja konteinerite, vaid ka füüsiliste serverite, riistvarapõhiste tulemüüride ja kolmandate osapoolte võrguseadmete vahel, mis teeb ACI praegu unikaalse lahenduse.
Cisco uus lähenemine andmesidevõrgu ehitusele rakenduste loogika alusel ei tähenda ainult automatiseerimist, turvalisust ja tsentraliseeritud haldust. See on ka kaasaegne horisontaalselt skaleeritav võrk, mis vastab kõigile kaasaegse äri nõudmistele.
Application Centric Infrastructure'i rakendamine ACI põhjal võimaldab kõigil ettevõtte osakondadel suhtlemiseks ühtset keelt. Halduse põhialuseks on rakenduse tööloogika, kus on määratletud vajalikud reeglid ja seosed. Samuti järgivad rakenduse tööloogikat rakenduse omanikud ja arendajad, infotehnoloogia teenus, raamatupidajad ning ettevõtte omanikud.
Nii viib Cisco praktikas ellu uue põlvkonna andmekeskuse võrgu kontseptsiooni. Kas tahate ise veenduda? Tulge näidisessioonile Application Centric Infrastructure Peterburis ja nautige tuleviku andmekeskuse võrku juba täna.
Sündmusele registreeruda on võimalik .
Allikas: habr.com
