Die Rolle des Netzwerkingenieurs entwickelt sich weiter, aber bevor Sie mit den Augen rollen und sagen: „Oh nein, kein weiterer Artikel zur Netzwerkautomatisierung“, hören Sie mir zu. Es gibt einige großartige Artikel, in denen untersucht wird, wie die Netzwerkautomatisierung Teil dieses Wandels ist, aber seit ich die VAR-Welt vor ein paar Jahren verlassen habe und intern in einigen größeren Unternehmen arbeite, scheint sich meine eigentliche tägliche Arbeit mehr und mehr zu konzentrieren mehr zu einem: Analytik.
Analytics ist die Sammlung und Interpretation von Daten, und Netzwerkanalyse ist die Sammlung und Analyse von Daten aus unserer Netzwerkinfrastruktur, insbesondere in Bezug auf die Anwendungsleistung. Ich war schon immer in relativ traditionellen Rollen als Netzwerktechniker tätig, daher beschäftige ich mich nicht mit der Analyse von Daten, nur weil ich Daten liebe. Stattdessen möchte ich diese Informationen verwenden, um Muster, Korrelationen und so weiter zu finden aussagekräftig und umsetzbar um das Netzwerk irgendwie zu verbessern.
Die Veränderung für mich in den letzten paar Jahren hat dazu geführt, dass ich mich weniger darauf konzentriere, wie man eine Rechenzentrumskernumschaltung konfiguriert, und mehr darauf, herauszufinden, was wirklich tagtäglich im Netzwerk vor sich geht. Dies hatte insbesondere mit der Fehlerbehebung bei schlechter Anwendungsbereitstellung, Informationssicherheit und Kapazitätsplanung zu tun. Und all das erforderte Netzwerkdatenanalysen.
Kurz nachdem ich eine Stelle bei einem großen Unternehmen angetreten hatte, erhielt ich eine E-Mail von einem Wissenschaftler, der die High-Performance-Computing-Cluster seines Teams leitete. Jede Nacht etwa zur gleichen Zeit fiel die Datenübertragung zu unseren externen Kunden aus und dauerte dann viele Minuten, bis sie wiederhergestellt war. Diese Wissenschaftler sammelten den ganzen Tag über eine riesige Menge atmosphärischer Daten, die sie dann für Kunden analysierten, die die Berichte, die Rohdaten oder beides gekauft hatten. Einige dieser Kunden waren sehr große wissenschaftliche Einrichtungen, die diese äußerst zeitkritischen Informationen über FTP abgerufen haben.
Die Anwendung, die den Cluster verwaltete, befand sich auf einem Bare-Metal-Server, der sich oben im Rack befand und über eine proprietäre Konnektivität mit dem Cluster verbunden war, aber auch zu Verwaltungszwecken und zur Bereitstellung der fertigen Berichte mit dem LAN verbunden war. Der Fehler trat bei mehreren Kunden auf, daher habe ich abgetan, dass das Problem auf ihrer Seite lag. Es musste bei uns sein. Auf einem unserer Hosts, dem Cluster-Controller oder irgendwo in unserem Netzwerkpfad ist etwas passiert.
Der leitende Wissenschaftler übernahm den Vorfall und überprüfte, ob die Anwendung und die Server ordnungsgemäß funktionierten. Auf seiner Seite schien alles in Ordnung zu sein, also vermutete er ein Netzwerkproblem. Wir konnten keine Netzwerkaktivitäten feststellen, die einen Konflikt verursacht hätten, also habe ich mir zunächst die Konfiguration aller Netzwerkgeräte im Pfad angesehen. Ich habe mich bei Switches, Firewalls und Routern angemeldet, aber nichts Ungewöhnliches gesehen.
Was war hier los? Die Protokolle würden die Antwort enthüllen. Mit der Software, die wir damals hatten, sah ich, dass wir sehr wenige Informationen von sehr wenigen Geräten sammelten. Es gab nicht viel mehr zu sehen. Wir brauchten aussagekräftige Informationen. Sicher, ich hätte die ganze Nacht an Geräten herumstöbern können, um in Echtzeit zu sehen, was vor sich geht, aber ich wusste, dass ich nicht in der Lage sein würde, so einfach irgendetwas zu korrelieren. Stattdessen habe ich unser Datenerfassungstool so konfiguriert, dass es alles im Netzwerk erfasst. Ich habe SNMP auf einigen Geräten konfiguriert, NETFLOW auf anderen, und für diejenigen, die beides nicht unterstützen, habe ich das Erfassungstool so konfiguriert, dass es diese IPs kontinuierlich anpingt und ihre offenen Ports scannt.
Nach einigen Tagen des Telefonierens, Googelns und Chattens mit dem leitenden Wissenschaftler wurde ein Kunde sehr ungeduldig und wütend, dass seine Importe fast jede Nacht fehlschlugen. Dies wurde zu einem hochkarätigen Thema und zu einer Top-Priorität für mich. Ich habe der Datenerfassungssoftware mehr Speicherplatz gewidmet und sie eine Woche laufen lassen. Als ich mir die Ergebnisse ansah, entdeckte ich jede Nacht ungefähr zur gleichen Zeit eine ungewöhnliche Spitze in der CPU des Anwendungscontrollers – zu der Zeit, als das Problem begann. Das war ein guter Anfang, aber es gab keinen Grund, den der leitende Wissenschaftler auf dem Server selbst finden konnte, der dies verursachen würde. Die Netzwerkverbindungen sahen keine ungewöhnliche Überlastung, und keiner unserer Switches im Pfad zeigte überhaupt etwas Ungewöhnliches.
Da unser Erfassungstool mittelmäßig war, musste ich einige Stunden damit verbringen, selbst über all diese neuen Daten zu brüten. Mein Kollege hat mir geholfen, indem er ein Skript geschrieben hat, um nach CPU-, Link- und Speicherauslastung zu suchen und das dann in einem grafischen Format über eine Art cleveren E-Mail-Konnektor darzustellen. Nach all dieser Zeit und Mühe erschien eine rote Flagge, die uns auf einen Zugriffsschalter hinwies, der jede Nacht eine CPU-Spitze hatte. Ich meldete mich am Switch an und sah, dass die Betriebszeit einen wahrscheinlichen Neustart zur schicksalhaften Zeit in der vergangenen Nacht widerspiegelte.
Bevor ich die Arbeit verließ, ersetzte ich den Schalter, stellte sicher, dass die IP-Adresse eines der Widgets auf unserem Überwachungs-Dashboard war, und richtete einen einfachen dauerhaften Ping ein. Mein Kollege hat ein Skript geschrieben, um uns eine E-Mail zu senden, wenn die Pings abfallen, und wir haben die Überwachungssoftware so eingerichtet, dass sie eine Warnung sendet, wenn die CPU-Spitzenwerte auftreten. Zu unserer Bestürzung erhielten wir am nächsten Morgen E-Mails, die uns darüber informierten, dass Pings abgefallen waren, und Benachrichtigungen von der Erfassungssoftware, dass die CPU anstieg. Wir haben den Schalter überprüft – er war eingeschaltet. Ich habe die Betriebszeit überprüft – zeigte einen Neustart mitten in der Nacht. Wir waren uns sicher, dass die Antwort in den Daten liegt. Aber das Durcharbeiten war so mühsam und hat für unseren Kunden viel zu lange gedauert. Irgendwo darin muss ein Muster oder eine Korrelation gewesen sein, die wir nicht gefunden hatten, also suchten wir weiter. Wir brauchten einen besseren Weg, dies zu tun, aber im Moment haben wir uns so gut wie möglich durch die Verwendung der Software und der benutzerdefinierten Skripte gequält. Dann haben wir etwas gefunden. Ein unbekanntes Gerät mit einer unbekannten IP-Adresse wurde sehr gesprächig, als der Switch neu gestartet wurde. Es war keine doppelte Adresse und sie befand sich nicht im selben Subnetz, aber es passierte jede Nacht zur selben Zeit.
Das Auffinden des Geräts war einfach. Es war nicht in DNS, aber es war eine Reservierung in DHCP. Es stellte sich heraus, dass es der Controller für die Backup-Klimaanlage war, die jede Nacht eingeschaltet wurde. Dies wäre normalerweise kein Problem, aber als wir in den Serverraum gingen, stellten wir fest, dass die AC-Einheit an dieselbe PDU wie der Switch angeschlossen war. Es gab nichts anderes auf der PDU, und es war nichts, was wir uns vorher angesehen haben.
Als die AC-Einheit eingeschaltet wurde, war der Stromkreis so stark entladen, dass der Schalter neu gestartet wurde. Das war zumindest unsere Theorie. Wir verlegten den Schalter auf eine andere PDU und riefen die HLK-Mitarbeiter an. Der Schalter wurde in dieser Nacht nicht neu gestartet, und soweit ich weiß, haben die HLK-Leute ein Problem mit einem Sensor festgestellt, und der Elektriker hat das Stromproblem behoben.
Um dies herauszufinden, mussten viele Daten gesammelt und intelligent analysiert werden. An diesem Punkt arbeiten meine Netzwerktechniker-Kollegen und ich heutzutage in der Unternehmens-IT. Sicher, es gibt gelegentlich Firewall-Upgrades oder MDF-Switch-Ersetzungen, aber meistens sammle und analysiere ich Daten, um Probleme mit der Anwendungsleistung zu beheben oder an einer Informationssicherheitsaufgabe zu arbeiten.
Ich glaube nicht, dass sich die Rolle eines Netzwerkingenieurs so verändert, dass wir Programmierer und Datenwissenschaftler werden müssen, aber ich sehe einen wachsenden Trend, sehr gut darin zu sein, eine enorme Menge dynamischer Daten zu sammeln und zu analysieren vergängliche Informationen.
NetBrain haben kürzlich eine sehr vielversprechende Technologie angekündigt, die darauf abzielt, diese Analytics-Herausforderung anzugehen – sie nennen es Ausführbar Runbooks. Grundsätzlich ist a Runbook bietet eine Möglichkeit, Netzwerkdaten automatisch zu sammeln und zu analysieren. Da diese Runbooks können (von Programmierern und Nicht-Programmierern gleichermaßen) angepasst werden, sie können verwendet werden, um Analysen für jede Netzwerkfunktion durchzuführen. Das folgende Beispiel ist a Runbook das geschrieben wurde, um das OSPF-Routing-Design zu analysieren.