Сховище для віртуалізації на Proxmox: ZFS vs Ceph vs iSCSI vs NFS

Правила прийняття рішень, які реально працюють

Якщо запам’ятати одне — пам’ятайте це: ви не обираєте «сховище», ви обираєте моделі відмов. Продуктивність — це функція; передбачуваність — це продукт.

Обирайте ZFS (локально), коли

• Ви можете терпіти, що сховище одного вузла не буде автоматично спільним.
• Ви хочете сильну цілісність даних і прозору поведінку під час відновлення.
• Ваше навантаження переважно — «VM живе на вузлі, на якому запускається», а міграції/HA робляться через реплікацію або бекапи.
• Ви цінуєте операційну простоту: одна коробка, один пул, один набір інструментів.

Орієнтовна порада: Для 1–3 вузлів ZFS — стандартна відповідь, якщо у вас немає жорсткої вимоги до спільного блочного сховища і міграцій без планування.

Обирайте Ceph, коли

• Вам потрібно спільне сховище між багатьма гіпервізорами і ви очікуєте, що вузли можуть падати без драм.
• Ви можете дозволити собі 3+ вузли (справді) і достатньо дисків, щоб реплікація була осмисленою.
• У вас є мережа, що це витримає: низька затримка, без оверсабскрайбу, бажано виділена для трафіку сховища.
• Ви готові свідомо керувати розподіленою системою, а не робити це випадково.

Орієнтовна порада: Ceph чудовий, коли у вас є кластер. Це хобі, якщо у вас два вузли й мрія.

Обирайте iSCSI, коли

• Ви вже маєте масив/САН, що робить snapshots, реплікацію та має контракт підтримки.
• Ви хочете блочні семантики і центральне управління сховищем.
• Ви вмієте налаштувати multipath правильно і розумієте зону ураження одного масиву.

Орієнтовна порада: iSCSI підходить, якщо масив — це продукт. Якщо ваш «масив» — це Linux VM з парою дисків, ви винаходите розчарування заново.

Обирайте NFS, коли

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

Орієнтовна порада: NFS — мінівен серед сховищ для віртуалізації: не сексуальний, але майже завжди достатній, і кожен має думку про підсклянники.

Парафразована цитата: ідея надійності Джима Грея (перефразовано): якщо ви не можете пояснити модель відмов, у вас немає системи — лише демо.

Ментальна модель: що віртуальні машини роблять зі сховищем

Віртуальні машини роблять три речі, які сховище не любить:

• Випадкові записи від кількох гостей одночасно. Навіть «послідовні» записи гостя фрагментуються хостом.
• Хаос метаданих: знімки, клонування, тонке розподілення та copy-on-write перетворюють «запис даних» на «запис даних плюс облік».
• Чутливість до затримок: VM — це шар планувальників. Додайте 5 ms на шарі сховища, і ви можете отримати +50 ms «чому SSH лагає?» зверху.

Далі додаються особливості Proxmox:

• Диски VM можуть бути raw (найкраще), qcow2 (багатофункціонально, але з накладними витратами) або RBD (блок Ceph).
• Бекапи і знімки робляться на хості, а не в гості — це чудово, доки ваша підсистема сховища не інтерпретує це як «неочікуване збільшення записів».
• Жива міграція хоче спільне сховище або швидке копіювання. «Швидке копіювання» все одно залишається копіюванням. Копіювання — це IO.

Тож питання: де ви хочете локалізувати складність — на кожному вузлі (ZFS), у спільному NAS/SAN (NFS/iSCSI) чи в тканині вашого кластера (Ceph)?

Жарт 1/2: Сховище — єдине місце, де «в тестуванні працювало» означає «ніхто не тестував гучного сусіда VM».

ZFS на Proxmox: локальний підхід, пріоритет — надійність

ZFS — це файлова система й менеджер томів, який ніби особисто ображений на тихі розриви цілісності. Контрольні суми скрізь. Copy-on-write семантика. Знімки, які дійсно корисні. Send/receive реплікація, яка нудна в найкращому сенсі.

У чому ZFS чудовий для віртуалізації

