Netzwerkstruktur für das Cisco ACI-Rechenzentrum – zur Unterstützung des Administrators

Netzwerkstruktur für das Cisco ACI-Rechenzentrum – zur Unterstützung des Administrators
Mit Hilfe dieses magischen Teils des Cisco ACI-Skripts können Sie schnell ein Netzwerk einrichten.

Die Netzwerkfabrik für das Cisco ACI-Rechenzentrum existiert seit fünf Jahren, aber Habré hat nicht wirklich etwas darüber erzählt, also habe ich beschlossen, es ein wenig zu reparieren. Ich erzähle Ihnen aus eigener Erfahrung, was es ist, welchen Nutzen es hat und wo es einen Rechen hat.

Was ist das und wo kommt es her?

Als ACI (Application Centric Infrastructure) im Jahr 2013 angekündigt wurde, rückten die Wettbewerber von drei Seiten gleichzeitig auf traditionelle Ansätze für Rechenzentrumsnetzwerke vor.

Einerseits versprachen SDN-Lösungen der „ersten Generation“ auf Basis von OpenFlow, Netzwerke flexibler und gleichzeitig günstiger zu machen. Die Idee bestand darin, die Entscheidungsfindung, die traditionell durch proprietäre Switch-Software erfolgt, auf einen zentralen Controller zu verlagern.

Dieser Controller hätte eine einheitliche Sicht auf alles, was passiert, und würde auf dieser Grundlage die Hardware aller Switches auf der Ebene von Regeln für die Verarbeitung bestimmter Abläufe programmieren.
Andererseits ermöglichten Overlay-Netzwerklösungen die Implementierung der erforderlichen Konnektivitäts- und Sicherheitsrichtlinien ohne jegliche Änderungen am physischen Netzwerk, indem Softwaretunnel zwischen virtualisierten Hosts aufgebaut wurden. Das bekannteste Beispiel für diesen Ansatz war Nicira, das zu diesem Zeitpunkt bereits für 1,26 Milliarden US-Dollar von VMWare übernommen wurde und aus dem das aktuelle VMWare NSX hervorging. Etwas pikanter wurde die Situation durch die Tatsache, dass die Mitbegründer von Nicira dieselben Leute waren, die zuvor an den Ursprüngen von OpenFlow standen, und dies jetzt sagen, um eine Rechenzentrumsfabrik zu bauen OpenFlow ist nicht geeignet.

Und schließlich haben die auf dem freien Markt erhältlichen Switch-Chips (sogenanntes Merchant Silicon) einen Reifegrad erreicht, in dem sie zu einer echten Bedrohung für traditionelle Switch-Hersteller geworden sind. Wenn früher jeder Anbieter unabhängig voneinander Chips für seine Switches entwickelte, begannen Chips von Drittherstellern, vor allem von Broadcom, im Laufe der Zeit den Abstand zu Anbieterchips hinsichtlich der Funktionen zu verringern und diese hinsichtlich des Preis-Leistungs-Verhältnisses zu übertreffen. Daher glaubten viele, dass die Tage der Schalter auf selbst entwickelten Chips gezählt seien.

ACI ist Ciscos „asymmetrische Antwort“ (genauer gesagt das von seinen ehemaligen Mitarbeitern gegründete Unternehmen Insieme) auf all das geworden.

Was ist der Unterschied zu OpenFlow?

Hinsichtlich der Funktionsverteilung ist ACI eigentlich das Gegenteil von OpenFlow.
In der OpenFlow-Architektur ist der Controller für das Schreiben detaillierter Regeln (Flows) verantwortlich.
In der Hardware aller Switches, also in einem großen Netzwerk, kann es für die Verwaltung und vor allem für die Änderung von zig Millionen Datensätzen an Hunderten von Punkten im Netzwerk verantwortlich sein, sodass seine Leistung und Zuverlässigkeit zu einem Engpass werden große Umsetzung.

ACI verwendet den umgekehrten Ansatz: Natürlich gibt es auch einen Controller, aber die Switches erhalten von ihm deklarative Richtlinien auf hoher Ebene, und der Switch selbst führt deren Rendering in Details spezifischer Einstellungen in der Hardware durch. Der Controller kann neu gestartet oder ganz ausgeschaltet werden, und dem Netzwerk passiert nichts Schlimmes, außer natürlich der mangelnden Kontrolle in diesem Moment. Interessanterweise gibt es in ACI Situationen, in denen OpenFlow weiterhin verwendet wird, jedoch lokal innerhalb des Hosts für die Open vSwitch-Programmierung.

