The Operations Loop 03 — Failover und Wiederherstellung prüfen

EdwardMoon

Der Maßstab für eine Überprüfung ist nicht, ob sich ein Bildschirm öffnet, sondern ob Daten und Pfade tatsächlich miteinander verbunden sind. Dieser Beitrag dokumentiert die bei der VirtualBox-Praxisübung am 20.09.2026 ausgeführten Aufgaben und Beobachtungsergebnisse. Dabei wird zwischen architektonischen Erwartungen, tatsächlichen Tests und noch nicht durchgeführten Bereichen unterschieden.

• 1. Überprüfungsumgebung und Kriterien für die Beurteilung
• 2. Aufzeichnung des tatsächlichen erfolgreichen Onboardings
• 3. Erkannte und behobene Probleme bis zum Erreichen des regulären Pfads
• 4. Backup und isolierte Wiederherstellung
• 5. Test zum Ausfall des zentralen Knotens
• 6. Proxy-Unterbrechung und erneute Übertragung verzögerter Daten
• 7. Schutz von Asset-Daten und Pfadüberprüfung
• 8. Zielinstallation ohne Internet und Paketüberprüfung
• 9. Überprüfung der Architekturbildschirme
• 10. Überprüfungs-Checkliste und Grenzen
• Weiterführende Lektüre und Konfigurationsmaterialien

1. Überprüfungsumgebung und Kriterien für die Beurteilung

Es wurden Rocky Linux 10.2, Zabbix 7.0.30 LTS, NetBox 4.7.1 und AWX 24.6.1 verwendet. Es wurden zwei zentrale VMs sowie Quorum, Gateway, Provision und Proxy/Bastion für drei Umgebungen konfiguriert. Alle VMs teilen sich Arbeitsspeicher, CPU und Speicher eines physischen PCs.

Ein erfolgreiches Onboarding gilt erst dann als bestanden, wenn alle folgenden Schritte erfolgreich sind: PXE-Installation → autorisierter SSH-Pfad → tatsächliche Asset-Erfassung → NetBox-natives IPAM → Zabbix-Registrierung → NetBox-basierte AWX-Inventory-Sync → Überprüfung der tatsächlichen neuesten Werte. Eine API-Registrierungsantwort und der Empfang aktueller Daten sind unterschiedliche Prüfpunkte.

2. Aufzeichnung des tatsächlichen erfolgreichen Onboardings

PROD wurde auf einer leeren 32-GiB-Platte mit einer internen Netzwerkkarte installiert. SSH über den Bastion-Host bestätigte Rocky Linux 10.2, die Management-IP 10.77.20.101/24, SELinux Enforcing und die PXE-Abschlussmarkierung. Anschließend wurde der Speicher von 4 auf 1 GiB reduziert.

Der Prüfjob bestätigte den Empfang aktueller tatsächlicher Laufzeitdaten. Erfolgreiche Registrierung und funktionierende Überwachung waren gemeinsam die Abnahmekriterien.

In NetBox wurden 1 vCPU, 954 MiB für den Gast verfügbarer Speicher, 32768 MiB Festplatte, Rocky Linux 10.2, Virtualisierungstyp virtualbox, Verwaltungs-NIC enp0s3, die PROD-Umgebung und die tatsächliche Partitionsstruktur gespeichert. Der beobachtete Speicherwert des Gasts von 954 MiB und der zugewiesene VirtualBox-Wert von 1024 MiB sind unterschiedlich.

Das NetBox-Inventar von AWX erhielt ansible_host=10.77.20.101, ansible_user=labadmin, fml_environment=prod, fml_subnet=20. Es wurden nicht nur die Ressourcennamen synchronisiert, sondern auch die Verwaltungs-IP und die für die Berechnung des Bastion-Pfads erforderlichen Umgebungsvariablen gemeinsam überprüft.

Nach der PXE-Installation auf leerer Platte bestand DEV Workflow 30 mit Registrierung 31, Inventaraktualisierung 32 und Prüfung 34. Überwachungshost 10684 nutzte DEV-Proxy 2 und damit einen von PROD getrennten Pfad.

STG startet automatisch nach Erkennung des Installationsabschlusses

Nachdem die erste SSH-Identität von STG durch den Public Key und den Fingerprint der seriellen VirtualBox-Konsole autorisiert wurde, wurde der Installations-RAM von 4 GiB auf 1 GiB reduziert. Der Installationsabschluss-Controller bestätigte den Autorisierungsschlüssel, das Installationskennzeichen sowie Hostnamen und Maschinen-ID und synchronisierte das SCM- sowie das Bootstrap-Inventar. Danach wurde Job 38 ohne manuellen Workflow-Start begonnen.

Auch STG lieferte aktuelle reale Überwachungsdaten. AWX enthielt die drei Umgebungshosts mit Management-IP und Umgebungsvariablen. Die erste SSH-Identitätsfreigabe blieb eine Betreiberprüfung; nicht genehmigte Schlüssel wurden nicht umgangen.

3. Gefundene und behobene Probleme bis zum Normalpfad