• Передбачуване відновлення: mirrored vdev втрачає диск — ви його замінюєте, запускаєте resilver. Ніякої магії.
• Знімки з реально працюючими інструментами: ZFS snapshots дешеві; їхня ціна — довгострокова фрагментація й ріст метаданих, якщо тримати занадто багато.
• Локальна продуктивність: з NVMe-міррорами й достатнім обсягом RAM ZFS дуже швидкий для VM-навантажень.
• Цілісність даних: end-to-end контрольні суми ловлять погані диски, кабелі, контролери й погані дні.

Чим ZFS не є

ZFS за замовчуванням не є спільним сховищем. Ви можете реплікувати, робити бекапи, будувати шар вище, але сам ZFS не дасть прозорого спільного блочного сховища між вузлами.

Правила проєктування, що тримають вас у безпеці

• Міррори кращі за RAIDZ для затримок VM. RAIDZ підходить для ємнісних, читально-важких, послідовних навантажень. Випадкові записи VM — не та робота.
• Не одержуйте одержимості SLOG, якщо не розумієте sync-записи. Для багатьох VM-навантажень SLOG не потрібен або потрібен дуже хороший. Дешевий «SLOG SSD» може стати пасткою, якщо він бреше про захист від втрати живлення.
• Використовуйте raw диски/томи де можливо. qcow2 дає можливості; він також додає накладні витрати. ZVOL або raw-файли зазвичай працюють краще для гарячого IO.
• Контролюйте кількість знімків. Сотні знімків на зайнятих VM-датасетах поступово перетворять ваш «швидкий пул» на «швидкий пул (історична реконструкція)».

Налаштування, що мають значення (і чому)

Три важливі ручки з’являються в постмортемах частіше, ніж повинні:

• ashift (вирівнювання розміру сектора). Помилка при створенні пулу закладає write amplification.
• recordsize / volblocksize. Невідповідність робочому навантаженню веде до марнування IO або подвоєння записів.
• sync. «sync=disabled» — це спосіб перетворити батарею UPS на лотерею втрати даних.

Ceph на Proxmox: розподілене сховище з реальною потужністю

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

У чому Ceph чудовий

• Спільне блочне сховище (RBD) між хостами, з живою міграцією, що не потребує копіювання дисків.
• Толерантність до відмов, якщо правильно спроєктовано: OSD впав, хост впав, диски померли — кластер продовжує обслуговувати.
• Операційна ефективність на масштабі: додаєте вузли, OSD, ребаланс, продовжуєте працювати.

Чого потребує Ceph

• Якість мережі: затримки й втрата пакетів проявляються як «випадкове сповільнення VM» і «заблоковані задачі».
• Бюджет IOPS: реплікація означає, що ви платите за записи кілька разів. Малі записи множаться і журналюються. Це не опціонально.
• Резерв ємності: робота поблизу заповненості — це не «ефективність», це уривчастий обрив продуктивності. Ребаланс потребує простору.
• Операційна зрілість: ви маєте вміти інтерпретувати стан кластера, стани backfill та поведінку placement group без панічних кліків.

Ceph для Proxmox: практичні поради

Для дисків VM використовуйте RBD, якщо у вас немає специфічної потреби в POSIX-файловій системі; CephFS чудовий для спільних файлів, але зазвичай не найкращий вибір для «гарячих» VM-дисків. Якщо ваше навантаження чутливе до затримок і багато записів, плануйте швидкі OSD (NVMe або дуже хороші SSD) та реальну мережу для сховища.

Тюнінг Ceph — це менше магічних sysctl і більше адекватної архітектури: достатньо OSD, відповідна реплікація, достатньо CPU на хості й не запуск Ceph на тих самих слабких вузлах, що ви хочете використовувати для обчислень.

Жарт 2/2: Ceph — «простий» так само, як і контейнерні контейнери — «лише коробка». Цікавими є всі речі навколо неї.

iSCSI: блочне сховище з різкими краями

iSCSI — це блочне сховище поверх IP. Воно не сучасне, не модне і не зникне. У корпоративному середовищі це часто шлях найменшого опору, бо вже є SAN і команда, що говорить мовою LUN.

Коли iSCSI — правильна відповідь

• Вам потрібне спільне блочне сховище і ви довіряєте масиву більше, ніж DIY-розподіленому сховищу.
• Ви хочете центральні знімки/реплікацію, які обробляє масив (і вендор бере нічні дзвінки).
• Ви можете реалізувати multipath і резервні мережі правильно.

Моделі відмов, які треба прийняти

