Mit diesem fantastischen Skript für Cisco ACI lässt sich das Netzwerk schnell einrichten.
Die Netzwerktechnologie für das Rechenzentrum Cisco ACI gibt es bereits seit fünf Jahren, doch auf Hub gibt es kaum Informationen darüber. Daher habe ich mich entschieden, dies ein wenig zu verbessern. Ich werde aus eigener Erfahrung berichten, was es ist, welchen Nutzen es bringt und wo die Stolpersteine liegen.
Was ist das und woher kommt es?
Zum Zeitpunkt der Ankündigung von ACI (Application Centric Infrastructure) im Jahr 2013 sahen sich traditionelle Ansätze für Rechenzentrumsnetzwerke gleich von drei Seiten Konkurrenz gegenüber.
Einerseits versprachen die 'ersten Generation'-SDN-Lösungen auf Basis von OpenFlow, Netzwerke gleichzeitig flexibler und kostengünstiger zu machen. Die Idee war, die Entscheidungsfindung, die traditionell von proprietärer Switch-Software durchgeführt wurde, auf einen zentralen Controller zu verlagern.
Dieser Controller hätte eine zentrale Sicht auf alles, was geschieht, und würde darauf basierend die Hardware aller Switches auf der Ebene der Regelverarbeitung bestimmter Datenströme programmieren.
Andererseits ermöglichten Overlay-Netzwerklösungen, die erforderliche Konnektivität und Sicherheitsrichtlinien ohne Änderungen im physischen Netzwerk zu implementieren, indem sie Softwaretunnel zwischen virtualisierten Hosts aufbauten. Das bekannteste Beispiel für diesen Ansatz ist die Lösung von Nicira, die zu diesem Zeitpunkt bereits von VMWare für 1,26 Milliarden Dollar übernommen wurde und die Grundlage für das heutige VMWare NSX bildete. Eine interessante Wendung in dieser Situation war, dass die Mitbegründer von Nicira dieselben Personen waren, die zuvor an den Anfängen von OpenFlow beteiligt waren und jetzt sagten, dass man für den Aufbau einer Rechenzentrumsfabric auf diese Technologie zurückgreifen müsse. .
Und schließlich haben die auf dem freien Markt erhältlichen Switch-Chips (bekannt als Merchant Silicon) einen Reifegrad erreicht, der sie zu einer ernsthaften Bedrohung für traditionelle Switch-Hersteller gemacht hat. Während früher jeder Anbieter seine eigenen Chips für seine Switches entwickelte, haben im Laufe der Zeit Chips von Drittanbietern, vor allem von Broadcom, die Lücke zu den Hersteller-Chips hinsichtlich der Funktionen verringert und in Bezug auf das Preis-Leistungs-Verhältnis sogar übertroffen. Daher glaubten viele, dass die Tage von Switches mit selbst entwickelten Chips gezählt sind.
ACI wurde als "asymmetrische Antwort" von Cisco (genauer gesagt, von dem zugehörigen Unternehmen Insieme, das von ehemaligen Mitarbeitern gegründet wurde) auf all das verstanden.
Was ist der Unterschied zu OpenFlow?
Aus Sicht der Funktionsverteilung ist ACI praktisch das Gegenteil von OpenFlow.
In der OpenFlow-Architektur ist der Controller dafür verantwortlich, detaillierte Regeln (Flows) zu definieren.
In der Hardware aller Switches kann die Verantwortung für die Verwaltung und, was am wichtigsten ist, die Änderung von zig Millionen Einträgen an Hunderten von Punkten im Netzwerk liegen. Daher wird ihre Leistung und Zuverlässigkeit in großflächigen Implementierungen zum Engpass.
In ACI wird ein umgekehrter Ansatz verfolgt: Ein Controller ist natürlich vorhanden, aber die Switches erhalten von ihm hochrangige deklarative Richtlinien, und die Umsetzung in die Details der spezifischen Einstellungen erfolgt direkt im Switch. Der Controller kann neu gestartet oder sogar vollständig abgeschaltet werden, ohne dass es negative Auswirkungen auf das Netzwerk hat, abgesehen von der temporären Unmöglichkeit der Verwaltung. Interessanterweise gibt es in ACI Situationen, in denen OpenFlow dennoch lokal innerhalb des Hosts zur Programmierung von Open vSwitch verwendet wird.
ACI basiert vollständig auf Overlay-Transport mit VXLAN, umfasst jedoch innerhalb einer Lösung auch den zugrunde liegenden IP-Transport. Cisco bezeichnet dies als "integriertes Overlay". Als Endpunkt für Overlays in ACI werden in den meisten Fällen Fabrik-Switches verwendet (diese arbeiten mit Kanalgeschwindigkeit). Hosts müssen nichts über die Fabrik, Kapselung usw. wissen, jedoch kann in bestimmten Fällen (zum Beispiel zur Anbindung von OpenStack-Hosts) VXLAN-Verkehr bis zu ihnen geleitet werden.
Overlays werden in ACI nicht nur verwendet, um flexible Konnektivität über das Transportnetz bereitzustellen, sondern auch zur Übertragung von Metainformationen (diese werden beispielsweise zur Anwendung von Sicherheitsrichtlinien genutzt).
Broadcom-Chips wurden bereits zuvor von Cisco in den Nexus 3000 Switches verwendet. In der Nexus 9000-Serie, die speziell zur Unterstützung von ACI entwickelt wurde, wurde anfangs ein hybrides Modell implementiert, das als Merchant+ bezeichnet wurde. Im Switch kamen gleichzeitig der neue Broadcom Trident 2 Chip und ein ergänzender Chip von Cisco zum Einsatz, der die gesamte ACI-Intelligenz umsetzte. Offenbar ermöglichte dies eine schnellere Markteinführung des Produkts und senkte den Preis des Switches auf ein Niveau, das näher an den Modellen mit nur Trident 2 lag. Dieser Ansatz hielt in den ersten zwei bis drei Jahren der ACI-Bereitstellung stand. In dieser Zeit entwickelte Cisco die nächste Generation der Nexus 9000, die bereits auf eigenen Chips mit höherer Leistung und Funktionen basierte, jedoch auf demselben Preisniveau blieb. Die externen Spezifikationen in Bezug auf die Interaktion im Fabriknetzwerk blieben dabei vollständig erhalten. Gleichzeitig wurde die interne Hardware vollständig überarbeitet: eine Art Refactoring, jedoch für die Hardware.
Wie ist die Architektur von Cisco ACI aufgebaut?
Im einfachsten Fall wird ACI nach der Clos-Netzwerktopologie aufgebaut, häufig auch als Spine-Leaf bezeichnet. Es können zwischen zwei (oder einem, wenn die Ausfallsicherheit nicht von Bedeutung ist) und sechs Spine-Switches vorhanden sein. Je mehr es sind, desto höher ist die Ausfallsicherheit (weniger Bandbreiten- und Zuverlässigkeitsverluste bei einem Ausfall oder während der Wartung eines Spine) und die Gesamtleistung. Alle externen Verbindungen laufen über die Leaf-Switches: dazu gehören Server, die Verbindung zu externen Netzwerken über L2 oder L3 sowie die Anbindung von APIC-Controllern. Generell kann gesagt werden, dass die gesamte Konfiguration, die Erfassung von Statistiken, das Monitoring von Ausfällen und mehr durch die Schnittstelle der Controller erfolgt, wobei bei Implementierungen in Standardgröße in der Regel drei Stück vorhanden sind.
Für die Switches ist keine Verbindung über die Konsole erforderlich, selbst zum Starten des Netzwerks: Der Controller erkennt die Switches selbständig und fügt sie zu einer Fabrik zusammen, einschließlich aller Einstellungen der Dienstprotokolle. Daher ist es beim Aufbau sehr wichtig, die Seriennummern der installierten Geräte zu notieren, um später herauszufinden, welcher Switch sich in welchem Rack befindet. Für das Troubleshooting kann bei Bedarf eine SSH-Verbindung zu den Switches hergestellt werden: Sie unterstützen die gängigen Cisco-Show-Befehle ausreichend.
Innerhalb der Fabrik wird IP-Transport verwendet, sodass es keine Spanning Tree-Probleme oder andere Übel der Vergangenheit gibt: alle Links sind aktiv, und die Konvergenz bei Ausfällen ist sehr schnell. Der Verkehr in der Fabrik wird über Tunnel auf Basis von VXLAN übertragen. Genauer gesagt bezeichnet Cisco die Kapselung als iVXLAN, was sich von herkömmlichem VXLAN unterscheidet, da reservierte Felder im Netzwerkheader zur Übertragung von Steuerinformationen verwendet werden, insbesondere bezüglich der Beziehung des Verkehrs zur EPG-Gruppe. Dies ermöglicht es, Interaktionsregeln zwischen Gruppen in der Hardware zu implementieren, wobei ihre Nummern so verwendet werden, wie man Adressen in gewöhnlichen Access-Listen verwendet.
Tunnel ermöglichen die Ausdehnung sowohl über den internen IP-Transport als auch über L2- und L3-Segmente (das heißt, VRF). Der Standardgateway ist dabei verteilt. Das bedeutet, dass jeder Switch für die Routing von eintreffendem Verkehr in die Fabrik verantwortlich ist. In Bezug auf die Logik des Datenverkehrsmanagements ähnelt ACI einer Fabrik basierend auf VXLAN/EVPN.
Wenn ja, wo liegen die Unterschiede? In allem anderen!
Der erste Unterschied, dem Sie in ACI begegnen, ist, wie die Server ins Netzwerk eingebunden werden. In traditionellen Netzwerken erfolgt die Einbindung sowohl physischer Server als auch virtueller Maschinen in VLANs, und alles Weitere hängt davon ab: Konnektivität, Sicherheit usw. Bei ACI hingegen wird eine Struktur verwendet, die Cisco als EPG (End-Point-Gruppe) bezeichnet, von der man nicht wegkommt. Kann man sie VLANs gleichsetzen? Ja, aber in diesem Fall besteht die Gefahr, einen Großteil der Vorteile zu verlieren, die ACI bietet.
Bezüglich EPG werden alle Zugriffsregeln formuliert, und in ACI wird standardmäßig das Prinzip der 'Whitelisting'-Strategie verwendet, das heißt, nur der Verkehr ist erlaubt, der ausdrücklich genehmigt wurde. Das bedeutet, wir können EPG-Gruppen wie 'Web' und 'MySQL' erstellen und eine Regel definieren, die die Interaktion zwischen ihnen nur über Port 3306 erlaubt. Das funktioniert ohne Bindung an IP-Adressen und sogar innerhalb desselben Subnetzes!
Wir haben Kunden, die sich gerade wegen dieses Features für ACI entschieden haben, da es ermöglicht, Zugriffe zwischen Servern (ob virtuell oder physisch – ganz egal) zu beschränken, ohne sie zwischen Subnetzen hin- und her zu verschieben, und somit die Adressierung nicht berührt werden muss. Ja, wir wissen, niemand trägt dies manuell ein. IP-Adressen In Anwendungs-Konfigurationen, oder?
Die Verkehrsregeln in ACI werden als Verträge bezeichnet. In einem solchen Vertrag wird eine oder mehrere Gruppen oder Ebenen in einer mehrstufigen Anwendung zum Dienstanbieter (zum Beispiel für eine Datenbank), während andere die Verbraucher sind. Der Vertrag kann den Verkehr einfach weiterleiten oder etwas Komplexeres tun, wie etwa den Verkehr zu einer Firewall oder einem Lastverteiler umleiten und auch den QoS-Wert ändern.
Wie gelangen Server in diese Gruppen? Wenn es sich um physische Server oder andere Komponenten handelt, die in ein bestehendes Netzwerk integriert sind, in dem wir einen VLAN-Trunk erstellt haben, müssen wir den Switch-Port und den darauf verwendeten VLAN angeben, um sie in die EPG aufzunehmen. Wie wir sehen, sind VLANs dort erforderlich, wo sie unverzichtbar sind.
Wenn es sich bei den Servern um virtuelle Maschinen handelt, genügt es, auf die angebundene Virtualisierungsumgebung zu verweisen, und der Rest geschieht von selbst: Es wird eine Portgruppe (um in VMWare-Terminologie zu sprechen) zur Anbindung der VM erstellt, die erforderlichen VLANs oder VXLANs werden zugewiesen, und sie werden auf den entsprechenden Switch-Ports konfiguriert. Obwohl ACI also auf einem physikalischen Netzwerk basiert, wirken die Verbindungen für virtuelle Server deutlich einfacher als für physische. ACI verfügt bereits über integrierte Verbindungen zu VMWare und MS Hyper-V sowie Unterstützung für OpenStack und RedHat Virtualization. Zudem gibt es seit einiger Zeit eingebaute Unterstützung für Containerplattformen wie Kubernetes, OpenShift und Cloud Foundry, die sowohl die Anwendung von Richtlinien als auch das Monitoring umfasst. Der Netzwerkadministrator kann somit sofort sehen, auf welchen Hosts welche Pods aktiv sind und in welche Gruppen sie eingeordnet wurden.
Neben der Zugehörigkeit zu bestimmten Port-Gruppen verfügen virtuelle Server über zusätzliche Eigenschaften wie Namen und Attribute, die als Kriterien für ihre Migration in eine andere Gruppe verwendet werden können, etwa beim Umbenennen von VMs oder beim Hinzufügen eines weiteren Tags. Cisco bezeichnet dies als mikroskalierte Gruppen, obwohl die Möglichkeit, mehrere Sicherheits-Segmente in Form von EPGs innerhalb desselben Subnetzes zu erstellen, im Grunde auch als Mikroskalierung betrachtet werden kann. Nun, das weiß der Anbieter besser.
Die EPGs sind rein logische Konstrukte, die nicht an bestimmte Switches, Server usw. gebunden sind. Daher können mit ihnen und den darauf basierenden Strukturen (Anwendungen und Tenants) Dinge realisiert werden, die in herkömmlichen Netzwerken schwer durchzuführen sind, zum Beispiel Klonen. So ist es beispielsweise sehr einfach, einen Klon einer Produktionsumgebung zu erstellen, um eine Testumgebung zu erhalten, die garantiert identisch mit der produktiven Umgebung ist. Das kann man manuell machen, aber es ist besser (und einfacher) über die API.
Die Logik der Verwaltung in ACI unterscheidet sich grundsätzlich von dem, was man normalerweise gewohnt ist.
In traditionellen Netzwerken von Cisco ist die Programmierschnittstelle primär, während die GUI oder CLI sekundär ist, da sie über dieselbe API arbeiten. Deshalb gewöhnt sich fast jeder, der mit ACI arbeitet, irgendwann an das Objektmodell, das zur Verwaltung verwendet wird, und beginnt, etwas zu automatisieren, das seinen Bedürfnissen entspricht. Am einfachsten ist es, dies mit Python zu tun: dafür gibt es komfortable, fertige Werkzeuge.
Die versprochenen Stolpersteine
Das Hauptproblem ist, dass viele Aspekte in ACI anders umgesetzt sind. Um effektiv damit zu arbeiten, muss man umdenken. Dies gilt insbesondere für die Netzwerkteams großer Kunden, wo Ingenieure jahrelang mit dem "Einrichten von VLANs" auf Anfragen beschäftigt sind. Die Tatsache, dass ein VLAN jetzt kein VLAN mehr ist und man für die Einrichtung neuer Netzwerke in virtualisierten Hosts VLANs nicht mehr manuell anlegen muss, verwirrt die traditionellen Netzwerkexperten und zwingt sie dazu, an gewohnten Ansätzen festzuhalten. Es ist anzumerken, dass Cisco versucht hat, die Umstellung etwas zu erleichtern, indem es im Controller ein "NXOS-ähnliches" CLI hinzugefügt hat, das die Konfiguration über eine Oberfläche ermöglicht, die den traditionellen Switches ähnelt. Trotzdem muss man, um ACI wirklich effektiv nutzen zu können, verstehen, wie es funktioniert.
Aus Preissicht unterscheidet sich ACI-Netzwerke in großen und mittleren Maßstäben praktisch nicht von traditionellen Netzwerken auf Cisco-Hardware, da für ihren Aufbau dieselben Switches verwendet werden (Nexus 9000 können sowohl im ACI- als auch im traditionellen Modus betrieben werden und sind mittlerweile das Hauptarbeitsmittel für neue Rechenzentrumsprojekte). Bei Rechenzentren mit zwei Switches machen sich jedoch die Controller und die Spine-Leaf-Architektur bemerkbar. Kürzlich wurde eine Mini ACI-Fabrik eingeführt, in der zwei der drei Controller durch virtuelle Maschinen ersetzt wurden. Dies reduziert zwar die Preisunterschiede, doch diese bleiben weiterhin bestehen. Daher wird die Wahl des Kunden durch sein Interesse an Sicherheitsfunktionen, Integration mit Virtualisierung und einer einheitlichen Steuerung bestimmt.
Quelle: habr.com
