Cloud, Data Center Fabrics und Software-defined Networks

Ivan Pepelnjak
Ein Interview mit dem Netzwerk- und Rechenzentrumsexperten Ivan Pepelnjak.
 
CIOs, Rechenzentrumsarchitekten und Netzwerkverantwortliche haben es nicht leicht. Die Vorgaben sind klar: Kosteneinsparungen, Effizienzsteigerungen und operationelle Flexibilität. Auf der anderen Seite stehen die zunehmende Digitalisierung und die neuen Anforderungen, die durch Big Data, Analytics und Business Intelligence (BI) gestellt werden. Die massive Zunahme des Datenvolumens verlangt nach einer geeigneten Rechenzentrumsinfrastruktur. Data Center Fabrics ermöglichen die nahtlose Verbindung von Daten- und Speichernetzwerken und bilden die Grundlage für Flexibilität und Agilität im Rechenzentrum. Es gibt aber weder einheitliche Standards noch einheitliche Architekturen. Um etwas Licht ins Dunkel zu bringen unterhielt sich inside-it.ch mit Ivan Pepelnjak, einem weltweit anerkannten Top-Experten.
 
Ein Begriff, der im Zusammenhang mit Rechenzentren immer wieder auftaucht ist "Data Center Fabrics" (Rechenzentrumsstruktur). Welches Problem versuchen diese Data Center Fabrics zu lösen?
 
Data Center Fabrics sollen ein Problem lösen, das einfach zu definieren ist: Eine vereinheitlichte Rechenzentrumsinfrastruktur bieten, die Daten- und Speichernetzwerke nahtlos verbindet. Wie immer steckt der Teufel dabei in den Details.
 
Sind Data Center Fabrics ein Bereich, der jedermann betrifft oder ist es ein Thema, das nur für Rechenzentrumsarchitekten relevant ist?
 
Obwohl jedermann über Cloud spricht, sind grosse Organisationen von Applikationen abhängig, die in einem eigenen Rechenzentrum, oder über mehrere eigene Rechenzentren verteilt laufen. Dies macht Data Center Fabrics zu einer der unternehmenskritischsten Infrastrukturkomponenten in fast allen grösseren Organisationen. Während der Ausfall einer einzelnen Applikation einen Betrieb lahmlegen kann, ist der Ausfall des ganzen Rechenzentrums für ein Unternehmen oft existenzgefährdend. Data Center Fabrics spielen aber auch bei Cloud-Service-Providern eine grosse Rolle.
 
Gibt es eine Standardarchitektur und Standardtechnologie, oder gibt es unterschiedliche Ansätze?
 
Es gibt weder eine Standardarchitektur noch eine Standardtechnologie. Jeder Anbieter preist seine eigenen Produkte, Architekturen und Technologien an. Die Anbieter können sich nicht einmal darauf einigen, was zum Erreichen der Zielsetzung gemacht werden muss. Das hängt teilweise mit einem engen Fokus auf bestimmte Marktsegmente zusammen.
 
Einige Anbieter bewerben beispielsweise FibreChannel-over-Ethernet stark als ein Muss in Bezug auf die Funktionalität von Data Center Fabrics, während andere Anbieter die Integration von FibreChannel bewusst auslassen, weil ihre Kundenbasis vorwiegend auf IP-basierte Speicherlösungen setzt.
 
Betrachtet man das Marktangebot, so sieht man, dass es Anbieter gibt, die sich auf Lösungen für grosse, schnelle und stabile IP-basierte Strukturen spezialisieren, die bei grossen Cloud-Anbietern gefragt sind. Andere Anbieter haben es auf Kunden abgesehen, die so viele Features wie möglich sehen wollen. Diese umfassen dann auch beispielsweise die Integration von FibreChannel und die Unterstützung von grossen VLANs.
 
