Retour sur le problème de l’architecture mutualisée du 1er Juillet

Ce matin, nous avons rencontré l’un des plus gros problèmes qu’il est possible de rencontrer pour l’architecture mutualisée. Comme vous le savez, nous avons investi pour améliorer l’espace de stockage du cluster d’hébergement mutualisé car les volumes actuels n’arriveront bientôt plus à suivre l’évolution de nos services. Dans ce sens nous avons commandé une machine 100% SSD en RAID 5 qui prendra la relève de la machine actuelle en RAID 5 également.

Ce matin la machine actuelle de stockage du cluster mutualisé à crashée. Une sortie d’écran bleu pour Linux si vous préférez. Le système n’ayant pas redémarré depuis plus de 1 an et demi, il effectue une vérification d’intégrité du disque dur avant de terminer le boot. C’est cette vérification qui a pris beaucoup de  temps. De plus, lorsque le système fait ce type de vérification il est possible, voir souvent probable, qu’il trouve une erreur sur le disque et demande à effectuer une réparation de celui-ci. Réparation qui prend généralement énormément de temps également.

Nous avions prévu ce problème et nous avons donc immédiatement agit une fois que nous nous sommes rendu compte que l’espace de stockage prendra trop de temps à revenir. Nous avons donc monté sur notre architecture mutualisée notre espace de stockage secondaire, un clone du premier. Le montage a pris plus de temps que nous l’imaginions mais nous y sommes finalement arrivés et l’ensemble des sites ont pu de nouveau fonctionner sans perte de données.

Nous fonctionnons donc actuellement sur l’espace de stockage secondaire, légèrement moins performant que le premier mais tout à fait capable de recevoir la charge des visiteurs de l’architecture mutualisée. Nous avons décidé de ne pas repasser sur l’espace de stockage principal car nous allons bientôt passer l’ensemble sur notre nouvel espace 100% SSD. Nous avons bien sûr activé un clone de l’espace de stockage en production pour parer à tout nouveau problème.

Ce soucis ce matin nous a appris plusieurs choses :
– Nous avons pris trop de temps pour remonter l’espace de stockage. Nous allons donc mettre en place de nouvelles procédures pour améliorer ce délai.
– L’architecture de stockage en SSD va être la bienvenue et surtout elle va ouvrir les portes à une réplication instantanée de l’espace. Grâce à la technologie ZFS nous allons être en mesure d’être plus réactif et donc plus efficace lorsque nous rencontrerons un problème similaire.

Le passage sur l’architecture SSD va commencé mi-juillet plutôt que début juillet. Nous préférons prendre notre temps pour maîtriser parfaitement la nouvelle technologie et pour mettre en place des procédures de récupération plus efficaces. Le transfert se fera de façon transparente pour nos clients.

Merci pour votre patience durant le soucis sur l’architecture mutualisée de ce matin. Nous apprenons de nos erreurs et nous ferons mieux la prochaine fois, car en informatique il y a toujours une prochaine fois!

Bonne journée à tous

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *