Nous venons de faire une maintenance ce dimanche matin afin de gêner le moins possible. Nous avions programmé la fermeture des Backs Office entre 10 h à 12 h 00 mais cela à pris un peu plus de temps. Ils sont de nouveau accessibles depuis 14 h 00. Durant la maintenance les sites étaient accessibles.
Je vous fais un compte rendu, c'est technique mais pour ceux qui veulent comprendre, je rentre dans les détails.
En quoi consistait cette maintenance :
1) Test de reboot
Cette maintenance consistait à effectuer des tests de reboot sur le serveur de base de données principal, le "Master". Cette machine est un HP 16 Core avec 64 Go de RAM ECC. Elle possède 8 disques SSD Intel de 120 Go et un disque de Boot interne. Nous avons retiré par prévention le disque de boot interne vendredi dernier, car nous craignons qu'il soit un point faible de la machine. On devient Parano ... avec l'architecture de serveur. Résultat 3 reboots réussis, la machine se comporte bien :-)
2) Restauration des Machines Virtuelles sur RAID iSCSI
Depuis mi-octobre nous testions une nouvelle manière de répartir les machines virtuelles. Au lieu de mettre la moitié des Machines Virtuelles sur le serveur de fichier n°1 et l'autre moitié sur le serveur de fichier n°2, ce qui est à l'origine de l'indisponibilité durant 4 heures dans la nuit de samedi 29. Nous avions monté une machine virtuelle en Raid 1 en iSCSI. Ainsi en cas de panne d'un des gros serveurs de fichiers, elle continue à fonctionner avec un seul disque sur le second serveur. C'est validé, ça marche. L'incident du 29 nous l'a prouvé sur les machines concernées. En revanche nous avons profité de cette maintenance pour procéder à la réparation du Raid. Résultat, même si ça évite la panne à chaud, ça ne fait que la reporter.... mauvaise piste :-/
Intervention lundi dans Data Center :
1) Serveur de fichier n°1
Jeudi dernier, nous avons réussi à resynchroniser les disques de notre serveur de fichier n°1. Il était tombé en panne samedi 29. Lundi, Jérôme retirera les derniers disques WD Green qui restent dans la machine et qui sont à l'origine de la panne. Maintenant la machine semble à nouveau bien tourner mais nous n'avons plus totalement confiance. Cette intervention devrait être sans incidence la machine n'étant plus en production.
On a contacté SUN / Oracle afin de changer la carte mère et toutes les cartes contrôleurs de ce serveur de fichiers. Si ce n'est pas possible, on mettra la machine au rencard.
Ce genre de machine coute quand même 30 000 euros pièce.... même si je pense que notre erreur a été d'utiliser des disques basse consommation d'énergie. Il n'est pas normal que lorsqu'un disque sur 48 lâche, l'ensemble de la machine plante, normalement le RAID c'est fait pour cela .....
2) Back up et réseau
Le serveur de video était doublé par un autre serveur dans un second data center. Normalement il nous aurait suffit de changer les points de montage et les vidéos seraient reparties. Mais nous avons rencontré un problème sur le réseaux OVH entre Roubaix et Paris qui nous a limité la bande passante à 100 M/s au lieu 1 Gb/s. Du coup les vidéos étaient servies lentement. Nous n'avons pas eu de réponse du support OVH pendant le weekend de la Toussaint. En fin de compte j'ai contacté le patron d'OVH qui a reconnu le problème et m'a expliqué comment contourner cette limite de 100 Mb/s.
Comme vous l'a expliqué Samir dans les commentaires, nous allons mettre en place un troisième niveau de back up sur le Cloud Amazon. En cas de perte du serveur de fichier Vidéo, le relais sera pris automatiquement sans coupure, puisque le player est devenu intelligent. Cela sera pleinement fonctionnel dans les toutes prochaines semaines.
Pour finir ...
5 Personnes travaillent à plein temps sur l'architecture WMaker avec 2 points quotidiens de reporting. A la fin du mois on publiera un schéma décrivant les modifications apportées à l'architecture. Conscients de la gêne que cela vous a procuré, nous avons élaboré les compensations que nous allons vous proposer dès demain.
