18 Juil 10 Koreus.com était en maintenance pendant presque 4 jours

Semaine noire pour Koreus.com, presque 4 jours d’indisponibilité. Comment cela est-ce possible ?

Depuis quelques temps, je remarque que le serveur où se trouve MySQL se comporte bizarrement. La charge CPU est élevéee sans raison apparente, ce qui provoque régulièrement  des erreurs lorsqu’on essaie d’accéder au site.

Dimanche 4 juillet, le serveur semble planté, impossible de se connecter en ssh, seul le ping marche. Je décide de faire un reboot hard pour relancer la machine. Je ne m’inquiète pas plus que cela

Dimanche 11 juillet, une semaine plus tard, rebelotte, le serveur est encore planté ! Même symptôme que la dernière fois. Je refais un reboot hard. Je regarde encore une fois dans les logs si je trouve quelque chose d’anormal mais rien. Je ne m’inquiète pas plus que cela.

Mardi 13  juillet  vers 9h, le serveur redémarre tout seul ! Je décide de monitorer la machine toute la journée. Je constate que le Load Average est vraiment important. Je regarde les graphs MRTG depuis le début de l’année et dès juin, il y a eu un pic au niveau de la charge CPU. Je ne trouve pas d’explications, je n’ai rien installé sur la machine depuis longtemps. Je décide de faire quelques optimisations dans le fichier de configuration de MySQL. Mais rien y fait. Le Load Average est anormalement élevé.

Mercredi 14 juillet vers 10h, encore un plantage de la machine ! Après un reboot hard, je découvre dans les logs des messages d’erreur.
kernel: sd 4:1:3:0: [sda] Unhandled sense code
kernel: sd 4:1:3:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:1:3:0: [sda] Sense Key : Hardware Error [current]
kernel: Info fld=0xe1d0125
kernel: sd 4:1:3:0: [sda] Add. Sense: No defect spare location available
kernel: sd 4:1:3:0: [sda] CDB: Read(10): 28 00 0e 1d 01 1d 00 00 80 00
kernel: end_request: I/O error, dev sda, sector 236781861

Je regarde sur Google si je vois des infos intéressantes sur ces erreurs mais rien de précis. Je décide de rebooter en mode rescue (un genre de mode sans échec) et je constate que le RAID est dégradé.

State of RAID 1 : DEGRADED

root@rescue:~# mpt-status -i 10
ioc0 vol_id 10 type IM, 2 phy, 931 GB, state DEGRADED, flags ENABLED
ioc0 phy 1 scsi_id 11 SEAGATE ST31000640SS 0001, 931 GB, state ONLINE, flags NONE
ioc0 phy 0 scsi_id 255 , 931 GB, state MISSING, flags OUT_OF_SYNC


10h30, j’ouvre un ticket chez OVH pour remplacer le disque.
10h47, le support me répond pour me dire qu’il vont faire un diagnostic hardware dans 15 mn.
11h48, le disque dur est changé et l’intervention terminée.

Je décide de relancer la machine en mode normal. Les disques RAID ne sont pas synchronisés, les performances de la machine seront dégradées mais au moins le site sera alive. Dès que c’est fait, je me jète sur les logs et oh désespoir, j’ai les mêmes erreurs. Je me dis, c’est normal, les disques se synchronisent, ça doit venir de là. De plus, la machine est horriblement lente, je mets tout ça sur le dos de la synchronisation. Je décide de redémarrer la machine en mode rescue. Le site est de toute façon inutilisable dans l’état actuel, je préfère le mode rescue pour accélérer la synchronisation du raid.

24 plus tard, jeudi 15 juillet, les disques sont enfin synchronisés. Le raid-1 est optimal. Mais j’ai toujours les erreurs de « kernel: sd 4:1:3:0: [sda] Sense Key : Hardware Error [current] ».
9h38, je recontacte le support.
12h17, réponse du support, une intervention est prévue sur la machine pour changer la carte RAID.
12h34, la carte est changée mais j’ai toujours des erreurs de kernel « I/O error ».  Le technicien va remplacer l’autre disque dur.
13h25, le disque dur a été remplacé mais j’ai encore les erreurs !
14h50, le technicien pense que l’erreur vient du premier disque qui a été remplacé mais comme le RAID n’est pas synchronisé, il ne peut pas faire le remplacement, sinon je perds toutes les données. Il me conseille d’attendre la fin de la synchronisation. J’approuve. Il me conseille également de faire un backup des données.

Vendredi 16 juillet à 20h49, la synchro est enfin terminée ! Je contacte le support pour les prévenir.

Samedi 17 juillet à 10h14, réponse du support. Le tech va intervenir pour remplacer le disque.
10h32, le disque est remplacé mais devinez quoi ? J’ai toujours les erreurs !
11h06, le tech décide de remplacer la carte mère.
12h50,message du support pour me dire que la carte mère est remplacé mais qu’il y a toujours les erreurs . On m’invite à faire une vérification du système de fichier en mode rescue. Ce que je fais, rien d’anormal et pourtant j’ai toujours les erreurs de kernel « I/O error » dans les logs.
14h36, ultime solution proposée par le tech. Changer les deux disques et réinstaller le serveur.
15:37, j’ai des backups, j’approuve.
17h58, la distribution linux a été installée sur le serveur.  Il ne me reste plus qu’à réinstaller les services et restaurer les backups. Cela prend beaucoup moins de temps que prévu.
vers 20h, le site remarche enfin ! Il me reste encore quelques trucs à peaufiner mais le plus dur est fait. Ouf !

En tout cas, 4 jours de down, c’est long, très long. C’est pourquoi, j’avais créé une page statique qui expliquait ce qui se passait. J’ai aussi énormément utilisé Twitter pour communiquer. Je ne voulais pas laisser mes visiteurs dans le flou. Les gens sont patients à condition qu’on leur explique la situation.

Et l’erreur, elle venait d’où ? Et bien figurez vous que je ne sais pas. Mais maintenant je ne l’ai plus et la machine ne souffre plus d’un Load Average élevé.
Est-ce qu’ OVH, mon hébergeur a fait son boulot ? Oui et merci au support pour sa disponibilité et sa réactivité (sauf peut être vendredi soir 😉 ).

Pour info : J’ai deux serveurs, l’un pour la base de données (MySQL) et l’autre pour le Web (Apache). Le premier était en maintenance, le second se portait comme un charme et s’occupait de vous afficher la page de maintenance.