SMB/CIFS у Proxmox повільний для дисків VM: чому це погано і що використовувати натомість

Як насправді виглядає «SMB повільний» у Proxmox

Коли люди кажуть «SMB повільний», зазвичай мають на увазі одне з трьох:
низька пропускна здатність, велика латентність або «стрибуча» продуктивність.
Диски VM найбільше страждають від останніх двох. VM може завантажитися при посередній пропускній здатності.
Але вона не витримає випадкових 500 ms записів із синхронними семантиками.

Реальність на чергуванні — це не «копіювання файлу повільне». Це:

• завантаження VM займає 4–10 хвилин, потім раптом повертається до нормального стану, коли кеші прогріваються;
• бази даних зависають. Журнали чекають. У логах з’являється «fsync() taking too long»;
• інтерактивна латентність: SSH-сесії завмирають на секунду, а потім наганяють;
• операції кластера виглядають моторошно: міграції зависають, резервні копії тайм-аутяться, процеси qemu переходять у D-state;
• найгірше: все нормально — поки не стане погано, і тоді це інцидент на рівні хоста.

Диски VM часто не проходять тест «передбачуваності». Сховище, яке дає 5 ms більшу частину дня, але 800 ms щоразу, коли антивірус сканує файловий сервер — це не «швидко», це «генератор сюрпризів».

Жарт №1: SMB для дисків VM — як використовувати вантажівку для гонок. Вона рухається, але ніхто не задоволений часом кола.

Чому SMB/CIFS — поганий вибір для дисків VM

1) I/O VM — дрібні, синхронні й чутливі до затримок

Багато VM I/O — це випадкові читання/записи 4K–64K плюс метадані.
Гостьові ОС та додатки часто використовують fsync(), бар’єри та коміти журналів.
Навіть коли додаток «асинхронний», файлові системи гостя зазвичай ні.

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

2) Додаткові шари додають очікування (і способи зависати)

Для SMB-дисків шлях I/O зазвичай такий:

• Гостьова файлова система → гостьовий блок-слой → virtio-scsi/virtio-blk
• QEMU на Proxmox → ядро хоста → CIFS-клієнт
• Мережевий стек → свіч → NIC → NIC файлового сервера
• Samba/SMB сервер → локальна ФС на сервері → сховище сервера

Будь-який із цих шарів може ввести head-of-line блокування. CIFS-монти можуть зависати при перепідключенні.
Файлова система сервера може призупинитися під час створення снапшотів. Антивірус може блокувати файли.
«Простий» запис перетворюється на збір комітету.

3) Блокування, lease/oplocks і кешування налаштовані під файли — диски VM поводяться як «гарячі блоки»

SMB добре координує доступ до спільних файлів. Диски VM не є «спільними файлами» у звичному сенсі.
Це великі образи з інтенсивним випадковим I/O, часто звертаються один процес гіпервізора, який очікує стабільні семантики і сталу латентність.

Механізми кешування і блокувань SMB (oplocks/leases) корисні для звичайних файлів.
Але коли всередині VM працює база даних, яка лежить у файлі, ви будуєте вежу кешів.
Тимчасова затримка блокування стає «MySQL завис», і ви починаєте дебаг не того шару.

4) Семантики відмово- та перепідключення не те, що потрібно вашим VM

SMB може перепідключатися. Це звучить добре, поки ви не уявите, як виглядає «reconnect» для диска VM:
довгі простої I/O. Потоки QEMU зависають. Зсуви часу у гостя. Іноді корупція файлової системи, якщо стек бреше про надійність.

Так, SMB3 має durable handles, witness, multichannel та інше.
Але на практиці ви все одно ставитеся до того, що файловий сервер і його SMB-стек мають поводитися ідеально під частковими відмовами.
Ця ставка програє частіше, ніж визнають у постмортемах.

5) Семантика синхронних записів може тихо підстрелити вас

Диски VM, особливо з дефолтними налаштуваннями QEMU та поведінкою гостя, генерують багато синхронних записів.
На сервері це може відповідати «write-through» поведінці, яка змушує підтвердження переходити до стабільного сховища.
Якщо підлегле сховище файлового сервера не має write-back кешу з захистом (BBU/flash-backed),
ваші IOPS тепер обмежені ротаційною латентністю або write amplification на недорогих SSD.

Навіть з хорошими дисками SMB додає кругові поїздки. Латентність домінує.
Можна мати 10GbE канал і при цьому отримувати жахливі IOPS, якщо кожний I/O вимагає кількох послідовних очікувань.

6) Перевага «легких прав доступу» не має значення для дисків VM

Людям подобається SMB через ACL, інтегровані з корпоративними IdP.
Це важливо для користувацьких шарів. Воно рідко важливе для образів VM.
Для зберігання VM ви хочете: передбачувану продуктивність, передбачувані відмови і передбачуване відновлення.
Еллегантність ACL не допоможе вам о 3:00 ранку, коли ERP VM директора зависла в D-state.

Перефразована ідея (John Allspaw, operations/reliability): «Складні системи ламаються складно; надійність приходить через навчання і стійкість, а не через бажану конфігурацію».

Цікавинки та історичний контекст (коротко і по суті)

1. SMB зародився в 1980-х як протокол мережевого шарингу файлів; його ДНК — «файли», а не «віртуальні блочні пристрої».
2. CIFS фактично був брендингом SMB1 і прославився надмірною балакучістю; SMB2/3 багато покращили, але репутація заслужена.
3. SMB2 зменшив кількість кругових поїздок і ввів кредитну систему управління потоком; це допомогло для WAN, але диски VM усе ще карають за латентність.
4. SMB3 додав шифрування і multichannel; добре для безпеки й пропускної здатності, але шифрування може з’їдати CPU і додавати джиттер при навантаженні.
5. Windows-файлові сервери популяризували «share як платформу зберігання»; віртуалізація повернула індустрію до блогових або розподілених сховищ для дисків.
6. NFS став стандартом для віртуалізації частково тому, що його семантики і реалізації краще підходили до шаблонів доступу образів VM (особливо на корпоративних масивах).
7. iSCSI пережив, бо він нудний: блочний пристрій, зрозуміла multipath-історія, передбачувані семантики для гіпервізорів.
8. Дизайн RADOS Block Device (RBD) у Ceph сформувався під потреби обслуговування випадкового I/O VM у масштабі з реплікацією та вбудованим відновленням.
9. Дебати «NAS vs SAN» циклиться десятиліттями; диски VM постійно повертають увагу до латентності та порядку записів.

Швидкий план діагностики: знайти вузьке місце за хвилини

Це порядок дій, який я використовую, коли Proxmox-хост працює з VM на SMB і надходять скарги «весь кластер повільний».
Мета — не ідеальний бенчмаркінг. Мета — швидко знайти домінантне обмеження, щоб вирішити: налаштувати, мігрувати чи замінити.

Перше: підтвердьте, що це латентність сховища, а не навантаження CPU чи пам’яті

• Перевірте завантаження хоста й I/O wait. Якщо iowait стрибає разом із зависаннями VM — ви в потрібній зоні.
• Підтвердьте процеси qemu в D-state (uninterruptible sleep). Це зазвичай очікування на сховище.

Друге: ізолюйте, де з’являється латентність

• Чи сам CIFS-монт зависає? Шукайте reconnects, timeouts або «server not responding».
• Чи мережа викидає пакети або домовляється про невірні налаштування (MTU mismatch, дивні flow control)?
• Чи підсистема дисків файлового сервера насичена або змушує синхронні записи на повільні носії?

Третє: перевірте семантики, які ви ненавмисно налаштували

• Опції монтування SMB: режим кешу, actimeo, vers, multichannel, signing, encryption.
• Samba/сервер: strict sync, sync always, oplocks/leases, aio налаштування.
• Proxmox/QEMU: режим кешу диска, IO thread, aio backend, discard налаштування.

Четверте: вирішіть, чи марні зусилля по налаштуванню

Якщо навантаження — це бази даних, CI-ранери, поштові сервери або щось із великою кількістю дрібних синхронних записів, припиніть тюнінг SMB і почніть план міграції.
Якщо це легкі десктопні VM і латентність «лише» помірна, ви можете тимчасово обійтися змінами.

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

Це реальні перевірки, які можна запустити на Proxmox-хості і, де потрібно, на SMB-сервері.
Кожне завдання містить: команду, що означає типовий вивід, і рішення, яке потрібно прийняти.

Завдання 1: Підтвердити iowait і чергу виконання під час «повільного» вікна

cr0x@pve1:~$ mpstat -P ALL 1 5
Linux 6.8.12-pve (pve1)  12/26/2025  _x86_64_ (32 CPU)

12:01:10 PM  CPU   %usr  %nice   %sys %iowait  %irq %soft  %steal  %idle
12:01:11 PM  all   12.3   0.0     4.1   38.7    0.0  0.6    0.0     44.3

Значення: 38.7% iowait — тривожний знак: CPU простівають, чекаючи завершення I/O.
Рішення: розглядайте це як латентність сховища, а не «потрібно більше CPU». Перейдіть до перевірки шляху I/O.

Завдання 2: Визначити, які пристрої дійсно повільні

cr0x@pve1:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.52    0.00    3.90   36.10    0.00   49.48

Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
sda              0.2     1.1     0.0     0.1   2.10    0.00   0.3
dm-5            55.0   420.0     4.2    31.8  180.4   22.10  99.2

Значення: dm-5 насичений із середнім очікуванням ~180 ms. Це «VM відчуватимуть себе підіймальними».
Рішення: зв’яжіть dm-5 з бекендом SMB-монту (часто loop, файл або FUSE-шар).
Якщо це CIFS-монт, переходьте до CIFS-специфічних перевірок.

Завдання 3: Перевірити, чи qemu-процеси блокуються на I/O

cr0x@pve1:~$ ps -eo pid,stat,comm,args | grep -E "qemu-system|D " | head
21133 D    qemu-system-x86_64 /usr/bin/kvm -id 101 -name vm101 ...

Значення: стан D означає uninterruptible sleep, зазвичай очікування на сховище.
Рішення: підтвердьте, які файлові системи/монти обслуговують ці I/O; шукайте CIFS-стали та затримки на сервері.

Завдання 4: Підтвердити, що диск VM на SMB у Proxmox

cr0x@pve1:~$ qm config 101 | sed -n '1,120p'
boot: order=scsi0;ide2;net0
memory: 8192
name: vm101
scsi0: smbstore:101/vm-101-disk-0.qcow2,size=80G
scsihw: virtio-scsi-single

Значення: диск — це qcow2-файл на сховищі з ім’ям smbstore.
Рішення: очікуйте подвійну індексацію (метадані qcow2 + семантики файлової системи SMB). Плануйте міграцію на raw-on-block або RBD.

Завдання 5: Переглянути опції CIFS-монту на хості Proxmox

cr0x@pve1:~$ mount | grep cifs
//filesrv01/vmstore on /mnt/pve/smbstore type cifs (rw,relatime,vers=3.1.1,cache=strict,username=svc_pve,uid=0,gid=0,soft,nounix,serverino,mapposix,nofail)

Значення: soft може викликати помилки I/O при тимчасових відмовах; cache=strict може збільшувати метадані кругових поїздок.
Рішення: прибирайте «прикольні» опції. Уникайте soft для дисків VM; краще — припинити використання SMB для дисків VM.

Завдання 6: Перевірити статистику CIFS-клієнта на предмет перепідключень і таймаутів

cr0x@pve1:~$ cat /proc/fs/cifs/Stats
Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 3 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects 17
Total vfs operations: 121044
Total timeouts: 9
Total retries: 203

Значення: перепідключення/таймаути в робочий час — ризик для продуктивності і цілісності даних.
Рішення: ставте стабільність мережі і сервера в якості вимоги. Якщо не вдається звести reconnects до нуля — мігруйте з SMB.

Завдання 7: Шукати помилки CIFS у kernel log

cr0x@pve1:~$ dmesg -T | grep -i cifs | tail -n 8
[Thu Dec 26 12:03:18 2025] CIFS: VFS: Server filesrv01 has not responded in 60 seconds. Reconnecting...
[Thu Dec 26 12:04:19 2025] CIFS: VFS: cifs_reconnect: server reconnect succeeded

Значення: 60 секунд — це вічність для дисків VM. Гості зависнуть; дехто може впасти.
Рішення: припиніть бути вірними ілюзії, що це прийнятно для продакшн-сховища VM. Виправте мережу/сервер або переносьте сховище.

Завдання 8: Підтвердити здоров’я мережевого шляху (дропи, помилки, MTU)

cr0x@pve1:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123349901  9812331  0       214      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8331990021  8441122  0       0        0       0

Значення: є RX drops. Вони можуть бути нешкідливими або корелювати зі стрибками.
Рішення: якщо дропи зростають під час зависань, перевіряйте буфери свічів, розміри кілець NIC, flow control і узгодженість MTU по всьому шляху.

Завдання 9: Виміряти латентність до файлового сервера під навантаженням (не тільки одноразовий ping)

cr0x@pve1:~$ ping -c 20 -i 0.2 filesrv01
PING filesrv01 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=63 time=0.380 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=63 time=0.412 ms
64 bytes from 10.20.0.10: icmp_seq=9 ttl=63 time=12.881 ms
64 bytes from 10.20.0.10: icmp_seq=10 ttl=63 time=0.401 ms

--- filesrv01 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3810ms
rtt min/avg/max/mdev = 0.362/1.104/12.881/2.776 ms

Значення: поодинокі сплески 10–15 ms вже погані для синхронного I/O. SMB підсилює ці сплески.
Рішення: якщо є джиттер латентності, не ставте диски VM на віддалену ФС, яка залежить від стабільних кругових поїздок.

Завдання 10: Швидкий тест I/O на SMB-монті (латентність покаже всю картину)

cr0x@pve1:~$ fio --name=randwrite --directory=/mnt/pve/smbstore --size=2G --bs=4k --rw=randwrite --iodepth=16 --numjobs=1 --runtime=30 --time_based --direct=1
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=psync, iodepth=16
...
  write: IOPS=420, BW=1680KiB/s (1720kB/s)(50.0MiB/30500msec)
    lat (usec): min=2100, max=980000, avg=38000.12, stdev=92000.55

Значення: середнє 38 ms з піковим майже 1 s. Це не «трохи повільно». Це «пауза VM».
Рішення: припиніть використовувати SMB для дисків VM під це навантаження. Можна тюнити, але не можна витягнути 980 ms хвостову латентність простими налаштуваннями.

Завдання 11: Перевірити конфігурацію сховища Proxmox (що воно думає про «smbstore»)

cr0x@pve1:~$ cat /etc/pve/storage.cfg | sed -n '1,200p'
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

cifs: smbstore
        path /mnt/pve/smbstore
        server filesrv01
        share vmstore
        content images,backup
        username svc_pve
        vers 3.1.1

Значення: Proxmox трактує це як файлове сховище, придатне для образів і бекапів.
Рішення: залишайте SMB для бекапів/ISO, якщо потрібно; видаліть images зі списку контентів, щоб зменшити кількість інцидентів.

Завдання 12: Перевірити режим кешу диска QEMU (він може зробити гірше або просто інше)

cr0x@pve1:~$ qm config 101 | grep -E '^scsi0:'
scsi0: smbstore:101/vm-101-disk-0.qcow2,cache=writeback,discard=on,size=80G

Значення: cache=writeback може підвищити відчуття швидкості, але збільшує blast radius при падінні хоста або зависаннях SMB.
Рішення: не використовуйте режим кешу як пластир для поганого бекенду. Якщо вам треба writeback, значить бекенд неправильний.

Завдання 13: Перевірити Samba-сервер на політики синхронних записів (на стороні сервера)

cr0x@filesrv01:~$ testparm -sv 2>/dev/null | grep -E 'strict sync|sync always|aio read size|aio write size'
        aio read size = 1
        aio write size = 1
        strict sync = Yes
        sync always = Yes

Значення: sync always = Yes — це обрив продуктивності для дисків VM: воно примушує стійкі запити на кожен запис.
Рішення: якщо це файловий сервер для документів — залишайте надійність. Якщо ви намагалися зробити з нього SAN — припиніть і переробіть дизайн.

Завдання 14: Перевірити, що файлова система і сховище сервера не є реальним лімітером

cr0x@filesrv01:~$ iostat -x 1 3
Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
nvme0n1         120.0   980.0    22.4   110.8   3.20    1.90  72.0
md0              10.0   320.0     1.1    38.0  45.00   18.50  99.0

Значення: Один пристрій нормальний (NVMe), RAID/md-пристрій завантажений під 99% і має 45 ms await.
Рішення: навіть якби SMB був ідеальним, бекенд не витримує. Диски VM покарають такий дизайн. Переносьте VM на швидше, орієнтоване на VM сховище.

Що використовувати замість: розумні варіанти зберігання для Proxmox

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

Опція A: Локальні NVMe/SSD з ZFS (швидко, передбачувано, досить керовано)

Для багатьох Proxmox-команд найкраща відповідь — найдослівніша:
розміщуйте диски VM на локальних NVMe/SSD і використовуйте ZFS для цілісності та снапшотів.
Ви втрачаєте «shared storage» для живих міграцій, якщо не реплікуєте або не використовуєте ZFS replication.
Зате отримуєте хвостову латентність, яка не нагадує кардіограму.

Коли локальний ZFS виграє:

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

Ключ: зберігайте диски VM як ZVOLи (блочні пристрої) або raw-файли на ZFS, а не qcow2 на SMB. Дайте ZFS достатньо RAM. Моніторьте write amplification.

Опція B: Ceph RBD (shared storage зроблений правильно, хоч і важко)

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

Коли Ceph виграє:

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

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

Опція C: iSCSI + LVM (нудне блочне сховище, працює добре, передбачувані семантики)

iSCSI — частий «дорослий у кімнаті»: масив експортує LUNи, хости бачать блок-пристрої, multipath керує відмовами шляхів.
На верху можна покласти LVM або LVM-thin у Proxmox.
Продуктивність зазвичай стабільна, а поведінка під навантаженням легше передбачувана, ніж у SMB.

Де iSCSI блискуче:

• У вас є реальний масив або добре побудований target з правильним кешуванням і надмірністю.
• Ви хочете централізоване сховище і стабільну продуктивність.
• Вам потрібна чітка multipath-історія.

Опція D: NFS (краще за SMB для образів VM, але не перший вибір для write-heavy)

NFS часто використовується для образів VM і може працювати добре, коли за ним стоїть корпоративний NAS, налаштований для віртуалізації.
Як правило, він має менше «Windows baggage» і більш прості UNIX-орієнтовані семантики в багатьох середовищах.
Але: це все ще мережева файлова система. Латентність і поведінка на стороні сервера мають значення.

Якщо використовуєте NFS — обирайте пристрій, який створено і підтримується для VM-стрима, і перевіряйте латентність під навантаженням синхронних записів.

Опція E: SMB підходить для бекапів, ISO, шаблонів і холодного зберігання

SMB — не зло. Його просто просять бути тим, чим він не є.
Використовуйте його для:

• ISO-репозиторіїв
• датасторів Proxmox Backup Server (зазвичай краще на локальних дисках, але SMB може підходити для вторинних копій)
• експорту бекапів на іншу систему
• шаблонів і артефактів, не чутливих до латентності

Утримуйте диски VM поза SMB, якщо лише навантаження не тривіальне і вплив відмов — тривіальний.
Якщо й те, й інше тривіальне, можливо вам взагалі не потрібен Proxmox — але ось ми й тут.

Жарт №2: Найшвидший спосіб пришвидшити SMB для VM — перестати використовувати SMB для VM.

Три корпоративні історії з краю «здавалося, що все нормально»

Міні-історія 1: Інцидент від хибного припущення («10GbE означає, що все швидко»)

Середня компанія мала Proxmox-кластер для внутрішніх сервісів: Git, CI, кілька Windows-серверів додатків і базу даних, яку всі вдавалися, ніби вона не критична.
Сховище було SMB на Windows-файловому сервері, бо там «вже було багато місця», а команда інфраструктури любила ACL.
Також у них були 10GbE uplinks, що всім додавало відчуття сучасності й безпеки.

Перший серйозний інцидент стався під час планового сканування безпеки. Сканер звернувся до шару датастору VM.
Антивірус файлового сервера помітив тисячі змін блоків всередині qcow2-файлів як «цікаві».
CPU сервера підскочив, черга диска зросла, і час відповіді SMB пішов від субмілісекунд до «нарешті».

На стороні Proxmox процеси qemu накопичилися в D-state. Гості не падали миттєво — вони просто перестали відповідати.
Моніторинг показував «здорові» VM, бо процеси існували і хости були в мережі. Користувачі писали «все зависло».
Команда перезавантажила Proxmox-нод, що погіршило проблему: кешовані записи, які не були безпечно закомічені, перетворилися на перевірки файлових систем у гостях і часткову корупцію.

Хибне припущення було простим: 10GbE пропускної здатності = продуктивність дисків VM.
Вони мали пропускну здатність. Вони не мали низької, стабільної латентності під синхронними випадковими записами.
Після постмортему вони перемістили диски VM на локальні дзеркала ZFS і використали реплікацію для кількох VM, які потребували швидшого відновлення.
Файловий сервер повернувся до того, у чому був сильний: файлів.

Міні-історія 2: Оптимізація, що відпрацювала проти

Інша організація мала невеликий Proxmox-фарм, де хтось помітив, що SMB-backed VM повільні під час ранкових логінів.
Доброзичливий інженер переключив режим кешу диска QEMU на writeback заради «швидкості».
Це спрацювало. Шторм логінів пройшов м’якше. Кількість тікетів знизилась. Усі заспокоїлись.

Через два місяці подія з електроживленням вдарила по стійці. UPS тримав, потім не витримав. Хости впали жорстко.
Після перезавантаження більшість VM повернулися. Деякі — ні. Одна база даних завантажилась, але додаток виводив помилки цілісності протягом дня.
Ніхто не міг точно сказати, скільки записів втрачено, бо шлях зберігання включав кілька кешів з різними семантиками надійності.

Повернення ударило не в те, що writeback завжди поганий. Погано те, що writeback використовували, щоб приховати бекенд, який не витримував синхронну латентність.
Вони оптимізували симптом і збільшили невизначеність при відмовах.
Наступним кроком було нудне, але вірне рішення: перейти на iSCSI з масивом, що має захищений кеш, і налаштувати multipath.
Продуктивність стала стабільною, а відмови — зрозумілими.

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день (вимірювати хвостову латентність)

Фінтех-подібна компанія планувала розширення Proxmox і хотіла спільне сховище для міграцій.
SMB пропонували, бо вже був високодоступний пар файлових серверів, і команда зберігання обіцяла «це enterprise».
SRE команда не сперечалася за смаком. Вони попросили тестове вікно.

Вони запустили fio з Proxmox-нод до пропонованого SMB-монту з навантаженням, сформованим під диски VM: випадкові 4K-записи, синхронний рушій, iodepth, що імітує конкуренцію.
Середня латентність була не жахливою. Але 99.9-й персентиль — жахливий, з періодичними стрибками сотні мілісекунд.
Потім повторили тест, провокуючи фонову активність на файловому сервері: снапшоти, обертання логів та бекап-джоби.
Хвіст став ще гіршим.

Результат був політично незручний, але операційно ідеальний: SMB схвалили тільки для бекапів і ISO.
Диски VM перейшли на Ceph RBD, бо організація була готова експлуатувати розподілену систему і хотіла відмовостійкість на рівні вузла.
Коли згодом верхньошарове обладнання локально почало втрачати пакети, Ceph деградував, але залишався придатним; SMB, ймовірно, перетворив би це на зависання VM.

Практика, що їх врятувала — не магія. Це було вимірювання правильного показника (хвостової латентності) і тестування під реальним фоновим шумом.
Нудно, правильно і уникнуло інциденту, що могли б списати на «випадкову нестабільність Proxmox».

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

1) Симптом: VM «замерзають», але CPU хоста в основному простий

Корінна причина: висока латентність сховища і блокований I/O (qemu в D-state), часто під час перепідключень SMB або призупинень на сервері.

Виправлення: підтвердьте за допомогою mpstat, iostat, dmesg і CIFS-статистики; потім мігруйте диски VM з SMB (Ceph RBD, iSCSI або локальний ZFS).

2) Симптом: Резервні копії проходять добре, а інтерактивні навантаження жахливі

Корінна причина: пропускна здатність ок, але хвостова латентність — ні. Потоки бекапу послідовні; диски VM — випадкові і синхронно-важкі.

Виправлення: тестуйте дрібно-блочний випадковий I/O і дивіться на max/percentiles. Не вважайте швидкість копіювання файлу еквівалентом.

3) Симптом: Продуктивність хороша після перезавантаження, потім деградує

Корінна причина: теплий кеш приховує бекенд-латентність, поки робочий набір не виросте; кеші метаданих SMB і writeback маскують реальність.

Виправлення: тестуйте холодний і теплий стани. Слідкуйте за викидом кешу на сервері, поведінкою writeback і чергами диска. Віддавайте перевагу сховищу з консистентною латентністю.

4) Симптом: Випадкові «Input/output error» всередині гостей

Корінна причина: CIFS змонтований з soft або агресивними таймаутами/повторами при тимчасових відмовах.

Виправлення: уникайте soft для сховища VM; виправте стабільність мережі; краще — припиніть використовувати SMB для дисків VM.

5) Симптом: Міграція зависає або триває вічно

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

Виправлення: використовуйте Ceph/блокове сховище для живих міграцій або локальне сховище з реплікацією і приймайте плановані прострої.

6) Симптом: Усе погано, коли «хтось запускає скан» або «починається бекап»

Корінна причина: фонові задачі на файловому сервері (AV, снапшоти, бекапи) конкурують з I/O VM і викликають стрибки латентності.

Виправлення: розділяйте обов’язки. Сховище для дисків VM не повинно ділитися політиками і завданнями з користувацькими шарами.

7) Симптом: Добрий ping, поганий латентність диска

Корінна причина: SMB-операції — це не ICMP; вони включають CPU сервера, файлові блокування, журналювання і підтвердження на диску.

Виправлення: вимірюйте те, що важливо: латентність I/O і хвостову поведінку за допомогою fio і реальних слідів навантаження VM.

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

Контрольний список A: Якщо ви вже на SMB і страждаєте

1. Підтвердьте симптом — це латентність I/O: запустіть mpstat і iostat -x під час інциденту.
2. Перевірте здоров’я CIFS-клієнта: шукайте reconnects/таймаути у /proc/fs/cifs/Stats і в логах ядра.
3. Перевірте базові мережеві речі: дропи/помилки, узгодженість MTU і джиттер латентності до сервера.
4. Перевірте обмеження на стороні сервера: черги диска, політики sync, jobs снапшотів, AV-сканування.
5. Зупиніть кровотечу: перемістіть найголосніші VM (бази даних, CI, пошта) спочатку на локальні SSD або блочне сховище.
6. Змініть використання Proxmox storage: видаліть images з SMB-сховища і залиште його для бекапів/шаблонів.
7. Побудуйте заміну: оберіть Ceph/iSCSI/локальний ZFS відповідно до операційної реальності, а не до бажань.
8. Міграція з планом: заплануйте вікна техпідтримки, протестуйте відновлення з бекапів і перевірте цілісність файлових систем гостя після переміщення.

Контрольний список B: Вибір правильної альтернативи

• Потрібні живі міграції і спільні диски? Віддавайте перевагу Ceph RBD або справжньому iSCSI/FC SAN.
• Потрібна найпростіша надійна продуктивність? Локальні NVMe дзеркала з ZFS і реплікація для критичних VM.
• Вже є корпоративний NAS для VM? NFS може бути прийнятним; доведіть хвостову латентність.
• Використовуєте Windows-файловий сервер, бо він є? Використовуйте його для файлів і експорту бекапів, а не як основне сховище VM.

