вторник, 30 июня 2009 г.

SMF и Method "stop" exited with status 208

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

При разработке сервисов SMF, в частности, при написании управляющих методов (скриптов) и сервисных манифестов нас подстерегает одна маленькая, но довольно неприятная проблема.

Речь идет, в частности, о поведении самописных SMF-сервисов при остановке/рестарте/перезагрузке - они без видимых причин выпадают по таймауту с ошибкой, приведенной в заголовке статьи: "Method "stop" exited with status 208".

С чем это связано и почему так?

Первое столкновение произошло при модификации SMF-сервиса Nessus 3.2.1 (существует версия для Solaris и SMF в ней написан не слишком аккуратно - его пришлось править, но это отдельная история). Сервис некорректно уходил в состояние maintenance при остановке.

Вскрытие показало следующее - в журнале сервиса было вот такое сообщение:

[ May 22 18:27:51 Executing stop method ("/etc/init.d/nessusd stop") ]
[ May 22 18:27:51 Method "stop" exited with status 208 ]

При этом запуск сервиса выполняется совершенно нормально:

[ May 22 21:08:21 Executing start method ("/etc/init.d/nessusd start") ]
[ May 22 21:08:21 Method "start" exited with status 0 ]

Простейший поиск в Гугле привел к следующим результатам:

Результат 1
Результат 2
Результат 3

Наиболее внятно описывает проблему первый результат, если оставить в покое воду и перейти к сути - управляющий метод, в случае, когда сервис достаточно просто убить, не должен этого делать явно. Это должно быть описано в сервисном манифесте. Ну что же, открываем смотрим:

Метод:

stop_proc ()
{
# Stop nessus daemon
pkill nessusd
}

.....

'stop')
# This condition never occurs, because of daemon has not pid-file.
#test -f /opt/nessus/var/nessus/nessusd.pid && kill `cat /opt/nessus/var/nessus/nessusd.pid`
stop_proc
;;

Сервисный манифест (символы тэгов не показаны):

exec_method
type='method'
name='stop'
exec='/etc/init.d/nessusd %m'
timeout_seconds='60'

exec_method
type='method'
name='restart'
exec='/etc/init.d/nessusd %m'
timeout_seconds='60'

Итак, при остановке у нас вызывается функция stop_proc (), использующая pkill. Она-то и не нравится SMF. Причем что интересно - прямое выполнение скрипта (не из SMF) выполняет и запуск, и останов и рестарт - корректно. Даже если усилить нажим и написать pkill -KILL nessusd. Однако, при вызове скрипта из SMF в последнем случае вываливается чертовски непонятное сообщение:

[ May 22 21:16:37 Executing stop method ("/etc/init.d/nessusd stop") ]
[ May 22 21:16:37 Method "stop" failed due to signal KILL ]

Хотя уже все понятно. Pkill возвращает код возврата:

The following exit values are returned:
0 One or more processes were matched.
1 No processes were matched.
2 Invalid command line options were specified.
3 A fatal error occurred.

однако SMF его игнорирует, в последнем случае он ловит сообщение Killed от pkill и тоже не считает его корректным завершением команды.

Всякие игры около подпрограммы остановки процесса, наподобие:

(ужасный кусок извращения)

pkill nessusd>/dev/null 2>&1
retcode=`$ECHO $?`
case "$retcode" in
0) exit 0;;
*) exit 1;;
esac

(другой кусок, не лучше)

[ `pkill nessusd` ] && exit 0

или, тем более, попытки вывести выполнение скрипта на финализирующий exit 0 (хотя данный кусок не показан - уверяю вас, скрипт в оригинале завершается именно командой exit 0) - никакого заметного воздействия, разумеется, не возымели.

Что ж, воспоследуем совету, найденному на вершине поиска Гугл и просто слегка подправим сервисный манифест:

exec_method
type='method'
name='stop'
exec=':kill'
timeout_seconds='60'

Только в этом месте и только вызов метода exec (сам код скрипта мы вообще никак не модифицируем). Что сие означает? Означает это, что для остановки сервиса (который мы так и так убиваем) мы вызываем нативный метод SMF :kill.

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

