Die SDSM ist zu Ende gegangen, aber das unkontrollierte Verlangen zu schreiben bleibt bestehen.

Viele Jahre litt unser Bruder unter der Erledigung routinierter Aufgaben, kreuzte die Finger vor dem Commit und schlief wegen nächtlicher Rollbacks nicht genug.
Doch dunkle Zeiten neigen sich dem Ende zu.

Mit diesem Artikel beginne ich eine Serie darüber, wie mir Automatisierung wahrgenommen wird.
Im Verlauf werden wir die Phasen der Automatisierung, die Speicherung von Variablen, die Formalisierung des Designs, RestAPI, NETCONF, YANG, YDK behandeln und werden viel programmieren.
Mir bedeutet, dass a) dies keine objektive Wahrheit ist, b) es nicht der unbestritten beste Ansatz ist, c) mein Blick selbst im Verlauf vom ersten bis zum letzten Artikel sich ändern kann — um ehrlich zu sein, habe ich alles seit der Entwurfsphase bis zur Veröffentlichung zweimal komplett umgeschrieben.

Inhalt

1. Ziele
   1. Das Netzwerk — wie ein einziger Organismus
   2. Konfigurationstests
   3. Versionskontrolle
   4. Überwachung und Selbstwiederherstellung von Diensten

2. Werkzeuge
   1. Inventarisierungssystem
   2. IP-Raumverwaltungssystem
   3. System zur Beschreibung von Netzwerkdiensten
   4. Geräteinitialisierungsmechanismus
   5. Vendor-unabhängiges Konfigurationsmodell
   6. Vendor-spezifischer Treiber
   7. Mechanismus zur Bereitstellung von Konfigurationen auf ein Gerät
   8. CI/CD
   9. Mechanismus zur Datensicherung und Abweichungserkennung
   10. Überwachungssystem

3. Fazit

Ich werde versuchen, die ADSM in einem Format zu führen, das sich ein wenig vom SDSM unterscheidet. Es werden weiterhin umfangreiche, ausführliche nummerierte Artikel erscheinen, und dazwischen werde ich kleine Notizen aus dem Alltag veröffentlichen. Ich werde versuchen, hier gegen den Perfektionismus anzukämpfen und nicht jeden von ihnen zu polieren.

Wie lustig es ist, dass man denselben Weg ein zweites Mal gehen muss.

Zuerst musste ich selber Artikel über Netzwerke schreiben, da es sie im russischen Internet nicht gab.

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

Vielleicht liege ich falsch, also schickt Links zu brauchbaren Ressourcen. Das wird jedoch meine Entschlossenheit, zu schreiben, nicht ändern, denn das Hauptziel besteht ohnehin darin, selbst etwas zu lernen, und das Leben der anderen zu erleichtern ist ein angenehmer Bonus, der die Verbreitung von Wissen fördert.

Wir werden versuchen, ein mittelgroßes Rechenzentrum LAN DC zu nehmen und das gesamte Automatisierungsschema zu erarbeiten.
Einige Dinge werde ich praktisch zum ersten Mal zusammen mit euch machen.

In den hier beschriebenen Ideen und Werkzeugen werde ich nicht original sein. Dmitry Figol hat einen ausgezeichneten Kanal mit Streams zu diesem Thema.
Die Artikel werden in vielerlei Hinsicht mit ihnen überschneiden.

In LAN DC 4 DCs, etwa 250 Switches, ein halbes Dutzend Router und ein paar Firewalls.
Nicht Facebook, aber ausreichend, um tief über Automatisierung nachzudenken.
Es gibt jedoch die Meinung, dass man, wenn man mehr als ein Gerät hat, bereits eine Automatisierung benötigt.
Es ist tatsächlich schwer vorstellbar, dass jemand heute ohne mindestens ein paar Shell-Skripte leben kann.
Obwohl ich gehört habe, dass es Firmen gibt, in denen die IP-Adressverwaltung in Excel erfolgt und jedes aus Tausenden von Netzgeräten manuell konfiguriert wird, wobei jedes eine einzigartige Konfiguration hat. Das kann man natürlich als moderne Kunst verkaufen, aber die Gefühle der Ingenieure werden sicher verletzt sein.

Ziele

Jetzt werden wir möglichst abstrakte Ziele setzen:

• Das Netzwerk — wie ein einziger Organismus
• Konfigurationstests
• Versionierung des Netzwerkstatus
• Überwachung und Selbstwiederherstellung von Diensten

Später in diesem Artikel werden wir besprechen, welche Mittel wir verwenden werden, und in den folgenden Artikeln Ziele und Mittel im Detail.

Das Netzwerk — wie ein einziger Organismus

Der prägnante Satz des Zyklus, auch wenn er auf den ersten Blick nicht besonders erheblich erscheint: Wir werden das Netzwerk konfigurieren, nicht einzelne Geräte..
In den letzten Jahren beobachten wir einen Trend, die Netzwerke als eine einheitliche Entität zu betrachten, weshalb uns nun Software Defined Networking, Intent Driven Networks und Autonome Netzwerke.
Denn was brauchen Anwendungen global von einem Netzwerk: Konnektivität zwischen Punkten A und B (nun manchmal +B-Я) und Isolation von anderen Anwendungen und Benutzern.

Und so besteht unsere Aufgabe in dieser Reihe darin, ein System aufzubauen, das die aktuelle Konfiguration des gesamten Netzwerks, die sich bereits in die aktuelle Konfiguration jedes Geräts gemäß seiner Rolle und seinem Standort decomponiert, unterstützt.
Das System Netzwerkmanagement bedeutet, dass wir zur Änderung auf dieses System zugreifen, und es berechnet dann den benötigten Zustand für jedes Gerät und konfiguriert es.
So minimieren wir fast auf null das manuelle Eingreifen in die CLI – alle Änderungen an den Geräteeinstellungen oder am Netzwerkdesign müssen formalisiert und dokumentiert werden – und erst dann auf die notwendigen Elemente des Netzwerks angewendet werden.

Das heißt, zum Beispiel, wenn wir entschieden haben, dass ab jetzt die Stacked Switches in Kasan zwei Netzwerke anstelle von einem ankündigen sollten, wir

1. Dokumentieren zuerst die Änderungen in den Systemen
2. Generieren die Zielkonfiguration aller Netzwerkgeräte
3. Starten das Programm zur Aktualisierung der Netzwerkkonfiguration, das berechnet, was an jedem Knoten entfernt werden muss, was hinzugefügt werden muss, und bringt die Knoten in den gewünschten Zustand.

Dabei nehmen wir manuelle Änderungen nur im ersten Schritt vor.

Konfigurationstests

Es ist bekannt, dass 80% der Probleme während der Änderung der Konfiguration auftreten - ein indirekter Beweis dafür ist, dass während der Neujahrsferien normalerweise alles ruhig ist.
Ich habe persönlich Dutzende globaler Ausfälle 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 den Fehler beim sechsten nicht bemerkt, alte Änderungen, die von jemand anderem vorgenommen wurden, eingefügt. Es gibt unzählige Szenarien.

Die Automatisierung ermöglicht es uns, weniger Fehler zu machen, jedoch in größerem Maßstab. So kann man nicht nur ein Gerät, sondern das gesamte Netzwerk auf einmal lahmlegen.

Seit jeher haben unsere Vorfahren die Richtigkeit der vorgenommenen Änderungen mit scharfem Auge, steelen Eiern und der Funktionsfähigkeit des Netzwerks nach deren Implementierung überprüft.
Die Vorfahren, deren Arbeiten zu Stillstand und katastrophalen Verlusten führten, hinterließen weniger Nachkommen und sollten mit der Zeit aussterben, aber die Evolution ist ein langsamer Prozess, und daher überprüfen bis heute nicht alle im Voraus die Änderungen im Labor.
An der Spitze des Fortschritts stehen diejenigen, die den Prozess der Testautomatisierung der Konfiguration und deren weiterer Anwendung im Netzwerk automatisiert haben. Anders gesagt - sie haben das CI/CD-Verfahren (Continuous Integration, Continuous Deployment) von Entwicklern übernommen.
In einem der Teile werden wir uns ansehen, wie man dies mit einem Versionskontrollsystem, wahrscheinlich GitHub, umsetzt.

Sobald Sie sich mit dem Gedanken an Netzwerkintegration und -bereitstellung vertraut gemacht haben, wird Ihnen die Methode zur Überprüfung der Konfiguration durch deren Anwendung im Produktionsnetzwerk sofort wie ein frühmittelalterliches Unwissenheit erscheinen. Etwa so, als würde man mit einem Hammer auf einen Sprengkopf schlagen.

