Archive

Posts Tagged ‘Error 2140’

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 в задачах…

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

Итак, все-таки пришлось отказаться от приготовления “быстросупа” в пользу более детальных вещей ;)

Возник ряд проблем:
- все описанные действия проивзодятся от имени пользователя root
- иногда (собственно, легко воспроизводимо, если на сервере более одного ресурса) возникает ошибка:
Screen shot 2011-02-02 at 12.53.08.png

“Лечение” – либо перезапуск сервера (svcadm restart svc:/network/smb/server:default) – на мой взгляд малореально на работающем сервере, либо – настройка полномочий иным образом:

Проблем – добавит, но и избавит от необходимости перезапускать сервер каждый раз после добавления ресурса. После нажатия на кнопку ОК ошибка все равно всплывет – но права применятся.
- ресурс для SMB сервера на zfs лучше всего создавать такой командой – zfs create -o casesensitivity=mixed -o nbmand=on -o sharesmb=name=test2,guestok=true,abe=true -o compression=on -o dedup=on storage1/test2, где есть ряд важных ньюансов (dedup & compression – опускаем):
nbmand=on – неблокирующая принудительная блокировка (помогите подобрать аналог из мира smb.conf)
casesensitivity=mixed – по умолчанию, ФС в Юниксе чуйствительна в регистру – специально для SMB Server предусмотрена опция mixed, ее надо указать ТОЛЬКО при создании ФС
sharesmb=…,guestok=true… – опция sharemgr, позволяет получить доступ гостю (Guest) к этому ресурсу
sharesmb=…abe=true – опция sharemgr, дословно Access-Based Enumeration for a Share (перечислеие на основе доступа к ресурсу) – по-русски позволяет видеть только те элементы, для которых у авторизованного пользователя есть доступ, а не все подряд на всем ресурсе – может быть полезно, например, для домашних директорий пользователей в одной “куче”

Если-таки доберетесь до тестов на “живой” площадке – советую начать читать отсюда, и дойти до вот этого места ;)