Netzwerk-Programmierbarkeit und Automatisierung

Kapitel 1. Trends in der Netzwerkbranche

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bist du neu im Bereich Software Defined Networking (SDN)? Bist du in den letzten Jahren dem SDN-Wahn verfallen? Egal, in welche Kategorie du fällst, mach dir keine Sorgen. In diesem Buch erfährst du alles über die Grundlagen der Netzwerkprogrammierung und -automatisierung, beginnend mit dem Aufstieg von SDN. Dieses Kapitel gibt dir einen Einblick in die Trends in der Netzwerkbranche rund um SDN, seine Relevanz und seine Auswirkungen in der heutigen Welt der Netzwerke. Wir beginnen mit einem Rückblick darauf, wie Software Defined Networking zum Mainstream wurde und schließlich zu den Trends rund um Netzwerkprogrammierbarkeit und -automatisierung führte.

Der Aufstieg des softwaredefinierten Netzwerks

Wenn es eine Person gäbe, der man den ganzen Wandel in der Netzwerkbranche zuschreiben könnte, dann wäre es Martin Casado, der derzeit General Partner und Risikokapitalgeber bei Andreessen Horowitz ist. Zuvor war Casado VMware Fellow, Senior Vice President und General Manager in der Networking and Security Business Unit bei VMware. Er hat die Branche tiefgreifend beeinflusst, nicht nur durch seine direkten Beiträge (u.a. OpenFlow und Nicira), sondern auch dadurch, dass er den großen etablierten Netzwerkunternehmen die Augen geöffnet und gezeigt hat, dass sich Netzwerkbetrieb, Agilität und Verwaltbarkeit ändern müssen. Schauen wir uns das etwas genauer an.

OpenFlow

OpenFlow war wohl oder übel das erste wichtige Protokoll der Software Defined Networking (SDN) Bewegung. OpenFlow ist das Protokoll, an dem Martin Casado während seiner Doktorarbeit an der Stanford University unter der Leitung von Nick McKeown gearbeitet hat. OpenFlow ist nur ein Protokoll, das die Entkopplung der Steuerebene eines Netzwerkgeräts von der Datenebene ermöglicht (siehe Abbildung 1-1). In einfachsten Worten kann man sich die Steuerebene als das Gehirn eines Netzwerkgeräts vorstellen und die Datenebene als die Hardware oder anwendungsspezifischen integrierten Schaltkreise (ASICs), die die Weiterleitung der Pakete übernehmen.

Abbildung 1-1. Entkopplung der Kontroll- und Datenebene mit OpenFlow

OpenFlow im Hybrid-Modus betreiben

In Abbildung 1-1 sind die Netzwerkelemente ohne Steuerebene dargestellt. Dies stellt einen reinen OpenFlow-Einsatz dar. Viele Geräte unterstützen auch den Betrieb von OpenFlow in einem hybriden Modus, d. h. OpenFlow kann auf einem bestimmten Port, einem virtuellen lokalen Netzwerk (VLAN) oder sogar innerhalb einer normalen Paketweiterleitungspipeline eingesetzt werden. Wenn es in der OpenFlow-Tabelle keine Übereinstimmung gibt, werden die vorhandenen Weiterleitungstabellen (MAC, Routing usw.) verwendet, was eher dem Policy Based Routing (PBR) entspricht.

Das bedeutet, dass OpenFlow ein Low-Level-Protokoll ist, das als direkte Schnittstelle zu den Hardware-Tabellen (z. B. Forwarding Information Base oder FIB) verwendet wird, die einem Netzwerkgerät mitteilen, wie es den Datenverkehr weiterleiten soll (z. B. "Datenverkehr zum Zielort 192.168.0.100 soll über Port 48 gehen").

Hinweis

OpenFlow ist ein Low-Level-Protokoll, das Flow-Tabellen manipuliert und sich damit direkt auf die Weiterleitung von Paketen auswirkt. OpenFlow ist nicht für die Interaktion mit Attributen der Managementebene wie Authentifizierung oder SNMP-Parameter gedacht.

Da die von OpenFlow verwendeten Tabellen im Vergleich zu traditionellen Routing-Protokollen mehr als die Zieladresse unterstützen, gibt es mehr Granularität (passende Felder im Paket), um den Weiterleitungspfad zu bestimmen. Diese ist der Granularität des Policy Based Routing nicht unähnlich. Wie OpenFlow viele Jahre später, ermöglicht PBR Netzwerkadministratoren die Weiterleitung von Datenverkehr auf der Grundlage von "nicht-traditionellen" Attributen, wie der Quelladresse eines Pakets. Es dauerte jedoch eine ganze Weile, bis die Netzwerkhersteller eine gleichwertige Leistung für den über PBR weitergeleiteten Verkehr anboten, und das Endergebnis war immer noch sehr herstellerspezifisch. Mit dem Aufkommen von OpenFlow konnten wir nun die gleiche Granularität bei den Entscheidungen zur Weiterleitung des Datenverkehrs erreichen, allerdings auf eine herstellerunabhängige Weise. Es wurde möglich, die Fähigkeiten der Netzwerkinfrastruktur zu verbessern, ohne auf die nächste Version der Hardware des Herstellers zu warten.

Geschichte der programmierbaren Netzwerke

OpenFlow war nicht das erste Protokoll oder die erste Technologie, die verwendet wurde, um Kontrollfunktionen und Intelligenz von den Netzwerkgeräten zu entkoppeln. Es gibt eine lange Geschichte von Technologien und Forschungen, die OpenFlow vorausgingen, obwohl OpenFlow die Technologie ist, die die SDN-Revolution ausgelöst hat. Einige der Technologien, die OpenFlow vorausgingen, sind Forwarding and Control Element Separation (ForCES), Active Networks, Routing Control Platform (RCP) und Path Computation Element (PCE). Einen genaueren Blick auf diese Geschichte wirfst du in dem Papier "The Road to SDN: An Intellectual History of Programmable Networks" von Jen Rexford, Nick Feamster und Ellen Zegura.

Warum OpenFlow?

Es ist zwar wichtig zu verstehen, was OpenFlow ist, aber noch wichtiger ist es, die Gründe für die Forschungs- und Entwicklungsarbeit an der ursprünglichen OpenFlow-Spezifikation zu verstehen, die zum Aufstieg des Software Defined Networking geführt hat.

Martin Casado hat während seines Studiums in Stanford für die US-Regierung gearbeitet. Während seiner Zeit bei der Regierung bestand die Notwendigkeit, auf Sicherheitsangriffe auf die IT-Systeme zu reagieren (schließlich handelt es sich um die US-Regierung). Casado merkte schnell, dass er die Computer und Server nach Belieben programmieren und manipulieren konnte. Die tatsächlichen Anwendungsfälle wurden nie veröffentlicht, aber es war diese Art der Kontrolle über die Endpunkte, die es ermöglichte, zu reagieren, zu analysieren und möglicherweise einen Host oder eine Gruppe von Hosts bei Bedarf neu zu programmieren.

Für das Netzwerk war es fast unmöglich, dies auf saubere und programmatische Weise zu tun. Schließlich war jedes Netzwerkgerät geschlossen (z. B. für die Installation von Software Dritter gesperrt) und verfügte nur über eine Befehlszeilenschnittstelle (CLI). Obwohl die Befehlszeilenschnittstelle bei Netzwerkadministratoren sehr bekannt und sogar beliebt war und ist, war Casado klar, dass sie nicht die nötige Flexibilität bot, um das Netzwerk wirklich zu verwalten, zu betreiben und zu sichern.

In Wirklichkeit hatte sich die Art und Weise, wie Netzwerke verwaltet wurden, in über 20 Jahren nicht verändert, abgesehen von der Hinzufügung von CLI-Befehlen für neue Funktionen. Die größte Veränderung war die Umstellung von Telnet auf SSH. Das war ein Scherz, den das SDN-Unternehmen Big Switch Networks oft in seinen Folien verwendete, wie du in Abbildung 1-2 sehen kannst.

Abbildung 1-2. Was hat sich geändert? Von Telnet zu SSH (Quelle: Big Switch Networks)

Aber Spaß beiseite: Die Verwaltung von Netzwerken hinkt anderen Technologien drastisch hinterher, und genau das wollte Casado in den nächsten Jahren ändern. Dieser Mangel an Verwaltbarkeit lässt sich oft besser verstehen, wenn man andere Technologien betrachtet. Andere Technologien verfügen fast immer über modernere Methoden zur Verwaltung einer großen Anzahl von Geräten, sowohl für das Konfigurationsmanagement als auch für die Datenerfassung und -analyse - zum Beispiel Hypervisor Manager, Wireless Controller, IP PBXs, PowerShell, DevOps-Tools und die Liste ließe sich fortsetzen. Einige dieser Tools werden von den Anbietern als kommerzielle Software angeboten, andere wiederum sind eher lose aufeinander abgestimmt, um plattformübergreifende Verwaltung, Betrieb und Agilität zu ermöglichen.

Wenn wir zu dem Szenario zurückgehen, als Casado noch für die Regierung arbeitete, war es dann möglich, den Datenverkehr je nach Anwendung umzuleiten? Hatten die Netzwerkgeräte eine API? Gab es einen einzigen Kommunikationspunkt zum Netzwerk? Die Antworten lauteten überwiegend nein. Wie sollte es möglich sein, das Netzwerk so zu programmieren, dass es die Weiterleitung von Paketen, Richtlinien und die Konfiguration genauso einfach steuert, wie es möglich war, ein Programm zu schreiben und es auf einem Endrechner auszuführen?

Die ursprüngliche OpenFlow-Spezifikation war das Ergebnis von Martin Casado, der diese Art von Problemen aus erster Hand erfuhr. Der Hype um OpenFlow ist zwar abgeflaut, seit sich die Branche endlich mehr auf Anwendungsfälle und Lösungen als auf Low-Level-Protokolle konzentriert, aber diese erste Arbeit war der Katalysator für die gesamte Branche, um zu überdenken, wie Netzwerke aufgebaut, verwaltet und betrieben werden. Vielen Dank, Martin.

Das bedeutet auch, dass dieses Buch wahrscheinlich nicht geschrieben worden wäre, wenn es Martin Casado nicht gegeben hätte, aber das werden wir jetzt nie erfahren!

Was ist Software Defined Networking?

Wir haben eine Einführung in OpenFlow bekommen, aber was ist Software Defined Networking (SDN)? Ist es dasselbe, etwas anderes oder nichts von beidem? Um ehrlich zu sein, ist SDN genau das, was die Cloud vor fast einem Jahrzehnt war, bevor wir verschiedene Arten von Clouds kannten, wie Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS).

Referenzbeispiele und Entwürfe erleichtern das Verständnis dafür, was Cloud ist und was nicht, aber schon bevor es diese Begriffe gab, konnte man darüber diskutieren, dass man Cloud schon kannte, wenn man sie sah. So ähnlich verhält es sich auch mit Software Defined Networking. Es gibt öffentliche Definitionen, die besagen, dass White-Box-Netzwerke SDN sind oder dass eine API auf einem Netzwerkgerät SDN ist. Ist das wirklich SDN? Nicht wirklich.

Anstatt zu versuchen, eine Definition von SDN zu geben, werden wir auf die Technologien und Trends eingehen, die oft als SDN angesehen und in die SDN-Diskussion einbezogen werden. Dazu gehören:

• OpenFlow

• Virtualisierung von Netzwerkfunktionen

• Virtuelle Vermittlung

• Netzwerkvirtualisierung

• Geräte-APIs

• Netzwerk-Automatisierung

• Bare-Metal-Switching

• Netzwerkstrukturen für Rechenzentren

• SD-WAN

• Controller Vernetzung

Hinweis

Wir geben in diesem Buch bewusst keine Definition von SDN. SDN wird zwar in diesem Kapitel erwähnt, aber wir konzentrieren uns vor allem auf allgemeine Trends, die oft als SDN kategorisiert werden, um sicherzustellen, dass du jeden dieser Trends genau kennst.

Der Rest des Buches konzentriert sich auf Netzwerkautomatisierung, APIs und periphere Technologien, die wichtig sind, um zu verstehen, wie alle Teile in Netzwerkgeräten zusammenkommen, die programmatische Schnittstellen mit modernen Automatisierungstools und Instrumenten bieten.

OpenFlow

Auch wenn wir OpenFlow bereits vorgestellt haben, möchten wir noch ein paar weitere wichtige Punkte hervorheben, die du im Zusammenhang mit OpenFlow wissen solltest.

Einer der größten Vorteile, der sich aus der Verwendung eines Protokolls wie OpenFlow zwischen einem Controller und den Netzwerkgeräten ergeben sollte, war die echte Herstellerunabhängigkeit von der Controller-Software, die manchmal auch als Netzwerkbetriebssystem (NOS) bezeichnet wird, und den zugrunde liegenden virtuellen und physischen Netzwerkgeräten. Tatsächlich ist es aber so, dass Anbieter, die OpenFlow in ihren Lösungen einsetzen (z. B. Big Switch Networks, HP und NEC), OpenFlow-Erweiterungen entwickelt haben, weil sich die Standards schnell weiterentwickeln und sie einzigartige Mehrwertfunktionen anbieten müssen, die die Standardversion von OpenFlow nicht bietet. Es bleibt abzuwarten, ob alle Erweiterungen in die zukünftigen Versionen des OpenFlow-Standards aufgenommen werden.

Wenn du OpenFlow verwendest, hast du den Vorteil, dass du genauer bestimmen kannst, wie der Datenverkehr durch das Netzwerk fließt, aber mit großer Macht kommt auch große Verantwortung. Das ist toll, wenn du ein Team von Entwicklern hast. Google hat zum Beispiel ein OpenFlow-basiertes WAN namens B4 eingeführt, das die Effizienz seines WANs auf fast 100 % erhöht. Für die meisten anderen Unternehmen ist die Verwendung von OpenFlow oder eines anderen Protokolls weniger wichtig als das, was eine Gesamtlösung für das zu unterstützende Unternehmen bietet.

Hinweis

Während dieser Abschnitt OpenFlow heißt, geht es architektonisch gesehen darum, die Kontrollebene von der Datenebene zu entkoppeln. OpenFlow ist nur das Hauptprotokoll, das verwendet wird, um diese Funktionalität zu erreichen.

Virtualisierung von Netzwerkfunktionen

Network Functions Virtualization, auch bekannt als NFV, ist kein komplexes Konzept. Es bezieht sich darauf, dass Funktionen, die traditionell als Hardware eingesetzt wurden, stattdessen als Software eingesetzt werden. Die gängigsten Beispiele dafür sind virtuelle Maschinen, die als Router, Firewalls, Load Balancer, IDS/IPS, VPN, Application Firewalls und andere Dienste/Funktionen fungieren.

Mit NFV wird es möglich, eine monolithische Hardware, die vielleicht zehn- oder hunderttausende von Dollar gekostet hat, mit hunderten bis tausenden von Befehlszeilen zu zerlegen, um sie in N Stück Software, nämlich virtuelle Appliances, zu konfigurieren. Diese kleineren Geräte lassen sich aus der Perspektive des einzelnen Geräts viel besser verwalten.

Hinweis

Das vorangegangene Szenario verwendet virtuelle Appliances als Formfaktor für NFV-fähige Geräte. Dies ist nur ein Beispiel. Die Bereitstellung von Netzwerkfunktionen als Software kann in vielen Formen erfolgen, z. B. eingebettet in einen Hypervisor, als Container oder als Anwendung, die auf einem x86-Server läuft.

Es ist nicht unüblich, Hardware zu installieren, die in drei bis fünf Jahren nur für den Fall der Fälle benötigt wird, weil es zu kompliziert und noch teurer ist, schrittweise Upgrades durchzuführen. Hardware ist also nicht nur kapitalintensiv, sondern wird auch nur für Was-wäre-wenn-Szenarien verwendet , wenn es zu einem Wachstum kommt. Der Einsatz von softwarebasierten oder NFV-Lösungen bietet eine bessere Möglichkeit, ein Netzwerk oder eine bestimmte Anwendung zu skalieren und die Fehleranfälligkeit zu minimieren, während gleichzeitig ein Pay-as-you-grow-Modell verwendet wird. Anstatt eine einzelne große Cisco ASA zu kaufen, kannst du zum Beispiel nach und nach Cisco ASAv Appliances einsetzen und nach Wachstum bezahlen. Mit neueren Technologien eines Unternehmens wie Avi Networks kannst du auch Load Balancer problemlos skalieren.

Wenn NFV so viele Vorteile bieten kann, warum werden dann nicht mehr Lösungen und Produkte, die in diese Kategorie fallen, in der Produktion eingesetzt? Dafür gibt es mehrere Gründe. Erstens erfordert es ein Umdenken bei der Architektur des Netzwerks. Wenn es nur eine einzige monolithische Firewall gibt (als Beispiel), läuft alles durch diese Firewall - also alle Anwendungen und alle Nutzer oder, wenn nicht alle, dann eine bestimmte Gruppe, die dir bekannt ist. Im modernen NFV-Modell, in dem viele virtuelle Firewalls eingesetzt werden können, gibt es eine Firewall pro Anwendung oder Tenant im Gegensatz zu einer einzigen großen Firewall. Dadurch ist die Fehlerdomäne pro Firewall oder anderer Service Appliance relativ klein, und wenn eine Änderung vorgenommen oder eine neue Anwendung eingeführt wird, müssen die anderen anwendungsbezogenen (mandantenbezogenen) Firewalls nicht geändert werden.