Eine organische Fortsetzung der Ideen über das System Netzwerkmanagement und CI/CD ist eine vollständige Versionskontrolle der Konfiguration.

Versionskontrolle

Wir gehen davon aus, dass bei jeglichen Änderungen, selbst den geringfügigsten, selbst an einem unauffälligen Gerät, das gesamte Netzwerk von einem Zustand in einen anderen übergeht.
Und wir führen den Befehl niemals direkt auf dem Gerät aus, sondern ändern den Zustand des Netzwerks.
Lassen Sie uns diese Zustände Versionen nennen?

Nehmen wir an, die aktuelle Version ist 1.0.0.
Hat sich die IP-Adresse des Loopback-Interfaces an einem der ToR geändert? Das ist eine kleinere Version – sie erhält die Nummer 1.0.1.
Haben wir die Richtlinien für das Importieren von Routen in BGP überarbeitet – das ist schon etwas ernster – und wir haben 1.1.0.
Haben wir uns entschieden, IGP abzulehnen und nur auf BGP umzusteigen – das ist bereits eine radikale Änderung im Design – 2.0.0.

Anmerkung: Verschiedene Rechenzentren können unterschiedliche Versionen haben – das Netzwerk entwickelt sich weiter, neue Geräte werden installiert, wo neue Spine-Ebenen hinzugefügt werden, woanders nicht usw.

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

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

Das Gleiche gilt für das Zurücksetzen von Änderungen – das ist nicht das Rückgängigmachen der letzten Befehle, das ist kein Rollback durch das Betriebssystem des Geräts – das bedeutet, das gesamte Netzwerk auf eine neue (alte) Version zurückzuführen.

Überwachung und Selbstwiederherstellung von Diensten

Diese scheinbar offensichtliche Aufgabe in modernen Netzwerken erreicht ein neues Niveau.
Bei großen Dienstanbietern wird oft der Ansatz verfolgt, dass ein ausgefallener Dienst sehr schnell behoben und ein neuer gestartet werden muss, anstatt herauszufinden, was passiert ist.
„Sehr“ bedeutet, dass von allen Seiten reichlich Monitoring eingesetzt werden muss, das innerhalb von Sekunden die geringsten Abweichungen von der Norm erkennt.
Und hier sind gewohnte Metriken, wie die Auslastung des Interfaces oder die Erreichbarkeit von Knoten, nicht mehr ausreichend. Auch die manuelle Überwachung durch den Diensthabenden reicht nicht aus.
Für viele Dinge muss es im Allgemeinen Self-Healing geben – die Monitorings leuchten rot und kümmern sich selbst darum, wo es schmerzt.

Hier überwachen wir nicht nur einzelne Geräte, sondern auch die Gesundheit des gesamten Netzwerks, sowohl wie bei einem Whitebox-Ansatz, was vergleichsweise klar ist, als auch bei einem Blackbox-Ansatz, was bereits komplexer ist.

Was benötigen wir, um solche ehrgeizigen Pläne umzusetzen?

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

Werkzeuge

Das klingt ziemlich kompliziert, um mit der Dekomposition des Projekts in Komponenten zu beginnen.

Und es werden zehn sein:

1. Inventarisierungssystem
2. IP-Raumverwaltungssystem
3. System zur Beschreibung von Netzwerkdiensten
4. Geräteinitialisierungsmechanismus
5. Vendor-unabhängiges Konfigurationsmodell
6. Vendor-spezifischer Treiber
7. Mechanismus zur Bereitstellung von Konfigurationen auf ein Gerät
8. CI/CD
9. Mechanismus zur Datensicherung und Abweichungserkennung
10. Überwachungssystem

Das ist übrigens ein Beispiel dafür, wie sich die Sicht auf die Ziele des Zyklus geändert hat – im Entwurf der Komponenten waren es vier.

In der Abbildung habe ich alle Komponenten und das Gerät selbst dargestellt.
Überlappende Komponenten interagieren miteinander.
Je größer der Block, desto mehr Aufmerksamkeit sollte diesem komponenten gewidmet werden.

Komponente 1. Inventarisierungssystem

