proxmox storage optimization

Я хочу построить небольшой домашний сервер виртуализации на базе ProxMox. Требования к подсистеме хранения такие:

кеширование SSD
дедупликация при небольшом потреблении памяти. не обязательно inline, можно просто по расписанию.
сжатие

Варианты:

ZFS - все круто (“искаропки” есть кеширование, дедупликация и сжатие). Однако, дедупликация требует очень много памяти (>5GB на 1Tb данных). А также на производительность влияет неотключаемый Copy-On-Write.
ext3/4 over LVM - быстрая и стабильная. можно сделать кеширование на SSD. Нет дедупликации. Нет сжатия.
BTRFS over LVM - можно сделать кеширование на SSD. Есть дедупликация по запросу. Есть сжатие. Можно отключить Copy-On-Write (но тогда отключится сжатие).
Virtual Data Optimizer - VDO суперштука. Модуль ядра, который реализует inline-дедупликацию и сжатие для томов LVM. Пока что доступен только в RedHat и непонятно что со стабильностью/производительностью/ресурсами. Уже есть в составе Debian - https://manpages.debian.org/testing/lvm2/lvmvdo.7.en.html

Решение

Выбор пал на связку BTRFS over LVM. Она позволяет дедуплицировать данные по расписанию (с помощью duperemove), кешировать данные на SSD с помощью lvmcache.
Файлы образов дисков должны быть в формате qcow2, что позволит делать снепшоты.
Файловые системы контейнеров LXC можно хранить как в виде образов, так и просто в папках на BTRFS. Последний вариант будет скорее всего быстрее (вследствие отсутствия loop-устройства), позволит дедуплицировать и\или сжимать файлы контейнеров средствами BTRFS.
Забегая вперед, скажу, что SSD кеш делает виртуальные машины ГОРАЗДО отзывчивее. Даже в условиях нехватки оперативной памяти.

ВНИМАНИЕ!!!

Всем, кто решит использовать BTRFS + lvmcache на хосте ProxMox нужно помнить следующее:

lvmcache НЕ совместим с различными вариантами hibernate. Если вы попытаетесь выполнить pm-hibernate на хосте кешированными томами, то никакого hibernate не произойдет. Система просто перезагрузится, а данные на дисках будут повреждены. Я пробывал.
использование BTRFS с флагом nodatacow (то есть отключение Copy-On-Write) наверное, немного поднимет производительность, но взамен сделает и без того не самую надежную файловую систему абсолютно неремонтопригодной. Отключится весь функционал, обеспечивающий надежность хранения (CoW и контрольные суммы). В результате, при повреждения файловой системы даже btrfs check использовать не получится (по причине отсутствия ctree).

Создание кешированного тома LVM

https://superuser.com/questions/952016/how-can-i-use-one-lvmcache-cache-pool-lv-for-multiple-origin-lvs

Пример конфигурации такой. два диска - /dev/vdb (SSD) и /dev/vdc (HDD). Создаем физичесике тома и группу томов test:

pvcreate /dev/vdb
pvcreate /dev/vdc
vgcreate vgname /dev/vdb /dev/vdc

Создаем том с кешем на SSD:

lvcreate --type cache-pool -L1G -n cache vgname /dev/vdb

Создаем том с данными:

lvcreate -L9G -n data vgname /dev/vdc

И теперь собираем конструкцию:

lvconvert --type cache --cachepool vgname/cache vgname/data
Do you want wipe existing metadata of cache pool volume test/cache? [y/n]: y
Logical volume vgname/data is now cached.

Отсоединить кеш от тома можно командой:

lvconvert --splitcache vgname/data

Состояние тома можно поглядеть командой:

dmsetup -v status vgname/data

Тип кеша можно поменять командами:

lvchange --cachemode writeback vgname/data
lvchange --cachemode writethrough vgname/data

Создание хранилища Proxmox

Для начала надо смонтировать том с параметрами noatime,nodiratime

mkdir /mnt/vgname-data
echo '/dev/mapper/vgname-data  /mnt/vgname-data  btrfs   noatime,nodiratime  0  2' >> /etc/fstab
mount /mnt/vgname-data
pvesm add dir Test-Data --path /mnt/vgname-data

Тестирование FIO

Тестовый хост - Pentium Silver J5005, 8GB Ram, mdadm RAID1 2x2Tb Seagate HDD (подключены к SoC AHCI), OCZ Vertex2 EX 100Gb SSD Cache (подключен к ASMedia ASM1061), transparent_hugepage выключены.
FIO под Windows Server 2008R2 скачанный отсюда: https://bluestop.org/fio/ у меня не заработал. Все время при запуске падал - fio.exe has stopped working.
Очевидно, это проблемы со сборкой, потому что FIO скачанный отсюда: https://ci.appveyor.com/project/axboe/fio/build/job/1q9lno301yq74mxc/artifacts заработал без проблем.
Тесты запускались такими командами:

fio.exe   --name=baseline --rw=randread --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall
fio.exe   --name=baseline --rw=randwrite --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall

То есть тест блоками по 4k, случайные чтение и запись, глубина очереди 32, размер тестового файла - 1Gb, без кеширования на уровне Windows (direct=1).
Тесты запускались по три раза, чтобы тестовый файл попал в SSD-кеш.