Auf der anderen Seite gibt es in der traditionellen Welt der monolithischen Geräte im Wesentlichen nur einen einzigen Bereich für die Verwaltung der Sicherheitsrichtlinien - eine einzige CLI oder GUI. Das kann die Fehleranfälligkeit immens erhöhen, aber es bietet den Administratoren eine optimierte Richtlinienverwaltung, da nur ein einziges Gerät verwaltet wird. Je nach Team oder Mitarbeitern, die diese Geräte betreuen, entscheiden sie sich vielleicht immer noch für einen monolithischen Ansatz. Das ist die Realität, aber wir hoffen, dass mit der Zeit und mit verbesserten Tools, die bei der Nutzung und Verwaltung von softwarezentrierten Lösungen helfen können, mehr Einsätze dieser Art von Technologie zu sehen sein werden. In einer Welt mit modernem, automatisiertem Netzwerkbetrieb und -management wird es aus Sicht der Betriebseffizienz weniger wichtig sein, welche Architektur man wählt, da man entweder ein einzelnes Gerät oder eine größere Anzahl von Geräten auf viel effizientere Weise verwalten kann.

Abgesehen von der Verwaltung spielt auch die Tatsache eine Rolle, dass viele Anbieter ihre virtuelle Appliance-Edition nicht aktiv verkaufen. Wir sagen nicht, dass sie keine virtuellen Optionen anbieten, aber sie sind normalerweise nicht die bevorzugte Wahl vieler traditioneller Gerätehersteller. Wenn ein Anbieter in den letzten Jahren ein Hardware-Geschäft betrieben hat, ist das aus Sicht des Vertriebs und der Vergütung ein drastischer Wechsel zu einem softwarebasierten Modell. Aus diesem Grund schränken viele dieser Anbieter die Leistung oder die Funktionen ihrer virtuellen Appliance-basierten Technologie ein.

Wie in vielen dieser Technologiebereiche liegt ein großer Vorteil von NFV auch in der Flexibilität. Durch die Abschaffung von Hardware wird die Zeit für die Bereitstellung neuer Dienste verkürzt, da die Zeit für Racking, Stacking, Verkabelung und Integration in eine bestehende Umgebung entfällt. Durch den Einsatz eines Software-Ansatzes wird die Bereitstellung so schnell wie die Bereitstellung einer neuen virtuellen Maschine in der Umgebung. Ein wesentlicher Vorteil dieses Ansatzes ist die Möglichkeit, die virtuelle Appliance für weitere Tests zu klonen und zu sichern, z. B. in Disaster-Recovery-Umgebungen (DR).

Wenn NFV eingesetzt wird, entfällt die Notwendigkeit, den Datenverkehr durch ein bestimmtes physisches Gerät zu leiten, um den gewünschten Dienst zu erhalten.

Virtuelle Vermittlung

Die gängigsten virtuellen Switches auf dem Markt sind der VMware Standard Switch (VSS), der VMware Distributed Switch (VDS), der Cisco Nexus 1000V, der Cisco Application Virtual Switch (AVS) und der Open Source Open vSwitch (OVS).

Diese Switches werden immer wieder in die SDN-Diskussion miteinbezogen, aber in Wirklichkeit sind sie softwarebasierte Switches, die im Hypervisor-Kernel angesiedelt sind und die lokale Netzwerkkonnektivität zwischen virtuellen Maschinen (und jetzt auch Containern) bereitstellen. Sie bieten Funktionen wie MAC-Learning und Features wie Link-Aggregation, SPAN und sFlow, genau wie ihre physischen Switches es schon seit Jahren tun. Während diese virtuellen Switches oft in umfassenderen SDN- und Netzwerkvirtualisierungslösungen zu finden sind, handelt es sich bei ihnen um einen Switch, der einfach nur in Software läuft. Virtuelle Switches sind zwar keine eigenständige Lösung, aber sie sind extrem wichtig, wenn wir uns als Branche weiterentwickeln. Sie haben eine neue Zugangsebene oder einen neuen Rand im Rechenzentrum geschaffen. Der Netzwerkrand ist nicht mehr der physische Top-of-Rack-Switch (TOR), der hardwaredefiniert ist und nur eine begrenzte Flexibilität (in Bezug auf die Entwicklung von Funktionen) bietet. Da der neue Rand durch den Einsatz virtueller Switches softwarebasiert ist, können neue Netzwerkfunktionen schneller in Software erstellt und Richtlinien einfacher im gesamten Netzwerk verteilt werden. Zum Beispiel können Sicherheitsrichtlinien an dem virtuellen Switch-Port implementiert werden, der dem eigentlichen Endpunkt, sei es eine virtuelle Maschine oder ein Container, am nächsten ist, um die Sicherheit des Netzwerks weiter zu erhöhen.

Netzwerkvirtualisierung

Lösungen die als Netzwerkvirtualisierung kategorisiert werden, sind zum Synonym für SDN-Lösungen geworden. Für Zwecke dieses Abschnitts bezieht sich die Netzwerkvirtualisierung auf softwarebasierte Overlay-Lösungen. Die beliebtesten Lösungen, die in diese Kategorie fallen, sind NSX von VMware, die Virtual Service Platform (VSP) von Nuage und Contrail von Juniper.

Ein Hauptmerkmal dieser Lösungen ist, dass ein Overlay-basiertes Protokoll wie Virtual eXtensible LAN (VxLAN) verwendet wird, um Konnektivität zwischen Hypervisor-basierten virtuellen Switches herzustellen. Dieser Konnektivitäts- und Tunneling-Ansatz sorgt für Layer-2-Adjazenz zwischen virtuellen Maschinen, die auf verschiedenen physischen Hosts existieren, unabhängig vom physischen Netzwerk, d.h. das physische Netzwerk kann Layer 2, Layer 3 oder eine Kombination aus beidem sein. Das Ergebnis ist ein virtuelles Netzwerk, das vom physischen Netzwerk entkoppelt ist und das Wahlmöglichkeiten und Flexibilität bieten soll.

Hinweis

