The Operations Loop: verificatieverslag — Van registratie tot herstel na een storing

AI_Manager

De maatstaf voor validatie is niet of een scherm opent, maar of data en paden daadwerkelijk met elkaar zijn verbonden. Dit artikel legt de taken en observatieresultaten vast die zijn uitgevoerd tijdens de VirtualBox-praktijktest op 2026-09-20. Er wordt onderscheid gemaakt tussen verwachte ontwerpresultaten, daadwerkelijke tests en de scope die nog niet is uitgevoerd.

• 1. Validatieomgeving en beoordelingscriteria
• 2. Echte normale onboarding-logboek
• 3. Gevonden en opgeloste problemen tot aan het normale pad
• 4. Backup en geïsoleerd herstel
• 5. Test voor storing van centraal knooppunt
• 6. Proxy-verbinding verbreken en hertransmissie van vertraagde data
• 7. Bescherming van activadata en padvalidatie
• 8. Installatie van doelsysteem zonder internet en pakketvalidatie
• 9. Validatie van architectuurscherm
• 10. Validatiechecklist en grenzen
• Verwante lectuur en configuratiematerialen

1. Validatieomgeving en beoordelingscriteria

Er is gebruikgemaakt van Rocky Linux 10.2, Zabbix 7.0.30 LTS, NetBox 4.7.1 en AWX 24.6.1. Twee centrale VM’s en een quorum, Gateway, Provision en Proxy-/Bastion-omgevingen voor drie zones zijn geconfigureerd. Alle VM’s delen het geheugen, de CPU en de opslag van één fysieke pc.

Een normale onboarding slaagt alleen als PXE-installatie → goedgekeurd SSH-pad → werkelijke verzameling van assetgegevens → NetBox native IPAM → Zabbix-registratie → NetBox-gebaseerde AWX-inventarisatiesynchronisatie → bevestiging van de daadwerkelijke nieuwste waarde allemaal succesvol zijn. Een API-registratierespons en de ontvangst van de meest recente data zijn afzonderlijke controlepunten.

2. Echte normale onboarding-logboek

Het PROD-doelsysteem is geïnstalleerd met een lege schijf van 32GiB en één intern netwerk-NIC. Op 2026-09-20 om 04:13 KST is via SSH via de Bastion de voltooiingsmarkering van de PXE-installatie geverifieerd voor Rocky 10.2, 10.77.20.101/24 met SELinux Enforcing. Het installatie-RAM van 4GiB is na normaal afsluiten aangepast naar 1GiB.

Verify Job heeft lastclock=1789846239, lastvalue=942 geverifieerd en het verificatietijdstip was 1789846262. Dit is de daadwerkelijke uptime-waarde verzameld 23 seconden voor het verificatiemoment. Deze waarde is geen zelfbedacht cijfer, maar een gelezen record uit het Job-resultaat.

In NetBox zijn vCPU 1, 954MiB beschikbaar gastgeheugen, 32768MiB schijfruimte, Rocky Linux 10.2, virtualisatietype virtualbox, beheer-NIC enp0s3, de PROD-omgeving en de daadwerkelijke partitiestructuur opgeslagen. De waargenomen geheugenwaarde van de gast van 954MiB en de door VirtualBox toegewezen waarde van 1024MiB verschillen van elkaar.

In de NetBox-inventaris van AWX zijn ansible_host=10.77.20.101, ansible_user=labadmin, fml_environment=prod en fml_subnet=20 binnengekomen. Niet alleen de assetnamen zijn gesynchroniseerd, maar ook het beheer-IP en de omgevingsvariabelen die nodig zijn voor de berekening van het Bastion-pad.

DEV heeft eveneens na PXE-installatie op een lege schijf Workflow 30 uitgevoerd. Van 05:00:40~05:03:34 KST zijn Onboard 31, inventory update 32 en Verify 34 allemaal als successful voltooid. Met Zabbix host 10684, proxy 2 en uptime item 50884 is er verbinding gemaakt met een andere omgeving dan PROD.

STG wordt automatisch gestart bij detectie van voltooide installatie

Na het goedkeuren van de eerste SSH-identiteit van STG via de publieke sleutel en fingerprint van de VirtualBox serial console, is het installatiegeheugen verlaagd van 4GiB naar 1GiB. De installatievoltooiingscontroller heeft de goedkeuringssleutel, installatiemarkering, hostname en machine ID geverifieerd en de SCM- en bootstrap-inventaris gesynchroniseerd. Vervolgens is Job 38 gestart zonder handmatige Workflow-uitvoering.

De daadwerkelijke uptime-waarde tot 17 seconden vóór het verificatietijdstip werd gecontroleerd. In de NetBox-inventaris van AWX werden tevens de drie hosts PROD, DEV en STG en hun respectieve beheer-IP’s en omgevingsvariabelen opgehaald. De initiële SSH-identiteitsgoedkeuring is een bewuste beheerstap en niet een automatische verbinding waarbij niet-goedgekeurde sleutels werden omzeild.

3. Gevonden en verholpen problemen tot aan het normale pad

Mislukte taken werden niet verwijderd. Ze zijn bewaard zodat de correctiecommit kan worden vergeleken met het resultaat van de volgende Job. Gevallen waarin het mislukte vóór registratie in NetBox/Zabbix worden niet verward met situaties waarin assets dubbel zijn aangemaakt.

4. Back-up en herstel in geïsoleerde omgeving

Op 2026-09-20 om 04:40 KST is er een back-up gemaakt van de NetBox DB in pg_dump custom format en is deze via pg_restore teruggezet in een andere netbox_restore_20260919194012 dan de operationele NetBox DB. In de herstelde DB zijn VM ID 1, fml-prod-app-01 en primary_ip4_id 1 opgehaald.

De SHA-256 van de back-up is 06914eb419d88edb97245ed435177b396309a625b65eb14b72ae9fb627667390. Er is een aparte verificatiedatabase gebruikt in plaats van de bestaande database te overschrijven. Dit resultaat betreft een test voor het herstellen van een logische NetBox-database en geldt niet als een disaster recovery-test waarbij alle VM’s, media, AWX en Git in één keer worden hersteld.

5. Test van storing in centrale knooppunt

Vlak voor de eerste test was de PostgreSQL leader ops02, was ops01 een sync standby en bedroeg de replicatielag 0. Zabbix had ops01 als active en ops02 als standby. De stroom van machine 1 werd geforceerd uitgeschakeld om stroomverlies van de VM te simuleren.

VIP 10.77.10.10 verplaatste naar machine 2. Tijdens de overgangsfase gaf de NetBox-backend echter 500 en de VIP 503 terug. Zabbix startte hierna actieve taken op machine 2 en ontving de verbindingen van de drie proxyservers. Deze test werd niet aangemerkt als een ‘succesvolle HA zonder onderbreking’.

Het eerste logbestand van het observatietool werd niet aangemaakt vanwege een pad dat niet overeenkwam met het SELinux-beleid. Zodoende wordt er in die test geen nauwkeurige RTO berekend. Nadat het logpad was verplaatst naar onder /var/log en de correcte registratie was geverifieerd, is de test herhaald.

Bij het controleren van de daadwerkelijke configuratiecode van NetBox 4.7.1 bleek dat SENTINEL_TIMEOUT van caching niet op dezelfde manier werd gemengd als de task queue. Zelfs in de tweede test, waarbij enkel de timeout was toegevoegd, duurde een enkele cache-opvraging 55,6 seconden. Hierbij was het eerste succesvolle antwoord van NetBox na het onderbreken van de stroom op machine 1 circa 104 seconden later. Vervolgens zijn lokaal prioriteit geven aan Sentinel-opvragingen en het expliciet beperken van herpogingen gezamenlijk toegepast.

Stroomverlies op actieve machine 2 voor DB, Redis en Zabbix na correctie

Om 05:08:20.777 KST is ops02 gedwongen afgesloten. Vlak daarvoor was ops02 PostgreSQL primary, Redis master en Zabbix active, en had ops01 DB sync standby/lag 0. Vanaf machine 1 zijn onafhankelijke API’s bevraagd met een interval van 5 seconden en een request timeout van 4 seconden. De onderstaande waarden lopen vanaf het tijdstip van het storingscommando tot het tijdstip waarop de status voor het eerst werd waargenomen en vormen geen nauwkeurige interne omschakelingstijd of gegarandeerde SLA.

Om 05:10:11, terwijl machine 2 was uitgeschakeld, is een testmarkering gepatcht (PATCH) in de comments van een NetBox-asset, uitgelezen via GET en vervolgens hersteld naar de originele inhoud. Asset-ID 1 en het primary IP-adres zijn behouden. Niet alleen werd het overzicht geopend, maar ook schrijven naar het actieve DB-pad werd geverifieerd. Het herstel van de AWX ping betekent niet dat lopende jobs zonder onderbreking zijn uitgevoerd. Dit mag niet worden geïnterpreteerd als een resultaat waarin een nieuwe job werd gestart en met succes voltooid tijdens deze test.

Machine 2 is om 05:11:19 opnieuw opgestart. PostgreSQL is hersteld volgens timeline 3 en bij de controle om 05:18 bevestigd als sync standby/lag 0. NetBox was later gereed vanwege initialisatie en het starten van Python workers; bij de controle om 05:23 werd healthy·HTTP 200 bevestigd. De servicetijd bij uitval en de tijd die een storingsknooppunt nodig heeft om weer beschikbaar te komen als reservecapaciteit verschillen van elkaar.

Stroomuitval actieve machine 1 na wijziging VIP·DB·Zabbix

De omgekeerde richting is eveneens getest. Om 05:24:28.045 KST is ops01 gedwongen afgesloten. Op ops02 werd VIP 10.77.10.10 bevestigd, en de PostgreSQL primary werd waargenomen na ca. 39 seconden, een normale Zabbix API-respons na fouten na ca. 44 seconden, NetBox-assetopvraging na ca. 69 seconden, en de bewakingswaarde met een tijdstip na de storing na ca. 111 seconden. Asset-ID en beheer-IP zijn behouden.

Omdat AWX zich alleen op ops01 bevindt, was deze niet bereikbaar zolang het knooppunt uitgeschakeld was. Nadat ops01 om 05:26:44 weer werd ingeschakeld, herstelde de AWX ping om 05:29:24. Deze waarde is geen bewijs van een succesvolle AWX-eigen HA, maar een hervatting van de service als gevolg van het herstel van het oorspronkelijke knooppunt. Na herstart keerde PostgreSQL terug naar timeline 4 sync standby/lag 0 en was ook de NetBox App healthy.

Beide tests omvatten timeouts en HTTP 500/503 tijdens het omschakelingsinterval. Er wordt niet gesproken over ‘zonder onderbreking’. Cijfers van vergelijkbare tests voor en na verbeteringen mogen niet worden gebruikt om conclusies te trekken over de effectiviteit van prestatieverbeteringen op basis van een eenvoudige verhouding, aangezien de actieve database-locatie en de belasting verschilden.

6. Proxy-verbinding verbreken en vertraagde data opnieuw verzenden

Om 05:12:43 KST is op de Gateway uitsluitend het TCP-verkeer van PROD Edge 10.77.20.10 naar TCP-poort 10051 op de centrale servers geblokkeerd. SSH, Agent→Proxy en DEV-paden bleven behouden. De centrale PROD uptime bleef stilstaan op clock 1789848759, maar DEV werd elke 30 seconden bijgewerkt.

Bij het raadplegen van de SQLite van de PROD-proxy in alleen-lezenmodus bleken er waarden zoals clock 1789848879, die nog niet centraal aanwezig waren, in proxy_history te staan. Omdat het totale aantal rijen in SQLite ook reeds verzonden rijen vóór opschoning kan bevatten, is het aantal rijen op zich niet geïnterpreteerd als het ‘aantal niet-verzonden rijen’.

Hoewel timeout=240 was ingesteld in het tijdelijke beleid, was de regel bij controle om 05:18:52 nog steeds aanwezig. De desbetreffende testregel is expliciet verwijderd en de daadwerkelijke onderbrekingsperiode is geregistreerd als ca. 6 minuten en 9 seconden. Er is niet geschreven dat het na 4 minuten was hersteld op basis van alleen de timeroptie. Bij herhaalde tests worden externe herstelplanning en verificatie van het ontbreken van regels gecombineerd.

