Сколько нужно памяти proxmox
Обновлено: 04.07.2024
Я хочу построить небольшой домашний сервер виртуализации на базе 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.
Читайте также: