PowerScale: Erweiterungsprobleme der Var-Partition

Das aktuelle IOCA-Skript (Isilon On-Cluster Analysis) erzeugt die folgenden Warnungen im Zusammenhang mit /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 es ignoriert wird, ist es möglich, dass auf einem Gen6- oder Gen6-MLK-Node während eines Austauschvorgangs von Laufwerken oder Schlitten ein Fehler auftritt.

Wenn der Node hochfährt, wird die Überprüfung der /var/log/messages Die Datei für den Node zeigt Fehler und Panikmeldungen ähnlich der folgenden an:

(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 sowie 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, dass sich das Spiegelungspaar 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 partitioniert werden /var Auf Laufwerken im selben Laufwerkschlitten spiegeln. Dies führt dazu, dass der Node einen Fehler auslöst, wenn der Schlitten entfernt wird, wenn beide Spiegelungen für das gemountete /var Partition im Schlitten befinden.

Entweder mirror/var0 oder mirror/var1 dient als aktive /var Partitionsspiegelung jederzeit möglich ist. Aus der Panikmeldung im Beispiel geht hervor, dass /mirror/var1 war der aktive Spiegel. Wenn wir uns 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) <<<<

Der Befehl 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 wird, hat der Node eine Panik ausgelöst, weil er nicht auf die zugreifen konnte /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 aktive /var -Partition auf dem System. Die letzte bekanntermaßen funktionierende Partition (LKG) behält die ursprüngliche Größe bei. Wenn die 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 sich dieses Problem auf eine LKG-Partition auf dem Cluster auswirkt, 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 der Größe (1,0 G) zurückgegeben wird, ist es betroffen.

Im obigen Beispiel werden die Labor-2 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 er ebenfalls betroffen ist.

Die dauerhafte Korrektur für das FEHLERDOMÄNENPROBLEM ist in den folgenden Codeversionen enthalten:

• OneFS 9.5.0.6 
• 9.4.0.16 
• 9.2.1.25 

An der permanenten Korrektur für die Partitionen unterschiedlicher Größe /var wird gearbeitet. Um das Problem zu beheben, befolgen Sie den skriptbasierten Prozess. Wenn Sie kein Upgrade durchführen können, befolgen Sie den skriptbasierten Prozess.
 
So verwenden Sie das Skript:

1. Laden Sie das Skript und die md5-Datei in den Cluster herunter. Kopieren Sie die Dateien nach /ifs/data/Isilon_Support auf dem Cluster und vergewissern Sie sich, 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 den 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. Bei großen (30+ Nodes) oder ausgelasteten Clustern kann dies länger dauern. Wenn das Skript abgeschlossen ist, wird gemeldet, 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

Im weiteren Verlauf des Skripts wird die Statuszeile aktualisiert:

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

Wenn das Skript erfolgreich abgeschlossen wurde, wird Folgendes angezeigt:

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 betroffene Nodes repariert wurden und das Skript keine Probleme aufwies. Wenn sich die empfangene Ausgabe von diesem Beispiel unterscheidet, wenden Sie sich an den Dell Support und stellen Sie die Ausgabe und die Protokolldateien vom Bundle-Speicherort bereit.