msgbartop
De tout et de rien
msgbarbottom

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.

Reader's Comments

  1.    

    Quelle histoire !! Merci d’avoir partagé ton expérience. Petite question : pourquoi ne pas avoir monter sur ton dédié Apache une BDD MySQL de manière temporaire, quitte à couper certains services pour tenir la charge ?

  2.    

    Il pourrait être utile de mettre en place un serveur MySQL en slave pour avoir toujours un serveur MySQL de disponible, quitte lors de l’utilisation du slave de présenter le site en mode dégradé comme par exemple en désactivant les commentaires.

    Ça permet en plus de faire des backups de la base de données depuis le slave, et donc de ne pas impacter le serveur principal.

  3.    

    @Fabien oui j’y pense 🙂

    @Frédéric Je n’y tout simplement pas pensé 😀 Mais quand j’y réfléchis, je pensais à chaque fois qu’il suffisait d’attendre quelques heures pour que le site soit opérationnel. Je ne pensais pas que cela allait durer aussi longtemps.

  4.    

    C’est quand même dingue de pas savoir d’où ça vient, c’est frustrant.

    Peut être que c’est la distribution linux qui n’est pas la plus adaptée à un serveur (j’y connais pas grand chose en linux)…

    Peut être que des disques SSD seraient plus adaptés pour le serveur MySQL…

    En tout cas, je pensais que koreus avait bien plus de serveur. Par exemple, les vidéos ou les jeux flash sont hébergés sur des sous-domaines variables :

    media1.koreus.com
    media2

    media9 !

    Donc je pensais qu’il y avait 1 ou 2 serveurs web (PHP/MySQL) et quelques serveurs de stockage de fichier à côté.

  5.    

    Donc je pensais qu’il y avait 1 ou 2 serveurs web (PHP/MySQL) et quelques serveurs de stockage de fichier à côté

    C’est le cas 😉

  6.    

    Je me suis ennuyer au taff…HAHAHAHAHAHA

  7.    

    frustrant comme situation.
    je suis chez infomaniak pes de souci de ce genre.

  8.    

    AoSix : « Je me suis ennuyer au taff…HAHAHAHAHAHA »

    + 100000000000

  9.    

    Et ben j’ai mas tout compris, mais chui content de retrouver Koreus ?

  10.    

    La même est pas qu’au taff, idem pour retrouver des vidéos que j’avais en tête sur koreus et que je voulais montrer à mes amis ^^

    Et sinon pourquoi ne pas faire une architecture de serveur avec 2-3 serveurs apache et 1 serveur Mysql avec l’un en slave MySQL, a la limite en prenant des serveurs moins puissant et un IP load balancing qui te permettrait d’avoir une haute disponibilité et le MySQL slave pour prendre le relais en cas de panne du serveur dédié à MySQL.

  11.    

    D’ou l’importance d’une stratégie de DRP (autant sur la solution technique que ton process.. qui comprend l’élément: quand est-ce que je le mets en oeuvre… Ce qui évite le « ca va repartir dans quelques heures »), testée de manière régulière pour pouvoir s’assurer que l’on peut remonter le site assez rapidement, quitte à fonctionner en mode dégradé pendant une certaine période.

    Différentes solutions techniques sont proposées plus haut, après chacune a un coût. Il faut évaluer le coût de la solution vs l’impact de la non-disponibilité.

    @Port de Hyeres: Cela n’a pas de rapport avec ton hébergeur. Cela peut arriver à n’importe qui. Parfois on ne le remarque pas, tout simplement. 😉

  12.    

    Je mettrais un grand coup de virtualisation à base KVM là dedans moi 😉

  13.    

    bonjour moi j’ai un souci.
    j’ai pas de mise a jour sur le site http://www.koreus.com

    c’est a dire que depuis une semaines j’ai toujours les meme vidéos. le dernière que j’ai eu c’est le pigeon avec un clou dans la tete voila.

    et depuis c’est toujours celle-là. ece normal ? moi je pense pas.

    merci de m’aider

  14.    

    Merci pour cette belle histoire, c’est dingue !

  15.    

    Ce qui est fou, c’est que malgré toutes les précautions requises au préalables, on est toujours à la merci d’un bug ! C’est presque une loi physique tellement c’en est vrai.

  16.    

    Content aussi de retrouver koreus

  17.    

    Ouep tout le monde n’a pas autant de chance…

  18.    

    Je suis expert en assurance spécialisé en informatique et j’interviens quotidiennement sur des systèmes RAID dégradés, y compris perte de plusieurs disques simultannément = erase complet des data
    Méfiez vous du RAID !!! Je conseille la virtualisation au maximum, ou si possible hébergement type cloud (amazon and co)