Bonjour,
Dans la soirée de jeudi, un filer ZFS, qui gère les RPS 196/197, a planté
plusieurs fois. Le détail se trouve sur https://travaux.ovh.com/?do=details&id=2169
Nous avons repéré des erreurs de communication sur le bus SCSI entre la
tête et les shelfs de disques. Nous avons décidé de changer les shelfs.
Après le changement de shelfs et le reboot du filer, le filesystem de RPS 196
a redémarré sans problème. Par contre celui de RPS 197 ne voulait plus rien
entendre. Les données ont été corrompues malgré le fait qu'il s'agit d'un
RAID-1 sur 3 disques !

Le backup quant à lui est toujours en récupération. Les 4x3.2To de
données sont toujours en train d'être restaurées.

Après plusieurs jours et nuit de travail continue, nous avons réussi
à récupérer les données de certains RPS 197 dont les clients ont
ouvert un ticket d'incident. Il s'agit des données à quelques secondes
avant le crash du filer ...

Si vous avez besoins récupérer les données en urgence, merci d'ouvrir
le "ticket d'incident" dans le manager (pas un conseil sur le support).
Nous allons en priorité mettre en place les copies de fichier pour vous.

Une fois que les urgences de certains clients seront finies, nous allons
mettre en place les données de tous les 197. Probablement demain.

Comment nous avons fait ?
-------------------------
Le filer de données fonctionne sous Solaris avec ZFS. Le fonctionnement
de ZFS est "copy-on-write", c'est à dire que les données ne sont jamais
écrasées. Le ZFS écrit les nouvelles données et change le pointage dans la
metabase pour dire "les données se trouvent maintenant ici, et pas la bas".
Les données qui ne sont plus utilisées ne sont jamais effacées.

On dit qu'on ne peut pas perdre les données avec ZFS. C'est totalement
secure. On ne peut pas corrompre les données et donc ZFS fonctionne toujours.
Et quand ça arrive (!?) les réponses sont "C'est pas possible. Sinon
reprends ton backup, connard".

Nous avons démarré les travaux dans la nuit de jeudi sur 3 axes:
- nous avons réinstallé tous les RPS 197 sur un nouveau filer en v2
les clients qui avaient un backup ont pu redémarrer de suite.
- récupération de données du backup de dimanche (J-4)
- récupération de données à partir du filesystem dit corrompu

Le backup est une image binaire de filesystem de taille 4x3.2Go. Il est
stocké sur un autre filer, pas à Roubaix mais à Paris (pour plus de sécurité).
Nous avons lancé les récupérations de ces images, mais à la vitesse d'environ
1To/1.2To par jour, nous avons pour plusieurs jours pour récupérer
les données. Nous avons eu plusieurs timeout sur la connexion ssh
qui récupérait les données et nous avons dû recommencer l'opération à
nouveau. Depuis vendredi, ça avance mais c'est long à cause de la distance
entre Paris et Roubaix (même avec des MTU du réseau à 10K).

En parallèle nous avons commencé une course pour récupérer les données
du filer lui-même avant le backup. A ce jour, nous avons repéré qu'un
post d'un admin qui avait réussit à récupérer les données à partir d'un
filesystem ZFS cassé mais sans vraiment de informations sur la méthode.
Mais le fait que quelqu'un avait réussi récupérer voulait dire que c'était
possible. Alors si c'était possible, on pouvait le faire aussi.

Nous avons travaillé depuis jeudi nuit jusqu'à ce matin en quasi non stop.
Il fallait juste donner du temps au temps pour trouver la méthode et avancer
dans le débuggage. Hier dans l'après midi, le filesystem a monté (yeah !) et
il nous a fallu encore une nuit pour commencer à récupérer les données des
clients.

Pour monter le filesystem, nous avons travaillé sur 2 axes à nouveaux:
- travailler en live sur les octets des disques pour corriger les informations
des labels qui disent où se trouvent les données puis remonter dans le temps
jusqu'à trouver les données correct (avec les uberblock)
- travailler sur le code source pour le réécrire afin de monter un
filesystem pas bon (avec les checksum erronés, avec des if qu'il faut sauter
etc) monte quand même.

Les travaux sur les disques nous ont obligés de comprendre exactement le ZFS.
Il a fallu lire les peu de docs existantes puis parler et parler entre nous
afin se mettre d'accord sur ce que chacun a compris. Puis une fois revenu
devant les écrans, nous avons retrouvé sur les disques les informations aux
endroits qu'il fallait. Nous avons corrigé ces informations afin que l'ensemble
ressemble à un filesystem. En suite, nous avons remonté dans le temps pour
trouver la 1ere metabase qui avait le filesystem avec les données valides. On l'a
trouvé à environ 1 minute avant le crash. Le filesystem était devenu montable.

En parallèle, Nous avons travaillé sur le code source afin d'enlever tout ce qui
empêche au ZFS de monter le filesystem. Au lieu de réécrire le code source et
le compiler, nous avons fouillé dans la RAM directement. Nous avons repéré les
endroits où il y avait le code du kernel compilé, les fonctions qui nous interessaient
puis nous l'avons patché (en assembleur) pour monter le filesystem. Nous avons
utilisé les traceurs de mémoire tout en exécutant la commande qui monte le filesystem.
6 patchs ont été appliqués puis hier soir le filesystem a monté. Il a fallu encore
verifié les données et remonter dans le temps.

Nous allons décrire la méthode complète sur notre (futur) blog. Ceci va
certainement intéresser les admins qui ont des données corrompu avec ZFS.
Sur le net, on trouve souvent ce genre de posts sans aucune reponse ni de solution.

L'ensemble parait complexe. Honnêtement c'est un peu le cas. Il nous a fallu 5 jours
pour rendre les données des disques lisibles à coup des éditeurs hexadécimaux
et des copies bloc à bloc à partir des disques et vers les disques puis pour
tracer l'exécution des commandes dans la mémoire et trouver les endroits
à corriger. Une belle expérience et un excellent travail d'équipe des admins
de chez Ovh.

Normalement tous les clients qui avaient besoins de données vont les récupérer
aujourd'hui (à ce jour nous avons 12 clients dans notre support d'incident).
Les clients RPS 197 vont avoir 1 mois gratuit à cause de cet incident. Sous 2-3
jours, nous allons fournir un URL avec le document à nous renvoyer.

Nous sommes désolés pour cette panne et le délai de récupération de données.

Avec la version 2 du RPS (qui est en place depuis 10 jours) nous n'aurons plus
ce genre de problème dans la mesure où le backup est personnel (chaque RPS a
son propre backup au lieu d'un grand backup de 220 RPS). De l'autre côté, nous
avons maintenant une meilleure connaissance de Solaris et Opensolaris au
niveau de ZFS et le SCSI ainsi que l'iSCSI. Ceci dit, après une bonne nuit,
voir 2, nous allons voir exactement ce qu'il s'est passé et comment faire de
sort que ce genre de choses n'arrive plus. Nous exploitons Solaris depuis 1an
environ et c'est le premier crash que nous avons enregistré. Sun n'est pas
non plus une entreprise debutante dans le stockage. Ce genre d'incident ne
peut plus se reproduire.

Amicalement
Octave