Offensichtlich wollen wir wissen, welche Geräte wo stehen und womit sie verbunden sind.
Das Inventarisierungssystem ist ein wesentlicher Bestandteil jedes Unternehmens.
In der Regel hat das Unternehmen für Netzgeräte ein separates Inventarisierungssystem, das spezifischere Aufgaben erfüllt.
Im Rahmen der Artikelreihe werden wir dies als DCIM – Data Center Infrastructure Management bezeichnen. Obwohl der Begriff DCIM eigentlich viel mehr umfasst.

Für unsere Zwecke werden wir darin folgende Informationen über das Gerät speichern:

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

Es ist ganz klar, dass wir das alles selbst wissen wollen.
Aber wird das bei der Automatisierung helfen?
Natürlich.
Zum Beispiel wissen wir, dass in diesem Rechenzentrum auf Leaf-Switches, wenn es Huawei ist, ACLs zur Filterung bestimmter Datenströme auf VLAN angewendet werden müssen, während dies bei Juniper auf Einheit 0 des physischen Interfaces gelten muss.
Oder wir müssen einen neuen Syslog-Server auf allen Border-Routern der Region installieren.

Darin werden wir virtuelle Netzgeräte speichern, wie zum Beispiel virtuelle Router oder Routen-Reflektoren. Wir können DNS-Server, NTP, Syslog und alles hinzufügen, was irgendwie mit dem Netzwerk zu tun hat.

Komponente 2. IP-Raum-Management-System

Ja, auch heute gibt es Gruppen von Menschen, die in einer Excel-Datei die Präfixe und IP-Adressen verwalten. Aber der moderne Ansatz ist dennoch eine Datenbank mit einem Frontend auf nginx/apache, API und umfassenden Funktionen zur Verwaltung von IP-Adressen und Netzwerken mit Trennung in VRF.
IPAM – IP-Adressverwaltung.

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

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

Es ist klar, dass wir sicherstellen möchten, dass wir, wenn wir eine neue IP-Adresse für den Loopback des ToR vergeben, nicht auf das Problem stoßen, dass sie bereits jemandem zugewiesen wurde. Oder dass wir dasselbe Präfix zweimal an verschiedenen Enden des Netzwerks verwendet haben.
Aber wie hilft das bei der Automatisierung?
Einfach.
Wir fragen im System nach dem Präfix mit der Rolle Loopbacks, das verfügbare IP-Adressen zur Zuweisung enthält – wenn es gefunden wird, weisen wir die Adresse zu, wenn nicht, bitten wir um die Erstellung eines neuen Präfixes.
Oder bei der Erstellung der Gerätkonfiguration können wir aus demselben System erfahren, in welchem VRF das Interface sein sollte.
Und beim Start eines neuen Servers geht das Skript ins System, erfährt, welcher Server-Switch, welcher Port und welches Subnetz dem Interface zugewiesen sind – aus diesem wird die Serveradresse zugewiesen.

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

Komponente 3. System zur Beschreibung von Netzwerkdiensten

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

• Infrastrukturdienstleistungen
• Kundendienste.

Die ersten sollen die grundlegende Konnektivität und Geräteverwaltung sicherstellen. Dazu gehören VTY, SNMP, NTP, Syslog, AAA, Routing-Protokolle, CoPP usw.
Die zweiten bieten einen Dienst für den Kunden an: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP usw.
Es gibt natürlich auch Grenzfälle – wo gehören MPLS LDP, BGP hin? Und auch Routing-Protokolle können für Kunden verwendet werden. Aber das ist nicht entscheidend.

Beide Arten von Diensten lassen sich in Konfigurationsprimitive unterteilen:

• physische und logische Schnittstellen (Tag/Antag, mtu)
• IP-Adressen und VRF (IP, IPv6, VRF)
• ACLs und Verkehrspolitiken
• Protokolle (IGP, BGP, MPLS)
• Routing-Politiken (Präfixlisten, Communities, ASN-Filter).
• Dienstleistungen (SSH, NTP, LLDP, Syslog...)
• usw.

Wie genau wir das machen werden, weiß ich noch nicht. Wir klären das in einem separaten Artikel.

Ein wenig näher am Leben könnten wir beschreiben, dass
Der Leaf-Switch sollte BGP-Sitzungen mit allen angeschlossenen Spine-Switches haben, die angeschlossenen Netzwerke in den Prozess importieren und nur Netzwerke aus einem bestimmten Präfix von Spine-Switches annehmen. Die CoPP IPv6 ND auf 10 pps begrenzen usw.
Die Spine-Switches halten ihrerseits Sitzungen mit allen angeschlossenen Leaf-Switches und fungieren als Route-Reflektoren, wobei sie nur Routen bestimmter Länge und mit einer bestimmten Community von ihnen annehmen.

