Вики IT-KB

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== Замена неисправного физического диска в СХД HP 3PAR 7200  =====

{{:hewlett-packard:pasted:20180314-121012.png }} Подозреваю, что в штатной обстановке СХД **HP 3PAR 7200** должна автоматически перестраивать свой дисковый массив после физической замены диска в состоянии **failed** на новый диск. Но в некоторых случаях, спровоцированных самим администратором, обслуживающим СХД, может получиться так, что такое перестроение не отработает корректно. В таком случае потребуется выполнить ряд манипуляций по ручному выведению неисправного диска в **Offline** с последующим подключением нового диска. Здесь описан пример такой процедуры.

Подключаемся к СХД **HP 3PAR 7200** по протоколу **SSH**, используя для аутентификации учётную запись **3paradm**

Получаем список неисправных дисков:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% showpd -failed -degraded</br><font style="color:#B2B2B2;">
                             -Size(MB)-- ----Ports----
Id CagePos Type RPM State     Total Free A      B      Capacity(GB)
31 1:7:0?  FC    15 failed   278528    0 1:0:2  0:0:2*          300
-------------------------------------------------------------------
 1 total                     278528    0
</font></pre></HTML>

В данном случае мы видим, что неисправен диск с идентификатором **Id** ''31'' и размещением: дисковая полка ''1'', диск ''7'' (то есть восьмой дисковый слот в полке, так как отсчёт дисков в полке начинается с **0**)

 
Убеждаемся в том, что не выполняется никаких сервисных операций:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">cli% servicemag status</br><font style="color:#B2B2B2;">
No servicemag operations logged.</font></pre></HTML>

Запускаем режим обслуживания диска с идентификатором ''31'' (на вопрос о запуске **servicemag** отвечаем утвердительно):

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag start -pdid 31</br><font style="color:#B2B2B2;">
Are you sure you want to run servicemag?
select q=quit y=yes n=no: y
servicemag start -pdid 31
... servicing disks in mag: 1 7
...      normal disks:  
...  not normal disks:  WWN [5000C5004F9F9E1C] Id [31]  diskpos [0]

The servicemag start operation will continue in the background.
</font></pre></HTML>

Операция перевода диска в **Offline** будет запущена в фоновом режиме.
Чтобы посмотреть текущий статус операции выполним:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</br><font style="color:#B2B2B2;">
Cage 1, magazine 7:
The magazine is being brought offline due to a servicemag start.
The last status update was at Tue Mar 13 15:58:23 2018.
Chunklets relocated: 3 in 55 seconds
Chunklets remaining: 240
Chunklets marked for moving: 240
Estimated time for relocation completion based on 18 seconds per chunklet is: 
1 hours, 12 minutes and 0 seconds
servicemag start -pdid 31 -- is in Progress
</font></pre></HTML>

Здесь мы увидим примерное рассчётное время до завершения операции. Дожидаемся пока операция не завершится.

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</br><font style="color:#B2B2B2;">
Cage 1, magazine 7:
The magazine was successfully brought offline by a servicemag start command.
The command completed at Tue Mar 13 17:04:16 2018.
servicemag start -pdid 31 -- Succeeded
</font></pre></HTML>

Видим, что команда перевода проблемного диска в Offline выполнена успешно и завершена в нашем примере в ''17:04:16''.  

Теперь давайте посмотрим то, как изменился статус диска (**servicing** - насколько я понимаю, признак того, что диск выведен в обслуживание):

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% showpd -s 31</br><font style="color:#B2B2B2;">
Id CagePos Type -State- -Detailed_State--
31 1:7:0   FC   failed  vacated,invalid_media,smart_threshold_exceeded,servicing
-----------------------------------------------------
 1 total
</font></pre></HTML>

На данном этапе физически извлекаем неисправный диск из СХД и устанавливаем новый сменный диск.

После того, как сменный диск установлен, современные версии 3PAR OS могут в автоматическом режиме запустить процедуру вывода дискового слота из обслуживания и ввода нового диска в работу. Подождав 2-3 минуты после установки диска, проверим, не запустился ли этот процесс:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</pre></HTML>

