Шкала потужності: Проблеми з розширенням розділу var

Поточний скрипт інструменту Isilon On-Cluster Analysis (IOCA) генерує наступні попередження, пов'язані з /var Розділи:

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.

Або:

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.

При ігноруванні не виключено, що на вузлі Gen6 або Gen6 MLK під час процедури заміни приводу або санчат може виникнути паніка.

Коли вузол підіймається, переглядаючи /var/log/messages Файл для вузла показує помилки та тривожні повідомлення, схожі на наступні:

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

У версіях 9.2.1.16 і новіших, 9.4.0.6 і новіших, а також 9.5.0.0 і новіших OneFS розширює розмір розділу /var до 2 ГБ під час оновлення. Процес розширення може спричинити ініціацію цих повідомлень або подій.

Повідомлення, пов'язане з тим, що дзеркальна пара знаходиться в одному домені несправностей, специфічне для вузлів MLK Gen6 і Gen6 (A200, A2000, A300, A3000, H400, H500, H600, H5600, H700, H7000, F800 і F810). Розширення може не перевіряти домени помилок розділів належним чином, розміщуючи обидва розділи для будь-якого з них /var дзеркало на дисках в тому ж приводі санчат. Це викликає паніку у вузла при знятті санчат, якщо обидва дзеркала для встановлюються /var перегородки знаходяться в санчатах.

Або mirror/var0 або mirror/var1 виконує роль активного /var дзеркало перегородки в будь-який час. З панічного повідомлення в прикладі ми бачимо, що /mirror/var1 було активним дзеркалом. Дивлячись на gmirror status і isi devices drive list виводи команд для вузла:

Усічено status Вихід команди:

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

Об'єкт drive list Вихід команди:

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

У цьому прикладі /mirror/var1 побудований на накопичувачах D0 і D1. При видаленні санчат D з грона, вузол запанікував через неможливість доступу до /var файлова система.

Різні розміри розділів var можуть вплинути на будь-який тип вузла Isilon або PowerScale, який працює під керуванням OneFS 9.x. Розширення для /var тільки розширює активне /var розділ на системі. Розділ останнього відомого добра (LKG) залишається оригінального розміру. Якщо активний /var розділ розширюється і заповнюється більш ніж на 50%, це може спричинити проблеми, якщо розділ потрібно повернути для обслуговування.

Щоб визначити, чи впливає ця проблема на розділ LKG на кластері, скористайтеся такою командою:

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

Приклад:

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

Якщо будь-який із пристроїв повернеться з розміром (1,0 Гб), це вплине на нього.

У наведеному вище прикладі lab-2 var0 Це впливає на перегородки і їх необхідно виправити. Повторно виконайте команду для var1 по всьому кластеру, щоб визначити, чи це також уражено.

Остаточне виправлення ЛИШЕ ПРОБЛЕМИ З ДОМЕНОМ FAULT міститься в наступних випусках коду:

• OneFS 9.5.0.6 
• 9.4.0.16 
• 9.2.1.25 

Працює над постійним виправленням для розділів /var різного розміру. Щоб вирішити проблему, дотримуйтесь описаного сценарію. Якщо ви не можете оновити систему, дотримуйтесь описаного сценарію.
 
Щоб скористатися сценарієм:

1. Завантажте скрипт і файл md5 в кластер. Скопіюйте файли в /ifs/data/Isilon_Support на кластері та переконайтеся, що хеш md5 збігається з хешем у файлі 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. Якщо хеш не співпадає, скачайте скрипт з FTP-сайту і знову скопіюйте його в кластер. Якщо хеш збігається, виконайте наступну команду від імені користувача root:

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

3. Зазвичай сценарій виконується 5-10 хвилин. Це може зайняти більше часу на великих (30+ вузлів) або завантажених кластерах. Коли сценарій завершується, він повідомляє, чи був він успішним або чи були проблеми.

Коли ви запускаєте скрипт, ви бачите такий результат:

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

У міру просування сценарію рядок Статус оновлюється:

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

Коли сценарій успішно завершиться, ви побачите наступне:

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

Це вказує на те, що будь-які пошкоджені вузли були відремонтовані, і сценарій не мав жодних проблем. Якщо отримані дані відрізняються від цього прикладу, зверніться до служби підтримки Dell і надайте вихідні дані та файли журналу з місця розташування пакета.