• Централізована зона ураження: збій масиву болить для всього кластеру.
• Чутливість до мережевого шляху: мікропропуски та неправильно налаштований MTU можуть виглядати як «корупція диска VM», коли насправді це таймаути й скиди.
• Взаємодія глибини черги й затримок: один балакучий VM може загнати LUN у хвостову латентність, якщо масив не забезпечений належним чином.

У Proxmox часто поєднують iSCSI з LVM або ZFS поверх iSCSI (так, можна, але робіть це свідомо). Якщо у вас вже є ZFS локально, ставити ZFS поверх iSCSI зазвичай означає подвоєння складності без очевидної вигоди.

NFS: просте спільне сховище (поки не перестане бути простим)

NFS — це файлове сховище по мережі. Воно легко налаштовується, просто для розуміння та просто перерастає. Для багатьох кластерів Proxmox це правильний компроміс: спільне сховище для ISO/шаблонів/бекапів і навіть для VM-дисків, якщо вимоги до продуктивності помірні та сервер добрий.

NFS блищить, коли

• Ви хочете спільне сховище без запуску розподіленої системи зберігання.
• Ви цінуєте просте відновлення: змонтували експорт деінде — файли на місці.
• Ваше навантаження не надто чутливе до затримок або важких записів.

NFS болить, коли

• Ваш NAS недостатньо потужний і стає єдиною точкою звуження.
• Параметри монтування невірні для образів VM (кешування й блокування важливі).
• Ви поводитеся з NFS як з блочним сховищем і очікуєте, що воно буде поводитися як SAN.

Proxmox добре підтримує NFS. Просто не прикидайтеся, що це магія. NFS-сервер тепер критична залежність: моніторте його, патчуйте і дайте йому дискову підсистему, яка не впаде під час scrub/відновлення RAID.

Цікаві факти та трохи історії (корисний варіант)

1. ZFS з’явився в Sun Microsystems у середині 2000-х з end-to-end контрольними сумами як базовою функцією, а не доповненням.
2. Copy-on-write передує сучасній віртуалізації; це стара ідея, яка стала масовою через те, що знімки й клони — операційне золото.
3. Ceph починався як університетський проєкт і став великим open-source сховищем, яке широко використовували в епоху OpenStack приватних хмар.
4. RBD з’явився, бо файлові системи були недостатні для хмарних блочних семантик: образи, клони й знімки масштабувалися краще з нативним блочним інтерфейсом.
5. NFS існує з 1980-х і досі живе, бо «спільна файлова система» — фундаментальна потреба, і її достатньо просто відлагодити на рівні пакетів.
6. iSCSI стандартизували на початку 2000-х щоб принести доступ SAN до звичайних Ethernet-мереж.
7. Write amplification — це не теоретична проблема: COW-файлові системи плюс VM-навантаження можуть значно примножувати бекенд-записи, особливо при знімках і малих блоках.
8. CRUSH-алгоритм Ceph спроєктований, щоб уникнути центральних таблиць для розміщення даних, що важливо при масштабуванні.
9. Proxmox популяризував «batteries included» кластеризацію для малих і середніх компаній: ви отримуєте KVM, управління, бекапи й інтеграцію сховища без складання десятка компонентів самотужки.

12+ практичних завдань: команди, вивід, рішення

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

Завдання 1: Визначити бекенд сховища для VM

cr0x@server:~$ qm config 101
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app01
scsi0: local-zfs:vm-101-disk-0,size=120G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0

Значення: local-zfs каже, що це том на ZFS на цьому вузлі, а не спільний. Якщо ви очікували спільне сховище для живої міграції — от і розбіжність.

Рішення: Для HA/живої міграції без простоїв або перемістіть диск VM на Ceph/NFS/iSCSI, або реалізуйте ZFS-реплікацію + плановий failover.

Завдання 2: Підтвердити, які сховища бачить Proxmox

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      102305280        25165824        77175168   24.60%
local-zfs        zfspool  active     9999220736      2130706432      7868514304   21.31%
ceph-rbd         rbd      active    29997662208      8996782080     209,?         29.99%

Значення: Підтверджує, які бекенди онлайн і чи Proxmox до них добирається. Якщо Ceph показує дивну місткість або стає inactive — припиніть звинувачувати «VM».

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

Завдання 3: Перевірка здоров’я ZFS (не гадати)

cr0x@server:~$ zpool status -x
all pools are healthy