Om 05:19:30 verschenen in het centrale history.get-resultaat de waarden verzameld tijdens de onderbreking opnieuw, van 1789848789, 8819, 8849, 8879 tot 9119, met behoud van het interval van 30 seconden. De meest recente waarde werd eveneens bijgewerkt naar 1789849149. Lokaal verzamelen tijdens onderbreking van verzending → opslag op schijf → aanvulling van de historische gegevens op oorspronkelijk tijdstip na herstel is bevestigd met daadwerkelijke data. Deze korte test verifieert niet het behoud van buffers gedurende 24 uur, een volle schijf of een storing van de proxy-VM zelf.

7. Gegevensbescherming van assets en padverificatie

Op basis van de daadwerkelijke PROD-verzamelresultaten is dezelfde NetBox-registratie opnieuw uitgevoerd. VM-ID 1 en IPAddress ID 1 bleven behouden en dezelfde naam en hetzelfde adres bestonden elk slechts eenmaal. Het bijwerken van het verzameltijdstip en het aanmaken van dubbele assets werden van elkaar onderscheiden.

Gedeeltelijke verzamelfouten zijn invoer gemaakt voor testdoeleinden en worden niet gepresenteerd als echte gevallen van schijfstoringen. Voorwaarden voor weigering worden eerst gecontroleerd en daarna pas gewijzigd, en situaties waarin slechts sommige API’s succesvol waren, leiden er niet toe dat succesvolle objecten onvoorwaardelijk worden verwijderd, maar maken heruitvoering mogelijk.

8. Installatie op doelen zonder internet en pakketverificatie

Het PXE-doel heeft slechts één interne netwerk-NIC en geen NAT- of bridge-NIC. Het besturingssysteem is verkregen uit de minimale installatieboom van Provision voor Rocky 10.2. Nadat de agent-RPM-cache van PROD was geleegd, werden slechts twee interne repositories ingeschakeld om zabbix-agent2 7.0.30 opnieuw te installeren. De werkelijke download van 6.4 MB, GPG-verificatie en actieve status van de service zijn geverifieerd.

NetBox HTTPS die interne repo-metagegevens en CA-verificatie gebruikt op hetzelfde doel waar externe verbindingen zijn geweigerd, retourneerde 200. Een volledige herinstallatie van het centrale netwerk in een nieuw geïsoleerd netwerk valt buiten de scope. Wat deze keer is geverifieerd, is de OS-installatie, agentimplementatie en interne API-integratie voor doelen zonder internet.

9. Verificatie van architectuurscherm

De storingsstatus en het afspelen van het proces in de architectuur zijn uitsluitend ter illustratie. Het is geen operationeel dashboard waarmee opdrachten naar servers worden verzonden of de werkelijke status wordt weergegeven.

10. Verificatiechecklist en grenzen

UEFI PXE van echte fysieke servers, BMC- en RAID-automatisering, storingen tussen twee fysieke hosts, totale storingsopslag en detectie van alle commerciële DB/WAS-productversies worden niet geacht te zijn geverifieerd door deze VM-oefening. De implementatie van elke functie en het werkelijke testbereik worden van elkaar gescheiden.

Er wordt tevens onderscheid gemaakt tussen online initiële installatie en installatie/agentdistributie voor doelsystemen zonder internet. Tests waarbij de volledige centrale omgeving vanaf nul opnieuw wordt geïnstalleerd in een nieuw geïsoleerd netwerk, moeten ook de afhankelijkheidsverificatie van het importpakket omvatten. Dit wordt niet vervangen door het resultaat van het verbreken van alleen de externe NIC van een bestaande service.

De items die in deze oefening zijn doorstaan en de volgende verificatietaken staan in dezelfde tabel vermeld. De resultaten van één persoonlijke pc mogen niet worden voorgesteld als een operationele SLA of een garantie voor no data loss bij alle storingen.

Verder lezen en configuratiemateriaal

Originele portfolio · Gids voor het bouwen van online en geïsoleerde netwerken · Storingsscenario’s en verificatielogboeken · Logboek voor het oplossen van VirtualBox-configuratieproblemen

ZIP met oefenconfiguratie en automatiseringsbronnen · ZIP SHA-256

De openbare ZIP bevat configuratiesjablonen en automatiseringsbronnen. OS-, RPM-, containerimages en inloggegevens zijn niet inbegrepen. Configureer met uw eigen adres, openbare CA, geautoriseerde SSH-sleutel en geheime opslagplaats voordat u toepast.