DE | Deutsch
Networking Solutions 25.02.2019

Software Defined X – Was mache ich im Enterprise Campus oder Data Center?

Wenn wir modernisierte oder moderne Netzwerkinfrastrukturen ansehen, bedeutet das direkt Software Defined? Gibt es Gründe, warum Software Defined sinnvoll ist oder eventuell auch nicht? Muss ich unbedingt Software Defined als Lösung verwenden, wenn ich meine Netzwerkinfrastruktur aktualisiere? Welche Lösung bietet mit die größten Vorteile? Viele Fragen. Wir liefern die Antworten.

Artikel teilen

Aber machen wir einen Schritt zurück und definieren zuerst, was es bedeutet, wenn wir über eine Software-Defined-Network Infrastruktur (SDN) sprechen. Im Grunde lösen wir uns von den vorhandenen Hardwaregrundlagen und bilden darauf einen zusätzlichen Layer ab, eine Schicht, auf der wir Netzwerkfunktionen in Software weitestgehend unabhängig von der Hardware definieren können.

 

SDN– verschiedene Layer.

Vormals war es wichtig zu wissen, welche Pfade der Datenverkehr im Netzwerk nimmt. Es wurden Redundanzen häufig durch Hardware abgebildet. In einem SDN sprechen wir von einer Fabric. Durch die Campus Fabric (Enterprise), beziehungsweise Data Center Fabric wird Redundanz eher durch das darunter liegende Routingprotokoll und die vermaschte Verkabelung (Clos network) der Hardware abgebildet. Die Verkabelung und der physikalische Aufbau eine Fabric erfolgt nach dem "Clos Architektur Ansatz".

 

Dieser Ansatz sieht ein non-blocking Design vor, welches durch erhöhte Bandbreite Oversubscription, also rechnerisch mögliche Flaschenhälse, ausschließt. Hier wird der Aggregations Layer als Spine bezeichnet und der Access Layer als Leaf. Im Grunde sind die Ansätze im Data Center und im Enterprise Campus ähnlich. Der Übergang von einer Redundanz auf Hardware Ebene zu einer größeren Redundanz auf Protokollebene findet dadurch statt.

 

Jeder Baustein einer Fabric lässt sich ersetzen und die Infrastruktur ist an sich bereits größtmöglich redundant verkabelt. Redundanz wird durch den Einsatz von Routingprotokollen innerhalb der Fabric gewährleistet. Somit ist die darauf abgebildete Infrastruktur unabhängig von der darunter liegenden Hardware.

 

So können VLANs, Switches, ACLs, eventuell auch Services als Firewall, Loadbalancer oder ähnlichem unabhängig vom Hardware Layer abgebildet werden. Teilweise sind Services bereits virtualisiert verfügbar und ergänzen die Netzwerk-Lösung. Letztlich geht es immer darum, sich von der vorhandenen Verkabelung und Hardware unabhängig zu machen und Services und Netzwerkstukturen in Software abzubilden. Auch bei der Erweiterung in die Cloud kann ein SDN-Ansatz sinnvoll sein.

 

 

Spine – Leaf – Control Plane – Data Plane.

Wir unterscheiden zwischen Control Plane und der Data Plane. Die Control Plane wird hauptsächlich über verschiedene Routingprotokolle abgebildet, welche teilweise auch Layer-2-Informationen übertragen. Die Data Plane nutzt VXLAN als Framework für die Übertragung von virtuellen Layer-2-Netzwerken über ein geroutetes Layer 3, die Control Plane.

 

Dies beinhaltet, dass die Hardwareverkabelung möglichst standardiesiert innerhalb eines Spine- und Leaf-Konstruktes erfolgt. Diese Fabric, in einem Software definiertem Netzwerk, ermöglicht es alle Netzwerkfunktionen zentral über eine Management-Instanz zu steuern. Ähnlich einer Registry auf einem Windows Betriebssystem, die als Konfiguration einmal zentral abgelegt ist, wird das SDN zentral verwaltet.

 