Fehlgeschlagene Jobs wurden nicht gelöscht. Sie wurden belassen, um Korrektur-Commits mit den Ergebnissen des nächsten Jobs vergleichen zu können. Ein vor der NetBox/Zabbix-Registrierung aufgetretener Fehler wird nicht mit der Situation duplizierter tatsächlicher Assets verwechselt.

4. Backup und Isolationswiederherstellung

Die NetBox-Datenbank wurde mit pg_dump gesichert und mit pg_restore in eine separate Prüfdatenbank eingespielt. Das Asset fml-prod-app-01 und seine Zuordnung zur primären Management-IP blieben erhalten.

Der SHA-256-Hash des Backups lautet 06914eb419d88edb97245ed435177b396309a625b65eb14b72ae9fb627667390. Es wurde eine separate Verifizierungs-DB verwendet, ohne die bestehende DB zu überschreiben. Dieses Ergebnis ist ein Test der logischen NetBox-DB-Wiederherstellung und kein Notfallwiederherstellungstest, bei dem alle VMs, Medien, AWX und Git auf einmal wiederhergestellt werden.

5. Ausfalltest für den zentralen Knoten

Unmittelbar vor dem ersten Test war der PostgreSQL-Leader ops02, ops01 war ein Sync-Standby und die Replikationsverzögerung betrug 0. In Zabbix war ops01 aktiv und ops02 Standby. Der Strom von Maschine 1 wurde gewaltsam abgeschaltet, um einen VM-Stromausfall zu simulieren.

Die VIP 10.77.10.10 wechselte zu Maschine 2. Im Übergangsbereich gab das NetBox-Backend jedoch den Status 500 und die VIP den Status 503 zurück. Zabbix nahm daraufhin aktive Jobs auf Maschine 2 auf und empfing die Verbindungen der drei Proxies. Dieser Test wurde nicht als „erfolgreiches unterbrechungsfreies HA“ eingestuft.

Die erste Logdatei des Beobachtungswerkzeugs wurde aufgrund eines Pfads, der nicht zu den SELinux-Richtlinien passte, nicht erstellt. Daher wird in diesem Test keine präzise RTO berechnet. Nach dem Verschieben des Protokollierungspfads unter /var/log und der Bestätigung der ordnungsgemäßen Aufzeichnung wurde der Test wiederholt.

Anfangs verzögerten Wiederholungsversuche der Cache-Verbindung die NetBox-Wiederherstellung. Nach Prüfung des Konfigurationscodes wurden der lokale Sentinel bevorzugt und Verbindungs- sowie Wiederholungsversuche begrenzt. Danach wurde erneut getestet.

Stromausfall von Maschine 2 nach Behebung von DB, Redis und aktivem Zabbix

Der aktive zentrale Knoten 2 für PostgreSQL, Redis und Zabbix wurde zwangsweise ausgeschaltet. Rollenwechsel und Dienstantworten auf Knoten 1 wurden bestätigt. Vorübergehende Antwortfehler während des Wechsels schließen die Bewertung als unterbrechungsfreies Failover aus.

Bei ausgeschaltetem Knoten 2 wurde eine Testmarkierung in NetBox geschrieben, gelesen und zurückgesetzt. Asset und Management-IP blieben erhalten; Schreiben über die verbleibende DB funktionierte. Eine wiederhergestellte AWX-Statusantwort beweist keine Kontinuität laufender Jobs.

Nach dem Neustart kehrte Knoten 2 als synchroner PostgreSQL-Standby zurück, und NetBox wurde betriebsbereit. Dienstverfügbarkeit und Wiederherstellung der Reservekapazität wurden getrennt geprüft.

Stromverlust an Host 1 bei aktiven VIP, DB und Zabbix nach Änderung

Auch die Gegenrichtung wurde durch Ausschalten von Knoten 1 getestet. Knoten 2 behielt die gemeinsame Service-IP und DB-Schreibrolle; NetBox-Abfragen und neue Zabbix-Daten wurden wieder verfügbar. Asset-Identität und Management-IP blieben erhalten.

AWX lief nur auf Knoten 1 und war während dessen Ausfall nicht verfügbar. Der Neustart stellte AWX, DB-Replikation und NetBox wieder her. Dies war die Wiederherstellung des ursprünglichen Servers, kein AWX-HA-Erfolg.

Beide Tests beinhalten Timeouts und HTTP 500/503 im Übergangsbereich. Es wird nicht als „unterbrechungsfrei“ bezeichnet. Da sich die Datenbankaktivierungsposition und die Last bei Messungen vor und nach Verbesserungen ähnlicher Tests unterscheiden, darf die Leistungswirkung nicht anhand einfacher Verhältnisse abgeleitet werden.

6. Proxy-Trennung und erneute Übertragung verzögerter Daten

Am Gateway wurde nur TCP 10051 vom PROD-Proxy 10.77.20.10 zum zentralen Netz gesperrt. SSH, lokale Agent-Erfassung und DEV blieben erreichbar. Zentrale PROD-Aktualisierungen stoppten, während DEV weiter erfasste.

Die schreibgeschützte Prüfung der PROD-Proxy-Datenbank bestätigte lokal gespeicherte, zentral noch fehlende Daten. Die Gesamtzahl der Zeilen wurde wegen möglicherweise noch vorhandener bereits versendeter Datensätze nicht als Zahl ungesendeter Daten gewertet.

Die temporäre Sperrregel blieb trotz Ablaufkonfiguration bestehen. Sie wurde ausdrücklich entfernt und die Verbindung geprüft. Weitere Tests kontrollieren die tatsächliche Regelentfernung statt allein den Timer.

Nach Wiederkehr der Verbindung wurden gepufferte Daten in ursprünglicher Reihenfolge und mit ursprünglichem Erfassungsabstand zentral übernommen. Aktuelle Werte wurden wieder aktualisiert. Langzeitaufbewahrung, voller Datenträger und Ausfall der Proxy-VM bleiben separate Prüfungen.

7. Schutz von Asset-Daten und Pfadüberprüfung

Basierend auf den tatsächlichen PROD-Erfassungsergebnissen wurde dieselbe NetBox-Registrierung erneut ausgeführt. Die VM-ID 1 und die IPAddress-ID 1 wurden beibehalten, und derselbe Name sowie dieselbe Adresse existierten jeweils nur einmal. Es wurde zwischen der Aktualisierung des Erfassungszeitpunkts und der Erstellung doppelter Assets unterschieden.

Der teilweise Erfassungsfehler ist eine für Testzwecke erstellte Eingabe und wird nicht als realer Fall eines Festplattenausfalls vorgestellt. Ablehnungsbedingungen werden zuerst geprüft und dann geändert. Bei Situationen, in denen nur einige APIs erfolgreich waren, werden erfolgreiche Objekte nicht bedingungslos gelöscht, sondern können zu einer erneuten Ausführung führen.

8. Installation auf Zielen ohne Internet und Paketüberprüfung

Das PXE-Ziel verfügt nur über eine interne Netzwerk-NIC und keine NAT- oder Bridge-NIC. Das Betriebssystem wurde vom Rocky 10.2 Minimal-Installationsbaum von Provision bezogen. Nachdem der Agent-RPM-Cache von PROD geleert wurde, wurden nur zwei interne Repositorys aktiviert und zabbix-agent2 7.0.30 wurde neu installiert. Der tatsächliche Download von 6.4 MB, die GPG-Überprüfung und der aktive Dienst wurden bestätigt.

NetBox HTTPS mit interner Repo-Metadaten- und CA-Überprüfung gab auf demselben Ziel mit verbindungseingeschränktem Externbereich den Status 200 zurück. Eine vollständige Neuinstallation der gesamten Zentrale in einem neuen isolierten Netzwerk liegt außerhalb des Rahmens. Was diesmal verifiziert wurde, ist die Betriebssysteminstallation, das Agenten-Deployment und die interne API-Integration für Ziele ohne Internetzugang.

9. Überprüfung der Architekturanzeige

Der Ausfallstatus und die Ablaufwiedergabe der Architektur dienen Erklärungszwecken. Es handelt sich hierbei um kein Betriebsdashboard zum Senden von Befehlen an Server oder zum Anzeigen des tatsächlichen Status.

10. Verifizierungs-Checkliste und Grenzen

Es gilt nicht als durch diese VM-Übung verifiziert, UEFI-PXE physischer Server, BMC- und RAID-Automatisierung, Ausfälle zwischen zwei physischen Hosts, vollständiger Speicherausfall oder die Erkennung aller kommerziellen DB/WAS-Produktversionen durchgeführt zu haben. Die Implementierung jeder Funktion und der tatsächliche Testumfang werden getrennt voneinander betrachtet.

Es wird auch zwischen der Online-Erstinstallation und der Installation sowie Agentenbereitstellung für Ziele ohne Internet unterschieden. Der Test zur Neuinstallation des gesamten zentralen Bereichs von Grund auf in einem neuen isolierten Netzwerk muss auch die Überprüfung der Abhängigkeiten des Importpakets umfassen. Dies wird nicht durch das Ergebnis ersetzt, bei einem bestehenden Dienst lediglich die externe NIC zu trennen.

Die in dieser Übung bestanden Punkte und die nächsten Verifizierungsaufgaben wurden in derselben Tabelle festgehalten. Die Ergebnisse eines einzelnen PCs dürfen nicht als Betriebs-SLA oder Garantie für Datenverlustfreiheit bei allen Ausfällen dargestellt werden.

Weiterführende Lektüre und Konfigurationsmaterialien

Portfolio-Original · Leitfaden zum Aufbau von Online- und isolierten Netzwerken · Fehlerszenarien und Verifizierungsprotokolle

ZIP mit Übungskonfiguration und Automatisierungsquellcode · ZIP SHA-256

Das öffentliche ZIP enthält Konfigurationsvorlagen und Automatisierungsquellcode. Betriebssysteme, RPMs, Container-Images und Anmeldeinformationen sind nicht enthalten. Die Anwendung erfolgt nach der Konfiguration mit eigenen Adressen, öffentlichen CAs, autorisierten SSH-Schlüsseln und Geheimhaltungsspeichern.