rssLink RSS for all categories
 
icon_orange
icon_green
icon_green
icon_orange
icon_red
icon_green
icon_green
icon_orange
icon_red
icon_red
icon_green
icon_green
icon_green
icon_blue
icon_orange
icon_red
icon_green
icon_green
icon_orange
icon_red
icon_green
icon_red
icon_green
icon_blue
icon_orange
icon_green
icon_green
icon_green
icon_green
icon_blue
icon_green
icon_green
 

FS#2169 — iscsi5/6

Attached to Project— RPS
Incident
tous les RPS
CLOSED
100%
La communication entre le SAN et les serveurs iSCSI a coupé.
Nous avons rebooté le SAN + les serveurs iSCSI.
Date:  Tuesday, 20 May 2008, 13:52PM
Reason for closing:  Done
Comment by OVH - Thursday, 08 May 2008, 19:42PM

Des erreurs de communication subsistent. Nous venons de rebooter le SAN.


Comment by OVH - Thursday, 08 May 2008, 19:51PM

Nous intervenons physiquement sur le SAN pour vérifier son bon fonctionnement.


Comment by OVH - Thursday, 08 May 2008, 20:34PM

Nous avons changé le shelf qui semble poser problème.


Comment by OVH - Thursday, 08 May 2008, 21:18PM

Le changement du shelf n'a pas résolu le problème.
Nous remettons en place le iscsi sur 196 (iscsi5).
Pour le iscsi de 197 (iscsi6), nous inspectons le shelf ainsi que les disques correspondants.


Comment by OVH - Thursday, 08 May 2008, 23:09PM

Nous avons un grave probleme sur le filesysteme 197. Le systeme est
monté sur un RAID-10 de 12 disques (basés sur 4 raid-1 de 3 disques
chacun). Il se trouve que le filesysteme a enregistré les erreurs
sur 2 raid-1 (soit 6 disques !).

root@filerz3:~# zpool status -x
pool: filer197
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see: http://www.sun.com/msg/ZFS-8000-CS
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
filer197 FAULTED 0 0 4 corrupted data
mirror ONLINE 0 0 0
c1t20d0 ONLINE 0 0 0
c1t21d0 ONLINE 0 0 0
c1t22d0 ONLINE 0 0 0
mirror ONLINE 0 0 2
c1t23d0 ONLINE 0 0 4
c1t24d0 ONLINE 0 0 4
c1t25d0 ONLINE 0 0 4
mirror ONLINE 0 0 2
c1t26d0 ONLINE 0 0 4
c1t27d0 ONLINE 0 0 4
c1t28d0 ONLINE 0 0 4
mirror ONLINE 0 0 0
c1t29d0 ONLINE 0 0 0
c1t30d0 ONLINE 0 0 0
c1t31d0 ONLINE 0 0 0

Nous avons sortis les disques sur un autre filer pour travailer
sur ces disques afin de voir si on peut recuperer les données
ou c'est foutu et on doit travailer à partir du backup (daté
de ce dimanche).


Comment by OVH - Thursday, 08 May 2008, 23:13PM

Après differents essais sur differentes configurations entre
differents disques, le filesystem ne veut pas demarrer. Les
données sont là, les disques n'ont pas d'erreurs, mais l'ensemble
de veut pas monter.

Nous allons travailer à partir de backup du dimanche. Par contre
ceci prendra plusieurs heures pour recopier les données binaires
sous forme de disque. Nous utilisons pour ça les commandes de
ZFS (zsend/zreceive).


Comment by OVH - Thursday, 08 May 2008, 23:25PM

Bonjour,
Nous avons un grave probleme sur l'ensemble des RPS qui sont
installés sur la 197. Il y a 167 RPS touchés par ce probleme.
Le plus ancien RPS touché a été installé il y a 18 jours. Le
plus recent il y a 10 jours.

Le detail:
http://travaux.ovh.com/?do=details&id=2169

Nous avons effectué des maintenances cette nuit, ce matin et
cette apres midi sur le SAN qui gere les RPS 196 et 197.
Fin de l'apres midi, le SAN s'est mis en défaut et nous avons
dû intervenir sur place. Apparament un probleme hardware est
à l'origine du probleme. Nous avons changé les shelfs et nous
avons redemarré le SAN. Le filesystem 196 n'a aucun probleme.
Tout est à nouveau en fonctionnement. Par contre sur la 197,
nous avons un grave probleme: malgré un RAID-1 sur 3 disques
plusieurs disques ont des données corrompu et le filesystem
ne veut pas monter.

