BillionPhotos.com - stock.adobe.
Architektur zur Netzwerkautomatisierung in 5 Phasen aufbauen
Die Implementierung einer Architektur zur Netzwerkautomation umfasst mehrere Elemente. Dazu zählen eine Core-Orchestrierungs-Engine, diverse Datenbanken und Netzwerk-Testing.
Die meisten Netzwerkmanager sind natürlich an Netzwerkautomatisierung interessiert. Aber wie sollten Sie die Architektur für die Netzwerkautomation planen? Und um welche Elemente sollten Sie sich zuerst kümmern? In diesem Artikel stellen wir eine Architektur vor und geben Tipps, in welcher Reihenfolge die einzelnen Elemente implementiert werden können.
Die Zahl der Architekturen zur Netzwerkautomatisierung dürfte der Anzahl der Netzwerke entsprechen. Der Trick besteht darin, eine Automatisierungsarchitektur zu erstellen, die unabhängig von irgendeinem Produkt ist, ganz gleich, ob kommerziell oder Open Source.
Beginnen Sie mit den Anforderungen, die architektonische Funktionen widerspiegeln, zum Beispiel die Automations-Engine. Jede dieser Funktionen besitzt Inputs und Outputs, die bestimmen, wie die einzelnen Elemente interagieren.Verfolgen Sie dann einen stufenweisen Ansatz, der die Automatisierungsfähigkeiten in dem Maße steigert, wie die neuen Technologien und Prozesse in der vorangegangenen Phase integriert und übernommen werden.
Die architektonischen Funktionen und Phasen
Wie so vieles andere im Leben folgen auch Implementierungen der Evolution vom Einfachen zum Komplexen. Die frühen Phasen bieten einfache Funktionen, die reine Lesevorgänge auf Netzwerkgeräten durchführen. Spätere Phasen ermöglichen die Änderung von Gerätekonfigurationen. Die letzten Phasen schließlich automatisieren komplette Prozesse, etwa Tests auf virtuellen Instanzen des Produktionsnetzwerks vor dem finalen Rollout. Einige Funktionen lassen sich entsprechend den Anforderungen des Unternehmens auch in andere Phasen verschieben.
Phase 1: Start von Nur-Lese-Prozessen
Phase 1 ermöglicht eine grundlegende Funktionalität durch drei Funktionen: das System für die Automationsorchestrierung, die Benutzeroberfläche (User Interface, UI) und die Geräteabstraktionsschicht. Phase 1 beginnt mit automatisierten Prozessen, die nur lesend zugreifen. Diese archivieren Konfigurationen, sammeln Troubleshooting-Daten und validieren Netzwerkkonfigurationen anhand von Vorlagen (Templates). Die Elemente in Phase 1 umfassen:
- Automationsorchestrierung. Die Core-Orchestrierungs-Engine steuert den Automatisierungsprozess. Sie enthält Skalierungsfunktionen, wie parallele Verarbeitung und verteilte Agenten. Für diese Funktion sind mehrere kommerzielle Produkte und Open-Source-Pakete verfügbar.
- Benutzeroberfläche. Kommerzielle Produkte verfügen in der Regel über eine GUI und eine API, was für spätere Phasen der Automation wichtig ist. Open-Source-Projekte bieten üblicherweise eine Befehlszeile für die Administration und eine API zur Programmsteuerung.
- Abstraktionsschicht. Die Abstraktionsschicht ermöglicht ein Modell, das die Unterschiede zwischen den Geräteanbietern verbirgt, sodass sich die Netzwerkgeräteschnittstelle stark vereinfachen lässt. Die Abstraktionsschicht kann in einige Orchestrierungssysteme integriert sein.
Phase 2: Hinzufügen einer Quelle der Wahrheit im Netzwerk
In Phase 2 kommen eine NSoT-Datenbank (Network Source of Truth) und eine Schnittstelle für ein Trouble-Ticketing-System hinzu. Die Elemente in Phase 2 umfassen:
- NSoT-Datenbank. Die NSoT speichert Informationen über den gewünschten Netzwerkstatus, den das System zur Automationsorchestrierung nutzt, um den Netzwerkbetrieb zu validieren und – in späteren Phasen – zu korrigieren. Zu diesen Daten können Adresszuweisungen, benachbarte Netzwerkprotokolle sowie der Betriebszustand und die Erreichbarkeit der Schnittstellen gehören.
- Automatisches Trouble Ticketing. Eine Schnittstelle für ein Trouble-Ticketing-System ermöglicht es dem System zur Automationsorchestrierung, Tickets zu erstellen, wenn der Netzwerkstatus und die NSoT voneinander abweichen. Die Problembehebung wird anfangs manuell erfolgen, in späteren Phasen aber zunehmend automatisiert ablaufen.
Phase 3: Konfigurationsvorlagen und -skripte speichern
Mit Phase 3 beginnt der Übergang zu einem IaC-Betriebsmodell (Infrastructure as Code). Die Elemente in dieser Phase umfassen:
- Repository für das Quellcodemanagement. Ein Quellcode-Repository, typischerweise basierend auf Git, wird genutzt, um Konfigurationsvorlagen, gespeicherte Konfigurationen und Skripte abzulegen. Es ist eng mit dem System zur Automationsorchestrierung integriert, um Gerätekonfigurationen von gespeicherten Vorlagen und NSoT-Daten zu erstellen. Beispielsweise lassen sich dadurch die Konfigurationen für das gesamte Netzwerkequipment eines Data Center Pods generieren.
- Workflows. In Phase 3 beginnt die Umstellung der Workflows von manuell auf automatisch. Die Workflows können mit Skripten, die im Quellcode-Repository gespeichert sind, instanziiert werden. Kommerzielle Produkte bieten häufig mehrere Mechanismen, um die Workflows zu steuern, zum Beispiel grafische Editoren und APIs.
- Chatbots. Chatbots ermöglichen es dem Automationssystem, Workflow- und Statusinformationen an UC-Chaträume (Unified Communications) zu übertragen. Dort arbeitet das Netzwerkpersonal gemeinsam an Implementierung und Fehlerbehebung. Hierbei handelt es sich um einen besonders effektiven Mechanismus für verteilte Netzwerkteams, deren Mitglieder auf diese Weise remote arbeiten können.
Phase 4: Implementierung von Netzwerk-Feedback
Phase 4 bietet einen Feedback-Mechanismus vom Netzwerk. Bis zu diesem Punkt hat das Netzwerk nur wenig Feedback geliefert, sieht man einmal von Validierungs-Checks anhand von NSoT-Daten ab. Die Elemente in Phase 4 umfassen:
- Telemetrie und Monitoring. In der Vergangenheit basierte das Netzwerk-Monitoring auf dem Simple Network Management Protocol (SNMP). Modernere Implementierungen setzen hingegen auf Streaming-Telemetrie. Netzwerke werden für geraume Zeit beide Methoden nutzen müssen.
- Monitoring- und Managementdatenbanken. Die Überwachungsdaten müssen irgendwo gespeichert werden. Das geschieht entweder in einer relationalen Datenbank (für Beziehungsdaten wie Gerätetyp und Interface-Liste) oder in einer Zeitreihendatenbank (für Interface-Performance-Variablen).
- Aktions-Trigger. Netzwerk-Monitoring ist nur dann von Vorteil, wenn die Ergebnisse auch zu Reaktionen führen. Aktions-Trigger nutzen entweder Regelsätze oder Machine Learning, um Anomalien zu erkennen, Alarme auszulösen und Trouble Tickets zu eröffnen. Fortgeschrittenere Implementierungen lösen automatisierte Workflows aus, um die Problembehebung ohne menschliche Eingriffe zu beginnen, etwa alternatives Routing um einen ausgefallenen Link herum.
Phase 5: Automatisieren der Änderungstests und der -validierung
In Phase 5, der letzten in der Architektur, geht es darum, Change Testing und Validierung zu automatisieren. Diese Phase umfasst:
- Virtuelles Netzwerk-Testing. Ein wesentlicher Treiber der Network Change Control ist die Methode, eine Änderung im Labor zu testen, bevor sie in der Produktionsumgebung eingesetzt wird. Das Labor nutzt virtuelle, per Software simulierte Geräte, um die Schlüsselparameter des Produktionsnetzwerks zu modellieren. Beabsichtigte Änderungen instanziieren das virtuelle Netzwerk, führen Pre-Change-Tests durch, um zu überprüfen, ob das Labor wie vorgesehen funktioniert. Sie wenden außerdem die Änderung an und führen Post-Change-Tests durch, um zu sehen, ob das gewünschte Ergebnis erreicht wurde.
- Change Validation Testing. Wenn das virtuelle Netzwerk-Testing erfolgreich verläuft, kann die Änderung auf das Produktionsnetzwerk angewendet werden. Die Freigabe folgt dem gleichen dreistufigen Prozess: Validierung des Pre-Change-Status, Anwenden der Änderung und nachfolgend Post-Change-Validierung des resultierenden Zustands.
Das Endziel
Die in diesem Artikel beschriebene Architektur für die Netzwerkautomatisierung ist als Rahmen zu verstehen. Passen Sie sie entsprechend Ihren Bedürfnissen und der Funktionalität der von Ihnen ausgewählten Tools an.
Das Ziel besteht letztlich darin, einen Continuous-Integration-, Continuous-Delivery- und Continuous-Deployment-Prozess zu gestalten, in dem kleine, klar definierte Netzwerkänderungen nur nach dem Bestehen von strengen Tests automatisch bereitgestellt werden. Dieses Verfahren, das als NetOps oder NetDevOps bezeichnet wird, ermöglicht es Ihnen, Ihr Netzwerk auf Infrastructure as Code zu migrieren und dabei viele der gleichen Konzepte und Techniken wie bei der erfolgreichen Methoden für die Softwareentwicklung zu nutzen.
