Найкраща збірка Proxmox для домашньої лабораторії 2026: обладнання, мережеві інтерфейси, структура сховища та енергоефективність

November 15, 2025 • February 3, 2026 • Читання: 5 хв • Views: 7

Було корисно?

Ви знаєте цей момент: натискаєте «Start» на VM, і вона зависає на десять секунд. Копіювання на NAS повзає. Plex буферизує. А вентилятори звучать ніби невелика атака дронів. Найгірше — ви не можете зрозуміти, чи вузьке місце в плануванні CPU, латентності сховища, апаратних відвантаженнях NIC, чи в тому, що пул ZFS робить «правильну» річ у абсолютно невідповідний час.

Це практичний посібник зі збірки Proxmox homelab на 2026 рік для людей, які дійсно запускають сервіси. Ми підберемо обладнання, яке поводитиметься передбачувано, спроєктуємо схеми зберігання, що не самосаботуються, і триматимемо споживання енергії достатньо низьким, щоб ви не почали «вимикати речі» як план місткості.

Цілі проєктування для homelab 2026

«Краща» збірка залежить від контексту. Фокус у тому, щоб вибрати обмеження, які триматимуть вас подалі від кювету.

Ціль 1: передбачувана латентність, а не пикові бенчмарки

Більшість homelab’ів не виходять з ладу через те, що вони повільні в абсолютному значенні; вони виходять з ладу тому, що латентність стає непередбачуваною. ZFS робить resilver. Дешевий NVMe тримає thermal-throttling. NIC i225 має невдалий день. VM на «швидкому SSD» насправді сидить на QLC-диску без вільної запасної області.

Ціль 2: ізоляція відмов

Проєктуйте так, щоб одна відмова диска, один просідання PSU або одна невдала конфігураційна правка не виводили з ладу все. Тут окупляться дзеркальний завантажувальний диск, окремі пули і нудна мережна топологія.

Ціль 3: енергоефективність без втрати надійності

Погоня за мінімальним енергоспоживанням в режимі простою може заштовхнути вас у дивні платформі класу ноутбуків з крихким I/O. Потрібен «достатньо ефективний» варіант з надійними драйверами, ECC якщо можливо, і шасі, що охолоджує без вересків вентиляторів.

Ціль 4: підтримуваність під помірним навантаженням

Якщо ви не можете замінити диск, не виймаючи весь сервер з шафи, у вас не сервер — у вас головоломка.

Один цитат (перефразована ідея): Джин Кім часто повторює істину операцій: надійність приходить від швидкого зворотного зв’язку і малих змін, а не від героїзму.

Жарт №1: RAID — не резервне копіювання; це просто дискоспільно домовляються виходити з ладу за розкладом, який ви не обирали.

Цікаві факти та коротка історія (чому все так)

Факт 1: ZFS був спроєктований у Sun з end-to-end контрольними сумами як ключова особливість, щоб ловити «тиху корупцію», яку традиційні RAID охоче повертають вам як валідні дані.
Факт 2: Ранні споживчі SSD робили TRIM опціональним; сучасні файломатали і прошивки SSD передбачають його наявність для стабільної продуктивності, особливо на QLC NAND.
Факт 3: 1GbE було «достатньо швидко», поки віртуалізація не зробила східно-західний трафік нормою. Міграції VM, бекапи та реплікація зберігання перетворили мережі на нову шину диска.
Факт 4: iSCSI та NFS здаються простими, поки не з’явиться латентність; більшість квитків «зберігання повільне» насправді — «мережевий джиттер поганий» у кращій обгортці.
Факт 5: ARC (RAM-кеш) ZFS зробив «більше пам’яті» функцією продуктивності задовго до того, як стало модно називати це «прискорення в пам’яті».
Факт 6: 2.5GbE для споживачів здобуло популярність, бо вендори материнських плат шукали відмінність без оплати за PHY 10GbE і великого енергоспоживання.
Факт 7: NVMe не лише збільшив пропускну здатність; він скоротив командну латентність, прибравши спадщинні стекі зберігання, призначені для обертових дисків.
Факт 8: Підйом Proxmox відображає ширшу тенденцію: операційна зручність часто перемагає теоретичну чистоту. «Одна панель для всього» має значення, коли ви втомилися.

Вибір обладнання, що не зіпсує вам вихідні

Sweet spot 2026: один солідний вузол або три менших вузли

У 2026 році ви можете дозволити собі запуск Proxmox у двох розумних конфігураціях:

Один «великий» вузол: простіше, дешевше, менше енергоспоживання, менше точок відмови. Мінус: обслуговування означає простій, якщо ви не спроєктували захист.
Кластер з трьох вузлів: краще для експериментів з HA, живих міграцій та поетапних оновлень. Мінус: більше споживання, більше мережі, і рано чи пізно ви будете налагоджувати кворум о 1-й ночі.

CPU: пріоритет — енергоефективність, віртуалізація та лінії I/O

Вам потрібен сучасний CPU з:

апаратною віртуалізацією (AMD-V/Intel VT-x) і IOMMU (AMD-Vi/VT-d) для passthrough PCIe.
достатньою кількістю PCIe-ліній для NVMe і справжнього NIC без драм шарингу ліній.
низьким споживанням в режимі простою. Багато homelab’ів простіше працюють в простоях, ніж на піках.

Моя думка: віддавайте перевагу серверній або prosumer workstation платформі з підтримкою ECC і стабільними оновленнями прошивки. Не тому, що ECC — це магія, а тому, що плати з підтримкою ECC зазвичай краще виконують тренування пам’яті та трасування PCIe.

RAM: купуйте більше, ніж думаєте, і активно контролюйте ARC

Для віртуалізації на ZFS оперативна пам’ять має три завдання: пам’ять гостьових ОС, ARC-кеш і метадані. Для одного вузла з кількома VM/контейнерами 64 GB — це «підлога, щоб не хвилюватися». Для вузла зі зберіганням або трьохвузлового кластера з реплікацією 128 GB — комфортно.

Не дозволяйте ARC з’їдати систему, якщо у вас є бази даних, що їдять пам’ять. Обмежуйте його.

Материнська плата і платформа: нудне — виграє

Шукайте:

IPMI або еквівалент віддаленого управління, якщо можливо. Це не тільки для перезавантаження; це для бачення апаратних помилок, коли ОС не працює.
два робочі PCIe слоти (ideal — x8 електрично). Один для NIC, інший — для HBA або додаткового NVMe.
достатньо M.2 слотів з радіаторами, що дійсно торкаються накопичувача.
опції BIOS для налаштування ASPM і C-states без ломки пристроїв.

Корпус і охолодження: бажано «тихий під навантаженням», а не «тихий в простої»

Повітряний потік — це функція надійності. Корпус, що вміщує нормальні вентилятори і дає дискам прямий повітряний потік, зменшить тротлінг SSD і перегрів HDD. Також: «тихі» відмови дисків — найгірший вид смерті, бо ви помітите їх тільки коли scrub закричить.

Блок живлення: важлива ефективність та стійкість до стрибків

Купіть якісний PSU. Не для «більше ватт», а для стабільної подачі під транзієнтним навантаженням. Сучасні CPU і GPU (навіть якщо GPU немає) можуть викликати різкі зміни навантаження. Добрий блок 80 Plus Platinum часто зберігає кілька ватт в простої і поводиться краще, коли UPS намагається вижити.

NIC, комутування та VLAN-логіка

Вибирайте NIC, як файлову систему: за драйверами, а не за виглядом

У 2026 році типовою мережею homelab є 2.5GbE. Це дешево і підходить для одного вузла з локальним сховищем. Але якщо ви робите будь-що з наступного, переходьте на 10GbE:

Proxmox Backup Server, що тягне великі бекапи щодня
реплікація ZFS між вузлами
спільне сховище (NFS/iSCSI) або Ceph
часті міграції VM

10GbE: SFP+ досі найкращий вибір

SFP+ має екосистему: DAC-кабелі, низьке енергоспоживання і менше «загадкових PHY» проблем. RJ45 10GbE працює, але він гарячіший, зазвичай витрачає більше енергії в простої, і ви можете ненароком зібрати теплову гармошку, яка ще й запускає Linux.

Налаштування bridge: тримайте все нудним

Linux bridge з VLAN-aware режимом працює добре. Уникайте хитромудростей на кшталт вкладених бриджів, якщо вам не подобається налагоджувати broadcast-шторм через власний оптимізм.

Жарт №2: Найшвидша у світі мережа не виправить VLAN, тегований в неправильне місце. Пакети не читають ваші наміри.

Макет SSD/HDD: пули ZFS, special vdev та режими відмови

Починайте з робочого навантаження, а не з типу диска

У вашому homelab’і ймовірно є три шаблони зберігання:

