NetBrain Gründer und CEO Lingping Gao präsentierte seine Think-Tank-Session „Hidden Challenges of Network Automation in the SDN Age and Beyond“ auf der Cisco Live 2018 in Orlando. Dieser Beitrag fasst seine Präsentation zusammen.
Was sind unsere größten Herausforderungen bei der Netzwerkautomatisierung? Ich spreche von den heutigen realen Netzwerkumgebungen – nicht von zukünftigen Herausforderungen. Es geht um unsere aktuellen, täglichen Arbeitsabläufe und Aufgaben: Fehlerbehebung, Änderungsmanagement, Sicherheit und Dokumentation in SDN-, Multi-Cloud- und Hybridnetzwerken.
Es gibt zwei grundlegende Dinge, die die Netzwerkautomatisierung zu einer Herausforderung machen. Das erste ist das Netzwerk selbst. Netzwerke sind heute wirklich komplex. Wir haben gerade die Virtualisierung hinter uns, dann kommen softwaredefinierte Netzwerke wie Cisco ACI und jetzt haben wir SD-WAN. Das zweite sind unsere Tools und Daten. Wir verwenden viele Tools – Ticketsysteme wie ServiceNow, 24×7-Überwachungslösungen, Splunk, SEIM und IDS und sogar APM. Jedes Tool erledigt seine eigene Aufgabe, funktioniert aber auf einer „Insel“. Wir haben am Ende viele Datensilos. So viele Tools mit einer Fülle von Daten bedeuten, dass die Automatisierung der Fehlerbehebung oder des Änderungsmanagements nicht so einfach ist.
Abgesehen davon gibt es 5 „versteckte“ Herausforderungen der Netzwerkautomatisierung für die alltägliche praktische Netzwerkautomatisierung, die ich im Laufe der Jahre gelernt habe.
Wenn Menschen „Netzwerkautomatisierung“ hören, haben sie oft eine von zwei Reaktionen. Entweder sagen sie: „Das ist es nicht wert“, oder sie denken: „Du versuchst mir meinen Job wegzunehmen.“ Im ersten Fall glauben Netzwerkmanager, dass sie viel Geld ausgeben werden, ohne eine große Rendite für ihre Investition zu erzielen. Sie möchten nicht daran denken, eine weitere Lösung zu kaufen, Zeit damit zu verbringen, eine neue Vorgehensweise zu finden oder ein weiteres Skript zu schreiben. Am anderen Ende hören einige Netzwerkingenieure – in der Regel die NOC-Leute der ersten Ebene – „Jobeliminierung“, wenn Sie das Wort „Automatisierung“ sagen.
Automatisierung lohnt sich und wird Ihnen nicht Ihren Job wegnehmen. Sie stellt die Gleichung auf den Kopf: Automatisierung beseitigt die unrentablen Aufgaben. Automatisierung kann und wird die Arbeit der Menschen nicht überflüssig machen. Aber sie beseitigt all die Sackgassenarbeit, die niemand machen will. Dadurch wird Zeit für alle frei, um anspruchsvollere Aufgaben zu übernehmen.
In den heutigen Netzwerken reicht Scripting nicht mehr aus. Jeder, der ein Python- oder Java-Skript geschrieben hat, weiß, dass die größte Herausforderung bei der Netzwerkautomatisierung bei Skripten nicht darin besteht, sie zu schreiben. Es pflegt sie. Sie haben einmal ein Skript geschrieben, aber dann, wenn sich das Netzwerk ändert, müssen Sie viel Debugging durchführen. Und das Teilen dieses Skripts mit anderen Leuten ist nicht so einfach.
Auch heute noch hört man viel darüber, wie Netzwerker Programmierer werden müssen. Ich sehe nicht wirklich, dass es für uns ein natürlicher Schritt ist, vom Netzwerktechniker zum Entwickler zu werden – oder eine Lösung für die Netzwerkautomatisierung.
Was meinen wir mit „Wann muss ich den Knopf drücken?“? Die Leute denken, dass wir bei der Automatisierung alles einmal schreiben, dann loslegen und alles von selbst erledigt wird. Aber in der realen Welt funktioniert das nicht so. Irgendjemand irgendwo muss diesen Teil der Automatisierung auslösen – zur Fehlerbehebung, für das Änderungsmanagement, für die Sicherheit usw. Wenn es mitten in der Nacht zu einem Ausfall kommt, wer startet dann die Automatisierung, die das Problem diagnostiziert? Und wann? Heute ist das eine große Herausforderung für die Netzwerkautomatisierung, die wir lösen müssen.
Wir bewegen uns hin zu Hybridnetzwerken. Ob wir es wollen oder nicht, es werden immer mehr ACI-, NSX- und andere SDN-basierte Rechenzentren entstehen. Auch SD-WAN wird immer wichtiger. Das traditionelle Netzwerk, mit dem wir uns gerade erst vertraut gemacht haben, reicht nicht mehr aus. Gilt für die Automatisierung in einem traditionellen Netzwerk meist das Prinzip „einmal schreiben, einmal verwenden“? Genau damit müssen wir uns heute ständig auseinandersetzen. Man könnte zwar sagen: „Okay, wir trennen die Automatisierung für das traditionelle Netzwerk vom neuen Netzwerk.“ Aber was ist mit dem Datenfluss? Wie gehen wir mit Verzögerungen beim Übergang vom traditionellen Netzwerk zum SDN um? Wir müssen also herausfinden, wie wir innerhalb des Hybridnetzwerks automatisieren können – genau wie in einem Netzwerk mit mehreren Anbietern.
Wir haben bereits viele Tools – oder Lösungen. Aber jedes Tool spricht seine eigene Sprache; Sie sind ihre eigene „Dateninsel“. Sie haben ein Leistungsüberwachungstool, das nicht mit dem Ereignisverwaltungstool kommuniziert, das nicht mit dem Angriffserkennungssystem kommuniziert, und so weiter. Alle wichtigen Informationen, die Sie benötigen – gebündelt – sind in Datensilos voneinander isoliert.
Wie können wir diese Herausforderungen also bewältigen? Wir haben versucht, die Hardware aufzurüsten, die Software zu ändern und die Mitarbeiter auszutauschen – das ist nicht die Lösung. Wir brauchen eine Automatisierung, die anders denkt. Wir brauchen adaptive Automatisierung.
Das Konzept der adaptiven Automatisierung ist nichts Neues. Im Bereich Maschinenbau gibt es eine CAD-Lösung (Computer Aided Design); die Elektronikindustrie hat EDA (Electronic Design Automation); In der Vernetzung gibt es etwas Ähnliches: Wir nennen es Adaptive Automation. Die Idee dahinter ist, dass Sie, wenn Sie eine Reihe von Aufgaben haben, die Sie in einem komplexen Netzwerk ausführen müssen und die verschiedene Dateninseln integrieren müssen, zwei Dinge benötigen, um das Problem zu lösen.
Eine Möglichkeit ist die Verwendung einer Karte. In CAD- oder EDA-Anwendungen ist das Diagramm (oder die Karte) eigentlich ein Datenmodell, das Sachverhalte visuell abstrahiert. Man benötigt also eine Karte, um die Aufgabe abstrahieren zu können. Mithilfe einer Karte lässt sich der Umfang der Aufgabe definieren.
Das andere Puzzleteil ist a runbook – kein Skript – mit dem Sie organisieren können, was Sie tun müssen. Das runbook erlaubt Ihnen, die zu definieren Schritte Ihrer Aufgabe.
Zusammen verwirklicht die Karte die Idee, Ihr Netzwerk zu dokumentieren, eine zentrale Ansicht Ihres Netzwerks zu erstellen und die runbook realisiert „Just-in-Time“-Automatisierung und „Write Once, Execute Everywhere“-Fähigkeit.
Diese adaptive Automatisierung behandelt die Netzwerkautomatisierung Schritt für Schritt, Schritt für Schritt, für die 5 oben genannten Herausforderungen. Schauen wir uns ein Beispiel an, wie das aussehen würde.
Angenommen, Sie erhalten eine Benachrichtigung in Ihrer Ereigniskonsole – beispielsweise ein Ticket in ServiceNow, dass eine App langsam ist. Im Adaptive Automation-Framework wird als Erstes eine „Just-in-Time“-Automatisierung über die API ausgelöst, um eine Dynamic Map von dieser Langsamkeit. Dann eine „Level-0-Diagnose“ runbook tritt automatisch in Aktion, um Leistungsdaten, CLI-Befehlsdaten oder Daten aus Ihrem Leistungsverwaltungstool zu sammeln und die Informationen an das ServiceNow-Ticket anzuhängen. Dies alles geschieht automatisch in dem Moment, in dem das Ereignis erstellt wird, wenn die Langsamkeit erkannt wird – beispielsweise mitten in der Nacht –, ohne dass ein menschliches Eingreifen erforderlich ist. (Deshalb wird es als „Level-0-Diagnose“ bezeichnet.) Das ist Schritt 1.
Schritt 2: Morgens, wenn Sie zur Arbeit kommen, gibt es das ServiceNow, das mitten in der Nacht erstellt wurde. Jetzt führen Sie verschiedene Slowness-Performance- oder QoS-Troubleshootings durch runbookS. Diese Runbooks wurden von Ihren leitenden Netzwerkingenieuren auf der Grundlage ihres Know-hows, sowohl ihres Domänenwissens als auch ihrer Fachkompetenz, erstellt. Falls erforderlich, kann der Level 1-Techniker das Problem dann an einen Level 2- oder 3-Techniker eskalieren. Wenn das Ticket eskaliert wird, wird alles, was der Level 1-Techniker getan hat, in der erfasst runbook So muss der Techniker der nächsten Stufe das Rad nicht neu erfinden und dieselben grundlegenden Diagnosen erneut durchführen. Um tiefer in das Problem einzudringen, können Sie eine einzige Glasscheibe nutzen, um Informationen aus allen anderen Tools (Splunk, Protokolldateien, Lösungen zur Leistungsüberwachung rund um die Uhr) anzuzeigen.
Sobald Sie das Problem identifiziert haben – und das nimmt etwa 80 % unserer Fehlerbehebungszeit in Anspruch – können Sie das Problem beheben. Das Beheben von Problemen ist ziemlich einfach: Ändern Sie möglicherweise die QoS-Konfiguration, leiten Sie den Datenverkehr möglicherweise um. Und Sie haben ein Automatisierungstool, das die Änderungen nicht nur übertragen, sondern auch die Auswirkungen dieser Änderungen automatisch überprüfen kann. Dies ist eigentlich wichtiger, als die Änderungen automatisch zu pushen.
Mit Adaptive Automation können Sie dieses Problem dann proaktiv überwachen, sodass Sie es sofort erfassen können, wenn es erneut auftritt (was wahrscheinlich der Fall sein wird), ohne darauf warten zu müssen, dass jemand eine Entscheidung darüber trifft, wie es angegangen werden soll. Die Schritte Ihres Level 2-Ingenieurwerkzeugs können in a kodiert werden runbook die ausgelöst werden können, um automatisch rund um die Uhr ausgeführt zu werden.