Значення: Пул здоровий. Якщо продуктивність погана, це не через те, що ZFS наразі деградований.

Рішення: Якщо звітується degraded vdev або checksum errors, припиніть працювати над продуктивністю і почніть працювати над безпекою даних.

Завдання 4: Перевірити розкладку ZFS pool (mirror vs RAIDZ)

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

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0

Значення: Mirror vdev. Добре для затримок VM. Якщо бачите RAIDZ1/2 з малою кількістю дисків і write-heavy VM — очікуйте більшу хвостову латентність.

Рішення: Якщо проблеми з латентністю VM і ви на RAIDZ, подумайте про міграцію «гарячих» VM на mirrors або SSD/NVMe vdev.

Завдання 5: Перевірити властивості ZFS, що впливають на поведінку VM

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,sync tank/vmdata
NAME         PROPERTY     VALUE
tank/vmdata  atime        off
tank/vmdata  compression  lz4
tank/vmdata  recordsize   128K
tank/vmdata  sync         standard

Значення: Розумні значення за замовчуванням: lz4 частіше допомагає; atime=off уникнути записів метаданих; sync=standard — безпечно.

Рішення: Якщо бачите sync=disabled на VM-датасетах, вирішіть, чи готові ви втратити недавні записи після збою. Більшість продакшенів не повинні цього робити.

Завдання 6: Знайти тиск на ARC (RAM як компонент продуктивності)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   812    74      9     9   12    65   88     0    0   48G   56G
12:01:02   790    80     10     8   10    72   90     0    0   48G   56G
12:01:03   805    77     10     7    9    70   91     0    0   48G   56G

Значення: Розмір ARC проти цілі (arcsz vs c) і показник промахів. Високий miss rate під час стабільного навантаження може означати, що робочий набір не поміщається в RAM.

Рішення: Якщо промахи постійно високі і диски зайняті, додайте RAM або перемістіть гарячі навантаження на швидший носій; не займайтесь мікроналаштуванням перед правильним розміром.

Завдання 7: Перевірити живу IO-латентність на хості

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12-pve (pve1)  12/28/25  _x86_64_  (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   310.0  4096.0 18560.0   2.10   0.25  11.0
nvme1n1         118.0   305.0  4000.0 18200.0   2.35   0.24  10.7

Значення: await — практичний показник «наскільки це погано відчувається». Якщо await 20–200 ms, гості скаржитимуться. Якщо %util на 100%, ви наситили ресурс.

Рішення: Високий await при низькому util вказує на чергу в іншому місці (контролер, блокування файлової системи, мережа). Високий await при високому util — треба більше шпинделів/IOPS.

Завдання 8: Відобразити процес/VM, який робить IO

cr0x@server:~$ pvesh get /nodes/pve1/qemu --output-format json-pretty
[
  {
    "cpu": 0.17,
    "diskread": 1610612736,
    "diskwrite": 987654321,
    "mem": 0.62,
    "name": "db01",
    "pid": 24510,
    "status": "running",
    "uptime": 182003,
    "vmid": 110
  },
  {
    "cpu": 0.04,
    "diskread": 10485760,
    "diskwrite": 7340032,
    "mem": 0.28,
    "name": "app01",
    "pid": 25111,
    "status": "running",
    "uptime": 55321,
    "vmid": 101
  }
]

Значення: Швидкий огляд по VM. VM «db01» робить значний IO. Корелюйте з метриками затримки.

Рішення: Якщо один VM домінує в IO і спричиняє шкоду іншим, ізолюйте його (виділений пул, QoS, окремий клас OSD або перемістіть з NFS).

Завдання 9: Перевірка NFS-монтажу (параметри мають значення)

cr0x@server:~$ findmnt -t nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET           SOURCE                  FSTYPE OPTIONS
/mnt/pve/nfs-vm  nas01:/export/proxmox   nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys

Значення: Ви хочете hard монтування для образів VM (щоб уникнути тихої корупції через короткі записи), і розумні rsize/wsize. NFSv4.2 зазвичай підходить, якщо NAS його підтримує.

Рішення: Якщо бачите soft монтування — виправте. «Soft» для некритичних читань, не для дисків VM.

Завдання 10: Перевірка латентності NFS-сервера з клієнта

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
1248933    120        0

Client nfs v4:
ops count  retrans
READ 402911  18
WRITE 311220 47
COMMIT 1021   0

Значення: Переспроби (retransmits) вказують на проблеми мережі/сервера. Декілька бувають; зростання корелює зі зависаннями і фризами VM.

Рішення: Якщо retrans стрибає під час інцидентів — припиніть налаштовувати Proxmox і перевірте навантаження NAS, помилки NIC, буфери комутаторів, несумісний MTU.

Завдання 11: Сесія iSCSI та статус multipath

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.10.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)
tcp: [2] 10.10.11.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)

cr0x@server:~$ multipath -ll
mpatha (3600a098038314c6a6b5d4a6f4b6a6f30) dm-3 VENDOR,Array
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Значення: Дві iSCSI-сесії: ймовірно дві fabric/VLAN. Multipath показує активний шлях і включений шлях. Якщо є лише один шлях — немає резервування.

Рішення: Якщо шляхи стрибають або один впав — виправляйте мережу перед тим, як звинувачувати масив або Proxmox.

Завдання 12: Стан кластера Ceph на швидку руку

cr0x@server:~$ ceph -s
  cluster:
    id:     3c3b1e2d-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 12 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 4h)
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   2 pools, 128 pgs
    objects: 1.02M objects, 3.9 TiB
    usage:   11 TiB used, 22 TiB / 33 TiB avail
    pgs:     127 active+clean, 1 active+clean+scrubbing

Значення: «slow ops» — червоний прапорець для затримок. Триває scrub. Іноді scrub збігається з видимими для користувачів ривками.

Рішення: Якщо slow ops не проходять — перевіряйте латентність OSD і мережу. Якщо scrub дає біль, регулюйте вікна scrub і пріоритети замість постійного відключення scrub.

Завдання 13: Латентність OSD Ceph і перф-лічильники

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    3                   4
1    4                   5
2    45                  52
3    3                   4

Значення: OSD 2 хворіє в порівнянні з піром. Часто це поганий диск, насичений пристрій або галасливий сусід на тому ж вузлі.

Рішення: Якщо потрібно — відлити/помітити OSD як out, або дослідити конкретний хост/диск. Не «налаштовуйте Ceph» глобально, щоб компенсувати один проблемний пристрій.

Завдання 14: Перевірити тиск від бекапів Proxmox (сховище може бути в порядку, а бекапи вбивають)

cr0x@server:~$ grep -E "vzdump|INFO:|ERROR:" /var/log/syslog | tail -n 8
Dec 28 01:10:02 pve1 vzdump[31120]: INFO: starting new backup job: vzdump 110 --storage nfs-backup --mode snapshot
Dec 28 01:10:05 pve1 vzdump[31120]: INFO: VM 110 - starting backup
Dec 28 01:10:09 pve1 vzdump[31120]: INFO: VM 110 - using inotify to track modifications
Dec 28 01:12:41 pve1 vzdump[31120]: INFO: VM 110 - backup finished

Значення: Бекапи працювали в часі болю. Snapshot-режим хороший, але все одно генерує читальний IO і роботу з метаданими.

Рішення: Якщо латентність сховища корелює з вікнами бекапів — змініть графік, обмежте паралельність або перемістіть цілі бекапів з того самого вузького місця.

Швидкий план діагностики: що перевірити першим/другим/третім

Це порядок, який швидко дає відповіді. Мета не в досконалості; мета — припинити суперечки і ізолювати шар.

Перше: визначити, локально це на хості, спільне чи мережеве

• Перевірте місце диска VM: qm config <vmid>.
• Перевірте список сховищ: pvesm status.
• Якщо це Ceph/NFS/iSCSI — припускайте, що мережа залучена, доки не доведено протилежне.

Друге: виміряти затримки там, де це має значення

• Латентність диска на хості: iostat -x 1.
• Ceph «slow ops» і ceph osd perf.
• NFS retransmits: nfsstat -c.
• iSCSI здоров’я шляхів: multipath -ll.

Третє: перевірити стани деградації/відновлення

• ZFS: zpool status для resilver/scrub/checksum errors.
• Ceph: recovery/backfill/scrub у ceph -s.
• NAS/масив: чи він відновлюється, робить scrub або знімки?

Четверте: знайти «бовдура» VM і кореляцію по часу

• Лічильники IO по VM: pvesh get /nodes/<node>/qemu.
• Перевірте вікна бекапів і завдання знімків.
• Шукайте орендаря, який насичує спільні черги.

П’яте: перевірити нудні, але важливі речі

• Помилки NIC та дропи: ip -s link, лічильники комутаторів.
• Сумісність MTU (особливо якщо ви пробували jumbo frames).
• CPU steal/ready і IO wait: більшість болю сховища може маскуватися як конкуренція за CPU.

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

1) VM зависає на 30–120 секунд на NFS

Симптоми: Логи гостя показують таймаути диска; хост показує повідомлення «server not responding»; потім все відновлюється.

Корінь: Збій NFS-сервера (навантаження, латентність сховища або втрата мережі). Hard-монти змушують клієнтів чекати (це безпечніше, ніж корупція даних).

Виправлення: Усуньте вузьке місце NAS або мережі. Перевірте параметри findmnt. Подумайте про переміщення чутливих VM на локальні ZFS-міррори або Ceph RBD.

2) ZFS пул виглядає здоровим, але VM повільні під час знімків

Симптоми: Спайки латентності під час вікон бекапів; IO стає випадковим; промахи ARC ростуть.

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

Виправлення: Зменште кількість/утримання знімків, рознесіть бекапи у часі, тримайте гарячі датасети окремо і віддавайте перевагу raw/ZVOL для критичних дисків.

3) Ceph спочатку швидкий, а потім раптом «липкий»

Симптоми: HEALTH_WARN slow ops; jitter IO VM; іноді блоковані задачі.

Корінь: Робота поблизу заповненості або повільно деградуючий OSD. Backfill/recovery конкурує з клієнтським IO.

Виправлення: Підтримуйте простір у запасі, замінюйте диски раніше, плануйте scrub, не ігноруйте один повільний OSD у ceph osd perf.

4) iSCSI «працює», але в гостях рандомні помилки файлової системи

Симптоми: Гості показують помилки ext4/xfs; multipath показує флапи шляхів; dmesg має SCSI resets.

Корінь: Нестабільний мережевий шлях, неправильний MTU, погані кабелі/оптика або невірне налаштування multipath/таймаутів.

Виправлення: Стабілізуйте лінки, забезпечте резервні шляхи, вирівняйте MTU наскрізь і перевірте здоров’я multipath. Не ховайте проблему за повторними спробами.

5) ZFS «sync=disabled» зробило швидше… доки не моргнуло світло

Симптоми: Після збою деякі VM завантажуються з корумпованими файловими системами; бази даних потребують ремонту.

Корінь: Вимкнення sync підтверджувало записи до їхньої безпеки на стабільних носіях.

Виправлення: Поверніть sync до standard, додайте коректний SLOG з захистом від втрати живлення, якщо потрібна латентність sync-записів, і використовуйте UPS правильно (але UPS — не повна заміна).

6) Ceph на 1 GbE «якось працює», але міграції жахливі

Симптоми: Висока латентність у пікові години; клієнтський IO стає повільним; відновлення триває вічно.

Корінь: Мережа — це шина Ceph. 1 GbE — податок, який ви платите за кожен запис.

Виправлення: Оновіть принаймні до 10 GbE (часто 25 GbE у серйозних розгортаннях), відокремте трафік сховища і перестаньте ставитись до мережі як до опції.

Чек-листи / покроковий план

Якщо ви будуєте 1–3 вузлову інсталяцію Proxmox

1. За замовчуванням — локальні ZFS-міррори для дисків VM.
2. Використовуйте окреме сховище (зазвичай NFS) для ISO/шаблонів/бекапів.
3. Вирішіть наперед, як керуватимете відмовою вузла:
   • ZFS-реплікація між вузлами для важливих VM, або
   • Відновлення з бекапів з визначеним RTO/RPO.
4. Розрахуйте RAM з урахуванням ARC; не позбавляйте ZFS пам’яті.
5. Тримайте політику знімків у межах; проєктуйте графіки бекапів навколо IO.

Якщо ви будуєте кластер 4+ вузлів і хочете спільне сховище VM

1. Обирайте Ceph RBD, якщо можете надати:
   • мінімум 3+ вузли (для кворуму і реплікації),
   • швидкі пристрої зберігання,
   • серйозну мережу для сховища.
2. Відокремте домени відмов: хост, диск, стійка (rack), якщо є.
3. Плануйте резерв ємності: не працюйте близько до заповнення.
4. Автоматизуйте перевірки здоров’я: slow ops, OSD perf, вікна scrub.
5. Тестуйте відмови: витягніть OSD, перезавантажте вузол, перевірте відновлення й вплив на латентність VM.

Якщо ваша компанія вже має SAN/NAS

1. Використовуйте iSCSI для блочного сховища VM, якщо масив перевірений і підтримується.
2. Використовуйте NFS для спільних файлів, шаблонів і бекапів там, де файлові семантики допомагають.
3. Реалізуйте multipath і резервні комутатори серйозно.
4. Отримайте доступ до телеметрії масиву, інакше ви будете діагностувати в сліпу.

Проста матриця «що обрати»

• ZFS: найкраще для одно- або мало вузлової продуктивності та цілісності даних; спільне сховище через реплікацію/бекапи.
• Ceph: найкраще для спільного сховища й стійкості на масштабі; вимагає мережі й операційної зрілості.
• iSCSI: найкраще, коли у вас уже є справжній масив; велика зона ураження, але передбачувано при хорошому масиві.
• NFS: найпростіше для спільних файлів; підходить для VM-дисків при хорошому NAS і помірних навантаженнях.

Три корпоративні історії з полів сховища

Інцидент через хибне припущення: «NFS — це просто повільніший локальний диск»

У них був акуратний кластер Proxmox: три compute-вузли й один NAS-апарат, який усім подобався через дружній UI і миготливі лампочки. Диски VM жили на NFS, бо це спрощувало міграцію, і команда сховища казала «він же надлишковий».

Припущення було, що NFS поводиться як повільніший локальний диск. Тобто: якщо NAS завантажений — VM повільнішають. Реальна поведінка суворіша: якщо NAS затримається достатньо довго, клієнти жорстко зависають. Це не баг; це те, як «hard mounts» зберігають коректність.

Одного дня запланований scrub NAS перетнувся з бекап-джобом Proxmox. NAS не впав. Він просто довше відповідав. Ядерні модулі гостей почали логувати таймаути IO. Бази даних зробили те, що роблять бази даних, коли їх налякати: перестали довіряти власному стану.

Постмортем був неприємний, бо графік, який усі дивилися, був throughput. Throughput здавався нормальним. Убивцею була латентність, і ніхто не графував NFS retransmits або глибину черги дисків NAS.

Виправлення було нудним: перемістити чутливі VM на локальні ZFS-міррори, залишити NFS для бекапів/шаблонів і додати моніторинг, що показує хвостову латентність та retransmits. Міграція стала менш магічною. Інциденти — значно рідшими.

Оптимізація, що повернулася бумерангом: «Давайте вимкнемо sync; швидше ж»

Інша команда мала ZFS на SSD-міррорах і кілька VM з транзакційним навантаженням. Вони бачили періодичні спайки write latency і хтось запропонував класичне рішення: встановити sync=disabled на датасеті. Продуктивність покращилась миттєво. Аплодисменти. Тікет закрито.

Через два місяці сталася невелика подія з електропостачанням. Не катастрофа — більше миготіння, яке нагадує, що будівля старіша за ваш CI. Хости перезавантажились. Більшість VM повернулися. Декілька — ні. Одна база даних повернулась, але шар застосунку почав виводити тонкі невідповідності даних.

Тепер «оптимізація продуктивності» стала проблемою інцидент-реакції з юридичним департаментом в кроці. Команда дізналася невтішну істину: коли ви вимикаєте sync, ви міняєте стійкість на швидкість. Іноді цей обмін прийнятний у лабораторії. У продакшені треба документувати це й отримати підпис людей, яких потім шукатимуть за відповідальність.

Кінцеве виправлення було не екзотичним. Вони повернули sync у безпечний режим і додали правильний SLOG з захистом від втрати живлення для навантажень, які потребують низької латентності sync-записів. Також покращили тестування UPS і припинили довіряти «є батареї» як архітектурній властивості.

Нудна, але правильна практика, що врятувала ситуацію: «Резерв і rehearsed failure»

Компанія з Proxmox + Ceph мала правило, яке всім не подобалося: тримати вільне місце вище порогу і ніколи не допускати, щоб кластер підходив близько до заповнення. Це було непопулярно, бо виглядало як витрачання бюджету. Фінанси люблять заповнені диски; інженери люблять тихі пейджери.

