I løpet av de siste årene har Cisco aktivt promotert en ny arkitektur for å bygge et dataoverføringsnettverk i datasenteret - Application Centric Infrastructure (eller ACI). Noen er allerede kjent med det. Og noen klarte til og med å implementere det på sine bedrifter, inkludert i Russland. Men for de fleste IT-fagfolk og IT-ledere er ACI fortsatt enten et uklart akronym eller bare en refleksjon over fremtiden.
I denne artikkelen vil vi prøve å bringe denne fremtiden nærmere. For å gjøre dette vil vi snakke om de viktigste arkitektoniske komponentene til ACI, og også illustrere hvordan det kan brukes i praksis. I tillegg vil vi i nær fremtid organisere en visuell demonstrasjon av ACI, som enhver interessert IT-spesialist kan melde seg på.
Du kan lære mer om den nye nettverksarkitekturen i St. Petersburg i mai 2019. Alle detaljer er inne . Melde deg på!
forhistorie
Den tradisjonelle og mest populære nettverkskonstruksjonsmodellen er en tre-nivå hierarkisk modell: kjerne -> distribusjon (aggregering) -> tilgang. I mange år var denne modellen standarden; produsenter produserte forskjellige nettverksenheter med passende funksjonalitet for det.
Tidligere, da informasjonsteknologi var en slags nødvendig (og ærlig talt, ikke alltid ønsket) tillegg til virksomheten, var denne modellen praktisk, veldig statisk og pålitelig. Men nå som IT er en av driverne for forretningsutvikling, og i mange tilfeller selve virksomheten, har den statiske karakteren til denne modellen begynt å skape store problemer.
Moderne virksomhet genererer et stort antall forskjellige komplekse krav til nettverksinfrastruktur. Suksessen til virksomheten avhenger direkte av tidspunktet for implementeringen av disse kravene. Forsinkelse i slike forhold er uakseptabelt, og den klassiske modellen for nettverksbygging tillater ofte ikke å møte alle forretningsbehov i tide.
For eksempel krever fremveksten av en ny kompleks forretningsapplikasjon at nettverksadministratorer utfører et stort antall lignende rutineoperasjoner på et stort antall forskjellige nettverksenheter på forskjellige nivåer. I tillegg til å være tidkrevende, øker det også risikoen for å gjøre feil, noe som kan føre til alvorlig nedetid på IT-tjenester og som følge av dette økonomisk tap.
Roten til problemet er ikke engang selve fristene eller kompleksiteten i kravene. Faktum er at disse kravene må "oversettes" fra språket i forretningsapplikasjoner til språket for nettverksinfrastruktur. Som du vet, er enhver oversettelse alltid et delvis tap av mening. Når applikasjonseieren snakker om logikken til applikasjonen sin, forstår nettverksadministratoren et sett med VLAN, Access-lister på dusinvis av enheter som må støttes, oppdateres og dokumenteres.
Den akkumulerte erfaringen og konstante kommunikasjonen med kundene tillot Cisco å designe og implementere nye prinsipper for å bygge et datasenternettverk for dataoverføring som møter moderne trender og først og fremst er basert på logikken til forretningsapplikasjoner. Derav navnet - Application Centric Infrastructure.
ACI-arkitektur.
Det er mest korrekt å vurdere ACI-arkitekturen ikke fra den fysiske siden, men fra den logiske siden. Den er basert på en modell av automatiserte retningslinjer, hvis objekter på toppnivå kan deles inn i følgende komponenter:
- Nettverk basert på Nexus-svitsjer.
- APIC-kontroller klynge;
- Søknadsprofiler;
La oss se på hvert nivå mer detaljert – og vi vil gå fra enkelt til komplekst.
Nettverk basert på Nexus-svitsjer
Nettverket i en ACI-fabrikk ligner på den tradisjonelle hierarkiske modellen, men det er mye enklere å bygge. Leaf-Spine-modellen brukes til å organisere nettverket, som har blitt en allment akseptert tilnærming for implementering av neste generasjons nettverk. Denne modellen består av to nivåer: henholdsvis Spine og Leaf.
Ryggnivået er kun ansvarlig for ytelsen. Den totale ytelsen til Spine-brytere er lik ytelsen til hele stoffet, så brytere med 40G eller høyere porter bør brukes på dette nivået.
Spine-brytere kobles til alle brytere på neste nivå: Bladbrytere, som endeverter er koblet til. Hovedrollen til Leaf-svitsjer er portkapasitet.
Dermed løses skaleringsproblemer enkelt: hvis vi trenger å øke stoffgjennomstrømningen, legger vi til Spine-svitsjer, og hvis vi trenger å øke portkapasiteten, legger vi til Leaf.
For begge nivåer brukes Cisco Nexus 9000-seriens switcher, som for Cisco er hovedverktøyet for å bygge datasenternettverk, uavhengig av arkitektur. For Spine-laget brukes Nexus 9300- eller Nexus 9500-brytere, og kun for Leaf Nexus 9300.
Modellutvalget av Nexus-svitsjer som brukes i ACI-fabrikken er vist i figuren nedenfor.
APIC (Application Policy Infrastructure Controller) Controller Cluster
APIC-kontrollere er spesialiserte fysiske servere, mens det for små implementeringer er mulig å bruke en klynge med én fysisk APIC-kontroller og to virtuelle.
APIC-kontrollere gir kontroll- og overvåkingsfunksjoner. Det viktige er at kontrollerne aldri deltar i dataoverføring, det vil si at selv om alle klyngekontrollerne svikter, vil dette ikke påvirke stabiliteten til nettverket i det hele tatt. Det skal også bemerkes at ved hjelp av APIC-er administrerer administratoren absolutt alle fysiske og logiske ressurser på fabrikken, og for å gjøre endringer er det ikke lenger behov for å koble til en bestemt enhet, siden ACI bruker en enkelt kontrollpunkt.
La oss nå gå videre til en av hovedkomponentene i ACI - applikasjonsprofiler.
Søknadsnettverksprofil er det logiske grunnlaget for ACI. Det er applikasjonsprofiler som definerer interaksjonspolicyer mellom alle nettverkssegmenter og beskriver selve nettverkssegmentene. ANP lar deg abstrahere fra det fysiske laget og faktisk forestille deg hvordan du trenger å organisere interaksjon mellom ulike nettverkssegmenter fra et applikasjonssynspunkt.
En applikasjonsprofil består av koblingsgrupper (End-point groups - EPG). En tilkoblingsgruppe er en logisk gruppe verter (virtuelle maskiner, fysiske servere, containere osv.) som er plassert i samme sikkerhetssegment (ikke nettverk, men sikkerhet). Sluttvertene som tilhører en bestemt EPG kan bestemmes av et stort antall kriterier. Følgende er ofte brukt:
- Fysisk havn
- Logisk port (portgruppe på den virtuelle svitsjen)
- VLAN ID eller VXLAN
- IP-adresse eller IP-undernett
- Serverattributter (navn, plassering, OS-versjon osv.)
For samspillet mellom ulike EPG-er er det gitt en enhet kalt kontrakter. Kontrakten definerer forholdet mellom de ulike EPG-ene. Kontrakten definerer med andre ord hvilken tjeneste en EPG yter til en annen EPG. For eksempel oppretter vi en kontrakt som lar trafikk flyte over HTTPS-protokollen. Deretter kobler vi til denne kontrakten, for eksempel EPG Web (en gruppe webservere) og EPG App (en gruppe applikasjonsservere), hvoretter disse to terminalgruppene kan utveksle trafikk via HTTPS-protokollen.
Figuren nedenfor beskriver et eksempel på å sette opp kommunikasjon mellom ulike EPGer gjennom kontrakter innenfor samme ANP.
Det kan være et hvilket som helst antall applikasjonsprofiler innenfor en ACI-fabrikk. I tillegg er ikke kontrakter knyttet til en spesifikk applikasjonsprofil; de kan (og bør) brukes til å koble sammen EPG-er i forskjellige ANP-er.
Faktisk er hver applikasjon som krever et nettverk i en eller annen form beskrevet av sin egen profil. For eksempel viser diagrammet ovenfor standardarkitekturen til en trelags applikasjon, bestående av et N antall eksterne tilgangsservere (Web), applikasjonsservere (App) og DBMS-servere (DB), og beskriver også reglene for samhandling mellom dem. I en tradisjonell nettverksinfrastruktur vil dette være et sett med regler skrevet på tvers av de ulike enhetene i infrastrukturen. I ACI-arkitekturen beskriver vi disse reglene innenfor en enkelt applikasjonsprofil. ACI, ved å bruke en applikasjonsprofil, gjør det mye enklere å opprette et stort antall innstillinger på forskjellige enheter ved å gruppere dem alle i en enkelt profil.
Bildet nedenfor viser et mer realistisk eksempel. En Microsoft Exchange-applikasjonsprofil laget av flere EPG-er og kontrakter.
Sentral styring, automatisering og overvåking er en av hovedfordelene med ACI. ACI Factory avlaster administratorer for det kjedelige arbeidet med å lage et stort antall regler på ulike brytere, rutere og brannmurer (mens den klassiske manuelle konfigurasjonsmetoden er tillatt og kan brukes). Innstillinger for applikasjonsprofiler og andre ACI-objekter brukes automatisk i hele ACI-stoffet. Selv når du fysisk bytter servere til andre porter i struktursvitsjene, er det ikke nødvendig å duplisere innstillinger fra gamle brytere til nye og fjerne unødvendige regler. Basert på vertens EPG-medlemskapskriterier, vil fabrikken gjøre disse innstillingene automatisk og automatisk rydde opp i ubrukte regler.
Integrerte ACI-sikkerhetspolicyer implementeres som hvitelister, noe som betyr at det som ikke er eksplisitt tillatt er forbudt som standard. Sammen med automatisk oppdatering av nettverksutstyrskonfigurasjoner (fjerning av "glemte" ubrukte regler og tillatelser), øker denne tilnærmingen betydelig det generelle nivået av nettverkssikkerhet og begrenser overflaten til et potensielt angrep.
ACI lar deg organisere nettverksinteraksjon ikke bare mellom virtuelle maskiner og containere, men også av fysiske servere, maskinvarebrannmurer og tredjeparts nettverksutstyr, noe som gjør ACI til en unik løsning for øyeblikket.
Ciscos nye tilnærming til å bygge et datanettverk basert på applikasjonslogikk handler ikke bare om automatisering, sikkerhet og sentralisert administrasjon. Det er også et moderne horisontalt skalerbart nettverk som oppfyller alle kravene til moderne virksomhet.
Implementeringen av en nettverksinfrastruktur basert på ACI lar alle avdelinger i bedriften snakke samme språk. Administratoren styres kun av applikasjonens logikk, som beskriver de nødvendige reglene og tilkoblingene. I tillegg til logikken i applikasjonen, styres eierne og utviklerne av applikasjonen, informasjonssikkerhetstjenesten, økonomer og bedriftseiere av den.
Dermed implementerer Cisco konseptet med et neste generasjons datasenternettverk. Vil du se dette selv? Kom til demonstrasjonen Applikasjonssentrisk infrastruktur i St. Petersburg og jobbe med fremtidens datasenternettverk nå.
Du kan melde deg på arrangementet .
Kilde: www.habr.com