Сколько нужно памяти proxmox

Обновлено: 15.01.2025

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

дедупликация при небольшом потреблении памяти. не обязательно 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 и непонятно что со стабильностью/производительностью/ресурсами.

Выбор пал на связку 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

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

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

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

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

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

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

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

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

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

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

То есть тест блоками по 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.

Тестирование с помощью 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.

Читайте также: