вторник, 18 ноября 2008 г.

Новый друг лучше старых двух

Вышел новый релиз Солярис 10 - 10/08.

Вообще, этот год очень урожайный на релизы Solaris. Два релиза в году - означают либо очень много багов ;), либо новые возможности.

Итак, что в новом релизе революционного?

Самая, пожалуй, привлекательная новая возможность - установка ОС на ZFS и многочисленные усовершенствования самой ZFS и средств ее администрирования.

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

Слегка шокирует неприменимость fsck к файловым системам zfs (это просто непривычно для ОС вообще и для Solaris в частности), однако в целом впечатление самое благоприятное.

Можно даже рискнуть и посадить уже на ZFS все файловые системы. Если на машине есть 4 Гб оперативной памяти, то даже с достаточно тихоходными дисками SATA, система начинает работать так, будто дисковой системы почти нет.

Понятное дело, что по мере прогрева кэша файловой системы и заполнения его данными, расход оперативной памяти растет - однако ZFS резво освобождает память по запросам приложений.

Кстати, достаточно занятно наблюдать за расходованием оперативной памяти при помощи top (первое время, затем после выхода БД в стационарное состояние, заполнение памяти стабилизируется примерно на величине 7/8 и остается почти неизменным в дальнейшем с небольшими колебаниями).

Вот что показывает top на машине с 2мя процессорами SPARC-III и 4 Гб оперативной памяти при работающей БД Oracle, с запущеным листенером, OEM dbconsole, установленным компаньоном и веб-сервером Apache:

root@athena /# top

last pid: 17797; load avg: 0.04, 0.07, 0.14; up 2+20:57:03 15:56:21
84 processes: 83 sleeping, 1 on cpu
CPU states: 99.0% idle, 0.3% user, 0.7% kernel, 0.0% iowait, 0.0% swap
Memory: 4096M phys mem, 158M free mem, 8193M total swap, 8190M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
20943 root 1 59 0 4544K 2616K cpu/1 3:40 0.13% top
9430 oracle 1 59 0 1339M 1317M sleep 0:17 0.05% oracle
21679 oracle 1 59 0 1337M 1308M sleep 1:11 0.04% oracle
9405 oracle 37 29 10 272M 164M sleep 11:11 0.04% java
21681 oracle 1 59 0 1336M 1314M sleep 0:15 0.03% oracle
21663 oracle 1 59 0 1333M 1303M sleep 0:52 0.03% oracle
21673 oracle 17 59 0 1336M 1306M sleep 2:35 0.03% oracle
9702 oracle 7 59 0 34M 19M sleep 0:21 0.02% emagent
21683 oracle 1 59 0 1332M 1302M sleep 1:03 0.01% oracle
244 root 12 59 0 158M 4544K sleep 0:59 0.01% java
9723 oracle 1 59 0 1336M 1314M sleep 0:03 0.01% oracle
140 root 7 59 0 4752K 2672K sleep 0:25 0.01% picld
21671 oracle 16 59 0 1346M 1305M sleep 3:26 0.00% oracle
9428 oracle 1 59 0 1335M 1313M sleep 0:04 0.00% oracle
403 root 1 100 -20 3000K 1088K sleep 0:26 0.00% xntpd

Свободной памяти, как следует из приведенного скриншота, практически нет. Однако и подкачка как таковая заключается в 3 Мб за последние сутки. При этом и сама БД, и OEM ворочаются на удивление резво. Даже если учесть тот факт, что на указанной машине они и так не тормозили (на данной машине использованы достаточно веселые жесткие диски SAS 10K, которых 4 штуки).

На пулах ZFS, причем, находится только БД, полностью ПО Oracle и объектные библиотеки Native Compilation.

Хотя объем самой базы достаточно мал (это все-таки не боевая продуктивная система с терабайтами и терабайтами данных), все же реакция базы достаточно веселая, а OEM практически реагирует молниеносно.

Хотя выглядит это достаточно необычно (чтобы не сказать больше ;)). Оперативная память загружена, однако процессоры практически холодные, а выраженная подкачка отсутствует - и тем не менее все работает и работает быстро.

Однако вылезло и несколько неприятных моментов - собственно, с самим Солярисом.

Первый момент - никаким усилиями не удалось выполнить JumpStart upgrade с версии 5/08 (при настроенной конфигурации для той же машины, причем предыдущий апгрейд с 8/07 до 5/08 был выполнено полностью hands-off и без единой проблемы). Обычные апгрейды были выполнены без единой заминки на четырех машинах (SPARC и x64), а вот Custom JumpStart обломался. В то же время, нулевая установка при помощи JS (в вариантах с установкой ZFS root pool и на UFS) проходит отлично.

С одним замечанием. В некоторых случаях sun_install не может определить из BIOS (на платформе X64) какой из дисков является загрузочным, а в конце установки не выполняет автоматическую перезагрузку и надо руками выполнять init 6 (хотя я грешу на конфигурацию Custom JumpStart).

Второй момент. Sun добавил поддежрку новых механизмов хэширования паролей (по FIPS):

#
# Copyright 2008 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)crypt.conf 1.2 08/05/14 SMI"
#
# The algorithm name __unix__ is reserved.

1 crypt_bsdmd5.so.1
2a crypt_bsdbf.so.1
md5 crypt_sunmd5.so.1
5 crypt_sha256.so.1
6 crypt_sha512.so.1

Однако, при выборе любого из них как дефолтного и смены пароля утилитой passwd вход пользователем, для которого осуществлялось перешифрование (которе делалось абсолютно честно, что проверялось командой cat /etc/shadow), становился принципиально невозможным. Правильный пароль не принимался. Работают эти механизмы или нет в текущих релизах ядра 10/08 - неизвестно. Информации в Интернете на тему этих двух типов хэширования в продуктивном Солярисе 10/08 на момент написания статьи найти не удалось.

Третий момент. Совершенно непонятно, какой логикой руководствуется инсталлятор, разбивая и распределяя пространство на ZFS root pool. Результаты работы df -h неочевидны. Посему достаточно непонятно, как это самое пространство будет использоваться при реальной эксплуатации и что делать с канонической догмой системного администрирования UNIX - все системные слайсы раздельно.

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

Компрессирование данных ZFS, конечно, круто - но достаточно непрактично, примерно как метровый член. :) (подобного функционала все наелись еще во времена Stacker/DrvSpace/DoubleSpace).

Основной закон сохранения IT гласит - "Либо экономятся ресурсы - либо обеспечивается высокая скорость. Обе этих цели одновременно принципиально недостижимы".

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

Стабильность нового релиза пока не вызывает нареканий, правда, и живет он всего ничего :)

Да будет его жизнь долгой и счастливой.

Аминь.

Enter.

PS. Пожалуй, все же дьявольски не хватает приличного инструмента (более приличного, нежели Live Upgrade) для миграции файловых систем с UFS на ZFS. Не всегда имеется в наличии еще один жесткий диск для означенной процедуры.