Pasen & Pinksteren: downtime openov GTFS-RT

[Stefan de Konink]

Nouja, het moment is toch gekomen: We hebben/hadden wat problemen in het
afgelopen uur met onze GTFS en GTFS-RT dienstverlening. Zoals het nu gaat
gaan we op onze redundante infrastructuur verder en schakelen we later weer
terug.

Met dank aan GoAbout voor de mentale ondersteuning vanavond.

--
Stefan

[Stefan de Konink]

Het leukste van problemen is dat je de aanleiding en oorzaak natuurlijk ook
gewoon met elkaar kunt delen, omdat we allemaal wel eens falen. Doe je dat
niet (falen), hebben we ook zeker plek voor je als beheerder.

Als eerste, we draaien al jaren een tweede GTFS-RT systeem schaduw en we
hebben ook een tweede onafhankelijke database draaien. Er worden zelfs
automatische backups van gemaakt, dus het overschakelen bij problemen is
een DNS TTL verder. Het mooiste was ook nog eens: gisteren om 12 uur (check
zabbix!) hebben we die schaduw systemen ook nog eens voorzien van software
updates, dus alles was daar spik en span.

Vandaag was het dus Pinksteren en ik had geen downtime gepland, tot we
opeens een berichtje op Telegram binnen kregen van de onvolprezen
UptimeRobot. Ik wilde schrijven "Het is niet als of er een e1000 in zit,
die om onbekende redenen uitvalt", maar haha er zit dus wel gewoon een
PRO/1000 in. Welliswaar met een ee1004 module. Maar goed: het systeem was
onbereikbaar. Met hulp van GoAbout konden we in ieder geval een reset doen.

We maken gebruik van een softraid 1 configuratie op twee nvme chipjes. En
vanuit een rescue shell is net vaak even vechten om een werkde configuratie
weer aan te krijgen. De raid configuratie was ook direct de achilleshiel.
We gebruiken alleen raid op de root partitie, maar de GPT BIOS boot, en
werkelijke boot partities zijn niet gemirrored. Het lijkt er ook op of er
bij het opstarten geen volgorde in zit. De oplossing was uiteindelijk ook
gewoon de boot partitie van dezelfde kernel te voorzien.

Volgens journalctl --list-boots zou het systeem in de afgelopen dagen al
een aantal keer (succesvol) herstart zijn, maar het ontging me dan wie of
wat dat zou hebben veroorzaakt en waarom daar dan geen bericht van was
gekomen. De enige hint die uit journalctl kwam was dat de schijf vol was.
Waarom dat herstarten veroorzaakt ontging me.


Goed, nu we toch bezig waren. Database gedumpt, systeem bijgewerkt,
database herstelt, wireguard geconfigureerd en herstart. (Dit was niet de
volgorde waarin het heeft plaatsgevonden, maar dat had wel verreweg het
snelste geweest.)

--
Stefan