Проверяем остановку сервиса:

[ Jun 29 17:25:43 Executing stop method (:kill) ]
[ Jun 29 17:25:47 Method "stop" exited with status 0 ]

Все отлично, и остановка и перезапуск сервиса работает гладко:

[ Jun 29 17:49:41 Stopping because service restarting. ]
[ Jun 29 17:49:41 Executing stop method (:kill) ]
[ Jun 29 17:49:41 Executing start method ("/etc/init.d/nessusd start") ]
[ Jun 29 17:49:41 Method "start" exited with status 0 ]

Вот и все решение проблемы.

Как говорится, "Фигово, когда много знаешь" или "Keep it simple, stoopid"! ;)

PS. Хотя это может показаться самоочевидным, тем не менее подчеркну - логи (не обязательно сервисов SMF) - весьма полезная вещь при анализе проблем, не стоит ограничиваться лишь диагностическими сообщениями svcs -xv, как делают многие.

пятница, 19 июня 2009 г.

Легко ли угробить систему на ZFS root pool?

В предыдущей статье встал вопрос, что как-то страшновато зачищать zpool.cache при наличии ZFS root pool в системе, и, по логике, надо лечить систему с полетевшим ZFS-пулом полной брутальной переустановкой, как развлекаются окошечники (у них много свободного времени, хи-хи ;)).

Развлекаться так развлекаться. Игрища и блудницы в нашем полном распоряжении, повеселимся, дык!

Проведем эксперимент экспериментов и попробуем шаловливыми ручонками ушатать систему на ZFS root pool и с еще одним пулом ZFS на втором диске до полной гибели. ;)

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

Обстряпаем мы это так.

1. Установим систему с двумя пулами на двух дисках.
2. Вынесем на живой системе с двумя пулами zpool.cache полностью. Не будем убивать пулы - просто имитируем ситуацию отказа некорневого пула, когда нужно удалять кэш-файл.
3. Перезагрузимся.
4. Посмотрим, что произойдет.

Итак, начали!

server4# cd /etc/zfs
server4# ls -al
total 24
drwxr-xr-x 2 root sys 3 Oct 27 04:28 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
-rw-r--r-- 1 root root 1040 Oct 27 04:28 zpool.cache
server4# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors
server4# zpool create -f data c0t0d0s0
server4# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors

Мы на исходной позиции. Система стоит на ZFS-руте полностью, на втором диске у нас пул DATA, который в онлайне и смонтирован. Кэш-файл содержит, соответственно, ссылки на оба пула.

Производим вынос тела:

server4# cd /etc/zfs
server4# ls -al
total 26
drwxr-xr-x 2 root sys 3 Oct 27 04:36 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
-rw-r--r-- 1 root root 2052 Oct 27 04:36 zpool.cache
server4# rm *
server4# ls -al
total 20
drwxr-xr-x 2 root sys 2 Oct 27 04:37 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
server4# init 6

После непродолжительной гражданской панихиды тело было предано земле:

server4# svc.startd: The system is coming down. Please wait.
svc.startd: 90 system services are now being stopped.
svc.startd: The system is down.
syncing file systems... done
rebooting...

SC Alert: Host System has Reset
Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present. Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses


Sun Fire V215, No Keyboard
Copyright 2008 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.0.a, 1024 MB memory installed, Serial #78457024.
Ethernet address 0:14:4f:ad:28:c0, Host ID: 84ad28c0.



Rebooting with command: boot
Boot device: /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@1,0:a File and args:
SunOS Release 5.10 Version Generic_137137-09 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hardware watchdog enabled
Hostname: server4
Reading ZFS config: done.
Mounting ZFS filesystems: (3/3)

server4 console login: root
Password:
Last login: Fri Oct 27 04:32:36 on console
Oct 27 04:39:59 server4 login: ROOT LOGIN /dev/console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA300-S10_B.2 on server4
server4# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors

"Дык, ети ж твою за ногу!" - сказали мужики. Корневой пул жив, мало того, он исправен и сам вернул себя взад! А второго пула нет. Окей, вернем его обратно?

server4# zpool import data
server4# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors
server4#

Ха. "Он завелся!"*

Don't panic, мальчики и девочки. Убить систему, стоящую на корневом пуле ZFS не трудно - а очень трудно.
____________________________________
* Крик молодого Анакина Скайуокера в фильме "Звездные Войны I эпизод: Скрытая угроза", когда он смог-таки завести двигатели своего кара.

четверг, 18 июня 2009 г.

Состояние пула FAULTED (ZFS-8000-HC)

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

У ZFS в текущей реализации есть одно свойство. В случае проблем с пулом, как то-серьезный сбой контроллера, грубые ошибки в аппаратной конфигурации, отключение ZIL-устройства или недоступность какой-либо компоненты пула, невозможность по какой-либо причине соединиться с LUN на iSCSI при размещении пула или его части на iSCSI-устройстве-иногда имеет место быть ситуация, когда пул продолжает генерировать ошибки после фиксации состояния FALUTED либо DEGRADED.

Последнее действие с ZFS, которое удается выполнить, обычно zpool status, который сообщает, что пул

state: FAULTED
status: One or more devices are faultd in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see:
http://www.sun.com/msg/ZFS-8000-HC

В этой ситуации любая попытка выполнить обращение к любой файловой системе ZFS приводит к deadlock - то есть, описанное в ссылке рекомендуемое действие - zpool clear - не помогает. Да и вообще любая ZFS-команда (даже не относящаяся к пострадавшему пулу) повисает немедленно, даже такая безобидная как zfs list.

Разумеется, ни разрушить пул, ни сделать что-либо еще так же невозможно.

"Документированный баг - это не баг, а фича" ;)

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

Собственно, проверенный на практике способ лечения основан именно на вышележащей ссылке.

Внимание. Хочу предостеречь - если на отказавшем пуле были данные, советую начать с поисков резервной копии или последнего снапшота. (снапшотов) Потому что решение нацелено на разблокирование ZFS, а не на спасение утопающих данных. Также обращаю внимание, что, если система содержит корневой ZFS-пул, то есть полностью находится на ZFS, то данное решение потенциально может привести систему в незагружаемое состояние и тогда будьте готовы к выполнению процедуры, описанной здесь.

Итак, восстанавливаем работоспособность системы:

1. Перезагружаемся по init 6. Убивать подвисшие процессы уже бессмысленно.
2. Сразу после запуска логинимся как root.
3. Выполняем cd /etc/zfs; rm zpool.cache
4. Снова перезагружаемся по init 6.
5. Импортируем пулы, которые не пострадали командой zpool import.

Готово. Теперь можно устранять проблемы и пересоздавать пострадавший пул и восстанавливать данные (если таковые были).

Замечание: На данном этапе импорт пулов пересоздаст удаленный/переименованный файл.

Замечание 2: Весьма трудно ухлопать систему с корневым ZFS-пулом. Если он исправен, то даже при полном удалении файла /etc/zfs/zpool.cache данный файл будет пересоздан при перезагрузке и корневой ZFS-пул вернется в онлайн а система загрузится - см. следующую статью.

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

Наиболее безобидна данная процедура при сбое в случае игрищ с блудницами пустыми пулами, когда шаловливые ручки заламывают пул до состояния непрерывной неработоспособности.

PS. Помните о смерти. О физическом бэкапе нужно вспоминать до, а не после попадалова. И вспоминать почаще. Только он может спасти гигантов мысли. Не то армейским способом можно потерять немало данных. Я предупредил.

понедельник, 15 июня 2009 г.

ZIL на RAM-диске и скорость, Часть I

"Здравствуйте, джентльмены, здравствуйте, мои дорогие! Что-то вы плохо выглядите, давайте-ка я вас осмотрю!" *

В одной из прошлых статей я собирался рассказать об одном занятном эксперименте, который планировал.

Ну, в общем, первый результат уже есть. Он еще сырой и не претендует на полноту и глубину, но некоторые предварительные проработки были сделаны.

Как сказано в Писании, если читать глубоко и внимательно - если положить ZIL (ZFS Intent Log) файловой системы ZFS на быстродействующее устройство, то можно ощутимо ускорить операции записи.

