I løbet af de sidste par år har Cisco aktivt promoveret en ny arkitektur til opbygning af et datatransmissionsnetværk i datacentret - Application Centric Infrastructure (eller ACI). Nogle er allerede bekendt med det. Og nogle formåede endda at implementere det på deres virksomheder, herunder i Rusland. For de fleste it-professionelle og it-chefer er ACI dog stadig enten et obskurt akronym eller blot en refleksion over fremtiden.
I denne artikel vil vi forsøge at bringe denne fremtid tættere på. For at gøre dette vil vi tale om de vigtigste arkitektoniske komponenter i ACI og også illustrere, hvordan det kan bruges i praksis. Derudover vil vi i den nærmeste fremtid arrangere en visuel demonstration af ACI, som enhver interesseret IT-specialist kan tilmelde sig.
Du kan lære mere om den nye netværksarkitektur i St. Petersborg i maj 2019. Alle detaljer er inde . Tilmelde!
forhistorie
Den traditionelle og mest populære netværkskonstruktionsmodel er en hierarkisk model i tre niveauer: kerne -> distribution (aggregering) -> adgang. I mange år var denne model standarden; producenter producerede forskellige netværksenheder med den passende funktionalitet til det.
Tidligere, da informationsteknologi var en slags nødvendig (og ærligt talt, ikke altid ønsket) vedhæng til erhvervslivet, var denne model praktisk, meget statisk og pålidelig. Men nu hvor IT er en af driverne bag forretningsudvikling, og i mange tilfælde selve virksomheden, er denne models statiske karakter begyndt at give store problemer.
Moderne forretninger genererer en lang række forskellige komplekse krav til netværksinfrastruktur. Virksomhedens succes afhænger direkte af tidspunktet for implementeringen af disse krav. Forsinkelse i sådanne forhold er uacceptabelt, og den klassiske model for netværkskonstruktion tillader ofte ikke at opfylde alle forretningsbehov rettidigt.
For eksempel kræver fremkomsten af en ny kompleks forretningsapplikation, at netværksadministratorer udfører et stort antal lignende rutineoperationer på et stort antal forskellige netværksenheder på forskellige niveauer. Udover at det er tidskrævende, øger det også risikoen for at begå fejl, som kan føre til alvorlig nedetid på IT-ydelser og som følge heraf økonomiske tab.
Roden til problemet er ikke engang selve deadlines eller kravenes kompleksitet. Faktum er, at disse krav skal "oversættes" fra sproget i forretningsapplikationer til sproget i netværksinfrastrukturen. Som du ved, er enhver oversættelse altid et delvist tab af betydning. Når applikationsejeren taler om logikken i sin applikation, forstår netværksadministratoren et sæt VLAN'er, Access-lister på snesevis af enheder, der skal understøttes, opdateres og dokumenteres.
Den akkumulerede erfaring og konstante kommunikation med kunderne gjorde det muligt for Cisco at designe og implementere nye principper for opbygning af et datacenterdatatransmissionsnetværk, der opfylder moderne trends og først og fremmest er baseret på logikken i forretningsapplikationer. Deraf navnet - Application Centric Infrastructure.
ACI arkitektur.
Det er mest korrekt at betragte ACI-arkitekturen ikke fra den fysiske side, men fra den logiske side. Det er baseret på en model af automatiserede politikker, hvis objekter på øverste niveau kan opdeles i følgende komponenter:
- Netværk baseret på Nexus-switche.
- APIC controller klynge;
- Ansøgningsprofiler;
Lad os se på hvert niveau mere detaljeret – og vi vil gå fra simpelt til komplekst.
Netværk baseret på Nexus-switche
Netværket i en ACI-fabrik ligner den traditionelle hierarkiske model, men det er meget nemmere at bygge. Leaf-Spine modellen bruges til at organisere netværket, hvilket er blevet en almindeligt accepteret tilgang til implementering af næste generations netværk. Denne model består af to niveauer: henholdsvis Spine og Leaf.
Rygsøjlens niveau er kun ansvarlig for ydeevne. Den samlede ydeevne af Spine switches er lig med ydeevnen af hele stoffet, så switche med 40G eller højere porte bør bruges på dette niveau.
Spine switches forbindes til alle switches på næste niveau: Blad switches, som endeværter er forbundet til. Leaf-switches hovedrolle er portkapacitet.
Således løses skaleringsproblemer nemt: Hvis vi skal øge stofgennemstrømningen, tilføjer vi Spine-switche, og hvis vi skal øge portkapaciteten, tilføjer vi Leaf.
Til begge niveauer anvendes Cisco Nexus 9000-serien switches, som for Cisco er hovedværktøjet til opbygning af datacenternetværk, uanset deres arkitektur. Til Spine-laget bruges Nexus 9300 eller Nexus 9500-switche, og kun til Leaf Nexus 9300.
Modeludvalget af Nexus-switche, der bruges på ACI-fabrikken, er vist i figuren nedenfor.
APIC (Application Policy Infrastructure Controller) Controller Cluster
APIC-controllere er specialiserede fysiske servere, mens det til små implementeringer er muligt at bruge en klynge af en fysisk APIC-controller og to virtuelle.
APIC-controllere giver kontrol- og overvågningsfunktioner. Det vigtige er, at controllere aldrig deltager i dataoverførsel, det vil sige, selvom alle cluster-controllere fejler, vil dette slet ikke påvirke netværkets stabilitet. Det skal også bemærkes, at ved hjælp af APIC'er administrerer administratoren absolut alle fysiske og logiske ressourcer på fabrikken, og for at foretage ændringer er der ikke længere behov for at oprette forbindelse til en bestemt enhed, da ACI bruger en enkelt kontrolpunkt.
Lad os nu gå videre til en af hovedkomponenterne i ACI - applikationsprofiler.
Ansøgningsnetværksprofil er det logiske grundlag for ACI. Det er applikationsprofiler, der definerer interaktionspolitikker mellem alle netværkssegmenter og beskriver selve netværkssegmenterne. ANP giver dig mulighed for at abstrahere fra det fysiske lag og i virkeligheden forestille dig, hvordan du skal organisere interaktion mellem forskellige netværkssegmenter fra et applikationssynspunkt.
En applikationsprofil består af forbindelsesgrupper (End-point-grupper - EPG). En forbindelsesgruppe er en logisk gruppe af værter (virtuelle maskiner, fysiske servere, containere osv.), der er placeret i samme sikkerhedssegment (ikke netværk, men sikkerhed). Slutværterne, der tilhører en bestemt EPG, kan bestemmes af et stort antal kriterier. Følgende er almindeligt anvendt:
- Fysisk havn
- Logisk port (portgruppe på den virtuelle switch)
- VLAN ID eller VXLAN
- IP-adresse eller IP-undernet
- Serverattributter (navn, placering, OS-version osv.)
Til interaktion mellem forskellige EPG'er er der tilvejebragt en enhed kaldet kontrakter. Kontrakten definerer forholdet mellem de forskellige EPG'er. Med andre ord definerer kontrakten, hvilken service en EPG leverer til en anden EPG. For eksempel opretter vi en kontrakt, der tillader trafik at flyde over HTTPS-protokollen. Dernæst forbinder vi med denne kontrakt, for eksempel EPG Web (en gruppe af webservere) og EPG App (en gruppe af applikationsservere), hvorefter disse to terminalgrupper kan udveksle trafik via HTTPS-protokollen.
Nedenstående figur beskriver et eksempel på opsætning af kommunikation mellem forskellige EPG'er gennem kontrakter inden for samme ANP.
Der kan være et hvilket som helst antal applikationsprofiler inden for en ACI-fabrik. Derudover er kontrakter ikke bundet til en specifik applikationsprofil; de kan (og bør) bruges til at forbinde EPG'er i forskellige ANP'er.
Faktisk er hver applikation, der kræver et netværk i en eller anden form, beskrevet af sin egen profil. For eksempel viser diagrammet ovenfor standardarkitekturen for en tre-lags applikation, bestående af et N antal eksterne adgangsservere (Web), applikationsservere (App) og DBMS-servere (DB), og beskriver også reglerne for interaktion mellem dem. I en traditionel netværksinfrastruktur vil dette være et sæt regler skrevet på tværs af de forskellige enheder i infrastrukturen. I ACI-arkitekturen beskriver vi disse regler inden for en enkelt applikationsprofil. ACI, ved hjælp af en applikationsprofil, gør det meget nemmere at oprette et stort antal indstillinger på forskellige enheder ved at gruppere dem alle i en enkelt profil.
Billedet nedenfor viser et mere realistisk eksempel. En Microsoft Exchange-applikationsprofil lavet af flere EPG'er og kontrakter.
Central styring, automatisering og overvågning er en af de vigtigste fordele ved ACI. ACI Factory aflaster administratorer for det kedelige arbejde med at skabe en lang række regler på forskellige switche, routere og firewalls (mens den klassiske manuelle konfigurationsmetode er tilladt og kan bruges). Indstillinger for applikationsprofiler og andre ACI-objekter anvendes automatisk i hele ACI-strukturen. Selv når du fysisk skifter servere til andre porte i fabric-switcherne, er der ingen grund til at duplikere indstillinger fra gamle switches til nye og fjerne unødvendige regler. Baseret på værtens EPG-medlemskabskriterier, vil fabrikken foretage disse indstillinger automatisk og automatisk rydde op i ubrugte regler.
Integrerede ACI-sikkerhedspolitikker implementeres som hvidlister, hvilket betyder, at det, der ikke udtrykkeligt er tilladt, er forbudt som standard. Sammen med den automatiske opdatering af netværksudstyrskonfigurationer (fjernelse af "glemte" ubrugte regler og tilladelser), øger denne tilgang betydeligt det overordnede niveau af netværkssikkerhed og indsnævrer overfladen af et potentielt angreb.
ACI giver dig mulighed for at organisere netværksinteraktion ikke kun mellem virtuelle maskiner og containere, men også af fysiske servere, hardware firewalls og tredjeparts netværksudstyr, hvilket gør ACI til en unik løsning i øjeblikket.
Ciscos nye tilgang til opbygning af et datanetværk baseret på applikationslogik handler ikke kun om automatisering, sikkerhed og centraliseret styring. Det er også et moderne horisontalt skalerbart netværk, der opfylder alle kravene i moderne forretning.
Implementeringen af en netværksinfrastruktur baseret på ACI gør det muligt for alle afdelinger i virksomheden at tale det samme sprog. Administratoren styres kun af applikationens logik, som beskriver de nødvendige regler og forbindelser. Ud over applikationens logik er ejerne og udviklerne af applikationen, informationssikkerhedstjenesten, økonomer og virksomhedsejere styret af den.
Således implementerer Cisco konceptet om et næste generations datacenternetværk. Vil du selv se dette? Kom til demonstrationen Applikationscentreret infrastruktur i Sankt Petersborg og arbejde med fremtidens datacenternetværk nu.
Du kan tilmelde dig arrangementet .
Kilde: www.habr.com