PowerScale: Probleme mit der Var-Partitionserweiterung

Das aktuelle Skript des Isilon On-Cluster Analysis Tool (IOCA) erzeugt die folgenden Warnungen in Bezug auf die /var Partitionen:

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.

Oder:

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.

Wenn dies ignoriert wird, ist es möglich, dass während eines Laufwerks- oder Schlittenaustauschverfahrens ein Fehler auf einem Gen6- oder Gen6-MLK-Node auftritt.

Wenn der Node wieder hochgefahren wird, wird die /var/log/messages In der Datei für den Node werden Fehler und Meldungen angezeigt, die den folgenden ähneln:

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

In den Versionen 9.2.1.16 und höher, 9.4.0.6 und höher und 9.5.0.0 und höher erweitert OneFS die /var-Partitionsgröße während eines Upgrades auf 2 GB. Der Erweiterungsprozess kann dazu führen, dass diese Meldungen oder Ereignisse ausgelöst werden.

Die Meldung in Bezug auf das Spiegelungspaar, das sich in derselben Fehlerdomäne befindet, ist spezifisch für Gen6- und Gen6-MLK-Nodes (A200, A2000, A300, A3000, H400, H500, H600, H5600, H700, H7000, F800 und F810). Die Erweiterung validiert die Partitionsfehlerdomänen möglicherweise nicht ordnungsgemäß, sodass beide Partitionen für eine der beiden /var Spiegelung auf Laufwerken im selben Laufwerkschlitten. Dies führt dazu, dass der Node einen Fehler aufweist, wenn der Schlitten entfernt wird, wenn beide Spiegelungen für den gemounteten /var Partition im Schlitten befinden.

Entweder mirror/var0 oder mirror/var1 dient als aktive /var Partitionsspiegelung zu einem beliebigen Zeitpunkt. In der Panikmeldung im Beispiel sehen wir, dass /mirror/var1 war der aktive Spiegel. Mit Blick auf die gmirror status und isi devices drive list Befehlsausgaben für den Node:

Truncated status Befehlsausgabe:

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

Die Tasten drive list Befehlsausgabe:

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

In diesem Beispiel /mirror/var1 basiert auf den Laufwerken D0 und D1. Wenn der D-Schlitten aus dem Cluster entfernt wurde, trat auf dem Node ein Fehler auf, da nicht auf das /var Dateisystem.

Die unterschiedlichen Größen der var-Partitionen können sich auf jeden Isilon- oder PowerScale-Node-Typ auswirken, auf dem OneFS 9.x ausgeführt wird. Die Erweiterung für /var Erweitert nur die aktiven /var -Partition auf dem System. Die Partition des letzten zweifelsfrei funktionierenden Modus (LKG) behält die ursprüngliche Größe bei. Wenn der aktive /var Die Partition wird erweitert und zu mehr als 50 % gefüllt. Dies kann zu Problemen führen, wenn die Partition zu Wartungszwecken rotiert werden muss.

Um festzustellen, ob dieses Problem eine LKG-Partition auf dem Cluster betrifft, verwenden Sie den folgenden Befehl:

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

Beispiel:

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

Wenn eines der Geräte mit einer Größe von (1,0G) zurückkommt, ist es betroffen.

Im obigen Beispiel haben die Lab-2-Ports var0 Partitionen sind betroffen und müssen repariert werden. Führen Sie den Befehl erneut aus für var1 im gesamten Cluster, um festzustellen, ob es ebenfalls betroffen ist.

Die dauerhafte Lösung für das PROBLEM MIT DER FEHLERDOMÄNE ist in den folgenden Codeversionen enthalten:

• OneFS 9.5.0.6 
• 9.4.0.16 
• 9.2.1.25 

An der dauerhaften Korrektur für die unterschiedlich großen /var-Partitionen wird gearbeitet. Befolgen Sie das Skript, um das Problem zu beheben. Wenn Sie kein Upgrade durchführen können, folgen Sie dem skriptbasierten Prozess.
 

So verwenden Sie das Skript:

1. Laden Sie das Skript und die md5-Datei auf das Cluster herunter. Kopieren Sie die Dateien nach /ifs/data/Isilon_Support Vergewissern Sie sich auf dem Cluster, dass der MD5-Hash mit dem Hash in der MD5-Datei übereinstimmt:

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. Wenn der Hash nicht übereinstimmt, laden Sie das Skript von der FTP-Site herunter und kopieren Sie es erneut in das Cluster. Wenn der Hash übereinstimmt, führen Sie den folgenden Befehl als root aus:

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

3. Die Ausführung des Skripts dauert in der Regel 5 bis 10 Minuten. Auf großen (30+ Nodes) oder ausgelasteten Clustern kann dies länger dauern. Wenn das Skript abgeschlossen ist, wird berichtet, ob es erfolgreich war oder ob Probleme aufgetreten sind.

Wenn Sie das Skript starten, wird die folgende Ausgabe angezeigt:

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

Während das Skript fortschreitet, wird die Statuszeile aktualisiert:

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

Wenn das Skript erfolgreich abgeschlossen wurde, sehen Sie Folgendes:

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

Dies weist darauf hin, dass alle betroffenen Nodes repariert wurden und das Skript keine Probleme aufwies. Wenn die empfangene Ausgabe von diesem Beispiel abweicht, wenden Sie sich an den Dell Support und geben Sie die Ausgabe und die Protokolldateien vom Bundle-Speicherort an.