🥇Erfahrungen bei der Umsetzung von Netzwerkfabriken auf Basis von EVPN VXLAN und Cisco ACI sowie ein kleiner Vergleich

Bewerten Sie die Verbindungen im mittleren Teil des Diagramms. Darauf werden wir später zurückkommen.

Irgendwann werden Sie mit dem Problem konfrontiert, dass große komplexe L2-Netzwerke unheilbar krank sind. Zunächst einmal gibt es Probleme im Zusammenhang mit der Verarbeitung von BUM-Traffic und der Funktionsweise des STP-Protokolls. Zweitens ist die gesamte Architektur moralisch veraltet. Das führt zu unangenehmen Problemen in Form von Ausfallzeiten und Schwierigkeiten bei der Verwaltung.

Wir hatten zwei parallele Projekte, in denen die Kunden die Vor- und Nachteile der Optionen nüchtern bewerteten und zwei verschiedene Overlay-Lösungen wählten, die wir implementierten.

Es gab die Möglichkeit, genau die Implementierung zu vergleichen. Nicht den Betrieb, darüber kann man in zwei bis drei Jahren sprechen.

Was ist also eine Netzwerkfabrik mit Overlay-Netzen und SDN?

Was tun mit den drängenden Problemen der klassischen Netzwerkarchitektur?

Jedes Jahr tauchen neue Technologien und Ideen auf. In der Praxis gab es lange kein dringendes Bedürfnis, Netzwerke umzugestalten, da alles auch nach den alten, bewährten Methoden von Hand erledigt werden kann. Und was ist, wenn wir im 21. Jahrhundert leben? Schließlich muss der Admin arbeiten und kann sich nicht nur in seinem Büro aufhalten.

Dann begann der Boom beim Bau großflächiger Rechenzentren. Da wurde klar, dass das Limit der Entwicklung der klassischen Architektur nicht nur in Bezug auf Funktionsfähigkeit, Fehlertoleranz und Skalierbarkeit erreicht war. Eine der Lösungen für diese Probleme war die Idee, Overlay-Netze über einem routbaren Backbone zu schaffen.

Darüber hinaus stellte sich mit der Vergrößerung der Netzwerke das dringende Problem des Managements solcher Fabriken, was zur Entstehung von Lösungen für softwaredefinierte Netzwerke führte, die es ermöglichen, die gesamte Netzwerkinfrastruktur als Ganzes zu verwalten. Und wenn das Netzwerk von einem einzigen Punkt aus verwaltet wird, ist es für andere Komponenten der IT-Infrastruktur einfacher, mit ihm zu interagieren, und derartige Interaktionsprozesse lassen sich einfacher automatisieren.

Fast jeder große Hersteller nicht nur von Netzwerkhardware, sondern auch von Virtualisierung hat in seinem Portfolio solche Lösungen.

Es bleibt nur zu klären, was für welche Bedürfnisse geeignet ist. Beispielsweise genügt bei besonders großen Unternehmen mit einem guten Team von Entwicklern und Betrieb in 99 Prozent der Fälle nicht immer die Standardlösung der Anbieter, weshalb sie auf die Entwicklung eigener SD (software defined) Lösungen zurückgreifen. Dazu gehören beispielsweise Cloud-Anbieter, die ständig ihr Serviceangebot für ihre Kunden erweitern, wobei Standardlösungen einfach nicht mit ihren Anforderungen Schritt halten können.

Für mittelgroße Unternehmen genügt die von den Anbietern in Form einer Standardlösung angebotene Funktionalität in 99 Prozent der Fälle.

Was sind Overlay-Netzwerke?

Worin besteht die Idee von Overlay-Netzwerken? Im Grunde genommen nehmen Sie ein klassisches routbares Netzwerk und bauen ein weiteres Netzwerk darüber auf, um mehr Funktionen zu erhalten. Es geht häufig um eine effiziente Lastverteilung auf die Hardware und Kommunikationsleitungen, eine signifikante Erhöhung des Skalierungslimits, eine Verbesserung der Zuverlässigkeit und viele Sicherheitsvorteile (durch Segmentierung). Darüber hinaus bieten SDN-Lösungen die Möglichkeit eines sehr, sehr, sehr komfortablen flexiblen Managements und machen das Netzwerk transparenter für seine Nutzer.

Wenn lokale Netzwerke in den 2010er Jahren erfunden worden wären, würden sie ganz anders aussehen als das, was wir als Erbe von den Militärs der 1970er Jahre erhalten haben.

Aus Sicht der Technologien für den Bau von Fabriken mithilfe von Overlay-Netzwerken gibt es derzeit zahlreiche Implementierungen von Herstellern und Internetprojekten (RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve und andere). Ja, es gibt Standards, aber die Implementierung dieser Standards durch verschiedene Hersteller kann abweichen. Daher ist es beim Bau solcher Fabriken theoretisch nur auf dem Papier möglich, vollständig auf vendor-lock zu verzichten.

