Die CDSM-Phase ist vorbei, aber das unkontrollierbare Verlangen zu schreiben, bleibt bestehen.

Über viele Jahre hinweg litt unser Kollege unter der Erledigung routinemäßiger Arbeiten, drückte vor Commits die Daumen und bekam zu wenig Schlaf wegen nächtlicher Rollbacks.
Doch dunkle Zeiten finden ein Ende.

Mit diesem Artikel beginne ich eine Reihe über Ich die Sicht auf Automatisierung.
Dabei werden wir die Phasen der Automatisierung, die Speicherung von Variablen, die Formalisierung des Designs, sowie RestAPI, NETCONF, YANG, YDK besprechen und viel programmieren.
Mir bedeutet, dass a) dies keine objektive Wahrheit ist, b) nicht unbedingt der beste Ansatz ist, c) meine Meinung sich sogar im Verlauf von der ersten bis zur letzten Veröffentlichung ändern kann – ehrlich gesagt habe ich vom Entwurf bis zur Veröffentlichung alles zweimal komplett umgeschrieben.

Inhalt

1. Ziele
   1. Das Netzwerk – wie ein einheitlicher Organismus
   2. Konfigurationstest
   3. Versionsverwaltung
   4. Überwachung und Selbstheilung der Dienste

2. Werkzeuge
   1. Inventarsystem
   2. IP-Adressverwaltungssystem
   3. System zur Beschreibung der Netzwerkdienste
   4. Geräteinitialisierungsmechanismus
   5. Vendor-unabhängiges Konfigurationsmodell
   6. Vendor-spezifischer Treiber für Schnittstellen
   7. Mechanismus zur Konfigurationserstellung auf Geräten
   8. CI/CD
   9. Backup- und Abweichungserkennungssystem
   10. Überwachungssystem

3. Fazit

Ich werde das ADSM in einem etwas anderen Format als SDSM führen. Große, ausführliche nummerierte Artikel werden weiterhin erscheinen, und zwischen diesen werde ich kleine Notizen aus meinem Alltag veröffentlichen. Ich werde versuchen, hier den Perfektionismus zu bekämpfen und nicht jeden Einzelnen zu polieren.

Wie lustig, dass ich den gleichen Weg ein zweites Mal gehen muss.

Zunächst musste ich selbst Artikel über Netzwerke schreiben, da es im russischen Internet keine gab.

Jetzt konnte ich kein umfassendes Dokument finden, das die Ansätze zur Automatisierung systematisiert und die oben genannten Technologien anhand einfacher praktischer Beispiele behandelt.

Vielleicht bin ich im Irrtum, also schickt mir Links zu guten Ressourcen. Doch das wird meine Entschlossenheit nicht ändern, zu schreiben, denn das Hauptziel ist es, selbst etwas zu lernen, und das Leben der anderen zu erleichtern ist ein schöner Bonus, der zur Verbreitung von Wissens beiträgt.

Wir werden versuchen, ein mittelgroßes Rechenzentrum LAN DC zu nehmen und das gesamte Automatisierungsschema zu entwickeln.
Einige Dinge werde ich praktisch zum ersten Mal gemeinsam mit Ihnen tun.

In den hier beschriebenen Ideen und Werkzeugen werde ich nicht originell sein. Dmitri Figol hat einen hervorragenden Kanal mit Streams zu diesem Thema..
Die Artikel werden in vielen Aspekten mit ihm überschneiden.

Im LAN DC gibt es 4 Rechenzentren, etwa 250 Switches, ein halbes Dutzend Router und ein paar Firewalls.
Nicht Facebook, aber ausreichend, um ernsthaft über Automatisierung nachzudenken.
Es besteht jedoch die Meinung, dass, wenn Sie mehr als ein Gerät haben, Automatisierung nötig ist.
Es ist schwer vorzustellen, dass jemand heutzutage ohne mindestens ein paar Skripte leben kann.
Obwohl ich gehört habe, dass es Firmen gibt, in denen die IP-Adressen in Excel verwaltet werden und jedes der Tausenden von Netzwerkgeräten manuell konfiguriert wird und eine einzigartige Konfiguration hat. Das kann man natürlich als moderne Kunst verkaufen, aber die Gefühle eines Ingenieurs würden sicher verletzt werden.

Ziele

Jetzt setzen wir uns maximal abstrakte Ziele:

• Das Netzwerk – wie ein einheitlicher Organismus
• Konfigurationstest
• Versionierung des Netzwerkzustands.
• Überwachung und Selbstheilung der Dienste

Später in diesem Artikel werden wir die verwendeten Mittel näher erläutern, und in den folgenden Artikeln die Ziele und Mittel im Detail.

Das Netzwerk – wie ein einheitlicher Organismus

Ein zentraler Begriff in diesem Zusammenhang, auch wenn er auf den ersten Blick nicht so bedeutend erscheint: Wir werden das Netzwerk konfigurieren, nicht die einzelnen Geräte..
In den letzten Jahren beobachten wir einen Trend, das Netzwerk als eine zusammenhängende Einheit zu betrachten, was zur Einführung von Software-Defined Networking, Intent Driven Networks und Autonomen Netzwerken.
Denn was benötigen Anwendungen global von einem Netzwerk: Verbindungen zwischen Punkt A und B (und manchmal auch von B nach A) sowie Isolation von anderen Anwendungen und Nutzern.

Und so besteht unsere Aufgabe in dieser Serie darin, ein System aufzubauen, das die aktuelle Konfiguration des gesamten Netzwerks, die bereits auf die aktuelle Konfiguration jedes Geräts gemäß seiner Rolle und Position heruntergebrochen wird.
System Netzwerkmanagement bedeutet, dass wir, um Änderungen vorzunehmen, auf das Netzwerk zugreifen, und es wiederum den erforderlichen Zustand für jedes Gerät berechnet und es konfiguriert.
So minimieren wir nahezu auf null das manuelle Arbeiten im CLI – alle Änderungen an den Geräteeinstellungen oder dem Netzwerkdesign müssen formalisiert und dokumentiert werden – und werden erst danach auf die erforderlichen Netzwerkkomponenten umgesetzt.

Das heißt, wenn wir entschieden haben, dass die Switches in Kazan ab sofort zwei Netzwerke anstelle von einem ankündigen sollen, dann

1. Dokumentieren wir zunächst die Änderungen in den Systemen.
2. Wir generieren die Zielkonfiguration aller Netzwerkgeräte.
3. Wir starten das Programm zur Aktualisierung der Netzwerkkonfiguration, das berechnet, was auf jedem Knoten entfernt werden muss, was hinzugefügt werden soll und bringt die Knoten in den gewünschten Zustand.

Dabei nehmen wir die Änderungen nur im ersten Schritt manuell vor.

Konfigurationstest

Bekanntlich, treten 80% der Probleme während der Konfigurationsänderungen auf — ein indirekter Beweis dafür ist, dass während der Neujahrsferien normalerweise alles ruhig verläuft.
Ich habe persönlich Dutzende von globalen Ausfällen aufgrund menschlicher Fehler miterlebt: falscher Befehl, im falschen Konfigurationszweig ausgeführt, Community vergessen, MPLS global auf dem Router gelöscht, fünf Geräte konfiguriert, und beim sechsten die Fehlermeldung nicht bemerkt, alte Änderungen von jemand anderem committet. Es gibt unzählige Szenarien.

Automatisierung wird uns helfen, weniger Fehler zu machen, jedoch in größerem Maßstab. So könnte man nicht nur ein Gerät, sondern das gesamte Netzwerk auf einmal lahmlegen.

Seit jeher haben unsere Vorfahren die Richtigkeit von Änderungen mit scharfem Blick, stählernen Eiern und der Leistungsfähigkeit des Netzwerks nach deren Umsetzung überprüft.
Die Vorfahren, deren Arbeiten zu Ausfällen und katastrophalen Verlusten führten, hinterließen weniger Nachkommen und sollten im Laufe der Zeit aussterben. Aber die Evolution ist ein langsamer Prozess, und deshalb prüfen bis heute nicht alle Änderungen vorher im Labor.
An der Spitze des Fortschritts stehen diejenigen, die den Testprozess der Konfiguration automatisiert haben und deren weitere Anwendung im Netzwerk. Mit anderen Worten — sie haben das CI/CD-Verfahren (Continuous Integration, Continuous Deployment) von Entwicklern übernommen.
In einem der Abschnitte werden wir besprechen, wie dies mit einem Versionskontrollsystem, wahrscheinlich GitHub, umgesetzt werden kann.

Sobald Sie sich mit dem Gedanken des Netzwerk-CI/CD angefreundet haben, wird Ihnen die Methode zur Überprüfung der Konfiguration durch deren Anwendung im Live-Netzwerk wie ein frühmittelalterlicher Unfug vorkommen. Etwa so, als würde man mit einem Hammer auf einen Sprengkopf hämmern.

Eine organische Fortsetzung der Ideen über das System des Netzwerkmanagements und CI/CD wird ein vollständiges Versioning der Konfiguration.

Versionsverwaltung

Wir gehen davon aus, dass bei jeglichen Änderungen, selbst den kleinsten, auch an einem unsichtbaren Gerät, das gesamte Netzwerk von einem Zustand in einen anderen übergeht.
Und wir führen immer den Befehl nicht auf dem Gerät aus, sondern ändern den Zustand des Netzwerks.
Lass uns diese Zustände Versionen nennen?

Nehmen wir an, die aktuelle Version ist 1.0.0.
Wenn sich die IP-Adresse des Loopback-Interfaces eines der ToR-Geräte ändert? Das ist eine Minor-Version – sie erhält die Nummer 1.0.1.
Wenn wir die Importrichtlinien für Routen im BGP überarbeiten – das ist schon etwas ernster – dann ist es 1.1.0.
Wenn wir uns entscheiden, das IGP abzulehnen und ausschließlich auf BGP umzusteigen – das ist eine radikale Designänderung – dann wird es 2.0.0.

Dabei können verschiedene Rechenzentren unterschiedliche Versionen haben – das Netzwerk entwickelt sich weiter, neue Geräte werden eingesetzt, an manchen Stellen werden neue Spine-Ebenen hinzugefügt, an anderen nicht, usw.

Über semantische Versionierung darüber werden wir in einem separaten Artikel sprechen.

Ich wiederhole – jede Änderung (außer Debugging-Befehlen) ist ein Versionsupdate. Die Administratoren müssen über alle Abweichungen von der aktuellen Version informiert werden.

Das Gleiche gilt für das Zurücksetzen von Änderungen – es handelt sich nicht um das rückgängigmachen der letzten Befehle, auch nicht um einen Rollback durch das Betriebssystem des Geräts – es geht um die Rückführung des gesamten Netzwerks auf eine neue (alte) Version.

Überwachung und Selbstheilung der Dienste

Dies ist eine selbstverständliche Aufgabe, die in modernen Netzwerken auf ein neues Niveau gelangt.
Oft praktizieren große Dienstanbieter den Ansatz, dass ein ausgefallener Dienst sehr schnell niedergeschlagen und ein neuer hochgefahren werden muss, anstatt zu klären, was passiert ist.
„Sehr“ bedeutet, dass man sich von allen Seiten intensiv mit Monitorings eindecken muss, die innerhalb von Sekunden kleinste Abweichungen von der Norm erkennen.
Und hier sind die gewohnten Metriken, wie die Auslastung der Schnittstelle oder die Verfügbarkeit des Knotens, nicht ausreichend. Auch die manuelle Überwachung durch den Bereitschaftsdienst reicht nicht aus.
Für viele Dinge sollte es überhaupt Self-Healing geben – die Monitorings leuchten rot und helfen sich selbst, wo es wehtut.

Hier überwachen wir nicht nur einzelne Geräte, sondern auch die Gesundheit des gesamten Netzwerks, und zwar sowohl im Weißbox- als auch im Schwarzbox-Stil, was bereits komplizierter ist.

Was benötigen wir für die Umsetzung solcher ehrgeizigen Pläne?

• Eine Übersicht aller Geräte im Netzwerk, deren Standort, Rollen, Modelle und Softwareversionen haben.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Ein System zur Beschreibung von Netzwerkdiensten haben.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• In der Lage sein, ein Gerät zu initialisieren.
  Hostname, Mgmt IP, Mgmt Route, Benutzer, RSA-Schlüssel, LLDP, NETCONF.
• Das Gerät konfigurieren und die Konfiguration auf die gewünschte (einschließlich der alten) Version zurücksetzen.
• Die Konfiguration testen.
• Regelmäßig den Zustand aller Geräte auf Abweichungen vom aktuellen Status überprüfen und die zuständigen Personen informieren.
  Nachts hat jemand heimlich eine Regel in die ACL hinzugefügt..
• Die Funktionsfähigkeit überwachen.

Werkzeuge

Das klingt ziemlich kompliziert, um das Projekt in Komponenten zu zerlegen.

Und es werden zehn sein:

1. Inventarsystem
2. IP-Adressverwaltungssystem
3. System zur Beschreibung der Netzwerkdienste
4. Geräteinitialisierungsmechanismus
5. Vendor-unabhängiges Konfigurationsmodell
6. Vendor-spezifischer Treiber für Schnittstellen
7. Mechanismus zur Konfigurationserstellung auf Geräten
8. CI/CD
9. Backup- und Abweichungserkennungssystem
10. Überwachungssystem

Das ist übrigens ein Beispiel dafür, wie sich die Sichtweise auf die Ziele des Zyklus wandelte – im Entwurf der Komponenten waren es 4.

In der Abbildung habe ich alle Komponenten und das entsprechende Gerät dargestellt.
Überschneidende Komponenten interagieren miteinander.
Je größer der Block, desto mehr Aufmerksamkeit muss diesem Bestandteil gewidmet werden.

Komponente 1. Inventarisierungssystem.

Offensichtlich möchten wir wissen, welche Hardware wo steht und an was sie angeschlossen ist.
Das Inventarsystem ist ein wesentlicher Bestandteil jedes Unternehmens.
In der Regel verfügt das Unternehmen für Netzwerkgeräte über ein separates Inventarsystem, das spezifischere Aufgaben erfüllt.
Im Rahmen dieser Artikelreihe werden wir dies als DCIM – Data Center Infrastructure Management bezeichnen. Obwohl der Begriff DCIM streng genommen viel mehr umfasst.

Für unsere Zwecke werden wir die folgenden Informationen über das Gerät speichern:

• Inventarnummer
• Bezeichnung/Beschreibung
• Modell (Huawei CE12800, Juniper QFX5120 usw.)
• Merkmale (Module, Schnittstellen usw.)
• Rolle (Leaf, Spine, Border Router usw.)
• Standort (Region, Stadt, Rechenzentrum, Rack, Einheit)
• Interkonnektivitäten zwischen Geräten
• Netzwerktopologie

Es ist uns allen klar, dass wir alles darüber wissen möchten.
Aber hilft das bei den Automatisierungszielen?
Auf jeden Fall.
Zum Beispiel wissen wir, dass in diesem Rechenzentrum auf Leaf-Switches, wenn es sich um Huawei handelt, ACL zur Filterung bestimmter Datenströme auf VLAN angewendet werden müssen, und wenn es sich um Juniper handelt, dann auf Unit 0 des physischen Interfaces.
Oder wir müssen einen neuen Syslog-Server auf alle Border-Router in der Region verteilen.

In dieser werden wir virtuelle Netzwerkgeräte speichern, wie zum Beispiel virtuelle Router oder Route-Reflectoren. Wir können DNS-Server, NTP, Syslog und alles hinzufügen, was in irgendeiner Weise mit dem Netzwerk zu tun hat.

Komponente 2. IP-Adressmanagement-System

Ja, es gibt nach wie vor Gruppen von Menschen, die Präfixe und IP-Adressen in einer Excel-Datei erfassen. Aber der moderne Ansatz ist eine Datenbank mit einer Frontend-Lösung auf nginx/apache, API und umfangreichen Funktionen zur Verwaltung von IP-Adressen und Netzwerken mit VRF-Unterteilung.
IPAM - IP Address Management.

Für unsere Zwecke werden wir darin folgende Informationen speichern:

• VLAN
• VRF
• Netze/Subnetze
• IP-Adressen
• Zuweisung von Adressen zu Geräten, Netzen zu Standorten und VLAN-Nummern

