PowerScale : Problèmes d’extension de partition Var

Le script actuel de l’outil Isilon On-Cluster Analysis (IOCA) génère les avertissements suivants liés au /var Partitions:

System Partition Free Space                       FAIL
  CRITICAL: The following nodes have /var mirrors of different sizes: 1-10
  INFO: Please reference KB 000213248 (https://www.dell.com/support/kbdoc/000213248) for further information.
  INFO: For more information refer to KB article 000041465 found at https://www.dell.com/support/kbdoc/000041465.

ou :

Mirror Status                                     FAIL
  CRITICAL: The mirror pair for var1 appear to be in the same fault domain on nodes: 1-10.
  CRITICAL: The following nodes have /var mirrors of different sizes: 1-10
  INFO: Please open a Technical Support Service Request and reference this failure within the description.
  INFO: Please refer to KB 000213248 (https://www.dell.com/support/kbdoc/en-us/000213248) for further information.

Si elle est ignorée, il est possible qu’un fonctionnement inattendu se produise sur un nœud MLK Gen 6 ou Gen 6 lors d’une procédure de remplacement de disque ou de traîneau.

Lorsque le nœud s’affiche, l’examen des paramètres /var/log/messages Le fichier du nœud affiche des messages d’erreur et de fonctionnement inattendu similaires à ce qui suit :

(da21:pmspcbsd0:0:22:0): pccb 0xfffffe8543174480, ccb 0xfffff80e31347000: ccbStatus 3, scsiStatus 5 
(da22:pmspcbsd0:0:23:0): pccb 0xfffffe8543151fe0, ccb 0xfffff807c4753000: ccbStatus 3, scsiStatus 5 
(da21:pmspcbsd0:0:22:0): WRITE(10). CDB: 2a 00 00 04 dd 44 00 00 04 00 
(da21:pmspcbsd0:0:22:0): CAM status: CCB request aborted by the host 
(da22:pmspcbsd0:0:23:0): WRITE(10). CDB: 2a 00 00 04 dd 44 00 00 04 00 
(da21:pmspcbsd0:0:22:0): Retrying command, 3 more tries remain 
(da22:pmspcbsd0:0:23:0): CAM status: CCB request aborted by the host 
(da21:pmspcbsd0:0:22:0): pccb 0xfffffe8543151fe0, ccb 0xfffff80e31347000: ccbStatus 3, scsiStatus 2 
(da22:pmspcbsd0:0:23:0): Retrying command, 3 more tries remain 
(da21:pmspcbsd0:0:22:0): cam_periph_error: SSQ_LOST removing device ccb 0xfffff80e31347000 status 0x8 flags 0x2 
(da22:pmspcbsd0:0:23:0): pccb 0xfffffe8543151fe0, ccb 0xfffff807c4753000: ccbStatus 3, scsiStatus 2 
(da21:pmspcbsd0:0:22:0): Invalidating pack 
(da22:pmspcbsd0:0:23:0): cam_periph_error: SSQ_LOST removing device ccb 0xfffff807c4753000 status 0x8 flags 0x2 
(da22:pmspcbsd0:0:23:0): Invalidating pack 
(da21:pmspcbsd0:0:22:0): removing device entry 
(da21:pmspcbsd0:0:22:0): Periph destroyed 
panic @ time 1681142660.493, thread 0xfffffe874ee12000: mirror/var1: all devices failed (read, offset 1304707072, length 0) 
time = 1681142660 
cpuid = 3, TSC = 0x5e76342b8e8e59 
Panic occurred in module kernel loaded at 0xffffffff80200000: 

Stack: -------------------------------------------------- 
kernel:g_mirror_worker+0x251f 
kernel:fork_exit+0x82 
-------------------------------------------------- 
Disabling swatchdog 
Dumping stacks (40960 bytes)

Dans les versions 9.2.1.16 et ultérieures, 9.4.0.6 et ultérieures, et 9.5.0.0 et versions ultérieures, OneFS étend la taille de la partition /var à 2 Go lors d’une mise à niveau. Le processus d’extension peut entraîner le déclenchement de ces messages ou événements.

Le message lié à la paire de miroirs se trouvant dans le même domaine de pannes est spécifique aux nœuds MLK Gen6 et Gen6 (A200, A2000, A300, A3000, H400, H500, H600, H5600, H700, H7000, F800 et F810). L’extension peut ne pas valider correctement les domaines de pannes de la partition, en plaçant les deux partitions pour l’un ou l’autre /var Mise en miroir sur les disques du même traîneau de disque. Cela provoque un fonctionnement inattendu du nœud lorsque le traîneau est retiré si les deux miroirs du /var partition se trouvent dans le traîneau.

Ou mirror/var0 ou mirror/var1 sert d’actif /var miroir de partition à tout moment. Le message d’erreur de l’exemple montre que /mirror/var1 était le miroir actif. Si l’on regarde le gmirror status et isi devices drive list sorties de commande pour le nœud :

Truncated status Résultat de la commande :

gmirror status
     mirror/var1  COMPLETE  da14p3 (ACTIVE) <<<<
                            da13p3 (ACTIVE) <<<<

la commande drive list Résultat de la commande :

isi devices drive list
Lnn  Location  Device    Lnum  State   Serial       Sled
---------------------------------------------------------
21   Bay  1    /dev/da1  15    L3      xxxxxxxxxxxx N/A
21   Bay  2    /dev/da2  16    L3      xxxxxxxxxxxx N/A
21   Bay  A0   /dev/da5  12    HEALTHY xxxxxxxx     A
21   Bay  A1   /dev/da4  13    HEALTHY xxxxxxxx     A
21   Bay  A2   /dev/da3  14    HEALTHY xxxxxxxx     A
21   Bay  B0   /dev/da8  9     HEALTHY xxxxxxxx     B
21   Bay  B1   /dev/da7  10    HEALTHY xxxxxxxx     B
21   Bay  B2   /dev/da6  11    HEALTHY xxxxxxxx     B
21   Bay  C0   /dev/da11 6     HEALTHY xxxxxxxx     C
21   Bay  C1   /dev/da10 7     HEALTHY xxxxxxxx     C
21   Bay  C2   /dev/da9  8     HEALTHY xxxxxxxx     C
21   Bay  D0   /dev/da14 3     HEALTHY xxxxxxxx     D <<<<
21   Bay  D1   /dev/da13 4     HEALTHY xxxxxxxx     D <<<<
21   Bay  D2   /dev/da12 5     HEALTHY xxxxxxxx     D
21   Bay  E0   /dev/da17 0     HEALTHY xxxxxxxx     E
21   Bay  E1   /dev/da16 1     HEALTHY xxxxxxxx     E
21   Bay  E2   /dev/da15 2     HEALTHY xxxxxxxx     E
---------------------------------------------------------

Dans cet exemple, /mirror/var1 est construit sur les disques D0 et D1. Lorsque le traîneau D est retiré du cluster, le nœud présente un fonctionnement inattendu en raison de l’impossibilité d’accéder au /var système de fichiers.

Les différentes tailles des partitions var peuvent affecter n’importe quel type de nœud Isilon ou PowerScale qui exécute OneFS 9.x. L’extension pour /var Étend uniquement l’actif /var sur le système. La partition LKG (Last Known Right) conserve sa taille d’origine. Si l’option active /var La partition est développée et remplie à plus de 50 %, ce qui peut entraîner des problèmes si la partition doit être pivotée pour maintenance.

Pour déterminer si ce problème affecte une partition LKG sur le cluster, utilisez la commande suivante :

# isi_for_array -sX 'gmirror list var0 var1' | grep -A20 mirror | egrep "var|Media"

Exemple :

lab-1# isi_for_array -sX 'gmirror list var0 var1' | grep -A20 mirror | egrep "var|Media"
lab-1: 1. Name: mirror/var0
lab-1:    Mediasize: 2147479552 (2.0G)
lab-1:    Mediasize: 2147483648 (2.0G)
lab-1:    Mediasize: 2147483648 (2.0G)
lab-2: 1. Name: mirror/var0
lab-2:    Mediasize: 2147479552 (1.0G) <<<<
lab-2:    Mediasize: 2147483648 (1.0G) <<<<
lab-2:    Mediasize: 2147483648 (1.0G) <<<<
lab-3: 1. Name: mirror/var0
lab-3:    Mediasize: 2147479552 (2.0G)
lab-3:    Mediasize: 2147483648 (2.0G)
lab-3:    Mediasize: 2147483648 (2.0G)
lab-4: 1. Name: mirror/var0
lab-4:    Mediasize: 2147479552 (2.0G)
lab-4:    Mediasize: 2147483648 (2.0G)
lab-4:    Mediasize: 2147483648 (2.0G)
....

Si l’un des appareils revient avec une taille de (1,0 Go), il est affecté.

Dans l’exemple ci-dessus, l’attribut lab-2 var0 Les partitions sont concernées et doivent être corrigées. Exécutez à nouveau la commande pour var1 sur l’ensemble du cluster pour déterminer s’il est également affecté.

Le correctif permanent pour le FAULT DOMAIN ISSUE ONLY se trouve dans les versions de code suivantes :

• OneFS 9.5.0.6 
• 9.4.0.16 
• 9.2.1.25 

Le correctif permanent pour les différentes partitions /var est en cours d’élaboration. Pour résoudre le problème, suivez le processus scripté. Si vous ne parvenez pas à effectuer la mise à niveau, suivez le processus scripté.
 
Pour utiliser le script :

1. Téléchargez le script et le fichier md5 sur le cluster. Copiez les fichiers dans /ifs/data/Isilon_Support sur le cluster et vérifiez que le hachage md5 correspond au hachage du fichier md5 :

Lab-1# mv var_mirror_repair.sh /ifs/data/Isilon_Support/
Lab-1# mv var_mirror_repair.md5 /ifs/data/Isilon_Support/
Lab-1# md5 /ifs/data/Isilon_Support/var_mirror_repair.sh
MD5 (/ifs/data/Isilon_Support/var_mirror_repair.sh) = 0881afeeb39fdaf02e2a90d784e4ed21
Lab-1# # cat /ifs/data/Isilon_Support/var_mirror_repair.md5
0881afeeb39fdaf02e2a90d784e4ed21

2. Si le hachage ne correspond pas, téléchargez le script à partir du site FTP et copiez-le à nouveau sur le cluster. Si le hachage correspond, exécutez la commande suivante en tant qu’utilisateur root :

lab-1# sh /ifs/data/Isilon_Support/var_mirror_repair.sh

3. L’exécution du script prend généralement entre 5 et 10 minutes. Elle peut prendre plus de temps sur les clusters volumineux (+ de 30 nœuds) ou occupés. Une fois le script terminé, il indique s’il a réussi ou s’il y a eu des problèmes.

Lorsque vous lancez le script, le résultat suivant s’affiche :

Lab-1# sh /ifs/data/Isilon_Support/var_mirror_repair.sh
Full output can be found at:
 /ifs/data/Isilon_Support/var_mirror_repair.FULL_CLUSTER.2023-10-19T092522.csv

Status: 0/4 Nodes checked, 0/4 var0 partitions, 0/4 var1 partitions

Au fur et à mesure que le script progresse, la ligne Status est mise à jour :

Status: 4/4 Nodes checked, 4/4 var0 partitions, 4/4 var1 partitions

Une fois le script terminé avec succès, vous voyez ce qui suit :

Status: 4/4 Nodes checked, 4/4 var0 partitions, 4/4 var1 partitions

No issues were identified.

Moving files to: var_mirror_repair.2023-10-19T092522.d
Bundle Location: var_mirror_repair.2023-10-19T092522.tgz

Cela indique que tous les nœuds concernés ont été réparés et que le script n’a rencontré aucun problème. Si la sortie reçue est différente de cet exemple, contactez le support Dell et fournissez la sortie et les fichiers log à partir de l’emplacement du bundle.