Cisco on viime vuosina aktiivisesti edistänyt uutta arkkitehtuuria datakeskuksen tiedonsiirtoverkon rakentamiseen - Sovelluskeskeinen infrastruktuuri (tai ACI). Joillekin se on jo tuttu. Ja jotkut jopa onnistuivat toteuttamaan sen yrityksissään, myös Venäjällä. Useimmille IT-ammattilaisille ja IT-johtajille ACI on kuitenkin edelleen joko hämärä lyhenne tai vain heijastus tulevaisuudesta.
Tässä artikkelissa yritämme tuoda tätä tulevaisuutta lähemmäksi. Tätä varten puhumme ACI:n tärkeimmistä arkkitehtonisista komponenteista ja havainnollistamme myös kuinka sitä voidaan käyttää käytännössä. Lisäksi järjestämme lähitulevaisuudessa ACI:n visuaalisen esittelyn, johon kuka tahansa kiinnostunut IT-asiantuntija voi ilmoittautua.
Voit oppia lisää uudesta verkkoarkkitehtuurista Pietarissa toukokuussa 2019. Kaikki yksityiskohdat ovat mukana . Kirjaudu!
esihistoria
Perinteinen ja suosituin verkon rakentamismalli on kolmitasoinen hierarkkinen malli: ydin -> jakelu (aggregointi) -> pääsy. Useiden vuosien ajan tämä malli oli vakio, valmistajat tuottivat erilaisia verkkolaitteita, joissa oli siihen sopivat toiminnot.
Aikaisemmin, kun tietotekniikka oli eräänlainen välttämätön (ja suoraan sanottuna, ei aina haluttu) lisäosa liiketoiminnalle, tämä malli oli kätevä, erittäin staattinen ja luotettava. Nyt kun IT on kuitenkin yksi liiketoiminnan kehittämisen ajureista ja monissa tapauksissa myös itse liiketoiminnasta, mallin staattisuus on alkanut aiheuttaa suuria ongelmia.
Nykyaikainen liiketoiminta tuottaa suuren joukon erilaisia monimutkaisia vaatimuksia verkkoinfrastruktuurille. Yrityksen menestys riippuu suoraan näiden vaatimusten täytäntöönpanon ajoituksesta. Viivästyminen tällaisissa olosuhteissa ei ole hyväksyttävää, ja klassinen verkkorakentamisen malli ei useinkaan mahdollista kaikkia liiketoiminnan tarpeita oikea-aikaisesti.
Esimerkiksi uuden monimutkaisen liiketoimintasovelluksen syntyminen edellyttää, että verkonvalvojat suorittavat suuren määrän samanlaisia rutiinitoimintoja useilla eri verkkolaitteilla eri tasoilla. Sen lisäksi, että se on aikaavievää, se lisää myös riskiä tehdä virheitä, jotka voivat johtaa vakaviin IT-palvelujen seisokkiin ja sen seurauksena taloudellisiin menetyksiin.
Ongelman syy ei ole edes itse määräajat tai vaatimusten monimutkaisuus. Tosiasia on, että nämä vaatimukset on "käännettävä" yrityssovellusten kielestä verkkoinfrastruktuurin kielelle. Kuten tiedätte, mikä tahansa käännös on aina osittainen merkityksen menetys. Kun sovelluksen omistaja puhuu sovelluksensa logiikasta, verkonvalvoja ymmärtää joukon VLAN-verkkoja, Access-luetteloita kymmenistä laitteista, joita on tuettava, päivitettävä ja dokumentoitava.
Kertynyt kokemus ja jatkuva kommunikointi asiakkaiden kanssa antoivat Ciscolle mahdollisuuden suunnitella ja toteuttaa uusia nykyajan trendejä vastaavan datakeskuksen tiedonsiirtoverkon rakentamisen periaatteita, jotka perustuvat ennen kaikkea liiketoimintasovellusten logiikkaan. Siitä nimi - Application Centric Infrastructure.
ACI-arkkitehtuuri.
On oikein tarkastella ACI-arkkitehtuuria ei fyysiseltä, vaan loogiselta puolelta. Se perustuu automatisoitujen käytäntöjen malliin, jonka ylimmän tason objektit voidaan jakaa seuraaviin komponentteihin:
- Nexus-kytkimiin perustuva verkko.
- APIC-ohjain klusteri;
- Sovellusprofiilit;
Katsotaanpa jokaista tasoa yksityiskohtaisemmin - ja siirrymme yksinkertaisesta monimutkaiseen.
Nexus-kytkimiin perustuva verkko
ACI-tehtaan verkko on samanlainen kuin perinteinen hierarkkinen malli, mutta se on paljon yksinkertaisempi rakentaa. Verkoston organisoinnissa käytetään Leaf-Spine -mallia, josta on tullut yleisesti hyväksytty lähestymistapa seuraavan sukupolven verkkojen toteuttamiseen. Tämä malli koostuu kahdesta tasosta: Spine ja Leaf, vastaavasti.
Selkärangan taso vastaa vain suorituskyvystä. Spine-kytkimien kokonaissuorituskyky on yhtä suuri kuin koko kudoksen suorituskyky, joten tällä tasolla tulisi käyttää kytkimiä, joissa on 40G tai suurempi portti.
Spine kytkimet yhdistetään kaikkiin kytkimiin seuraavalla tasolla: Leaf kytkimet, joihin päätyisännät on kytketty. Leaf-kytkimien päärooli on porttikapasiteetti.
Siten skaalausongelmat ratkeavat helposti: jos haluamme lisätä kankaan läpimenoa, lisäämme Spine-kytkimet ja jos tarvitsemme lisää porttikapasiteettia, lisäämme Leafin.
Molemmilla tasoilla käytetään Cisco Nexus 9000 -sarjan kytkimiä, jotka ovat Ciscolle päätyökalu konesaliverkkojen rakentamiseen niiden arkkitehtuurista riippumatta. Spine-kerroksessa käytetään Nexus 9300- tai Nexus 9500 -kytkimiä ja Leaf-kytkimiä vain Nexus 9300.
ACI-tehtaalla käytettyjen Nexus-kytkimien mallivalikoima on esitetty alla olevassa kuvassa.
APIC (Application Policy Infrastructure Controller) -ohjainklusteri
APIC-ohjaimet ovat erikoistuneita fyysisiä palvelimia, kun taas pienissä toteutuksissa on mahdollista käyttää klusteria, jossa on yksi fyysinen APIC-ohjain ja kaksi virtuaalista.
APIC-ohjaimet tarjoavat ohjaus- ja valvontatoimintoja. Tärkeää on, että ohjaimet eivät koskaan osallistu tiedonsiirtoon, eli vaikka kaikki klusteriohjaimet pettäisivät, tämä ei vaikuta verkon vakauteen ollenkaan. On myös huomattava, että APIC:ien avulla järjestelmänvalvoja hallitsee ehdottomasti kaikkia tehtaan fyysisiä ja loogisia resursseja, eikä muutosten tekemiseksi enää tarvitse muodostaa yhteyttä tiettyyn laitteeseen, koska ACI käyttää yksi ohjauspiste.
Siirrytään nyt yhteen ACI:n pääkomponenteista - sovellusprofiileihin.
Sovellusverkkoprofiili on ACI:n looginen perusta. Sovellusprofiilit määrittelevät vuorovaikutuskäytännöt kaikkien verkkosegmenttien välillä ja kuvaavat itse verkkosegmenttejä. ANP mahdollistaa abstraktion fyysisestä kerroksesta ja itse asiassa kuvitella, kuinka sinun on järjestettävä vuorovaikutus eri verkkosegmenttien välillä sovelluksen näkökulmasta.
Sovellusprofiili koostuu yhteysryhmistä (päätepisteryhmät - EPG). Yhteysryhmä on looginen ryhmä isäntiä (virtuaalikoneita, fyysisiä palvelimia, säiliöitä jne.), jotka sijaitsevat samassa suojaussegmentissä (ei verkko, vaan suojaus). Tiettyyn EPG:hen kuuluvat pääteisännät voidaan määrittää useilla kriteereillä. Yleisesti käytetään seuraavia:
- Fyysinen portti
- Looginen portti (virtuaalikytkimen porttiryhmä)
- VLAN ID tai VXLAN
- IP-osoite tai IP-aliverkko
- Palvelimen attribuutit (nimi, sijainti, käyttöjärjestelmäversio jne.)
Eri EPG:iden vuorovaikutusta varten tarjotaan entiteetti, jota kutsutaan sopimuksiksi. Sopimuksessa määritellään eri EPG:iden välinen suhde. Toisin sanoen sopimuksessa määritellään, mitä palvelua yksi EPG tarjoaa toiselle EPG:lle. Luomme esimerkiksi sopimuksen, joka sallii liikenteen kulkemisen HTTPS-protokollan kautta. Seuraavaksi yhdistämme tähän sopimukseen esimerkiksi EPG Webin (verkkopalvelimien ryhmä) ja EPG Appin (sovelluspalvelimien ryhmä), minkä jälkeen nämä kaksi pääteryhmää voivat vaihtaa liikennettä HTTPS-protokollan kautta.
Alla olevassa kuvassa on esimerkki viestinnän muodostamisesta eri EPG:iden välillä saman ANP:n sisällä olevien sopimusten kautta.
ACI-tehtaalla voi olla mikä tahansa määrä sovellusprofiileja. Lisäksi sopimuksia ei ole sidottu tiettyyn sovellusprofiiliin, vaan niitä voidaan (ja pitäisi) käyttää EPG:iden yhdistämiseen eri ANP:issä.
Itse asiassa jokainen sovellus, joka vaatii verkkoa muodossa tai toisessa, on kuvattu omalla profiilillaan. Esimerkiksi yllä oleva kaavio näyttää kolmikerroksisen sovelluksen vakioarkkitehtuurin, joka koostuu N määrästä ulkoisia pääsypalvelimia (Web), sovelluspalvelimia (App) ja DBMS-palvelimia (DB), ja kuvaa myös vuorovaikutussäännöt niitä. Perinteisessä verkkoinfrastruktuurissa tämä olisi joukko sääntöjä, jotka on kirjoitettu infrastruktuurin eri laitteille. ACI-arkkitehtuurissa nämä säännöt kuvataan yhdessä sovellusprofiilissa. Sovellusprofiilia käyttävä ACI helpottaa useiden asetusten luomista eri laitteille ryhmittelemällä ne kaikki yhdeksi profiiliksi.
Alla olevassa kuvassa on realistisempi esimerkki. Microsoft Exchange -sovellusprofiili, joka on tehty useista EPG:istä ja sopimuksista.
Keskitetty hallinta, automaatio ja valvonta ovat yksi ACI:n tärkeimmistä eduista. ACI Factory vapauttaa järjestelmänvalvojat työlästä työstä, joka liittyy useiden sääntöjen luomiseen eri kytkimille, reitittimille ja palomuureille (vaikka perinteinen manuaalinen konfigurointimenetelmä on sallittu ja sitä voidaan käyttää). Sovellusprofiilien ja muiden ACI-objektien asetuksia sovelletaan automaattisesti koko ACI-kankaaseen. Vaikka vaihtaisit palvelimia fyysisesti muihin kudoskytkimien portteihin, ei tarvitse kopioida asetuksia vanhoista kytkimistä uusiin ja poistaa tarpeettomia sääntöjä. Isännän EPG-jäsenyysehtojen perusteella tehdas tekee nämä asetukset automaattisesti ja puhdistaa automaattisesti käyttämättömät säännöt.
Integroidut ACI-suojauskäytännöt toteutetaan sallittujen listojen muodossa, mikä tarkoittaa, että se, mikä ei ole nimenomaisesti sallittua, on oletuksena kiellettyä. Yhdessä verkkolaitteiden konfiguraatioiden automaattisen päivityksen kanssa ("unohdettujen" käyttämättömien sääntöjen ja käyttöoikeuksien poistaminen) tämä lähestymistapa lisää merkittävästi verkon yleistä suojaustasoa ja kaventaa mahdollisen hyökkäyksen pintaa.
ACI:n avulla voit järjestää verkkovuorovaikutuksen virtuaalikoneiden ja säiliöiden lisäksi myös fyysisten palvelimien, laitteistopalomuurien ja kolmannen osapuolen verkkolaitteiden välillä, mikä tekee ACI:sta tällä hetkellä ainutlaatuisen ratkaisun.
Ciscon uusi lähestymistapa sovelluslogiikkaan perustuvan tietoverkon rakentamiseen ei ole vain automaatiota, turvallisuutta ja keskitettyä hallintaa. Se on myös moderni horisontaalisesti skaalautuva verkko, joka täyttää kaikki nykyaikaisen liiketoiminnan vaatimukset.
ACI-pohjaisen verkkoinfrastruktuurin käyttöönotto mahdollistaa yrityksen kaikkien osastojen puhuvan samaa kieltä. Järjestelmänvalvojaa ohjaa vain sovelluksen logiikka, joka kuvaa tarvittavat säännöt ja yhteydet. Sovelluksen logiikan ohella sovelluksen omistajat ja kehittäjät, tietoturvapalvelu, ekonomistit ja yrittäjät ohjaavat sitä.
Näin Cisco on toteuttamassa konseptia seuraavan sukupolven datakeskusverkosta. Haluatko nähdä tämän itse? Tule mielenosoitukseen Sovelluskeskeinen infrastruktuuri Pietarissa ja työskennellä tulevaisuuden datakeskusverkon kanssa nyt.
Tapahtumaan voi ilmoittautua .
Lähde: will.com