Der Begriff " Overlay-Netzwerk" wird oft in Verbindung mit dem Begriff " Underlay-Netzwerk" verwendet. Zur Verdeutlichung: Das Underlay ist das zugrunde liegende physische Netzwerk, das du physisch verkabelst. Das Overlay-Netzwerk wird mit einer Netzwerkvirtualisierungslösung aufgebaut, die dynamisch Tunnel zwischen virtuellen Switches innerhalb eines Rechenzentrums erstellt. Auch hier handelt es sich um eine softwarebasierte Netzwerkvirtualisierungslösung. Beachte auch, dass viele reine Hardware-Lösungen jetzt mit VxLAN als Overlay-Protokoll eingesetzt werden, um Layer-2-Tunnel zwischen Top-of-Rack-Geräten in einem Layer-3-Rechenzentrum aufzubauen.

Das Overlay ist zwar ein Implementierungsdetail von Netzwerkvirtualisierungslösungen, aber diese Lösungen sind viel mehr als nur virtuelle Switches, die durch Overlays zusammengefügt werden. In der Regel handelt es sich um umfassende Lösungen, die Sicherheit, Lastausgleich und die Integration in das physische Netzwerk über einen einzigen Verwaltungspunkt (den Controller) bieten. Oftmals bieten diese Lösungen auch Integrationen mit den besten Anbietern von Layer 4-7-Diensten an, so dass du die Wahl hast, welche Technologie du in deinen Netzwerkvirtualisierungsplattformen einsetzen möchtest.

Agilität wird auch durch die zentrale Controller-Plattform erreicht, über die jeder virtuelle Switch dynamisch konfiguriert wird und die Appliances nach Bedarf bedient werden. Wenn du dich erinnerst, ist das Netzwerk aufgrund der CLI, die bei allen Anbietern in der physischen Welt allgegenwärtig ist, operativ ins Hintertreffen geraten. Bei der Netzwerkvirtualisierung müssen virtuelle Switches nicht mehr manuell konfiguriert werden, denn jede Lösung vereinfacht diesen Prozess, indem sie eine zentrale grafische Benutzeroberfläche (GUI), eine Befehlszeilenschnittstelle (CLI) und eine API bereitstellt, über die Änderungen programmgesteuert vorgenommen werden können.

Geräte-APIs

Auf haben die Anbieter in den letzten Jahren erkannt, dass es nicht mehr ausreicht, nur eine Standard-CLI anzubieten, und dass die Verwendung einer CLI den Betrieb stark behindert hat. Wenn du jemals mit einer Programmier- oder Skriptsprache gearbeitet hast, kannst du das wahrscheinlich verstehen. Diejenigen, die das noch nicht getan haben, werden in Kapitel 7 mehr darüber erfahren.

Das Hauptproblem besteht darin, dass die Skripterstellung mit Legacy- oder CLI-basierten Netzwerkgeräten keine strukturierten Daten zurückgibt. Das bedeutete, dass die Daten vom Gerät in einem rohen Textformat an ein Skript zurückgegeben wurden (z. B. die Ausgabe einer Show-Version) und der Skriptschreiber diesen Text dann analysieren musste, um Attribute wie die Betriebszeit oder die Betriebssystemversion zu extrahieren. Wenn sich die Ausgabe der show Befehle auch nur geringfügig änderte, brachen die Skripte aufgrund falscher Parsing-Regeln ab. Dieser Ansatz ist alles, was Administratoren bisher zur Verfügung stand. Eine Automatisierung war zwar technisch möglich, aber jetzt gehen die Anbieter nach und nach zu API-gesteuerten Netzwerkgeräten über.

Durch das Angebot einer API entfällt das Parsen von Rohtext, da strukturierte Daten von einem Netzwerkgerät zurückgegeben werden, was den Zeitaufwand für das Schreiben eines Skripts erheblich reduziert. Anstatt den Text zu analysieren, um die Betriebszeit oder ein anderes Attribut zu finden, wird ein Objekt zurückgegeben, das genau das liefert, was benötigt wird. Dadurch wird nicht nur die Zeit für das Schreiben eines Skripts verkürzt und die Einstiegshürde für Netzwerktechniker/innen (und andere Nicht-Programmierer/innen) gesenkt, sondern es wird auch eine übersichtlichere Schnittstelle geschaffen, mit der professionelle Softwareentwickler/innen schnell Code entwickeln und testen können, ähnlich wie sie es mit APIs auf Nicht-Netzwerkgeräten tun. "Code testen" kann bedeuten, neue Topologien zu testen, neue Netzwerkfunktionen zu zertifizieren, bestimmte Netzwerkkonfigurationen zu überprüfen und vieles mehr. All diese Dinge werden heute manuell durchgeführt und sind sehr zeitaufwändig und fehleranfällig.

Eine der ersten populäreren APIs in der Netzwerkszene war die von Arista Networks. Ihre API heißt eAPI und ist eine HTTP-basierte API, die JSON-kodierte Daten verwendet. Keine Sorge, HTTP-basierte APIs und JSON werden in den folgenden Kapiteln behandelt, beginnend mit Kapitel 5. Seit haben wir gesehen, wie Cisco APIs wie Nexus NX-API und NETCONF/RESTCONF auf bestimmten Plattformen ankündigte und ein Anbieter wie Juniper, der schon immer über eine erweiterbare NETCONF-Schnittstelle verfügte, aber nicht allzu viel Aufmerksamkeit darauf lenkte. Es ist erwähnenswert, dass heutzutage fast jeder Anbieter eine Art von API hat.

Dieses Thema wird in Kapitel 7 noch ausführlicher behandelt.

Netzwerk-Automatisierung

In dem Maße, wie sich APIs in der Netzwerkwelt weiterentwickeln, werden auch immer mehr interessante Anwendungsfälle auftauchen, um sie zu nutzen. In naher Zukunft ist die Netzwerkautomatisierung ein Hauptkandidat für die Nutzung der programmatischen Schnittstellen, die von modernen Netzwerkgeräten, die eine API anbieten, bereitgestellt werden.

Bei der Netzwerkautomatisierung geht es nicht nur um die Automatisierung der Konfiguration von Netzwerkgeräten. Das ist zwar die gängigste Vorstellung von Netzwerkautomatisierung, aber der Einsatz von APIs und programmatischen Schnittstellen kann viel mehr automatisieren und bieten als nur die Weitergabe von Konfigurationsparametern.

Der Einsatz einer API vereinfacht den Zugriff auf alle Daten, die in Netzwerkgeräten gespeichert sind. Denk an Daten wie Flow-Level-Daten, Routing-Tabellen, FIB-Tabellen, Schnittstellenstatistiken, MAC-Tabellen, VLAN-Tabellen, Seriennummern - die Liste lässt sich beliebig fortsetzen. Der Einsatz moderner Automatisierungstechniken, die wiederum eine API nutzen, kann bei der täglichen Verwaltung von Netzwerken zur Datenerfassung und automatischen Diagnose schnell helfen. Da eine API verwendet wird, die strukturierte Daten zurückliefert, hast du als Administrator außerdem die Möglichkeit, genau den Datensatz anzuzeigen und zu analysieren, den du willst und brauchst, auch wenn er von verschiedenen show Befehlen stammt, was letztendlich die Zeit für die Fehlersuche und -behebung im Netzwerk reduziert. Anstatt dich mit N Routern zu verbinden, auf denen BGP läuft, um eine Konfiguration zu überprüfen oder ein Problem zu beheben, kannst du Automatisierungstechniken nutzen, um diesen Prozess zu vereinfachen.

Außerdem führt der Einsatz von Automatisierungstechniken zu einem berechenbareren und einheitlicheren Netzwerk insgesamt. Dies kann durch die Automatisierung der Erstellung von Konfigurationsdateien, die Automatisierung der Einrichtung eines VLANs oder die Automatisierung der Fehlerbehebung erreicht werden. Dies vereinfacht den Prozess für alle Benutzer, die eine bestimmte Umgebung unterstützen, anstatt dass jeder Netzwerkadministrator seine eigenen bewährten Methoden anwendet.

Die verschiedenen Arten der Netzwerkautomatisierung werden in Kapitel 2 ausführlicher behandelt.

Bare-Metal-Switching

Das Thema Bare-Metal-Switching wird auch oft als SDN bezeichnet, ist es aber nicht. Das ist es wirklich nicht! Trotzdem ist es wichtig, dass wir eine Einführung in die verschiedenen Technologietrends geben, die als SDN wahrgenommen werden. Wenn wir ins Jahr 2014 zurückspulen (und sogar noch früher), wurde der Begriff für Bare-Metal-Switching als White-Box oder Commodity-Switching bezeichnet. Der Begriff hat sich geändert, und das nicht ohne Grund.

Bevor wir uns mit dem Wechsel von White-Box zu Bare-Metal befassen, ist es wichtig zu verstehen, was dies auf einer hohen Ebene bedeutet, denn es ist ein massiver Wandel in der Art und Weise, wie Netzwerkgeräte betrachtet werden. In den letzten 20 Jahren wurden Netzwerkgeräte immer als physische Geräte gekauft - diese physischen Geräte bestanden aus Hardware-Appliances, einem Betriebssystem und Funktionen/Anwendungen, die du auf dem System nutzen kannst. Diese Komponenten stammten alle von demselben Anbieter.

Bei den White-Box- und Bare-Metal-Netzwerkgeräten sieht das Gerät eher wie ein x86-Server aus (siehe Abbildung 1-3). Es ermöglicht dem Nutzer, jede der benötigten Komponenten zu zerlegen, so dass es möglich ist, Hardware von einem Anbieter zu kaufen, ein Betriebssystem von einem anderen zu erwerben und dann Funktionen/Apps von anderen Anbietern oder sogar der Open-Source-Community zu laden.

White-Box-Switching war während des OpenFlow-Hypes eine Zeit lang ein heißes Thema, denn es ging darum, die Hardware zu standardisieren und das Gehirn des Netzwerks in einem OpenFlow-Controller zu zentralisieren, der heute auch als SDN-Controller bekannt ist. Und 2013 gab Google bekannt, dass sie ihre eigenen Switches gebaut haben und sie mit OpenFlow steuern! Das war damals das Thema vieler Gespräche in der Branche, aber in Wirklichkeit ist nicht jeder Endnutzer Google, also wird auch nicht jeder Nutzer seine eigene Hardware- und Softwareplattform bauen.

Parallel zu diesen Bemühungen entstanden einige Unternehmen, die sich ausschließlich auf Lösungen für White-Box-Switching konzentrierten. Zu diesen gehören Big Switch Networks, Cumulus Networks und Pica8. Jedes dieser Unternehmen bietet reine Softwarelösungen an, d. h., sie brauchen noch Hardware, auf der ihre Software läuft, um eine End-to-End-Lösung anbieten zu können. Ursprünglich kamen diese White-Box-Hardwareplattformen von Original Direct Manufacturers (ODM) wie Quanta, Super Micro und Accton. Wenn du in der Netzwerkbranche tätig bist, hast du wahrscheinlich noch nie etwas von diesen Anbietern gehört.

Abbildung 1-3. Ein Blick auf traditionelle und Bare-Metal-Switching-Stacks

Erst als Cumulus und Big Switch Partnerschaften mit Unternehmen wie HP und Dell ankündigten, ging die Branche dazu über, diesen Trend nicht mehr White-Box, sondern Bare-Metal zu nennen, da nun auch namhafte Hersteller Betriebssysteme von Drittanbietern wie Big Switch und Cumulus Networks auf ihren Hardware-Plattformen unterstützen.

Es mag immer noch Verwirrung darüber herrschen, warum Bare-Metal technisch gesehen kein SDN ist, da ein Anbieter wie Big Switch in beiden Welten spielt. Die Antwort ist einfach. Wenn ein Controller in die Lösung integriert ist, der ein Protokoll wie OpenFlow verwendet (es muss nicht unbedingt OpenFlow sein) und programmatisch mit den Netzwerkgeräten kommuniziert, hat das den Charakter eines Software Defined Networking. Genau das macht Big Switch - sie laden Software auf die Bare-Metal/White-Box-Hardware, auf der ein OpenFlow-Agent läuft, der dann mit dem Controller als Teil ihrer Lösung kommuniziert.

