Bewerten Sie die Verbindungen im mittleren Teil des Diagramms. Wir werden im Folgenden darauf zurückkommen
Irgendwann werden Sie vielleicht feststellen, dass große, komplexe L2-basierte Netzwerke unheilbar krank sind. Zunächst einmal Probleme im Zusammenhang mit der Verarbeitung des BUM-Verkehrs und dem Betrieb des STP-Protokolls. Zweitens ist die Architektur im Allgemeinen veraltet. Dies führt zu unangenehmen Problemen in Form von Ausfallzeiten und umständlicher Handhabung.
Wir hatten zwei parallele Projekte, bei denen die Kunden alle Vor- und Nachteile der Optionen nüchtern abwägten und sich für zwei unterschiedliche Overlay-Lösungen entschieden und diese umgesetzt haben.
Es bestand die Möglichkeit, die Umsetzung zu vergleichen. Nicht Ausbeutung; wir sollten in zwei oder drei Jahren darüber reden.
Was ist also eine Netzwerkstruktur mit Overlay-Netzwerken und SDN?
Was tun mit den drängenden Problemen der klassischen Netzwerkarchitektur?
Jedes Jahr tauchen neue Technologien und Ideen auf. In der Praxis bestand die dringende Notwendigkeit, Netzwerke neu aufzubauen, noch lange nicht, da alles auch manuell mit den guten alten Methoden erledigt werden kann. Was also, wenn es das XNUMX. Jahrhundert ist? Schließlich soll ein Administrator arbeiten und nicht in seinem Büro sitzen.
Dann begann ein Boom beim Bau großer Rechenzentren. Dann wurde klar, dass die Entwicklungsgrenze der klassischen Architektur erreicht war, nicht nur hinsichtlich Leistung, Fehlertoleranz und Skalierbarkeit. Und eine der Möglichkeiten zur Lösung dieser Probleme war die Idee, Overlay-Netzwerke auf einem gerouteten Backbone aufzubauen.
Darüber hinaus ist mit der Vergrößerung der Netzwerke das Problem der Verwaltung solcher Fabriken akut geworden, was dazu führte, dass softwaredefinierte Netzwerklösungen aufkamen, die die gesamte Netzwerkinfrastruktur als Ganzes verwalten konnten. 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 solche Interaktionsprozesse lassen sich leichter automatisieren.
Fast jeder große Hersteller nicht nur von Netzwerkgeräten, sondern auch von Virtualisierung hat Optionen für solche Lösungen in seinem Portfolio.
Es bleibt nur noch herauszufinden, was für welche Bedürfnisse geeignet ist. Beispielsweise erfüllen besonders große Unternehmen mit einem guten Entwicklungs- und Betriebsteam nicht immer die Paketlösungen von Anbietern, die alle Anforderungen erfüllen, und sie greifen auf die Entwicklung eigener SD-Lösungen (Software Defined) zurück. Dabei handelt es sich beispielsweise um Cloud-Anbieter, die das Dienstleistungsangebot für ihre Kunden ständig erweitern und deren Bedürfnisse mit Paketlösungen einfach nicht mithalten können.
Für mittelständische Unternehmen reicht die vom Anbieter angebotene Funktionalität in Form einer Boxed-Lösung in 99 Prozent der Fälle aus.
Was sind Overlay-Netzwerke?
Was ist die Idee hinter Overlay-Netzwerken? Im Wesentlichen nehmen Sie ein klassisches geroutetes Netzwerk und bauen darauf ein weiteres Netzwerk auf, um mehr Funktionen zu erhalten. Am häufigsten geht es um eine effektive Lastverteilung auf Geräte und Kommunikationsleitungen, eine deutliche Erhöhung der Skalierbarkeitsgrenze, eine Erhöhung der Zuverlässigkeit und eine Reihe von Sicherheitsvorteilen (aufgrund der Segmentierung). Darüber hinaus bieten SDN-Lösungen die Möglichkeit einer sehr, sehr, sehr komfortablen, flexiblen Verwaltung und machen das Netzwerk für seine Verbraucher transparenter.
Wenn lokale Netzwerke in den 2010er Jahren erfunden worden wären, hätten sie im Allgemeinen ganz anders ausgesehen als das, was wir in den 1970er Jahren vom Militär geerbt haben.
In Bezug auf Technologien zum Aufbau von Fabrics mithilfe von Overlay-Netzwerken gibt es derzeit viele Anbieterimplementierungen und Internet-RFC-Projekte (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve und andere). Ja, es gibt Standards, aber die Umsetzung dieser Standards durch verschiedene Hersteller kann unterschiedlich sein, so dass es beim Aufbau solcher Fabriken immer noch möglich ist, die Lieferantensperre nur theoretisch auf dem Papier vollständig aufzugeben.
Bei einer SD-Lösung ist die Sache noch verwirrender: Jeder Anbieter hat seine eigene Vision. Es gibt völlig offene Lösungen, die man theoretisch selbst vervollständigen kann, und es gibt völlig geschlossene Lösungen.
Cisco bietet seine Version von SDN für Rechenzentren an – ACI. Natürlich ist dies eine zu 100 % herstellergebundene Lösung hinsichtlich der Auswahl der Netzwerkausrüstung, aber gleichzeitig ist sie vollständig in Virtualisierungssysteme, Containerisierung, Sicherheit, Orchestrierung, Load Balancer usw. integriert. Aber im Wesentlichen ist es immer noch eine Eine Art Blackbox, ohne die Möglichkeit des vollständigen Zugriffs auf alle internen Prozesse. Nicht alle Kunden stimmen dieser Option zu, da Sie vollständig von der Qualität des geschriebenen Lösungscodes und seiner Implementierung abhängig sind. Andererseits verfügt der Hersteller über einen der besten technischen Support weltweit und verfügt nur über ein engagiertes Team zu dieser Lösung. Als Lösung für das erste Projekt wurde Cisco ACI ausgewählt.
Für das zweite Projekt wurde eine Juniper-Lösung ausgewählt. Der Hersteller verfügt auch über ein eigenes SDN für das Rechenzentrum, der Kunde hat sich jedoch gegen die Implementierung von SDN entschieden. Als Netzwerkaufbautechnologie wurde eine EVPN-VXLAN-Fabric ohne den Einsatz zentraler Controller gewählt.
Wofür ist das
Durch die Einrichtung einer Fabrik können Sie ein einfach skalierbares, fehlertolerantes und zuverlässiges Netzwerk aufbauen. Die Architektur (Leaf-Spine) berücksichtigt die Eigenschaften von Rechenzentren (Verkehrswege, Minimierung von Verzögerungen und Engpässen im Netzwerk). Mit SD-Lösungen in Rechenzentren können Sie eine solche Fabrik sehr komfortabel, schnell und flexibel verwalten und in das Ökosystem des Rechenzentrums integrieren.
Beide Kunden mussten redundante Rechenzentren aufbauen, um Fehlertoleranz zu gewährleisten, außerdem musste der Datenverkehr zwischen den Rechenzentren verschlüsselt werden.
Der erste Kunde dachte bereits über Fabricless-Lösungen als möglichen Standard für seine Netzwerke nach, hatte jedoch in Tests Probleme mit der STP-Kompatibilität zwischen mehreren Hardware-Anbietern. Es kam zu Ausfallzeiten, die zum Absturz von Diensten führten. Und für den Kunden war dies von entscheidender Bedeutung.
Da Cisco bereits der Unternehmensstandard des Kunden war, schauten sie sich ACI und andere Optionen an und kamen zu dem Schluss, dass es sich lohnte, diese Lösung zu wählen. Mir gefiel die Automatisierung der Steuerung per Knopfdruck über einen einzigen Controller. Dienste werden schneller konfiguriert und schneller verwaltet. Wir haben uns entschieden, die Verkehrsverschlüsselung sicherzustellen, indem wir MACSec zwischen den IPN- und SPINE-Switches ausführen. So ist es uns gelungen, den Engpass in Form eines Krypto-Gateways zu umgehen, diese einzusparen und die maximale Bandbreite zu nutzen.
Der zweite Kunde entschied sich für eine Controller-lose Lösung von Juniper, da sein bestehendes Rechenzentrum bereits über eine kleine Installation verfügte, die eine EVPN-VXLAN-Fabric implementierte. Dort war es aber nicht fehlertolerant (ein Switch wurde verwendet). Wir haben beschlossen, die Infrastruktur des Hauptrechenzentrums zu erweitern und im Backup-Rechenzentrum eine Fabrik zu errichten. Das vorhandene EVPN wurde nicht vollständig genutzt: Die VXLAN-Kapselung wurde eigentlich nicht genutzt, da alle Hosts mit einem Switch verbunden waren und alle MAC-Adressen und /32-Hostadressen lokal waren, das Gateway für sie derselbe Switch war und es keine anderen Geräte gab , wo es notwendig war, VXLAN-Tunnel zu bauen. Sie beschlossen, die Verkehrsverschlüsselung mithilfe der IPSEC-Technologie zwischen Firewalls sicherzustellen (die Leistung der Firewall war ausreichend).
Sie versuchten es auch mit ACI, kamen aber zu dem Schluss, dass sie aufgrund der Herstellersperre zu viel Hardware kaufen müssten, einschließlich des Austauschs kürzlich gekaufter neuer Geräte, und dass dies wirtschaftlich einfach keinen Sinn machte. Ja, die Cisco-Fabric lässt sich in alles integrieren, aber innerhalb der Fabric selbst sind nur ihre Geräte möglich.
Andererseits können Sie, wie bereits erwähnt, eine EVPN-VXLAN-Struktur nicht einfach mit einem benachbarten Anbieter kombinieren, da die Protokollimplementierungen unterschiedlich sind. Es ist, als würde man Cisco und Huawei in einem Netzwerk kreuzen – die Standards scheinen gleich zu sein, aber man muss mit dem Tamburin tanzen. Da es sich um eine Bank handelt und Kompatibilitätstests sehr langwierig sein würden, haben wir beschlossen, dass es besser ist, jetzt beim selben Anbieter zu kaufen und uns nicht zu sehr mit Funktionen über die Basisfunktionen hinaus zu befassen.
Migrationsplan
Zwei ACI-basierte Rechenzentren:
Organisation der Interaktion zwischen Rechenzentren. Die Wahl fiel auf die Multi-Pod-Lösung – jedes Rechenzentrum ist ein Pod. Dabei werden die Anforderungen an die Skalierung nach Anzahl der Switches und Verzögerungen zwischen Pods (RTT kleiner 50 ms) berücksichtigt. Es wurde beschlossen, keine Multi-Site-Lösung zu erstellen, um die Verwaltung zu vereinfachen (eine Multi-Pod-Lösung verwendet eine einzige Verwaltungsschnittstelle, eine Multi-Site hätte zwei Schnittstellen oder würde einen Multi-Site-Orchestrator erfordern) und da kein geografischer Standort vorhanden ist Eine Reservierung von Stellplätzen war erforderlich.
Im Hinblick auf die Migration von Diensten aus dem Legacy-Netzwerk wurde die transparenteste Option gewählt, nämlich die schrittweise Übertragung von VLANs, die bestimmten Diensten entsprechen.
Für die Migration wurde werksseitig für jedes VLAN eine entsprechende EPG (Endpoint-Gruppe) erstellt. Zuerst wurde das Netzwerk zwischen dem alten Netzwerk und der Fabric über L2 gestreckt, dann wurde nach der Migration aller Hosts das Gateway auf die Fabric verschoben und der EPG interagierte mit dem bestehenden Netzwerk über L3OUT, während die Interaktion zwischen L3OUT und EPG wurde anhand von Verträgen beschrieben. Ungefähres Diagramm:
Eine Beispielstruktur der meisten ACI-Fabrikrichtlinien ist in der folgenden Abbildung dargestellt. Das gesamte Setup basiert auf Richtlinien, die in anderen Richtlinien usw. verschachtelt sind. Zunächst ist es sehr schwierig, es herauszufinden, aber wie die Praxis zeigt, gewöhnen sich Netzwerkadministratoren nach etwa einem Monat nach und nach an diese Struktur und beginnen dann erst zu verstehen, wie praktisch sie ist.
Vergleich
Bei der Cisco ACI-Lösung müssen Sie mehr Ausrüstung kaufen (separate Switches für die Inter-Pod-Interaktion und APIC-Controller), was sie teurer macht. Die Lösung von Juniper erforderte keinen Kauf von Controllern oder Zubehör; Es war möglich, die vorhandene Ausrüstung des Kunden teilweise zu nutzen.
Hier ist die EVPN-VXLAN-Fabric-Architektur für zwei Rechenzentren des zweiten Projekts:
Mit ACI erhalten Sie eine fertige Lösung – kein Tüfteln, kein Optimierungsbedarf. Während der ersten Bekanntschaft des Kunden mit der Fabrik sind keine Entwickler erforderlich, es werden keine unterstützenden Personen für Code und Automatisierung benötigt. Die Bedienung ist recht einfach; viele Einstellungen können über den Assistenten vorgenommen werden, was insbesondere für Leute, die mit der Befehlszeile vertraut sind, nicht immer ein Pluspunkt ist. In jedem Fall braucht es Zeit, das Gehirn auf neue Spuren zu bringen, sich an die Besonderheiten der Einstellungen durch Richtlinien und das Arbeiten mit vielen verschachtelten Richtlinien anzupassen. Darüber hinaus ist eine klare Struktur zur Benennung von Richtlinien und Objekten äußerst wünschenswert. Sollte ein Problem in der Logik des Controllers auftreten, kann es nur durch technischen Support gelöst werden.
In der EVPN-Konsole. Leiden oder sich freuen. Eine vertraute Schnittstelle für die alte Garde. Ja, es gibt eine Standardkonfiguration und Anleitungen. Du musst Mana rauchen. Verschiedene Designs, alles ist klar und detailliert.
Natürlich ist es in beiden Fällen bei der Migration besser, zunächst nicht die kritischsten Dienste, beispielsweise Testumgebungen, zu migrieren und erst dann, nachdem alle Fehler behoben wurden, mit der Produktion fortzufahren. Und schalten Sie am Freitagabend nicht ein. Sie sollten dem Anbieter nicht vertrauen, dass alles in Ordnung sein wird, es ist immer besser, auf Nummer sicher zu gehen.
Sie zahlen mehr für ACI, obwohl Cisco diese Lösung derzeit aktiv bewirbt und häufig gute Rabatte darauf gewährt, sparen Sie jedoch bei der Wartung. Die Verwaltung und jegliche Automatisierung einer EVPN-Fabrik ohne Controller erfordert Investitionen und regelmäßige Kosten – Überwachung, Automatisierung, Implementierung neuer Dienste. Gleichzeitig dauert der Erststart bei ACI 30–40 Prozent länger. Dies liegt daran, dass die Erstellung aller erforderlichen Profile und Richtlinien, die dann verwendet werden, länger dauert. Wenn das Netzwerk jedoch wächst, nimmt die Anzahl der erforderlichen Konfigurationen ab. Sie verwenden vorgefertigte Richtlinien, Profile und Objekte. Sie können Segmentierung und Sicherheit flexibel konfigurieren, Verträge zentral verwalten, die dafür verantwortlich sind, bestimmte Interaktionen zwischen EPGs zu ermöglichen – der Arbeitsaufwand sinkt stark.
Bei EVPN müssen Sie jedes Gerät im Werk konfigurieren, die Wahrscheinlichkeit von Fehlern ist höher.
Während die Implementierung von ACI langsamer war, dauerte das Debuggen von EVPN fast doppelt so lange. Wenn Sie im Fall von Cisco jederzeit einen Supporttechniker anrufen und nach dem Netzwerk als Ganzes fragen können (weil es als Lösung abgedeckt ist), kaufen Sie bei Juniper Networks nur Hardware, und diese ist abgedeckt. Haben die Pakete das Gerät verlassen? Na gut, dann deine Probleme. Sie können jedoch eine Frage zur Wahl der Lösung oder zum Netzwerkdesign stellen – und dann wird Ihnen empfohlen, gegen eine zusätzliche Gebühr einen professionellen Service zu erwerben.
Der ACI-Support ist sehr cool, weil er separat ist: Ein separates Team sitzt nur dafür. Es gibt auch russischsprachige Spezialisten. Die Anleitung ist detailliert, die Lösungen sind vorgegeben. Sie schauen und beraten. Sie validieren das Design schnell, was oft wichtig ist. Juniper Networks macht das Gleiche, aber viel langsamer (das hatten wir, Gerüchten zufolge soll es jetzt besser sein), was Sie dazu zwingt, alles selbst zu tun, wo ein Lösungsingenieur Ihnen raten kann.
Cisco ACI unterstützt die Integration mit Virtualisierungs- und Containerisierungssystemen (VMware, Kubernetes, Hyper-V) und die zentrale Verwaltung. Verfügbar mit Netzwerk- und Sicherheitsdiensten – Balancing, Firewalls, WAF, IPS usw. Gute Mikrosegmentierung sofort einsatzbereit. Bei der zweiten Lösung ist die Integration mit Netzwerkdiensten ein Kinderspiel, und es ist besser, die Foren im Voraus mit denjenigen zu besprechen, die dies getan haben.
Ergebnis
Für jeden Einzelfall ist es notwendig, eine Lösung auszuwählen, die nicht nur auf den Kosten der Ausrüstung basiert, sondern auch die weiteren Betriebskosten und die Hauptprobleme berücksichtigt, mit denen der Kunde derzeit konfrontiert ist, und welche Pläne er dort hat sind für den Aufbau der IT-Infrastruktur vorgesehen.
ACI war aufgrund der zusätzlichen Ausrüstung teurer, aber die Lösung ist fertig, ohne dass eine zusätzliche Nachbearbeitung erforderlich ist; die zweite Lösung ist komplexer und kostspieliger im Betrieb, aber billiger.
Wenn Sie besprechen möchten, wie viel die Implementierung einer Netzwerkstruktur bei verschiedenen Anbietern kosten könnte und welche Art von Architektur erforderlich ist, können Sie sich treffen und unterhalten. Wir beraten Sie kostenlos, bis Sie eine grobe Architekturskizze erhalten (mit der Sie Budgets kalkulieren können), detaillierte Ausarbeitung ist selbstverständlich bereits vergütet.
Vladimir Klepche, Unternehmensnetzwerke.
Source: habr.com