Лохматим СХД HPE 3PAR 7200. Часть 3. Избавляемся от чанклетов в состоянии "Failed"

HPE 3PAR 7200 - How to remove chunklets in "Failed" state without changing disks Продолжая ранее начатый квест по взбадриванию двух-контроллерной СХД HP 3PAR StoreServ 7200, напомню, что получена эта система в нашем случае была с небольшой частью дисковой ёмкости, которая была помечена как неисправная. В этой заметке мы поговорим о том, как выяснить то, к каким дисковым накопителям в СХД относится неисправная ёмкость и что в такой ситуации можно сделать.

Итак, при поверхностном осмотре состояния компонент СХД в консоли управления HP 3PAR Management Console было обнаружено 2GiB ёмкости в состоянии "Failed".

HP 3PAR Management Console - Failed Capacity

А насколько нам известно, в 3PAR OS 3.2/3.3 на самом нижнем уровне СХД оперирует физическими блоками (chanklets) размером 1GiB. Получается, что у нас есть 2 неисправных чанклета и нам в первую очередь потребуется выяснить, к каким дисковым накопителям относятся эти блоки. Для этого подключимся по SSH к СХД от имени учётной записи "3paradm" и выполним команду вывода информации о всех проблемных чанклетах:

3PAR02 cli% showpdch -fail

Pdid Chnk LdName LdCh State     Usage  Media Sp Cl From  To
   3  239   ----  ---  none available failed  N  N  --- ---
  12  296   ----  ---  none available failed  N  N  --- ---
-----------------------------------------------------------
Total chunklets: 2

Как видим, проблемные чанклеты физически находятся на дисках 3 и 12.

Теперь возникают резонные вопросы – насколько это опасно для данных и что делать с дисками, имеющими проблемные чанклеты?

Наличие некоторого количества неисправных чанклетов в 3PAR на самом деле не является для СХД какой-то критической проблемой и такие чанклеты попросту не будут использоваться для размещения данных. По некоторой неофициальной информации дисковый накопитель в актуальных версиях 3PAR OS будет считаться работоспособным, пока на нём не будет зафиксировано 10 неисправных чанклетов (или 6 чанклетов для более старых версий 3PAR OS). При превышении указанной границы диск помечается как неисправный и обязательно должен быть заменён.

Процедуру стандартной замены неисправного накопителя с помощью утилиты "servicemag" мы уже рассматривали ранее в заметке Вики IT-KB - Замена неисправного физического диска в СХД HP 3PAR 7200.

Можно предположить, что алгоритмы 3PAR OS помечают чанклет, как неисправный, в результате безуспешной попытки операций чтения/записи. Но что, если такая ошибка была вызвана не реальной проблемой носителя, а какой-то временной коллизией в работе микрокода контроллера накопителя/контроллеров дисковой корзины/контроллеров плат ввода-вывода или даже микрокода самой 3PAR OS? Вероятность этого может быть мала и не всегда очевидна, но всё же не стоит её сбрасывать со счетов.

Надо признать, что в нашем примере СХД не содержит полезных данных и после использования ёмкости ранее под одну задачу, мы готовим эту ёмкость под использование в другой задаче с полным перестроением CPG и Virtual Volumes. Поэтому, на данном этапе хочется дать двум дискам с единственным проблемным чанклетом "второй шанс", понимая при этом и то, что перспектива повторения ситуации с появлением битых чанков (если диски действительно "устали") вполне реальна.

Сложность этой затеи заключается в том, что разметка физической ёмкости накопителей на чанклеты штатным образом выполнятся лишь на этапе первичной инициализации СХД. И если в работающей системе на диске появился неисправный чанклет, то он будет болтаться на нём до логического завершения жизненного цикла диска в составе СХД. То есть, например, у нас не получится схитрить и обмануть 3PAR OS, просто выведя диск из работы и введя вновь в работу с помощью выше упомянутой утилиты "servicemag" (как при ранее упомянутой штатной замене диска). Это связано с тем, что СХД продолжает "помнить" об этом конкретном накопителе и при повторном вводе его в работу снова покажет на нём неисправный чанклет. Однако, если мы подумаем о том, как СХД вводит в работу новый накопитель (которого ранее ещё не было в системе), то становится очевидно, что на этапе ввода диска в работу происходит его форматирование и разбивка на "свежие" чанки. Получается, что для реализации нашей затеи нам просто нужно заставить 3PAR OS "забыть" о двух интересующих нас дисках.

Первое, что нам нужно сделать, – запретить СХД размещение данных на диске, который хотим полностью исключить из работы. Сначала сделаем это для первого диска с ID 3:

3PAR02 cli% setpd ldalloc off 3

Убеждаемся в том, что диск 3 перешёл в состояние "degraded" с признаком запрета размещения на нём данных:

3PAR02 cli% showpd -s 3

Id CagePos Type -State-- -------Detailed_State-------- -SedState--
 3 0:3:0  FC   degraded not_available_for_allocations not_capable
------------------------------------------------------------------
 1 total

Освобождаем все данные с диска 3, перенося их на другие доступные диски СХД с помощью команды "movepdtospare":

3PAR02 cli% movepdtospare -f -vacate -nowait 3

       Move -State- ----Detailed_State----
 3:526-18:0  normal ch_move_pending,normal
 3:527-18:1  normal ch_move_pending,normal
 3:528-19:2  normal ch_move_pending,normal
 3:535-18:3  normal ch_move_pending,normal
 3:536-18:4  normal ch_move_pending,normal
 3:537-18:5  normal ch_move_pending,normal
 3:538-18:6  normal ch_move_pending,normal
 3:539-18:7  normal ch_move_pending,normal
 3:540-18:8  normal ch_move_pending,normal
 3:541-18:9  normal ch_move_pending,normal
