Inför molnresan så är det mycket man bör tänka på. Cisco ACI Anywhere kan göra det enklare för dig som vill påbörja resan mot molnet, speciellt om du skall ha flera molnleverantörer i ett hybridmoln.
Anledningen till detta är att Cisco ACI Anywhere gör att du INTE behöver lära dig de olika molnleverantörernas namn och sätt att bygga nät etc, med Cisco ACI Anywhere är det samma sätt att bygga nät mm i valfritt moln som stöds som du gör i ditt OnPrem datacenter med Cisco ACI idag. Perfekt för hybridmoln.
Application Centric Infrastructure (ACI) är Ciscos IBN för Datacentret. ACI är IBN lösningen som kommer från köpet av Insieme. Insieme är ett företag som Cisco grundade för att skapa ett SDN för datacentret, och ACI är resultatet av arbetet som gjordes i detta företag.
Numera kallas Cisco ACI för IBN för datacentret då Cisco har valt att släppa SDN (Software Designed Network) till förmån för IBN (Intent Based network).
Cisco ACI är en tätt kopplad policystyrd lösning som integrerar programvara och hårdvara. hårdvaran för Cisco ACI är baserad på Cisco Nexus 9000-serien med switchar. Programvara och integrationspunkter för ACI inkluderar några få komponenter.
I stor utsträckning är nätverket för Cisco ACI inte annorlunda än vad som har distribuerats under de senaste åren i företagets datacentra. Det som emellertid skiljer sig är förvaltnings- och policyramen tillsammans med de protokoll som används i den underliggande strukturen.
Struktur
I en ACI-väv med Leaf-Spine tillhandahåller Cisco en ursprunglig Layer 3 IP-fabric (tänk tyg/väv) som stöder ECMP-routing mellan två slutpunkter i nätverket, men använder ett overlay-protokoll, som virtuellt utökbart lokalt nätverk (VXLAN) under omslaget för att tillåta all arbetsbelastning överallt i nätverket. Att stödja overlay-protokoll är det som ger fabricen möjlighet att ha maskiner, antingen fysiska eller virtuella, i samma logiska nätverk (lager 2-domän), även när du kör Layer 3-routing ner till toppen av varje rack. Cisco ACI stöder VLAN, VXLAN och nätverksvirtualisering med hjälp av generisk routinginkapsling (NV-GRE), som kan kombineras och överbryggas för att skapa ett logiskt nätverk / domän vid behov.
Ur ett managementperspektiv är det den centrala IBN Controllern för ACI-lösningen, APIC (Application Policy Infrastructure Controller) som hanterar och konfigurerar policyn på var och en av switcharna i ACI-strukturen. Hårdvara blir statslös med Cisco ACI, ungefär som det är med Ciscos UCS Computing Platform. Det betyder att ingen konfiguration är kopplad till enheten. APIC fungerar som ett centralt arkiv för alla policys och har förmågan att snabbt distribuera och återinstallera hårdvara vid behov genom att använda denna statslösa datormodell.
Tredjepartstjänster; lastbalansering, säkerhet
Cisco ACI fungerar också som en plattform för andra tjänster som krävs inom datacenter eller molnmiljö. Genom att använda APIC kan tredjepartstjänster integreras för avancerad säkerhet, lastbalansering och övervakning. Leverantörer och produkter, som SourceFire, Embrane, F5, Cisco ASA och Citrix, kan integreras nativt i ACI-strukturen och vara en del av den policy som definieras av administratören.
Från början fanns ACI endast i det egna datacentret, oavsett om det var co-location eller en egen hall. ACI var från första början endast till för en, men har senare utvecklats till att vara för flera datahallar (remote-leaf, multi-pod och multi-site).
Remote-Leaf är ett sätt att ansluta en liten hall med ett eller två löv endast inga spines. dessa löv ansluter till IPN eller ISN noderna och kommer att vara en del av en Pod i en Multi-Pod eller en site i Multi-Site.
Cisco ACI Multi-Pod
Multi-Pod är en vidareutveckling av Streched Fabric, detta innebär att man har samma overlay i flera datahallar. Multi-Pod är mycket lämpligt att använda sig av då man vi ha active-active datahallar. Upp till 12 hallar kan kopplas samman i en Multi-Pod lösning. Med Multi-Pod får man felisolering på underlay-nivån, i överliggande (overlay) så är man inte separerad i Podarna, dvs får man ett fel i sitt VXLan-baserade overlay så finns detta felet i alla Podarna. Med Multi-Pod så har man ett och samma Controller cluster för alla Podarna, i ACI kallas dessa controllers för APIC.
Cisco ACI Multi-Site
Multi-Site är ett sätt att bygga ACI så att man har separata ACI domäner per datahall, dvs man får en active-standby lösning eller där en av Siterna är DR-site. Man kan även få en active-active lösning med Multi-Site, med vissa begränsningar i antalet nät som kan vara aktiva i alla siterna. Med multi-site så har man total felisolering mellan siterna, både på underlay och overlay, dvs ett fel i en site kan INTE spridas vidare till en annan site. I multi-site har man separata controller clusters per site, och man har en controller av controllers för att bygga multi-site funktionaliteten, denna controller av controllers heter Multi-Site Orchestrator (MSO).
ACI idag har utvecklats till något mycket mer än bara en lösning i den egna hallen eller egna flera hallar, idag kan vi köra Cisco ACI Anywhere i molnet (för närvarande AWS och Azure, Google Cloud finns på road-map för ACI) och som en virtuell pod i vmware ESXi.
I denna artikel kommer jag att koncentrera mig på ACI i molnet.
Cisco ACI Anywhere i molnet
ACI kan idag installeras och köras i AWS och Azure, Google Cloud kommer inom en snar framtid.
I äldre ACI mjukvara (version 4.0 och 4.1) så var man tvungen att ha en egen ACI fabrik i sitt Datacenter, i och med version 4.2 så behövs inte detta längre utan man kan börja med ACI i molnet.
Om man vill ha last i både sitt egna ACI datacenter och hos en eller flera molnleverantörer i ett hybridmoln så behöver man MSO, där varje del blir sin egen site, dvs det egna datacentret blir en site och varje molnleverantör blir en egen site. För att förklara detta lite närmare så behöver vi titta på vad de olika molnleverantörerna benämner objekten som skapas jämfört med ACI Anywhere.
I både AWS och Azure så spinner man upp en Cloud APIC i en VPC/VNET i en Region, denna VPC/VNET kallas för infra VPC/VNET. Infra VPC/VNETen används för att transportera trafik mellan andra VPC/VNETs inom en region i AWS/Azure, skall man köra med flera regioner krävs det en Infra VPC/VNET per region men bara en Cloud APIC (upp till fyra regioner kan man köra på detta viset.)
Olika användningsfall för Cisco ACI Anywhere är hybridmoln, cloud-first/flera regioner och multi-cloud:
Use case #1: Hybridmoln/Hybrid-Cloud
Detta användningsfall innebär att man har en ACI fabrik i sitt datacenter redan idag, det kan vara en single-site, single-pod, en multi-site eller en multi-pod har man en multi-site så har man redan MSOn och därför är det lättare att addera en eller flera molneverantörer till denna i ett hybridmoln. Fördelarna med detta är att man INTE behöver lära sig hur man konfigurerar nät, säkerhetpolicys mm mm hos de olika molnleverantörerna utan man fortsätter att bygga hybridmoln på samma sätt som man gjort i sin ACI fabrik.
Use case #2: Cloud First med flera regioner
I detta Use case behöver man inte någon egen ACI fabrik eller en MSO, då kan hanterar de olika molnleverantörerna via de egna Cloud APIC man satt upp. Samma fördel som med användningsfall ett gäller, men det blir svårare att ha en vm i samma vxlan i båda molneverantörerna än i Use case 1 & 3.
Use case #3: Multi-Cloud (Cloud Only ACI)
I detta usecase behöver man inte någon egen ACI fabrik. Samma fördel som med usecase 1 gäller, plus att det blir enklare att ha vmar i de olika molnleverantörerna som sitter i samma vxlan (MSO bygger detta åt dig)
Cisco Intersight styr servrarna
Cisco Intersight är Ciscos Cloud baserade servermanagement mjukvara, denna mjukvara har utvecklats väldigt mycket den senaste tiden. Bland annat så har man lagt till support för att kunna knyta in Cisco ACI in i Intersight, detta för att underlätta vid TAC Case. Som det är idag när man skapar ett TAC case så behöver man i regel alltid bifoga tech support filer för att TAC ingenjören skall ha något att börja felsöka på. Dessa tech support filer är stora filer i Cisco ACI, runt 1.5-2GByte per APIC och ~1.5GB per switch man samlar in dessa filer för.
Som det var tidigare, innan ACI version 4.2, så behövde man samla in tech support filerna, ladda ner dem till sin dator och sedan ladda upp dem till Cisco TAC portal. Men med version 4.2 av Cisco ACI kan man knyta APICarna till Cisco Intersight, detta gör då att tech support filerna laddas upp direkt från din ACI fabrik (APIC) till Intersight och du slipper ladda ner för att sedan ladda upp filerna till TAC portalen. TAC ingenjören kan även initiera en uppladdning av tech supportfilerna till Intersight utan att behöva bland in mig, då det finns ett aktivt TAC case. Detta är en del av Connected TAC som funnits ca ett år för Cisco UCS och Cisco Hyperflex.
Vill du läsa mer så kan du läsa ”Intersight datacenter – serverkonfiguration utan perspiration”, ladda ned ”Spara pengar med Hyperflex”, se vårt inspelade webinar om automation med ACI – så kommer du igång. Eller varför inte:
