PowerScale: Problemas de expansión de partición var

El script actual de la herramienta de análisis en clúster (IOCA) de Isilon genera las siguientes advertencias relacionadas con el /var Particiones:

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.

O:

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 se ignora, es posible que se produzca un estado de alarma en un nodo MLK de 6.ª o 6.ª generación durante un procedimiento de reemplazo de unidades o sleds.

Cuando el nodo aparezca, revise el /var/log/messages El archivo para el nodo muestra errores y mensajes de alarma similares a los siguientes:

(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)

En las versiones 9.2.1.16 y posteriores, 9.4.0.6 y posteriores, y 9.5.0.0 y posteriores, OneFS expande el tamaño de partición /var a 2 GB durante una actualización. El proceso de expansión puede hacer que se activen estos mensajes o eventos.

El mensaje relacionado con el par en espejo que se encuentra en el mismo dominio de falla es específico de los nodos MLK de 6.ª y 6.ª generación (A200, A2000, A300, A3000, H400, H500, H600, H5600, H700, H7000, F800 y F810). Es posible que la expansión no valide correctamente los dominios de falla de partición, lo que coloca ambas particiones para cualquiera de ellos /var Espejeado en unidades en el mismo soporte de unidades. Esto provoca que el nodo entre en una situación de pánico cuando se extrae el sled si ambos espejos para el montaje /var partición están en el sled.

Cualquiera de los dos mirror/var0 o mirror/var1 sirve como el activo /var Duplicación de particiones en cualquier momento. En el mensaje de alarma del ejemplo, vemos que /mirror/var1 era el espejo activo. Al observar el gmirror status y isi devices drive list Salidas del comando para el nodo:

Truuncated status Salida del comando:

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

El comando drive list Salida del comando:

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
---------------------------------------------------------

En este ejemplo, /mirror/var1 se basa en las unidades D0 y D1. Cuando el sled D se extrae del clúster, el nodo entra en estado de alarma debido a la incapacidad de acceder al /var sistema de archivos.

Los diferentes tamaños de las particiones var pueden afectar cualquier tipo de nodo Isilon o PowerScale que ejecute OneFS 9.x. La expansión para /var solo expande el activo /var partición en el sistema. La última partición en buen estado (LKG) sigue siendo del tamaño original. Si el activo /var La partición se expande y se llena a más del 50 %, esto puede causar problemas si se debe rotar la partición para realizar tareas de mantenimiento.

Para determinar si este problema afecta a una partición LKG en el clúster, utilice el siguiente comando:

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

Ejemplo:

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 alguno de los dispositivos vuelve con un tamaño de (1,0 G), se ve afectado.

En el ejemplo anterior, los laboratorios var0 Las particiones se ven afectadas y se deben corregir. Vuelva a ejecutar el comando para var1 en todo el clúster para determinar si también se ve afectado.

La corrección permanente para el PROBLEMA DE DOMINIO DE FALLA ÚNICAMENTE se encuentra en las siguientes versiones de código:

• OneFS 9.5.0.6 
• 9.4.0.16 
• 9.2.1.25 

Se está trabajando en la corrección permanente para particiones /var de diferentes tamaños. Para resolver el problema, siga el proceso con script. Si no puede realizar la actualización, siga el proceso con script.
 
Para usar el script:

1. Descargue el script y el archivo md5 en el clúster. Copie los archivos en /ifs/data/Isilon_Support en el clúster y confirme que el hash md5 coincida con el hash en el archivo 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 el hash no coincide, descargue el script desde el sitio FTP y cópielo nuevamente en el clúster. Si el hash coincide, ejecute el siguiente comando como raíz:

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

3. El script suele tardar entre 5 y 10 minutos en ejecutarse. Puede tardar más tiempo en clústeres grandes (30+ nodos) u ocupados. Cuando se completa el script, informa si se realizó correctamente o si hubo problemas.

Cuando inicia el script, verá el siguiente resultado:

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

A medida que avanza el script, la línea Status se actualiza:

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

Cuando el script se completa correctamente, verá lo siguiente:

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

Esto indica que se repararon todos los nodos afectados y que el script no tuvo problemas. Si el resultado recibido es diferente a este ejemplo, comuníquese con el soporte de Dell y proporcione el resultado y los archivos de registro de la ubicación del paquete.