Если процесс на запустился автоматически, вызываем процедуру вывода дискового слота из обслуживания, указав номер полки и номер слота в полке.  
При этом автоматически запустится процедура восстановления диска в массиве.

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag resume 1 7</br><font style="color:#B2B2B2;">
Are you sure you want to run servicemag?
select q=quit y=yes n=no: y
Failed --
Cage 1 mag 7 'servicemag resume' was started 
since Tue Mar 13 17:03:56 2018 or it has been interrupted.  
Please run 'servicemag status -d' for further details
servicemag resume 1 7 -- Failed
Command failed
</font></pre></HTML> 

В некоторых случаях, как в моём примере, на данном шаге может возникнуть ошибка, однако при этом процедура восстановления всё же запустится. Подтверждение информации о том, что утилита **servicemag** не всегда ведёт себя адекватно можно найти и в других источниках, например в статье [[http://www.regmen.com/hp-3par-disk-replacement/|Storage Exploration - HP 3PAR disk replacement]].  

Проверить статус запущенной нами задачи можно ранее упомянутой командой (причём лучше делать это не сразу, а через несколько минут, так как планируемое время выполнения операции начинает отображаться не сразу):

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</br><font style="color:#B2B2B2;">
Cage 1, magazine 7:
The magazine is being brought online due to a servicemag resume.
The last status update was at Tue Mar 13 17:16:00 2018.
Chunklets relocated: 6 in 1 minutes and 59 seconds
Chunklets remaining: 711
Chunklets marked for moving: 711
Estimated time for relocation completion based on 19 seconds per chunklet is: 
3 hours, 45 minutes and 9 seconds
servicemag resume 1 7 -- is in Progress
</font></pre></HTML>

Дожидаясь завершения процесса выполнения, посмотрим как изменился статус диска:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% showpd -failed -degraded</br><font style="color:#B2B2B2;">
                             -Size(MB)-- ----Ports----
Id CagePos Type RPM State     Total Free A      B      Capacity(GB)
48 1:7:0?  FC    15 degraded 278528    0 -----  -----           300
-------------------------------------------------------------------
 1 total                     278528    0
</font></pre></HTML>


Обратите внимание на то, что новый диск имеет **Id** отличный от того, с каким был старый диск (''48'' вместо ''31'') 
То есть при установке ранее неизвестного СХД диска идентификатор **Id** присваивается следующий по счётчику с учётом всех имеющихся в СХД дисков.

Дожидаемся завершения процедуры восстановления... 

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</br><font style="color:#B2B2B2;">
Cage 1, magazine 7:
The magazine is being brought online due to a servicemag resume.
The last status update was at Tue Mar 13 17:16:00 2018.
Chunklet relocations have completed 243 in 56 minutes and 24 seconds
servicemag resume 1 7 -- is in Progress
</font></pre></HTML>

...до тех пор, пока задание восстановления не завершится и не перестанет отображаться в статусе **servicemag**:

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% servicemag status</br><font style="color:#B2B2B2;">
No servicemag operations logged.
</font></pre></HTML>

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

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% showpd -failed -degraded</br><font style="color:#B2B2B2;">
No PDs listed
</font></pre></HTML>

А также убедимся в том, что новый диск, который имел идентификатор ''48'', теперь изменил свой идентификатор на ''31'', то есть "встал на своё место": 

<HTML><pre style="background:#5a5a62;color:#ffffff;padding:10px;border:0px;">% showpd -s 31</br><font style="color:#B2B2B2;">
Id CagePos Type -State- -Detailed_State- -SedState--
31 1:7:0   FC   normal  normal           not_capable
----------------------------------------------------
 1 total
</font></pre></HTML>

В завершении хочу обратить Ваше внимание на то, что выполнять подобные процедуры на СХД, имеющей контракт технической поддержки нежелательно, а лучше всё-же доверить эту работу специально обученным гражданам из HPE. Как говорится, на Ваш страх и риск :) 

----

Дополнительные источники информации:

  * [[http://www.regmen.com/hp-3par-disk-replacement/|Storage Exploration - HP 3PAR disk replacement]]
  * [[https://kadirsert.blogspot.ru/2017/09/replacing-failed-physical-disk-with-new.html|Replacing a Failed Physical Disk with New One on HP 3PAR Storage]]

----
Проверено на следующих конфигурациях:
^ Версия 3PAR OS ^
| 3.2.2 (MU3) |

----
{{:user:blogroot.png?50&nolink |}} Автор первичной редакции:\\ [[user:blogroot|Алексей Максимов]] \\ Время публикации: 14.03.2018 11:07
{{tag>HP HPE 3PAR  "3PAR 7200" Storage}}
~~DISCUSSION~~