Es ist klar, dass wir sicherstellen wollen, dass wir, wenn wir eine neue IP-Adresse für den Loopback des ToR zuweisen, nicht darauf stoßen, dass sie bereits jemandem zugewiesen wurde. Oder dass wir dasselbe Präfix an verschiedenen Enden des Netzwerks zweimal verwendet haben.
Aber wie hilft das bei der Automatisierung?
Einfach.
Wir fordern im System ein Präfix mit der Rolle Loopbacks an, in dem verfügbare IP-Adressen zur Verfügung stehen – falls vorhanden, weisen wir die Adresse zu, wenn nicht, beantragen wir die Erstellung eines neuen Präfixes.
Oder beim Erstellen der Geräte-Konfiguration können wir aus demselben System erfahren, in welchem VRF sich das Interface befinden sollte.
Beim Start eines neuen Servers überprüft das Skript das System, um herauszufinden, welcher Switch, welcher Port und welches Subnetz dem Interface zugewiesen ist — daraus wird die Serveradresse zugewiesen.

Es liegt nahe, DCIM und IPAM in einem System zu vereinen, um Funktionen nicht zu duplizieren und zwei ähnliche Entitäten zu verwalten.
Das werden wir tun.

Komponente 3. System zur Beschreibung von Netzwerkdiensten

Wenn die ersten beiden Systeme Variablen speichern, die weiterhin verwendet werden müssen, beschreibt das dritte, wie jedes Gerät für seine Rolle konfiguriert werden sollte.
Es gibt zwei verschiedene Arten von Netzwerkdiensten:

• Infrastrukturelle
• Kundenspezifische.

Die ersten sind darauf ausgelegt, grundlegende Konnektivität und Gerätemanagement zu gewährleisten. Dazu gehören VTY, SNMP, NTP, Syslog, AAA, Routing-Protokolle, CoPP usw.
Die zweiten bieten Dienstleistungen für den Kunden an: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP usw.
Natürlich gibt es auch Grenzfälle – wo ordnet man MPLS LDP, BGP ein? Und Routing-Protokolle können auch für Kunden verwendet werden. Aber das ist nicht entscheidend.

Beide Arten von Diensten werden in Konfigurationsprimitive unterteilt:

• physikalische und logische Schnittstellen (Tag/Antag, mtu)
• IP-Adressen und VRF (IP, IPv6, VRF)
• ACLs und Verkehrsverarbeitungsrichtlinien
• Protokolle (IGP, BGP, MPLS)
• Routingrichtlinien (Präfixlisten, Communities, ASN-Filter).
• Dienste (SSH, NTP, LLDP, Syslog…)
• usw.

Wie genau wir das machen werden, kann ich im Moment nicht sagen. Wir werden das in einem separaten Artikel klären.

Wenn man es etwas praktischer betrachtet, könnten wir beschreiben, dass
der Leaf-Switch BGP-Sitzungen mit allen angeschlossenen Spine-Switches haben sollte, die angeschlossenen Netzwerke importieren und nur Netzwerke aus einem bestimmten Präfix von den Spine-Switches akzeptieren sollte. CoPP IPv6 ND auf 10 pps begrenzen usw.
Im Gegenzug halten die Spines Sitzungen mit allen angeschlossenen Leaves, fungieren als Root-Reflektoren und akzeptieren von diesen nur Routen einer bestimmten Länge und mit einer bestimmten Community.

Komponente 4. Mechanismus zur Initialisierung des Geräts

Unter diesem Titel vereine ich zahlreiche Aktionen, die erforderlich sind, damit das Gerät auf den Radarschirmen erscheint und remote erreichbar ist.

1. Das Gerät im Inventarsystem anlegen.
2. Eine dedizierte IP-Adresse für die Verwaltung bereitstellen.
3. Basiszugang darauf einrichten:
   Hostname, IP-Adresse der Verwaltung, Routing zur Verwaltungsnetzwerk, Benutzer, SSH-Schlüssel, Protokolle – telnet/SSH/NETCONF

Es gibt drei Ansätze:

• Alles vollständig manuell. Die Geräte werden zur Testumgebung gebracht, wo ein herkömmlicher Mensch sie in die Systeme einpflegt, sich über die Konsole verbindet und sie konfiguriert. Dies kann bei kleinen, statischen Netzwerken funktionieren.
• ZTP – Zero Touch Provisioning. Die Hardware kommt an, stellt sich auf, erhält über DHCP eine Adresse und konfiguriert sich selbst über einen speziellen Server.
• Infrastruktur von Konsolenservern, bei der die Erstkonfiguration über den Konsolenport automatisch erfolgt.

Über alle drei Ansätze werden wir in einem separaten Artikel sprechen.

Komponente 5. Anbieterunabhängiges Konfigurationsmodell

Bis jetzt waren alle Systeme isolierte Puzzlestücke, die variable und deklarative Beschreibungen dessen lieferten, was wir im Netzwerk sehen möchten. Doch irgendwann müssen wir uns mit konkreten Details auseinandersetzen.
In diesem Schritt werden für jedes spezifische Gerät die Primitiven, Dienste und Variablen zu einem Konfigurationsmodell kombiniert, das die vollständige Konfiguration des jeweiligen Geräts in einem herstellerunabhängigen Format beschreibt.
Was bringt dieser Schritt? Warum nicht gleich die Konfiguration des Geräts erstellen, die einfach hochgeladen werden kann?
Tatsächlich ermöglicht dies die Lösung von drei Aufgaben:

1. Sich nicht an eine spezifische Schnittstelle zur Interaktion mit dem Gerät anzupassen. Unabhängig davon, ob CLI, NETCONF, RESTCONF oder SNMP verwendet wird, bleibt das Modell gleich.
2. Die Anzahl der Templates/Skripte nicht an die Anzahl der Hersteller im Netzwerk anzupassen, und bei Änderungen im Design nur an einer Stelle anpassen zu müssen.
3. Die Konfiguration vom Gerät (Backup) zu laden, sie in genau dasselbe Modell zu überführen und direkt die Zielkonfiguration mit der vorhandenen zu vergleichen, um die Differenz zu berechnen und ein Konfigurationspatch vorzubereiten, das nur die Teile ändert, die erforderlich sind oder um Abweichungen zu identifizieren.

Infolge dieses Schrittes erhalten wir eine herstellerunabhängige Konfiguration.

Komponente 6. Hersteller-spezifischer Treiber

Es ist illusorisch zu glauben, dass man eines Tages Cisco genauso konfigurieren kann wie Juniper, indem man einfach identische Aufrufe sendet. Trotz der zunehmenden Beliebtheit von Whiteboxes und der Einführung von NETCONF, RESTCONF und OpenConfig unterscheidet sich der spezifische Inhalt, den diese Protokolle liefern, von Anbieter zu Anbieter, und das ist eines ihrer Wettbewerbsmerkmale, das sie nicht einfach aufgeben werden.
Ähnlich verhält es sich mit OpenContrail und OpenStack, die zwar eine RestAPI als ihre NorthBound-Schnittstelle haben, jedoch ganz unterschiedliche Aufrufe erwarten.

Im fünften Schritt muss das anbieterunabhängige Modell die Form annehmen, in der es auf die Hardware übertragen wird.
Und hier sind alle Mittel recht (nicht wirklich): CLI, NETCONF, RESTCONF, SNMP – einfach erschreckend.

Deshalb benötigen wir einen Treiber, der das Ergebnis des vorherigen Schrittes in das benötigte Format eines bestimmten Anbieters umwandelt: eine Reihe von CLI-Befehlen oder eine XML-Struktur.

Komponente 7. Mechanismus zur Bereitstellung der Konfiguration an das Gerät

Die Konfiguration haben wir erstellt, aber sie muss noch an die Geräte geliefert werden – und zwar offensichtlich nicht manuell.
Erstens, vor uns stellt sich die Frage, welches Transportmittel wir verwenden werden? Die Auswahl ist heute bereits groß:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (obwohl es aus der Liste herausfällt, da es ein Weg ist, FIB zu liefern und nicht für die Konfiguration)

Lassen Sie uns hier Klarheit schaffen. CLI – das ist Legacy. SNMP… ähem.
RESTCONF – ist bisher noch ein unbekanntes Wesen, REST API wird von fast niemandem unterstützt. Daher konzentrieren wir uns in dieser Runde auf NETCONF.

Tatsächlich, wie der Leser bereits verstanden hat, haben wir uns zu diesem Zeitpunkt bereits auf das Interface festgelegt – das Ergebnis des vorherigen Schrittes liegt bereits im Format des gewählten Interfaces vor.

, versucht der MLFQ, und welche Tools werden wir dafür verwenden?
Hier ist die Auswahl ebenfalls groß:

• Ein selbstgeschriebenes Skript oder eine Plattform. Rüsten wir uns mit ncclient und asyncIO aus und machen alles selbst. Was hindert uns daran, ein Deployment-System von Grund auf zu erstellen?
• Ansible mit seiner umfangreichen Sammlung an Netzwerkmodulen.
• Salt mit seiner begrenzten Netzwerkunterstützung und der Integration mit Napalm.
• Eigentlich Napalm, das nur ein paar Anbieter kennt und das war's, auf Wiedersehen.
• Nornir – ein weiteres Tierchen, das wir in Zukunft näher betrachten werden.

Hier ist noch kein Favorit ausgewählt – wir werden uns umsehen.

Was ist hier noch wichtig? Die Auswirkungen der Konfigurationsanwendung.
Erfolgreich oder nicht. Ist der Zugriff auf die Hardware noch möglich?
Es scheint, dass hier ein Commit mit Bestätigung und Validierung dessen, was ins Gerät geladen wurde, hilfreich sein könnte.
In Kombination mit einer korrekten Implementierung von NETCONF reduziert dies die Anzahl geeigneter Geräte erheblich – gängige Commits werden nicht von vielen Herstellern unterstützt. Aber das ist nur eine der Voraussetzungen im RFP. Letztendlich macht sich niemand Sorgen, dass kein russischer Anbieter die Bedingung für das 32*100GE-Interface erfüllen wird. Oder doch?

Komponente 8. CI/CD

Bis zu diesem Zeitpunkt haben wir bereits die Konfiguration für alle Geräte im Netzwerk vorbereitet.
Ich schreibe "für alle", weil wir über die Versionierung des Netzwerkstatus sprechen. Und selbst wenn die Einstellungen eines einzelnen Switches geändert werden müssen, werden die Änderungen für das gesamte Netzwerk berechnet. Offensichtlich können sie dabei für die meisten Knoten null sein.

Aber wie bereits erwähnt, sind wir keine Barbaren, die alles sofort in Produktion bringen wollen.
Die generierte Konfiguration muss zuerst durch die Pipeline CI/CD laufen.

CI/CD steht für Continuous Integration und Continuous Deployment. Dies ist ein Ansatz, bei dem das Team nicht alle sechs Monate eine neue Hauptversion veröffentlicht, die die alte vollständig ersetzt, sondern regelmäßig inkrementelle Neuerungen (Deployment) in kleinen, ausführlich getesteten Charge bereitstellt, die auf Kompatibilität, Sicherheit und Funktionalität (Integration) geprüft werden.

Dafür haben wir ein Versionskontrollsystem, das die Konfigurationsänderungen überwacht, eine Testumgebung, die sicherstellt, dass der Kundenservice nicht beeinträchtigt wird, ein Überwachungssystem, das dies überprüft, und der letzte Schritt ist die Bereitstellung der Änderungen im Produktionsnetzwerk.

Ausgenommen von Debugging-Befehlen müssen alle Netzwerkänderungen durch den CI/CD-Pipeline gehen – das ist unser Garant für ein sorgenfreies Leben und eine lange, glückliche Karriere.

Komponente 9. Backup-System und Abweichungserkennung

Über Backups muss man nicht mehr viele Worte verlieren.
Wir werden sie einfach nach einem Zeitplan oder bei Änderungen in der Konfiguration in Git abspeichern.

Der zweite Teil ist interessanter – jemand muss sich um diese Backups kümmern. In einigen Fällen muss dieser jemand alles wiederherstellen, wie es war, während in anderen Fällen jemand darüber informiert werden muss, dass etwas nicht in Ordnung ist.
Wenn beispielsweise ein neuer Benutzer aufgetaucht ist, der nicht in den Variablen aufgeführt ist, sollte man ihn besser von der Hacking-Aktion fernhalten. Bei einer neuen Firewall-Regel ist es besser, die Finger davon zu lassen; möglicherweise hat jemand einfach das Debugging aktiviert oder ein neuer Dienst wurde vorschnell ohne Beachtung der Vorschriften eingetragen, während bereits Nutzer darauf zugreifen.

Eine gewisse kleine Abweichung im gesamten Netzwerk lässt sich ohnehin nicht vermeiden, trotz aller Automatisierungssysteme und disziplinierter Leitung. Für die Fehlersuche wird dennoch niemand die Konfiguration in die Systeme einpflegen. Zumal das Modell der Konfiguration möglicherweise nicht einmal darauf ausgelegt ist.

Ein Beispiel wäre eine Firewall-Regel zur Zählung der Pakete für eine bestimmte IP, um das Problem zu lokalisieren – eine durchaus gängige temporäre Konfiguration.

Komponente 10. Überwachungssystem

Zunächst war ich nicht gewillt, das Thema Monitoring anzusprechen – es ist schließlich ein umfangreiches, umstrittenes und komplexes Thema. Doch im Verlauf stellte sich heraus, dass es ein untrennbarer Teil der Automatisierung ist. Man kann sie nicht ignorieren, selbst wenn man keine praktische Erfahrung hat.

Diese Überlegung ist ein organischer Bestandteil des CI/CD-Prozesses. Nach dem Rollout der Konfiguration ins Netzwerk müssen wir in der Lage sein festzustellen, ob alles in Ordnung ist.
Dabei geht es nicht nur um Diagramme zur Nutzung von Schnittstellen oder die Verfügbarkeit von Knoten, sondern auch um subtilere Aspekte – das Vorhandensein der erforderlichen Routen, deren Attribute, die Anzahl der BGP-Sitzungen, OSPF-Nachbarn und die End-to-End-Funktionalität der übergeordneten Dienste.
Haben die Syslogs auf den externen Servern aufgehört zu erscheinen? Ist der SFlow-Agent nicht ausgefallen? Haben die Drop-Raten in den Warteschlangen zugenommen? Ist die Konnektivität zwischen bestimmten Präfix-Paaren beeinträchtigt worden?

In einem separaten Artikel werden wir auch darüber nachdenken.

Fazit

Als Grundlage habe ich einen der modernen Designs für Rechenzentrumsnetze gewählt – L3 Clos Fabric mit BGP als Routing-Protokoll.
Wir werden dieses Mal das Netzwerk auf Juniper aufbauen, denn die JunOs-Oberfläche ist jetzt benutzerfreundlich.

Wir machen es uns nicht einfach, indem wir nur Open Source-Tools und ein Multi-Vendor-Netzwerk verwenden – daher werde ich neben Juniper auch einen weiteren Glücklichen auswählen.

Der Plan für die nächsten Veröffentlichungen sieht ungefähr so aus:
Zuerst werde ich über virtuelle Netzwerke sprechen. Vor allem, weil ich Lust darauf habe, und zweitens, weil das Design der Infrastruktur ohne diese Information nicht ganz nachvollziehbar ist.
Dann geht es um das Netzwerkdesign: Topologie, Routing, Richtlinien.
Wir werden eine Laboraufstellung zusammenstellen.
Lass uns nachdenken und vielleicht ein bisschen üben, wie man ein Gerät im Netzwerk initialisiert.
Und dann werden wir jeden Bestandteil im Detail betrachten.

Und ja, ich verspreche nicht, diesen Zyklus elegant mit einer fertigen Lösung abzuschließen. 🙂

Nützliche Links

• Bevor wir in die Serie eintauchen, ist es ratsam, das Buch von Nataliya Samoylenko zu lesen, Python für Netzwerkingenieure. Vielleicht auch einen Kurs.
• Es wäre auch empfehlenswert, über das Design von Rechenzentrumfabriken von Facebook zu lesen, verfasst von Peter Lapukhov. RFC Wie Overlay-SDN funktioniert, kann Ihnen die Dokumentation zur Architektur
• (ehemals Open Contrail) erläutern. Tungsten Fabric Roman Gorge. Für Kommentare und Korrekturen.

Vielen Dank

Artem Tschernobaj. Für KDPV.
Artem Tschernobai. Für KDPW.

Quelle: habr.com