Dépannage des disques en panne, des disques manquants et de l’état « failed was »

Problème

Cet article contient une procédure de résolution des problèmes des états « failed » ou « failed was » rapportés par vxdisk.

Message d’erreur

# vxdisk -o alldgs list
DEVICE       TYPE            DISK         GROUP        STATUS
disk_0       auto:cdsdisk    -            (vxfendg)    online
disk_1       auto:cdsdisk    -            (vxfendg)    online
disk_2       auto:cdsdisk    -            (vxfendg)    online
disk_3       auto:cdsdisk    datadg01     datadg       online
disk_4       auto            -            -            error
disk_5       auto:cdsdisk    datadg03     datadg       online
disk_6       auto:cdsdisk    datadg04     datadg       online
disk_7       auto:cdsdisk    -            (sambadg)    online
disk_8       auto:cdsdisk    -            -            online
disk_9       auto:cdsdisk    -            -            online
sda          auto:none       -            -            online invalid
-            -         datadg02     datadg       failed was:disk_4

Solution

Sommaire

1. Introduction
2. Disques à l’état « failed » et à l’état « failing »
3. Sauvegarde d’urgence de la configuration d’un groupe de disques
4. Le disque a-t-il été exclu par vxvm.exclude ?
5. Le disque a-t-il été remplacé par une autre solution de gestionnaire de volume logique ?
6. Détermination du potentiel de réassociation d’un disque
7. Vérification de la lisibilité d’un disque par le système d’exploitation
8. Les chemins d’accès au disque ont-ils été désactivés ?
9. Restauration de la configuration d’un groupe de disques avec vxconfigrestore
10. Restauration manuelle de la configuration d’un groupe de disques, avec les UDID et les ID des disques
11. Redémarrage du volume

1. Introduction

(Retour au début)


Cet article contient une procédure de résolution des problèmes des états « failed » ou « failed was » rapportés par vxdisk.

L’état « failed » indique un disque qui n’est plus accessible. Ceci est souvent dû à des erreurs d’E/S durables sur le disque, qui empêchent sa lecture par le système d’exploitation (SE). Cela peut également être le résultat d’une corruption au sein de la région privée Veritas.

La région privée est la partie du disque sur laquelle Veritas stocke les enregistrements relatifs au groupe de disques (disques, volumes, sous-disques et plex). Elle s’oppose à la région publique, qui contient les volumes réels, y compris les données des utilisateurs.

2. Disques à l’état « failed » et à l’état « failing »

(Retour au début)


L’état « failed » ne doit pas être confondu avec l’état « failing ». Cet article discute essentiellement de l’état « failed », tel que rapporté par vxdisk. Pour de plus amples informations sur la résolution des problèmes liés à l’état « failing », consultez https://www.veritas.com/support/fr_FR/article.000034531.

3. Sauvegarde d’urgence de la configuration d’un groupe de disques#vxvmexclude

(Retour au début)


Avant d’apporter d’autres modifications, utilisez vxconfigbackup pour créer une sauvegarde d’urgence de la région privée des autres disques du groupe de disques affectés.

Vxconfigbackup ne sauvegarde pas les données réelles contenues dans les volumes. À la place, il sauvegarde la base de données de configuration de la région privée Veritas qui se trouve sur les disques, ainsi que certaines informations sur les disques eux-mêmes. La base de données de configuration stocke des informations sur les disques contenus dans le groupe de disques, sur les structures des volumes, sur les plex et sur les sous-disques.

Si vxconfigbackup n’est pas disponible, vxprivutil peut-être utilisé pour générer une copie de la base de données de configuration.
 

Pour plus d’informations sur vxconfigbackup et vxprivutil (entre autres, syntaxe et exemples), consultez l’article suivant :

« Utilisation de vxconfigbackup et vxprivutil pour sauvegarder la configuration d’un groupe de disques de la région privée Veritas »
https://www.veritas.com/support/fr_FR/article.000087431

4. Le disque a-t-il été exclu par vxvm.exclude ?

(Retour au début)

/etc/vx/vxvm.exclude conserve une liste de chemins d’accès, de contrôleurs et de produits exclus. Vérifiez si le disque (ou le chemin d’accès/le contrôleur qui lui est associé) est répertorié dans ce fichier.

Si la valeur de « exclude_all » est 1, tous les périphériques doivent être exclus.

Figure 1 : contenu par défaut de /etc/vx/vxvm.exclude

5. Le disque a-t-il été remplacé par une autre solution de gestionnaire de volume logique ?

(Retour au début)


Si vxdisk indique que le type de disque inclut les mots « LVM » ou « ZFS », il est possible que le disque ait été remplacé par une autre solution de gestionnaire de volume logique (LVM). Il est également possible qu’il existe un problème avec le zonage SAN, suite auquel les disques sont présentés aux mauvais systèmes. Avant d’apporter d’autres modifications, assurez-vous que le disque n’est censé être dirigé vers un autre système.

Pour ramener un disque dans son groupe de disques Veritas d’origine, le contrôle de ce disque par une autre solution LVM doit être annulé, puis le disque doit être initialisé pour Veritas avec vxdisksetup. Consultez la documentation du fournisseur approprié pour de plus amples informations sur l’annulation du contrôle d’un disque par une solution LVM.

6. Détermination du potentiel de réassociation d’un disque#5

(Retour au début)
 
 

Vxreattach permet de restaurer le nom du média d’origine du disque, puis d’associer à nouveau ce disque au groupe de disques. Il ne peut normalement être utilisé que si l’état du disque est « online » (voir Figure 2).

Exécutez vxreattach (avec l’argument « -c ») pour déterminer si un disque peut à nouveau être associé au groupe de disques.


Figure 2 : Utilisation de vxreattach avec l’argument « -c » pour vérifier si une nouvelle association est possible

Si vxreattach -c renvoie un groupe de disque et un nom de média de disque sans renvoyer d’erreur, poursuivez l’association du disque (Figure 3). Si une nouvelle association n’est pas possible, une erreur V-5-2-238 s’affiche.


Figure 3 : Utilisation de vxreattach pour associer à nouveau un dique au groupe de disques

7. Vérification de la lisibilité d’un disque par le système d’exploitation

(Retour au début)


Utilisez les commandes natives du SE pour vous assurer que le SE peut lire le disque (et l’étiquette du disque).

• Utilisez des commandes comme prtvtoc, fdisk, lspv ou diskinfo pour lire l’étiquette du disque.
• Utilisez dd pour lire un bloc du disque.

Veritas dépend des pilotes de périphérique du système d’exploitation pour communiquer avec des disques. Si le système d’exploitation ne peut pas lire un disque, Veritas n’y parviendra également pas. Si un disque ne dispose pas d’une étiquette, ou si l’étiquette a été corrompue, Veritas ne reconnaîtra pas le disque. Ces étapes vous aideront à identifier la source d’une panne de disque.
 

8. Les chemins d’accès au disque ont-ils été désactivés ?

(Retour au début)

Utilisez vxdmpadm pour déterminer l’état des chemins d’accès vers les disques (Figure 4).

Veritas désactivera un chemin d’accès en cas d’erreurs d’E/S graves ou durable. Lorsque tous les chemins d’accès vers un disque sont désactivés, le serveur ne peut plus lire ou écrire sur le volume. Si un chemin d’accès a été désactivé, consultez le journal système et recherchez des événements d’erreurs d’E/S rapportés par « vxdmp » ou « scsi ».

Bien qu’un chemin d’accès puisse être réactivé avec « vxdmpadm enable », vxdmp devrait automatiquement évaluer l’état d’un chemin d’accès dans un intervalle de cinq minutes à l’aide d’une requête scsi. Si la requête est réussie, le chemin est automatiquement réactivé. Si un chemin d’accès reste désactivé au-delà de cet intervalle, il est possible que des erreurs d’E/S soient toujours détectées, ce qui nécessite un examen plus approfondi. Les chemins d’accès ne sont pas automatiquement réactivés si le groupe de disques a été désactivé ou si vxesd est arrêté. Le comportement de vxdmp en réponse aux chemins désactivés peut être modifié dans les paramètres personnalisables DMP, disponibles via la commande « vxmpadm gettune ».
 

Figure 4 : exemple d’un chemin d’accès désactivé, tel que rapporté par vxdmpadm

9. Restauration de la configuration d’un groupe de disques avec vxconfigrestore

(Retour au début)

Si la commande vxreattach ne peut être exécutée, utilisez vxconfigrestore pour restaurer le groupe de disques.

Vxconfigrestore ne restaure pas les données réelles contenues dans les volumes. La commande restaure uniquement la base de données de configuration Veritas qui se trouve dans la région privée des disques. La base de données de configuration stocke des informations sur les disques contenus dans le groupe de disques, sur les structures des volumes, sur les plex et sur les sous-disques.
 

10. Restauration manuelle de la configuration d’un groupe de disques, avec les ID uniques des disques (UDID) et les ID des disques

(Retour au début)

S’il n’est pas possible d’utiliser vxconfigrestore pour restaurer les disques, vous pouvez comparer les attributs UDID ou ID des disques avec les enregistrements contenus dans la base de données de configuration de la région privée.
 

11. Redémarrage du volume

(Retour au début)


Lorsque le disque d’origine a été rajouté à son groupe de disques, certaines étapes supplémentaires peuvent être nécessaires pour restaurer le volume. Utilisez vxprint pour déterminer l’état actuel (Figure 5).

• Pour les volumes en miroir :
  • Si au moins un plex n’a pas été affecté par la panne, les autres plex devraient être resynchronisés lorsqu’ils sont réassociés au volume.  Il peut être nécessaire d’utiliser vxrecover pour initier ce processus (Figure 6).
  • Si tous les plex ont été affectés par la panne, il peut être nécessaire d’examiner manuellement chaque plex pour déterminer celui qui contient les mises à jour les plus récentes.

Avertissement : ne forcez pas simplement le démarrage d’un volume en miroir. Un plex contenant des blocs anciens ou corrompus pourrait remplacer un plex contenant des données à jour. L’article suivant présente une procédure pour déterminer manuellement le plex en miroir le plus à jour :

« Détermination manuelle du plex en miroir contenant les données les plus récentes et resynchronisation »
https://www.veritas.com/support/fr_FR/article/article.000087709

• Pour les volumes qui ne sont pas en miroir :
  • Il peut être nécessaire de redémarrer manuellement le volume avec vxvol après avoir rajouté le disque dans le groupe de disques (Figure 5).

Figure 5 : Utilisation de vxprint pour déterminer l’état d’un volume

Figure 6 : utilisation de vxvol pour démarrer un volume et utilisation de vxprint pour examiner les modifications d’état du volume

Figure 7 : Utilisation de vxrecover pour terminer la restauration ou démarrer la resynchronisation d’un volume

mots-clés : failed, failing, failed disk, failed disks, failing disk, failed disks