Komponente 4. Mechanismus zur Initialisierung des Geräts

Unter diesem Titel bündele ich eine Vielzahl von Aktionen, die stattfinden müssen, damit das Gerät auf den Radaren erscheint und remote erreichbar ist.

1. Das Gerät im Inventarsystem erfassen.
2. Eine IP-Adresse für die Verwaltung zuweisen.
3. Zugriff auf das Gerät einrichten:
   Hostname, IP-Adresse der Verwaltung, Route zum Verwaltungsnetzwerk, Benutzer, SSH-Schlüssel, Protokolle — telnet/SSH/NETCONF

Es gibt drei Ansätze:

• Alles komplett manuell. Das Gerät wird zum Stand gebracht, wo ein gewöhnlicher Mensch es in die Systeme einpflegt, sich über die Konsole verbindet und es konfiguriert. Kann bei kleinen statischen Netzwerken funktionieren.
• ZTP — Zero Touch Provisioning. Die Hardware kommt an, wird aufgestellt, erhält über DHCP eine Adresse, geht zu einem speziellen Server und konfiguriert sich selbst.
• Infrastruktur von Konsolenservern, wo die erste Konfiguration über den Konsolenport im automatischen Modus erfolgt.

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

Komponente 5. Herstellerunabhängiges Konfigurationsmodell

Bisher waren alle Systeme aus unterschiedlichen Puzzlestücken zusammengesetzt, die eine variable und deklarative Beschreibung dessen geben, was wir im Netzwerk sehen möchten. Doch irgendwann muss man sich mit der Konkretheit auseinandersetzen.
In diesem Stadium werden für jedes spezifische Gerät Primitive, Dienste und Variablen in ein Konfigurationsmodell integriert, das die vollständige Konfiguration des spezifischen Geräts beschreibt, allerdings in einer herstellerunabhängigen Weise.
Was bringt dieser Schritt? Warum nicht sofort die Konfiguration des Geräts erstellen, die man einfach hochladen kann?
Tatsächlich ermöglicht dies die Lösung von drei Aufgaben:

1. Sich nicht an ein bestimmtes Interaktionsinterface mit dem Gerät anpassen. Egal ob CLI, NETCONF, RESTCONF, SNMP – das Modell wird gleich sein.
2. Die Anzahl der Vorlagen/Skripte nicht nach der Anzahl der Anbieter im Netzwerk zu gestalten, und im Falle einer Designänderung dasselbe an mehreren Stellen anzupassen.
3. Die Konfiguration vom Gerät (Backup) laden, sie in genau dasselbe Modell zerlegen und die Zielkonfiguration direkt mit der bestehenden vergleichen, um die Differenz zu berechnen und einen Konfigurationspatch vorzubereiten, der nur die Teile ändert, die notwendig sind, oder um Abweichungen zu identifizieren.

Das Ergebnis dieser Phase ist eine anbieterunabhängige Konfiguration.

Komponente 6. Anbieter-spezifischer Treiber

Man sollte sich nicht Illusionen hingeben, dass man eines Tages Cisco genau so konfigurieren kann wie Juniper, indem man ihnen einfach identische Aufrufe sendet. Trotz der zunehmenden Beliebtheit von Whiteboxen und der Unterstützung für NETCONF, RESTCONF und OpenConfig unterscheidet sich der spezifische Inhalt, den diese Protokolle liefern, von Anbieter zu Anbieter, und das ist eines ihrer wettbewerbsfähigen Merkmale, das sie so leicht nicht aufgeben werden.
Das ist ungefähr das gleiche wie OpenContrail und OpenStack, die ein RestAPI als ihren NorthBound-Interface haben, aber völlig unterschiedliche Aufrufe erwarten.

Also muss das anbieterunabhängige Modell im fünften Schritt die Form annehmen, die es für die Hardware benötigt.
Und hier sind alle Mittel recht (nicht): CLI, NETCONF, RESTCONF, SNMP einfach schrecklich.

Deshalb brauchen wir einen Treiber, der das Ergebnis des vorherigen Schrittes in das erforderliche Format des spezifischen Anbieters überträgt: eine Menge CLI-Befehle, XML-Struktur.

Komponente 7. Mechanismus zur Bereitstellung der Konfiguration auf dem Gerät

