Remplacement ou réparation d'un périphérique endommagé

Cette section explique comment déterminer les types de panne de périphériques, effacer les erreurs transitoires et remplacer un périphérique.

Détermination du type de panne de périphérique

L'expression périphérique endommagé peut décrire un grand nombre de situations :

Bit rot : sur la durée, des événements aléatoires, tels que les influences magnétiques et les rayons cosmiques, peuvent entraîner une inversion des bits stockés dans le disque. Ces événements sont relativement rares mais, cependant, assez courants pour entraîner des corruptions de données potentielles dans des systèmes de grande taille ou de longue durée.
Lectures ou écritures mal dirigées : les bogues de microprogrammes ou les pannes de matériel peuvent entraîner un référencement incorrect de l'emplacement du disque par des lectures ou écritures de blocs entiers. Ces erreurs sont généralement transitoires, mais un grand nombre d'entre elles peut indiquer un disque défectueux.
Erreur d'administrateur : les administrateurs peuvent écraser par erreur des parties du disque avec des données erronées (la copie de /dev/zero sur des parties du disque, par exemple) qui entraînent la corruption permanente du disque. Ces erreurs sont toujours transitoires.
Interruption temporaire de service : un disque peut être temporairement indisponible, entraînant l'échec des E/S. En général, cette situation est associée aux périphériques connectés au réseau, mais les disques locaux peuvent également connaître des interruptions temporaires de service. Ces erreurs peuvent être transitoires ou non.
Matériel défectueux ou peu fiable : cette situation englobe tous les problèmes liés à un matériel défectueux, y compris les erreurs d'E/S cohérentes, les transports défectueux entraînant des corruptions aléatoires ou des pannes. Ces erreurs sont typiquement permanentes.
Périphérique mis hors ligne : si un périphérique est hors ligne, il est considéré comme ayant été mis hors ligne par l'administrateur, parce qu'il était défectueux. L'administrateur qui a mis ce dispositif hors ligne peut déterminer si cette hypothèse est exacte.

Il est parfois difficile de déterminer la nature exacte de la panne du dispositif. La première étape consiste à examiner le décompte d'erreurs dans la sortie de zpool status. Par exemple :

# zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
  scan: scrub in progress since Tue Sep 27 17:12:40 2011
    63.9M scanned out of 528M at 10.7M/s, 0h0m to go
    0 repaired, 12.11% done
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       2     0     0
          mirror-0  ONLINE       2     0     0
            c2t2d0  ONLINE       2     0     0
            c2t1d0  ONLINE       2     0     0

errors: Permanent errors have been detected in the following files:

        /tank/words

Les erreurs sont divisées en erreurs d'E/S et en erreurs de sommes de contrôle. Ces deux catégories peuvent indiquer le type de panne possible. Une opération typique renvoie un très petit nombre d'erreurs (quelques-unes sur une longue période). Si les erreurs sont nombreuses, un périphérique est probablement en panne ou sur le point de tomber en panne. Cependant, une erreur provoquée par un administrateur peut également entraîner un grand nombre d'erreurs. Le journal système syslog constitue une autre source d'informations. Si le journal présente un grand nombre de messages SCSI ou de pilote Fibre Channel, il existe probablement de graves problèmes matériels. L'absence de messages syslog indique que les dommages sont probablement transitoires.

L'objectif est de répondre à la question suivante :

Est-il possible qu'une autre erreur se produise dans ce périphérique ?

Les erreurs qui ne se produisent qu'une fois sont considérées transitoires et n'indiquent pas une panne potentielle. Les erreurs suffisamment persistantes ou sévères pour indiquer une panne matérielle potentielle sont considérées comme étant des erreurs fatales. Aucun logiciel automatisé actuellement disponible avec ZFS ne permet de déterminer le type d'erreur. Par conséquent, l'administrateur doit procéder manuellement. Une fois l'erreur déterminée, vous pouvez réaliser l'action adéquate. En cas d'erreurs fatales, effacez les erreurs transitoires ou remplacez le périphérique. Ces procédures de réparation sont décrites dans les sections suivantes.

