Bien que nous ayons un sytème de monitoring de serveurs, celui ci n'en faisait pas partie. De ce fait nous n'avons été conscient du problème que le Dimanche en milieu d'après midi.
Un mail de l'hébergeur (OVH) de ce serveur nous informais qu'ils étaient intervenus sur la machine afin de changer l'alimentation et qu'ils avaient consaté que les disques Raid étaient brulants.
Après un reboot à distance du serveur de notre part, il n'est pas revenu. Nous avons donc contacté OVH dès le dimanche soir pour qu'il fasse un diagnostic, qu'ils nous éditent un bon de commande en conséquence et qu'ils fassent les réparations nécessaires.
Après plusieurs relances le Lundi matin, le diagnotisc était établi, le problème venant des disques. Nous demandons alors qu'on nous mette un des 2 disques en place afin de récupérer les données et si cela n'est pas possible de nous restaurer le backup.
Le Lundi soir, le serveur est de nouveau disponible mais vide, aucun des 2 disques n'est récupérable, il faut donc restaurer le backup. Mais pour le récupérer il nous faut un code d'accès qu'OVH a oublié de nous fournir.
Le Mardi matin nous appelons la HotLine toutes les heures pour avoir ce mot de passe, c'est vraiment idiot d'avoir un serveur actif sans pouvoir le réinstaller. Finalement à 14 heures, le service commercial intervient et le support technique nous communique cette information, 1 heure plus tard (15 heures) les premiers sites redémarrent. Nous commencons par réinstaller les noms de domaines, puis les mails et pour finir les sites.
Un mail de l'hébergeur (OVH) de ce serveur nous informais qu'ils étaient intervenus sur la machine afin de changer l'alimentation et qu'ils avaient consaté que les disques Raid étaient brulants.
Après un reboot à distance du serveur de notre part, il n'est pas revenu. Nous avons donc contacté OVH dès le dimanche soir pour qu'il fasse un diagnostic, qu'ils nous éditent un bon de commande en conséquence et qu'ils fassent les réparations nécessaires.
Après plusieurs relances le Lundi matin, le diagnotisc était établi, le problème venant des disques. Nous demandons alors qu'on nous mette un des 2 disques en place afin de récupérer les données et si cela n'est pas possible de nous restaurer le backup.
Le Lundi soir, le serveur est de nouveau disponible mais vide, aucun des 2 disques n'est récupérable, il faut donc restaurer le backup. Mais pour le récupérer il nous faut un code d'accès qu'OVH a oublié de nous fournir.
Le Mardi matin nous appelons la HotLine toutes les heures pour avoir ce mot de passe, c'est vraiment idiot d'avoir un serveur actif sans pouvoir le réinstaller. Finalement à 14 heures, le service commercial intervient et le support technique nous communique cette information, 1 heure plus tard (15 heures) les premiers sites redémarrent. Nous commencons par réinstaller les noms de domaines, puis les mails et pour finir les sites.
Aucun mail n'a été perdu
Aucun mail n'a été perdu, en effet lorsqu'un serveur s'arrete, les mails qui lui sont expédiés reviennent au serveur expéditeur, généralement celui ci renouvelle la tentative pendant 7 jours avant de jeter l'éponge.
Certains sites en V3 ont été affectés :
Quelques sites (issus de la V2) n'ayant jamais fait de changements de DNS, étaient actifs, mais pas par leur domaine, nous avons profité de ces 2 jours d'interruption pour les configurer correctement mais cela doit nous apprendre qu'il faut renseigner correctement ses DNS.
Nous avons donc décidé de lancer prochainement une grande campagne de mise à jour des DNS auprès de tout le monde pour que vous n'ayez jamais de problème. Ce point est détaillé dans le paragraphe ci dessous
Nous avons donc décidé de lancer prochainement une grande campagne de mise à jour des DNS auprès de tout le monde pour que vous n'ayez jamais de problème. Ce point est détaillé dans le paragraphe ci dessous
Pourquoi cela ne peut plus arriver en V3
Contrairement à la V2 qui tourne sur un seul et même serveur, la V3 s'appuie sur 5 serveurs différents pour fonctionner.
1. Un serveur fait tourner l'application
2. Un autre fait fonctionner la base de données
3. Un pour les backups et la réplication de la base de données
4. Un pour les stats
5. Un pour les mails
Ces serveurs sont backupés entre eux, ce qui évite ce genre de panne, s'il l'un d'entre eux tombe en panne un autre prend le relai en quelques minutes. Il n'y a plus de besoin de récupérer de backup, puisque tout est en double, il suffit alors d'indiquer que c'est un autre serveur qui prend le relais.
1. Un serveur fait tourner l'application
2. Un autre fait fonctionner la base de données
3. Un pour les backups et la réplication de la base de données
4. Un pour les stats
5. Un pour les mails
Ces serveurs sont backupés entre eux, ce qui évite ce genre de panne, s'il l'un d'entre eux tombe en panne un autre prend le relai en quelques minutes. Il n'y a plus de besoin de récupérer de backup, puisque tout est en double, il suffit alors d'indiquer que c'est un autre serveur qui prend le relais.