Mit diesem magischen Stück Skript Cisco ACI kann man schnell ein Netzwerk einrichten.
Die Netzwerkfabrik für Rechenzentren Cisco ACI existiert bereits seit fünf Jahren, aber auf Habré wurde darüber nicht viel gesagt, also habe ich beschlossen, das ein wenig zu ändern. Ich werde aus meiner Erfahrung erzählen, was das ist, welchen Nutzen es hat 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 wurden die traditionellen Ansätze für Rechenzentrumsnetzwerke gleichzeitig von drei Seiten angegriffen.
Auf der einen Seite versprachen SDN-Lösungen der "ersten Generation" auf Basis von OpenFlow, Netzwerke gleichzeitig flexibler und kostengünstiger zu machen. Die Idee war, die Entscheidungsfindung, die traditionell von proprietärer Software der Switches durchgeführt wurde, auf einen zentralen Controller zu verlagern.
Dieser Controller hätte eine einheitliche Sicht auf alles Geschehen und würde auf dieser Basis die Hardware aller Switches auf der Ebene von Regeln für die Verarbeitung bestimmter Flüsse programmieren.
Auf der anderen Seite ermöglichten Overlay-Netzwerklösungen die Umsetzung der gewünschten Konnektivität und Sicherheitsrichtlinien ganz ohne Änderungen im physischen Netzwerk, indem sie Software-Tunnel zwischen virtualisierten Hosts errichteten. Das bekannteste Beispiel für diesen Ansatz war die Lösung von Nicira, die zu diesem Zeitpunkt bereits von VMWare für 1,26 Milliarden Dollar übernommen worden war und den Grundstein für das heutige VMWare NSX legte. Eine gewisse Würze der Situation verlieh das fact, dass die Mitgründer von Nicira dieselben Personen waren, die zuvor die Grundlagen von OpenFlow gelegt hatten und nun sagten, dass für den Aufbau einer Rechenzentrumsfabrik OpenFlow nicht geeignet ist. .
Schließlich haben die Switching-Chips, die auf dem offenen Markt verfügbar sind (das, was man merchant silicon nennt), ein Reifegrad erreicht, bei dem sie eine echte Bedrohung für traditionelle Switch-Hersteller darstellten. Während früher jeder Anbieter Chips für seine eigenen Switches entwickelte, begannen die Chips von Drittherstellern, insbesondere von Broadcom, im Funktionsumfang aufzuholen und sie hinsichtlich des Preis-Leistungs-Verhältnisses zu übertreffen. Daher glaubten viele, dass die Tage der Switches mit selbst entwickelten Chips gezählt sind.
ACI wurde zu einer "asymmetrischen Antwort" von Cisco (genauer gesagt von der in Cisco integrierten Firma Insieme, die von ehemaligen Mitarbeitern gegründet wurde) auf all das.
Was ist der Unterschied zu OpenFlow?
Aus der Perspektive der Funktionsverteilung ist ACI faktisch das Gegenteil von OpenFlow.
In der OpenFlow-Architektur ist der Controller für das Schreiben detaillierter Regeln (Flows)
in der Hardware aller Switches verantwortlich, das heißt, in einem großen Netzwerk kann die Verantwortung für die Pflege und vor allem die Änderung von zig Millionen Einträgen an hunderten Punkten im Netzwerk liegen, weshalb die Leistung und Zuverlässigkeit in großen Implementierungen zum Engpass werden.
In ACI wird ein umgekehrter Ansatz verwendet: Es gibt zwar auch einen Controller, aber die Switches erhalten von ihm hochrangige deklarative Richtlinien, während die Umsetzung in spezifische Einstellungen in der Hardware vom Switch selbst durchgeführt wird. Der Controller kann neu gestartet oder sogar ganz abgeschaltet werden, und es passiert nichts Schlimmes mit dem Netzwerk, außer natürlich, dass zu diesem Zeitpunkt keine Steuerung möglich ist. Interessanterweise gibt es in ACI Situationen, in denen OpenFlow dennoch verwendet wird, aber lokal innerhalb des Hosts zur Programmierung von Open vSwitch.
ACI basiert vollständig auf einem Overlay-Transport auf Basis von VXLAN, schließt jedoch im Rahmen einer einheitlichen Lösung auch den darunterliegenden IP-Transport ein. Cisco bezeichnete dies als „integriertes Overlay“. Als Endpunkt für Overlays werden in ACI meist Fabrik-Switches verwendet (sie erledigen dies mit Kanalgeschwindigkeit). Hosts müssen nichts über die Fabrik, Kapselung usw. wissen, aber in einigen Fällen (zum Beispiel zur Anbindung von OpenStack-Hosts) kann VXLAN-Verkehr auch zu ihnen weitergeleitet werden.
Overlays werden in ACI nicht nur zur Bereitstellung flexibler Konnektivität über das Transportsystem verwendet, sondern auch zur Übertragung von Metainformationen (diese werden beispielsweise zur Anwendung von Sicherheitsrichtlinien verwendet).
Broadcom-Chips wurden bereits zuvor von Cisco in der Nexus 3000 Switch-Serie verwendet. In der Nexus 9000-Familie, die speziell zur Unterstützung von ACI entwickelt wurde, wurde anfänglich ein hybrides Modell implementiert, das Merchant+ genannt wurde. Im Switch wurden gleichzeitig der neue Broadcom Trident 2 Chip und ein ergänzender Chip von Cisco verwendet, der die gesamte ACI-Magie umsetzt. Das hat anscheinend die Markteinführung beschleunigt und den Preis des Switches auf ein Niveau gesenkt, das nah an den einfachen Trident 2-Modellen liegt. Dieser Ansatz hielt die ersten zwei bis drei Jahre der ACI-Lieferungen. In dieser Zeit hat Cisco die nächste Generation der Nexus 9000 auf den Markt gebracht, die bereits auf ihren eigenen Chips mit höherer Leistung und Funktionalität basiert, jedoch zum gleichen Preisniveau. Die externen Spezifikationen in Bezug auf die Interaktion in der Fabrik blieben vollständig erhalten. Gleichzeitig hat sich die interne Hardware komplett geändert: etwas wie ein Refactoring, aber für die Hardware.
Wie ist die Architektur von Cisco ACI aufgebaut?
Im einfachsten Fall basiert ACI auf einer Clos-Netzwerktopologie, oder wie oft gesagt wird, Spine-Leaf. Es kann zwischen zwei (oder einem, wenn Fehlertoleranz nicht wichtig ist) und sechs Spine-Level-Switches geben. Je mehr es davon gibt, desto höher ist die Fehlertoleranz (geringerer Leistungs- und Zuverlässigkeitsverlust bei einem Ausfall oder Wartung eines Spine) und die Gesamteffizienz. Alle externen Verbindungen laufen zu den Leaf-Level-Switches: dazu gehören Server, das Anbinden an externe Netzwerke über L2 oder L3 und die Verbindung von APIC-Controllern. Grundsätzlich wird bei ACI nicht nur die Konfiguration, sondern auch die Statistiksammlung, das Monitoring von Ausfällen und mehr alles über das Interface der Controller durchgeführt, von denen es in normalen Implementierungen drei gibt.
Es ist niemals notwendig, sich über die Konsole mit den Switches zu verbinden, selbst nicht für den Netzwerkstart: Der Controller entdeckt die Switches selbst und stellt das Fabriknetzwerk zusammen, einschließlich der Einstellungen aller Protokolle. Daher ist es beim Einbau sehr wichtig, die Seriennummern der installierten Geräte festzuhalten, um später nicht raten zu müssen, welcher Switch in welchem Rack steht. Für das Troubleshooting kann man sich bei Bedarf über SSH mit den Switches verbinden: Auf ihnen sind die üblichen Cisco Show-Befehle recht gründlich implementiert.
Innerhalb der Fabrik wird IP-Transport verwendet, sodass es kein Spanning Tree und andere Schrecken der Vergangenheit gibt: Alle Links sind aktiv, und die Konvergenz bei Ausfällen ist sehr schnell. Der Datenverkehr in der Fabrik wird über Tunnel auf der Basis von VXLAN übertragen. Genauer gesagt, Cisco nennt die Kapselung iVXLAN, die sich von dem normalen VXLAN dadurch unterscheidet, dass die reservierten Felder im Netzwerkheader zur Übertragung von Verwaltungsinformationen verwendet werden, vor allem zur Beziehung des Datenverkehrs zur Gruppe EPG. Dies ermöglicht die Implementierung von Interaktionsregeln zwischen Gruppen in der Hardware, indem ihre Nummern genauso wie in normalen Access-Listen verwendet werden.
Tunnel ermöglichen es, sowohl L2-Segmente als auch L3 (d. h. VRF) über den internen IP-Transport auszudehnen. Dabei ist das Standard Gateway verteilt. Das bedeutet, dass jeder Switch für die Routing der eingehenden Fabrikdaten verantwortlich ist. In Bezug auf die Verkehrstransferlogik ähnelt ACI einer Fabrik auf der Basis von VXLAN/EVPN.
Wenn ja, wo liegen die Unterschiede? In allem anderen!
Der erste Unterschied, dem man in ACI begegnet, ist, wie Server ins Netzwerk eingebunden werden. In traditionellen Netzwerken erfolgt die Anbindung sowohl physischer Server als auch virtueller Maschinen an VLANs, und alles andere orientiert sich daran: Konnektivität, Sicherheit usw. In ACI wird jedoch eine Konstruktion verwendet, die Cisco als EPG (End-Point Group) bezeichnet, von der man sich nicht befreien kann. Kann man sie mit VLAN gleichsetzen? Ja, aber in diesem Fall besteht die Gefahr, einen großen Teil der Vorteile von ACI zu verlieren.
Alle Zugriffsregeln werden relativ zu EPG formuliert, und in ACI wird standardmäßig das Prinzip der „Whitelist“ verwendet, das heißt, es ist nur der Datenverkehr zugelassen, der ausdrücklich erlaubt wird. 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. Dies funktioniert unabhängig von Netzwerkadressen und sogar innerhalb eines Subnetzes!
Wir haben Kunden, die sich genau wegen dieser Funktion für ACI entschieden haben, da sie den Zugriff zwischen Servern (virtuellen oder physischen – egal) einschränken kann, ohne sie zwischen Subnetzen zu verschieben, also die Adressierung nicht berührt. Ja, ja, wir wissen, niemand schreibt sie von Hand IP-Adressen in den Anwendungs-Konfigurationen, oder?
Die Regeln für den Datenverkehr 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 einen Datenbankdienst) und andere zum Verbraucher. Der Vertrag kann den Datenverkehr einfach leiten oder etwas Ausgeklügelteres tun, wie ihn an eine Firewall oder einen Lastenausgleich weiterzuleiten und auch den Wert von QoS zu ändern.
Wie gelangen Server in diese Gruppen? Wenn es sich um physische Server handelt oder um etwas, das in ein existierendes Netzwerk integriert ist, in das wir einen VLAN-Trunk erstellt haben, müssen wir für die Platzierung in der EPG den Anschluss des Switches und den verwendeten VLAN angeben. Wie wir sehen, erscheinen VLANs dort, wo man nicht auf sie verzichten kann.
Wenn es sich jedoch um virtuelle Maschinen handelt, reicht es aus, auf die angeschlossene Virtualisierungsumgebung zu verweisen, und der Rest geschieht von selbst: Es wird eine Portgruppe (wenn wir in Begriffen von VMware sprechen) zur Verbindung von VMs erstellt, die erforderlichen VLANs oder VXLANs werden zu den entsprechenden Ports der Switches zugewiesen usw. Daher sieht die Verbindung von virtuellen Servern in ACI viel einfacher aus als die von physischen Servern, obwohl ACI auf einem physischen Netzwerk basiert. ACI hat bereits eine Integration mit VMware und MS Hyper-V sowie Unterstützung für OpenStack und RedHat Virtualization. Seit einiger Zeit gibt es auch eine integrierte Unterstützung für Containerplattformen: Kubernetes, OpenShift, Cloud Foundry, die sowohl die Anwendung von Richtlinien als auch das Monitoring umfasst, sodass Netzwerkadministratoren sofort sehen können, auf welchen Hosts welche Pods laufen und in welche Gruppen sie eingeteilt wurden.
Neben der Zugehörigkeit zu einer bestimmten Portgruppe haben virtuelle Server zusätzliche Eigenschaften: Name, Attribute usw., die als Kriterien für deren Übertragung in eine andere Gruppe verwendet werden können, zum Beispiel bei der Umbenennung von VMs oder dem Hinzufügen eines zusätzlichen Tags. Cisco nennt dies Mikrosegmentierungsgruppen, obwohl die Möglichkeit, viele Sicherheitssegmente in Form von EPG innerhalb desselben Subnetzes zu erstellen, auch eine Form der Mikrosegmentierung ist. Nun, das sieht der Anbieter wahrscheinlich anders.
Die EPGs sind rein logische Konstrukte, die nicht an bestimmte Switches, Server usw. gebunden sind, sodass man mit ihnen und auf ihnen basierenden Konstruktionen (Anwendungen und Tenants) Dinge tun kann, die in traditionellen Netzwerken schwer umzusetzen sind, beispielsweise Klonen. Das heißt, es ist sehr einfach, eine Kopie der Produktionsumgebung zu erstellen, um eine Testumgebung zu erhalten, die garantiert identisch mit der Produktion ist. Man kann es manuell machen, aber besser (und einfacher) geht es über die API.
Im Allgemeinen unterscheidet sich die Steuerungslogik in ACI erheblich von dem, was man normalerweise antrifft
in traditionellen Netzwerken von Cisco: Die Programmierschnittstelle ist primär, während GUI oder CLI sekundär sind, da sie über dieselbe API funktionieren. Daher beginnt fast jeder, der sich mit ACI beschäftigt, nach einer Weile, sich in das Objektmodell einzuarbeiten, das für das Management verwendet wird, und etwas zu automatisieren, um seinen Bedürfnissen gerecht zu werden. Am einfachsten lässt sich das mit Python realisieren: Es gibt dafür bequeme, fertig entwickelte Werkzeuge.
Die versprochenen Stolpersteine
Das Hauptproblem ist, dass viele Dinge in ACI anders gemacht werden. Um damit richtig arbeiten zu können, muss man umdenken. Dies gilt insbesondere für die Netzbetriebs-Teams in großen Unternehmen, wo Ingenieure jahrelang mit der "Zuweisung von VLANs" nach Anträgen beschäftigt waren. Das, was jetzt VLAN ist – ist nicht mehr VLAN, und um neue Netzwerke in virtualisierte Hosts zu verlegen, muss man VLANs überhaupt nicht manuell erstellen, erschüttert die traditionellen Netzwerker und zwingt sie, an gewohnten Ansätzen festzuhalten. Man muss anmerken, dass Cisco versucht hat, das Ganze etwas zu entschärfen, und dem Controller ein "NXOS-ähnliches" CLI hinzugefügt hat, das die Konfiguration über eine Oberfläche ermöglicht, die traditionellen Switches ähnelt. Aber um ACI richtig zu nutzen, muss man trotzdem verstehen, wie es funktioniert.
In Bezug auf die Preise in großen und mittleren ACI-Netzwerken unterscheidet sich die Preisgestaltung tatsächlich nicht von traditionellen Netzwerken auf Cisco-Hardware, da die gleichen Switches verwendet werden (Nexus 9000 können sowohl im ACI- als auch im traditionellen Modus betrieben werden und sind mittlerweile das Hauptarbeitsgerät für neue Rechenzentrumprojekte). Für Rechenzentren hingegen machen sich Controller und die Spine-Leaf-Architektur bei zwei Switches jedoch bemerkbar. Kürzlich wurde eine Mini-ACI-Fabrik eingeführt, bei der zwei von drei Controllern durch virtuelle Maschinen ersetzt wurden. Dies verringert zwar den Kostenunterschied, aber er bleibt dennoch bestehen. Daher wird die Wahl des Kunden von seinem Interesse an Sicherheitsfunktionen, der Integration mit Virtualisierung, einer einheitlichen Verwaltungsoberfläche und anderem bestimmt.
Quelle: habr.com
