Bewerten Sie die Verbindungen in der Mitte des Schemas. Darauf werden wir gleich zurückkommen.
Irgendwann könnten Sie feststellen, dass große komplexe Layer-2-Netzwerke unheilbar krank sind. Zuerst aufgrund von Problemen mit der Verarbeitung von BUM-Verkehr und dem Betrieb des STP-Protokolls. Zweitens wegen einer generell veralteten Architektur. Dies führt zu unangenehmen Problemen wie Ausfallzeiten und erschwertem Management.
Wir hatten zwei parallele Projekte, in denen die Auftraggeber nüchtern alle Vor- und Nachteile der Optionen abwogen und zwei verschiedene Overlay-Lösungen wählten, die wir dann 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 Netzfabrik mit überlagerten Netzwerken und SDN?
Was tun mit den drängenden Problemen der klassischen Netzwerkarchitektur?
Jedes Jahr entstehen neue Technologien und Ideen. In der Praxis war die dringende Notwendigkeit, Netzwerke umzugestalten, lange Zeit nicht vorhanden, da vieles immer noch händisch nach alten, bewährten Methoden erledigt werden kann. Was macht es schon, dass wir im 21. Jahrhundert leben? Letztendlich sollte der Administrator arbeiten und nicht nur in seinem Büro sitzen.
Dann begann der Boom beim Bau großer Rechenzentren. Zu diesem Zeitpunkt wurde klar, dass die Grenzen der klassischen Architektur sowohl in Bezug auf Funktionsfähigkeit, Fehlertoleranz als auch Skalierbarkeit erreicht waren. Eine der Lösungen für diese Herausforderungen war die Idee, über einem routierbaren Backbone überlagerte Netzwerke aufzubauen.
Darüber hinaus stellte sich mit der Ausweitung der Netzwerke das akute Problem des Managements solcher Fabriken, was zur Entstehung von Lösungen für softwaredefinierte Netzwerke führte, die es ermöglichen, die gesamte Netzwerk-Infrastruktur als ein einziges Ganzes zu steuern. Wenn das Netzwerk von einem einzigen Punkt aus verwaltet wird, ist es einfacher für andere Komponenten der IT-Infrastruktur, mit ihm zu interagieren, und solche Interaktionsprozesse lassen sich einfacher automatisieren.
Fast jeder große Hersteller von Netzwerk- und Virtualisierungsausrüstung hat in seinem Portfolio Optionen für solche Lösungen.
Es bleibt nur noch zu klären, was für welche Bedürfnisse geeignet ist. Zum Beispiel benötigen besonders große Unternehmen mit einem kompetenten Entwicklungsteam nicht immer die Standardlösungen der Anbieter, um alle Anforderungen zu erfüllen, und greifen daher auf die Entwicklung eigener SD (software defined) Lösungen zurück. Dazu gehören beispielsweise Cloud-Anbieter, die ständig ihr Serviceangebot für ihre Kunden erweitern, und Standardlösungen können einfach nicht mit ihren Bedürfnissen Schritt halten.
Für mittelständische Unternehmen reicht in 99 Prozent der Fälle die Funktionalität, die der Anbieter in Form einer Standardlösung anbietet.
Was sind Overlay-Netzwerke?
Die Idee der Overlay-Netze besteht darin, dass Sie ein klassisches routierbares Netzwerk nehmen und darüber ein weiteres Netzwerk aufbauen, um zusätzliche Funktionen zu erhalten. Es geht dabei häufig um eine effiziente Lastverteilung auf die Hardware und Kommunikationslinien, eine signifikante Erhöhung der Skalierbarkeit, die Verbesserung der Zuverlässigkeit und eine Vielzahl von Sicherheitsvorteilen durch Segmentierung. Zudem ermöglichen SDN-Lösungen eine sehr, sehr, sehr flexible Verwaltung und machen das Netzwerk transparenter für die Nutzer.
Wenn man lokale Netzwerke in den 2010er Jahren erfunden hätte, würden sie ganz anders aussehen als das Erbe, das wir von den Militärs der 1970er Jahre übernommen haben.
Aus der Perspektive der Technologie zur Erstellung von Fabriken mit Overlay-Netzen gibt es derzeit zahlreiche Implementierungen von Herstellern und Internet-Projekten (RFC) wie EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve und anderen. Ja, es gibt Standards, aber die Umsetzung dieser Standards kann von den verschiedenen Herstellern abweichen. Daher ist es in der Praxis nur theoretisch möglich, bei der Schaffung solcher Fabriken vollständig auf vendor-lock zu verzichten.
Mit SD-Lösungen gestaltet sich die Situation noch komplizierter, da jeder Anbieter seine eigene Sichtweise hat. Es gibt vollkommen offene Lösungen, die theoretisch individuell angepasst werden können, und vollkommen geschlossene Lösungen.
Cisco bietet seine eigene SDN-Lösung für Rechenzentren — ACI. Natürlich ist dies eine 100 % vendor-lock Lösung in Bezug auf die Auswahl der Netzwerkausrüstung, aber sie integriert sich vollständig mit Virtualisierungs-, Containerisierungs-, Sicherheits-, Orchestrierungs- und Lastverteilungssystemen. Es bleibt jedoch im Grunde ein Black Box, ohne dass vollständiger Zugang zu allen internen Prozessen möglich ist. Nicht alle Kunden sind mit dieser Lösung einverstanden, da man vollständig von der Qualität des geschriebenen Codes und seiner Implementierung abhängt. Auf der anderen Seite bietet der Hersteller einen der besten technischen Supportservices weltweit und hat ein spezialisiertes Team, das sich ausschließlich mit dieser Lösung beschäftigt. Für das erste Projekt wurde daher genau Cisco ACI ausgewählt.
Für das zweite Projekt wurde eine Lösung von Juniper ausgewählt. Der Hersteller verfügt auch über sein eigenes SDN für Rechenzentren, jedoch entschied sich der Auftraggeber gegen die Implementierung von SDN. Als Netzwerktechnologie wurde eine EVPN VXLAN-Fabrik ohne Verwendung zentralisierter Controller gewählt.
Wozu ist das notwendig?
Die Erstellung einer Fabrik ermöglicht den Aufbau eines einfach skalierbaren, fehlertoleranten und zuverlässigen Netzwerks. Die Architektur (Leaf-Spine) berücksichtigt die Besonderheiten Rechenzentren (Verlauf des Datenverkehrs, Minimierung der Latenzzeiten und Engpässe im Netzwerk). SD-Lösungen in Rechenzentren ermöglichen eine sehr bequeme, schnelle und flexible Verwaltung einer solchen Fabrik und deren Integration in das Rechenzentrums-Ökosystem.
Beiden Auftraggebern war es wichtig, Backup-Rechenzentren zur Gewährleistung der Ausfallsicherheit aufzubauen. Darüber hinaus musste der Datenverkehr zwischen den Rechenzentren verschlüsselt werden.
Der erste Auftraggeber hatte bereits Lösungen ohne Fabrik als möglichen Standard für seine Netzwerke in Betracht gezogen, hatte jedoch bei Tests Probleme mit der STP-Kompatibilität zwischen mehreren Hardware-Anbietern. Es kam zu Ausfallzeiten, die Serviceausfälle zur Folge hatten, was für den Auftraggeber kritisch war.
Cisco war bereits der Unternehmensstandard des Kunden, der sich ACI und andere Optionen angesehen hat und beschlossen hat, genau diese Lösung zu wählen. Die Automatisierung der Verwaltung mit einem einzigen Schalter über einen zentralen Controller gefiel ihnen. Die Dienste lassen sich schneller einrichten und verwalten. Um den Datenverkehr zu verschlüsseln, wurde MACSec zwischen den IPN- und SPINE-Switches implementiert. So konnte ein Engpass durch einen Kryptogateway vermieden und Kosten gespart werden, während die Bandbreite optimal genutzt wird.
Der zweite Kunde wählte eine Lösung ohne Controller von Juniper, da in ihrem bestehenden Rechenzentrum bereits eine kleine Installation mit der Implementierung einer EVPN VXLAN-Fabrik vorhanden war. Diese war jedoch nicht ausfallsicher (es wurde ein einzelner Switch verwendet). Sie entschieden, die Infrastruktur des Haupt-Rechenzentrums zu erweitern und eine Fabrik im Backup-Rechenzentrum aufzubauen. Das vorhandene EVPN wurde nicht vollständig genutzt: Die VXLAN-Kapselung kam faktisch nicht zur Anwendung, da alle Hosts an einen Switch angeschlossen waren und alle MAC-Adressen und /32-Adressen der Hosts lokal waren, wobei dieser Switch als Gateway diente, ohne andere Geräte, für die VXLAN-Tunnel aufgebaut werden mussten. Die Verschlüsselung des Traffics beschlossen sie mit IPSEC-Technologie zwischen den Firewalls sicherzustellen (die Leistung des MSE war ausreichend).
Auch ACI haben wir betrachtet, beschlossen jedoch, dass aufgrund der Vendor-LOCK-IN zu viel Hardware angeschafft werden müsste, einschließlich des Austauschs kürzlich erworbener neuer Geräte, was einfach keinen wirtschaftlichen Sinn ergibt. Ja, die Cisco-Fabrik integriert sich in alles, aber innerhalb der Fabrik sind nur ihre eigenen Geräte möglich.
Auf der anderen Seite lässt sich, wie bereits erwähnt, eine EVPN VXLAN Fabrik nicht einfach mit einem beliebigen benachbarten Anbieter mischen, da die Implementierungen des Protokolls unterschiedlich sind. Das ist wie das Mischen von Cisco und Huawei in einem Netzwerk – die Standards sind zwar allgemein, aber man muss sich anstrengen. Da es sich um eine Bank handelt und die Kompatibilitätstests sehr lange dauern würden, wurde entschieden, besser jetzt bei demselben Anbieter einzukaufen und sich nicht allzu sehr mit Funktionalitäten jenseits des Grundbedarfs zu beschäftigen.
Migrationsplan
Zwei Rechenzentren auf Basis von ACI:
Organisation der Interaktion zwischen den Rechenzentren. Eine Multi-Pod-Lösung wurde gewählt – jedes Rechenzentrum fungiert als Pod. Es wurden Anforderungen an die Skalierung der Anzahl der Switches und an die Latenzen zwischen den Pods berücksichtigt (RTT unter 50 ms). Es wurde beschlossen, keine Multi-Site-Lösung für eine bessere Verwaltungsfreundlichkeit zu erstellen (für die Multi-Pod-Lösung wird eine einheitliche Verwaltungsschnittstelle verwendet, während für eine Multi-Site-Lösung zwei Schnittstellen notwendig wären oder ein Multi-Site Orchestrator benötigt würde), zudem war kein geografisches Redundanzkonzept erforderlich.
Hinsichtlich der Migration von Services aus dem Legacy-Netzwerk wurde die transparenteste Option gewählt: die schrittweise Übertragung von VLANs, die bestimmten Services zugeordnet sind.
Für die Migration wurde für jedes VLAN eine entsprechende EPG (End-Point-Group) in der Fabrik erstellt. Zunächst wurde das Netzwerk zwischen dem alten Netzwerk und der Fabrik über L2 herstellt, und nachdem alle Hosts migriert waren, wurde das Gateway in die Fabrik verschoben, wobei die Interaktion der EPG mit dem bestehenden Netzwerk über L3OUT erfolgte. Die Interaktion zwischen L3OUT und EPG wurde dabei durch Verträge beschrieben. Ein schematisches Beispiel:
Die ungefähre Struktur der meisten ACI-Fabrikpolitiken ist in der Abbildung unten dargestellt. Sämtliche Konfigurationen basieren auf Politiken, die in andere Politiken verschachtelt sind, und so weiter. Anfänglich ist es sehr kompliziert, das zu verstehen, aber allmählich, wie die Praxis zeigt, gewöhnen sich Netzwerkadministratoren innerhalb von etwa einem Monat an diese Struktur, und erst dann wird das Verständnis für ihre Benutzerfreundlichkeit klar.
Der Vergleich
In der Cisco ACI-Lösung muss mehr Hardware gekauft werden (separate Switches für die Inter-Pod-Interaktion und APIC-Controller), was sie teurer macht. Die Juniper-Lösung erforderte keinen Kauf von Controllern und unterstützender Hardware; es konnte teilweise vorhandene Hardware des Kunden verwendet werden.
Hier ist die Architektur von EVPN VXLAN in der Fabrik für zwei Rechenzentren des zweiten Projekts:
Mit ACI erhältst du eine fertige Lösung – kein Herumexperimentieren, keine Optimierung nötig. Bei der ersten Vorstellung des Systems für den Kunden sind keine Entwickler und keine unterstützenden Personen für den Code und die Automatisierung erforderlich. Die Nutzung allein ist ausreichend, viele Einstellungen können sogar über einen Assistenten vorgenommen werden, was nicht immer ein Vorteil ist, besonders für diejenigen, die die Kommandozeile gewöhnt sind. In jedem Fall braucht man Zeit, um den Kopf auf die neuen Abläufe umzustellen, auf die Besonderheiten der Einstellungen über Richtlinien und das Management einer Vielzahl von ineinander verschachtelten Richtlinien. Es ist zudem sehr wünschenswert, eine klare Struktur für die Benennung von Richtlinien und Objekten zu haben. Bei Problemen in der Logik des Controllers kann die Lösung nur über den technischen Support erfolgen.
In EVPN – die Konsole. Leid oder Freude. Gewohnte Benutzeroberfläche für die alte Garde. Ja, es gibt eine Standardkonfiguration und Anleitungen. Du wirst die Handbücher durchforsten müssen. Unterschiedliche Konstrukte, alles klar und detailliert.
Natürlich ist es in beiden Fällen besser, bei der Migration zunächst die weniger kritischen Dienste wie Testumgebungen zu migrieren. Erst nachdem alle Bugs behoben sind, sollte man mit der Produktion beginnen. Und vermeide es, am Freitagabend zu konfigurieren. Vertraue dem Anbieter nicht, dass alles gut geht — es ist immer besser, auf Nummer sicher zu gehen.
Bei ACI zahlst du mehr, obwohl Cisco derzeit aktiv diese Lösung fördert und häufig gute Rabatte darauf bietet. Allerdings sparst du bei der Wartung und Betreuung. Das Management und die Automatisierung der EVPN-Fabrik ohne Controller erfordern Investitionen und regelmäßige Ausgaben – Monitoring, Automatisierung und die Einführung neuer Dienste. Zudem dauert der erste Start bei ACI etwa 30–40 Prozent länger. Dies liegt daran, dass das gesamte Set an erforderlichen Profilen und Richtlinien, die anschließend verwendet werden, länger erstellt wird. Mit dem Wachstum des Netzwerks verringert sich jedoch die Anzahl der benötigten Konfigurationen. Du kannst bereits im Voraus erstellte Richtlinien, Profile und Objekte verwenden. Du kannst die Segmentierung und Sicherheit flexibel anpassen und zentral Verträge verwalten, die für die Genehmigung bestimmter Interaktionen zwischen EPG verantwortlich sind – der Arbeitsaufwand sinkt erheblich.
In EVPN muss jedes Gerät in der Fabrik konfiguriert werden, was die Fehlerwahrscheinlichkeit erhöht.
Wenn ACI langsamer implementiert wird, dauerte die Anpassung von EVPN fast doppelt so lange. Bei Cisco kann man immer einen Support-Ingenieur fragen und allgemeine Fragen zum Netzwerk stellen (weil es als gesamte Lösung abgedeckt ist), während Sie bei Juniper Networks nur die Hardware kaufen und nur diese abgedeckt ist. Sind Pakete vom Gerät weggegangen? Na gut, das ist dann Ihr Problem. Aber Sie können eine Anfrage zur Lösung oder zum Netzwerkdesign öffnen – und dann wird empfohlen, einen professionellen Service zu erwerben, gegen Aufpreis.
Der ACI-Support ist großartig, weil er separat ist: Ein eigenes Team arbeitet ausschließlich dafür. Es gibt auch russischsprachige Spezialisten. Die Anleitung ist detailliert, die Lösungen sind vorgegeben. Sie schauen und empfehlen. Das Design wird schnell validiert, was oft wichtig ist. Juniper Networks macht das Gleiche, aber deutlich langsamer (so war es bei uns, jetzt soll es laut Gerüchten besser sein), was dazu führt, dass man selbst alles machen muss, wo man einen Solution Engineer hätte um Rat fragen können.
Cisco ACI unterstützt die Integration mit Virtualisierungs- und Containerisierungssystemen (VMware, Kubernetes, Hyper-V) sowie eine zentrale Verwaltung. Es gibt Netzwerkausgaben und Sicherheitsdienste — Lastverteilung, Firewalls, WAF, IPS und mehr... Eine gute Mikrosementierung ist bereits enthalten. Bei der zweiten Lösung wird die Integration mit Netzwerkdiensten komplizierter, und es ist besser, im Voraus Foren zu konsultieren, wo andere ähnliche Erfahrungen geteilt haben.
Zusammenfassung
Für jeden spezifischen Fall ist es notwendig, eine Lösung auszuwählen, die nicht nur auf den Kosten der Hardware beruht, sondern auch die zukünftigen Betriebskosten und die aktuellen Probleme des Kunden berücksichtigt, sowie die Pläne für die Weiterentwicklung der IT-Infrastruktur.
ACI ist aufgrund der zusätzlichen Hardware teurer, bietet aber eine schlüsselfertige Lösung ohne Anpassungsbedarf. Die zweite Lösung ist komplexer und kostspieliger in der Nutzung, jedoch günstiger.
Wenn Sie darüber sprechen möchten, wie viel die Implementierung einer Netzwerkfabrik bei verschiedenen Anbietern kosten könnte und welche Architektur erforderlich ist, können wir uns treffen und darüber sprechen. Bis zu einem groben Entwurf der Architektur (mit dem Sie Budgets schätzen können) geben wir Ihnen kostenlos Hinweise, die detaillierte Ausarbeitung ist natürlich kostenpflichtig.
Wladimir Kleptsche, Unternehmensnetzwerke.
Quelle: habr.com
