Action disabled: revisions

proxmox storage optimization

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

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

Варианты:

  1. ZFS - все круто (“искаропки” есть кеширование, дедупликация и сжатие). Однако, дедупликация требует очень много памяти (>5GB на 1Tb данных). А также на производительность влияет неотключаемый Copy-On-Write.
  2. ext3/4 over LVM - быстрая и стабильная. можно сделать кеширование на SSD. Нет дедупликации. Нет сжатия.
  3. BTRFS over LVM - можно сделать кеширование на SSD. Есть дедупликация по запросу. Есть сжатие. Можно отключить Copy-On-Write (но тогда отключится сжатие).
  4. 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 нужно помнить следующее:

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

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

Для начала надо смонтировать том с параметрами 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

Тестовый хост - 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
  • Предсказуемо, стабильно высокие результаты при минимальной загрузке 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 результаты должны быть еще интереснее.

Тестирование производилось на 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 WriteBoot 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
Enter your comment. Wiki syntax is allowed:
 
  • proxmox/proxmox_storage_optimization.txt
  • Last modified: 2022/09/07 14:18
  • by admin