Même si les erreurs de périphériques sont considérées comme étant transitoires, elles peuvent tout de même entraîner des erreurs de données impossibles à corriger au sein du pool. Ces erreurs requièrent des procédures de réparation spéciales, même si le périphérique sous-jacent est considéré comme étant fonctionnel ou réparé. Pour de plus amples informations sur la réparation d'erreurs de données, reportez-vous à la section Réparation de données endommagées.

Suppression des erreurs transitoires

Si les erreurs de périphérique sont considérées comme étant transitoires, dans la mesure où il est peu probable qu'elles affectent la maintenance du périphérique, elles peuvent être effacées en toute sécurité pour indiquer qu'aucune erreur fatale ne s'est produite. Pour effacer les compteurs d'erreurs pour les périphériques mis en miroir ou RAID-Z, utilisez la commande zpool clear. Par exemple :

# zpool clear tank c1t1d0

Cette syntaxe efface toutes les erreurs du périphérique et tout décompte d'erreurs de données associées au périphérique.

Pour effacer toutes les erreurs associées aux périphériques virtuels du pool et tout décompte d'erreurs de données associées au pool, respectez la syntaxe suivante :

# zpool clear tank

Pour de plus amples informations relatives à la suppression des erreurs de pool, reportez-vous à la section Effacement des erreurs de périphérique de pool de stockage.

Remplacement d'un périphérique dans un pool de stockage ZFS

Si le périphérique présente ou risque de présenter une panne permanente, il doit être remplacé. Le remplacement du périphérique dépend de la configuration.

Détermination de la possibilité de remplacement du périphérique
Périphériques impossibles à remplacer
Remplacement d'un périphérique dans un pool de stockage ZFS
Affichage de l'état de réargenture

Détermination de la possibilité de remplacement du périphérique

Si le périphérique à remplacer fait partie d'une configuration redondante, il doit exister suffisamment de répliques pour permettre la récupération des données correctes. Si deux disques d'un miroir à quatre directions sont défaillants, chaque disque peut être remplacé car des répliques saines sont disponibles. Cependant, en cas de panne de deux disques dans un périphérique virtuel RAID-Z à quatre directions (raidz1), aucun disque ne peut être remplacé en l'absence de répliques suffisantes permettant de récupérer les données. Si le périphérique est endommagé mais en ligne, il peut être remplacé tant que l'état du pool n'est pas FAULTED. Toutefois, toute donnée endommagée sur le périphérique est copiée sur le nouveau périphérique, à moins que le nombre de copies des données non endommagées soit déjà suffisant.

Dans la configuration suivante, le disque c1t1d0 peut être remplacé et toute donnée du pool est copiée à partir de la réplique saine, c1t0d0.

    mirror            DEGRADED
    c1t0d0             ONLINE
    c1t1d0             FAULTED

Le disque c1t0d0 peut également être remplacé, mais un autorétablissement des données est impossible, car il n'existe aucune réplique correcte.

Dans la configuration suivante, aucun des disques défaillants ne peut être remplacé. Les disques ONLINE ne peuvent pas l'être non plus, car le pool lui-même est défaillant.

    raidz              FAULTED
    c1t0d0             ONLINE
    c2t0d0             FAULTED
    c3t0d0             FAULTED
    c4t0d0             ONLINE

Dans la configuration suivante, chacun des disques de niveau supérieur peut être remplacé. Cependant, les données incorrectes seront également copiées dans le nouveau disque, le cas échéant.

c1t0d0         ONLINE
c1t1d0         ONLINE

Si les deux disques sont défectueux, alors tout remplacement est impossible car le pool lui-même est défectueux.

Périphériques impossibles à remplacer

Si la perte d'un périphérique entraîne une défaillance du pool ou si le périphérique contient trop d'erreurs de données dans une configuration non redondante, alors le remplacement du périphérique en toute sécurité est impossible. En l'absence de redondance suffisante, il n'existe pas de données correctes avec lesquelles réparer le périphérique défectueux. Dans ce cas, la seule option est de détruire le pool, recréer la configuration et restaurer les données à partir d'une copie de sauvegarde.

Pour de plus amples informations sur la restauration d'un pool entier, reportez-vous à la section Réparation de dommages présents dans l'ensemble du pool de stockage ZFS.

Remplacement d'un périphérique dans un pool de stockage ZFS

