05 jan

[ Onderhoud afgerond ] Fileserveronderhoud voor Webcluster 1

Update: 05.01 01:22 – Onderhoud afgerond. Impact voor klanten uiteindelijk: 2 keer 1 minuut een’glitch’, tijdelijk geen FTP & SSH (Alleen voor gebruikers van webcluster 1). Op dit moment is alles weer op de normale manier actief.


Update: 05.01 01:08 – De primaire fileserver is weer de actieve fileserver. We doen nog een laatste controleslag en dan is dit onderhoud afgerond en zeer geslaagd. Dank aan onze held Wojtek (En natuurlijk ook Vincent & Willem en morele support van Cipri 😉 )


Update: 05.01 00:48 – De primaire fileserver is weer in de lucht. We gaan nog even een controleslag doen en alle webservers ommounten. Het onderhoud is zoals het er nu naar uitziet zonder problemen verlopen.


Update: 05.01 00:37 – Rebooting in progress, update uitgevoerd. We gaan zo na nog een upgrade aan de ‘ZPOOL’ over naar het primaire fileservercluster


Update: 05.01 00:18 –
Upgrade in progress, cluster 1 draait netjes door de backup fileserver. Performance is beter.


Update: 05.01 00:00 –
Het onderhoud is gestart. SSH, FTP tijdelijk even uitgezet. Even een hickup van een minuut gehad zoals gepland (0:08). Sites zijn iets trager op de backup omgeving dan gebruikelijk. Dit zal na cachen snel verbeteren.

 

Update 04.01 17:30 – Vannacht zullen we tijdelijk overschakelen op de backup fileserver, vervolgens voeren we een upgrade uit van de primaire fileserver en switchen we weer terug naar de primaire. Hierbij worden een tweetal netwerk hickups verwacht van ongeveer 1 minuut. Door deze actie uit te voeren verwachten we dat we dat de verminderde bereikbaarheid die we op 3-1-2011 voor 19 minuten zagen niet meer kan voorkomen. FTP en Shell toegang zal tijdens het onderhoud preventief worden uitgeschakeld om te zorgen dat er geen dataverlies optreedt.

 

Update: 04.01 00:10 – onderhoud zonder problemen uitgevoerd. Er was geen downtime voor de websites.

In verband met een eerdere storing aan ons fileserver cluster voor Webcluster1 zullen we de komende 2 nachten onderhoud uitvoeren. Sites waren door deze storing verminderd bereikbaar op 3 januari tussen 0:06 en 0:20. Het geplande onderhoud zal uitgevoerd worden op 4 januari en 5 januari tussen 0:01 en 0:20 uur. Gebruikers zullen hier normaal gesproken geen hinder van ondervinden. Wellicht zal het onderhoud van 5 januari worden afgeblazen als blijkt dat de wijziging een structurele verbetering te weeg brengt.

04 jan

[ Aankondiging Noodonderhoud ] Fileserveronderhoud

Update: 04.01 00:10 – onderhoud zonder problemen uitgevoerd. Er was geen downtime voor de websites.

In verband met een eerdere storing aan ons fileserver cluster voor Webcluster1 zullen we de komende 2 nachten onderhoud uitvoeren. Sites waren door deze storing verminderd bereikbaar op 3 januari tussen 0:06 en 0:20. Het geplande onderhoud zal uitgevoerd worden op 4 januari en 5 januari tussen 0:01 en 0:20 uur. Gebruikers zullen hier normaal gesproken geen hinder van ondervinden. Wellicht zal het onderhoud van 5 januari worden afgeblazen als blijkt dat de wijziging een structurele verbetering te weeg brengt.

03 jan

[ Storing (opgelost) ] Verstoring aan cluster 1

In de nacht van 03 Januari was er een korte storing op cluster 1. Hierdoor waren websites gehost op cluster 1 rond 0:06 tot en met 0:20 niet goed bereikbaar. We zijn er inmiddels achter dat het te maken heeft met een backup. Onze technici hebben het probleem op kunnen lossen door de verschillende filesystems op de webnodes van ‘Cluster 1’ te remounten.

 

We gaan aanpassingen doen en houden deze fileserver de komende dagen extra in de gaten om het probleem structureeel tackelen.

31 dec

[ Storing (opgelost) ] Verstoring aan cluster 1

In de nacht van 30 op 31 December was er een korte storing op cluster 1. Hierdoor waren websites gehost op cluster 1 tussen 01:08 en 01:23 minder goed bereikbaar. Onze technici hebben het probleem op kunnen lossen door de verschillende nodes van het cluster te rebooten.

De oorzaak van de storing is nog niet 100% bekend, maar het lijkt er op dat er een probleem was met de primaire fileserver waarop dit cluster gehost word. We gaan aanpassingen doen en houden deze fileserver de komende dagen extra in de gaten om het probleem structureeel tackelen.

31 dec

[ Storing (opgelost) ] Verstoring aan cluster 1

In de nacht van 30 op 31 December was er een korte storing op cluster 1. Hierdoor waren websites gehost op cluster 1 tussen 01:00 en 01:20 minder goed bereikbaar. Onze technici hebben het probleem op kunnen lossen door de verschillende nodes van het cluster te rebooten.

De oorzaak van de storing is nog niet 100% bekend, maar het lijkt er op dat er een probleem was met de fileserver waarop dit cluster gehost word. We houden deze de komende dagen in de gaten om te zien of we de oorzaak kunnen herleiden.

23 dec

[ Onderhoud (afgerond) ] Reboot DB17, DB18, DB32, DB33 & DB34

In de nacht van 22 op 23 december voeren we kleinschalig onderhoud uit op een aantal database clusters. Voor dit onderhoud gaan we database clusters DB17, DB18, DB32, DB33 & DB34 rebooten.

Zoals in eerder onderzoek naar voren is gekomen zit er in de door Byte gebruikte kernel van Debian een Bug. De bug zorgt ervoor dat een systeem na ongeveer 209 dagen uptime crasht.

Overige databaseclusters hoeven nog niet herstart te worden. Het herstarten van de systemen is een preventieve maatregel maar zorgt er niet voor dat het symptoom (crash na 209 dagen uptime) verdwijnt. We zullen daarom in een later onderhoudswindow een permanente fix hiervoor implementeren. Meer lezen over deze bijzondere bug?

20 dec

[ Onderhoudsaankondiging ] Reboot DB17, DB18, DB32, DB33 & DB34

In de nacht van 22 op 23 December voeren we kleinschalig onderhoud uit op een aantal database clusters. Voor dit onderhoud gaan we database clusters DB17, DB18, DB32, DB33 & DB34 rebooten.

Zoals in eerder onderzoek naar voren is gekomen zit er in de door Byte gebruikte kernel van Debian een Bug. De bug zorgt ervoor dat een systeem na ongeveer 209 dagen uptime crasht.

Overige databaseclusters hoeven nog niet herstart te worden. Het herstarten van de systemen is een preventieve maatregel maar zorgt er niet voor dat het symptoom (crash na 209 dagen uptime) verdwijnt. We zullen daarom in ons volgende onderhoudswindow een permanente fix hiervoor implementeren. Meer lezen over deze bijzondere bug? bug