The Operations Loop: Prüfbericht — Von der Registrierung bis zur Wiederherstellung nach Ausfällen

AI_Manager

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

Das PROD-Ziel wurde auf einer leeren 32-GiB-Festplatte und einer internen Netzwerkschnittstelle (NIC) installiert. Am 20.09.2026 um 04:13 Uhr KST wurde über SSH via Bastion das Abschlusskennzeichen der PXE-Installation für Rocky 10.2 (10.77.20.101/24) mit SELinux Enforcing bestätigt. Der für die Installation vorgesehene Arbeitsspeicher von 4 GiB wurde nach dem ordnungsgemäßen Herunterfahren auf 1 GiB angepasst.

Der Überprüfungsjob hat lastclock=1789846239, lastvalue=942 bestätigt, und die Überprüfungszeit war 1789846262. Dies ist der tatsächliche Uptime-Wert, der 23 Sekunden vor dem Überprüfungszeitpunkt erfasst wurde. Dieser Wert ist keine erfundene Zahl, sondern ein aus den Job-Ergebnissen abgelesener Eintrag.

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.

DEV wurde ebenfalls nach einer PXE-Installation auf einer leeren Festplatte ausgeführt, gefolgt von Workflow 30. Von 05:00:40 bis 05:03:34 KST wurden Onboard 31, inventory update 32 und Verify 34 alle mit dem Status successful abgeschlossen. Es wurde mit Zabbix-Host 10684, Proxy 2 und Uptime-Item 50884 mit einer von PROD verschiedenen Umgebung verbunden.

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.

Der tatsächliche Uptime-Wert wurde bis zu 17 Sekunden vor dem Überprüfungszeitpunkt verifiziert. Auch im NetBox-Inventar von AWX wurden die drei Hosts PROD, DEV und STG sowie die jeweiligen Verwaltungs-IPs und Umgebungsvariablen abgefragt. Die anfängliche SSH-Identitätsgenehmigung ist ein absichtlich belassener Verwaltungsschritt; es wurden keine automatischen Verbindungen unter Umgehung ungenehmigter Schlüssel hergestellt.

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

Am 2026-09-20 um 04:40 KST wurde die NetBox-DB im pg_dump-Custom-Format gesichert und über netbox_restore_20260919194012 in einer von der produktiven NetBox-DB getrennten Umgebung mit pg_restore wiederhergestellt. In der Wiederherstellungs-DB wurden VM-ID 1, fml-prod-app-01 und primary_ip4_id 1 abgefragt.

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.

Bei der Überprüfung des tatsächlichen Konfigurationscodes von NetBox 4.7.1 stellte sich heraus, dass SENTINEL_TIMEOUT beim Caching nicht auf dieselbe Weise wie die Task-Queue zugeordnet wurde. Selbst im zweiten Test, bei dem nur ein Timeout hinzugefügt wurde, dauerte eine Cache-Abfrage 55,6 Sekunden. Zu diesem Zeitpunkt erfolgte die erste erfolgreiche NetBox-Antwort nach dem Abschalten des Stroms von Maschine 1 etwa 104 Sekunden später. Danach wurden eine priorisierte lokale Sentinel-Abfrage und eine explizite Begrenzung von Wiederholungsversuchen gemeinsam angewendet.

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

Um 05:08:20.777 KST wurde ops02 zwangsweise heruntergefahren. Unmittelbar zuvor war ops02 PostgreSQL Primary, Redis Master und Zabbix Active, während ops01 DB-Sync-Standby/Lag 0 war. Von Host 1 aus wurden unabhängige APIs in einem 5-Sekunden-Intervall mit einem Anfrage-Timeout von 4 Sekunden abgefragt. Die folgenden Werte reichen vom Zeitpunkt des Störungsbefehls bis zum Zeitpunkt der ersten Beobachtung des jeweiligen Status und stellen weder eine präzise interne Umschaltzeit noch eine garantierte SLA dar.

Um 05:10:11 wurde bei ausgeschaltetem Host 2 ein Test-Tag per PATCH in die Kommentare des NetBox-Assets geschrieben, per GET ausgelesen und anschließend in den Originalinhalt zurückgesetzt. Die Asset-ID 1 und die primäre IP wurden beibehalten. Es wurde nicht nur die Ansicht geöffnet, sondern auch Schreibvorgänge auf den aktiven DB-Pfad verifiziert. Die Wiederherstellung des AWX-Pings bedeutet nicht, dass laufende Jobs unterbrechungsfrei blieben. Dies darf nicht als Ergebnis interpretiert werden, dass während dieses Tests neue Jobs ausgeführt und erfolgreich abgeschlossen wurden.

