Neues im Netzwerk-Management & -Monitoring Entwicklungs-Treiber im Netzwerk-Management

Anbieter zum Thema

SolarWinds EMEA Headquarters

WatchGuard Technologies GmbH

Heidelberg iT Management GmbH & Co. KG

Soft & Cloud GmbH

Evolution bedeutet Veränderung, und nichts verändert sich so schnell wie Technologien. Und Veränderung gehört selbstverständlich auch zur IT. Wir fassen jüngste und zukünftige Herausforderungen aus den Bereichen Netzwerk-Management und Netzwerk-Monitoring zusammen.

Im Bereich von klassischen IT-Netzwerken ist die Entwicklungsgeschwindigkeit zwar nicht so rasant wie zum Beispiel bei Anwendungen oder Datenspeichern, jedoch sind, neben immer schnelleren Verbindungen wie 400G im Core, auch Quantensprünge wie Netzwerk-Virtualisierung/SDN ein Thema der Gegenwart. Einhergehend allerdings entsteht Komplexität, wenn Multi-Cloud-Umgebungen dem traditionellen Netzwerk quasi den Boden unter den Füssen wegziehen. Um den Anforderungen auch weiterhin zu entsprechen, muss auch beim Netzwerk-Management/Monitoring eine permanente Weiterentwicklung stattfinden.

Was hat Netzwerk-Monitoring in der Vergangenheit bewegt?

Dazu gibt es eine kurze Entwicklungsgeschichte. Rückblickend haben wir uns von „Hallo, bist du noch da?“-ICMP-Paketen zum Sammeln von KPI durch Standards wie SNMP und WMI bewegt, haben asynchrone Nachrichten wie Syslog zurate gezogen und versucht, das Ganze irgendwie in Relation zu bringen. Mit der Zeit kam Logik ins Spiel (Routingloop entdeckt – wurden Konfigurationen verändert?), wurde Automation hinzugefügt (vorherige Konfiguration wiederherstellen) und es wurde Unterstützung für mehr Dynamik, zeitnahe Informationen und Aktionen gewährleistet.

Eine der aktuellen Herausforderung ist, dass immer mehr Bereiche in der IT zusammenwachsen. Das ist zum einen eine Schwierigkeit für den Anwender – den Technikexperten – aber natürlich auch für die Werkzeuge, die genutzt werden.

Obgleich in vielen traditionellen deutschen Unternehmen und vor allem im öffentlichen Sektor das Warten von Java-6-Anwendungen die Realität darstellt und lebenserhaltender Maßnahmen bedarf, ist man an anderer Stelle schon etwas weiter. Beim „New Business“ ist es unerheblich, von wo eine Anwendung bereitgestellt wird und von wo aus oder wie darauf zugegriffen wird. Diese Unternehmen sind von DevOps angetrieben und, überspitzt dargestellt, werfen Entwickler einen Code auf irgendeine Plattform und haben wenig bis keine Kenntnis von Themen wie L3-Routing, Load-Balancing oder gar Security.

Hier kann der gelernte Netzwerk-Admin helfen. Aber wie soll er das, wenn er nicht weiß, von wo Daten wohin gesendet werden oder wie üblicherweise der Zugriff erfolgt?

Im Bereich der Security bei der Nutzung von Clouds spricht man von „shared responsibility“, und dies sollte auch im Bereich der Netzwerkadministration gelten. Man kann vom Netzwerk-Admin nicht erwarten, die komplette Cloud zu verwalten, aber ein Verständnis der dortigen Eigenarten zu Themen wie Site-to-Site-Verbindungen sollte vorhanden sein. Darüber hinaus ist es hilfreich, wenn man Anwendungen, die einem vom traditionellen On-Prem-Netzwerk bereits bekannt sind, zur Kontrolle und Überwachung auch für Clouds nutzen kann. Zum einen muss nicht noch ein weiteres Werkzeug gelernt werden, zum anderen erleichtert dies auch die Fehlersuche durch die automatische Anzeige von Relationen.

Moderne Probleme erfordern moderne Lösungen

Moderne Lösungen nutzen vermehrt APIs zur Kommunikation mit Geräten oder Umgebungen, um beim Cloud-Beispiel zu bleiben. Sowohl Azure als auch AWS bieten verschiedene Möglichkeiten zur Kommunikation, aber idealerweise ist es für den Netzwerk-Admin nicht nötig, hier tiefer einzutauchen. Die verfügbaren Überwachungs-Werkzeuge erledigen das von allein.

Die gleichen Tools sind zudem in der Lage, Informationen von verschiedenen Schichten zu korrelieren. Auf den ersten Blick könnte es dem Netzwerk-Profi egal sein, dass ein Switch Pakete für einen E-Mail-Server verschiebt. Aber, wenn es irgendwo ein Problem mit der Anwendung gibt, was hört man zuerst? „Das Netzwerk ist langsam“. In den meisten Fällen ist diese Aussage falsch, und wir wissen das. Aber wir müssen es beweisen.

