среда, 31 января 2018 г.

Ошибки при удалении multipath диска


В продолжение предыдущей статьи. Что происходит, когда произошла авария (или просто накосячили) и все пути для multipath устройства находятся в состоянии failed? Пример ниже:

# multipath -ll
mpathb (360a98000646e6c512f4a6f714f46324f) dm-6 NETAPP ,LUN
size=110G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 0:0:0:42 sdc 8:32 failed faulty running
| `- 1:0:2:42 sdad 65:208 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 0:0:2:42 sdl 8:176 failed faulty running
`- 1:0:1:42 sdw 65:96 failed faulty running

Удаление multipath устройства может закончиться ошибкой:

# multipath -f mpathb
Jan 29 13:42:58 | mpathb: map in use
Jan 29 13:42:58 | failed to remove multipath map mpathb

При этом утилиты просмотра дисков, такие как pvs, начинают зависать, в системе начинают появляться неубиваемые процессы в состоянии D - uninterruptible sleep. Все это, конечно же, очень печалит и ставит в тупик. Но, как говорится, даже если вас съели — то у вас все равно есть два пути. Этой беде тоже можно помочь.
Обратите внимание на опцию в конфигурации multipath диска - "queue_if_no_path" — дословно держать очередь, если нет активных путей. Опцию нужно убрать из конфигурации и затем нужно перечитать конфигурационный файл. После чего уйдут процессы в состоянии uninterruptible sleep, которые держат диск. 
Эта опция может отсутствовать в явном виде в конфигурационном файле, она часто встречается в дефолтной настройке даемона multipathd для различных схд. Убрать опцию queue_if_no_path на multipath диске можно следующим образом:

# dmsetup message mpathb 0 fail_if_no_path

После чего диск можно удалить:

# multipath -f mpathb