Andererseits bietet Cumulus Networks eine Linux-Distribution an, die speziell für Netzwerk-Switches entwickelt wurde. Diese Distribution bzw. dieses Betriebssystem führt herkömmliche Protokolle wie LLDP, OSPF und BGP aus, ohne dass ein Controller erforderlich ist, was es vergleichbar und kompatibel mit nicht-SDN-basierten Netzwerkarchitekturen macht.

Mit dieser Beschreibung sollte klar sein, dass Cumulus ein Unternehmen für Netzwerkbetriebssysteme ist, das seine Software auf Bare-Metal-Switches betreibt, während Big Switch ein Bare-Metal-basiertes SDN-Unternehmen ist, das die Verwendung seines SDN-Controllers erfordert, aber auch die Bare-Metal-Switching-Infrastruktur von Drittanbietern nutzt.

Kurz gesagt geht es beim Bare-Metal/White-Box-Switching um Disaggregation und die Möglichkeit, Netzwerkhardware von einem Anbieter zu kaufen und Software von einem anderen zu laden, wenn du dich dafür entscheidest. In diesem Fall haben Administratoren die Möglichkeit, Design, Architektur und Software zu ändern, ohne die Hardware auszutauschen, sondern nur das zugrunde liegende Betriebssystem.

Netzwerkstrukturen für Rechenzentren

warst du schon einmal in der Situation, dass du die verschiedenen Netzwerkgeräte in einem Netzwerk nicht einfach austauschen konntest, obwohl sie alle mit Standardprotokollen wie Spanning Tree oder OSPF arbeiten? Wenn ja, bist du nicht allein. Stell dir vor, du hättest ein Rechenzentrumsnetzwerk mit einem kollabierten Kern und einzelnen Switches oben in jedem Rack. Stell dir vor, was passieren muss, wenn es Zeit für ein Upgrade ist.

Es gibt viele Möglichkeiten, solche Netzwerke aufzurüsten, aber was wäre, wenn nur die Top-of-Rack-Switches aufgerüstet werden müssten und im Rahmen des Evaluierungsprozesses für neue TOR-Switches entschieden würde, einen neuen Anbieter oder eine neue Plattform zu verwenden? Das ist völlig normal und wird immer wieder gemacht. Der Prozess ist ganz einfach: Verbinde die neuen Switches mit dem bestehenden Core (natürlich unter der Annahme, dass es im Core verfügbare Ports gibt) und konfiguriere 802.1Q Trunking, wenn es sich um eine Layer-2-Verbindung handelt, oder konfiguriere dein bevorzugtes Routing-Protokoll, wenn es sich um eine Layer-3-Verbindung handelt.

Das sind die Fabrics für Rechenzentrumsnetzwerke. Das ist der Punkt, an dem sich der Denkprozess rund um Rechenzentrumsnetzwerke ändern muss.

Data Center Network Fabrics zielen darauf ab, die Denkweise von Netzwerkbetreibern von der Verwaltung einzelner Boxen auf die Verwaltung eines Systems in seiner Gesamtheit zu ändern. Wenn wir das frühere Szenario verwenden, wäre es nicht möglich, einen TOR-Switch gegen einen anderen Anbieter auszutauschen, der nur eine einzelne Komponente eines Rechenzentrumsnetzwerks ist. Vielmehr muss das Netzwerk, wenn es als System eingesetzt und verwaltet wird, als System betrachtet werden. Das bedeutet, dass der Upgrade-Prozess eine Migration von System zu System oder von Fabric zu Fabric ist. In der Welt der Fabrics können Fabrics ausgetauscht werden, wenn es Zeit für ein Upgrade ist, aber die einzelnen Komponenten innerhalb der Fabric können nicht ausgetauscht werden - zumindest die meiste Zeit. Dies kann möglich sein, wenn ein bestimmter Anbieter einen Migrations- oder Upgrade-Pfad anbietet und wenn Bare-Metal-Switching (nur der Austausch der Hardware) verwendet wird. A Einige Beispiele für Netzwerk-Fabrics in Rechenzentren sind die Application Centric Infrastructure (ACI) von Cisco, die Big Cloud Fabric (BCF) von Big Switch oder die Fabric und das hyperkonvergente Netzwerk von Plexxi.

Neben der Tatsache, dass das Netzwerk als System behandelt wird, gibt es noch einige andere gemeinsame Merkmale von Netzwerken in Rechenzentren:

• Sie bieten eine einzige Schnittstelle zur Verwaltung oder Konfiguration der Fabric, einschließlich der Richtlinienverwaltung.

• Sie bieten verteilte Standard-Gateways in der gesamten Fabric.

• Sie bieten Multi-Pathing-Funktionen.

• Sie verwenden eine Art SDN-Controller, um das System zu verwalten.

SD-WAN

Einer der heißesten Trends im Bereich Software Defined Networking war in den letzten zwei Jahren Software Defined Wide Area Networking (SD-WAN). In den letzten Jahren wurde eine wachsende Zahl von Unternehmen gegründet, die sich mit dem Problem des Wide Area Networking auseinandersetzen. A Einige dieser Anbieter sind Viptela (vor kurzem von Cisco übernommen), CloudGenix, VeloCloud, Cisco IWAN, Glue Networks und Silverpeak.

Seit der Umstellung von Frame Relay auf MPLS hat es im WAN keinen radikalen Technologiewandel mehr gegeben. Da die Kosten für Breitband und Internet nur einen Bruchteil der Kosten für entsprechende private Leitungen betragen, werden seit einigen Jahren vermehrt Site-to-Site-VPN-Tunnel eingesetzt, die die Grundlage für das nächste große Ding im WAN bilden.