Die von den Anbietern verwendeten Architekturen unterscheiden sich massiv. Das geht von der zentralisierten Control Plane (Kontrollebene), bei der stapelbare Switches zu Bauelementen einer Data Center Fabric umfunktioniert werden, bis zu komplett verteilten Strukturen, die aus altbewährten Routers und Switches bestehen, auf die man zusätzliche Technologien draufklatscht und sie so fabric-tauglich macht. Wie üblich haben Hersteller und Komitees Standards entwickelt und verabschiedet, die unterschiedliche Aspekte von Data Center Fabrics abdecken. So gibt es TRILL (Transparent Interconnection of Lots of Links) und SPB (Shortest Path Bridging, die grosse Layer 2-Fabrics ermöglichen und FCoE (FibreChannel over Ethernet) für die Integration von FibreChannel. Wie auch üblich sind die Implementierungen der unterschiedlichen Anbieter meist inkompatibel zueinander. Eine vereinigte Data Center Fabric aus Geräten unterschiedlicher Hersteller ist deshalb im besten Fall nur schwierig zu bewerkstelligen. Will man sich Ärger und Kosten ersparen, so gibt es bessere Ideen.?
 
Was sind einige der bekannten Fallgruben?
 
Das Konzept einer einzigen, zentral verwalteten und vereinigten Transportinfrastruktur über das ganze Rechenzentrum ist äusserst verlockend. Die Netzwerkarchitekten vergessen dabei oft, dass eine Funktionseinheit meist mit einer einheitlichen Fehlerdomäne verbunden ist. Eine einzelne Störung irgendwo in der Fabric kann die ganze Fabric zum Absturz bringen. Umfasst die Fabric das ganze Rechenzentrum oder gar mehrere Rechenzentren, so hat das desaströse Auswirkungen. Dies zeigt sich zum Beispiel beim Auftreten von Bridging Loops oder Broadcast Storms. Beachtet man bei der Planung, der Konfiguration und dem Betrieb von VLANs gewisse Spielregeln nicht, so kann das zu grossflächigen Ausfällen mit entsprechenden Folgekosten führen.
 
Ein weiteres Thema, das den Zenit des Hype-Zyklus erreicht hat, ist SDN (Software Defined Networks). Welches Problem versucht SDN zu lösen?
 
In der sich schnell ändernden IT-Welt von 2016 und den kommenden Jahren ist es nicht mehr unbedingt effizient, alle Gerätekonfigurationen in Handarbeit zu erstellen und manuell zu verteilen. Das ist aber heute immer noch die häufigste Methode, um Netzwerkelemente zu konfigurieren und Netzwerkdienste bereitzustellen Vom Bereitstellen und zu beziehen. Für die Problemlösung gibt es unterschiedliche Ansätze. Diese reichen von einer radikalen Rearchitektur bestehender Netzwerke unter Verwendung einer zentralisierten Control Plane (Kontrollebene) bis zur schrittweisen Verbesserung mittels Netzwerkautomation.
 
Was ist ein software-definitiertes Netzwerk und welche Komponenten umfasst es?
 
Leider gibt es weder eine einheitliche noch eine gute Definition in Bezug auf SDN. Der SDN-Hype wurde von der Open Networking Foundation (ONF) ausgelöst. Die Definition der ONF hat zwei Hauptelemente: Erstens die physische Trennung der Network Control Plane (Netzwerkkontrollebene) von der Forwarding Plane (Weiterleitungsebene) und zweitens eine zentralisierte Control Plane. So wie die ONF SDN definiert, entspricht es einer Netzwerkarchitektur wie sie in den 1960ern üblich war, in einer Zeit bevor die DARPA angefangen hat die frühen Forschungen für das Internet zu finanzieren.
Etliche Hersteller haben versucht, ihre eigene Definition von SDN auf dem Markt durchzudrücken. Nach diesen unterschiedlichen Definitionen kann SDN fast alles sein: Vom programmierbaren Netzwerkelement bis hin zu Whitebox-Switches. Bei letzteren handelt es sich um kostengünstige Hardware mit einer X86-CPU und Standardkomponenten, auf der ein Netzwerkbetriebssystem und Programme die Funktionalität eines spezialisierten Switches oder Routers zur Verfügung stellen.
 
Die meisten Leute, die mit Aspekten von SDN in der Praxis im echten Leben zu tun haben sprechen deutlich weniger von SDN als die Industrieorganisationen und die Hersteller. Für sie dreht sich die Diskussion um Lösungen, welche den aktuellen Zustand im Netzwerkbereich verbessern können. Diese sollten mindestens folgende drei Bereiche abdecken:
(1) Eine Form von zentraler Sicht, zentral verwalteten Richtlinien und zentraler Kontrolle, die als Einheit in der Regel als Controller bezeichnet wird.
(2) Ein hochautomatisiertes Netzwerk, das dem Controller erlaubt, abhängig von externen Anforderungen, die Netzwerkkonfiguration und das Verhalten in Echtzeit zu ändern.
(3) Idealerweise ein Rückmeldungsmechanismus, der dem Controller erlaubt, auf Änderungen im Netzwerk zu reagieren und ein Problembehebungsmechanismus, bei dem der Controller die angebotenen Netzwerkdienste an Änderungen im Zustand des Netzwerks anpassen kann. So könnte ein Controller beispielsweise den Netzwerkverkehr bei Eintritt eines Verbindungsausfalls umleiten.
 
Gibt es unterschiedliche Ansätze für SDN und falls ja, sind diese interoperabel?
 
Es gibt die unterschiedlichsten Herangehensweise für SDN und es wird lange dauern bis wir zumindest eine minimale Interoperabilität zwischen den unterschiedlichen Lösungen sehen.
 
Wenn wir die vorgehend aufgezeigte flexiblere und praxisorientierte Sicht in Bezug auf SDN einnehmen, so können SDN-Lösungen einen breiten Bereich abdecken: Von Lösungen für das Bereitstellen und Beziehen von Geräten und Diensten bis zu Controllern, die Verkehrsflüsse über die Netzwerke in Echtzeit anpassen (Traffic Engineering), Netzwerkrichtlinien ändern oder direkt mit der Paketweiterleitung interagieren.
 
Können software-definierte Netzwerke einen negative Auswirkung auf die Netzwerkleistung haben?
 
Selbstverständlich nicht… wenn man den Herstellern glaubt, welche die Lösungen verkaufen. Man sollte allerdings immer im Hinterkopf behalten, dass neuartige Lösungen normalerweise ein Hort für eine interessante Sammlung von Bugs sind, die sich erst im Einsatz manifestieren. Bisher fehlt es auch an genügender operationeller Erfahrung mit Echtzeitanpassungen an das Netzwerkverhalten.
 
Ich empfehle meinen Kunden deshalb, nichts zu überstürzen und das Ganze eher gemächlich anzugehen: Am Anfang genügt ein schreibgeschützter Zugriff auf das Netzwerk. Als nächster Schritt folgt dann das Bereitstellen und Beziehen von Geräten, weil dieses nicht unternehmenskritisch ist. Es folgt das manuell kontrollierte Bereitstellen und Beziehen von Diensten, bei dem jemand die Konfigurationsänderungen vor dem Einsatz überprüft. Erst wenn sich alles bewährt hat, sollte man auf automatisches Bereitstellen und Beziehen von Diensten wechseln.
 
Wo kann man zusätzliche herstellerunabhängige Informationen zu den Themen Data Center Fabric und SDN finden?
 
Wenn Sie sich mit den unterliegenden Technologien und Applikationen vertraut machen wollen, so finden sich auf meiner Website eine grosse Menge an Präsentationen und Webinaren. So auch zu den Themen "SDN" und "Data Center Fabrics?. Zudem leite ich am 22. März am Morgen einen Workshop mit dem Thema "Data Center Fabrics Overview" und gebe am 22 März am Nachmittag ein Training im Bereich SDN.
(Gespräch: Christoph Jaggi)

Ivan Pepelnjak gilt als einer der weltbesten Experten auf dem Gebiet von Netzwerken, Cloud, Rechenzentren und skalierbarem Web Application Design. Sein Blog ist eines der meistgelesenen Technologie-Blogs weltweit. Als Consultant berät und begleitet er Unternehmen durch Paradigmenwechsel und zeigt auf, wie gleichzeitig die Kosten verringert und die operationelle Effizienz gesteigert werden kann. Seine Webinare, Bücher und Blogeinträge machen sein breitgefächertes Wissen der Allgemeinheit zugänglich.