Beste klant/collega,

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

Wij vragen aandacht voor het volgende:

1. Kernel upgrades / reboot ronde hosting servers

Regelmatig sturen wij aankondigingen over stukjes applicatie of middelware software die ge-update wordt, denk aan Apache, PHP, MySQL, enz. Deze applicatiesoftware ligt bovenop een OS laag (die overigens ook regelmatig ge-update wordt, maar omdat dat de applicaties niet raakt melden we dat iha niet) en de OS laag ligt weer bovenop een stuk software dat een “kernel” heet. Deze kernel is de schakel tussen de hardware van een server (CPU, memory, disken, netwerk) en alle diensten die op die server draaien, zoals web-, applicatie- en databaseservers.

Zo'n kernel is ook maar gewoon een stuk software en kan dus net zo goed bugs bevatten. Ook van dit stuk software komen regelmatig nieuwe versies uit. Bij “gewone” software is het zo dat om de nieuwe versie actief te maken, de oude versie gestopt en de nieuwe gestart moet worden. Dat is bijvoorbeeld de reden dat we database updates vaak 's nachts uitvoeren, want tussen het stoppen en het starten zit een klein moment dat zo'n database even niet beschikbaar is.

Hetzelfde geldt in essentie voor een kernel update. De oude kernel moet gestopt worden om een nieuwe te kunnen starten. Echter, in tegenstelling tot “gewone” software is er een reboot van de betrokken server nodig om een nieuwe kernel actief te kunnen maken.

Van tijd tot tijd komt het voor dat er zulke ernstige fouten (met name op security gebied) in de kernel gevonden worden, dat wij genoopt zijn om direct in te grijpen en meteen een aantal reboots in te plannen. Maar het kan ook voorkomen dat er gedurende langere tijd geen ernstige fouten gevonden worden. In die situatie zitten we nu. Er zijn het afgelopen jaar geen zeer ernstige fouten gevonden, maar wel heel veel kleinere fouten. Aangezien al die kleine fouten ook opstapelen voeren wij elke 6 tot 12 maanden een reboot ronde uit op ons gehele serverpark, om zo een hoge stabiliteit op het serverpark te kunnen garanderen.

Verder zijn er bij applicatie software vaak een (klein) aantal major versies die onderhouden worden. Van tijd tot tijd komt er een nieuwe major versie uit en gaat een oudere major versie uit support. Denk aan End-Of-Life momenten van php-7.3, mariadb-10.2 e.d. Datzelfde gebeurt ook met kernels. Er zijn een aantal Long Term Support (LTS) versies, maar op enig moment gaat ook zo'n LTS versie uit support. In die situatie zitten we nu ook met onze kernels. Per 1-1-2023 gaat de LTS kernelversie die we nu gebruiken (4.9.x) uit support en zijn we dus genoodzaakt om te upgraden naar een nieuwere versie. De upgrade naar een nieuwere LTS versie nemen we in deze change meteen mee. De delen van het platform die qua rechtenstructuur gebaat zijn bij wat backward compatibility worden ge-upgrade naar linux kernel versie 4.19. Dit betreft met name het appcluster en het testcluster. De delen waar dit niet voor nodig is (mail, dns) worden ge-upgrade naar versie 5.4

Alle hosting servers van het on-premise platform (o.a. het appcluster, maar ook andere clusters die voor mediastreaming, DNS, mail en nog andere zaken zorgen; collectief noemen we dit “de netboot omgeving”) worden gereboot.

Bijna overal kunnen we door middel van loadbalancing of andere vormen van High Availability ervoor zorgen dat het rebooten van een losse server geen impact op de dienstverlening heeft. Dit, omdat er andere servers klaarstaan om op zo'n moment het relevante stukje dienstverlening over te nemen.

Er zijn echter een paar plekken waar dit om technische redenen niet 100% mogelijk is. Deze benoemen we hieronder:

• upload servers van appcluster (upload-sites.omroep.nl), testcluster (upload-testsites.omroep.nl) en mediacluster (upload.omroep.nl): bestaande logins worden verbroken. Wel kan er meteen opnieuw weer ingelogged worden. Om de overlast hiervan te minimaliseren kiezen we ervoor het onderhoud aan de upload servers buiten kantoortijden uit te voeren.
• alle non-loadbalanced diensten¹⁾ in het testcluster worden 10-30 sec onderbroken terwijl de dienst migreert naar een reeds gereboote server.
• hetzelfde geldt voor non-loadbalanced diensten in het appcluster. Hier kiezen we ervoor om dit samen te nemen met het geplande storage onderhoud, zodat de totale overlast geminimaliseerd wordt.

Omdat er in het gros van de gevallen geen impact op de dienstverlening is of omdat het (in het geval van het testcluster) geen productie betreft worden alle andere reboots gedurende kantoortijden uitgevoerd.

De planning van de reboots is als volgt:

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