Gängige Konzepte für Außenstellen umfassen in der Regel eine private (MPLS-)Leitung und/oder eine öffentliche Internetverbindung. Wenn beides vorhanden ist, wird das Internet in der Regel nur als Backup genutzt, insbesondere für den Datenverkehr von Gästen oder für allgemeine Daten, die über ein VPN zurück zum Unternehmen geleitet werden, während die MPLS-Leitung für Anwendungen mit geringer Latenz wie Sprach- oder Videokommunikation verwendet wird. Wenn der Datenverkehr zwischen den Leitungen aufgeteilt wird, erhöht sich die Komplexität der Routing-Protokollkonfiguration und die Granularität des Routings zur Zieladresse wird eingeschränkt. Die Quelladresse, die Anwendung und die Echtzeitleistung des Netzwerks werden bei der Entscheidung über den besten Weg in der Regel nicht berücksichtigt.

Eine gängige SD-WAN-Architektur, die viele der modernen Lösungen verwenden, ähnelt der Netzwerkvirtualisierung im Rechenzentrum, da ein Overlay-Protokoll verwendet wird, um die SD-WAN-Kantengeräte miteinander zu verbinden. Da Overlays verwendet werden, ist die Lösung unabhängig vom zugrundeliegenden physischen Transport, so dass SD-WAN über das Internet oder ein privates WAN funktioniert. Diese Lösungen laufen oft über zwei oder mehr Internetleitungen an Zweigstellen und verschlüsseln den Datenverkehr vollständig mit IPSec. Darüber hinaus messen viele dieser Lösungen ständig die Leistung der einzelnen Leitungen und sind in der Lage, für bestimmte Anwendungen selbst bei Stromausfällen schnell zwischen den Leitungen fehlzuschlagen. Da die Anwendungsebene sichtbar ist, können Administratoren auch einfach auswählen, welche Anwendung eine bestimmte Route nehmen soll. Diese Funktionen sind in WAN-Architekturen, die ausschließlich auf zielbasiertes Routing mit traditionellen Routing-Protokollen wie OSPF und BGP setzen, oft nicht zu finden.

Aus Sicht der Architektur bieten die SD-WAN-Lösungen der oben genannten Anbieter wie Cisco, Viptela und CloudGenix in der Regel auch eine Form von Zero-Touch-Provisioning (ZTP) und ein zentralisiertes Management mit einem Portal, das vor Ort oder in der Cloud als SaaS-basierte Anwendung zur Verfügung steht und das Management und den Betrieb des WAN in Zukunft drastisch vereinfacht.

Ein wertvolles Nebenprodukt der SD-WAN-Technologie ist, dass sie den Endnutzern mehr Auswahlmöglichkeiten bietet, da im Grunde jeder Anbieter oder jede Art von Verbindung im WAN und im Internet genutzt werden kann. Dadurch wird die Konfiguration und Komplexität von Carrier-Netzwerken vereinfacht, was wiederum den Carriern die Möglichkeit gibt, ihr internes Design und ihre Architektur zu vereinfachen und so hoffentlich ihre Kosten zu senken. Aus technischer Sicht geht es noch einen Schritt weiter: Alle logischen Netzwerkkonstrukte wie Virtual Routing and Forwarding (VRFs) werden über die Benutzeroberfläche (UI) der Controller-Plattform verwaltet, die der SD-WAN-Anbieter bereitstellt.

Controller Vernetzung

Unter gibt es bei einigen dieser Trends Überschneidungen, wie du vielleicht schon gemerkt hast. Das ist einer der verwirrenden Punkte, wenn du versuchst, all die neuen Technologien und Trends zu verstehen, die in den letzten Jahren entstanden sind.

Unter zum Beispiel verwenden beliebte Netzwerkvirtualisierungsplattformen einen Controller, ebenso wie verschiedene Lösungen, die in die Kategorien Data Center Network Fabric, SD-WAN und Bare-Metal-Switch fallen. Verwirrend? Du fragst dich vielleicht, warum die Controller-basierten Netzwerke in sich selbst aufgeteilt wurden. In Wirklichkeit ist es oft nur ein Merkmal und ein Mechanismus, um moderne Lösungen bereitzustellen, aber nicht alle der vorherigen Trends decken alles ab, was Controller aus technologischer Sicht leisten können.

Ein sehr beliebter Open-Source-SDN-Controller ist zum Beispiel OpenDaylight (ODL), wie in Abbildung 1-4 dargestellt. ODL ist, wie viele andere Controller auch, eine Plattform und kein Produkt. Sie sind Plattformen, die spezialisierte Anwendungen wie Netzwerkvirtualisierung anbieten können, aber sie können auch für Netzwerküberwachung, Sichtbarkeit, Tap-Aggregation oder jede andere Funktion in Verbindung mit Anwendungen genutzt werden, die auf der Controller-Plattform aufsetzen. Das ist der Hauptgrund, warum es wichtig ist, zu verstehen, was Controller über die traditionellen Anwendungen wie Fabrics, Netzwerkvirtualisierung und SD-WAN hinaus bieten können.

Abbildung 1-4. OpenDaylight Architektur

Zusammenfassung

Hier hast du sie: eine Einführung in die Trends und Technologien, die am häufigsten als Software Defined Networking bezeichnet werden und den Weg zu einem besseren Netzwerkbetrieb durch Netzwerkprogrammierbarkeit und Automatisierung ebnen. In den letzten sieben Jahren wurden Dutzende von SDN-Startups gegründet, Millionen von VC-Geldern investiert und Milliarden für die Übernahme dieser Unternehmen ausgegeben. Und wenn wir noch einen Schritt weiter gehen, verfolgen alle das gemeinsame Ziel, Softwareprinzipien und -technologien zu nutzen, um den Nutzern der Technologie mehr Leistung, Kontrolle, Flexibilität und Wahlmöglichkeiten zu bieten und gleichzeitig die betriebliche Effizienz zu steigern.

In Kapitel 2 werfen wir einen Blick auf die Netzwerkautomatisierung und gehen näher auf die verschiedenen Arten der Automatisierung, einige gängige Protokolle und APIs und die Entwicklung der Automatisierung in den letzten Jahren ein.