Вони також проводили квартальні репетиції відмов. Не театральний хаос — просто витягнути OSD, перезавантажити вузол і подивитися, що сталося. Вимірювали час відновлення і вплив на латентність VM. Це було не весело. Це було роботою.

Потім у понеділок помер хост. Справжня смерть: материнська плата, не перезавантаження. Ceph перебалансувався, клієнти продовжували працювати, кластер залишився придатним до роботи. Латентність підросла, але не стала нелінійною, бо був простір для backfill і мережа не була на межі.

Відновлення було антиклімактичним. Це найвища похвала для сховища.

Що їх врятувало — не якийсь секретний Ceph-флаг. Це був резерв ємності, моніторинг і вже відпрацьована поведінка системи під час контролюваних відмов.

Поширені питання

1) Чи використовувати ZFS або Ceph для двовузлового кластера Proxmox?

Використовуйте ZFS локально й реплікуйте або робіть бекапи. Двовузловий Ceph можливий дивними способами, але рідко вартий операційних ризиків і компромісів у продуктивності.

2) Чи поганий RAIDZ для Proxmox?

Не «поганий», але часто неправильний інструмент для латентності VM. Міррори зазвичай дають вищі IOPS і нижчу хвостову латентність для випадкових записів, типових для змішаних VM-навантажень.

3) ZFS на SSD: чи потрібен SLOG?

Лише якщо у вас значний обсяг sync-записів і вам важлива їхня латентність. Якщо додаєте SLOG — робіть це enterprise-рівня з захистом від втрати живлення, інакше це стане пасткою для надійності.

4) Для Ceph на Proxmox: використовувати RBD чи CephFS для дисків VM?

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

5) Чи можна запускати Ceph і VM на тих самих вузлах Proxmox?

Так, і багато хто так робить. Але розрахуйте CPU/RAM відповідно і пам’ятайте: коли навантаження VM піде вгору, демони Ceph конкуруватимуть за ресурси. Для передбачуваного сховища на великому масштабі варто розглянути виділені вузли сховища.

6) Чи прийнятний NFS для дисків VM?

Так, якщо NAS потужний, і навантаження не ультрачутливе до затримок. Це поширено для малих кластерів. Моніторьте латентність і retransmits, і не використовуйте «soft» монтування.

7) iSCSI проти NFS для Proxmox: що швидше?

Залежить більше від сервера/масиву і мережі, ніж від протоколу. iSCSI може дати передбачувану блочну поведінку; NFS може бути простішим в експлуатації. Обирайте за моделями відмов і керованістю, а не за скріншотом бенчмарку.

8) Диски VM мають бути qcow2 чи raw?

Raw зазвичай швидший і простіший. qcow2 дає можливості (наприклад, внутрішні знімки), але додає накладні витрати. У Proxmox віддавайте перевагу raw/ZVOL для «гарячих» дисків, якщо не потрібні функції qcow2.

9) Як швидко визначити, чи проблема в Ceph або в самій VM?

Перевірте ceph -s на slow ops і ceph osd perf на викидаки, потім корелюйте з iostat на хості і симптомами затримки диска у VM. Якщо Ceph показує slow ops — це не «просто VM».

10) Чи можна змішувати HDD і SSD у Ceph?

Можна, але робіть це свідомо (окремі класи пристроїв, окремі пули). Сліпе змішування зазвичай означає, що швидкі диски проведуть життя в очікуванні повільних.

Висновок: практичні наступні кроки

Обирайте бекенд сховища, виходячи з того, як ви хочете, щоб виглядали відмови, а не з того, як виглядають дашборди.

• Якщо ви малі (1–3 вузли), побудуйте локальні ZFS-міррори для дисків VM, тримайте NFS для бекапів і спільних артефактів, і реалізуйте реплікацію/бекапи з перевіреним відновленням.
• Якщо у вас «реальний» кластер (4+ вузлів) і ви можете профінансувати мережу та диски — використовуйте Ceph RBD і ставтеся до нього як до розподіленої системи: моніторьте, тримайте резерв, репетируйте відмови.
• Якщо у вас вже є нормальний масив — iSCSI — розумна корпоративна відповідь: просто налаштуйте multipath правильно і прийміть централізовану залежність.
• Якщо вам потрібне спільне сховище без розподіленої платформи — NFS залишається найпростішим рішенням, і простота — це функція продуктивності о 3 ранку.

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