Nest Org Ru Team Site

Кратенько. Летим неделю. Полет – нормальный. Из приятных бонусов отмечена работа VSS (Volume Shadow Copy). SMB Server исправно живет и вроде как не “доставляет” клиенту. Из неприятных не-бонусов – проблема с подключением системы хранения к ESX (пулы теряются после перезагрузки). Пока не разобрался – это “грабли” самого ESX (надо все-таки генерировать новую сигнатуру для каждой vmfs3?), или же это проблемы COMSTAR? Storage Unit’ы остаются на прежнем месте, LUN’ы местами не меняются – короче, странно. Ожидаю озарения. И надо наконец дорисовать шпаргалку по COMSTAR – вяло выгляжу, когда непрерывно ползаю по манам, в попытке сообразить, где же я ЭТО (то или иное) видел?

Вообще ESX я как-то мастерски обходил стороной – есть вот повод плотно почитать, что он из себя представляет с точки зрения систем хранения.

Пока до реализации планов испробовать Oracle 11 на Oracle Solaris 11 (забавные получаются каламбурчики) не добрался – но уже на подходе. Про тесты Sun Ray Software писать нечего – все по старому – с инсталляцией проблемы, киоски работают криво. В целом – пригодно для работы. Но пока Oracle не выкатит официальный документ Installation Guide for Solaris (11) и в Release Notes не появится заветная надпись – только голый энтузиазм.

Все давно хотел пустить в работу Solaris 11 + COMSTAR + CIFS w/ AD, да еще и под рабочей нагрузкой, да еще и с данными – особо никому не надо было…

Праздник-таки настал. Наконец-то удалось провести практическое внедрение Solaris 11 – фаза один – переезд – выполнен. Конфигурация – Sun Fire X4500, 48x750GB SATA, собранных в большой RAIDZ2, 16 Gb RAM. Подключен (был) через аггрегацию (4-х портов). Стояла свежая Solaris 10 9/10. Было настроено 4 LUN (zvol), подключенные к ESX 4.1 через комплектный iSCSI Target – медленный, постоянно отваливающийся – короче, почти не рабочая связка. Также – была установлена samba (из комплекта ОС) – порядка 2 Тб данных розданны по smb/cifs с авторизацией в домене – масса маленьких файлов.

В результате – переставили Solaris (теперь Oracle Solaris 11 2010.09 beta, кое-какие обновления), избавились от горячо нелюбимой мной аггрегации на линках iSCSI (оставив ее там, где она нужна – на сети с CIFS сервером), переехали на Oracle SMB Server (что доставило, потому как с правами будут еще долго возиться). ESX теперь “смотрит” на Solaris через COMSTAR. Сегодня на меня почти снизошло озарение, как он должен правильно быть настроен – через неделю озарение опять потеряется – и прийдется “курить” man’ы. В ближайшее время – тестируемся под пользовательской нагрузкой (десяток-другой виртуальных машин, десяток-другой пользователей на “шаре” smb). Фаза два, вроде как.

Что сильно напрягло – ну конечно ESX… Не понимаю я жизнерадостного увлечения им, и не занимался я им никогда. Не стало неожиданностью, что хоть LUN’ы с его vmfs3 и изменили свое назначение на изменившимся же iqn таргета – я все-таки ожидал, что удасться обойтись без проблем – ситуация описанная в мануале – но кто же знал, что vCenter настолько кривой.

Фаза три – зеркалим рутовый пул, обновляем версию продуктивного пула – радуемся.

Фаза четыре – “чешется” попробовать COMSTAR с FC в продуктиве. Ждем, это в ближайших планах.

В продолжение раннего поста –  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 в задачах…

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

Возник ряд проблем:
- все описанные действия проивзодятся от имени пользователя root
- иногда (собственно, легко воспроизводимо, если на сервере более одного ресурса) возникает ошибка:

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

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