Under de senaste åren har Cisco aktivt främjat en ny arkitektur för att bygga ett dataöverföringsnätverk i datacentret - Application Centric Infrastructure (eller ACI). Vissa är redan bekanta med det. Och några lyckades till och med implementera det på sina företag, inklusive i Ryssland. Men för de flesta IT-proffs och IT-chefer är ACI fortfarande antingen en obskyr akronym eller bara en reflektion över framtiden.
I den här artikeln kommer vi att försöka föra denna framtid närmare. För att göra detta kommer vi att prata om de viktigaste arkitektoniska komponenterna i ACI, och också illustrera hur det kan användas i praktiken. Dessutom kommer vi inom en snar framtid att organisera en visuell demonstration av ACI, som alla intresserade IT-specialister kan anmäla sig till.
Du kan lära dig mer om den nya nätverksarkitekturen i St. Petersburg i maj 2019. Alla detaljer finns i . Bli Medlem!
förhistoria
Den traditionella och mest populära nätverkskonstruktionsmodellen är en hierarkisk modell med tre nivåer: kärna -> distribution (aggregering) -> åtkomst. Under många år var denna modell standarden; tillverkare producerade olika nätverksenheter med lämplig funktionalitet för den.
Tidigare, när informationsteknik var ett slags nödvändig (och ärligt talat, inte alltid önskvärd) bihang till verksamheten, var denna modell bekväm, mycket statisk och pålitlig. Men nu när IT är en av drivkrafterna för affärsutveckling, och i många fall själva verksamheten, har den statiska karaktären hos denna modell börjat orsaka stora problem.
Modernt företagande genererar ett stort antal olika komplexa krav på nätverksinfrastruktur. Framgången för verksamheten beror direkt på tidpunkten för implementeringen av dessa krav. Förseningar i sådana förhållanden är oacceptabelt, och den klassiska modellen för nätverkskonstruktion tillåter ofta inte att tillgodose alla affärsbehov i tid.
Till exempel kräver uppkomsten av en ny komplex affärsapplikation nätverksadministratörer att utföra ett stort antal liknande rutinoperationer på ett stort antal olika nätverksenheter på olika nivåer. Förutom att det är tidskrävande ökar det också risken för att göra fel, vilket kan leda till allvarliga driftstopp av IT-tjänster och som en följd av det ekonomiska förluster.
Roten till problemet är inte ens själva deadlines eller kravens komplexitet. Faktum är att dessa krav måste "översättas" från språket för affärsapplikationer till språket för nätverksinfrastruktur. Som ni vet är varje översättning alltid en partiell förlust av betydelse. När applikationsägaren talar om logiken i sin applikation förstår nätverksadministratören en uppsättning VLAN, Access-listor på dussintals enheter som behöver stödjas, uppdateras och dokumenteras.
Den samlade erfarenheten och ständiga kommunikationen med kunderna gjorde det möjligt för Cisco att designa och implementera nya principer för att bygga ett datacenternätverk för dataöverföring som möter moderna trender och som först och främst är baserat på logiken i affärsapplikationer. Därav namnet - Application Centric Infrastructure.
ACI-arkitektur.
Det är mest korrekt att betrakta ACI-arkitekturen inte från den fysiska sidan, utan från den logiska sidan. Den är baserad på en modell av automatiserade policyer, vars objekt på toppnivå kan delas in i följande komponenter:
- Nätverk baserat på Nexus-switchar.
- APIC-styrenhetskluster;
- Applikationsprofiler;
Låt oss titta på varje nivå mer i detalj - och vi kommer att gå från enkel till komplex.
Nätverk baserat på Nexus-switchar
Nätverket i en ACI-fabrik liknar den traditionella hierarkiska modellen, men det är mycket enklare att bygga. Leaf-Spine-modellen används för att organisera nätverket, vilket har blivit ett allmänt accepterat tillvägagångssätt för att implementera nästa generations nätverk. Denna modell består av två nivåer: Spine respektive Leaf.
Ryggnivån är endast ansvarig för prestanda. Den totala prestandan för Spine-switchar är lika med prestandan för hela tyget, så switchar med 40G-portar eller högre bör användas på denna nivå.
Spine switchar ansluter till alla switchar på nästa nivå: Leaf switchar, till vilka ändvärdar är anslutna. Huvudrollen för Leaf-switchar är portkapacitet.
Således är skalningsproblem lätt att lösa: om vi behöver öka tyggenomströmningen lägger vi till Spine-switchar och om vi behöver öka portkapaciteten lägger vi till Leaf.
För båda nivåerna används switchar i Cisco Nexus 9000-serien, som för Cisco är huvudverktyget för att bygga datacenternätverk, oavsett arkitektur. För Spine-lagret används Nexus 9300 eller Nexus 9500-switchar och endast för Leaf Nexus 9300.
Modellutbudet av Nexus-switchar som används i ACI-fabriken visas i bilden nedan.
APIC (Application Policy Infrastructure Controller) Controller Cluster
APIC-kontroller är specialiserade fysiska servrar, medan det för små implementeringar är möjligt att använda ett kluster av en fysisk APIC-kontroller och två virtuella.
APIC-styrenheter tillhandahåller kontroll- och övervakningsfunktioner. Det viktiga är att kontroller aldrig deltar i dataöverföring, det vill säga även om alla klusterkontroller misslyckas, kommer detta inte att påverka nätverkets stabilitet alls. Det bör också noteras att administratören med hjälp av APIC:er hanterar absolut alla fysiska och logiska resurser i fabriken, och för att göra några ändringar finns det inte längre ett behov av att ansluta till en viss enhet, eftersom ACI använder en enda kontrollpunkt.
Låt oss nu gå vidare till en av huvudkomponenterna i ACI - applikationsprofiler.
Application Network Profile är den logiska grunden för ACI. Det är applikationsprofiler som definierar interaktionspolicyer mellan alla nätverkssegment och beskriver själva nätverkssegmenten. ANP låter dig abstrahera från det fysiska lagret och faktiskt föreställa dig hur du behöver organisera interaktion mellan olika nätverkssegment ur tillämpningssynpunkt.
En applikationsprofil består av anslutningsgrupper (End-point groups - EPG). En anslutningsgrupp är en logisk grupp av värdar (virtuella maskiner, fysiska servrar, behållare, etc.) som finns i samma säkerhetssegment (inte nätverk, utan säkerhet). Slutvärdarna som tillhör en viss EPG kan bestämmas av ett stort antal kriterier. Följande används vanligtvis:
- Fysisk hamn
- Logisk port (portgrupp på den virtuella switchen)
- VLAN ID eller VXLAN
- IP-adress eller IP-subnät
- Serverattribut (namn, plats, OS-version, etc.)
För samverkan mellan olika EPG:er tillhandahålls en enhet som kallas kontrakt. Kontraktet definierar förhållandet mellan de olika EPG:erna. Med andra ord, avtalet definierar vilken tjänst en EPG tillhandahåller till en annan EPG. Till exempel skapar vi ett kontrakt som tillåter trafik att flyta över HTTPS-protokollet. Därefter ansluter vi till detta kontrakt, till exempel EPG Web (en grupp webbservrar) och EPG App (en grupp av applikationsservrar), varefter dessa två terminalgrupper kan utbyta trafik via HTTPS-protokollet.
Figuren nedan beskriver ett exempel på att sätta upp kommunikation mellan olika EPG:er genom kontrakt inom samma ANP.
Det kan finnas hur många applikationsprofiler som helst inom en ACI-fabrik. Dessutom är kontrakt inte knutna till en specifik applikationsprofil, de kan (och bör) användas för att koppla ihop EPG:er i olika ANP:er.
Faktum är att varje applikation som kräver ett nätverk i en eller annan form beskrivs av sin egen profil. Till exempel visar diagrammet ovan standardarkitekturen för en applikation i tre nivåer, bestående av ett N antal externa åtkomstservrar (webb), applikationsservrar (App) och DBMS-servrar (DB), och beskriver även reglerna för interaktion mellan dem. I en traditionell nätverksinfrastruktur skulle detta vara en uppsättning regler skrivna över de olika enheterna i infrastrukturen. I ACI-arkitekturen beskriver vi dessa regler inom en enda applikationsprofil. ACI, med hjälp av en applikationsprofil, gör det mycket lättare att skapa ett stort antal inställningar på olika enheter genom att gruppera dem alla i en enda profil.
Bilden nedan visar ett mer realistiskt exempel. En Microsoft Exchange-applikationsprofil gjord av flera EPG:er och kontrakt.
Central hantering, automation och övervakning är en av de viktigaste fördelarna med ACI. ACI Factory avlastar administratörer från det tråkiga arbetet med att skapa ett stort antal regler på olika switchar, routrar och brandväggar (medan den klassiska manuella konfigurationsmetoden är tillåten och kan användas). Inställningar för applikationsprofiler och andra ACI-objekt tillämpas automatiskt i hela ACI-strukturen. Även när du fysiskt byter servrar till andra portar i strukturswitcharna, finns det inget behov av att duplicera inställningar från gamla switchar till nya och rensa bort onödiga regler. Baserat på värdens EPG-medlemskapskriterier kommer fabriken att göra dessa inställningar automatiskt och automatiskt rensa bort oanvända regler.
Integrerade ACI-säkerhetspolicyer implementeras som vitlistor, vilket innebär att det som inte är uttryckligen tillåtet är förbjudet som standard. Tillsammans med den automatiska uppdateringen av nätverksutrustningskonfigurationer (borttagning av "glömda" oanvända regler och behörigheter), ökar detta tillvägagångssätt avsevärt den övergripande nivån av nätverkssäkerhet och minskar ytan på en potentiell attack.
ACI låter dig organisera nätverksinteraktion inte bara av virtuella maskiner och behållare, utan också av fysiska servrar, hårdvarubrandväggar och nätverksutrustning från tredje part, vilket gör ACI till en unik lösning för tillfället.
Ciscos nya tillvägagångssätt för att bygga ett datanätverk baserat på applikationslogik handlar inte bara om automatisering, säkerhet och centraliserad hantering. Det är också ett modernt horisontellt skalbart nätverk som uppfyller alla krav i modern verksamhet.
Implementeringen av en nätverksinfrastruktur baserad på ACI tillåter alla avdelningar i företaget att tala samma språk. Administratören styrs endast av applikationens logik, som beskriver de nödvändiga reglerna och anslutningarna. Förutom applikationens logik vägleds ägare och utvecklare av applikationen, informationssäkerhetstjänsten, ekonomer och företagare av den.
Således omsätter Cisco konceptet med nästa generations datacenternätverk i praktiken. Vill du se detta själv? Kom till demonstrationen Applikationscentrerad infrastruktur i St Petersburg och arbeta med framtidens datacenternätverk nu.
Du kan anmäla dig till evenemanget .
Källa: will.com