четверг, 18 июня 2009 г.

Состояние пула FAULTED (ZFS-8000-HC)

Хочу описать одно решение проблемы с ZFS-пулами, возникающей в некоторых ситуациях и пока не имеющей удовлетворительного воркэраунда, причем с ней приходится сталкиваться довольно часто.

У ZFS в текущей реализации есть одно свойство. В случае проблем с пулом, как то-серьезный сбой контроллера, грубые ошибки в аппаратной конфигурации, отключение ZIL-устройства или недоступность какой-либо компоненты пула, невозможность по какой-либо причине соединиться с LUN на iSCSI при размещении пула или его части на iSCSI-устройстве-иногда имеет место быть ситуация, когда пул продолжает генерировать ошибки после фиксации состояния FALUTED либо DEGRADED.

Последнее действие с ZFS, которое удается выполнить, обычно zpool status, который сообщает, что пул

state: FAULTED
status: One or more devices are faultd in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see:
http://www.sun.com/msg/ZFS-8000-HC

В этой ситуации любая попытка выполнить обращение к любой файловой системе ZFS приводит к deadlock - то есть, описанное в ссылке рекомендуемое действие - zpool clear - не помогает. Да и вообще любая ZFS-команда (даже не относящаяся к пострадавшему пулу) повисает немедленно, даже такая безобидная как zfs list.

Разумеется, ни разрушить пул, ни сделать что-либо еще так же невозможно.

"Документированный баг - это не баг, а фича" ;)

Вообще говоря, решение подобной проблемы действительно задокументировано, хотя и в несколько иной ситуации, вот здесь.

Собственно, проверенный на практике способ лечения основан именно на вышележащей ссылке.

Внимание. Хочу предостеречь - если на отказавшем пуле были данные, советую начать с поисков резервной копии или последнего снапшота. (снапшотов) Потому что решение нацелено на разблокирование ZFS, а не на спасение утопающих данных. Также обращаю внимание, что, если система содержит корневой ZFS-пул, то есть полностью находится на ZFS, то данное решение потенциально может привести систему в незагружаемое состояние и тогда будьте готовы к выполнению процедуры, описанной здесь.

Итак, восстанавливаем работоспособность системы:

1. Перезагружаемся по init 6. Убивать подвисшие процессы уже бессмысленно.
2. Сразу после запуска логинимся как root.
3. Выполняем cd /etc/zfs; rm zpool.cache
4. Снова перезагружаемся по init 6.
5. Импортируем пулы, которые не пострадали командой zpool import.

Готово. Теперь можно устранять проблемы и пересоздавать пострадавший пул и восстанавливать данные (если таковые были).

Замечание: На данном этапе импорт пулов пересоздаст удаленный/переименованный файл.

Замечание 2: Весьма трудно ухлопать систему с корневым ZFS-пулом. Если он исправен, то даже при полном удалении файла /etc/zfs/zpool.cache данный файл будет пересоздан при перезагрузке и корневой ZFS-пул вернется в онлайн а система загрузится - см. следующую статью.

Тогда если при восстановительных процедурах что-либо пойдет не так, то можно будет хотя бы восстановить конфигурацию пулов и позвать людей в чорном. ;)

Наиболее безобидна данная процедура при сбое в случае игрищ с блудницами пустыми пулами, когда шаловливые ручки заламывают пул до состояния непрерывной неработоспособности.

PS. Помните о смерти. О физическом бэкапе нужно вспоминать до, а не после попадалова. И вспоминать почаще. Только он может спасти гигантов мысли. Не то армейским способом можно потерять немало данных. Я предупредил.