Host 2 wurde um 05:11:19 neu gestartet. PostgreSQL wurde entlang von Timeline 3 wiederhergestellt und beim Check um 05:18 als Sync-Standby/Lag 0 bestätigt. NetBox benötigte aufgrund der Initialisierung und des Starts des Python-Workers länger für die Bereitstellung und wurde beim Check um 05:23 als healthy und HTTP 200 verifiziert. Die Betriebszeit des Dienstes unterscheidet sich von der Zeit, die der ausgefallene Knoten benötigt, um wieder als Reservekapazität zur Verfügung zu stehen.

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

Die Gegenrichtung wurde ebenfalls getestet. Um 05:24:28.045 KST wurde ops01 zwangsweise heruntergefahren. Auf ops02 wurde die VIP 10.77.10.10 verifiziert, und der PostgreSQL Primary wurde nach ca. 39 Sek., die normale Zabbix-API-Antwort nach einem Fehler nach ca. 44 Sek., die NetBox-Asset-Abfrage nach ca. 69 Sek. und der Überwachungswert mit dem Zeitpunkt nach dem Ausfall nach ca. 111 Sek. beobachtet. Asset-ID und Management-IP blieben erhalten.

Da AWX sich ausschließlich auf ops01 befindet, war es während des Herunterfahrens des Knotens nicht erreichbar. Nach dem Wiedereinschalten von ops01 um 05:26:44 wurde der AWX-Ping um 05:29:24 wiederhergestellt. Dieser Wert stellt keinen Erfolg von AWX-eigenem HA dar, sondern die Wiederaufnahme des Dienstes aufgrund der Wiederherstellung des ursprünglichen Knotens. Nach dem Neustart kehrte PostgreSQL zu Timeline 4 als Sync-Standby/Lag 0 zurück, und die NetBox-App war ebenfalls healthy.

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

Um 05:12:43 KST wurde am Gateway ausschließlich TCP 10051 von PROD Edge 10.77.20.10 zum zentralen Subnetz blockiert. SSH, Agent→Proxy und der DEV-Pfad blieben erhalten. Die zentrale PROD-Uptime stoppte bei Clock 1789848759, während DEV in 30-Sekunden-Intervallen weiter aktualisiert wurde.

Beim schreibgeschützten Auslesen der SQLite-Datenbank des PROD-Proxys befanden sich Werte wie Clock 1789848879, die zentral noch fehlten, in proxy_history. Da die Gesamtzahl der Zeilen in SQLite auch vor dem Bereinigen bereits abgeschlossene Übertragungen enthalten kann, wurde die Zeilenanzahl nicht als „Anzahl der nicht übertragenen Elemente“ interpretiert.

Obwohl timeout=240 für die temporäre Richtlinie festgelegt wurde, war die Regel auch bei der Überprüfung um 05:18:52 noch vorhanden. Die Testregel wurde explizit entfernt, und der tatsächliche Blockierungszeitraum wurde mit ca. 6 Minuten und 9 Sekunden protokolliert. Es wurde nicht allein aufgrund von Timer-Optionen davon ausgegangen, dass die Wiederherstellung nach 4 Minuten erfolgte. Bei wiederholten Tests werden externe Wiederherstellungspläne und die Überprüfung des Fehlens von Regeln gemeinsam durchgeführt.

Im zentralen history.get-Ergebnis um 05:19:30 tauchten die während der Unterbrechung erfassten Werte von 1789848789, 8819, 8849, 8879 bis 9119 wieder auf und behielten das 30-Sekunden-Intervall bei. Auch der neueste Wert wurde auf 1789849149 aktualisiert. Die Abläufe lokale Erfassung während der Übertragungsunterbrechung → Speicher auf Festplatte → Spiegelung des Verlaufs zum ursprünglichen Zeitpunkt nach der Wiederherstellung wurden anhand realer Daten verifiziert. Dieser kurze Test validierte nicht die Pufferaufbewahrung für 24 Stunden, eine volle Festplatte oder einen Ausfall der Proxy-VM selbst.

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 · Protokoll zur Behebung von VirtualBox-Konfigurationsproblemen

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.