Met deze magische stuk script van Cisco ACI kan je snel een netwerk instellen.
Het netwerkinfrastructuur voor datacenters Cisco ACI bestaat al vijf jaar, maar er is eigenlijk weinig over geschreven op Habr, dus besloot ik dit een beetje te verbeteren. Ik zal mijn eigen ervaringen delen over wat het is, welk voordeel het biedt en waar de uitdagingen liggen.
Wat is dit en waar komt het vandaan?
Op het moment van de aankondiging van ACI (Application Centric Infrastructure) in 2013 stonden traditionele benaderingen van datacenter netwerken onder druk van concurrenten aan drie zijden.
Aan de ene kant beloofden 'eerste generatie' SDN-oplossingen op basis van OpenFlow netwerken flexibeler en goedkoper te maken. Het idee was om beslissingen, die traditioneel door propriëtaire software van switches werden genomen, te verplaatsen naar een centrale controller.
Deze controller zou een uniek overzicht hebben van alles wat er gebeurde en zou op basis hiervan de hardware van alle switches programmeren op het niveau van regels voor specifieke datastromen.
Aan de andere kant gaven overlay netwerk oplossingen de mogelijkheid om de benodigde connectiviteit en beveiligingsbeleid te implementeren zonder wijzigingen in het fysieke netwerk, door software-tunnels te bouwen tussen gevirtualiseerde hosts. Het meest bekende voorbeeld van deze aanpak was de oplossing van Nicira, dat destijds al was overgenomen door VMWare voor 1,26 miljard dollar en de basis legde voor het huidige VMWare NSX. Een bijkomende interessantheid van de situatie was dat de mede-oprichters van Nicira dezelfde mensen waren die eerder de basis legden voor OpenFlow, en nu zeiden dat voor het opbouwen van een datacenterinfrastructuur .
En tot slot, de switchchips die beschikbaar zijn op de open markt (wat men merchant silicon noemt), hebben een volwassenheid bereikt waarbij ze een reële bedreiging zijn voor traditionele switch fabrikanten. Vroeger ontwikkelde elke vendor zelf chips voor zijn switches, maar in de loop van de tijd begonnen chips van externe leveranciers, vooral van Broadcom, dichterbij de vendor-chips te komen qua functionaliteit, en wat betreft prijs/prestatie overtroffen ze hen. Daarom geloofde men dat de dagen van switches met eigen ontwikkelde chips geteld waren.
ACI werd het 'asymmetrische antwoord' van Cisco (of beter gezegd, van het bedrijf Insieme dat in Cisco werd opgenomen, opgericht door voormalige medewerkers) op al het bovenstaande.
Wat is het verschil met OpenFlow?
Wat betreft de functie-distributie is ACI feitelijk het tegenovergestelde van OpenFlow.
In de OpenFlow-architectuur is de controller verantwoordelijk voor het definiëren van gedetailleerde regels (stroomroutes)
in de hardware van alle switches, wat betekent dat deze in een groot netwerk verantwoordelijk kan zijn voor het onderhouden en, belangrijker nog, het wijzigen van tientallen miljoenen records op honderden punten in het netwerk. Daarom kan de prestaties en betrouwbaarheid in grote implementaties een knelpunt zijn.
In ACI wordt een omgekeerde benadering gebruikt: er is ook een controller, maar switches ontvangen van hem hoog-niveau declaratieve beleidsregels, en de omzetting naar details van specifieke instellingen in de hardware wordt zelf door de switch uitgevoerd. De controller kan opnieuw opgestart of volledig uitgeschakeld worden, en met het netwerk gebeurt er niets slechts, afgezien van het ontbreken van de mogelijkheid om het op dat moment te beheren. Interessant is dat er in ACI situaties zijn waarin OpenFlow toch lokaal binnen de host wordt gebruikt voor het programmeren van Open vSwitch.
ACI is volledig gebaseerd op overlaytransport op basis van VXLAN, maar omvat ook de onderliggende IP-transport in het kader van een enkele oplossing. Cisco heeft dit aangeduid als ‘geïntegreerde overlay’. De switches van de fabric worden in de meeste gevallen gebruikt als beëindigingspunt voor overlays (doen dit op kanaalsnelheid). Hosts hoeven niets te weten over de fabric, encapsulatie, enz., maar in sommige gevallen (bijvoorbeeld voor het aansluiten van OpenStack-hosts) kan VXLAN-verkeer ook naar hen worden geleid.
Overlays worden in ACI niet alleen gebruikt om flexibele connectiviteit via het transportnetwerk te bieden, maar ook voor het overbrengen van metadata (deze wordt bijvoorbeeld gebruikt voor het toepassen van beveiligingsbeleid).
Broadcom-chips werden eerder door Cisco gebruikt in de Nexus 3000-serie switches. In de Nexus 9000-familie, die speciaal werd uitgebracht ter ondersteuning van ACI, werd aanvankelijk een hybride model geïmplementeerd dat Merchant+ werd genoemd. In de switch werden tegelijkertijd de nieuwe Broadcom Trident 2-chip en een aanvullende chip van Cisco gebruikt, die de magie van ACI mogelijk maakten. Dit lijkt het product sneller op de markt te brengen en de prijs van de switch te verlagen tot een niveau dat dicht bij de modellen op basis van alleen de Trident 2 lag. Deze benadering was voldoende voor de eerste twee tot drie jaar van de ACI-leveringen. In deze tijd ontwikkelde en lanceerde Cisco de volgende generatie van de Nexus 9000, die al op hun eigen chips met hogere prestaties en een uitgebreider functieset was gebaseerd, maar op hetzelfde prijsniveau bleef. De externe specificaties van de interactie in de fabriek zijn volledig behouden. Tegelijkertijd is de interne opbouw volledig veranderd: iets als refactoring, maar dan voor hardware.
Hoe is de architectuur van Cisco ACI opgebouwd?
In de eenvoudigste gevallen wordt ACI opgebouwd volgens de Clos-netwerktopologie, of zoals vaak ook wordt gezegd, Spine-Leaf. Er kunnen van twee (of één, als we ons geen zorgen maken over redundantie) tot zes Spine-niveau switches zijn. Hoe meer switches, hoe hoger de redundantie (minder vermindering van bandbreedte en betrouwbaarheid bij een storing of onderhoud van een Spine) en de algehele prestaties. Alle externe verbindingen lopen naar de Leaf-niveau switches: dit zijn servers, verbindingen met externe netwerken via L2 of L3, en de aansluiting van APIC-controllers. In feite gebeurt niet alleen de configuratie met ACI, maar ook het verzamelen van statistieken, het monitoren van storingen en meer — alles gebeurt via de interfaces van de controllers, waarvan er in standaardimplementaties drie zijn.
Je hoeft nooit een console aan switches aan te sluiten, zelfs niet voor het opstarten van het netwerk: de controller ontdekt zelf de switches en bouwt de fabric op, inclusief de configuraties van alle protocollen. Daarom is het ook heel belangrijk om bij de installatie de serienummers van de geïnstalleerde apparatuur te noteren, zodat je later niet hoeft te raden welke switch zich in welke rack bevindt. Voor troubleshooting kan je, indien nodig, via SSH verbinding maken met de switches: op hen zijn de gebruikelijke show-commando's van Cisco vrij nauwkeurig gereproduceerd.
Binnen de fabriek wordt IP-vervoer gebruikt, dus er zijn geen Spanning Tree en andere verschrikkingen uit het verleden: alle verbindingen zijn actief en de convergeertijd bij storingen is zeer snel. Het verkeer in de fabriek wordt via tunnels op basis van VXLAN verzonden. Meer specifiek noemt Cisco de encapsulatie iVXLAN, en het verschilt van gewone VXLAN doordat de gereserveerde velden in de netwerkkop worden gebruikt voor het verzenden van beheersinformatie, voornamelijk over de relatie van het verkeer tot de EPG-groep. Dit maakt het mogelijk om interactieregels tussen groepen in de hardware te implementeren, waarbij hun nummers net zo worden gebruikt als adressen in gewone access-lists.
Tunnels maken het mogelijk om L2-segmenten en L3 (oftewel VRF) uit te breiden via intern IP-vervoer. Daarbij is de standaard gateway gedistribueerd. Dit betekent dat elke switch verantwoordelijk is voor de routering van het binnenkomende verkeer in de fabriek. Wat betreft de logica van verkeersdoorvoer lijkt ACI op een fabriek op basis van VXLAN/EVPN.
Zo ja, wat zijn de verschillen? In alles!
Het eerste verschil waar je in ACI mee te maken krijgt, is hoe servers aan het netwerk worden toegevoegd. In traditionele netwerken worden zowel fysieke servers als virtuele machines in VLAN's aangesloten, en daar hangt alles vanaf: connectiviteit, beveiliging, enzovoort. In ACI daarentegen wordt een structuur gebruikt die Cisco EPG (End-point Group) noemt, waar je niet omheen kunt. Kun je het gelijkstellen aan een VLAN? Ja, maar in dat geval loop je het risico een groot deel van wat ACI biedt te verliezen.
Alle toegangregels worden geformuleerd met betrekking tot de EPG, en in ACI wordt standaard het 'whitelist'-principe gebruikt, wat betekent dat alleen verkeer dat expliciet is toegestaan, is toegestaan. Dit betekent dat we EPG-groepen 'Web' en 'MySQL' kunnen creëren en een regel kunnen definiëren die interactie tussen hen alleen via poort 3306 toestaat. Dit werkt zonder afhankelijkheid van netwerknummers en zelfs binnen hetzelfde subnet!
We hebben klanten die ACI juist om deze functie hebben gekozen omdat het de toegang tussen servers (virtueel of fysiek - het maakt niet uit) kan beperken zonder ze tussen subnets te verplaatsen, en dus de adressering niet aanraakt. Ja, we weten, niemand schrijft het handmatig in de configuraties van de applicaties, toch? IP-adressen een configuraties, toch?
De regels voor het doorlaten van verkeer in ACI worden contracten genoemd. In zo'n contract wordt een of meerdere groepen of niveaus binnen een multi-tier applicatie de serviceprovider (bijvoorbeeld een databaservice), terwijl andere de consument zijn. Een contract kan verkeer eenvoudig doorlaten of iets gecompliceerder doen, zoals het doorsturen naar een firewall of load balancer, en bovendien de waarde van QoS wijzigen.
Hoe komen servers in deze groepen? Als het fysieke servers zijn of iets dat is opgenomen in een bestaand netwerk waar wij een VLAN-trunk hebben gecreëerd, is het noodzakelijk om de switchpoort en het gebruikte VLAN aan te geven om ze in EPG te plaatsen. Zoals we zien, verschijnen VLAN's daar waar ze nodig zijn.
Als de servers echter virtuele machines zijn, volstaat het om te verwijzen naar de aangesloten virtualisatie-omgeving, en verder gebeurt alles vanzelf: er wordt een portgroep aangemaakt (om in termen van VMWare te spreken) voor het aansluiten van VM's, de benodigde VLAN's of VXLAN's worden toegewezen, en worden op de vereiste switchpoorten geregistreerd, enzovoorts. Dus hoewel ACI is opgebouwd rond een fysiek netwerk, lijken de aansluitingen voor virtuele servers veel eenvoudiger dan voor fysieke. ACI heeft al ingebouwde koppelingen met VMWare en MS Hyper-V, evenals ondersteuning voor OpenStack en RedHat Virtualization. Vanaf een bepaald moment is er ook ingebouwde ondersteuning voor containerplatforms: Kubernetes, OpenShift, Cloud Foundry, waarbij dit zowel betrekking heeft op het toepassen van beleid als op monitoring, wat betekent dat netwerkbeheerders onmiddellijk kunnen zien op welke hosts welke pods draaien en in welke groepen ze zijn geplaatst.
Naast het lidmaatschap van een bepaalde portgroep, hebben virtuele servers extra eigenschappen: naam, attributen, enzovoorts, die kunnen worden gebruikt als criteria voor hun verplaatsing naar een andere groep, bijvoorbeeld bij het hernoemen van een VM of het verschijnen van een extra tag. Cisco noemt dit microsegmentatiegroepen, hoewel de constructie zelf met de mogelijkheid om meerdere beveiligingssegmenten in de vorm van EPG binnen hetzelfde subnet te creëren ook echt microsegmentatie is. Maar dat weet de leverancier beter.
EPG's zijn louter logische constructies die niet aan specifieke switches, servers, enz. zijn gekoppeld, waardoor je met hen en hun afgeleiden constructies (applicaties en tenants) dingen kunt doen die moeilijk te realiseren zijn in reguliere netwerken, zoals klonen. Het resultaat is dat je bijvoorbeeld heel eenvoudig een kloon van een productieomgeving kunt maken om een testomgeving te verkrijgen die gegarandeerd identiek is aan de productie. Dit kan handmatig, maar het is beter (en eenvoudiger) via de API.
Over het algemeen is de beheerslogica in ACI totaal verschillend van wat je doorgaans tegenkomt
in traditionele netwerken van dezelfde Cisco: de programmeerinterface is primair, terwijl de GUI of CLI secundair is, aangezien ze via dezelfde API werken. Daarom begint bijna iedereen die met ACI werkt, na een tijdje de objectmodel te begrijpen die wordt gebruikt voor beheer en iets te automatiseren naar hun behoeften. Dit is het eenvoudigste te doen vanuit Python: er zijn handige kant-en-klare tools voor.
De beloofde valkuilen
Het grootste probleem is dat veel dingen in ACI anders zijn. Om er goed mee te kunnen werken, moet je opnieuw leren. Dit geldt vooral voor netwerkoperationele teams bij grote klanten, waar ingenieurs jarenlang bezig zijn geweest met het ‘inrichten van VLAN's’ op aanvraag. Het feit dat VLAN nu niet langer een VLAN is, en dat je voor het aanleggen van nieuwe netwerken in gevirtualiseerde hosts geen VLAN's meer handmatig hoeft aan te maken, 'verstoort' traditionele netwerkprofessionals en dwingt hen om vast te houden aan vertrouwde benaderingen. Het is vermeldenswaard dat Cisco heeft geprobeerd om het wat toegankelijker te maken door een 'NXOS-achtige' CLI aan de controller toe te voegen, die het mogelijk maakt om configuraties te maken vanuit een interface die lijkt op traditionele switches. Maar toch, om ACI goed te kunnen gebruiken, moet je begrijpen hoe het werkt.
Wat betreft de prijs verschillen grote en middelgrote ACI-netwerken van traditionele netwerken met Cisco-apparatuur feitelijk niet, aangezien voor hun opbouw dezelfde switches worden gebruikt (Nexus 9000 kan zowel in ACI- als in traditionele modus functioneren en is nu de belangrijkste 'werkpaard' voor nieuwe datacenterprojecten). Voor datacenters met twee switches maakt de aanwezigheid van controllers en een Spine-Leaf-architectuur echter wel degelijk een verschil. Onlangs werd de Mini ACI-fabriek geïntroduceerd, waarin twee van de drie controllers zijn vervangen door virtuele machines. Dit helpt de kostenverschillen te verkleinen, maar deze blijven desondanks bestaan. Voor de klant wordt de keuze dus bepaald door hoe geïnteresseerd hij is in beveiligingsfuncties, integratie met virtualisatie, een enkel punt van beheer, en dergelijke.
Bron: habr.com
