Viimastel aastatel on Cisco aktiivselt propageerinud uut arhitektuuri andmekeskuses andmeedastusvõrgu ehitamiseks – Rakenduskeskne infrastruktuur (või ACI). Mõned on sellega juba tuttavad. Ja mõnel õnnestus see isegi oma ettevõtetes, sealhulgas Venemaal, rakendada. Enamiku IT-spetsialistide ja IT-juhtide jaoks on ACI aga endiselt kas ebaselge akronüüm või lihtsalt peegeldus tulevikule.
Selles artiklis püüame seda tulevikku lähemale tuua. Selleks räägime ACI peamistest arhitektuursetest komponentidest ning illustreerime ka seda, kuidas seda praktikas kasutada saab. Lisaks korraldame lähiajal ACI visuaalse demonstratsiooni, kuhu saab registreeruda iga huvitatud IT-spetsialist.
Uue võrguarhitektuuriga saab lähemalt tutvuda 2019. aasta mais Peterburis. Kõik üksikasjad on sees . Registreeri!
eelajalugu
Traditsiooniline ja populaarseim võrguehitusmudel on kolmetasandiline hierarhiline mudel: tuum -> jaotus (agregatsioon) -> juurdepääs. See mudel oli aastaid olnud standard, tootjad valmistasid erinevaid võrguseadmeid, millel oli selle jaoks sobiv funktsionaalsus.
Varem, kui infotehnoloogia oli omamoodi vajalik (ja ausalt öeldes mitte alati soovitud) lisand ettevõtlusele, oli see mudel mugav, väga staatiline ja usaldusväärne. Kuid nüüd, mil IT on üks äriarenduse tõukejõude ja paljudel juhtudel ka äri ise, on selle mudeli staatiline olemus hakanud tekitama suuri probleeme.
Kaasaegne äri loob võrgu infrastruktuurile suure hulga erinevaid keerulisi nõudeid. Ettevõtte edu sõltub otseselt nende nõuete täitmise ajast. Hilinemine sellistes tingimustes on vastuvõetamatu ja võrgu ehitamise klassikaline mudel ei võimalda sageli kõiki ärivajadusi õigeaegselt täita.
Näiteks nõuab uue keeruka ärirakenduse tekkimine võrguadministraatoritelt suure hulga sarnaseid rutiinseid toiminguid suurel hulgal erinevatel võrguseadmetel erinevatel tasanditel. Lisaks sellele, et see on aeganõudev, suurendab see ka eksimise ohtu, mis võib tuua kaasa tõsiseid IT-teenuste seisakuid ja sellest tulenevalt rahalist kahju.
Probleemi juur ei ole isegi tähtajad ise ega nõuete keerukus. Fakt on see, et need nõuded tuleb "tõlkida" ärirakenduste keelest võrgu infrastruktuuri keelde. Nagu teate, on iga tõlge alati osaline tähenduse kaotus. Kui rakenduse omanik räägib oma rakenduse loogikast, mõistab võrguadministraator VLAN-ide komplekti, Accessi loendeid kümnete seadmete kohta, mida tuleb toetada, värskendada ja dokumenteerida.
Kogutud kogemused ja pidev suhtlus klientidega võimaldasid Ciscol kavandada ja juurutada andmekeskuse andmeedastusvõrgu ehitamiseks uusi põhimõtteid, mis vastavad tänapäevastele trendidele ja põhinevad ennekõike ärirakenduste loogikal. Sellest ka nimi – Application Central Infrastructure.
ACI arhitektuur.
Kõige õigem on käsitleda ACI arhitektuuri mitte füüsilisest, vaid loogilisest küljest. See põhineb automatiseeritud poliitikate mudelil, mille tipptasemel olevad objektid saab jagada järgmisteks komponentideks:
- Nexuse lülititel põhinev võrk.
- APIC kontrollerite klaster;
- Rakendusprofiilid;
Vaatame iga taset üksikasjalikumalt - ja liigume lihtsast keeruliseks.
Nexuse lülititel põhinev võrk
ACI tehase võrk sarnaneb traditsioonilise hierarhilise mudeliga, kuid seda on palju lihtsam ehitada. Võrgu korrastamiseks kasutatakse Leaf-Spine mudelit, millest on saanud üldtunnustatud lähenemine järgmise põlvkonna võrkude juurutamisel. See mudel koosneb kahest tasemest: vastavalt selg ja leht.
Lülisamba tase vastutab ainult jõudluse eest. Spine-lülitite kogujõudlus on võrdne kogu kanga jõudlusega, seega tuleks sellel tasemel kasutada 40G või suurema pordiga lüliteid.
Lülisambalülitid ühenduvad kõigi järgmisel tasemel olevate lülititega: Lehtlülitid, mille külge on ühendatud otsahostid. Leafi lülitite peamine roll on pordi läbilaskevõime.
Seega on skaleerimise probleemid kergesti lahendatavad: kui on vaja suurendada kanga läbilaskevõimet, lisame Spine switchid ja kui on vaja suurendada pordi mahtu, lisame Leafi.
Mõlema taseme jaoks on kasutusel Cisco Nexus 9000 seeria lülitid, mis on Cisco jaoks andmekeskuste võrkude ehitamisel põhiliseks tööriistaks, sõltumata nende arhitektuurist. Seljakihi jaoks kasutatakse Nexus 9300 või Nexus 9500 lüliteid ja Leafi jaoks ainult Nexus 9300.
ACI tehases kasutatavate Nexuse lülitite mudelivalik on näidatud alloleval joonisel.
APIC (Application Policy Infrastructure Controller) kontrollerite klaster
APIC-kontrollerid on spetsiaalsed füüsilised serverid, samas kui väikeste rakenduste jaoks on võimalik kasutada klastrit ühest füüsilisest APIC-kontrollerist ja kahest virtuaalsest.
APIC-kontrollerid pakuvad juhtimis- ja jälgimisfunktsioone. Oluline on see, et kontrollerid ei osale kunagi andmeedastuses, st isegi kui kõik klastri kontrollerid ebaõnnestuvad, ei mõjuta see võrgu stabiilsust üldse. Samuti tuleb märkida, et APIC-de abil haldab administraator absoluutselt kõiki tehase füüsilisi ja loogilisi ressursse ning muudatuste tegemiseks ei pea enam konkreetse seadmega ühendust looma, kuna ACI kasutab üks kontrollpunkt.
Liigume nüüd edasi ühe ACI põhikomponendi – rakendusprofiilide – juurde.
Rakenduse võrguprofiil on ACI loogiline alus. Rakendusprofiilid määratlevad interaktsioonipoliitikad kõigi võrgusegmentide vahel ja kirjeldavad võrgusegmente endid. ANP võimaldab teil abstraheerida füüsilisest kihist ja tegelikult ette kujutada, kuidas peate korraldama erinevate võrgusegmentide vahelist suhtlust rakenduse vaatepunktist.
Rakenduse profiil koosneb ühendusrühmadest (lõpp-punkti rühmad – EPG). Ühendusgrupp on loogiline rühm hoste (virtuaalsed masinad, füüsilised serverid, konteinerid jne), mis asuvad samas turbesegmendis (mitte võrk, vaid turvalisus). Konkreetsesse EPG-sse kuuluvad lõpp-hostid saab määrata paljude kriteeriumide alusel. Tavaliselt kasutatakse järgmist:
- Füüsiline port
- Loogiline port (pordirühm virtuaalsel kommutaatoril)
- VLAN ID või VXLAN
- IP-aadress või IP-alamvõrk
- Serveri atribuudid (nimi, asukoht, OS-i versioon jne)
Erinevate EPG-de koostoimeks pakutakse olemit, mida nimetatakse lepinguteks. Leping määrab suhte erinevate EPG-de vahel. Teisisõnu määratleb leping, millist teenust üks EPG teisele EPG-le pakub. Näiteks loome lepingu, mis võimaldab liiklusel liikuda HTTPS-protokolli kaudu. Järgmisena ühendame selle lepinguga näiteks EPG Web (veebiserverite rühm) ja EPG App (rakendusserverite rühm), mille järel saavad need kaks terminalirühma HTTPS-protokolli kaudu liiklust vahetada.
Alloleval joonisel on näide erinevate EPG-de vahelise suhtluse loomisest sama ANP piires sõlmitud lepingute kaudu.
ACI tehases võib olla suvaline arv rakendusprofiile. Lisaks ei ole lepingud seotud konkreetse rakendusprofiiliga; neid saab (ja tuleks) kasutada EPG-de ühendamiseks erinevates ANP-des.
Tegelikult kirjeldatakse iga rakendust, mis ühel või teisel kujul nõuab võrku, oma profiiliga. Näiteks näitab ülaltoodud diagramm kolmetasandilise rakenduse standardarhitektuuri, mis koosneb N arvust välistest juurdepääsuserveritest (veeb), rakendusserveritest (rakendus) ja DBMS-i serveritest (DB), ning kirjeldab ka interaktsioonireegleid neid. Traditsioonilises võrguinfrastruktuuris oleks see reeglite kogum, mis on kirjutatud infrastruktuuri erinevatele seadmetele. ACI arhitektuuris kirjeldame neid reegleid ühes rakenduse profiilis. Rakendusprofiili kasutav ACI muudab palju lihtsamaks suure hulga seadete loomise erinevates seadmetes, rühmitades need kõik ühte profiili.
Alloleval pildil on realistlikum näide. Microsoft Exchange'i rakenduse profiil, mis on valmistatud mitmest EPG-st ja lepingust.
Keskhaldus, automatiseerimine ja monitooring on ACI üks peamisi eeliseid. ACI Factory vabastab administraatorid tüütust tööst, mis on seotud suure hulga reeglite loomisega erinevatele lülititele, ruuteritele ja tulemüüridele (samas, kui klassikaline käsitsi seadistamise meetod on lubatud ja seda saab kasutada). Rakendusprofiilide ja muude ACI objektide sätteid rakendatakse automaatselt kogu ACI kangale. Isegi serverite füüsilisel ümberlülitamisel muudele kangaslülitite portidele pole vaja sätteid vanadelt lülititelt uutele dubleerida ja tarbetuid reegleid kustutada. Hosti EPG liikmelisuse kriteeriumide alusel teeb tehas need sätted automaatselt ja puhastab automaatselt kasutamata reeglid.
Integreeritud ACI turbepoliitikaid rakendatakse valgete nimekirjadena, mis tähendab, et see, mis pole selgesõnaliselt lubatud, on vaikimisi keelatud. Koos võrguseadmete konfiguratsioonide automaatse värskendamisega ("unustatud" kasutamata reeglite ja lubade eemaldamine) tõstab selline lähenemine oluliselt üldist võrguturbe taset ja kitsendab võimaliku rünnaku pinda.
ACI võimaldab korraldada mitte ainult virtuaalmasinate ja konteinerite, vaid ka füüsiliste serverite, riistvara tulemüüride ja kolmandate osapoolte võrguseadmete võrguinteraktsiooni, mis teeb ACI-st hetkel ainulaadse lahenduse.
Cisco uus lähenemine rakendusloogikal põhineva andmevõrgu ehitamisele ei seisne ainult automatiseerimises, turvalisuses ja tsentraliseeritud halduses. Ühtlasi on tegu kaasaegse horisontaalselt skaleeritava võrguga, mis vastab kõikidele kaasaegse ettevõtluse nõuetele.
ACI-l põhineva võrguinfrastruktuuri juurutamine võimaldab kõigil ettevõtte osakondadel rääkida sama keelt. Administraator juhindub ainult rakenduse loogikast, mis kirjeldab vajalikke reegleid ja ühendusi. Nagu ka rakenduse loogikas, sellest juhinduvad rakenduse omanikud ja arendajad, infoturbeteenistus, majandusteadlased ja ettevõtete omanikud.
Seega viib Cisco ellu järgmise põlvkonna andmekeskuste võrgu kontseptsiooni. Kas soovite seda ise näha? Tulge demonstratsioonile Rakenduskeskne infrastruktuur Peterburis ja töötage tuleviku andmekeskuste võrguga juba praegu.
Üritusele saab registreeruda .
Allikas: www.habr.com