Завантаження VM і випадковий I/O: чутливі до латентності, люблять NVMe-дзеркала.
Медіа / масивне сховище: послідовні операції, дешевше за ТБ, підходить RAIDZ.
Резервні копії: write-heavy bursts, довге зберігання, хочуть дешеву ємність і передбачуваний час відновлення.

ZFS recordsize, volblocksize і чому значення за замовчуванням не завжди друг

Для дисків VM, які зберігаються як zvol, volblocksize має значення. Для datasets важливий recordsize. Не налаштовуйте хаотично. Налаштовуйте, коли можете описати I/O-патерн в одному реченні.

Загальний VM zvol: 16K — розумний дефолт для багатьох навантажень.
Бази даних: часто виграють від менших блоків, але тестуйте.
Медіа datasets: recordsize 1M — типовий варіант, бо читання великі і послідовні.

SLOG та L2ARC: припиніть купувати частини, поки проблеми немає

Більшість homelab’ів не потребують SLOG. Якщо ви не робите sync-записів через NFS/iSCSI на ZFS, SLOG — переважно дорогий талісман.

L2ARC може допомогти для read-heavy навантажень, що не влазять в RAM, але він споживає RAM для метаданих. Це не безкоштовно. Якщо можете — купіть більше RAM перш за все.

Special vdev: корисні, але гострі

Special vdev для метаданих і малих блоків може зробити HDD-пули більш відзивчивими. Але якщо ви втрачаєте special vdev — ви втрачаєте пул. Це не драма; це архітектура. Якщо використовуєте special vdev, дзеркальте їх і моніторьте як коштовність.

Вибір SSD: уникайте обіцянок «дешево і швидко»

Для VM pool приоритезуйте стабільну поведінку при тривалих записах і витривалість. Диск, який дає крутий бенчмарк 30 секунд, а потім руйнується — це не «швидкий», це «хвилинно ентузіастичний». Шукайте:

DRAM кеш або хоча б сильну реалізацію HMB
Добру стабільну швидкість запису (не лише SLC cache bursts)
Захист від втрати живлення, якщо ви серйозні (або принаймні UPS і консервативні налаштування)

Вибір HDD: планування ємності — це планування відмов

Для RAIDZ2 ємність гарна, поки resilver-часи не розтягуються. Великі диски означають довгі вікна відновлення. Плануйте на другу відмову під час rebuild. Саме тому існує RAIDZ2.

Енергоефективність: куди справді йдуть ватти

Пауза в простої — це рахунок, який ви платите щогодини

Більшість homelab’ів простоюють 80–95% часу. Витратьте зусилля на зниження споживання в простої:

віддавайте перевагу ефективним CPU і платам з хорошою поведінкою в простої.
відключайте непотрібні контролери в BIOS (додаткові SATA, RGB-контролери, непотрібне аудіо).
використовуйте менше, але більші вентилятори на нижчих обертах замість багатьох дрібних вентиляторів на повну.
обирайте SFP+ замість 10GBASE-T, якщо вам важливі ватти в простої.

Обертові диски чесні щодо споживання

HDD споживають постійну енергію і створюють тепло. Якщо ви гнобитеся за низьке споживання — подумайте про менше дисків з більшою ємністю, але пам’ятайте вікно відновлення. Якщо ви гнобитеся за тишу — монтуйте диски правильно і тримайте плавний повітряний потік.

Розмір PSU: не перепроєктовуйте значно

1200W PSU, що працює при 60W в простої, може бути менш ефективним ніж 450–650W у своїй «щасливій зоні». Купуйте якісну модель, розраховану на ваш реалістичний пік плюс запас.

Практичні завдання: команди, виводи та рішення

Ось реальні перевірки, які можна виконати на хості Proxmox. Кожна включає, що означає вивід і яке рішення з нього випливає. Робіть їх у цьому порядку під час збірки і знову, коли щось «не так».

Завдання 1: Підтвердити розширення віртуалізації та IOMMU

cr0x@server:~$ lscpu | egrep -i 'Model name|Virtualization|Flags'
Model name:                           AMD Ryzen 9 7900
Virtualization:                       AMD-V
Flags:                                ... svm ...

Значення: Ви хочете svm (AMD) або vmx (Intel). Якщо віртуалізація — «none», це налаштування BIOS або проблема платформи.

Рішення: Якщо відсутня — увімкніть SVM/VT-x і IOMMU/VT-d у BIOS перед тим, як будувати щось інше.

Завдання 2: Перевірити IOMMU групи (готовність до passthrough)

cr0x@server:~$ find /sys/kernel/iommu_groups/ -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:02.0

Значення: Групи існують; пристрої хоч якось ізольовані. Якщо директорії немає — IOMMU не увімкнено.

Рішення: Якщо потрібен passthrough GPU/NIC/HBA — перевірте ізоляцію груп зараз, перш ніж купувати плату, що збирає все докупи.

Завдання 3: Інвентарізувати пристрої зберігання та швидкість лінку

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
NAME        MODEL                    SIZE ROTA TYPE TRAN
nvme0n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
nvme1n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
sda         ST12000VN0008-2YS101    10.9T    1 disk sata
sdb         ST12000VN0008-2YS101    10.9T    1 disk sata

Значення: ROTA 0 = SSD/NVMe, 1 = HDD. TRAN каже про шинний інтерфейс. Якщо ваш «NVMe» з’являється як SATA — щось не так.

Рішення: Підтвердіть, що у вас саме ті носії, які планували. Це ловить неправильно вставлені M.2, що працюють на зменшених лініях.

Завдання 4: Перевірити здоров’я NVMe, температуру та лічильники зносу

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep 'temperature|percentage_used|data_units_written'
temperature                             : 41 C
percentage_used                         : 1%
data_units_written                      : 218,445

Значення: Температура під контролем, знос малий. Високі температури або швидке зростання зносу означає тротлінг або надмірні записи (часто через swap, логи або неправильні налаштування кешування).

Рішення: Якщо температури високі — поліпшіть повітряний потік або додайте радіатори. Якщо знос швидко росте — перемістіть write-heavy навантаження або перегляньте налаштування ZFS і логування.

Завдання 5: Перевірити драйвер NIC та стан лінку

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp3s0           UP             3c:ec:ef:12:34:56
enp4s0           UP             3c:ec:ef:65:43:21

Значення: Інтерфейси UP. Тепер перевірте швидкість/дуплекс.

Рішення: Якщо порт DOWN і повинен нести трафік VM — зупиніться і виправте це перш ніж звинувачувати сховище.

Завдання 6: Перевірити домовлену швидкість лінку (виявити 10G, що працює на 1G)

cr0x@server:~$ sudo ethtool enp4s0 | egrep 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Значення: Ви справді на 10GbE. Якщо бачите 1000Mb/s — маєте проблему з кабелем/трансивером/конфігом комутатора.

Рішення: Виправте фізичний рівень спочатку. Немає програмного налаштування, що зробить погану мідь гарною.

Завдання 7: Підтвердити VLAN-aware бриджі в мережі Proxmox

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.20/24
        gateway 192.168.10.1
        bridge-ports enp4s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Значення: Чистий бридж з включеним VLAN-aware. Якщо ви робите trunk’и, це та форма, яку ви хочете.

Рішення: Якщо бачите вкладені бриджі або випадкові post-up хакі — спростіть. Стабільність важливіша за хитромудрість.

Завдання 8: Підтвердити топологію пулу ZFS (чи справді дзеркало?)

cr0x@server:~$ sudo zpool status
  pool: fast
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        fast          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1p3 ONLINE       0     0     0
            nvme1n1p3 ONLINE       0     0     0

errors: No known data errors

Значення: Дзеркало здорове. Якщо ви бачите single-disk vdev — ви в одному кроці від поганого дня.

Рішення: Якщо топологія неправильна — виправте це перед тим, як додавати дані. Міграція пізніше болюча і зазвичай вимагає простою.

Завдання 9: Перевірити ashift (чи вирівняно під 4K сектора?)

cr0x@server:~$ sudo zdb -C fast | egrep 'ashift'
            ashift: 12

Значення: ashift=12 означає 4K сектори, що коректно для більшості сучасних SSD і HDD.

Рішення: Якщо ви випадково побудували пул з ashift=9, перезберіть пул зараз. Це не налаштування, що змінюється пізніше; це життєвий вибір.

Завдання 10: Перевірити властивості dataset ZFS для зберігання VM

cr0x@server:~$ sudo zfs get -o name,property,value compression,atime,recordsize fast
NAME  PROPERTY     VALUE
fast  compression  zstd
fast  atime        off
fast  recordsize   128K

Значення: Стиснення вкл. (добре), atime вимкнений (добре для багатьох навантажень). Recordsize стосується datasets, а не zvol.

Рішення: Тримайте стиснення увімкненим, якщо немає спеціальних причин. Якщо зберігаєте образи VM як файли в dataset — підбирайте recordsize за I/O.

Завдання 11: Перевірити блокове розмір zvol для диска VM

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize fast/vm-101-disk-0
NAME                PROPERTY      VALUE
fast/vm-101-disk-0   volblocksize 16K

Значення: Розумно для загального диска VM.

Рішення: Не змінюйте volblocksize пізніше, якщо не готові пересоздати zvol. Плануйте його на початку для спеціальних навантажень.

Завдання 12: Слідкувати за реальним I/O latency (швидко знайти болючі точки сховища)

cr0x@server:~$ sudo iostat -x 1 5
Device            r/s   w/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0  85.0     1.2     2.0    0.30   35.0
nvme1n1         118.0  83.0     1.1     1.9    0.28   33.0
sda               2.0  45.0    12.0    28.0    1.40   90.0

Значення: Латентність NVMe низька. Записи на HDD мають вищу await і високе завантаження, що може бути нормою або вашим вузьким місцем.

Рішення: Якщо диски VM на HDD і бачите високий w_await, перемістіть їх на NVMe або переробіть пул.

Завдання 13: Перевірити розмір ARC і тиск пам’яті

cr0x@server:~$ arc_summary | egrep 'ARC Size|ARC Max Size|Memory Throttle'
ARC Size:                               28.3 GiB
ARC Max Size:                           48.0 GiB
Memory Throttle Count:                  0

Значення: ARC активний, але не тротлиться. Якщо Memory Throttle Count зростає — є тиск пам’яті.

Рішення: Якщо тиск пам’яті реальний — додайте RAM або обмежте ARC. Не «оптимізуйте», морячи гостей пам’яттю.

Завдання 14: Визначити основних споживачів CPU і steal time (проблеми планування VM)

cr0x@server:~$ top -b -n 1 | head -20
top - 11:22:19 up 12 days,  3:10,  1 user,  load average: 5.21, 4.88, 4.31
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  4.1 sy,  0.0 ni, 77.1 id,  0.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 128000.0 total,   8200.0 free,  60200.0 used,  59600.0 buff/cache

Значення: Високий wa натякає на I/O wait. Високий st у віртуальному середовищі може вказувати на контенцію хоста, але на bare metal він має бути близький до нуля.

Рішення: Якщо wa високий — переходьте до перевірок сховища. Якщо навантаження високе, а CPU в більшості idle — підозрюйте I/O або блокування.

Завдання 15: Перевірити адекватність конфігурації сховища Proxmox

cr0x@server:~$ pvesm status
Name        Type     Status    Total     Used    Available
local       dir      active    98.0G     7.2G       90.8G
fast        zfspool  active     1.7T   420.0G        1.3T
bulk        zfspool  active    43.5T    12.1T       31.4T

Значення: Ви бачите, куди йде простір. Якщо образи VM потрапляють на local (root), ви от-от заповните ваш завантажувальний диск.

Рішення: Переконайтеся, що образи VM і rootfs контейнерів живуть на правильному пулі, а не на диску ОС.

Завдання 16: Перевірити здоров’я бекапів (PBS або результати vzdump)

cr0x@server:~$ ls -lh /var/lib/vz/dump/ | tail -5
-rw-r----- 1 root root  22G Dec 28 02:10 vzdump-qemu-101-2025_12_28-02_00_01.vma.zst
-rw-r----- 1 root root 1.2G Dec 28 02:14 vzdump-lxc-103-2025_12_28-02_12_10.tar.zst

Значення: Бекапи існують і недавні. Розмір виглядає правдоподібно. Якщо очікували 200 GB, а отримали 2 GB — ви бекапили не те (або стиснення приховало вашу помилку — рідко).

Рішення: Тестуйте відновлення. Успішний бекап без тесту відновлення — це просто оптимістичне логування.

Швидкий план діагностики (як швидко знайти вузьке місце)

Це порядок, який економить час. Мета — перестати гадати і почати звужувати.

Перше: вирішіть, CPU, сховище чи мережа

Підозра на CPU: високе використання CPU на хості, симптоми «ready time» у VM, повільний UI під навантаженням.
Підозра на сховище: високий I/O wait, довге завантаження VM, зависання під час бекапів, кореляція зі scrub/resilver ZFS.
Підозра на мережу: непослідовні трансфери файлів, повільна реплікація, спайки латентності, поведінка «іноді швидко».

Друге: перевірте фізичний рівень і швидкості лінків

Перед тим як торкатись налаштувань ZFS, підтвердьте, що ваш NIC не домовився на 1GbE, не втрачає пакети або не флапає.

Третє: ізолюйте робоче навантаження

Знайдіть, яка VM/контейнер наносять шкоду. У homelab’ах це часто:

неправильно налаштований торрент-клієнт, що треше метадані
база даних виконує vacuum/compaction на HDD
задача бекапу насичує пул у піковий час
надмірне overcommit пам’яті приводить до swap-штормів

Четверте: пошукайте роботи обслуговування ZFS

Scrub, resilver і масивні видалення snapshot можуть перетворити здорову систему на ту, що лагає. Це нормально. Виправлення — планування і місткість, а не пошуки винних.

П’яте: перевірте терміки і тротлінг

Термальний тротлінг виглядає як «випадкова повільність». Це не випадковість. Це фізика.

Три корпоративні короткі історії, з яких варто вчитися

Інцидент через неправильне припущення: «Дзеркала швидкі, отже будь-яке дзеркало підходить»

Середня компанія експлуатувала кластер віртуалізації з дзеркальними SSD на хості. Вони припустили, що «дзеркальні SSD» означає «достатньо швидко для всього». Це було правдою — поки не стало не правдою.

Проблема почалася з рідкісних пауз VM під час нічного вікна бекапів. Нічого драматичного. Потім база даних VM почала таймаутити в робочий час, і команда ганялася за конфігом бази, бо люди так роблять, коли налякані і під кофеїном.

Справжня причина: дзеркало складалося з споживчих QLC-дисків з маленькими SLC-кешами. Під час бекапів і інтенсивних операцій зі snapshot кеши закінчувалися, і диски падали за продуктивністю. Латентність підскочила. Гіпервайзер виглядав винним, бо він чекав.

У них було моніторинг, але він фокусувався на пропускній здатності, а не на перцентилях латентності. Тож графіки виглядали «добре», поки користувачі страждали. Виправлення було нудним: замінити диски на моделі зі стабільними записами та вивести підготовку бекапів з основного пулу VM.

Урок: «SSD дзеркало» не гарантія продуктивності. Стійкі характеристики запису важливіші за ярлик.

Оптимізація, що зіграла проти: «Додамо L2ARC, щоб пришвидшити читання»

Інша команда мала великий ZFS-пул і хотіла пришвидшити читання для файлового навантаження. Вони додали великий L2ARC SSD і тиждень святкували, бо бенчмарки покращились.

Потім система почала поводитися дивно: події тиску пам’яті, випадкові рестарти сервісів і падіння продуктивності, що виглядало як паузи GC. Вони звинувачували ядро. Потім — додаток. Потім — одне одного, що є традиційною дорогою ескалації.

Причина була тонкою, але класичною: наклад L2ARC з’їдав RAM для метаданих, скорочуючи ефективність ARC і збільшуючи тиск на систему. Навантаження не було достатньо «read-hot», щоб виправдати такий L2ARC, а кешування призводило до ще більшого перемішування. Вони фактично поміняли передбачуване кешування в RAM на складний SSD-кеш, що не відповідав патерну доступу.

Виправлення — видалити надмірний L2ARC, додати RAM і налаштувати доступи додатку. Пізніше вони повернули маленький L2ARC з жорсткими обмеженнями після вимірювання реальних показників попадань.

Урок: Додавання кешу може знизити продуктивність, якщо воно відбирає ресурс, який вам насправді потрібен (RAM) і не відповідає навантаженню.

Нудна, але правильна практика, що врятувала день: «Ми тестували відновлення щомісяця»

Третя організація працювала з Proxmox, ZFS і окремою системою бекапів. Нічого особливого. У них була одна звичка майже старомодна: щомісяця вони вибирали випадкову VM і виконували повне відновлення в ізольованій мережі, після чого перевіряли функціональність на рівні додатку.

Одного дня оновлення прошивки контролера сховища ввело періодичні скидання під важким I/O. Першою ознакою не був мертвий хост; першою ознакою були пошкоджені диски VM на одному вузлі після особливо жорсткого скидання під час записів. ZFS зробив, що міг, але кілька файлових систем гостьових ОС були некоректні.

Оскільки вони репетирували відновлення, реакція була спокійною. Вони ізолювали вузол, відновили постраждалі VM з відомих добрих бекапів і зберегли бізнес працюючим, поки виробник фіксував свою прошивку.

Ніяких героїв. Ніякого «може, все нормально». Просто відпрацьоване відновлення.

Урок: Тестування відновлення — це операційні відсотки складного капіталу. Це нудно, поки не стане єдиним, що має значення.

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: завантаження VM повільні, але бенчмарки пропускної здатності в порядку

Корінь проблеми: спайки латентності від виснаження кеша SSD, пул майже повний або активність обслуговування ZFS (scrub/resilver/видалення snapshot).

Виправлення: тримайте пули ZFS у комфортному використанні (не живіть на 90%), плануйте scrubs, виводьте write-heavy задачі з VM-пулу і використовуйте SSD зі стабільними тривалими записами.

2) Симптом: копії по мережі зупиняються приблизно на ~110 MB/s на «10GbE»

Корінь проблеми: лінк домовився на 1GbE, поганий трансивер/кабель або порт комутатора налаштовано неправильно.

Виправлення: перевірити за допомогою ethtool, поміняти DAC/трансивер, підтвердити конфіг комутатора. Не налаштовуйте TCP буфери, щоб виправити фізичну проблему.

3) Симптом: хост Proxmox випадково фрізить під навантаженням

Корінь проблеми: тиск пам’яті і swap-шторм, NVMe thermal throttling або нестабільна подача живлення.

Виправлення: перевірити dmesg на OOM і помилки NVMe, додати RAM, обмежити ARC, поліпшити охолодження і використовувати якісний PSU + UPS.

4) Симптом: scrub ZFS займає вічність і система пригальмовує

Корінь проблеми: пул з HDD з високим заповненням або конфлікт resilver/scrub з активним навантаженням.

Виправлення: запускати scrubs у неробочий час, розглянути дзеркала для IOPS-важких випадків і тримати запасну ємність. Якщо ви не можете комфортно проскрабити — ви переповнені.

5) Симптом: бекапи «успішні», але відновлення не вдається або неповні

Корінь проблеми: бекапите неправильне сховище, виключаєте змонтовані томи або тиха корупція не виявляється, бо відновлення не тестували.

Виправлення: регулярно тестуйте відновлення, переконайтеся, що бекап включає потрібні диски, і зберігайте бекапи на окремому обладнанні коли можливо.

6) Симптом: Ceph кластер працює до перезавантаження одного вузла, потім все повзає

Корінь проблеми: недопроєктована мережа, OSD на змішаних дисках різної якості або недостатньо RAM/CPU для накладних витрат Ceph.

Виправлення: не запускайте Ceph на «запасному» обладнанні. Якщо хочете HA — робіть це правильно: швидка мережа, послідовні диски і достатньо пам’яті.

7) Симптом: passthrough PCIe нестабільний або пристрої зникають після перезавантаження

Корінь проблеми: погана IOMMU група, BIOS-косяки, шаринг ліній або проблеми з управлінням живленням.

Виправлення: перевірте IOMMU групи, оновіть BIOS, уникайте riser-ів і вимкніть проблемні ASPM налаштування для постраждалих пристроїв.

Контрольні списки / покроковий план

Покроковий план: один вузол «серйозний homelab»

Виберіть платформу: стабільна материнська плата, ECC якщо можливо, щонайменше два PCIe слоти і два M.2 слоти.
Виберіть пам’ять: мінімум 64 GB, 128 GB якщо багато VM, активний ZFS або хочете запас.
Мережа: SFP+ 10GbE NIC якщо реплікуєте або маєте backup server; інакше 2.5GbE може бути прийнятним.
Boot mirror: два маленькі SSD у дзеркалі; тримайте ОС окремо від VM pool.
VM pool: NVMe дзеркало, пріоритет — витривалість і стабільні тривалі записи.
Bulk pool: RAIDZ2 для ємності; дзеркала якщо потрібні IOPS більше ніж ТБ.
Бекапи: окремий PBS вузол, якщо вам не байдужі дані. Якщо ні — хоча б окремі datasets і квоти.
Моніторинг: відстежуйте латентність (disk await), SMART/NVMe wear, стан пулу ZFS і швидкість лінків. Лише пропускна здатність — брехун.
Репетиція відновлення: щомісячне відновлення випадкової VM в ізольовану VLAN.

Покроковий план: три вузли для вивчення HA

Уніфікуйте вузли: однакові NIC, моделі дисків де можливо, однакові налаштування BIOS.
Мережа першою: 10GbE комутатор, чистий VLAN-план, виділена VLAN для зберігання/реплікації якщо можливо.
Визначте модель зберігання: локальний ZFS + реплікація (рекомендується) або Ceph (тільки якщо готові оперувати Ceph).
Увага до кворуму: плануйте, що станеться при відключенні вузла. Додайте qdevice для двовузлових варіантів, але краще мати три реальні вузли.
Бекапи залишаються окремими: реплікація — не резервне копіювання. PBS все ще важливий.
Дисципліна оновлень: поетапні оновлення, по одному вузлу, з планом відкату.

Список перевірок під час збірки: не пропускайте

BIOS оновлено до стабільного релізу (не обов’язково найновішого).
Віртуалізація + IOMMU увімкнені.
Тест пам’яті виконано за ніч, якщо дозволяє час.
NVMe температури перевірено під навантаженням; немає тротлінгу.
Швидкість лінку перевірена на хості і на комутаторі.
Топологія пулу ZFS перевірена перед тим, як дані попали.
Розклад scrub встановлено і перший scrub проглянуто.
Бекапи налаштовано і одне тестове відновлення виконано.

Часті питання

1) Чи запускати Proxmox на ZFS чи ext4/LVM?

Якщо вам важливі snapshot-и, цілісність і передбачувані операції — використовуйте ZFS. Якщо потрібен найпростіший набір і ви приймаєте менше захисту — ext4/LVM підійде. Для більшості серйозних homelab’ів: ZFS.

2) Дзеркало чи RAIDZ для зберігання VM?

Дзеркала для VM, якщо ваше навантаження не в основному послідовне і не толерантне до латентності. Дзеркала дають кращі IOPS і простішу поведінку при відновленні. RAIDZ чудовий для масивної ємності і медіа.

3) Чи потрібна ECC-пам’ять?

Це не обов’язково, але хороша ідея, якщо ви використовуєте ZFS і дбаєте про цілісність. Більш важливо те, що платформи з підтримкою ECC зазвичай зроблені не як іграшки. Якщо різниця в ціні невелика — купуйте ECC.

4) Чи достатньо 2.5GbE у 2026?

Для одного вузла з локальним сховищем — так. Для реплікації, спільного зберігання або частих бекапів ви відчуєте обмеження. 10GbE (SFP+) — чисте підвищення.

5) Чи потрібен SLOG для ZFS?

Тільки якщо ви обслуговуєте sync-записи (зазвичай NFS/iSCSI з sync увімкненим) і виміряли, що ZIL-шлях — вузьке місце. Інакше не купуйте SLOG просто щоб відчувати продуктивність.

6) Чи можна запускати Ceph на трьох маленьких вузлах?

Можна, і ви багато чого навчитеся — головно чому production Ceph любить швидкі мережі, багато RAM і однорідні диски. Для «я хочу, щоб сервіси були нудними» — local ZFS + реплікація зазвичай краще.

7) Яка найкраща конфігурація завантажувальних дисків?

Два маленькі SSD у дзеркалі. Тримайте ОС окремо від головного сховища. Якщо завантажувальне дзеркало помре — це незручність, а не катастрофа.

8) Наскільки заповненим може бути пул ZFS?

Не експлуатуйте його як валізу, яку ви сидите, щоб застебнути. Коли пули заповнюються, фрагментація і проблеми з продуктивністю зростають. Тримайте значущий вільний простір, особливо на VM-пулах.

9) Чи варто використовувати special vdev у HDD-пулі?

Тільки якщо ви розумієте домен відмов: втрата special vdev = втрата пулу. Якщо робите — дзеркальте його і агресивно моніторьте.

10) Який найпростіший надійний підхід до бекапу?

Proxmox Backup Server на окремому обладнанні, бекапи щодня з розумними політиками збереження і періодичною відправкою копій за межі сайту. І тест відновлення. Останнє — найважливіше.

Висновок: практичні подальші кроки

Будуйте для передбачуваної латентності, нудного відновлення і енергії, з якою можна жити. Переможе не той homelab 2026 з найбільшою кількістю ядер; переможе той, що не дивує вас.

Визначте архітектуру: один солідний вузол або три вузли з реплікацією.
Купіть NIC і комутатор з оглядом на стабільність драйверів і перевірку швидкості лінку.
Розділіть сховище на окремі зони: boot mirror, швидкий VM pool, bulk pool і бекапи поза хостом якщо можливо.
Виконайте перелічені вище командні завдання в перший день. Збережіть виводи. Вони стануть вашою базовою лінією.
Заплануйте scrubs, бекапи і тест відновлення. Запишіть це в календар як платіж за житло.

Схожі статті

Proxmox vs VMware ESXi: який гіпервізор обрати у 2026 році?