Поскольку быстрее памяти диска нет, идея заключается в том, чтобы попытаться положить ZIL на RAM-диск и посмотреть, стоит ли овчинка выделки.

Давайте посмотрим, как это выглядит.

Итак, я взял игрушечную машинку, SunFire v215, об одном процессоре SPARC-IIIi, одном гигабайте RAM, и двух одинаковых дисках SAS 10K по 73 Гб. Установил на нее Solaris 10 5/09 JumpStart'ом на UFS на второй диск, и, после минимизации (дабы легче летелось и чтобы освободить оперативную память), установил на нее уже написанный SMF-сервис RAM-диска.

Предварительно опытным путем был определен максимальный размер RAM-диска на данной системе - он составил 190 Мб.

Мда, не густо. Ну, у нас и на руках-то всего 1 Гб RAM. Жаловаться грех, а поиграться хватит.

Нам нужно устройство без файловой системы, без бэкапа (пока) и восстановления данных (нам пофигу на данный момент целостность лога), посему делаем необходимые изменения в управляющем методе, согласно readme, и приступаем к установке сервиса:

server5# ./ramdisk_smf_inst.sh
-------------------------------------------
- Ramdisk SMF service will be install now -
- ... -
-------------------------------------------

Copying Ramdisk SMF files...
*** XML service descriptor validation successful
*** XML service descriptor import successful
Verify Ramdisk SMF installation...
STATE STIME FMRI
disabled 19:04:35 svc:/system/ramdisk:default
If Ramdisk services installed correctly, enable and start it now
server5# svcadm enable ramdisk
server5# svcs ramdisk
STATE STIME FMRI
online 19:04:41 svc:/system/ramdisk:default

Порядок. Проверяем наличие RAM-диска:

server5# ramdiskadm
Block Device Size Removable
/dev/ramdisk/root 167116800 No
/dev/ramdisk/ramdisk1

Присутствует.

Теперь создадим ZFS-пул на первом (свободном) диске:

server5# zpool create -f data c0t0d0s0 log /dev/ramdisk/ramdisk1
server5# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0
logs ONLINE 0 0 0
/dev/ramdisk/ramdisk1 ONLINE 0 0 0

errors: No known data errors

Обратите внимание, что на корне системы (c0t1d0s0) у нас смонтированы все UFS операционной системы, а на диске c0t0d0s0 во весь объем создан ZFS-пул.

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

Итак, тесты. Мы будем создавать и копировать файлы. На UFS и ZFS. На время, насколько точно мы сможем его измерить. Не очень огромные файлы (позже я объясню, почему), а просто чтобы увидеть закономерности, буде таковые будут.

Тест 1
------

На UFS:
server5# cd /
server5# date; mkfile 100m test1.file; date
Monday, June 15, 2009 8:21:06 PM ALMT
Monday, June 15, 2009 8:21:08 PM ALMT
~3 сек

На ZFS:
server5# cd /data
server5# date; mkfile 100m test2.file; date
Monday, June 15, 2009 8:21:22 PM ALMT
Monday, June 15, 2009 8:21:23 PM ALMT
~1 сек

Гм, недурной разбег. Однако один раз - не голубой, и надо хоть какую-то статистику. Обратите внимание, размер файла составил примерно 60% от объема ZIL.

Играем далее.

Тест 2
------

На UFS:
server5# cd /
server5# date; mkfile 180m test1.file; date
Monday, June 15, 2009 8:28:12 PM ALMT
Monday, June 15, 2009 8:28:15 PM ALMT
~3 сек

На ZFS:
server5# cd /data
server5# date; mkfile 180m test2.file; date
Monday, June 15, 2009 8:28:30 PM ALMT
Monday, June 15, 2009 8:28:32 PM ALMT
~2 сек

Так, при приближении к размеру ZIL разница практически выравнивается (множественные прогоны это подтверждают, особенно следующий тест). Прошу заметить, что одиночную запись такого размера вы нечастно встретите, скажем, в СУБД. Разве что LOB.

Ради полноты проверки подтвердим одну нарождающуюся гипотезу:

Тест 3
------

На UFS:
server5# cd /
server5# date; mkfile 512m test1.file; date
Monday, June 15, 2009 8:32:40 PM ALMT
Monday, June 15, 2009 8:32:48 PM ALMT
~8 сек

На ZFS:
server5# cd /data
server5# date; mkfile 512m test2.file; date
Monday, June 15, 2009 8:33:03 PM ALMT
Monday, June 15, 2009 8:33:11 PM ALMT
~8 сек

"Ага!!!" - сказали мужики. Если объем записи превышает размер ZIL, разница в скорости записи на UFS и ZFS практически стремиться к нулю. Напоминаю - диски абсолютно идентичные.

Ладно, хорошо. Идем дальше.

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

Это не БД, конечно, но что-то ее хотя бы отдаленно напоминающее - читаем с диска и на него же пишем.

Тест 4
------

Копирование созданного файла 512m

На UFS:
server5# cd /
server5# date; cp test1.file test2.file; date
Monday, June 15, 2009 8:37:06 PM ALMT
Monday, June 15, 2009 8:37:22 PM ALMT
~14 сек

На ZFS:
server5# cd /data
server5# date; cp test2.file test3.file; date
Monday, June 15, 2009 8:35:12 PM ALMT
Monday, June 15, 2009 8:35:26 PM ALMT
~14 секунд

Тэкс, что мы видим. Тот же результат, что и просто при записи. Все, что превышает размер ZIL, не тормозит, конечно, но разница практически отсутствует по отношению к ZFS. Что ж, замечательно и то, что не хуже результат (Эй, у кого там ZFS в три раза медленней UFS при асинхронной записи?).

Ну, а теперь дискотека. Пулеметчик Ганс достал новые диски. Размер записи, примерно соответствующий среднестатистическому оракловскому параметру DB_FILE_MULTIBLOCK_READ_COUNT на OLTP.

Держитесь за кресла, а то выпадете:

Тест 5
------

Копирование созданного файла 50m

На UFS:
server5# cd /
server5# date; cp file1.test file2.test; date
Monday, June 15, 2009 8:41:42 PM ALMT
Monday, June 15, 2009 8:41:43 PM ALMT
~1-1,5 сек

На ZFS:
server5# cd /data
server5# date; cp file1.test file2.test; date
Monday, June 15, 2009 8:41:52 PM ALMT
Monday, June 15, 2009 8:41:52 PM ALMT
Менее 1 сек

"О так от,миста Тейба, о так от..." © Кен Кизи, "Полет над гнездом кукушки"

Менее 1 секунды во второй части данного теста (неоднократно - более 20 раз - повторенном) выглядело так - бдыщь! - мгновенно. То есть сильно менее 1 секунды.

Необходимое пояснение

Итак, что все это, вышеприведенное, означает?

Означает вот что.

ZIL, размещенный на быстродействующем устройстве, дает существенный прирост в скорости асинхронной записи на ZFS. По результататм (более 100 прогонов) приведенных тестов и при размере записи, меньшем, чем размер ZIL - порядка 50-60%.

Главный вопрос - почему?

Потому что.

ZIL играет при ZFS ту же самую роль, что и redo logs при Oracle. Фактически мы пишем изменения в него, а, так как он в наших тестах находится в памяти, то мы весьма мало пишем на сам диск. При этом запись практически полностью является отложенной, что и обусловливает такой скоростной разбег.

Да, это весьма напоминает JFS. Однако есть существенная разница. Механизм записи и метаданные в ZFS существенно отличаются от JFS/UFS. Еще не курившие мануалов почитают в концепциях, остальные знают, что грубо разница в объеме метаданных составляет почти те самые пресловутые три раза, ко всему прочему, метаданные ZFS организованы таким образом, что накладные расходы на их обмолот сильно меньше, нежели у JFS/UFS.

А это, в свою очередь, с высокой вероятностью означает, что политрук лжет.

Иначе говоря, заявления о том, что ZFS при записи по меньшей мере в три раза медленнее UFS в режиме forcedirectio, мягко говоря, кажутся недостоверными. Как минимум, производительность асинхронной записи даже на дефолтной ZFS не хуже, чем на UFS **.

