Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Administration d'Oracle Solaris 11.1 : Systèmes de fichiers ZFS Oracle Solaris 11.1 Information Library (Français) |
1. Système de fichiers Oracle Solaris ZFS (introduction)
2. Mise en route d'Oracle Solaris ZFS
3. Gestion des pools de stockage Oracle Solaris ZFS
4. Gestion des composants du pool root ZFS
5. Gestion des systèmes de fichiers Oracle Solaris ZFS
6. Utilisation des instantanés et des clones ZFS Oracle Solaris
7. Utilisation des ACL et des attributs pour protéger les fichiers Oracle Solaris ZFS
8. Administration déléguée de ZFS dans Oracle Solaris
9. Rubriques avancées Oracle Solaris ZFS
10. Dépannage d'Oracle Solaris ZFS et récupération de pool
Résolution des problèmes d'espace ZFS
Compte-rendu d'espace de système de fichiers ZFS
Compte-rendu sur l'espace des pools de stockage ZFS
Identification des défaillances ZFS
Périphériques manquants dans un pool de stockage ZFS
Périphériques endommagés dans un pool de stockage ZFS
Contrôle de l'intégrité d'un système de fichiers ZFS
Réparation du système de fichiers
Validation du système de fichiers
Contrôle du nettoyage de données ZFS
Nettoyage explicite de données ZFS
Nettoyage et réargenture de données ZFS
Résolution de problèmes avec le système de fichiers ZFS
Recherche de problèmes éventuels dans un pool de stockage ZFS
Consultation de la sortie de zpool status
Informations globales d'état des pools
Informations de configuration de pool
Erreurs d'altération de données
Rapport système de messages d'erreur ZFS
Réparation d'un configuration ZFS endommagée
Réparation d'un périphérique manquant
Reconnexion physique d'un périphérique
Notification relative à la disponibilité de périphériques dans ZFS
Remplacement ou réparation d'un périphérique endommagé
Détermination du type de panne de périphérique
Suppression des erreurs transitoires
Remplacement d'un périphérique dans un pool de stockage ZFS
Détermination de la possibilité de remplacement du périphérique
Périphériques impossibles à remplacer
Réparation de données endommagées
Identification du type d'altération de données
Réparation d'un fichier ou répertoire endommagé
Réparation de données endommagées avec plusieurs références de blocs
Réparation de dommages présents dans l'ensemble du pool de stockage ZFS
Réparation d'un système impossible à réinitialiser
11. Archivage des instantanés et récupération du pool root
12. Pratiques recommandées pour Oracle Solaris ZFS
Cette section explique comment déterminer les types de panne de périphériques, effacer les erreurs transitoires et remplacer un 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 altérations 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 l'endommagement permanent 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 endommagements 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://support.oracle.com/msg/ZFS-8000-8A config: NAME STATE READ WRITE CKSUM tank ONLINE 2 0 0 c8t0d0 ONLINE 0 0 0 c8t0d0 ONLINE 2 0 0 errors: Permanent errors have been detected in the following files: /tank/file.1
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 plus d'informations sur la réparation d'erreurs de données, reportez-vous à la section Réparation de données endommagées.
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 plus d'informations sur la suppression des erreurs de pool, reportez-vous à la section Effacement des erreurs de périphérique de pool de stockage.
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.
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 UNAVAIL, chaque disque peut être remplacé car des répliques saines sont disponibles. Cependant, si deux disques dans un périphérique virtuel RAID-Z à quatre directions (raidz1) sont UNAVAIL, 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 UNAVAIL. 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 UNAVAIL
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 UNAVAIL ne peut être remplacé. Les disques ONLINE ne peuvent pas l'être non plus, car le pool lui-même est UNAVAIL.
raidz1 UNAVAIL c1t0d0 ONLINE c2t0d0 UNAVAIL c3t0d0 UNAVAIL 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 UNAVAIL, tout remplacement est impossible car le pool lui-même est UNAVAIL.
Si la perte d'un périphérique rend un pool UNAVAIL ou si le périphérique contient trop d'erreurs de données dans une configuration non redondante, 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 plus d'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.
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 plus d'informations sur la commande zpool replace reportez-vous à la section Remplacement de périphériques dans un pool de stockage.
Exemple 10-1 Remplacement d'un disque SATA 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. Si le disque qui doit être remplacé n'est pas un disque SATA, reportez-vous à la section Remplacement de périphériques dans un pool de stockage.
Voici les principales étapes à suivre :
Déconnectez le disque (c1t3d0) à remplacer. Vous ne pouvez pas annuler la configuration d'un disque SATA utilisé.
Utilisez la commande cfgadm pour identifier le disque SATA (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 UNAVAIL, si disponible.
Reconfigurez le disque SATA (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 repaired 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 réargenture 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 10-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 :
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.
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 réargenture. Vous pouvez la surveiller à 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 réargenture 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 réargenture du disque en quelques minutes ou quelques secondes. Lors du remplacement d'un disque entier, la durée du processus de réargenture 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 réargenture et à identifier le périphérique en cours de remplacement.
Notez que tout pool en cours de réargenture 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 réargenture 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 réargenture 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.