Hallo, Habr!
In diesem Artikel möchten wir über die Automatisierung der Netzwerk-Infrastruktur sprechen. Wir werden ein funktionierendes Netzwerkmodell vorstellen, das in einem kleinen, aber sehr stolzen Unternehmen operiert. Alle Übereinstimmungen mit realem Netzwerk-Equipment sind rein zufällig. Wir betrachten einen Fall, der in diesem Netzwerk aufgetreten ist und zu einem möglichen Stillstand des Unternehmens für längere Zeit sowie erheblichen finanziellen Verlusten geführt hat. Die Lösung dieses Falls passt sehr gut in das Konzept der "Automatisierung der Netzwerk-Infrastruktur". Mit Automatisierungsmitteln zeigen wir, wie komplexe Aufgaben effizient in kurzer Zeit gelöst werden können, und überlegen, warum es vorteilhafter ist, diese Aufgaben auf diese Weise zu lösen, anstatt über die Konsole.
Haftungsausschluss
Unsere Hauptwerkzeuge zur Automatisierung sind Ansible (als Automatisierungsmittel) und Git (als Repository für Ansible-Playbooks). Ich möchte gleich klarstellen, dass dies kein einführender Artikel ist, in dem wir die Funktionsweise von Ansible oder Git erläutern und grundlegende Dinge erklären (z. B. was Rollenmangagementmodule, Inventar- und Variablen-Dateien in Ansible sind oder was passiert, wenn man die Befehle git push oder git commit eingibt). Es geht hier nicht darum, wie man mit Ansible üben kann, NTP oder SMTP auf der Hardware einrichtet. Diese Geschichte handelt davon, wie man schnell und möglichst fehlerfrei ein Netzwerkproblem löst. Ein gutes Verständnis dafür, wie Netzwerke funktionieren, ist ebenfalls wünschenswert, insbesondere was der TCP/IP-Protokollstapel, OSPF, BGP sind. Die Entscheidung für Ansible und Git lassen wir ebenfalls außen vor. Wenn Sie noch vor der Wahl einer konkreten Lösung stehen, empfehle ich dringend das Buch „Network Programmability and Automation. Skills for the Next-Generation Network Engineer“ von Jason Edelman, Scott S. Lowe und Matt Oswalt zu lesen.
Nun zum Geschäftlichen.
Problemstellung
Stellen Sie sich vor: Es ist 3 Uhr morgens, Sie schlafen fest und träumen. Ein Anruf auf Ihrem Telefon. Der technische Direktor ruft an:
— Ja?
— ###, ####, #####, der Cluster der Firewalls ist abgestürzt und lässt sich nicht wieder hochfahren!!!
Sie reiben sich die Augen, versuchen zu begreifen, was gerade passiert ist, und sich vorzustellen, wie es überhaupt so weit kommen konnte. Am Telefon hört man das verzweifelte Ziehen der Haare des Direktors, der um einen Rückruf bittet, weil er auf der anderen Leitung mit dem Geschäftsführer spricht.
Nach einer halben Stunde haben Sie die ersten Informationen von der Bereitschaftsschicht gesammelt und alle geweckt, die man wecken konnte. Der technische Direktor hat nicht gelogen: Es stimmt, der Hauptcluster der Firewalls ist ausgefallen und keine der grundlegenden Maßnahmen bringt ihn wieder zum Laufen. Alle Dienste, die das Unternehmen anbietet, funktionieren nicht.
Wählen Sie ein Problem nach Ihrem Geschmack, jeder wird etwas Eigenes in Erinnerung haben. Beispielsweise lief nach einem nächtlichen Update bei geringer Auslastung alles gut und alle Zufriedenen gingen schlafen. Als der Verkehr anstieg, überliefen die Pufferspeicher der Schnittstellen aufgrund eines Fehlers im Netzwerktreiber.
Die Situation könnte gut von Jackie Chan beschrieben werden.
Danke, Jackie.
Die Situation ist nicht gerade angenehm, oder?
Lassen Sie unseren Netzwerkfreund und seine trüben Gedanken für eine Weile beiseite.
Diskutieren wir, wie sich die Ereignisse weiter entwickeln werden.
Wir schlagen folgende Reihenfolge der Darstellung des Materials vor.
- Lassen Sie uns das Netzwerkschema betrachten und analysieren, wie es funktioniert;
- Wir beschreiben, wie wir die Einstellungen von einem Router auf einen anderen mit Ansible übertragen;
- Wir sprechen über die Automatisierung der IT-Infrastruktur im Allgemeinen.
Das Netzwerkschema und seine Beschreibung
Schema
Wir betrachten das logische Schema unserer Organisation. Wir werden keine spezifischen Hersteller nennen, da dies im Rahmen des Artikels nicht relevant ist. (Der aufmerksame Leser wird selbst erkennen, welche Geräte verwendet werden). Das ist einer der Vorteile von Ansible: Bei der Konfiguration ist es uns im Allgemeinen egal, um welche Geräte es sich handelt. Nur zur Erklärung, es handelt sich um Geräte bekannter Anbieter wie Cisco, Juniper, Check Point, Fortinet, Palo Alto ... Sie können Ihre eigene Auswahl einsetzen.
Wir haben zwei Hauptaufgaben beim Traffic-Umzug:
- Die Veröffentlichung unserer Dienste sicherzustellen, die das Geschäft des Unternehmens ausmachen;
- Die Verbindung zu Niederlassungen, einem entfernten Rechenzentrum und externen Organisationen (Partnern und Kunden) sowie den Internetzugang der Niederlassungen über das Zentralbüro sicherzustellen.
Lassen Sie uns mit den grundlegenden Elementen beginnen:
- Zwei Border-Router (BRD-01, BRD-02);
- Cluster von Firewalls (FW-CLUSTER);
- Core-Switch (L3-CORE);
- Ein Router, der als Lebensretter fungiert (im Zuge der Problemlösung übertragen wir die Netzwerkkonfigurationen von FW-CLUSTER auf EMERGENCY) (EMERGENCY);
- Switches zur Verwaltung der Netzwerkinfrastruktur (L2-MGMT);
- Virtuelle Maschine mit Git und Ansible (VM-AUTOMATION);
- Laptop, auf dem die Tests und die Entwicklung von Ansible-Playbooks durchgeführt werden (Laptop-Automation).
Im Netzwerk ist das dynamische Routing-Protokoll OSPF mit den folgenden Bereichen konfiguriert:
- Area 0 – Bereich, in dem sich die Router befinden, die für den Datenverkehr in der EXCHANGE-Zone verantwortlich sind;
- Area 1 – Bereich, in dem sich die Router befinden, die für die Bereitstellung der Unternehmensdienste verantwortlich sind;
- Area 2 – Bereich, in dem sich die Router befinden, die für das Management-Traffic-Routing verantwortlich sind;
- Area N – Bereiche der Filialnetzwerke.
An den Grenzroutern wurde ein virtueller Router (VRF-INTERNET) eingerichtet, auf dem eine eBGP-Vollansicht mit dem entsprechenden zugewiesenen AS läuft. Zwischen den VRFs ist iBGP konfiguriert. Das Unternehmen verfügt über einen Pool von öffentlichen IP-Adressen, die auf diesen VRF-INTERNET veröffentlicht werden. Ein Teil der öffentlichen Adressen wird direkt an den FW-CLUSTER (IP-Adressen, auf denen die Unternehmensdienste laufen) geroutet, ein anderer Teil wird über die EXCHANGE-Zone geroutet (interne Unternehmensdienste, die externe IP-Adressen benötigen, sowie externe Adressen NAT für Büros). Danach gelangt der Verkehr zu den virtuellen Routern, die auf dem L3-CORE mit öffentlichen und grauen Adressen (Sicherheitszonen) erstellt wurden.
Im Management-Netz werden dedizierte Switches verwendet, die ein physisch getrenntes Netzwerk darstellen. Das Management-Netz ist ebenfalls in Sicherheitszonen unterteilt.
Der EMERGENCY-Router spiegelt physisch und logisch den FW-CLUSTER. Alle Interfaces, außer denjenigen, die ins Management-Netz führen, sind deaktiviert.
Automatisierung und deren Beschreibung
Wir haben verstanden, wie das Netzwerk funktioniert. Nun besprechen wir Schritt für Schritt, was wir tun müssen, um den Verkehr vom FW-CLUSTER auf EMERGENCY umzuleiten:
- Wir deaktivieren die Schnittstellen am Kern-Switch (L3-CORE), die ihn mit dem FW-CLUSTER verbinden;
- Wir deaktivieren die Schnittstellen am L2-MGMT-Kern-Switch, die ihn mit dem FW-CLUSTER verbinden.
- Wir konfigurieren den NOTFALL-Router (standardmäßig sind alle Schnittstellen außer denjenigen, die mit L2-MGMT verbunden sind, deaktiviert):
- Wir aktivieren die Schnittstellen am NOTFALL-Router.
- Wir konfigurieren die externe IP-Adresse (für NAT), die am FW-Cluster verwendet wurde.
- Wir generieren gARP-Anfragen, damit die MAC-Adressen in den ARP-Tabellen von L3-CORE von FW-Cluster auf NOTFALL-Router geändert werden.
- Wir setzen die Standardroute statisch bis BRD-01, BRD-02.
- Wir erstellen NAT-Regeln.
- Wir aktivieren OSPF Area 1 am NOTFALL-Router.
- Wir aktivieren OSPF Area 2 am NOTFALL-Router.
- Wir setzen die Kosten für Routen in Area 1 auf 10.
- Wir setzen die Kosten für die Standardroute in Area 1 auf 10.
- Wir ändern IP-Adressen, die mit L2-MGMT verbunden sind (auf die, die am FW-CLUSTER waren).
- Wir generieren gARP-Anfragen, damit die MAC-Adressen in den ARP-Tabellen von L2-MGMT von FW-CLUSTER auf NOTFALL-Router geändert werden.
Kommen wir wieder zur ursprünglichen Aufgabenstellung zurück. Es ist drei Uhr morgens, enormer Stress, ein Fehler in jedem der Schritte kann zu weiteren Problemen führen. Sind Sie bereit, Befehle über die CLI einzugeben? Ja? Gut, gehen Sie zuerst, waschen Sie Ihr Gesicht, trinken Sie einen Kaffee und sammeln Sie Ihren Mut.
Bruce, bitte hilf den Jungs.
Wir machen unterdessen weiter mit unserer Automatisierung.
Im Folgenden finden Sie das Schema des Playbooks in Ansible-Termini. Dieses Schema spiegelt das wider, was wir zuvor beschrieben haben, jedoch bereits als konkrete Implementierung in Ansible.
An diesem Punkt haben wir erkannt, was zu tun ist, ein Playbook entwickelt, Tests durchgeführt und sind jetzt bereit, es zu starten.
Ein kurzer Einschub: Die Leichtigkeit der Erzählung sollte Sie nicht irreführen. Der Prozess des Schreibens von Playbooks war nicht so einfach und schnell, wie es scheint. Die Tests nahmen viel zeit in Anspruch, es wurde eine virtuelle Testumgebung geschaffen, die Lösung wurde mehrfach getestet, und es fanden etwa 100 Tests statt.
Wir starten... Es fühlt sich so an, als ob alles sehr langsam geschieht, irgendwo könnte ein Fehler sein, irgendetwas wird am Ende nicht funktionieren. Es ist ähnlich dem Gefühl, mit einem Fallschirm zu springen, während der Fallschirm sich zunächst nicht öffnen will... das ist normal.
Anschließend lesen wir die Ergebnisse der ausgeführten Operationen des Ansible-Playbooks (die IP-Adressen wurden aus Gründen der Vertraulichkeit ersetzt):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Notfall auf VCF] ********************************************************
TASK [vcf_junos_emergency_on : Deaktivieren der PROD-Schnittstellen zu FW-CLUSTER] *********************
changed: [vcf]
PLAY [------->Notfall auf MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Deaktivieren der MGMT-Schnittstellen zu FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]
PLAY [------->Notfall aktivieren] ****************************************************
TASK [mk_routeros_emergency_on : Aktivieren der EXT-INTERNET-Schnittstelle] **************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : gARP für EXT-INTERNET-Schnittstelle generieren] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Statischen Standard-Routen zu EXT-INTERNET aktivieren] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : NAT-Regel für EXT-INTERNET-Schnittstelle ändern] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : OSPF Area 1 PROD aktivieren] ******************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : OSPF Area 2 MGMT aktivieren] *****************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Kosten der OSPF Area 1-Schnittstellen auf 10 ändern] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Standardkosten der OSPF Area 1 auf 10 ändern] ******************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : IP-Adressen der MGMT-Schnittstellen ändern] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : gARPs für MGMT-Schnittstellen generieren] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Fertig!
Tatsächlich ist es noch nicht ganz bereit. Wir dürfen die Konvergenz dynamischer Routing-Protokolle und die Überlastung einer Vielzahl von Routen im FIB nicht vergessen. Darauf haben wir keinen Einfluss. Wir warten. Jetzt ist es konvergiert. Jetzt ist es bereit.
Und im Dorf Villabaggio (das nicht will, dass die Netzwerkeinstellungen automatisiert werden) spülen sie weiterhin das Geschirr. Bruce (übrigens ein anderer, aber nicht weniger genial) versucht zu verstehen, wie viel Equipment noch manuell neu konfiguriert werden muss.
Ich möchte noch einen wichtigen Punkt ansprechen. Wie bringen wir alles zurück? Nach einer gewissen Zeit werden wir unser FW-CLUSTER wieder zum Leben erwecken. Es handelt sich um die primäre Hardware, nicht um eine Back-up-Lösung, und das Netzwerk muss darauf laufen.
Fühlen Sie, wie der Druck auf die Netzwerkadministrator:innen steigt? Der technische Direktor wird tausend Gründe hören, warum man das nicht tun sollte und warum man es später machen kann. Leider entsteht das Netzwerk oft aus vielen Flickstücken, Resten vergangener Zeiten. Es sieht aus wie ein Patchwork. Unsere Aufgabe, nicht nur in dieser spezifischen Situation, sondern im Allgemeinen als IT-Spezialisten, ist es, das Netzwerk zu einem schönen englischen Wort zu bringen: 'Konsistenz'. Das ist vielschichtig und lässt sich übersetzen als: Harmonie, Widerspruchsfreiheit, Logik, Teamarbeit, Systematik und Kohärenz. All das beschreibt es. Nur in diesem Zustand ist das Netzwerk verwaltbar, wir verstehen klar, was funktioniert und was nicht, wir wissen genau, was im Bedarfsfall geändert werden muss, und wo wir bei Problemen hinschauen sollten. Nur in einem solchen Netzwerk können die Tricks durchgeführt werden, die wir gerade beschrieben haben.
Tatsächlich wurde ein weiterer Playbook vorbereitet, der die Einstellungen in den Ursprungszustand zurückversetzte. Die Logik seiner Funktionsweise ist die gleiche (es ist wichtig, sich daran zu erinnern, dass die Reihenfolge der Aufgaben sehr wichtig ist). Um den schon recht langen Artikel nicht unnötig zu verlängern, haben wir beschlossen, die Ausführungsliste des Playbooks nicht zu veröffentlichen. Nach solchen Übungen werden Sie sich viel ruhiger und sicherer fühlen, zudem werden alle improvisierten Lösungen sofort offensichtlich.
Alle Interessierten können uns kontaktieren und die Quellcodes aller geschriebenen Codes sowie aller Playbooks erhalten. Kontakte finden Sie im Profil.
Fazit
Aus unserer Sicht haben sich die Prozesse, die automatisiert werden können, noch nicht herauskristallisiert. Basierend auf den Erfahrungen, die wir gemacht haben, und den Diskussionen, die wir mit unseren westlichen Kollegen geführt haben, sind bisher folgende Themen erkennbar:
- Gerätebereitstellung;
- Datensammlung;
- Berichterstattung;
- Fehlerbehebung;
- Compliance.
Falls Interesse besteht, können wir die Diskussion zu einem der genannten Themen fortsetzen.
Außerdem möchten wir etwas über die Automatisierung nachdenken. Wie sollte sie unserem Verständnis nach sein:
- Das System sollte ohne menschliches Zutun arbeiten und sich gleichzeitig durch menschliche Eingriffe verbessern. Das System sollte nicht von Menschen abhängig sein;
- Der Betrieb sollte von Experten durchgeführt werden. Es fehlt an Fachkräften, die routinemäßige Aufgaben erledigen. Stattdessen gibt es Experten, die alle Routineprozesse automatisiert haben und sich nur um komplexe Herausforderungen kümmern;
- Routineaufgaben werden automatisch „auf Knopfdruck“ erledigt, sodass keine Ressourcen verschwendet werden. Die Ergebnisse solcher Aufgaben sind stets vorhersehbar und nachvollziehbar.
Und wohin sollen diese Punkte führen:
- Transparenz der IT-Infrastruktur (geringere Risiken bei Betrieb, Modernisierung und Implementierung. Weniger Ausfallzeiten pro Jahr);
- Möglichkeit zur Planung von IT-Ressourcen (Capacity-Planning-System — es ist sichtbar, wie viel benötigt wird und wie viele Ressourcen in einem zentralen System erforderlich sind, anstatt über E-Mails und Gespräche mit Abteilungsleitern);
- Möglichkeit, die Anzahl des IT-Personals zu reduzieren.
Autoren des Artikels: Alexander Tscheljakow (CCIE RS, CCIE SP) und Pawel Kirillow. Wir sind daran interessiert, über Lösungen zur Automatisierung von IT-Infrastrukturen zu diskutieren und Vorschläge zu machen.
Quelle: habr.com