Die Konfiguration haben wir generiert, aber sie muss auch auf die Geräte gebracht werden – und offenbar nicht manuell.
Zunächst einmal, stehen wir vor der Frage, welches Transportmittel wir nutzen werden? Die Auswahl ist heutzutage bereits nicht klein:

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

Lassen Sie uns hier die Punkte auf den i setzen. CLI – das ist Legacy. SNMP… Ähm, Ähm.
RESTCONF – ist noch ein unbekanntes Wesen, REST API wird von fast niemandem unterstützt. Daher konzentrieren wir uns im Zyklus auf NETCONF.

Tatsächlich haben wir uns, wie der Leser bereits erkannt hat, zu diesem Zeitpunkt bereits auf die Benutzeroberfläche geeinigt – das Ergebnis des vorherigen Schrittes liegt bereits im Format der gewählten Benutzeroberfläche vor.

Zweitens, und welche Werkzeuge werden wir dabei verwenden?
Hier gibt es ebenfalls eine große Auswahl:

• Ein selbstgeschriebenes Skript oder eine Plattform. Bewaffnen wir uns mit ncclient und asyncIO und machen alles selbst. Was hindert uns daran, das Deploymentsystem von Grund auf neu zu erstellen?
• Ansible mit seiner umfangreichen Bibliothek von Netzmodulen.
• Salt, das nur begrenzte Netzwerkfunktionen bietet und mit Napalm verbunden ist.
• Eigentlich Napalm, der ein paar Anbieter kennt und das war's, auf Wiedersehen.
• Nornir – ein weiteres Tierchen, das wir in Zukunft aufschneiden werden.

Hier ist noch kein Favorit gewählt – wir werden sie testen.

Was ist hier noch wichtig? Die Auswirkungen der Anwendung der Konfiguration.
Ob erfolgreich oder nicht. Ob weiterhin Zugriff auf das Gerät besteht oder nicht.
Es scheint, dass hier ein Commit mit Bestätigung und Validierung dessen, was ins Gerät geladen wurde, helfen könnte.
Das schränkt in Kombination mit der richtigen Implementierung von NETCONF den Kreis der geeigneten Geräte erheblich ein – normale Commits unterstützen nicht viele Hersteller. Aber das ist einfach eine der Voraussetzungen in RFP. Schließlich macht sich niemand Sorgen, dass kein einziger russischer Anbieter die Bedingung von 32*100GE-Schnittstellen erfüllt. Oder tut er das?

Komponente 8. CI/CD

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 es nötig ist, nur die Einstellungen eines einzelnen Switches zu ändern, werden die Änderungen für das gesamte Netzwerk berücksichtigt. Offensichtlich können sie dabei für die meisten Knoten null sein.

Aber, wie bereits weiter oben gesagt, sind wir keine Barbaren, die alles auf einmal in die Produktion schicken.
Die generierte Konfiguration muss zuerst durch die CI/CD-Pipeline laufen.

CI/CD steht für Continuous Integration, Continuous Deployment. Dies ist ein Ansatz, bei dem das Team nicht einmal alle sechs Monate ein neues großen Update veröffentlicht, das das alte vollständig ersetzt, sondern regelmäßig inkrementell (Deployment) neue Funktionen in kleinen Portionen einführt, die jeweils umfassend auf Kompatibilität, Sicherheit und Funktionalität (Integration) getestet werden.

Dafür haben wir ein Versionskontrollsystem, das die Änderungen der Konfiguration überwacht, ein Labor, in dem geprüft wird, ob der Kundenservice nicht ausfällt, ein Überwachungssystem, das diese Tatsache kontrolliert, und der letzte Schritt ist die Bereitstellung der Änderungen im Produktionsnetzwerk.

Mit Ausnahme der Debugging-Commands müssen alle Änderungen im Netzwerk durch das CI/CD-Pipeline gehen – das ist unser Garant für ein ruhiges Leben und eine lange, erfolgreiche Karriere.

Komponente 9. Backup- und Abweichungserkennungssystem

Nun, über Backups muss man nicht oft reden.
Wir werden sie einfach nach Cron oder bei Änderungen der Konfiguration in Git speichern.

