SDN und OpenFlow machen Fehlersuche schwieriger

Kommentieren Drucken

Zugegeben, mit dem neuen Hype um Software-Defined Networking (SDN) und OpenFlow kann sich der Autor noch nicht sehr anfreunden. Insofern ist jeder Kommentar des Autors zu SDN und OpenFlow tendenziös. Nichtsdestotrotz erlaube ich mir im Folgenden, SDN und OpenFlow aus der Perspektive des Troubleshooters zu bewerten.

Deduktion und Induktion sind die beiden logischen Werkzeuge des Troubleshooters. Es gibt Dinge, die so offensichtlich kausal bedingt und nachvollziehbar sind, dass sie mit den Mitteln der Deduktion erfasst werden können. Beispiel aus der Fehlersuche: die Kommunikation mit einem Server ist sehr instabil und holprig. Bei der Analyse stellt es sich heraus, dass die Einstellungen des Duplexmodus auf dem Switch und dem daran angeschlossenen Server inkompatibel sind, was zu einer erhöhten Fehlerrate führt, die sogar auch von der Interface-Statistik des Switches angezeigt wird. Hier liegen die kausalen Zusammenhänge und dementsprechend die Methodik der logischen Schlussfolgerung bei der Fehlersuche klar auf der Hand. Inkompatible Duplexmodi führen zwangsläufig zu fehlerhaften Paketen und diese zur instabilen Kommunikation. Die Deduktion führt geradeaus zum Ziel.

Leider ist den meisten Fehlern und Problemen in der IT nicht mit Deduktion beizukommen. Komplexere Probleme, mit deren Analyse der Troubleshooter am längsten braucht, sind in der Regel nur basierend auf Indizien zu analysieren. Aus den Indizien können aber grundsätzlich verschiedene Schlussfolgerungen gezogen werden. Außerhalb der Mathematik ist fast jede Induktion unvollständig. Performanceprobleme einer Webanwendung können an schlechter HTML-Programmierung liegen, aber auch an einem lahmen Proxy. Gewiss, je mehr Indizien in eine bestimmte Richtung weisen, desto wahrscheinlicher stimmt die Richtung.

Leider liefert die Realität meistens nur ungenügende Indizien. Der Troubleshooter steht dann vor der Wahl, entweder sich auf die ungenügenden Indizien zu beschränken oder zu versuchen, die Indizienlage zu verbessern. Um beim Webbeispiel zu bleiben, kann der Troubleshooter mal probehalber per Browsereinstellung unter Umgehung des verdächtigen Proxy auf die Webanwendung zugreifen und das Ergebnis mit dem Proxy-Szenario vergleichen. Hier greift der Troubleshooter aktiv in das Netzgeschehen ein, um die Indizienlage zu verbessern. Er ist kein reiner Beobachter mehr.

Nun zurück zu SDN und OpenFlow. Bisher ist jede Netzkomponente für sich autark (von MC-LAG-Pärchen, welche die Fehlersuche ebenfalls nicht einfacher machen, abgesehen) und arbeitet nach bekannten und standardisierten Verfahren. Ein Layer-2-Switch arbeitet gemäß den Spezifikationen im Standard IEEE 802.1D. Er lernt MAC-Adressen, legt die Ergebnisse seines Lernens in eine Tabelle mit Ports und zugeordneten MAC-Adressen ab und leitet Pakete anhand dieser Tabelle weiter. Ein Layer-3-Switch unterliegt den Vorgaben der IETF-Spezifikationen zu IP Routing. Er nimmt an einem Routing-Protokoll teil, legt die dadurch gelernten und die manuell eingestellten Routen in einer Routing-Tabelle ab, ordnet per ARP den IP-Adressen MAC-Adressen zu und speichert diese Zuordnungen in seiner ARP Cache. Der Layer-2-Switch ist ein auch allein lebensfähiges Stück Ethernet, der Layer-3-Switch ein auch allein lebensfähiges Internet. Man kann diese Mininetze isolieren, verändern, ersetzen, anders konfigurieren etc. Wenn man weiß was man tut, weiß man von vornherein, welche Auswirkungen das eigene Tun im schlimmsten Fall haben wird.

SDN und OpenFlow setzen dieser Übersichtlichkeit ein Ende. Der Switch ist nicht mehr autonom, sondern gehorcht dem zentralen Controller. Dieser ist für ein ganzes Netz zuständig. Mal so eben eine kleine Änderung an einem Switch vornehmen, hier und da Aging Timer für MAC- und ARP-Tabellen zu ändern, eine Route zu löschen oder hinzuzufügen, ist in einem komplexen Gebilde wie SDN bzw. OpenFlow höchst problematisch. Man verliert die Kontrolle über die Wirkung seiner Taten. SDN und OpenFlow machen den Troubleshooter vorsichtiger und behindern ihn damit ein Stück weit. Das ist zumindest meine Vermutung. Noch fehlen entsprechende Erfahrungen mit diesen Technologien.

Man kann gegen meine Bedenken argumentieren, dass aus autonomen Komponenten bestehende Netze nicht schon ewig bestehen. Es gab in Vergangenheit auch Netze unter weitgehender zentraler Kontrolle, zum Beispiel Netze gemäß Systems Network Architecture (SNA) von IBM. Und sie funktionierten stabiler als die heutigen Ethernets und Internets.

Der Haken bei dieser Gegenargumentation: SNA stand unter der Kontrolle eines Herstellers. Selbst die dümmsten Terminals waren von diesem Hersteller minutiös spezifiziert und zertifiziert. Es war das luxuriöse Zeitalter der EDV, in dem Mainframe-Zauberer First Class reisten und sich monatelang in IBM-Labors mit allen erdenklichen Szenarien in Großrechnerumgebungen befassen konnten.

Diese Zeiten sind ein für alle mal vorbei und kehren nicht wieder. Switches, Server, Hypervisoren, Speichersysteme und Software sollen auch im Zeitalter von SDN und OpenFlow von verschiedenen Herstellern stammen können. Und dann soll eine zentrale Instanz die Kontrolle für das gesamte Gebilde namens Netz übernehmen. An die Stelle der Herstellerverantwortung tritt die Betreiberverantwortung – zwangsläufig, denn kein Hersteller wird die Verantwortung für das korrekte Funktionieren der Komponenten eines anderen Herstellers übernehmen.

Der Betreiber ist auch für die Fehlersuche zuständig. Er kann aber an einem zentral gesteuerten Gebilde viel weniger aktiv Änderungen vornehmen als an gemäß Standards gekoppelten autonomen Komponenten. Die Verwendung eines wichtigen Mittels der Fehlersuche wird stark eingeschränkt. Insofern wird – zugegeben aus der zugespitzten pessimistischen Position betrachtet – die neue Welt die Nachteile der Gegenwart und Vergangenheit der Netze in sich vereinen: die heutige bunte Mischung aus Komponenten verschiedener Hersteller (mit Komponenten sind nicht nur Switches gemeint, s. o.) mit etwas chaotischen Auswirkungen einer- und die Unflexibilität einer zentralen Steuerung andererseits.

Bleibt zu hoffen, dass sich der Autor irrt und alles nicht so schlimm kommt wie im pessimistischen Szenario ausgemalt.

zugeordnete Kategorien: Endgeräte, 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.

*

.