3:542-18:10  normal ch_move_pending,normal
3:543-18:11  normal ch_move_pending,normal
3:544-18:12  normal ch_move_pending,normal
3:545-18:13  normal ch_move_pending,normal

Процесс переноса данных чанклетов на другие накопители может занять некоторое время. Отследить текущий статус переноса данных можно командой:

3PAR02 cli% showpdch -mov

Pdid Chnk        LdName LdCh  State  Usage Media Sp Cl  From   To
   3  526      pdsld0.1    7 normal relsrc valid  N  N   --- 18:0
   3  527      pdsld0.1    1 normal relsrc valid  N  N   --- 18:1
   3  535 .srdata.usr.0   57 normal relsrc valid  N  N   --- 18:3
   3  536 .srdata.usr.0   51 normal relsrc valid  N  N   --- 18:4
   3  537 .srdata.usr.0   44 normal relsrc valid  N  N   --- 18:5
  18    0      pdsld0.1    7 normal reltgt valid  N  N 3:526  ---
  18    1      pdsld0.1    1 normal reltgt valid  N  N 3:527  ---
  18    3 .srdata.usr.0   57 normal reltgt valid  N  N 3:535  ---
  18    4 .srdata.usr.0   51 normal reltgt valid  N  N 3:536  ---
  18    5 .srdata.usr.0   44 normal reltgt valid  N  N 3:537  ---
-----------------------------------------------------------------
Total chunklets: 10

Как видим, в нашем примере на текущий момент времени выполняется перенос данных с диска 3 на диск 18. Повторяем последнюю команду, чтобы получать обновлённую информацию о статусе переноса и дожидаемся, когда перенос данных будет завершён полностью:

3PAR02 cli% showpdch -mov

No chunklet information available.

Данные с нашего 3 диска "уехали", теперь осталось исключить диск из пула размещения резервных чанклетов (Spare chunklets). Для начала проверим то, сколько на данный момент времени мы имеем на диске чанклетов, выступающих в роли резервных:

3PAR02 cli% showpdch -spr 3

Pdid Chnk LdName LdCh State       Usage Media Sp Cl From  To
   3  493   ----  ---  none unavailable valid  Y  Y  --- ---
   3  494   ----  ---  none unavailable valid  Y  Y  --- ---
   ... вывод усечён ....
   3  533   ----  ---  none unavailable valid  Y  Y  --- ---
   3  534   ----  ---  none unavailable valid  Y  Y  --- ---
------------------------------------------------------------
Total chunklets: 39

Как видим, на диске есть 39 резервных чанклетов. Удалим их командой "removespare". В этой команде после ID диска указывается ключ ":a", что означает директиву удаления всех spare-чанков:

3PAR02 cli% removespare 3:a

Are you sure you want to remove spares?
select q=quit y=yes n=no: y
39 spares removed

Проверяем результат и убеждаемся в том, что с точки зрения СХД диск теперь не содержит резервных чанклетов:

3PAR02 cli% showpdch -spr 3

No chunklet information available.

Ну и, наконец, с помощью команды "dismisspd" полностью выводим диск из работы:

3PAR02 cli% dismisspd 3

Перечисленными выше командами мы вывели диск с ID 3 из работы.

Теперь можно повторить всю туже последовательность команд для второго диска с ID 12:

3PAR02 cli% setpd ldalloc off 12
...
3PAR02 cli% movepdtospare -f -vacate -nowait 12
...
3PAR02 cli% removespare 12:a
...
3PAR02 cli% dismisspd 12

Только теперь мы можем спокойно извлечь диски из дисковой корзины с пониманием того, что СХД "забыла" про эти диски.

На данном этапе мы ещё можем одуматься и установить на место извлечённых дисков новые сменные диски Smile … Но если таких дисков нет и затея повторно использовать эти же диски ещё не оставила "воспалённый разум", то вставляем эти диски снова в корзину. При этом (если диски одинаковые по ёмкости и типу) даже можем поменять эти диски местами.

После установки дисков наблюдаем за событиями, которые появляются в логе СХД. Например, чтобы посмотреть логи за последние 20 минут, выполнима команду следующего вида:

3PAR02 cli% showeventlog -min 20 -oneline

...
Informational  Disk state change sw_pd:3    pd 3 wwn 5000C50017B90D45 changed state from new to valid because disk was admitted successfully.
Informational  Disk state change hw_disk:5000C50017B90D45 pd wwn 5000C50017B90D45 changed state from new to valid because disk was admitted successfully.
Informational  Object added    sw_pd:3    Physical Disk 3 added
Informational  Object added    hw_disk:5000C50017B90D45 Disk 5000C50017B90D45 added
...
Informational  Disk state change sw_pd:12   pd 12 wwn 5000C50017D0A54B changed state from new to valid because disk was admitted successfully.
Informational  Disk state change hw_disk:5000C50017D0A54B pd wwn 5000C50017D0A54B changed state from new to valid because disk was admitted successfully.
Informational  Object added    sw_pd:12   Physical Disk 12 added
Informational  Object added    hw_disk:5000C50017D0A54B Disk 5000C50017D0A54B added
...

Как видим, система приняла диски как новые, проверила их на совместимость по версии микрокода и через мгновенье поменяла их статус с new на valid. При этом диски автоматически включились в работу и запустился фоновый процесс переноса части данных с других рабочих дисков. Заглянем в консоль HP 3PAR Management Console и проверим результат.

HP 3PAR Management Console - Capacity View is Normal

Как видно, в нашем случае емкость двух чанклетов, ранее отнесённых к категории "Failed" перешла в категорию "Free".

В результате мы добились поставленной задачи и избавились от двух неисправных чанклетов, оставив при этом все ранее используемые диски в работе.

Добавить комментарий