Es ist bei der Inbetriebnahme neuer Services nicht mehr notwendig Kabel zu verlegen, sondern die "Kabel stecke" ich über das zentrale Management. Spine – Leaf sieht im "Normalfall" eine Verkabelung aller Leafs mit jedem Spine Switch vor.

 

 

VXLAN.

Als zusätzliches Protokoll für den Einsatz in einem SDN verwenden wir VXLAN. Das Protokoll enthält weitere Informationen, die es ermöglichen, den bisherigen VLAN-basierten Traffic mit zusätzlichen IP-Headern zu versehen und somit innerhalb des Netzwerkes den Traffic getunnelt innerhalb des VLANs zu versenden.

 

Automatisierung über API.

Insgesamt sollen Aufgaben und Arbeitsschritte in Workflows eingebunden werden können. Einzelne Arbeitsschritte sollen vereinfacht und wenn möglich automatisiert ablaufen und dadurch Standards eingerichtet, beziehungsweise standardisierte Abläufe genutzt werden. Durch die Möglichkeit eine Infrastruktur in Software zu definieren, zu konfigurieren und in Betrieb zu nehmen, ist es später ebenso möglich diese wieder zentral zu entfernen, ohne dabei Änderungen an einzelnen Hardwarekomponenten vornehmen zu müssen.

 

Microsegmentierung.

Diese beinhaltet die Möglichkeit kleine Segmente zu bilden, bis auf einen einzelnen Host pro Segment. Diese Möglichkeit, Segmente innerhalb einer Fabric in Software zu definieren, ermöglich es auf sehr einfach Art Sicherheit basierend auf Benutzergruppen, Einstufung von Anwendung, Auffälligkeiten im Datenverkehr (KI) zu definieren und teil- oder gar vollautomatisiert in Echtzeit zu steuern.

 

Mulit-Tenancy – Mandatfähigkeit – Skalierung.

Für VLANs stehen mit 12 Bits insgesamt 4096 VLANs zur Verfügung. Bei VXLAN können über 24 Bit insgesamt 16 Millionen VXLAN-Segmente angelegt werden. Anforderungen in Bezug auf Mandantenfähigkeit und Skalierung sind hier die Grundlage für eine VXLAN Bereitstellung. Haustechnik und IoT-Geräte können so beispielsweise sicher eingebunden werden, ohne physikalisch diverse parallele Infrastrukturen aufzubauen, wie das bisher der Fall war.

 

Service Chaining.

Ein weiterer Vorteil einer Software-Definierten-Netzwerkumgebung ist, dass sich Service Chains (Verkettung von Netzwerkservices wie z.B. Firewall, Loadbalancer, WAN-Optimierung, etc.) leichter definieren und provisionieren lassen. Dies ist besonders sinnvoll, da inzwischen viele Services virtualisiert als Softwareinstanz zur Verfügung stehen.

 

DCI – Multi-Pod – Multi-Site – Erweiterung in die Cloud.

Sobald die Fabric über mehr als einen Standort (Data Center Interconnect) reichen soll, ist es notwendig das Design entsprechend anzupassen. Soll die Fabric als Multi-Pod über zwei Standorte als eine Fabric reichen? Oder ist es sinnvoller, an jedem Standort eine eigene Fabric in einem Multi-Site Design umzusetzen? Je nachdem ist es notwendig, das Management der Fabric auf weitere Controller zu erweitern, beziehungsweise zusammenzufassen. Oder möchte ich mein Netzwerk in die Cloud erweitern?

 

Verschiedene Hersteller bieten Lösungen. Lassen Sie uns zusammen ihre Umgebung und Anforderungen ansehen und ein Design erstellen. Weitere Informationen sowie Kontaktmöglichkeiten sind hier zu finden.

frank-wagner.png
Frank Wagner
Presales Consultant Networking Solutions