Indisponibilité majeure…
Vous avez pu vous en rendre compte, nous avons eu deux longues soirées d’indisponibilité sur la plateforme (dimanche 6 et lundi 7 décembre).
Avant les explications sur ce qui c’est passé, un petit rappel concernant la plateforme.
En dehors des serveurs de backup (hébergés à Montpellier), toute la plateforme est hébergée dans un rack unique (donc dans une salle unique dans un datacentre unique), dans le centre de Paris (derrière le Grand Rex).
Cette plateforme c’est un châssis (Dell M1000E) avec des lames (Dell M610) et des systèmes de stockage (Equallogic PS6100E et PS6100XS) avec le réseau pour que tout ça communique.
Le châssis intègre sa propre redondance physique : seize emplacements pour des lames, deux cartes de gestion, deux systèmes de réseau (chaque lame ayant six cartes réseaux), neuf ventilateurs et six alimentations.
Il peut fonctionner avec seulement trois alimentations, une seule carte de gestion et six ventilateurs (tout ça étant bien sûr « hot plug »).
Le système de stockage, c’est la même chose : chaque baie de stockage a une double alimentation et un double contrôleur et peut fonctionner avec seulement une alimentation et/ou un seul contrôleur. Chaque baie est configurée en RAID6, avec deux disques de spare.
C’est la même chose pour le réseau. Le réseau de gestion est double (deux switches gigabits intégrés au châssis) double connecté entre eux et à deux cartes réseaux sur chaque lame, le réseau de stockage utilise deux switches gigabit externes (eux aussi double connectés entre eux et à deux cartes par lames) et, bien entendu, c’est la même chose pour le réseau « logique » (deux switches 10 Gbps dans le châssis et deux cartes 10 Gbps dans chaque lame), le tout doublement connecté.
Sur le plan applicatif, la redondance est gérée grâce aux lames en surnombre (l’ensemble des VM hébergées pourrait tourner sur seulement trois lames), avec bascule automatique en cas de soucis sur une lame.
Bref, tout est prévu. En théorie.
Parce que, pour la pratique, on s’appuie sur l’extérieur, en l’occurrence le datacentre. Datacentre qui est en théorie entièrement redondé lui aussi : double alimentation électrique, double système d’onduleurs, double climatisation et le tout séparé pour chaque salle.
Mais il y a les maintenances. Obligatoires. Qui obligent à stopper, dans le cas qui nous intéresse, une des armoires de climatisation de la salle qui perd donc la redondance « froid ».
Et ce qui avait peu de chance d’arriver est néanmoins arrivé : dimanche l’armoire de climatisation qui fonctionnait (la seule) s’est arrêtée, de 16h20 à 17h30 environ (ré-enclenchement manuel par l’équipe d’astreinte).
La température est bien entendu montée très vite et très haut : mesurée au niveau de cartes mères, on passe de 45 à 90° en une trentaine de minutes. Résultat, une des baies de stockage et le châssis se sont mis en sécurité (température trop haute) et se sont éteints. Tout simplement.
Une fois la climatisation ré-enclenchée, la température redescend (moins vite qu’elle ne monte), le châssis a redémarré seul mais pas la baie de stockage.
Il a donc fallu une intervention « Remote Hands » pour la démarrer et commencer à relancer les machines virtuelles. Et se rendre compte que certaines étaient, même démarrées, inaccessibles.
Un des switches 10 Gbps du châssis apparaissait « en alerte », tout comme deux des alimentations du châssis.
Après une nouvelle intervention « Remote Hands » qui a confirmé que le switch semblait HS, y compris après un reseat, nous avons modifié la topologie réseau et la configuration globale du châssis pour forcer l’utilisation du second switch.
Les services ont donc été rétablis aux alentours de minuit (certaines VM ont nécessité des fsck, d’autres ont du être redémarrées et certains services spécifiques également). Quelques services n’ont été accessibles que lundi matin.
Lundi vers 18h nous sommes intervenu physiquement sur la plateforme afin de vérifier le switch qui semblait HS et effectuer un re-seat des alimentations elles-même en « warning ».
Là encore, il s’est passé ce qui ne devrait pas se passer : alors que le châssis est capable de fonctionner avec seulement trois alimentations, en débranchant un des alimentations en « warning » et en la rebranchant, il s’est éteint.
Il a donc fallu tout redémarrer une fois de plus…
Les VM ont bien redémarré mais certaines fonctionnaient très mal (ça ramait, beaucoup) alors que d’autres fonctionnaient normalement.
Après investigation, il est apparu que deux lames fonctionnaient normalement alors que les quatre autres « ramaient ».
Une des lames a été libérée de ses VM et rebootée, même chose (un reboot de lame, c’est 20 minutes environ).
Nous avons alors tenté le re-seat (physique) de lame et après son boot (encore 20 minutes), les VM déplacées sur cette lame fonctionnaient correctement.
Le re-seat des trois lames restantes a ensuite été effectué (une par une pour éviter un nouveau soucis), les VM vérifiées et les services étaient de retour à 23h.
Là encore quelques services ont nécessité une nouvelle intervention mardi matin.
La topologie réseau a été corrigée et des switches « spare » ont été commandés.
Et normalement, tout devrait fonctionner sans soucis pendant quelques années.
Jusqu’à la prochaine coupure électrique (vécu à Redbus Interhouse et Overlap) ou de climatisation, que vous pourrez suivre en live via notre compte Twitter : https://twitter.com/NetworkStudioFR.
Pour la petite histoire, la maintenance de climatisation devait être terminée vendredi dernier…
Elle a finalement été terminée mardi.
La mise en place d’une plateforme mirrorée (avec un autre datacentre) est tout à fait envisageable mais pose clairement un problème de coût (nous n’avons pas la masse critique pour que cela se fasse sans une augmentation importante des tarifs).