Es gibt verschiedene Methoden, durch die eine Monitoring-Lösung eine Art Bewusstsein für Anwendungen entwickeln kann. Klassisch hat man dazu ein IPFIX-kompatibles Protokoll wie zum Beispiel Netflow genutzt, jedoch kommt man damit häufig an seine Grenzen. Etwas eleganter ist DPI (Deep Packet Inspection), wo Anwendungen anhand der Form der Datenpakete erkannt werden.

Aktuell sehen wir, dass Anwendungsinformationen direkt von Servern abgegriffen und automatisch Abhängigkeiten erkannt werden. Als Beispiel: Ein Agent – on-prem oder in der Cloud – erkennt, dass ein Prozess, der vielleicht zu einem Webserver gehört, an einem Port lauscht, und sammelt Informationen über die externe IP-Adresse, die Daten sendet oder anfordert. Der gleiche Agent sitzt auf der externen IP und entdeckt dort eine Datenbank, auf die über den Webserver zugegriffen wird. Diese Datensätze in einem Diagramm zusammenzufügen, ist keine große Kunst, aber erlaubt es, auf einen Blick zu sehen, ob ein Problem vom Webserver, der Datenbank oder der Verbindung dazwischen verursacht wird.

Ganz unabhängig davon, wo ein Problem lokalisiert wird – nach dem Beantworten der Frage, wessen Problem es eigentlich ist – , startet der Prozess der Fehlerbehebung. Hier kommen die verschiedenen IT-Teams wieder zusammen, da Troubleshooting ein generischer Prozess ist.

Tickets werden angelegt, müssen dokumentiert und ständig aktualisiert werden, nach dem Leisten von „erster Hilfe“ (es läuft wieder) kommt die Ursachenforschung und, ganz wichtig, ein Sicherstellen, dass die gleiche Situation nicht noch einmal eintritt. Falls man eine zukünftig fehlerfreie Funktion auf Grund zu vieler beweglicher Teile nicht zu hundert Prozent sicherstellen kann, ist es unbedingt erforderlich, die notwendigen Schritte zum Lösen in eine Knowledge-Datenbank einzupflegen, um die Dauer, ein System/eine Dienstleistung wieder lauffähig zu bekommen, zu minimieren. Mean time to Resolve, MTTR, lautet das Stichwort. Auch hier hilft wieder eine moderne Lösung, die mit einem oder mehreren IT-Service-Management-Systemen kommunizieren kann oder vielleicht sogar integriert ist.

Sobald ein Problem eintritt, wird nicht nur das korrekte Team aktiviert, sondern automatisch ein Ticket mit allen notwendigen Informationen angelegt. Bei komplexen Fragen ist eine ITSM-Plattform der perfekte Platz, um verschiedene IT-Teams zu involvieren, ohne die Übersicht zu verlieren. Ebenso wird das Berichtswesen vereinfacht – und schließlich eine Knowledge-Datenbank ermöglicht.

Was bringt die Zukunft?

Im Moment werden eigentlich zu viele KPI zu oft gesammelt und zu lange behalten. Das ist der zugrundeliegenden Komplexität geschuldet. Die Datenpunkte werden genutzt, um Korrelation anzuzeigen und eine sichere Aussage treffen zu können, ohne nur zu vermuten.

Wir befinden uns gerade in der Phase, wo übergeordnete Telemetrie-Daten gesammelt werden, um etwa sagen zu können „dieses Problem ist in den letzten sechs Monaten viermal aufgetreten, und der durchschnittliche Zeitraum von der Erkennung bis zum Schließen des Tickets liegt bei drei Stunden.“

In Zukunft kann auf Grund der gesammelten Daten die Wahrscheinlichkeit berechnet werden, ob und wann es voraussichtlich zum nächsten Ausfall kommen wird. Marketing-Abteilungen werfen hier die Schlüsselworte ML und KI ein. Ebenso brauchen wir keine Dashboards mit hunderten von Diagrammen mehr. Solange der Datendurchsatz eines Geräts unterhalb eines automatisch berechneten Schwellwerts bleibt, ist die tatsächliche Datenmenge nur für das Berichtswesen interessant.

Solange ein Switch brav seine Pakete verschiebt, ist er ein guter Switch, und Details interessieren nicht. Die Monitoring-Lösung könnte daher einfach eine große, grüne Kugel anzeigen und im Falle eines Problems automatisch auf das relevante rote Unterelement wechseln.

Über den Autor

Sascha Giese ist Head Geek bei SolarWinds.

(ID:46749662)