Die zweite Hälfte ist interessanter – jemand muss auf diese Backups achten. In einigen Fällen muss dieser jemand alles wiederherstellen, wie es war, und in anderen Fällen muss er jemandem Bescheid geben, dass etwas nicht stimmt.
Wenn beispielsweise ein neuer Benutzer aufgekommen ist, der nicht in den Variablen vermerkt ist, muss er vom Hack ferngehalten werden. Und wenn eine neue Firewall-Regel hinzugefügt wurde – besser nicht berühren, vielleicht hat jemand einfach das Debugging eingeschaltet oder ein neuer Dienst wurde, ungeschickt, nicht gemäß den Vorschriften hinzugefügt, und schon sind die Leute darauf gestoßen.

Von einer gewissen kleinen Delta im Maßstab des gesamten Netzwerks werden wir dennoch nicht entkommen, trotz aller Automatisierungssysteme und der eisernen Hand des Managements. Für das Debugging der Probleme wird dennoch niemand die Konfiguration in Systeme eingeben. Zumal die Modellierung der Konfiguration dies vielleicht sogar nicht vorschreibt.

Zum Beispiel eine Firewall-Regel zur Zählung der Pakete an eine bestimmte IP-Adresse, um ein Problem zu lokalisieren – eine ganz gewöhnliche temporäre Konfiguration.

Komponente 10. Überwachungssystem

Zuerst wollte ich das Thema Überwachung nicht behandeln – es ist schließlich umfangreich, umstritten und kompliziert. Aber im Laufe der Dinge stellte sich heraus, dass es ein unverzichtbarer Teil der Automatisierung ist. Und man kann nicht einfach daran vorbeigehen, auch nicht ohne praktische Erfahrungen.

Um die Überlegung fortzusetzen – es ist ein organischer Teil des CI/CD-Prozesses. Nach der Bereitstellung der Konfiguration im Netzwerk müssen wir in der Lage sein zu bestimmen, ob alles jetzt in Ordnung ist.
Und es geht nicht nur um Grafiken zur Nutzung von Schnittstellen oder die Verfügbarkeit von Knoten, sondern um subtilere Dinge – das Vorhandensein von notwendigen Routen, Attributen darauf, der Anzahl von BGP-Sitzungen, OSPF-Nachbarn, der End-to-End-Funktionalität der darüber liegenden Dienste.
Haben die Syslogs auf dem externen Server aufgehört zu entstehen, oder ist der SFlow-Agent ausgefallen? Sind die Drops in den Warteschlangen gestiegen, oder ist die Konnektivität zwischen irgendeinem Präfix-Paar gestört?

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

Fazit

Als Grundlage wählte ich eines der modernen Designs für Rechenzentrumsnetze – L3 Clos Fabric mit BGP als Routingprotokoll.
Wir werden unser Netzwerk diesmal auf Juniper aufbauen, da die JunOs-Oberfläche jetzt einfach ist.

Wir erschweren uns das Leben mit der Verwendung ausschließlich von Open-Source-Tools und einem Multivendor-Netz – daher werde ich neben Juniper im Laufe der Zeit noch einen weiteren Glücklichen auswählen.

Der Plan der nächsten Veröffentlichungen sieht folgendermaßen aus:
Zuerst werde ich über virtuelle Netzwerke berichten. Erstens, weil ich das möchte, und zweitens, weil das Design des Infrastruktur-Netzwerks sonst nicht wirklich verständlich sein wird.
Dann geht es richtig um das Design des Netzwerks: Topologie, Routing, Richtlinien.
Wir werden eine Laborumgebung aufbauen.
Wir werden darüber nachdenken und vielleicht das Gerät im Netzwerk in Betrieb nehmen.
Und dann über jede Komponente in intimen Details.

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

Nützliche Links

• Bevor wir in die Serie eintauchen, ist es sinnvoll, das Buch von Natalia Samoylenko zu lesen, Python für Netzwerkingenieure.Und vielleicht auch zu absolvieren. einen Kurs.
• Es wird auch hilfreich sein, über das Design von Rechenzentrums-Fabriken von Facebook zu lesen, verfasst von Peter Lapukhoff. RFC Wie das Overlay-basierte SDN funktioniert, zeigt Ihnen die Dokumentation zur Architektur
• (früher Open Contrail). Tungsten Fabric Roman Gorge. Für Kommentare und Korrekturen.

Danke

Artem Tschernobaj. Für KDPV.
🥇Automatisierung für die Kleinsten. Nullte Folge. Planung | ProHoster

Quelle: habr.com