ACI basiert vollständig auf VXLAN-basiertem Overlay-Transport, umfasst jedoch den zugrunde liegenden IP-Transport als Teil einer einzigen Lösung. Cisco nannte dies den Begriff „integriertes Overlay“. Als Abschlusspunkt für Overlays in ACI werden in den meisten Fällen Werks-Switches verwendet (sie tun dies mit Verbindungsgeschwindigkeit). Hosts müssen nichts über die Fabrik, Kapselung usw. wissen. In einigen Fällen (z. B. um OpenStack-Hosts zu verbinden) kann jedoch VXLAN-Verkehr zu ihnen geleitet werden.

Overlays werden in ACI nicht nur zur Bereitstellung flexibler Konnektivität über das Transportnetzwerk verwendet, sondern auch zur Übertragung von Metainformationen (z. B. zur Anwendung von Sicherheitsrichtlinien).

Chips von Broadcom wurden von Cisco zuvor in den Switches der Nexus 3000-Serie verwendet. In der speziell zur Unterstützung von ACI freigegebenen Nexus 9000-Familie wurde ursprünglich ein Hybridmodell implementiert, das Merchant + hieß. Der Switch nutzte gleichzeitig sowohl den neuen Broadcom Trident 2-Chip als auch einen von Cisco entwickelten ergänzenden Chip, der die ganze Magie von ACI implementiert. Anscheinend war es dadurch möglich, die Veröffentlichung des Produkts zu beschleunigen und den Preis des Wechsels auf ein Niveau zu senken, das nahe an Modellen liegt, die einfach auf Trident 2 basieren. Dieser Ansatz reichte für die ersten zwei oder drei Jahre der ACI-Lieferungen aus. In dieser Zeit entwickelte und brachte Cisco die nächste Generation des Nexus 9000 auf eigenen Chips mit mehr Leistung und Funktionsumfang, aber zum gleichen Preisniveau auf den Markt. Äußere Vorgaben hinsichtlich der Interaktion im Werk bleiben vollständig erhalten. Gleichzeitig hat sich die Innenfüllung komplett verändert: so etwas wie Refactoring, aber für Eisen.

So funktioniert die Cisco ACI-Architektur

Im einfachsten Fall basiert ACI auf der Topologie des Klose-Netzwerks oder, wie man oft sagt, Spine-Leaf. Spine-Level-Schalter können zwischen zwei (oder eins, wenn uns die Fehlertoleranz nicht wichtig ist) bis sechs sein. Je mehr davon vorhanden sind, desto höher ist die Fehlertoleranz (je geringer die Bandbreiten- und Zuverlässigkeitsreduzierung im Falle eines Unfalls oder der Wartung eines Spines) und die Gesamtleistung. Alle externen Verbindungen gehen zu Switches auf Blattebene: Dies sind Server, die über L2 oder L3 an externe Netzwerke andocken und APIC-Controller verbinden. Im Allgemeinen erfolgt mit ACI nicht nur die Konfiguration, sondern auch die Erfassung von Statistiken, die Fehlerüberwachung usw. – alles erfolgt über die Schnittstelle von Controllern, von denen es in Standardimplementierungen drei gibt.

Sie müssen nie mit der Konsole eine Verbindung zu den Switches herstellen, auch nicht, um das Netzwerk zu starten: Der Controller selbst erkennt die Switches und stellt daraus eine Factory zusammen, einschließlich der Einstellungen aller Serviceprotokolle, daher ist es übrigens sehr wichtig, dies zu tun Notieren Sie sich bei der Installation die Seriennummern der zu installierenden Geräte, damit Sie später nicht raten müssen, welcher Switch sich in welchem ​​Rack befindet. Zur Fehlerbehebung können Sie sich bei Bedarf per SSH mit den Switches verbinden: Sie reproduzieren die üblichen Cisco-Show-Befehle recht sorgfältig.

