Beste klant/collega,

(Is dit bericht niet goed leesbaar? Bekijk dan de online versie.)

Op maandag 13 februari, om 12:25h hebben een aantal on-prem hosting diensten te maken gehad met een kortdurende (< 1 min) verstoring, te weten: icecast, DNS resolving, NTP en redir.omroep.nl. Dit was het gevolg van geplanned onderhoud waarbij een bepaald systeem onderdeel (systemd) iets harder om zich heen heeft geslagen dan de bedoeling was en een aantal diensten herstart zijn die niet op deze manier herstart hadden moeten worden. Ondertussen is de oorzaak van het probleem gevonden en is er een aanpassing gedaan zodat dit niet nogmaals voor kan komen.

Een onderdeel van de 2-maandelijkse software upgrades ronde op de on-prem (“netboot”) hosting omgeving is het maken van nieuwe OS images. Deze worden tijdens de upgrade ronde gedistribueerd naar alle servers. In zo'n nieuwer image kunnen updates zitten van bepaalde tools en/of bepaalde libraries. Bijvoorbeeld een nieuwe versie van een login-shell of een nieuwe versie van een dynamisch in te linken library.

Nadat een server voorzien is van een nieuw OS image kan het zijn dat bepaalde systeem services die op die server draaien nog gebruik maken van oude versies van dynamisch gelinkte libraries. Om ervoor te zorgen dat deze de nieuwe versies gaan gebruiken dienen de betrokken services herstart te worden. In de linux distributie die wij gebruiken (Centos8 = RHEL derivaat) is daar een standaard tool voor genaamd needs-updating, dat zoekt uit welke systeem services gerestart moeten worden.

In de architectuur die we hanteren op ons hosting platform is er een tamelijk strict ondersheid tussen diensten die onderdeel van onze publieke dienstverlening vormen (denk aan webservers, database servers, e.d.) en meer “huishoudelijke” diensten die alleen nodig zijn voor het goed functioneren van het OS als geheel. (b.v. logging en scheduling).

De “publieke” diensten worden in zo'n update ronde zo omzichtig mogelijk geherstart. Bijvoorbeeld, door webservers op de juiste manier te herstarten kunnen deze bijgewerkt worden, zonder dat de buitenwereld daar last van heeft. En zaken waarvoor dat niet mogelijk is schedulen we in het algemeen 's nachts tijdens een onderhoudswindow.

De “huishoudelijke” diensten hebben geen externe impact en de gedachte is dat deze overdag herstart kunnen worden.

Vanochtend is helaas gebleken dat de instantie binnen ons OS die over de huisgoudelijke diensten gaat (genaamd systemd) zich op een aantal servers vergrepen heeft aan de extern zichtbare publieke diensten en deze herstart heeft op een manier die niet helemaal comme-il-faut was, met als gevolg dat deze zaken een korte outage van ongeveer een minuut hebben gehad.

De reden dat dit gebeurd is, is dat er een noodzakelijke interactie is tussen beide types diensten. De huishoudmanager (systemd) gaat bij het starten van een server namelijk (noodzakelijkerwijze) ook over het starten van de publieke diensten. Vervolgens “onthoudt” systemd welke processen er gestart zijn en heeft zo een haakje om zaken te herstarten als systemd dat nodig acht.

Parallel aan het herstarten van de huishoudelijke diensten liep het proces om de publieke diensten te herstarten. Veel daarvan was al gedaan, maar niet alles. In het bijzonder is het voor icecast en het download platform zo dat deze instanties niet zomaar herstart kunnen worden, omdat daar gedurende langere tijd gebruikers sessies aan kunnen hangen, die afgebroken zouden worden bij een herstart. Om dat te voorkomen hebben we procedures om verkeer om te leiden naar andere instanties en te wachten tot er geen gebruikers sessies meer aan hangen, waarna zo'n instance zonder problemen herstart kan worden.

Het gevolg hiervan was dat op servers waar de publieke diensten al herstart waren de huishoudmanager zich koestgehouden heeft en alleen houdhoudelijke diensten herstart heeft. Maar op servers waar langlopende gebruikers sessies liepen (icecast e.d.) dacht systemd “Aha! Die moet ik hebben!” en heeft deze diensten op minder nette wijze herstart.

Dit verklaart ook waarom we dit in test niet gezien hebben: daar hangen geen langdurige gebruikerssessies aan publieke diensten. Dus die kunnen allemaal eenvoudig herstart worden, voordat de huishoudmanager zijn ding gaat doen.

De oplossing van al dit is gelukkig heel eenvoudig: Bij her herstarten van diensten kan een blocklist meegegeven worden. Die werd al gebruikt voor een aantal huishoudelijke diensten die met rust gelaten moeten worden (bijvoorbeeld omdat ze indirect impact op publieke diensten kunnen hebben). Daar zijn nu expliciet de publieke diensten aan toegevoegd.

Team Hosting&Streaming is gedurende al het onderhoud via de normale kanalen bereikbaar. Zie de contact pagina.