Aujourd’hui vers 18h server10 a eu une panne. Après vérification il s’agissait d’un kernel panic (crash du noyau du serveur). Un redémarrage a été fait (et a pris un certain temps à cause de la vérification de tous les volumes à la recherche de dommages disque).

À 18:25 les VPS ont été relancés.

Nous sommes désolés pour cet incident.

Ce matin apparemment server8 a cessé de répondre au ping. Il a été relancé une demi heure après et tous les VPS sont redevenus accessibles vers 8h du matin.

Nous allons chercher la cause du problème (kernel panic ?)

Aujourd’hui server11 a du être rebooté à cause d’un bug dans l’hyperviseur qui faisait que la latence disque était incroyablement longue (ce qui rendait les serveurs particulièrement lents).

Une maintenance avait été planifié, mais l’hyperviseur s’étant mis a dysfonctionner de plus en plus nous avons du redémarrer le serveur qui était devenu pratiquement indisponible depuis plusieurs minutes.

Les VPS sont en cours de redémarrage au moment de la rédaction de ce billet. Je suis désolé pour la gêne causée.

En debut d’après midi, server9 a eu une panne. Plus tard dans la journée il a été constaté qu’il s’agissait d’un disque defectueux. 

Le disque defectueux a été changé en debut de soirée. Aucune donnée n’a été perdue, mais le RAID doit se réparer avant un redémarrage des machines.

Edit : La resynchronisation du RAID est en cours, les VPS seront relancés une fois celle ci (pratiquement) terminée. Nous estimons la fin de la synchronisation RAID dans 4 heures à l’heure de redaction de ce billet, ce qui fait donc environ un rétablissement complet vers minuit ce soir.

Nous sommes désolés de la gêne causée et nous vous conseillons de consulter régulièrement ce billet pour avoir plus d’informations sur l’avancement de la réparation disque.

Un problème de routage s’est déclaré chez notre hébergeur (OVH) vers minuit. Nous (enfin eux) ne connaissons pas pour l’instant la ou les causes du problème.

Plus d’informations seront fournies d’ici peu. Pour un suivi en temps réel de la situation regardez le ticket d’intervention chez notre fournisseur OVH ou ce même billet sur tumblr. 

Edit 1:00: Il s’agissait d’une erreur de routage cette dernière a été fixée.

Etant donné les recents problèmes avec les nouveaux serveurs Tonbnc, je pense que relancer ce blog serait quelque chose d’intéressant voire d’utile.

Donc voilà, à partir de maintenant tous les downtime/maintenances/problèmes seront signalés ici en priorité, histoire d’avoir vraiment un suivi en continu des problèmes éventuels du service Tonbnc VPS.

Ce jour le dimanche 29 mai 2011, un comportement plus qu’étrange de l’hyperviseur Xen à nécessité un redémarrage du serveur principal de 6:45 à 7:15. Normalement les machines qui étaient déja démarrées avant la maintenance n’ont pas du être coupées. 

Malgré cela, certains programmes ou VPS supportent assez mal l’effet de “saut dans le temps” crée par la mise en pause des machines le temps de la maintenance. Si c’est votre cas (la machine devient très lente, inaccessible en SSH ou ne ping plus), songez à la redémarrer via le panel, voire la redémarrer complètement, cela devrait fixer le problème.

Aujourd’hui le 22 mai 2011, le serveur Server6 a eu un incident, il a été relancé à cause d’un problème électrique.

A 15:50 le serveur est revenu et il est actuellement opérationnel.

Server8 semble être down depuis 16:25 aujourd’hui. Un reboot software (qui devrait conserver intact les VPS a été tenté à 17:10. Actuellement on attend ce qui se passe ensuite.

Un reboot hardware sera fait si le serveur ne revient pas avant 17:20. La par contre l’état et l’uptime de vos VM sera remis a zéro mais aucune donnée (du moins non sauvegardée) ne sera perdue. 

Plus de détails dans quelques minutes.

Edit: 17:21 -> Un hard reboot vient d’être demandé. Normalement le serveur et les VPS devraient être relancés d’ici quelques minutes.

Edit: 17:25 -> Il ne reboote toujours pas. Nous allons tenter de le lancer dans un mode de rescue en réseau histoire de voir si le problème est logiciel ou materiel.

Edit: 17:36 -> Le serveur ne démarre pas en mode rescue. Probablement un problème d’alimentation, de réseau ou peut être quelque chose de materiel. Nous avons demander au support Hetzner Online de procéder a des verifications d’usage.

Edit: 19:10 -> Après une maintenance faite de la part d’Hetzner, la machine semble rebooter. Les machines sont relancées une par une. Le service est rétabli. Pour information le downtime aura duré 2h45.

Nous sommes réellement désolés, un mail sera envoyé d’ici quelques heures expliquant les causes détaillées de cet incident.

Maintenant qu’on sait d’où vient le problème de server4 (pour les mecs qui écoutent pas c’est en fait un disque du raid qui faisait des trucs funky qui généraient donc des incoherences tout cela faisait rebooter le serveur), il serait assez bien de le régler une bonne fois pour toute.

Et comme chaque jour sans RAID 1, c’est un jour dans la crainte que le second disque fasse comme son petit copain la, il serait bien de changer le défecteueux au plus vite.

C’est pourquoi, demain vers 6h30/7h, et ce jusqu’a 9h au plus tard, une maintenance d’urgence aura lieu et consistera à changer le disque /dev/sda qui est tout pété. A titre indicatif, Hetzner (l’hébergeur) nous a dit qu’il faudrait environ 30 minutes pour le changer. Ensuite, je pense qu’il en faudra peut être autant pour couper le serveur et relancer les machines virtuelles.

La bonne nouvelle c’est que techniquement, vos VM ne rebooteront pas, elles seront freezées a leur état à 6h30, et se réveilleront comme des fleurs vers 9h. Tout ça grace à la magie de Xen.

Donc allez on récapitule :

» Maintenance Dimanche 23 Mai 2010, de 6h30 à 9h00.
»»> Serveur concerné : server4.tonbnc.fr // Allemagne
»»> But : Changement de disque défectueux
»»> Vos VM ne seront pas rebootées. 

EDIT 23 Mai 2010 08:25 // Le changement de disque est terminé, la resync vient de commencer.