ZFS Appliance. zpool на zpool... А хочется как RAW по скорости!

Что есть - ZFS Appliance 7420 :
DATA: 50.1 ТБ
Parity: 52.9 TB
Reserved: 814 GB
Spare: 5.46 TB

Data+Parity: 38 HDD SATA
Spare: 2 SATA HDD
Log: 8 SSD SLC
Cache: 4 SSD eMLC

Сервер Т4-1, Solaris 11.1 SRU 19.6. Подключен к одному контроллеру Appliance (далее ZFSA) оптикой 4 Гб - один конец - ну нету больше ни SFP ни кабелей. ZFSA только одну голову включили.
На ZFSA делаем два LUN. Первый пусть 20ТБ - это будет файловая система ZFS. Второй том 10ТБ - будет типа RAW. По крайней мере не буду делать из него zpool/zfs.

Ставим Vdbench 5.2.
Делаем такой профиль нагрузки:

sd=sd1,lun=/dev/dsk/c0t600144F0D38CB9FD0000539856550004d0s0,threads=500
wd=wd1,sd=sd1,xfersize=8k,rdpct=70
rd=rd1,wd=wd1,iorate=max,elapsed=3000,interval=1

То есть наш LUN 10TB будем нагружать 500-ми потоками на чтение блоками 8К - 70% и остальные 30% - запись теми же блоками 8К.

Что получаем (в среднем вот такая картинка на всём протяжении трех тысяч тестовых попыток)
Jun 11, 2014  interval        i/o   MB/sec   bytes   read     resp     resp     resp    cpu%  cpu%
                             rate  1024**2     i/o    pct     time      max   stddev sys+usr   sys
21:59:20.014        31   12118.00    94.67    8192  69.54   41.088  117.648   29.401     2.2   1.8
21:59:21.027        32    9844.00    76.91    8192  69.98   49.287  189.694   39.058     1.6   1.4
21:59:22.014        33    8846.00    69.11    8192  70.42   58.373  278.969   47.641     1.6   1.3
21:59:23.015        34   11991.00    93.68    8192  70.09   41.427  114.597   29.526     1.9   1.6
21:59:24.014        35   11972.00    93.53    8192  69.29   41.832  116.797   30.124     2.0   1.7
21:59:25.014        36   11843.00    92.52    8192  69.64   42.325  117.584   30.306     2.5   1.9

#iostat -zxne 5
  r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device
7903.9 3364.8 63231.4 26918.3 254.9 256.1   22.6   22.7 100 100   0   0   0   0 c0t600144F0D38CB9FD0000539856550004d0

Обращаю внимание на actv=256
Похожие результаты имеем от 250 до 500 потоков. При 600-х вся картина становится грустной - перегрузка массива запросами, резкое увеличение response time, на порядки снижается IOPS.

Что мне хотелось бы - сделать теперь zpool/zfs со вторым томом и получить похожую картинку на той же нагрузке. Я понимаю, что ZFSA это уже ZPOOL/ZFS со всем что нужно настроить в этой связке и мне бы использовать ASM для работы с СУБД, но мой ДБА не умеет и не знает что такое ASM.

Создаем zpool db1 с одним томом 20ТБ с ZFSA.
Делаем профиль нагрузки :
fsd=fsd1,anchor=/db1/fs0,depth=1,width=1,files=1000,size=1g
fwd=fwd1,fsd=fsd1,xfersize=8k,fileio=random,fileselect=random,rdpct=70,threads=500
rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=3000,interval=1

Тут моя файловая система /db1. В ней будет создана структура файлов - 1000 файлов по 1ГБ каждый. 

Но прежде чем запустить работу vdbench, я настрою zfs как в мануале по Performance tuning а именно:

zfs set atime=off db1

zfs set logbias=throughput db1

zfs set recordsize=8k db1

в параметрах /etc/system у меня классическое:

set zfs:zfs_arc_max = 0x180000000

set zfs:zfs_vdev_max_pending=32

Запускаемся. Сначала vdbench будет очень долго трудиться над созданием структуры файлов. Он это делает по 8 потоков блоками 64К. Долго. Сделал.

Теперь начинаем работу - читаем 70% блоками 8К, файлы выбираем случайно.

Смотрим на статистику iostat/vdbench. Больше 2000 IOPS не получается.

ДАЛЕЕ - что я делаю то НЕ РЕКОМЕНДУЮ ДЕЛАТЬ БЕЗ ПОНИМАНИЯ ЗАЧЕМ Я ЭТО ДЕЛАЮ! НЕ ДЕЛАЙТЕ ЭТОГО У СЕБЯ БЕЗДУМНО!

1. Снимаем ограничение на глубину очереди :

