Skip to main content

Solaris 11. Универсальный сервер хранения. Нюансы II.

В продолжение раннего поста –  Solaris 11. Универсальный сервер хранения. Нюансы. – все никак не доходили руки написать.

Как верно было подмечено (см. комментарии по ссылке) – удаление ФС со включенной дедупликацией данных потенциально небезопасный процесс. Что и было подтверждено в результате производственного эксперимента. Было дано – старая V20Z на Оптеронах-248, 2 Гб памяти, два SCSI-диска (один для загрузки (rpool), другой выделенный для пула с данными). Сценарий для быстрого воспроизведения – создаем ФС (zfs create -o dedup=on -o recordsize=<ставим существенно меньше, чем 128к>storage/share).

Закидываем туда “настоящий” файл (/dev/zero – увы – не пройдет – у меня для теста были вполне себе настоящие файлы базы данных размерами всего-то по 4 гигабайта каждый) – любым удобным образом (NFS, CIFS, scp, etc). Удаляем FS (zfs destroy storage/share). Через 30 минут – zdb прекратил работать (I/O error – и точка). Через 1 час (напомню – там лежит 4 Гб данных!) – zfs/zpool команды не работают, через 1,5 часа – система пингуется, открытые ssh-сессии – “залипли”, новые сессии не открываются, консоль на движения не реагирует. Момент, когда это случилось – я (честно признаюсь) упустил. В одной из консолей был открыт vmstat 1, в другой – раз в минуту снимал состояние памяти (через mdb) – откровенного криминала не наблюдалось.

Мораль. Если планируется использовать ZFS+dedup где-то в (около)продуктивной среде – надо обязательно учесть возможные последствия при удалении ФС – для некоторых задач это НЕ критично (и я такие задачи нашел).

Мораль 2. Это надо проверить на Oracle Unified Storage 7000. Озадачился.

Мораль 3. Перезагрузка без физического отключения пула – не поможет (если что). При загрузке системы импорт пройдет автоматом, процесс продолжится без нашего участия. Феерично.

PS: шаги для быстрого воспроизведения проблемы – маловероятно, что в продуктиве будет такая конфигурация, но есть подтверждение о проблемах на нормально recordsize и конфигурации системы хранения:

zfs create -o dedup=on -o recordsize=512 storage/share
cp <amount of data greater than 2 gigs> /storage/share/
zfs destroy storage/share

В моем случае система повисла через полтора часа (Solaris 11, 2xAMD 248, 2GB RAM). На большем (правильном) блоке – объем данных нужно увеличить.

PPS: замечание “где это такой рекордсайз ты взял и это вообще не правильно!!!” – маленький хинт из man zfs:

The size specified must be a power of two  greater  than or equal to 512 and less than or equal to 128 Kbytes.

Более того – я вижу применение такого recordsize в задачах…