Après avoir déterminé qu'il est possible de remplacer un périphérique, exécutez la commande zpool replace pour le remplacer effectivement. Exécutez la commande suivante si vous remplacez le périphérique endommagé par un autre périphérique différent :

# zpool replace tank c1t1d0 c2t0d0

Cette commande lance la migration de données vers le nouveau périphérique, soit à partir du périphérique endommagé, soit à partir d'autres périphériques du pool s'il s'agit d'une configuration redondante. Une fois l'exécution de la commande terminée, le périphérique endommagé est séparé de la configuration. Il peut dorénavant être retiré du système. Si vous avez déjà retiré le périphérique et que vous l'avez remplacé par un autre dans le même emplacement, utilisez la forme "périphérique unique" de la commande. Par exemple :

# zpool replace tank c1t1d0

Cette commande formate adéquatement un disque non formaté et resynchronise ensuite les données à partir du reste de la configuration.

Pour de plus amples informations sur la commande zpool replace reportez-vous à la section Remplacement de périphériques dans un pool de stockage.

Exemple 11-1 Remplacement d'un périphérique dans un pool de stockage ZFS

L'exemple suivant illustre le remplacement d'un périphérique (c1t3d0) du pool de stockage mis en miroir tank sur un système équipé de périphériques SATA. Pour remplacer le disque c1t3d0 par un nouveau au même emplacement (c1t3d0), annulez la configuration du disque avant de procéder au remplacement. Voici les principales étapes à suivre :

Déconnectez le disque (c1t3d0) à remplacer. Vous ne pouvez pas annuler la configuration d'un disque utilisé.
Utilisez la commande cfgadm pour identifier le disque (c1t3d0) dont la configuration doit être annulée et annulez-la. Dans cette configuration en miroir, le pool est endommagé et le disque est hors ligne, mais le pool reste disponible.
Remplacez le disque (c1t3d0). Vérifiez que la DEL bleue Ready to Remove, indiquant que le périphérique est prêt à être retiré, est allumée avant de retirer le lecteur défaillant.
Reconfigurez le disque (c1t3d0).
Mettez le nouveau disque (c1t3d0) en ligne.
Exécutez la commande zpool replace pour remplacer le disque (c1t3d0).

Remarque - Si vous avez précédemment défini la propriété de pool autoreplace sur on, tout nouveau périphérique détecté au même emplacement physique qu'un périphérique appartenant précédemment au pool est automatiquement formaté et remplacé sans recourir à la commande zpool replace. Cette fonction n'est pas prise en charge sur tous les types de matériel.
Si un disque défectueux est automatiquement remplacé par un disque hot spare, vous devrez peut-être déconnecter le disque hot spare une fois le disque défectueux remplacé. Par exemple, si c2t4d0 reste actif comme disque hot spare actif une fois le disque défectueux remplacé, déconnectez-le.
```
# zpool detach tank c2t4d0
```
Si FMA signale le périphérique défaillant, effacez la panne de périphérique.
```
# fmadm faulty
# fmadm repair zfs://pool=name/vdev=guid
```

L'exemple suivant explique étape par étape comment remplacer un disque dans un pool de stockage ZFS.

# zpool offline tank c1t3d0
# cfgadm | grep c1t3d0
sata1/3::dsk/c1t3d0            disk         connected    configured   ok
# cfgadm -c unconfigure sata1/3
Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3
This operation will suspend activity on the SATA device
Continue (yes/no)? yes
# cfgadm | grep sata1/3
sata1/3                        disk         connected    unconfigured ok
<Physically replace the failed disk c1t3d0>
# cfgadm -c configure sata1/3
# cfgadm | grep sata1/3
sata1/3::dsk/c1t3d0            disk         connected    configured   ok
# zpool online tank c1t3d0
# zpool replace tank c1t3d0
# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            c0t2d0  ONLINE       0     0     0
            c1t2d0  ONLINE       0     0     0
          mirror-2  ONLINE       0     0     0
            c0t3d0  ONLINE       0     0     0
            c1t3d0  ONLINE       0     0     0

errors: No known data errors

Notez que la commande zpool output affiche parfois l'ancien disque et le nouveau sous l'en-tête de remplacement. Par exemple :

