AI-gestützte Anwendungsfälle im Netzwerkbetrieb großer Rechenzentren
Die meisten Aussagen über AI im Netzwerkbetrieb sind zu allgemein, um daraus zu handeln. Die nützliche Version ist enger gefasst: eine kleine Zahl von Aufgaben, bei denen ein Modell tatsächlich etwas leistet, das ein Schwellenwert nicht kann. Vier davon bewähren sich in großen Rechenzentrumsnetzwerken, und jede wird hier beschrieben: was sie tut, was sie braucht und was sie für den diensthabenden Betreiber ändert.
Vier Aufgaben, die sich zu automatisieren lohnen
Anomalieerkennung bei Interface- und Traffic-Verhalten
Das Problem. Statische Schwellenwerte sind auf den ungünstigsten Fall ausgelegt und übersehen deshalb die leisen Verschlechterungen: eine Verbindung, die beginnt, einen Bruchteil eines Prozents an Paketen zu verlieren, ein Interface, dessen CRC-Fehlerzahl langsam steigt, ein Traffic-Muster, das sich Stunden verschiebt, bevor sich jemand beschwert.
Was die Plattform leistet. Die Plattform lernt im Zeitverlauf den Normalbereich für jedes Interface, jede Verbindung und jedes Gerät, einschließlich des täglichen und wöchentlichen Verlaufs des Traffics, und markiert dann Abweichungen von dieser Baseline statt von einem fixen Wert. Bandbreitenauslastung, Durchsatz, Latenz, Jitter, Paketverlust, Interface-Fehler und optische Dämpfung sind allesamt Kandidaten für die Baseline-Bildung.
Was sich ändert. Ein sich verschlechternder Transceiver oder ein flatternder Port wird erkannt, solange es noch ein Performance-Problem ist – nicht erst, wenn daraus ein Ausfall geworden ist.
Alarmkorrelation über Geräte, Ebenen und Domänen hinweg
Das Problem. Ein vorgelagerter Ausfall erzeugt Alarme von jedem dahinterliegenden Gerät. In einer großen Umgebung sind das Hunderte von Meldungen für eine einzige Ursache, und die erste Aufgabe des Betreibers wird zum Sortieren statt zum Beheben.
Was die Plattform leistet. Ereignisse aus SNMP-Traps, Syslog und Schwellenwert-Alarmen werden anhand von Netzwerktopologie und zeitlichem Zusammenhang gruppiert: welche Geräte hinter der ausgefallenen Verbindung liegen, welche Alarme innerhalb desselben Zeitfensters eintrafen, welche eine Abhängigkeit in der L2/L3-Karte teilen. Zusammengehörige Ereignisse verschmelzen zu einem Incident mit der wahrscheinlichen Ursache an oberster Stelle.
Was sich ändert. Weniger, dafür umfassendere Incidents statt einer Flut von Symptomen – und ein Ausgangspunkt, der bereits die wahrscheinliche Ursache ist.
Kapazitätstrendprognose für Verbindungen und Geräte
Das Problem. Kapazitätsentscheidungen fallen oft erst, nachdem eine Verbindung während einer Spitzenlast bereits gesättigt war – der teuerste Zeitpunkt, das zu bemerken.
Was die Plattform leistet. Die historische Auslastung pro Interface und pro Gerät wird anhand der eigenen Wachstumskurve fortgeschrieben, sodass sich die Frage ändert: nicht mehr, was gerade ausgelastet ist, sondern welche Verbindungen zuerst an ihre Grenze stoßen und wann. Dieselbe Methode gilt für Ressourcengrenzen von Geräten wie Portanzahl, Tabellengrößen und Durchsatzreserve.
Was sich ändert. Upgrades werden auf ein Datum geplant statt auf einen Vorfall, und die am stärksten ausgelasteten Pfade erhalten Aufmerksamkeit, bevor sie zum Grund für einen fehlgeschlagenen Job werden.
Automatisierte Hinweise zur Ursache
Das Problem. Ursachenanalyse in einem großen Netzwerk besteht größtenteils aus dem Sammeln von Belegen: Interface-Zähler abrufen, jüngste Änderungen prüfen, Zeitpunkte mit anderen Ebenen abgleichen. Das ist langsam und wird für jeden Incident auf dieselbe Weise wiederholt.
Was die Plattform leistet. Sobald ein Incident entsteht, stellt die Plattform die Belege zusammen, die ein Techniker sonst von Hand sammeln würde: den Topologiepfad, die Interface- und Fehlerzähler rund um das Ereignisfenster, korrelierte Ereignisse von benachbarten Geräten, jüngste Konfigurationsänderungen und den Hardware-Zustand des betroffenen Equipments. Sie präsentiert die wahrscheinlichste Ursache mitsamt den zugrunde liegenden Daten.
Was sich ändert. Der Hinweis ist eine Abkürzung, kein Urteil. Der Techniker bestätigt ihn weiterhin, startet dabei aber mit zusammengestellten Belegen statt vor einem leeren Terminal.
Was zuerst vorhanden sein muss
Diese Anwendungsfälle scheitern weit häufiger an Datengründen als an Modellgründen. Die folgende Liste sind die praktischen Grundvoraussetzungen.
Eine präzise Topologie, denn Korrelation und Ursachenhinweise sind nur so gut wie die dahinterliegende Abhängigkeitskarte
Genug Historie, um eine Baseline zu bilden, da die Anomalieerkennung wissen muss, wie normal für diese konkrete Verbindung aussah – nicht für eine generische
Normalisierte Ereignisse aus herstellerübergreifendem Equipment, sodass derselbe Zustand, gemeldet von zwei Herstellern, auch als derselbe Zustand behandelt wird
Telemetrie auf Hardware-Ebene neben der Netzwerksicht, denn ein Switch mit ausfallendem Netzteil und ein überlasteter Uplink sehen in den Zählern unterschiedlich aus, im Ticket aber identisch
Eine klar definierte Grenze für Automatisierung: worauf die Plattform handeln darf, was sie nur empfehlen darf und was für Audits protokolliert wird
Die Ebenen hinter diesen Anwendungsfällen
Network Monitoring liefert das Rohmaterial: Switches, Router, Firewalls, Load Balancer und Fibre-Channel-Switches; Bandbreite, Durchsatz, Latenz, Jitter und Paketverlust; Portstatus, Interface-Fehler, CRC-Fehler und optische Dämpfung; L2- und L3-Topologie mit Geräteabhängigkeiten; sowie SNMP-Traps, Syslog und Schwellenwert-Ereignisse, korreliert zur Rauschreduzierung.
SmartBSM ist die Ebene, die darauf aufbaut: intelligente Alarmkorrelation und Rauschreduzierung, Ursachenidentifikation, Incident-Korrelation, Kapazitätsplanung und -prognose sowie automatische Generierung der Service-Topologie, die abbildet, welche Business Services vom betroffenen Pfad abhängen.
AI Operations deckt den ebenenübergreifenden Teil ab, bei dem ein Netzwerkereignis zusammen mit Hardware-, Storage- und Anwendungssignalen betrachtet wird – so lässt sich ein Problem, das wie eine Überlastung aussieht, stattdessen auf eine ausfallende Komponente zurückführen.
Maßgebliche Quellen
Häufige Fragen zu AI im Netzwerkbetrieb
Was sind die wichtigsten AI-Anwendungsfälle im Netzwerkbetrieb großer Rechenzentren?
Vier tauchen durchgängig auf: Anomalieerkennung anhand gelernter Baselines statt fixer Schwellenwerte, Alarmkorrelation, die Symptome einer Ursache zu einem einzigen Incident bündelt, Kapazitätstrendprognose, die die Auslastung pro Interface fortschreibt, und automatisierte Ursachenhinweise, die die Belege zusammenstellen, die ein Techniker sonst von Hand sammeln würde.
Wie unterscheidet sich AI-basierte Anomalieerkennung von Schwellenwert-Alarmierung?
Ein Schwellenwert löst aus, wenn ein Wert eine im Voraus festgelegte Grenze überschreitet – meist hoch genug angesetzt, um Fehlalarme zu vermeiden, wodurch langsame Verschlechterungen darunter hindurchrutschen. Baseline-basierte Erkennung lernt den Normalbereich und den Tagesverlauf für jedes Interface oder Gerät und markiert Abweichungen von diesem Muster, sodass eine für sich selbst ungewöhnlich verhaltende Verbindung erkannt wird, selbst wenn ihre absoluten Werte akzeptabel aussehen.
Reduziert Alarmkorrelation die Anzahl der Alarme oder gruppiert sie nur?
Sie gruppiert sie, und genau das reduziert die Arbeitslast des Betreibers. Die zugrunde liegenden Ereignisse bleiben erhalten, da Techniker die einzelnen Geräte-Belege bei der Diagnose weiterhin benötigen. Was sich ändert: Eine Ursache erzeugt einen zu triagierenden Incident statt Dutzender einzelner Meldungen.
Was braucht eine Netzwerkbetriebsplattform, bevor AI-Funktionen nützlich werden?
Eine präzise Topologie, genug historische Daten, um Baselines zu bilden, normalisierte Ereignisse über herstellerübergreifendes Equipment hinweg und Telemetrie auf Hardware-Ebene neben der Netzwerksicht. Ohne das korreliert das Modell unvollständige Daten, und seine Schlussfolgerungen erben die Lücken.
Sollte AI-gesteuerter Betrieb automatisch auf Netzwerkfehler reagieren?
Das ist eine Grundsatzentscheidung, keine technische. Ein gängiger Ansatz lässt die Plattform erkennen, korrelieren und empfehlen, während jede Änderung am laufenden Netzwerk den Freigabe- und Change-Prozess der Organisation durchläuft und die Aktion für Audits protokolliert wird.
Welche Sensaka-Produkte decken AI-gestützten Netzwerkbetrieb ab?
Network Monitoring liefert die Geräte-, Interface-, Topologie- und Ereignisebene. SmartBSM ergänzt darauf intelligente Alarmkorrelation, Ursachenanalyse, Kapazitätsanalyse und Business-Service-Mapping, und die Seite zu AI Operations beschreibt, wie ebenenübergreifende Korrelation Netzwerkereignisse mit Hardware-, Storage- und Anwendungskontext verknüpft.
Weitere Themen: AIOps-Anwendungsfälle, AIOps-Anomalieerkennung im Vergleich, was ist AIOps und beste Netzwerk-Monitoring-Tools.