LVM Cache/PM Cache/Format	Read, MiB/s	Write MiB/s	Read IOPS avg, k	Write IOPS avg, k	CPU Read, %	CPU Write, %
WB/NC/qcow2	133	100	34.0	25.6	26	0
WB/NC/raw	127	104	32.5	26,6	25	0
WB/WB/qcow2	158	107	40.5	27,4	0	0
WB/WT/qcow2	166	5.3	42.6	1.324	0	4
WB/WT/raw	154	5.47	39.5	1.335	0	3.5
WB/WB/raw	150	118	38.3	30.1	0	23
WT/WT/qcow2	213	0.046	54.5	0.011	21	0
WT/WB/qcow2	159	9.5	40.8	2.37	0	0.9
WT/NC/qcow2	128	0.612	32.8	0.152	12.5	0
WT/NC/raw	121	0.832	30.9	0.208	0	0
WT/WT/raw	288	0.041	73.7	0.010	56	0
WT/WB/raw	137	16.8	35.1	4.303	0	3.3
NC/WB/raw	146	4.4	37.3	1.099	0	0.4
NC/WT/raw	148	0.0476	37.8	0.011	0	0
NC/NC/raw	1.766	0.694	0.441	0.173	0	0.33
NC/NC/qcow2	1.830	0.244	0.457	0.061	0.86	0
NC/WT/qcow2	1.7	0.0465	0.449	0.011	0	0
NC/WB/qcow2	3.578	4.889	0.894	1.222	0	0.47

Результаты тестирования fio

Предсказуемо, стабильно высокие результаты при минимальной загрузке VCPU показал вариант, когда включено кеширование на LVM и Proxmox в режимах WriteBack. Его недостатком можно считать вероятность потери данных при выходе из строя SSD или отключении питания.
Не сильно отстает конфигурация с кешированием только на SSD в режиме WriteBack. От выхода из строя SSD можно защититься, использовав два накопителя в зеркальном массиве.
Разница между форматами qcow2 и raw несущественна, при большей функциональности qcow2.
В режимах Writeback на уровне proxmox без кеширования на SSD на уровне lvm, скорость записи очень нестабильна. Она может быть как довольно высокой (3000-4000 IOPS), так и довольно низкой (500-1000 IOPS) и меняется произвольным образом.
Режимы кеширования ProxMox WriteThrough - существенно ускоряют чтение (в 100 раз), но замедляют запись (в 5-20 раз) по сравнению с режимами без кеширования и writeback.
Возможно, на данной системе можно добиться более высоких результатов, если подключить cache SSD к SoC AHCI. Вот тут есть тестирование производительности разных контроллеров: http://www.thg.ru/storage/vliyaniye_kontrollera_na_skorost_ssd/print.html и ASMedia ASM1061 там далеко не лидер по производительности, а сам SSD по паспорту способен выдавать до 70000 IOPS. C PCI-E SSD результаты должны быть еще интереснее.

Тестирование с помощью CrystalDiskMark 6.0.2 x64

Тестирование производилось на VM - Windows Server 2008 R2, 4GB mem, 2 cores. Для тестирования виртуальной машине добавлен отдельный пустой диск 32Gb.
В качестве SSD cache выступал том LVM на SATA диске OCZ Vertex V2 EX.
Тест в Crystal Mark запускался по 3 раза, чтобы данные успевали закешироваться. В таблице приведены данные после третьего замера.
Параметры CrystalMark - 5, 1GiB.
Boot Time - время загрузки ОС от включения до появления приглашения Press Ctrl+Alt+Del.

1 - lvm cache - On WriteBack, proxmox cache - no cache, qcow2
2 - lvm cache - On WriteBack, proxmox cache - no cache, raw
3 - lvm cache - On WriteBack, proxmox cache - WriteBack, qcow2 . WARNING - Very High CPU Load while tests!!! Very Long test!!!
4 - lvm cache - On WriteBack, proxmox cache - WriteThrough, qcow2 WARNING - Very High CPU Load while tests!!! Very Long test!!!
5 - lvm cache - On WriteBack, proxmox cache - WriteThrough, raw WARNING - Very High CPU Load while tests!!! Very Long test!!!
6 - lvm cache - On WriteBack, proxmox cache - WriteBack, raw . WARNING - Very High CPU Load while tests!!! Very Long test!!!

Disk Config	Seq Read Q32T1	Seq Write Q32T1	4KiB Q8T8 Read	4KiB Q8T8 Write	4KiB Q32T1 Read	4KiB Q32T1 Write	4KiB Q1T1 Read	4KiB Q1T1 Write	Boot Time, sec
1	217,1	105,3	112,4	84,32	111,4	78,72	12,12	21,75	16
2	218,9	104,6	112,7	86,15	111,8	84,85	11,87	21,58
3	2423	245,6	329,0	163,6	285,6	165,5	39,83	34,49	16
4	2494	84,31	331,4	6,4	289,5	5,5	40,31	4,0
5	2566	90,61	347,9	6,67	301,8	5,86	40,73	4,2
6	2457	210,9	350,5	161	301,1	173,5	40,47	35,9

Table of Contents