Bei SD-Lösungen ist die Situation noch komplizierter, jeder Anbieter hat seine eigene Sichtweise. Es gibt vollständig offene Lösungen, die theoretisch individuell weiterentwickelt werden können, und es gibt vollständig geschlossene.

Cisco bietet seine SDN-Variante für Rechenzentren — ACI. Natürlich handelt es sich hierbei um eine 100 % vendor-lock Lösung hinsichtlich der Auswahl der Netzwerkhardware, aber sie lässt sich vollständig in Virtualisierungs-, Containerisierungs-, Sicherheits-, Orchestrierungs-, Lastenausgleichs- und andere Systeme integrieren. Im Grunde genommen bleibt es jedoch eine Art Black Box, ohne Möglichkeit für vollen Zugang zu allen internen Prozessen. Nicht alle Kunden stimmen einer solchen Lösung zu, da man vollständig von der Qualität des geschriebenen Codes und dessen Umsetzung abhängt. Andererseits hat der Hersteller einen der besten technischen Support-Teams der Welt und eine spezielle Mannschaft, die sich nur mit dieser Lösung beschäftigt. Für das erste Projekt wurde daher Cisco ACI gewählt.

Für das zweite Projekt wurde eine Lösung von Juniper ausgewählt. Der Hersteller hat ebenfalls sein SDN für Rechenzentren, jedoch entschied sich der Kunde gegen die Implementierung von SDN. Als Netzwerktechnologie wurde eine EVPN VXLAN-Fabrik ohne den Einsatz von zentralisierten Controllern gewählt.

Wozu benötigt man das?

Die Erstellung einer Fabrik ermöglicht einen einfach skalierbaren, ausfallsicheren und zuverlässigen Netzwerkaufbau. Die Architektur (Leaf-Spine) berücksichtigt die Besonderheiten von Rechenzentren (wie den Verkehrsfluss, Minimierung von Verzögerungen und Engpässen im Netzwerk). SD-Lösungen in Rechenzentren ermöglichen eine sehr bequeme, schnelle und flexible Verwaltung einer solchen Fabrik und deren Integration in das Ökosystem des Rechenzentrums.

Beiden Kunden war es notwendig, Backup-Rechenzentren zur Gewährleistung der Ausfallsicherheit zu errichten, zudem musste der Verkehr zwischen den Rechenzentren verschlüsselt werden.

Der erste Kunde betrachtete bereits Lösungen ohne Fabrik als potenziellen Standard für seine Netzwerke, hatte jedoch bei den Tests Probleme mit der STP-Kompatibilität zwischen mehreren Hardwareanbietern. Es traten Ausfallzeiten auf, die zu Serviceausfällen führten. Dies war für den Kunden kritisch.

Cisco war bereits der Unternehmensstandard des Kunden. Sie haben sich ACI und andere Optionen angeschaut und beschlossen, genau diese Lösung zu wählen. Die Automatisierung der Verwaltung auf Knopfdruck über einen einheitlichen Controller gefiel ihnen. Die Dienste lassen sich schneller einrichten und besser verwalten. Um die Verschlüsselung des Datenverkehrs sicherzustellen, beschlossen sie, MACSec zwischen den IPN- und SPINE-Switches zu aktivieren. So konnten sie einen Engpass durch das Kryptotunnel vermeiden und Kosten sparen, während sie die Bandbreite maximal nutzen konnten.

Der zweite Kunde wählte eine Lösung ohne Controller von Juniper, da es in ihrem bestehenden Rechenzentrum bereits eine kleine Installation mit der Umsetzung der EVPN VXLAN-Fabrik gab. Doch diese war nicht fehlertolerant (es wurde ein einzelner Switch verwendet). Man entschied sich, die Infrastruktur des Haupt-Rechenzentrums zu erweitern und eine Fabrik im Backup-Rechenzentrum zu bauen. Das vorhandene EVPN wurde nicht vollständig genutzt: Die VXLAN-Kapselung wurde faktisch nicht angewendet, da alle Hosts an einen einzigen Switch angeschlossen waren und alle MAC-Adressen und /32-Adressen der Hosts lokal waren. Der Gateway war dieser Switch, es gab keine anderen Geräte, zu denen VXLAN-Tunnel aufgebaut werden mussten. Die Verschlüsselung des Datenverkehrs sollte durch die IPSEC-Technologie zwischen den Firewalls sichergestellt werden (die Leistung der MSE war ausreichend).

Sie haben auch ACI getestet, aber entschieden, dass sie aufgrund der vendor-lokalen Anforderungen zu viel Hardware kaufen müssten, einschließlich der Ersetzung vor kurzem gekaufter neuer Geräte, und das macht einfach keinen wirtschaftlichen Sinn. Ja, die Cisco-Fabrik integriert sich mit allem, aber innerhalb der Fabrik sind nur ihre Geräte möglich.

Andererseits, wie bereits erwähnt, lässt sich eine EVPN VXLAN-Fabrik mit einem beliebigen benachbarten Anbieter nicht einfach mischen, da sich die Protokollimplementierungen unterscheiden. Es ist wie das Kreuzen von Cisco und Huawei in einem Netzwerk – die Standards scheinen zwar allgemein zu sein, aber man muss trotzdem einige Hürden überwinden. Da es sich um eine Bank handelt und die Kompatibilitätstests sehr lange dauern würden, entschlossen sie sich, besser jetzt beim gleichen Anbieter einzukaufen und sich nicht zu sehr mit Funktionalitäten außerhalb des Grundbedarfs aufzuhalten.

Migrationsplan

Zwei Rechenzentren auf Basis von ACI:

Organisation der Interaktion zwischen den Rechenzentren. Es wurde eine Multi-Pod-Lösung ausgewählt – jedes Rechenzentrum fungiert als Pod. Die Anforderungen an die Skalierung bezüglich der Anzahl der Switches und der Latenzen zwischen den Pods (RTT unter 50 ms) wurden berücksichtigt. Es wurde beschlossen, keine Multi-Site-Lösung zu implementieren, um das Management zu vereinfachen (für die Multi-Pod-Lösung wird eine einheitliche Verwaltungsoberfläche verwendet, für die Multi-Site-Lösung wären zwei Schnittstellen erforderlich gewesen oder ein Multi-Site-Orchestrator hätte benötigt werden müssen), da keine geografische Redundanz der Standorte gefordert wurde.

Im Hinblick auf die Migration der Dienste aus dem Legacy-Netzwerk wurde die transparenteste Option gewählt, die entsprechenden VLANs schrittweise zu migrieren.
Für die Migration wurde für jedes VLAN eine entsprechende EPG (End-Point-Gruppe) in der Fabrik erstellt. Zuerst wurde das Netzwerk über L2 zwischen dem alten Netzwerk und der Fabrik gespannt, danach, nach der Migration aller Hosts, wurde das Gateway in die Fabrik verschoben, und die Interaktion der EPG mit dem bestehenden Netzwerk erfolgte über L3OUT, wobei die Interaktion zwischen L3OUT und EPG mit Hilfe von Verträgen beschrieben wurde. Das schematische Beispiel:

Das schematische Diagramm der Struktur der meisten ACI-Richtlinien in der Fabrik ist im Bild unten zu sehen. Die gesamte Konfiguration basiert auf Richtlinien, die in andere Richtlinien eingebettet sind und so weiter. Zunächst ist es sehr schwierig, sich zurechtzufinden, aber im Laufe der Zeit, wie die Erfahrung zeigt, gewöhnen sich die Netzwerkadministrator:innen innerhalb von etwa einem Monat an diese Struktur, und dann wird das Verständnis, wie praktisch sie ist, allmählich klar.

Vergleich

In der Cisco ACI-Lösung müssen mehr Geräte (separate Switches für die Inter-Pod-Interaktion und APIC-Controller) angeschafft werden, was die Lösung teurer macht. Die Juniper-Lösung erforderte keine Anschaffung von Controllern und zusätzlicher Hardware; es konnte teilweise die bereits vorhandene Hardware des Kunden genutzt werden.

Hier ist die Architektur der EVPN VXLAN-Fabrik für zwei Rechenzentren des zweiten Projekts:

Bei ACI erhältst du eine fertige Lösung – kein Herumtüfteln, keine Optimierungen nötig. Bei der ersten Einführung des Kunden in die Fabrik sind keine Entwickler erforderlich, keine unterstützenden Personen für den Code und die Automatisierung. Es genügt, einfach zu betrieben, viele Einstellungen können sogar über einen Wizard vorgenommen werden, was nicht immer ein Vorteil ist, besonders für Menschen, die an die Kommandozeile gewöhnt sind. In jedem Fall braucht es Zeit, um das Denken auf neue Gleise umzustellen, um die Besonderheit der Einstellungen über Richtlinien und das Operieren mit vielen ineinander verschachtelten Richtlinien zu begreifen. Es ist sehr wünschenswert, darüber hinaus eine klare Struktur für die Benennung von Richtlinien und Objekten zu haben. Bei Problemen mit der Logik des Controllers kann die Lösung nur über den technischen Support erfolgen.

Bei EVPN – Konsole. Leidest oder freust dich. Die gewohnte Benutzeroberfläche für die alte Garde. Ja, es gibt eine Standardkonfiguration und Handbücher. Du wirst die Handbücher durchlesen müssen. Verschiedene Konstruktionen, alles klar und ausführlich.

Natürlich ist es in beiden Fällen besser, bei Migrationen zunächst die weniger kritischen Dienste, wie beispielsweise Testumgebungen, zu migrieren und erst danach, nachdem alle Bugs beseitigt wurden, zur Produktivumgebung überzugehen. Und nicht am Freitagabend konfigurieren. Es lohnt sich nicht, dem Anbieter zu glauben, dass alles gut wird; es ist immer besser, auf Nummer sicher zu gehen.

Bei ACI zahlst du mehr, obwohl Cisco derzeit aktiv diese Lösung bewirbt und oft gute Rabatte darauf anbietet, sparst du bei der Wartung – der Begleitung. Das Management und die Automatisierung von EVPN-Fabriken ohne Controller erfordern Investitionen und regelmäßige Ausgaben – Überwachung, Automatisierung, Einführung neuer Dienste. Dabei dauert der Erststart bei ACI etwa 30–40 Prozent länger. Dies geschieht, weil die gesamte Reihe der notwendigen Profile und Richtlinien, die dann verwendet werden, länger dauert. Aber mit dem Wachstum des Netzwerks verringert sich die Anzahl der benötigten Konfigurationen. Du nutzt bereits im Voraus erstellte Richtlinien, Profile und Objekte. Du kannst die Segmentierung und Sicherheit flexibel einstellen, zentral die Verträge verwalten, die für die Genehmigung bestimmter Interaktionen zwischen EPG verantwortlich sind – das Arbeitsvolumen sinkt drastisch.

Bei EVPN musst du jedes Gerät in der Fabrik konfigurieren, die Fehlerwahrscheinlichkeit ist höher.

Wenn ACI langsamer implementiert wird, hat EVPN fast doppelt so lange gebraucht, um abgestimmt zu werden. Wenn es bei Cisco immer möglich ist, einen Support-Mitarbeiter zu rufen und nach dem Netzwerk im Allgemeinen zu fragen (weil es als Lösung abgedeckt ist), kaufen Sie bei Juniper Networks nur die Hardware, und diese wird genau abgedeckt. Sind die Pakete vom Gerät weggegangen? Na gut, dann sind das Ihre Probleme. Aber Sie können eine Frage zur Auswahl der Lösung oder zum Netzwerkdesign aufwerfen – und dann wird empfohlen, einen professionellen Service zu erwerben, gegen Aufpreis.

Die Unterstützung für ACI ist sehr gut, weil sie separat ist: Ein separates Team ist nur dafür zuständig. Es gibt auch russischsprachige Spezialisten. Der Leitfaden ist detailliert, die Lösungen sind vordefiniert. Man schaut und gibt Ratschläge. Design wird schnell validiert, was oft wichtig ist. Juniper Networks macht das Gleiche, aber deutlich langsamer (bei uns war es so, jetzt soll es sich Gerüchten zufolge verbessert haben), was Sie dazu zwingt, alles selbst zu erledigen, wo Sie einen Solutions Engineer konsultieren könnten.

Cisco ACI unterstützt die Integration mit Virtualisierungs- und Containerisierungssystemen (VMware, Kubernetes, Hyper-V) und zentralisiertes Management. Es gibt auch Netzwerkdienste und Sicherheitsdienste – Lastverteilung, Firewalls, WAF, IPS und mehr... Gute Mikrosementierung out of the box. Bei der zweiten Lösung erfolgt die Integration mit Netzwerkdiensten eher mühsam, daher empfiehlt es sich, vorher in Foren mit denen zu stöbern, die das bereits gemacht haben.

Fazit

Für jeden spezifischen Fall muss eine Lösung gewählt werden, nicht nur unter dem Gesichtspunkt der Anschaffungskosten, sondern auch die zukünftigen Betriebskosten und die Hauptprobleme, mit denen der Kunde derzeit konfrontiert ist, müssen berücksichtigt werden sowie die Pläne zur Weiterentwicklung der IT-Infrastruktur.

ACI ist aufgrund von zusätzlicher Hardware teurer, bietet aber eine fertige Lösung ohne Notwendigkeit der Nachbearbeitung. Die zweite Lösung ist hinsichtlich der Betriebskosten komplizierter und teurer, aber günstiger.

Wenn Sie diskutieren möchten, wie viel die Implementierung einer Netzwerkfabrik bei verschiedenen Anbietern kosten könnte und welche Architektur benötigt wird, können wir uns treffen und sprechen. Bis zu einem groben Architekturentwurf (mit dem Budgets erstellt werden können) geben wir gerne kostenlos Auskunft, die detaillierte Ausarbeitung ist natürlich kostenpflichtig.