Intern verwendet die Fabrik IP-Transport, sodass es kein Spanning Tree und andere Schrecken der Vergangenheit gibt: Alle Verbindungen sind beteiligt und die Konvergenz bei Ausfällen erfolgt sehr schnell. Der Datenverkehr in der Fabric wird über Tunnel auf Basis von VXLAN übertragen. Genauer gesagt nennt Cisco selbst die iVXLAN-Kapselung und unterscheidet sich vom regulären VXLAN dadurch, dass die reservierten Felder im Netzwerk-Header zur Übertragung von Dienstinformationen verwendet werden, hauptsächlich über die Beziehung des Datenverkehrs zur EPG-Gruppe. Auf diese Weise können Sie die Regeln für die Interaktion zwischen Gruppen im Gerät umsetzen und deren Nummern auf die gleiche Weise verwenden, wie Adressen in gewöhnlichen Zugriffslisten verwendet werden.

Mithilfe von Tunneln können sowohl L2-Segmente als auch L3-Segmente (d. h. VRF) durch den internen IP-Transport gestreckt werden. In diesem Fall wird das Standard-Gateway verteilt. Dies bedeutet, dass jeder Switch für die Weiterleitung des in die Fabric eingehenden Datenverkehrs verantwortlich ist. In Bezug auf die Verkehrsflusslogik ähnelt ACI einer VXLAN/EVPN-Struktur.

Wenn ja, was sind die Unterschiede? Alles andere!

Der größte Unterschied, den Sie bei ACI feststellen, besteht darin, wie Server mit dem Netzwerk verbunden sind. In herkömmlichen Netzwerken geht die Einbeziehung sowohl physischer Server als auch virtueller Maschinen in VLANs über, und alles andere geht von ihnen aus: Konnektivität, Sicherheit usw. In ACI wird ein Design verwendet, das Cisco EPG (Endpoint Group) nennt Es gibt kein Entkommen. Ist es möglich, es mit VLAN gleichzusetzen? Ja, aber in diesem Fall besteht die Möglichkeit, dass das meiste, was ACI bietet, verloren geht.

In Bezug auf EPG sind alle Zugangsregeln formuliert, und in ACI wird standardmäßig das „White-List“-Prinzip verwendet, das heißt, es wird nur Verkehr zugelassen, dessen Durchfahrt ausdrücklich erlaubt ist. Das heißt, wir können die EPG-Gruppen „Web“ und „MySQL“ erstellen und eine Regel definieren, die die Kommunikation zwischen ihnen nur über Port 3306 zulässt. Dies funktioniert ohne Bindung an Netzwerkadressen und sogar innerhalb desselben Subnetzes!

Wir haben Kunden, die sich genau wegen dieser Funktion für ACI entschieden haben, da Sie damit den Zugriff zwischen Servern (virtuell oder physisch – egal) einschränken können, ohne sie zwischen Subnetzen zu verschieben, also ohne die Adressierung zu beeinträchtigen. Ja, ja, wir wissen, dass niemand IP-Adressen in Anwendungskonfigurationen manuell vorschreibt, oder?

Verkehrsregeln werden im ACI als Verträge bezeichnet. In einem solchen Vertrag werden eine oder mehrere Gruppen oder Ebenen in einer mehrschichtigen Anwendung zu einem Dienstanbieter (z. B. einem Datenbankdienst), andere werden zu einem Verbraucher. Der Vertrag kann den Datenverkehr einfach weiterleiten oder etwas Schwierigeres tun, ihn beispielsweise an eine Firewall oder einen Balancer weiterleiten und auch den QoS-Wert ändern.

Wie kommen Server in diese Gruppen? Wenn es sich um physische Server oder etwas handelt, das in ein bestehendes Netzwerk eingebunden ist, in dem wir einen VLAN-Trunk erstellt haben, müssen Sie zum Platzieren im EPG auf den Switch-Port und das darauf verwendete VLAN verweisen. Wie Sie sehen, tauchen VLANs dort auf, wo Sie nicht darauf verzichten können.

Wenn es sich bei den Servern um virtuelle Maschinen handelt, reicht es aus, auf die angeschlossene Virtualisierungsumgebung zu verweisen, und dann geschieht alles von selbst: Es wird eine Portgruppe (im Sinne von VMWare) erstellt, um die VM zu verbinden, die erforderlichen VLANs oder VXLANs werden erstellt zugewiesen werden, werden sie an den erforderlichen Switch-Ports usw. registriert. Obwohl ACI also um ein physisches Netzwerk herum aufgebaut ist, sehen Verbindungen für virtuelle Server viel einfacher aus als für physische. ACI verfügt bereits über integrierte Konnektivität mit VMWare und MS Hyper-V sowie Unterstützung für OpenStack- und RedHat-Virtualisierung. Ab einem bestimmten Zeitpunkt gibt es auch eine integrierte Unterstützung für Containerplattformen: Kubernetes, OpenShift, Cloud Foundry, wobei es sowohl um die Anwendung von Richtlinien als auch um die Überwachung geht, d. h. der Netzwerkadministrator kann sofort sehen, auf welchen Hosts welche Pods arbeiten und in welche Gruppen sie fallen.

Zusätzlich zur Aufnahme in eine bestimmte Portgruppe verfügen virtuelle Server über zusätzliche Eigenschaften: Name, Attribute usw., die als Kriterien für die Übertragung in eine andere Gruppe verwendet werden können, beispielsweise wenn eine VM umbenannt wird oder ein zusätzliches Tag erscheint Es. Cisco nennt dies Mikrosegmentierungsgruppen, obwohl das Design selbst mit der Möglichkeit, viele Sicherheitssegmente in Form von EPGs im selben Subnetz zu erstellen, im Großen und Ganzen ebenfalls eine Mikrosegmentierung darstellt. Nun, der Verkäufer weiß es besser.

EPGs selbst sind rein logische Konstrukte, die nicht an bestimmte Switches, Server usw. gebunden sind, sodass Sie mit ihnen und darauf basierenden Konstrukten (Anwendungen und Mandanten) Dinge tun können, die in normalen Netzwerken nur schwer möglich sind, wie z. B. Klonen. Nehmen wir an, es ist daher sehr einfach, eine Produktionsumgebung zu klonen, um eine Testumgebung zu erhalten, die garantiert mit der Produktionsumgebung identisch ist. Sie können es manuell tun, aber es ist besser (und einfacher) über die API.

Im Allgemeinen ähnelt die Steuerungslogik in ACI überhaupt nicht der, die Sie normalerweise antreffen
in herkömmlichen Netzwerken desselben Cisco: Die Softwareschnittstelle ist primär und die GUI oder CLI sind sekundär, da sie über dieselbe API arbeiten. Daher beginnt fast jeder, der an ACI beteiligt ist, nach einer Weile, sich mit dem für die Verwaltung verwendeten Objektmodell zurechtzufinden und etwas zu automatisieren, das seinen Anforderungen entspricht. Am einfachsten geht das mit Python: Dafür gibt es praktische vorgefertigte Tools.

Versprochener Rechen

Das Hauptproblem besteht darin, dass viele Dinge in ACI anders gemacht werden. Um normal damit arbeiten zu können, müssen Sie sich umschulen. Dies gilt insbesondere für Netzwerkbetriebsteams bei Großkunden, bei denen Ingenieure seit Jahren auf Anfrage „VLANs verschreiben“. Die Tatsache, dass VLANs jetzt keine VLANs mehr sind und Sie keine VLANs manuell erstellen müssen, um neue Netzwerke in virtualisierten Hosts einzurichten, sprengt traditionelle Netzwerker völlig und zwingt sie, an vertrauten Ansätzen festzuhalten. Es sei darauf hingewiesen, dass Cisco versucht hat, die Pille ein wenig zu versüßen, und dem Controller eine „NXOS-ähnliche“ CLI hinzugefügt hat, die es Ihnen ermöglicht, die Konfiguration über eine Schnittstelle vorzunehmen, die den herkömmlichen Switches ähnelt. Um ACI jedoch normal verwenden zu können, müssen Sie dennoch verstehen, wie es funktioniert.

Preislich unterscheiden sich ACI-Netzwerke im großen und mittleren Maßstab eigentlich nicht von herkömmlichen Netzwerken auf Cisco-Geräten, da für deren Aufbau dieselben Switches verwendet werden (Nexus 9000 kann im ACI- und im herkömmlichen Modus arbeiten und ist mittlerweile der wichtigste „Arbeitstier“ für neue Rechenzentrumsprojekte). Aber bei Rechenzentren mit zwei Switches macht sich natürlich das Vorhandensein von Controllern und der Spine-Leaf-Architektur bemerkbar. Kürzlich ist eine Mini-ACI-Fabrik aufgetaucht, in der zwei der drei Controller durch virtuelle Maschinen ersetzt werden. Dadurch verringert sich der Kostenunterschied, bleibt aber bestehen. Für den Kunden hängt die Wahl also davon ab, wie sehr er an Sicherheitsfunktionen, Integration mit Virtualisierung, einem einzigen Kontrollpunkt usw. interessiert ist.

Source: habr.com

Kommentar hinzufügen