replacing     DEGRADED     0     0    0
  c1t3d0s0/o  FAULTED      0     0    0
  c1t3d0      ONLINE       0     0    0

Ce texte signifie que la procédure de remplacement et la resynchronisation du nouveau disque sont en cours.

Pour remplacer un disque (c1t3d0) par un autre disque (c4t3d0), il suffit d'exécuter la commande zpool replace. Par exemple :

# zpool replace tank c1t3d0 c4t3d0
# zpool status
  pool: tank
 state: DEGRADED
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:35:41 2010
config:

        NAME             STATE     READ WRITE CKSUM
        tank             DEGRADED     0     0     0
          mirror-0       ONLINE       0     0     0
            c0t1d0       ONLINE       0     0     0
            c1t1d0       ONLINE       0     0     0
          mirror-1       ONLINE       0     0     0
            c0t2d0       ONLINE       0     0     0
            c1t2d0       ONLINE       0     0     0
          mirror-2       DEGRADED     0     0     0
            c0t3d0       ONLINE       0     0     0
            replacing    DEGRADED     0     0     0
              c1t3d0     OFFLINE      0     0     0
              c4t3d0     ONLINE       0     0     0

errors: No known data errors

La commande zpool status doit parfois être exécutée plusieurs fois jusqu'à la fin du remplacement du disque.

# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:35:41 2010
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            c0t1d0    ONLINE       0     0     0
            c1t1d0    ONLINE       0     0     0
          mirror-1    ONLINE       0     0     0
            c0t2d0    ONLINE       0     0     0
            c1t2d0    ONLINE       0     0     0
          mirror-2    ONLINE       0     0     0
            c0t3d0    ONLINE       0     0     0
            c4t3d0    ONLINE       0     0     0

Exemple 11-2 Remplacement d'un périphérique de journalisation défaillant

ZFS identifie les défaillances de journal d'intention dans la sortie de commande zpool status. Le composant FMA (Fault Management Architecture) signale également ces erreurs. ZFS et FMA décrivent comment récupérer les données en cas de défaillance du journal d'intention.

L'exemple suivant montre comment récupérer les données d'un périphérique de journalisation défaillant (c0t5d0 ) dans le pool de stockage (pool). Voici les principales étapes à suivre :

Vérifiez la sortie zpool status -x et le message de diagnostic FMA, décrits ici :

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&alias=EVENT:ZFS-8000-K4
Remplacez physiquement le périphérique de journalisation défaillant.
Mettez le nouveau périphérique de journalisation en ligne.
Effacez la condition d'erreur du pool.
Effacez l'erreur FMA.

Par exemple, si le système s'arrête soudainement avant que les opérations d'écriture synchrone ne soient affectées à un pool disposant d'un périphérique de journalisation distinct, un message tel que le suivant s'affiche :

# zpool status -x
  pool: pool
 state: FAULTED
status: One or more of the intent logs could not be read.
        Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
        or ignore the intent log records by running 'zpool clear'.
 scrub: none requested
config:

        NAME          STATE     READ WRITE CKSUM
        pool          FAULTED      0     0     0 bad intent log
          mirror-0    ONLINE       0     0     0
            c0t1d0    ONLINE       0     0     0
            c0t4d0    ONLINE       0     0     0
        logs          FAULTED      0     0     0 bad intent log
          c0t5d0      UNAVAIL      0     0     0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool
# fmadm faulty
# fmadm repair zfs://pool=name/vdev=guid

Vous pouvez résoudre la panne du périphérique de journalisation de l'une des façons suivantes :

Remplacez ou récupérez le périphérique de journalisation. Dans cet exemple, le périphérique de journalisation est c0t5d0.
Mettez le périphérique de journalisation en ligne.
```
# zpool online pool c0t5d0
```
Réinitialisez la condition d'erreur de périphérique de journalisation défaillante.
```
# zpool clear pool
```

Pour effectuer une récupération suite à cette erreur sans remplacer le périphérique de journalisation défaillant, vous pouvez effacer l'erreur à l'aide de la commande zpool clear. Dans ce scénario, le pool fonctionnera en mode dégradé et les enregistrements de journal seront enregistrés dans le pool principal jusqu'à ce que le périphérique de journalisation distinct soit remplacé.

