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 (перечислеие на основе доступа к ресурсу) – по-русски позволяет видеть только те элементы, для которых у авторизованного пользователя есть доступ, а не все подряд на всем ресурсе – может быть полезно, например, для домашних директорий пользователей в одной “куче”

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

7 thoughts on “Solaris 11. Универсальный сервер хранения. Нюансы.”

  1. Доброго времени суток!
    Сначала о лиричном: смысл выражения “быстросуп” в сочетании с solaris однозначно в мемориз:-). Теперь о практичном: я недавно успешно “положил” домашний nas на opensolaris B134 методом удаления фс с записанными на нее дедуплицированными данными. Это баг, суть в том, что при описанных мною действиях происходит блокировка всего IO, описание надо читать отсюда: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390. NAS в таком случае пингуется, но только и всего. В моем случае (NAS CPU Intel Pentium E6300 + 4 Gb RAM), при удалении 250Гб все сервисы пребывали в анабиозе около 8 часов. У меня нет тестовой площадки, поэтому есть просьба: если есть возможность, посмотрите что происходит в аналогичной ситуации на Solaris 11 Express b151. Может там ядро поправили на предмет блокировок и сервисы просто деградируют вместо отказа? Для продакшена такой баг – просто полный ахтунг, нетапп ржет в полный голос:-)

    1. я читал Ваш комментарий, просто сейчас со временем небольшие напряги. Не хочу давать быстрые (и необдуманные) ответы, тем более – тестировать мне сейчас не на чем. Как только (до конца недели) найду площадку – отпишусь.

  2. @ Ilya Tyshchenko aka ilyxa
    Спасибо за внимание – но если с тестированием возникают такие сложности, то не стоит уделять этому время (с которым напряги). Я отказался от дедупликации – вылезли еще некоторые неприятные моменты, связанные как с конкретной реализацией данной технологии в zfs,  так и с моим железом (совсем не для solaris оно).

    1. да собственно говоря, у меня сейчас с тестированием на больших объемах проблемы.

      А какого рода проблемы (любопытно)?

  3. @ Ilya Tyshchenko aka ilyxa
    Проблема связанная непосредственно с архитектурой дедупликации, описанная на багзилле opensolaris – необходимость размещения ZDT (таблица дедупликации, в которой содержаться указатели на уникальные блоки фс, и указатели на дублирующиеся – если очень криво выражаться) на наиболее быстром носителе. Естественно, любая файловая операция, начинается с обращения к ZDT. С ростом размера фс и особенно количества данных в них, она разрастается до таких размеров, что не помещается в оперативке. И начинает переползать сначала в кеш второго уровня, а затем и в своп, которые расположены на медленном жестком диске. И получается так, что любое действие с любым большим объектом генерит такое количество обращений к дискам, что скорость падает до неприличных величин – оно ухитряется сама себя кешировать на харде. Я получил до 3-5 мб/сек на запись там, где без дедупликации было 35. Рецепты от этой болячки есть – много оперативки под arc, чтоб вся таблица ZDT помещалась в нем, не вызывая лишнего дергания дисков. Плюс, readzilla и writezilla на SSD – если совсем много данных в пуле. В случае с моим железом – 4 гига оперативки сдаются сразу, а покупать SSD в NAS я не планирую, дешевле купить пару 2х терабайтных дисков и избавиться от дедупликации вообще на достаточно длительный срок. Собственно, что я и сделал. Неприятные моменты – первое, любые файловые операции сильно замедляют сервер. Что вполне понятно и укладывается в рамки разумного. Второе хуже – в момент удаления одной из фс, у меня она сама фс удалилась, но данные остались в виде папки в абсолютно неуничтожимом виде. Предложенные операции, типа zpool export/import, переименование, изменение точек монтирования, scrub, ни к чему не привели. Любая попытка удалить папку, наталкивается на device busy. Гугл отказался предоставлять еще какие-либо быстрые варианты решения проблемы, а времени на самостоятельное исследование у меня сейчас нет. Вот так.

Leave a Reply