Met behulp van dit magische stukje Cisco ACI-script kunt u snel een netwerk opzetten.
De netwerkfabriek voor het Cisco ACI-datacenter bestaat al vijf jaar, maar Habré vertelde er eigenlijk niets over, dus besloot ik er een beetje aan te sleutelen. Ik zal je uit eigen ervaring vertellen wat het is, wat het nut ervan is en waar het een hark heeft.
Wat is het en waar komt het vandaan?
Tegen de tijd dat ACI (Application Centric Infrastructure) in 2013 werd aangekondigd, waren concurrenten van drie kanten tegelijk bezig met traditionele benaderingen van datacenternetwerken.
Enerzijds beloofden de "eerste generatie" SDN-oplossingen op basis van OpenFlow netwerken tegelijkertijd flexibeler en goedkoper te maken. Het idee was om de besluitvorming die traditioneel via eigen switchsoftware wordt gedaan, naar een centrale controller te verplaatsen.
Deze controller zou één visie hebben op alles wat er gebeurt en op basis daarvan de hardware van alle schakelaars programmeren op het niveau van regels voor het verwerken van specifieke stromen.
Aan de andere kant maakten overlay-netwerkoplossingen het mogelijk om het noodzakelijke connectiviteits- en beveiligingsbeleid te implementeren zonder enige verandering in het fysieke netwerk, door softwaretunnels tussen gevirtualiseerde hosts te bouwen. Het bekendste voorbeeld van deze aanpak was Nicira, dat toen al voor 1,26 miljard dollar door VMWare was overgenomen en waaruit het huidige VMWare NSX voortkwam. Enige pikantheid van de situatie werd toegevoegd door het feit dat de mede-oprichters van Nicira dezelfde mensen waren die voorheen aan de oorsprong van OpenFlow stonden en nu zeggen dat om een datacenterfabriek te bouwen .
En ten slotte hebben de op de open markt verkrijgbare schakelchips (het zogenaamde handelssilicium) een stadium van volwassenheid bereikt waarin ze een reële bedreiging zijn geworden voor traditionele fabrikanten van schakelaars. Als elke leverancier eerder onafhankelijk chips voor zijn switches ontwikkelde, begonnen chips van externe fabrikanten, voornamelijk van Broadcom, in de loop van de tijd de afstand met leverancierschips te verkleinen in termen van functies, en overtroffen ze deze in termen van prijs / prestatieverhouding. Daarom geloofden velen dat de dagen van schakelaars op chips van hun eigen ontwerp geteld waren.
ACI is Cisco's "asymmetrische antwoord" geworden (meer precies, het bedrijf Insieme, opgericht door voormalige werknemers) op al het bovenstaande.
Wat is het verschil met OpenFlow?
Qua functieverdeling is ACI eigenlijk het tegenovergestelde van OpenFlow.
In de OpenFlow-architectuur is de controller verantwoordelijk voor het schrijven van gedetailleerde regels (stromen)
in de hardware van alle schakelaars, dat wil zeggen in een groot netwerk, kan deze verantwoordelijk zijn voor het onderhouden en vooral veranderen van tientallen miljoenen records op honderden punten in het netwerk, zodat de prestaties en betrouwbaarheid ervan een knelpunt worden in een grote implementatie.
ACI gebruikt de omgekeerde benadering: natuurlijk is er ook een controller, maar de switches ontvangen daarvan declaratief beleid op hoog niveau, en de switch zelf voert de weergave ervan uit in details van specifieke instellingen in de hardware. De controller kan opnieuw worden opgestart of helemaal worden uitgeschakeld, en er zal niets ergs met het netwerk gebeuren, behalve natuurlijk het gebrek aan controle op dit moment. Interessant is dat er situaties zijn in ACI waarin OpenFlow nog steeds wordt gebruikt, maar lokaal binnen de host voor Open vSwitch-programmering.
ACI is volledig gebouwd op VXLAN-gebaseerd overlay-transport, maar omvat het onderliggende IP-transport als onderdeel van één oplossing. Cisco noemde dit de term "geïntegreerde overlay". Als eindpunt voor overlays in ACI worden in de meeste gevallen fabrieksschakelaars gebruikt (ze doen dit op verbindingssnelheid). Hosts hoeven niets te weten over de fabriek, inkapseling, etc., maar in sommige gevallen (bijvoorbeeld om OpenStack-hosts te verbinden) kan VXLAN-verkeer naar hen toe worden gebracht.
Overlays worden in ACI niet alleen gebruikt om flexibele connectiviteit via het transportnetwerk te bieden, maar ook om meta-informatie over te dragen (het wordt bijvoorbeeld gebruikt om beveiligingsbeleid toe te passen).
Chips van Broadcom werden eerder door Cisco gebruikt in de Nexus 3000-serie switches. In de Nexus 9000-familie, speciaal uitgebracht om ACI te ondersteunen, werd oorspronkelijk een hybride model geïmplementeerd, dat Merchant + heette. De switch maakte tegelijkertijd gebruik van de nieuwe Broadcom Trident 2-chip en een aanvullende chip, ontwikkeld door Cisco, die alle magie van ACI implementeert. Blijkbaar maakte dit het mogelijk om de release van het product te versnellen en het prijskaartje van de overstap te verlagen tot een niveau dat dicht bij modellen ligt die eenvoudigweg op Trident 2 zijn gebaseerd. Deze aanpak was voldoende voor de eerste twee of drie jaar van ACI-leveringen. Gedurende deze tijd heeft Cisco de volgende generatie Nexus 9000 ontwikkeld en gelanceerd op zijn eigen chips met meer prestaties en functies, maar op hetzelfde prijsniveau. Externe specificaties qua interactie in de fabriek blijven volledig behouden. Tegelijkertijd is de interne vulling volledig veranderd: zoiets als refactoring, maar dan voor ijzer.
Hoe de Cisco ACI-architectuur werkt
In het eenvoudigste geval is ACI gebouwd op de topologie van het Klose-netwerk, of, zoals ze vaak zeggen, Spine-Leaf. Schakelaars op wervelkolomniveau kunnen van twee (of één, als we niet om fouttolerantie geven) tot zes zijn. Dienovereenkomstig geldt: hoe meer ervan, hoe hoger de fouttolerantie (hoe lager de vermindering van de bandbreedte en de betrouwbaarheid in geval van een ongeluk of onderhoud van één Spine) en de algehele prestaties. Alle externe verbindingen gaan naar switches op leaf-niveau: dit zijn servers en docking met externe netwerken via L2 of L3, en verbindende APIC-controllers. Over het algemeen gebeurt bij ACI niet alleen de configuratie, maar ook het verzamelen van statistieken, het monitoren van fouten, enzovoort - alles gebeurt via de interface van controllers, waarvan er drie zijn in standaardimplementaties.
Je hoeft nooit verbinding te maken met de switches via de console, zelfs niet om het netwerk te starten: de controller zelf detecteert de switches en stelt er een fabriek uit samen, inclusief de instellingen van alle serviceprotocollen, daarom is het trouwens erg belangrijk om Noteer tijdens de installatie de serienummers van de apparatuur die wordt geïnstalleerd, zodat u later niet hoeft te raden welke schakelaar in welk rack zit. Voor het oplossen van problemen kunt u indien nodig via SSH verbinding maken met de switches: ze reproduceren de gebruikelijke Cisco-show-opdrachten vrij zorgvuldig.
Intern maakt de fabriek gebruik van IP-transport, dus er zit geen Spanning Tree en andere verschrikkingen uit het verleden in: alle schakels zijn erbij betrokken en de convergentie in geval van storingen gaat erg snel. Het verkeer in de fabric wordt verzonden via tunnels op basis van VXLAN. Meer precies noemt Cisco zelf iVXLAN-inkapseling, en het verschilt van regulier VXLAN doordat de gereserveerde velden in de netwerkheader worden gebruikt om service-informatie te verzenden, voornamelijk over de relatie van verkeer met de EPG-groep. Hiermee kunt u de interactieregels tussen groepen in de apparatuur implementeren, waarbij u hun nummers op dezelfde manier gebruikt als adressen in gewone toegangslijsten.
Met tunnels kunnen zowel L2-segmenten als L3-segmenten (dat wil zeggen VRF) worden uitgerekt via het interne IP-transport. In dit geval wordt de standaardgateway gedistribueerd. Dit betekent dat elke switch verantwoordelijk is voor het routeren van het verkeer dat de fabric binnenkomt. In termen van verkeersstroomlogica is ACI vergelijkbaar met een VXLAN/EVPN-fabric.
Zo ja, wat zijn de verschillen? Al de rest!
Het grootste verschil dat u tegenkomt bij ACI is de manier waarop servers met het netwerk zijn verbonden. In traditionele netwerken gaat de opname van zowel fysieke servers als virtuele machines naar VLAN’s, en danst al het andere daaruit: connectiviteit, beveiliging, enz. In ACI wordt een ontwerp gebruikt dat Cisco EPG (End-point Group) noemt, van waaruit er is geen ontkomen aan. Is het mogelijk om het gelijk te stellen aan VLAN? Ja, maar in dit geval is er een kans om het grootste deel van wat ACI geeft te verliezen.
Met betrekking tot EPG zijn alle toegangsregels geformuleerd, en in ACI wordt standaard het principe van de "witte lijst" gebruikt, dat wil zeggen dat alleen verkeer is toegestaan, waarvan de doorgang expliciet is toegestaan. Dat wil zeggen, we kunnen de EPG-groepen "Web" en "MySQL" creëren en een regel definiëren die communicatie tussen hen alleen op poort 3306 toestaat. Dit werkt zonder gebonden te zijn aan netwerkadressen en zelfs binnen hetzelfde subnet!
We hebben klanten die juist vanwege deze functie voor ACI hebben gekozen, omdat je hiermee de toegang tussen servers (virtueel of fysiek - het maakt niet uit) kunt beperken zonder ze tussen subnetten te slepen, dat wil zeggen zonder de adressering aan te raken. Ja, ja, we weten dat niemand IP-adressen in applicatieconfiguraties met de hand voorschrijft, toch?
Verkeersregels in ACI worden contracten genoemd. In zo'n contract worden een of meer groepen of niveaus in een meerlaagse applicatie een dienstverlener (bijvoorbeeld een databasedienst), andere een consument. Het contract kan eenvoudig verkeer doorgeven, of het kan iets lastigers doen, bijvoorbeeld het doorsturen naar een firewall of balancer, en ook de QoS-waarde wijzigen.
Hoe komen servers in deze groepen terecht? Als dit fysieke servers zijn of iets dat is opgenomen in een bestaand netwerk waarin we een VLAN-trunk hebben gemaakt, moet u, om ze in de EPG te plaatsen, verwijzen naar de switchpoort en het VLAN dat daarop wordt gebruikt. Zoals je ziet verschijnen er VLAN’s waar je niet zonder kunt.
Als de servers virtuele machines zijn, volstaat het om naar de aangesloten virtualisatieomgeving te verwijzen, en dan gebeurt alles vanzelf: er wordt een poortgroep aangemaakt (in termen van VMWare) om de VM te verbinden, de benodigde VLAN's of VXLAN's zullen worden toegewezen, worden ze geregistreerd op de noodzakelijke switchpoorten, enz. Dus hoewel ACI rond een fysiek netwerk is opgebouwd, zien verbindingen voor virtuele servers er veel eenvoudiger uit dan voor fysieke. ACI beschikt al over ingebouwde connectiviteit met VMWare en MS Hyper-V, evenals ondersteuning voor OpenStack en RedHat Virtualisatie. Vanaf een gegeven moment is er ook ingebouwde ondersteuning voor containerplatforms verschenen: Kubernetes, OpenShift, Cloud Foundry, terwijl het zowel om de toepassing van beleid als om monitoring gaat, dat wil zeggen dat de netwerkbeheerder onmiddellijk kan zien op welke hosts welke pods werken en in welke groepen zij vallen.
Naast dat ze zijn opgenomen in een bepaalde poortgroep, hebben virtuele servers extra eigenschappen: naam, attributen, enz., die kunnen worden gebruikt als criteria om ze naar een andere groep over te dragen, bijvoorbeeld wanneer een VM wordt hernoemd of een extra tag verschijnt in Het. Cisco noemt dit microsegmentatiegroepen, hoewel het ontwerp zelf, met de mogelijkheid om veel beveiligingssegmenten in de vorm van EPG's op hetzelfde subnet te creëren, over het algemeen ook een behoorlijke microsegmentatie is. Nou ja, de verkoper weet wel beter.
EPG's zelf zijn puur logische constructies, niet gebonden aan specifieke switches, servers, enz., dus je kunt er dingen mee doen en daarop gebaseerde constructies (applicaties en tenants) die moeilijk te doen zijn in gewone netwerken, zoals klonen. Laten we zeggen dat het daardoor heel eenvoudig is om een productieomgeving te klonen om een testomgeving te krijgen die gegarandeerd identiek is aan de productieomgeving. Je kunt het handmatig doen, maar het is beter (en eenvoudiger) via de API.
Over het algemeen is de besturingslogica in ACI helemaal niet vergelijkbaar met wat u gewoonlijk tegenkomt
in traditionele netwerken van hetzelfde Cisco: de software-interface is primair en de GUI of CLI secundair, omdat ze via dezelfde API werken. Daarom begint bijna iedereen die betrokken is bij ACI na een tijdje het objectmodel dat voor beheer wordt gebruikt te navigeren en iets te automatiseren dat aan hun behoeften voldoet. De eenvoudigste manier om dit te doen is vanuit Python: daar zijn handige kant-en-klare tools voor.
Beloofde hark
Het grootste probleem is dat veel dingen in ACI anders worden gedaan. Om er normaal mee te kunnen werken, moet je je omscholen. Dit geldt vooral voor netwerkbeheerteams bij grote klanten, waar technici op verzoek al jaren VLAN's voorschrijven. Het feit dat VLAN's nu geen VLAN's meer zijn, en je VLAN's niet meer met de hand hoeft te creëren om nieuwe netwerken in gevirtualiseerde hosts te leggen, blaast het dak van traditionele netwerkers volledig weg en zorgt ervoor dat ze vasthouden aan vertrouwde benaderingen. Opgemerkt moet worden dat Cisco probeerde de pil een beetje zoeter te maken en een “NXOS-achtige” CLI aan de controller toevoegde, waarmee je de configuratie kunt uitvoeren vanaf een interface die lijkt op traditionele schakelaars. Maar toch, om ACI normaal te kunnen gebruiken, moet je begrijpen hoe het werkt.
In termen van prijs verschillen ACI-netwerken op grote en middelgrote schaal niet echt van traditionele netwerken op Cisco-apparatuur, aangezien dezelfde switches worden gebruikt om ze te bouwen (Nexus 9000 kan in ACI en in traditionele modus werken en zijn nu de belangrijkste netwerken geworden). "werkpaard" voor nieuwe datacenterprojecten). Maar voor datacenters met twee switches is de aanwezigheid van controllers en Spine-Leaf-architectuur uiteraard voelbaar. Onlangs is er een Mini ACI-fabriek verschenen, waarin twee van de drie controllers zijn vervangen door virtuele machines. Hierdoor wordt het verschil in kosten kleiner, maar het blijft wel bestaan. Voor de klant wordt de keuze dus bepaald door de mate waarin hij geïnteresseerd is in beveiligingsfuncties, integratie met virtualisatie, één enkel controlepunt, enzovoort.
Bron: www.habr.com