Envisagez d'utiliser des périphériques de journalisation mis en miroir afin d'éviter un scénario de défaillance de périphérique de journalisation.

Affichage de l'état de réargenture

Le processus de remplacement d'un périphérique peut prendre beaucoup de temps, selon la taille du périphérique et la quantité de données dans le pool. Le processus de déplacement de données d'un périphérique à un autre s'appelle la resynchronisation. Vous pouvez la contrôler à l'aide de la commande zpool status.

Les messages d'état de la réargenture zpool status suivants sont fournis :

Rapport de progression de la réargenture. Par exemple :

scan: resilver in progress since Mon Jun  7 09:17:27 2010
   13.3G scanned out of 16.2G at 18.5M/s, 0h2m to go
   13.3G resilvered, 82.34% done

Message de fin de la réargenture. Par exemple :

resilvered 16.2G in 0h16m with 0 errors on Mon Jun  7 09:34:21 2010

Les messages de fin de réargenture subsistent après plusieurs réinitialisations du système.

Les systèmes de fichiers traditionnels effectuent la réargenture de données au niveau du bloc. Dans la mesure où ZFS élimine la séparation en couches artificielles du gestionnaire de volume, il peut effectuer la resynchronisation de façon bien plus puissante et contrôlée. Les deux avantages de cette fonction sont comme suite :

ZFS n'effectue la réargenture que de la quantité minimale de données requises. Dans le cas d'une brève interruption de service (par rapport à un remplacement complet d'un périphérique), vous pouvez effectuer la resynchronisation du disque en quelques minutes ou quelques secondes. Lors du remplacement d'un disque entier, la durée du processus de resynchronisation est proportionnelle à la quantité de données utilisées dans le disque. Le remplacement d'un disque de 500 Go ne dure que quelques secondes si le pool ne contient que quelques giga-octets d'espace utilisé.
La réargenture est un processus fiable qui peut être interrompu, le cas échéant. En cas de mise hors-tension ou de réinitialisation du système, le processus de réargenture reprend exactement là où il s'est arrêté, sans requérir une intervention manuelle.

La commande zpool status permet de visualiser le processus de réargenture. Par exemple :

# zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scan: resilver in progress since Mon Jun  7 10:49:20 2010
    54.6M scanned out of 222M at 5.46M/s, 0h0m to go
    54.5M resilvered, 24.64% done
config:

        NAME             STATE     READ WRITE CKSUM
        tank             ONLINE       0     0     0
          mirror-0       ONLINE       0     0     0
            replacing-0  ONLINE       0     0     0
              c1t0d0     ONLINE       0     0     0
              c2t0d0     ONLINE       0     0     0  (resilvering)
            c1t1d0       ONLINE       0     0     0

Dans cet exemple, le disque c1t0d0 est remplacé par c2t0d0. Cet événement est observé dans la sortie d'état par la présence du périphérique virtuel replacing de la configuration. Ce périphérique n'est pas réel et ne permet pas de créer un pool. L'objectif de ce périphérique consiste uniquement à afficher le processus de resynchronisation et à identifier le périphérique en cours de remplacement.

Notez que tout pool en cours de resynchronisation se voit attribuer l'état ONLINE ou DEGRADED car il ne peut pas fournir le niveau souhaité de redondance tant que le processus n'est pas terminé. La resynchronisation s'effectue aussi rapidement que possible, mais les E/S sont toujours programmées avec une priorité inférieure à celle des E/S requises par l'utilisateur afin de minimiser l'impact sur le système. Une fois la resynchronisation terminée, la nouvelle configuration complète s'applique, remplaçant l'ancienne configuration. Par exemple :

# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h1m with 0 errors on Tue Feb  2 13:54:30 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2t0d0  ONLINE       0     0     0  377M resilvered
            c1t1d0  ONLINE       0     0     0

errors: No known data errors

L'état du pool est à nouveau ONLINE et le disque défectueux d'origine (c1t0d0) a été supprimé de la configuration.

Ignorer les liens de navigation
Quitter l'aperu
	Administration d'Oracle Solaris : Systèmes de fichiers ZFS Oracle Solaris 11 Information Library (Français)