Service-Oriented Networks (SON) statt Software-Defined Networks (SDN)

Kommentieren Drucken

Wie ja hier auch schon in mehreren Artikeln ausgeführt, ist Software-Defined Networking (SDN) ein sehr interessanter Ansatz für die Weiterentwicklung von Netzwerklösungen. Im Fokus von SDN stehen allerdings primär extrem große Firmen wie Google, Deutsche Telekom, Microsoft, Yahoo, etc. (also die Gründungsmitglieder der ONF). Andere Unternehmensnetzwerke, die nicht diese Größe erreichen, haben dagegen typischerweise andere Anforderungen.

Dies wird besonders am Beispiel von Google deutlich: Im Bestreben, die eigenen Netzwerke immer weiter zu optimieren, ist Google dazu übergegangen, nicht nur die Switche für das eigene Netz selber zu bauen, sondern auch die Steuerung über OpenFlow zu zentralisieren. Hierdurch erreicht Google die Möglichkeit, sein Netz kontrolliert bis fast zu 100% auszusteuern (siehe: http://goo.gl/o6jnv). Normalerweise werden in der Industrie 30% bis 40% als maximale Auslastung betrachtet, da es darüber hinaus immer schneller zu unkontrollierbaren Überlastsituationen kommt.

Die am Beispiel Google beschriebenen Anforderungen sind aber – glücklicherweise – nicht die Probleme und Anforderungen, die wir heute in den anderen Unternehmen sehen. Der größte Teil der deutschen Unternehmen beschäftigt sich zurzeit hauptsächlich mit der Virtualisierung ihrer Serverlandschaften und den daraus folgenden Konsequenzen für die Netzwerkarchitektur.

Aktuelle Anforderungen: Server bewegen – aber wie?
Alle Hypervisor-Hersteller (VMware, Microsoft, Citrix, etc.) bieten heute die Möglichkeit, virtuelle Maschinen im laufenden Betrieb zu verschieben (VMotion, Live-Migration, usw.). Hinderlich ist hierbei, dass die Hypervisor-Architekturen auf einer Layer 2-Struktur basieren, während Unternehmensnetzwerke seit Jahren mittels Layer 3 (als IP-Subnetze) strukturiert worden sind. Damit stellt sich natürlich die Frage, wie ein Server über eine Layer 3-Grenze hinweg bewegt werden kann, ohne seine IP-Adresse zu wechseln und die Verbindung zu seinem eigenen IP-Subnetz/VLAN aufrechtzuhalten. Hierzu muss das Serverinterface (die virtuelle Maschine) mit seinem ursprünglichen VLAN verbunden bleiben und auch sein Default Gateway behalten.

Die Antwort: Ein Service-orientiertes Netzwerk
Die Antwort kann nur darin bestehen, dass ein Automatismus in das Netzwerk gebracht wird, damit diese Anforderungen erfüllt werden können, d. h. das Netzwerk muss als Service-orientiertes Netzwerk zur Verfügung stehen. Dies bedeutet, dass die Komponenten der Netzwerkinfrastruktur (Layer 2- und Layer 3-Switche) Informationen über verfügbare Dienste automatisch austauschen und diese Dienste dann selbständig über die Netzwerkinfrastruktur miteinander verbinden. Wichtig ist an dieser Stelle, dass wir hier ganz allgemein von einem Dienst oder Service sprechen. Wir werden an späterer Stelle noch genauer darauf eingehen, was ein solcher Dienst sein kann.

Grundlage Service-orientierter Netzwerke
Voraussetzung für Service-orientierte Netzwerke ist, dass jede Komponente des Netzwerks sämtliche Verbindungen von und zu jeder anderen Komponente kennt, wie dies ja auch bei einem reinen IP-Netzwerk der Fall ist. Jeder Switch in diesem Service-orientierten Netzwerk berechnet daraus die jeweils kürzeste Verbindung zu jedem anderen Switch. Sollten mehrere Wege gleich kurz sein, so können für den Lastausgleich auch parallele Verbindungen verwendet werden. Wo ein Dienst innerhalb des Netzwerks benötigt wird und nur an diesen Stellen, wird dieser definiert und die Information „Ich – Switch ‚XYZ‘– bin Teilnehmer dieses Dienstes“ an alle Komponenten des Netzwerks durch den jeweiligen Switch verteilt. Somit geben alle Switche innerhalb des Netzwerkes, die an diesem Dienst teilnehmen möchten, diese Information bekannt. Da jeder Switch den kürzesten Weg zu jedem anderen Switch kennt, ist natürlich auch der kürzeste Weg zu den Switchen bekannt, die diesen Dienst anbieten. Dieses einfache Konzept eröffnet nun die Möglichkeit, innerhalb von Service-orientierten Netzwerken verschiedenste Dienste zu nutzen.

Service-orientierte Netzwerke für die Verschiebung von virtuellen Maschinen
Schauen wir uns die eingangs erwähnte Anforderung an, virtuelle Maschinen innerhalb eines Unternehmensnetzwerks verschieben zu können. Soll dies im laufenden Betrieb geschehen (vMotion, Live Migration, etc.) dann muss die virtuelle Maschine ihre IP-Adresse behalten, da aktive Verbindungen erhalten bleiben müssen. Andererseits kann eine solche Maschine in einem Bereich des Netzwerkes landen, für den ein anderer IP-Adressbereich eingerichtet ist. Es muss also eine Layer 2-Verbindung zwischen der alten Position und der neuen Position der verschobenen virtuellen Maschine geschaltet werden. Dies kann nun in Form eines Dienstes geschehen. Das VLAN stellt in diesem Fall einen Dienst dar. Hierfür muss nur noch an den entsprechenden Stellen des Netzwerks, an denen dieses VLAN benötigt wird, ein entsprechender Dienst definiert werden. Durch das Service-orientierte Netzwerk werden diese Stellen nun automatisch und ohne weitere manuelle Konfiguration miteinander verbunden.

Die Möglichkeit auf so einfache Art und Weise Layer 2-Verbindungen über eine Service-orientierte Netzwerk-Fabric zu führen, lässt sich natürlich auch noch für andere Anforderungen nutzen. Denkbar sind beispielsweise über das Unternehmen verteilte WLAN-Access-Points, die vielleicht mehrere SSIDs und auch VLANs unterstützen, die aber – über das Unternehmen verteilt – immer gleich konfiguriert sein sollen: z. B. immer das gleiche VLAN für den Gastzugang nutzen (um eine bessere Kontrolle des Datenverkehrs der Gäste zu bekommen) oder immer das gleiche VLAN für Voice-over-WLAN (um Roaming ohne Gesprächsabbruch zu ermöglichen).

Das Gast-VLAN bzw. das VoWLAN kann in einem Service-orientierten Netzwerk als Dienst betrachtet werden, der überall dort, wo er benötigt wird, definiert und dann automatisch über die Infrastruktur miteinander verbunden wird.

Weitere Dienste in einem Service-orientierten Netzwerk
Was könnten andere Dienste sein, die über ein Service-orientiertes Netzwerk unterstützt werden können?

Die Herausforderung: Multicast-Datenströme
Um in heutigen Netzwerken Multicast-Datenströme für IP-basierte Video-Überwachung oder für IPTV-, Video- und/oder Ticker-Verteilung zu unterstützen, ist ein zusätzliches Protokoll für die IP-Ebene notwendig (z. B. PIM-SM) sowie die Einrichtung von sogenannten Rendezvous-Points. Dies macht die gesamte Netzwerkarchitektur aber leider komplexer und fehleranfälliger.

In einem Service-orientierten Netzwerk wird Multicast als Service definiert. Wie funktioniert das? Da Multicast-Datenverkehr über wohl-definierte IP-Adressen gesendet werden muss, kann umgekehrt das Service-orientierte Netzwerk hieran erkennen, dass ein Multicast-Datenstrom gesendet werden soll. Hierfür kann es nun selbständig einen Dienst reservieren und im Netz bekanntgeben. Jede weitere Komponente innerhalb des Netzwerks, die nun von einem Endteilnehmer über IGMP erfährt, dass dieser den Multicast-Datenstrom empfangen möchte, weiß, dass es hierfür bereits einen Dienst gibt. Die Komponente meldet sich dementsprechend selber für diesen Dienst an und hat damit automatisch eine Verbindung für den Multicast-Datenverkehr aufgebaut. Hierfür sind kein neues Protokoll und keine Rendezvous-Points notwendig – und das Netzwerk nutzt alle Links optimal aus und schaltet die kürzesten Verbindungen vom Sender zu Empfänger.

Multicast auch für VXLAN nutzen
Auch VMware ist bewusst geworden, dass eine Layer 3-Infrastruktur einem dynamischen Netzwerk mit der Option, jederzeit virtuelle Maschinen verschieben zu können, entgegensteht. Die Antwort von VMware hierauf heißt VXLAN. Vereinfacht ausgedrückt, ist VXLAN ein Verfahren, um Layer 2-Pakete in IP-Pakete zu verpacken, über eine Layer 3-Infrastruktur zu versenden und am Ausgangspunkt wieder zu entpacken, sodass die ursprünglichen Layer 2-Pakete wieder zur Verfügung stehen. Da dies einem Tunnel-Verfahren entspricht, heißen der Eingangs- und der Endpunkt dieser Übertragung auch Virtual Tunnel End Point (VTEP). Diese Übertragung funktioniert solange problemlos, wie die IP-Adresse des Zieles (also die IP-Adresse der virtuellen Maschine) bekannt ist. Schwierig ist es allerdings, wenn die sendende Station die empfangende Station nicht kennt und sie durch einen Broadcast (ARP-Request) versucht, ausfindig zu machen. Jetzt muss der VTEP einen Layer 2-Multicast (den ARP-Request) in einen Layer 3-Multicast umsetzen, d. h. VMware braucht für den Einsatz von VXLAN zwingend auch eine Layer 3-Multicast-Struktur. Dies würde also wieder den Einsatz eines Layer 3-Multicast-Protokolls (wie im vorigen Absatz geschildert) erfordern.

Ein Service-orientiertes Netzwerk kann aber auch VXLAN wie einen Service handhaben. Hierbei wird der Virtual Network Identifier (der ein VXLAN-Netzwerk eindeutig kennzeichnet) als Service aufgefasst und damit werden die benötigten Multicast-Verbindungen über das Netzwerk automatisch zu Verfügung gestellt.

Auch Mandanten sind ein Service
Unter Mandantenfähigkeit versteht man allgemein die vollständige Trennung des Datenverkehrs von zwei oder mehr Parteien. Hierbei sollen die Mandanten wie beispielsweise verschiedene Abteilungen innerhalb eines Unternehmens, unterschiedliche Firmen innerhalb eines Bürokomplexes oder öffentlichen Einrichtungen einer Stadt wie Feuerwehr, Polizei und Verwaltung auf eine gemeinsame Netzwerkinfrastruktur zugreifen können, ohne den Verkehr anderer Mandanten sehen zu können. Hierbei geht die Trennung soweit, dass den beteiligten Parteien nicht nur die Nutzung von VLAN-IDs sondern auch von IP-Adressen völlig frei gestellt wird. Bislang war für die Realisierung der Mandantenfähigkeit der aufwendige Einsatz von MPLS notwendig. MPLS erforderte wiederum den Einsatz von MBGP und brachte wiederum ein erhöhtes Maß an Komplexität und Fehleranfälligkeit in die Netzwerke.

In einem Service-orientierten Netzwerk kann nun ein komplettes Kundennetzwerk (in Form eines VRF) als Dienst definiert werden. Da innerhalb des Netzwerks nur diese Dienste transportiert werden, sind die von den Kunden gewählten VLAN-IDs bzw. IP-Adressen nicht sichtbar und können daher ohne Störung durch andere Dienste (und dementsprechend anderen Kundennetzwerken) transportiert werden.

Service-orientierte Netzwerke – heute schon verfügbar
Wenn wir von Service-orientierten Netzwerken sprechen, dann meinen wir nicht etwas, was in einigen Jahren vielleicht verfügbar ist, sondern wir sprechen über eine Technologie, die Avaya bei seinen Kunden heute schon zum Einsatz gebracht hat. Die Grundlage dieser Technologie ist der Standard IEEE 802.1aq „Shortest Path Bridging (SPB)“, der eine SPB-Ethernet-Fabric definiert.

Grundlage von Shortest Path Bridging ist, die Pakete, die zu einem Service gehören mit einer Service-ID (I-SID) zu versehen. Das so erweiterte Ethernet-Paket erhält als (Ethernet)-Ziel-Adresse den Fabric-Ausgangs-Switch für den benötigten Service. Dadurch werden sämtliche Informationen aus dem ursprünglichen Paket für das Netzwerk verborgen. Das erweiterte Paket kann nun im gesamten Service-orientierten Netzwerk auf Layer 2 weitergeleitet werden, da ja die Ethernet-Zieladresse bekannt ist. Die Informationen, welcher Switch wo zu erreichen ist (Netzwerktopologie) und welcher Service an welcher Komponente unterstützt wird, werden über das klassische Routingprotokoll IS-IS ausgetauscht.

Mit diesen einfachen Schritten ist es also möglich, schon heute ein Service-orientiertes Netzwerk aufzubauen und die oben aufgeführten Dienste problemlos abzubilden.

Weitere Informationen zu Shortest Path Bridging finden Sie unter:

zugeordnete Kategorien: LAN, Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.