echo zfs_vdev_max_pending/W0t256 | mdb -kw

Результат конечно же будет сразу - мы видим 3-4 тысячи IOPS вместо 2-х тысяч.

2. Снимаем кэшировку в NVRAM:

echo zfs_nocacheflush/W0t1 |mdb -kw

Результат стал получше но мало изменилось, совсем мало + 500 IOPS.

3. Что может мешать работать zfs как RAW ? В моем понимании в этой ситуации - память ядра, которая работает как буферный кэш. Отвязываюсь от нее:

zfs set primarycache=none db1

zfs set secondarycache=none db1

Результаты видим сразу - до 6-7 тысяч подросли.

4. ОСТОРОЖНО! НЕ ПОВТОРЯТЬ без понимания!

ZFS имеет параметры и поведение, согласно которому вот что происходит:

Параметр zfs_txg_synctime_ms у меня был равен 5000 мс.

#echo zfs_txg_synctime_ms/D |mdb -k

zfs_txg_synctime_ms:

zfs_txg_synctime_ms:            5000

Что это значит - 5000 ms * dp_throughput (1000B/ms) = 5 000 000 B  - это лимит записи (write limit). И как он набирается, zfs блокирует операции записи, пока не сбросит его на диски. После сброса (sync) продолжаем работать. 

Снижаем до 1мс:

echo zfs_txg_synctime_ms/W0t1 | mdb -kw

zfs_txg_synctime_ms:            0x1388          =       0x1

Зачем? Моя задача сделать из zfs -> RAW , но как бы отвязаться от буферизации в памяти.

Может есть forcedirectio у ZFS ?? Я не нашел.

Зато vdbench работает и iostat показывает:

r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device

9459.6 1863.7 33980.4 33757.8  1.1 25.2    0.1    2.2  11  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

9862.5 1877.2 39283.4 34031.1  1.3 26.7    0.1    2.3  11  98   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

9840.9 2011.3 39882.0 33009.7  1.3 30.2    0.1    2.6  11  95   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

Увеличу количество потоков до 1000:

 13428.7 1546.8 42924.2 27747.3 14.0 41.6    0.9    2.8  16  96   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

 12028.1 1415.2 40124.5 25257.1 15.0 41.5    1.1    3.1  16  93   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

12909.0 1325.1 44641.5 23010.3 16.0 45.1    1.1    3.2  17  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

13653.4 1399.0 48039.5 25726.9 15.0 44.0    1.0    2.9  17  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

14593.8 1719.1 51977.4 28239.7 17.2 49.4    1.1    3.0  20  94   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

Это выглядит даже лучше чем RAW :))))

Вопросов больше чем ответов пока. 

Немного по настройкам томов на ZFSA. Я выключил на вкладке Shares->LUNs->Protocol галку Write cache enabled. Ибо судя по блогу одного из ораклистов при включеной этой опции мы имеем синхронные записи во флеш (Writezilla) а потом в DRAM. Оно хорошо бы включить для скорости эту опцию (с потерей в надежности!!!!) когда ZFSA поставляется БЕЗ WriteZilla. Они кстати стоят на каждой полке с дисками а ReadZilla - на контроллерах.

Для LUN db1 были умолчания: write bias = latency, cache device = all, Single copy, Fletcher4, Compression=off. Thin provision =off.

PS: кстати... Вот что попробовал и получил в догонку.

Если в настройках тома установить write bias = throughput, IOPS падают в разы - оно и понятно, поведение при такой настройке говорит делать sync на диски чаще. Тут нам поможет как раз Write cache enabled на вкладке Protocol. 

Включив Write cache enabled получаем еще лучше вариант по IOPS:

#iostat -zxne 5

 r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device

 17265.6 1898.4 85969.1 29162.4 25.7 75.8    1.3    4.0  26  93   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

15672.3 1554.0 76992.3 28906.9 24.3 60.5    1.4    3.5  24  98   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

 16188.2 1471.3 79249.6 26984.2 24.8 61.3    1.4    3.5  24  98   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

Коллеги, не надо критиковать - это чисто эксперимент и не более того:) 

Делаем изврат - UFS раздел на ZFS Pool :)

Практического применения это действо не имеет с моей точки зрения. Разве что академический интерес.
#zpool create test cxtxd0
#zfs create -V 2G test/oradata
тут еще для чистоты поставить можно для пула не возможность монтирования, размер блока, noatime=no,logbias=troughput и все-все что хочется. Даже Compression, deduplication.

#newfs -o time -m 1 /dev/zvol/dsk/test/oradata
#mount /dev/zvol/dsk/test/oradata /mnt

Далее тесты показывают, что я ничего тут не получаю из производительности :) дополнительно. Но судьба не лишена иронии:)

ZFS. Глубина очереди команд при работе с внешними хранилищами

Для ограничения и спасения дискового массива (особенно используемых совместно с другими) нужно ограничить глубину очереди. Это рекомендуется и производителями массивов в том числе. EMC например для своих VMAX рекомендует начать настройку с цифры 20 и далее вести ее до 32. HDS сразу предлагает с 32 начать.
Параметры выставляются в /etc/system

set ssd:ssd_max_throttle=32
set sd:sd_max_throttle=32

# echo sd_max_throttle/D | mdb -k

# echo ssd_max_throttle/D | mdb -k

Это выставит ограничитель на 32 глобально для дисков sd и ssd (не путать с флешами, это solaris:)))

И вот что заметилось - эти параметры были актуальны при работе с UFS. У ZFS есть свой параметр, который делает то же самое и по умолчанию он выставлен в 10.
Проверим сначала:
#echo zfs_vdev_max_pending/D | mdb -k
Увидим 10. Теперь установим в 32:
 - через /etc/system
set zfs:zfs_vdev_max_pending=32
 - на ходу для попробовать:
#echo zfs_vdev_max_pending/W0t32 | mdb -kw

Кстати, что бы посмотреть влияние этого параметра , стоило запустить генератор нагрузки vdbench и iostat -zxne 5 посмотреть на колонку actv, это и есть показатель глубины очереди. Для ZFS дисков он был бы не более 10.

После установки в 32, сделать тот же тест и посмотреть влияние. Если массив достаточно мощен, мы получим не плохой процент роста производительности.

PS: mdb -k
::memstat

Смотрим ZFS File Data - это то что забирает ZFS под свои кэши. Если не ограничить параметрами, то памяти не останется и плевать, что написано в доках о том, что мол ZFS отдаст сразу память как только она потребуется другому приложению. Этого не происходит (по крайней мере так как ждет приложение).

ZFS - где моя память??? :)

#kstat zfs:0:arcstats:size
module: zfs instance: 0
name: arcstats class: misc
size 2420348928

2GB памяти под кэш забрала ZFS. С одной стороны это и не плохо, но память нужна и другим приложениям. Убавить аппетиты можно так - в /etc/system запишем
set zfs:zfs_arc_max=0xЗНАЧЕНИЕ
где ЗНАЧЕНИЕ - это шестнадцатеричное представление объема отводимой памяти под кэш zfs

А вот как бы установить это огранчиение без перезагрузки сервера??

Вот здесь сценарий просмотра ARC-статистики ZFS

Swap на ZFS.

Поставил для игр SOlaris 10 10/08 (update 6) на zfs root. Ну работает и ладно... Играя дальше, пытался поставить VirtualBox 2.0 но оно ругаться начало - мол swap то мал! Надо что бы он был равен памяти.
# ./vb-install -f
Sun xVM VirtualBox 2.0.8 Installation

ERROR: Physical memory (32640 MByes) exceeds swap size (2048 MBytes)
Sun xVM VirtualBox 2.0.8 requires that the system swap size
has to be at least equal to the physical memory size on Solaris 10.
The installation of has failed.
Please check the log at '/var/sadm/install/logs/vb-install.2009_04_01_10:18:00.log'.

Делаем так:
#swap -l
swapfile dev swaplo blocks free
/dev/zvol/dsk/rpool/swap 181,2 8 4194296 4194296

#pfexec zfs set volsize=32G rpool/swap
#pfexec zfs set reservation=32G rpool/swap
#pfexec env NOINUSE_CHECK=1 swap -a /dev/zvol/dsk/rpool/swap $((8+4194296))

# swap -l
swapfile dev swaplo blocks free
/dev/zvol/dsk/rpool/swap 181,2 8 4194296 4194296
/dev/zvol/dsk/rpool/swap 181,2 4194304 62914560 62914560

теперь vbox начинает ставится...

ZFS: копируем данные

Из одного пула в другой на том же хосте. Исходный пул data, целевой ndb.
#zfs snapshot data/mysql@data_snap
#zfs send data/mysql@data_snap | zfs recv ndb/mysql

Solaris. ZFS раширяю SAN LUN

Есть Solaris, zfs. Есть SAN и LUN размером 50GB. Стало места мало. Можно создать новый лунь и добавить в пул zfs. А можно и не так. Можно расширить существующий LUN на массиве и таким образом увеличить место. Пул у меня называться будет data.
#zpool export data
#format - тут делаем так - выбираем нужный по WWN диск, говорим type->Autoconfigure. переписываме метки как было раньше но с новыми размерами, записываем метку
#zpool import data

Всё.