Контрольний список C: Рухи для безпечної міграції (бо зміни зберігання — місце, де кар’єри гинуть)

1. Зробіть свіжий бекап і протестуйте відновлення як мінімум однієї VM на цільове сховище.
2. Перемістіть одну некритичну VM і перевіряйте продуктивність та логи протягом повного робочого дня.
3. Відстежуйте хвостову латентність (99th/99.9th), а не лише середні значення, до і після.
4. Документуйте rollback: де старий образ, як його повторно приєднати і які залежності DNS/додатків існують.
5. Тільки потім мігруйте найшумніші навантаження.

FAQ

1) SMB завжди повільний, чи лише для дисків VM?

Переважно повільний (або нестабільний) для дисків VM. SMB може бути цілком придатним для користувацьких файлів, медіа, бекапів і артефактів.
Диски VM перетворюють латентність і джиттер на відмови.

2) А що, якщо я використовую SMB3.1.1 з multichannel і швидкий Windows-сервер?

Можна покращити пропускну здатність і стійкість, але ви все одно використовуєте мережеву файлову систему для чутливого до латентності блочно-подібного I/O.
Якщо навантаження легке — це може бути прийнятно. Для баз даних і зайнятих серверів — це все ще неправильний інструмент.

3) Чи можу я зробити SMB прийнятним опціями монтування?

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

4) Чи qcow2 на SMB гірше за raw на SMB?

Зазвичай так. qcow2 додає операції метаданих і поведінку фрагментації, які підсилюють латентність на віддалених файлових системах.
raw зменшує накладні витрати, але не виправляє фундаментальні семантики латентності і відмов SMB.

5) NFS справді краще за SMB для дисків Proxmox?

Часто так, особливо на сховищі, спроектованому для віртуалізації. Але NFS — все ще мережева файлова система.
Воно може бути відмінним, посереднім або жахливим залежно від сервера і мережі. Вимірюйте хвостову латентність під реальним навантаженням.

6) Чи варто запускати Ceph для малого 3-нодовго кластера?

Можливо. Proxmox робить Ceph доступнішим, але це все ще розподілена система.
Якщо ви можете дотримуватися моніторингу, дисципліни ємності і стабільної мережі — воно може працювати добре.
Якщо команда проблемно справляється з базовою гігієною сховища, локальний ZFS з реплікацією зазвичай безпечніший вибір.

7) Яка найпростіша «достатньо добра» архітектура для надійного зберігання VM?

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

8) Чому зависання VM корелюють з «роботами обслуговування файлового сервера»?

Бо ці задачі викликають стрибки латентності: снапшоти, антивірус, дедуплікація, tiering, синхронізація з хмарою та агенти бекапу конкурують за I/O і блокування.
Диски VM сприймають ці стрибки як затримки записів і блокування потоків I/O.

9) Якщо SMB поганий для дисків VM, навіщо Proxmox підтримує CIFS взагалі?

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

10) Який єдиний метрик, на який варто ставити алерт для цієї проблеми?

Латентність диска на хості (await) і, якщо можна збирати, видима гостем латентність fsync.
Також ставте алерти на CIFS reconnects/таймаути — це ранній димовий сигнал до того, як користувачі почнуть кричати.

Наступні кроки, які можна зробити цього тижня

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

1. Запустіть швидкий план діагностики під наступний період повільності і збережіть iowait, iostat, CIFS-статистику та уривки dmesg.
2. Класифікуйте навантаження: визначте топ-5 VM за write IOPS і чутливістю до fsync (бази даних, CI, пошта, служби каталогів).
3. Оберіть ціль:
   • локальний ZFS, якщо хочете швидку передбачуваність;
   • Ceph RBD, якщо потрібне спільне сховище і ви готові його обслуговувати;
   • iSCSI, якщо у вас є масив і потрібні блочні семантики.
4. Перемістіть одну VM, перевірте хвостову латентність і стабільність протягом доби, потім переносіть інші партіями.
5. Знизьте роль SMB до бекапів/шаблонів/ISO. Нехай він робить те, в чому сильний.

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