root@filerz3:~# zpool status -x
pool: filer197
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see: http://www.sun.com/msg/ZFS-8000-CS
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
filer197 FAULTED 0 0 4 corrupted data
mirror ONLINE 0 0 0
c1t20d0 ONLINE 0 0 0
c1t21d0 ONLINE 0 0 0
c1t22d0 ONLINE 0 0 0
mirror ONLINE 0 0 2
c1t23d0 ONLINE 0 0 4
c1t24d0 ONLINE 0 0 4
c1t25d0 ONLINE 0 0 4
mirror ONLINE 0 0 2
c1t26d0 ONLINE 0 0 4
c1t27d0 ONLINE 0 0 4
c1t28d0 ONLINE 0 0 4
mirror ONLINE 0 0 0
c1t29d0 ONLINE 0 0 0
c1t30d0 ONLINE 0 0 0
c1t31d0 ONLINE 0 0 0

Le checksum sur le 2ème et 3ème RAID-1 n'est pas bon mais
surtout le checksum n'est pas bon sur les 3 disques de 2
RAID-1 !

Nous allons travailer à partir de backup réalisé ce dimanche
mais ceci risque de prendre plusieurs heures voir plusieurs
dizaines d'heures pour reprendre le backup et en faire un
filesystem (actuellement le backup est sous forme d'un fichier
et donc binaires. nous allons le recuperer avec les commandes
ZFS zreceive/zsend).

Amicalement
Octave


Comment by OVH - Friday, 09 May 2008, 00:32AM

La construction de filesystem à partir de backup est très lente.
Ceci va prendre probablement toute la nuit voir plus.

Pour eviter la panne de RPS pour des clients qui ont leurs propres
backups, nous allons reinstaller tous les RPS 187 sur la nouvelle
plateforme l'iSCSI v2. Ceci permettra aux clients de remettre
rapidement les RPS en marche.

Lorsqu'on aura fini avec la recuperation du backup, nous allons
permettre aux clients de recuperer les données à travers l'iSCSI.

La version 2 de l'iSCSI n'aura plus ce probleme là vu que chaque
client a son propre filesystem sur le SAN (au lieu d'un grand
filesystem mutualisé parmis 230 clients).

La nuit sera longe ...


Comment by OVH - Friday, 09 May 2008, 05:13AM

Les reinstallations des RPS terminés. 100% fait. Tous les RPS 197
sont désormais sur la version 2 de l'iSCSI.

La mise en place du backup est toujours en cours. 12% fait.


Comment by OVH - Friday, 09 May 2008, 05:40AM

Nous travaillons sur 3 axes:
- les reinstallations de RPS
- la mise en place du backup
- travail sur le filesystem qui a laché

Le 1er c'est fait.
Le 2ème est en cours mais c'est très long.
Le 3ème, il s'agit de voir si on peut faire qqchose avec les 12
disques du filesystem afin de recuperer les données les plus
recentes possible. Il y a très peu de chance mais c'est possible.
http://www.opensolaris.org/jive/thread.jspa?messageID=220125
Nous installons un filer en opensolaris au lieu de solaris, le
build 78 puis nous allons les disques puis voir si on peut revenir
quelques secondes avant la corruption des données. Si ça marche,
tout ne sera pas recuperables mais ça sera mieux que le backup
de dimanche.


Comment by OVH - Friday, 09 May 2008, 19:54PM

Nous n'avons pas encore de resultats valables. Tout ne se passe
pas comme prevu. C'est extrement long. En attandant, nous continuons
à travailer sur le filesystem afin de le rendre lisible. Il faut
mettre les heures de travail et on ne compte pas lacher l'affaire.
Nous avons plus ou moins compris comme ZFS marche et on modifie les
données sur les labels. On travaile sur 2 axes: monter un filesystem
avec des labels corrompu (et donc court-circuiter les écritures dans
la memoire ou recompiler zfs en enlevant les bons if) et rendre les
labels valides. On se repose un peu puis on reattaque ce soir puis
ce wk biensûr.


Comment by OVH - Tuesday, 13 May 2008, 14:46PM

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


Comment by OVH - Tuesday, 20 May 2008, 13:52PM

Les clients impactés ont été contactés pour récupérer les données de 1 minutes avant le crash et pour la procédure du mois gratuit.