pathdoc - stock.adobe.com
Integration von Machine-Learning-Systemen ins Netzwerk
Machine-Learning-Systeme in Netzwerken gewinnen immer mehr an Akzeptanz. Doch noch werden Menschen und APIs gebraucht, um die Komplexität unter Kontrolle zu halten.
Die Nutzung von Machine Learning im Netzwerkbetrieb ist zum nächsten großen IT-Thema geworden und verdrängt in den Köpfen vieler Netzwerktechniker zunehmend Software-defined Networks. Doch bevor die Networking-Welt der Hysterie des Hype-Zyklus verfällt, ist jetzt eine gute Zeit, um die realistischen Kompromisse bei der Verwendung von Machine-Learning-Systemen gegenüber rein menschlichen Interaktionen unter die Lupe zu nehmen.
Das große Versprechen von maschinellem Lernen im Networking lautet, dass Ihr Netzwerk sich in ein Machine-Learning-System verwandeln lässt und ohne jeden Eingriff selbsttätig funktioniert. Vermutlich wird das Netzwerk Ihnen irgendwann mitteilen, wann und wo Sie mehr Ressourcen benötigen, so dass wahrscheinlich sogar das Netzwerkdesign einfacher werden wird.
Dieses Versprechen wird allerdings zu einem gewissen Grad durch die praktische Erfahrung mit Machine-Learning-Systemen relativiert. So ist Amazons Lagersystem ein Paradebeispiel für Machine Learning, das am Schnittpunkt der Mensch-Maschine-Interaktion zum Einsatz kommt. Im Fall von Amazon basiert die Lagerverwaltung auf maschinellem Lernen, um zu bestimmen, wo Produktregale zu bestimmten Zeiten positioniert sein sollten.
Im Gegensatz dazu ist es für einen menschlichen Arbeiter extrem ineffizient, etwas in einem Lager zu finden, das nach Produkten organisiert ist, die üblicherweise gemeinsam bestellt werden. Amazon hat Machine-Learning-Systeme in seinem Fulfillment Center in New Jersey implementiert, um Kundenaufträge effizienter zusammenzustellen. Anstatt dass Amazon-Mitarbeiter im Lager unterwegs sind, um die für die Aufträge notwendigen Produkte zu finden, nutzt Amazon Machine Learning und Roboter, um die Regale anzuordnen und sie sogar zum Mitarbeiter hin zu bewegen.
Auf das Networking übertragen, bedeutet dies, dass man ein Machine-Learning-System anweist, die optimalen QoS-Parameter (Quality of Service) für eine Gruppe von Anwendungen zu finden, die im Netzwerk laufen. Die beste Wahl wird höchstwahrscheinlich eine QoS-Queue pro Anwendung sein, wobei jede Queue für die optimale Performance der ihr zugewiesenen Anwendung zuständig ist, während auch die Traffic-Anforderungen der anderen Anwendungen berücksichtigt werden. Für Menschen würde jedoch die Verwaltung von vier bis acht QoS-Queues – oder Serviceklassen – kaum praktikabel sein. Können wir also tatsächlich ein Netzwerk nach dem Vorbild eines Amazon-Lagersystems aufbauen?
Machine-Learning-Systeme ins Netzwerk einbinden
Menschen werden voraussichtlich noch auf viele Jahre hinaus im Computer-Networking unverzichtbar bleiben. Das Beispiel von Amazons Lagerverwaltung lässt sich dann doch nicht so leicht übertragen. Das Bewegen von physischen Regalen ist bei weitem weniger komplex als die Übertragung von Paketen durch ein bereits komplexes Netzwerk. Raum für menschliche Interaktion entstehen zu lassen, folgt demnach im Networking deutlich anderen Regeln als beim Aufbau eines Lagers.
Im Netzwerkbereich muss man deshalb nach einem Weg suchen, um maschinelles Lernen in die spezifischen Tools einzubinden, und gleichzeitig eine Schnittstelle für die Interaktion bewahren, die Menschen nutzen können. Es bieten sich zwei potenzielle Wege in diese Richtung an.
Erstens könnte man den Anwendungsbereich von Tools für maschinelles Lernen enger fassen. Auf diese Weise würden sich die Ergebnisse einer Anfrage begrenzen lassen. Anstatt zum Beispiel ein Machine-Learning-System anzuweisen, die optimalen QoS-Einstellungen für die Anwendungen zu finden, könnte man sagen: „Finde die optimale Unterteilung von Queues, die Einstellungen für diese Queues, für diese Gruppe von Anwendungen.“
Indem man die Komplexität der Lösung einschränkt, die das Machine-Learning-System erstellen darf, ist es möglich, die Komplexität dessen, was das Machine-Learning-System generiert, in einem gewissen Rahmen zu halten, den Menschen verstehen und mit dem sie umgehen können. Selbst wenn Menschen von bestimmten Netzwerk-Management-Aufgaben ausgeschlossen werden, ist es keine gute Idee, zuzulassen, dass sich die Komplexität unkontrolliert ausbreitet.
Zweitens können Tools für maschinelles Lernen im Netzwerk eingeschränkt werden, indem das Machine-Learning-System klar festgelegte Aufgaben übernimmt und diese Grenzen nicht überschreiten darf. An dieser Stelle kommt das Konzept der API ins Spiel. Die Idee hinter einer API im Bereich Softwareentwicklung ähnelt stark der Idee der Route Aggregation beim Netzwerkdesign. Bei beiden handelt es sich um eine allgemeine Möglichkeit, die Komplexität immer weiter zu unterteilen, indem man Details des Subsystems hinter der API abstrahiert.
Um zum oben angeführten QoS-Beispiel zurückzukehren: Ein Netzwerkbetreiber könnte dem Machine-Learning-System erlauben, innerhalb eines einzelnen Netzwerkbereichs einigermaßen autonom zu agieren. Das ließe sich erreichen, indem man die Arbeit, die erledigt werden muss, um QoS bereitzustellen, bewusst vom Rest des Netzwerkbetriebs trennt. Der Netzwerk-Operator könnte Folgendes mit einbeziehen: die Erkennung unterschiedlicher Traffic-Arten im Netzwerk, die Unterteilung von Traffic in verschiedene Klassen, die Kennzeichnung von Traffic, so dass er unter eine bestimmte Serviceklasse fällt, sowie das Erstellen und Management der entsprechenden Queues, die zu diesen Serviceklassen gehören.
Derartige Abstrahierungen werden immer Schwachstellen aufweisen. Beispielsweise wird QoS sich immer mit Traffic Engineering und jeder Art von dynamischen Bandbreitenmechanismen überschneiden, so dass diese Faktoren einbezogen werden müssen.
Berücksichtigen der Einschränkungen von Machine Learning
Das grundlegende Umdenken besteht darin, sich von dem zu lösen, was man Bereiche im Netzwerk – oder Modularisierung entlang strikt topologischer Grenzen – nennen könnte, und zur Vorstellung von Network as a Service (NaaS) zu gelangen. Dieses Konzept betrachtet das Netzwerk als Gruppe von Services, die miteinander interagieren. Im Modell Bereiche im Netzwerk sind APIs dort platziert, wo beliebige Bereiche zusammentreffen, zum Beispiel das Data Center und der Core oder der Campus und der Core.
Aber im NaaS-Modell werden alle Services, die zur Unterstützung des Betriebs benötigt werden, in logische Subservices unterteilt, wie QoS oder Sicherheit. Diese Services interagieren über das gesamte Netzwerk, um eine Komplettlösung zu bilden. Es gibt in diesem Modell nach wie vor topologische Trennstellen, die genutzt werden, um Failure Domains zu erstellen und den Status zu kontrollieren, aber diese überschneiden sich mit Services und beenden sie nicht.
Machine-Learning-Systeme können und werden im künftigen Netzwerkdesign und -betrieb eine Rolle spielen. Die Rolle, die sie übernehmen, muss jedoch gründlich durchdacht werden. Machine Learning muss eingeschränkt werden, um zu verhindern, dass es zu einem Anwachsen unnötiger Komplexität kommt. Darüber hinaus müssen APIs sorgfältig positioniert werden, um die Arten von Failure-Domain-Trennung und Problembestimmung zu ermöglichen, die sich für den erfolgreichen Betrieb von Netzwerken als notwendig herausgestellt haben.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!