С другой стороны, я не исключаю наличие некоего локального нарушения законов сохранения, этакой сингулярности (в железе, софте или в прокладке между креслом и консолью;)), в силу которой ньютоновские законы перестают действовать и начинают действовать релятивистские. ;) И из-за этого ZFS тормозит. Фазы Луны. Козерог в Тельце. Плохая карма для IT-систем.

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

Однако я отвлекся. Мы говорили не о тормозах, а о дальнейшем поиске весьма высокопроизводительной конфигурации ZFS-пула. Как знать, можем, мы сможем помочь сингулярным сисадминам и релятивистским DBA. ;)***

Да, это не тесты, более того, это просто одиночные однопоточные операции, простые как три рубля, весьма отдаленно похожие на настоящую дисковую активность. Однако тенденция достоверно вписывается в теоретические объяснения Sun Microsystems и подтверждается статистикой функционирования реальных приложений на ZFS.

(Необходимое пояснение закончено)

Дабы избежать засады с ограничением на размер ZIL - есть два варианта.

Первый. Положить ZIL на пару (round-robin load balancing в этом случае у ZFS работает автоматически) раскиданных на физически разные контроллеры максимально быстродействующих диска - SAS 15K или SSD. Их размеры обычно заведомо превосходят совокупные размеры всех одновременно выполняющихся записей. Мало - добавим еще дисков туда же, масштабирование по горизонтали ограничено лишь возможностями выделения контроллеров и/или каналов ввода-вывода.

Второй. Если оставить в покое пока не выясненный вопрос с целостностью БД (на операциях startup/shutdown Solaris/RDBMS) при такой организации пула - взять машину с большим количеством RAM, и раскочегарить RAM-диск, и, соответственно, ZIL, на размер этак в 10-20 Гб. В памяти. Меньше - зато 50-60% прироста производительности подсистемы ввода-вывода. Сколько это будет в результирующей производительности СУБД - прикиньте сами. Можно вообще представить монструозную конфигурацию, где 128 Гб оперативной памяти отдано для RAM-диска двухтерабайтного ZFS-пула... нет, с утра я ничего не пил. ;)


Кстати, далеко не факт, что при размещении ZIL на нескольких 15K SAS (скажем, восьми) не получится почти такого же (или во всяком случае соизмеримого) прироста производительности.

Как бы то ни было - тесты не закончены. На данный момент у меня нет подходящей машины для полномасштабных тестов с Oracle Enterprise Edition и реалистичной базой данных, однако как только она будет - продолжение обязательно воспоследует.

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

To be continued...

PS. Не пытайтесь пока повторить данный трюк в домашних условиях. В данном эксперименте перед шатдауном опытной машины необходимо обязательно разрушать ZFS-пул с логом на RAM-диске. В противном случае после рестарта вы получите дергадировавший пул и дедлок на ZFS (это лечится, расслабьтесь, и не переустановкой). Это связано с тем, что ZFS-пул создан с автоматическим монтированием после старта ядра, а RAM-диск приходит позже - я не могу его инициализировать ранее, чем ОС перемонтирует файловую систему /usr в read/write, а ramdiskadm находится именно там. Сервис монтирования подобного пула после старта ramdisk и с соответствующими депендентами в репозитории SMF будет написан чуть позже.
____________________________________________
* © Доктор Ливси, "Остров Сокровищ".
** Единственное разумное объяснение тому, что ZFS может в некоторых -весьма редких - случаях быть медленней, чем UFS- это вот это: Tuning is often evil and should rarely be done. В отношении ZFS это практически во всех случаях справедливо. "Let's my people go!". За исключением параметра recordsize (и то зачастую его не нужно трогать) - в ZFS практически отсутствуют параметы, способные улучшить и ускорить работу файловой системы. Замедлить - всегда пожалуйста, если менять их без учета законов сохранения - а они в IT действуют, как это ни удивительно отдельным личностям, незнакомым с матаном.
*** Конечно же, следует читать "реляционным". ;) Шутка юмора.

суббота, 6 июня 2009 г.

RAM-диски в Solaris, часть II

Ранее я уже писал об опытах с RAM-дисками в Solaris. К сожалению, на тот момент у меня не было времени довести работы до конца и, в частности, написать сервис SMF, позволяющий автоматически создавать RAM-диски в момент старта системы.

Собственно, и необходимости особой на тот момент в этом не было.

Однако времена меняются, и такая задача возникла.

Возникла, как ни странно, в связи с ZFS.

Как известно, ZFS в текущей версии может быть кэширована (что используется в иерархических системах хранения) и имеет ZIL - ZFS Intent Log, журнал намерений, который можно размещать на сверхбыстродействующих устройствах, что позволяет очень сильно ускорить синхронную запись на ZFS в некоторых применениях.

Некоторые джентльмены жалуются, что ZFS сильно проигрывает UFS в синхронной записи в определенных приложениях. Более того, они жалуются, что сырые устройства (raw devices) по-прежнему впереди и на лихом коне в плане производительности.

Собственно, данное исследование (тюнинг синхронной записи на ZFS при размещении ZIL на отдельном скоростном устройстве) еще впереди, а пока речь пойдет о завершенной наконец работе с RAM-дисками.

Собственно, примерно за четыре дня был написан SMF-сервис RAM-диска, аналогичный данному скрипту, только в современном исполнении и для SMF (а не скриптов rc).

По различным причинам я не посчитал целесообразным делать поддержку множественных RAM-дисков и конфигурационных файлов. Вместо этого добавлена поддержка:

- Только создания RAM-диска как сырого устройства, без форматирования и автоматического монтирования.

- Форматирования RAM-диска не только в UFS, но и в ZFS, с автоматическим монтированием и поддержкой особых случаев: например, аварийного падения системы бывает трудновато запустить систему с отсутствием ZFS-пулов, которые система считает своей частью.

Разумеется, раз используется ZFS, есть возможность задавать или менять несколько особенно сильнодействующих параметров (в readme описано, каких именно и почему) файловой системы (пула).

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

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

Следует иметь в виду одну особенность RAM-дисков в Solaris.

Страницы RAM-дисков блокируются в памяти и не свопятся. Это означает, что, если перестараться с размером RAM-диска, можно спровоцировать интенсивную подкачку других приложений.

Имейте в виду, что подобный диск не будет приводить к проблемам и в принципе будет полезным лишь на системах, имеющих достаточное количество оперативной памяти.

Например, маньяки, которые любят заниматься сексом в трех-четырех презервативах ;) и гоняющие Солярис в виртуальной машине под WinXP на ноутбуках, выделив Солярису 512 Мб памяти (если им вообще удастся его запустить на таком количестве), будут стонать, что не могут вообще создать никакой RAM-диск.

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

В случае же, если вышеупомянутые маньяки таки сумеют выделить Солярису гигабайт и отрезать от него 128 Мб под RAM-диск, они также взвоют, что, вопреки всем публикациям и здравому смыслу, RAM-диск работает ужасающе медленно.

На мой взгляд, выполнение ОС в виртуальной машине вообще противоречит здравому смыслу в большинстве случаев (исключения чрезвычайно редки), и, на мой же взгляд, в подобном случае все справедливо. В трех презервативах ничего чувствовать нельзя - уж не обессудьте. ;)

вторник, 2 июня 2009 г.

Кошки вкусные

В продолжение двух последних статей хочу предложить маньякам только пруфлинки*. Дабы не быть обвиненным в субъективизме или голословных утверждениях.

Итак,

Пруфлинк Раз
Пруфлинк Два
Пруфлинк Три

Для умеющих читать на языке Шекспира, извлекать знания и самостоятельно проверять утверждения:

Пруфлинк Четыре

Ну и для любителей raw devices (сырых устройств - в буквальном переводе) и Direct IO:

Пруфлинк Пять

Кошки вкусные.

Вы просто не умеете их готовить.

_____________________
* По совершенно непостижимой для меня причине, маньяки испытывают невероятные сложности с чтением трахнутых мануалов (испытывают неизъяснимое отвращение к чтению оных) и особенно с самостоятельным использованием Гугла. JFGI!