Proxmox NFS таймаути: опції монтування, що покращують стабільність

Як виглядають «таймаути NFS» у Proxmox (і чому це страшно)

«Таймаут NFS» зазвичай евфемізм. Система не ввічливо завершує операцію; вона блокує її.
На Linux жорстко змонтована NFS‑файлова система буде повторювати операції, доки сервер не відповість.
Це правильна поведінка для цілісності даних, але особливий вид муки, коли під цим монтом лежать
диски віртуальних машин або цілі резервні цілі.

У Proxmox зони впливу залежать від того, що знаходиться на NFS:

• ISO/шаблони: дратує, але пережити можна. Запити не вдаються, операції повторюються.
• Місце для резервних копій (vzdump): завдання зависають, файли блокувань залишаються, моніторинг кричить.
• Диски VM на NFS: хост може зависнути на I/O. І/O гостя фризить, іноді QEMU ставить паузу, іноді виникає відчуття split‑brain без справжнього split‑brain.
• Спільне сховище для міграції: міграції зависають посередині. Тепер дві машини сперечаються, хто відповідає за проблему.

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

Дві короткі істини перед налаштуванням

• Опції монтування не виправлять зламану мережу. Вони можуть зробити поведінку при відмові розумнішою й зменшити зависання, але не переможуть фізику.
• Стабільність важливіша за швидкість для збереження Proxmox. Швидке сховище, яке іноді фризить, повільніше за помірне, яке ніколи не бреше.

Цікаві факти та історичний контекст (бо минуле все ще виставляє рахунки)

1. NFS зʼявився в середині 1980‑х у Sun Microsystems, щоб ділити файли між робочими станціями без спільної шини диска.
2. NFSv3 за дизайном безстанний (сервер мало відстежує стан клієнта), що спрощує відновлення після перезавантаження сервера, але переносить складність в інші місця.
3. NFSv4 додав стан (блокування, сесії, делегації). Краще семантично, але більше рухомих частин.
4. NFS поверх UDP колись був поширений для продуктивності; TCP здобув перемогу, бо працює краще на мережах з втратою пакетів і з сучасними NIC‑оптимізаціями.
5. «Hard mount» — типовий вибір у багатьох середовищах, бо безшумна втрата даних гірша за зависання. Так, це похмурий компроміс.
6. Клієнт NFS у Linux використовує RPC‑таймаути та експоненціальне збільшення інтервалів; «server not responding» не обовʼязково означає, що сервер впав — іноді він просто перевантажений.
7. Патерни I/O VM ворожі до балакучих протоколів: дрібні випадкові читання/записи, операції з метаданими, fsync. NFS проходить стрес‑тест, хочете того чи ні.
8. pNFS існує для масштабування NFS, але більшість налаштувань Proxmox його не використовують; вони на одному хеді й дивуються, чому він поводиться як одноголовий.

Цитата, яку варто приклеїти над кожним дашбордом сховища:
«Сподівання — не стратегія.» — генерал Гордон Р. Салліван

Жарт №1: NFS як офісний Wi‑Fi — коли він хороший, ніхто не помічає; коли поганий, усі стають мережевими інженерами.

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

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

Перше: підтвердьте режим відмови (блокований I/O vs повільний I/O vs проблема прав/блокувань)

• Шукайте «server not responding» у логах ядра на вузлі Proxmox. Якщо воно є, ви у сфері транспортного/RPC.
• Перевірте, чи процеси застрягли в стані D. Якщо бачите QEMU, vzdump або потоки ядра в D, у вас блокований I/O.
• Підтвердіть, чи це один вузол або всі вузли. Один вузол вказує на шлях NIC/комутатор; всі вузли — на проблему зі сторони сервера або на загальний сегмент мережі.

Друге: доведіть, чи сервер NFS зараз здоровий

• Завантаження сервера і затримка диска: якщо сервер насичений або його бекенд диска фризить, клієнти відчуватимуть таймаути.
• Відповідальність RPC‑сервісу: якщо rpcbind/nfsd‑потоки застрягли, навіть «пінгуємий» сервер не відповідатиме на NFS‑виклики.
• Коректність експорту: неправильний експорт може поводитися як переривчаста відмова, коли різні клієнти домовляються про різні шляхи/версії.

Третє: перевіряйте мережевий шлях, ніби ви йому не довіряєте (бо не повинні)

• Втрата пакетів і перемішування важать більше за сиру пропускну здатність. NFS чутливий до латентності і ненавидить мікросплески.
• Несумісність MTU створює «майже працює» поведінку, що псує день.
• Неправильне налаштування LACP та асиметрична маршрутизація спричиняють періодичні зависання, що виглядають як проблеми сервера NFS.

Точка рішення

Якщо у вас задачі в D‑стані + повідомлення ядра «server not responding» + зростання retrans, віддавайте пріоритет опціям
стабільності, які запобігають загрозам на рівні кластера (а потім виправляйте основну проблему). Якщо ж у вас нема retrans, але
повільні операції, дивіться на затримку диска сервера та насичення потоків NFS.

Опції монтування, що реально покращують стабільність

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

Базова рекомендація (стабільні значення за замовчуванням для NFS у Proxmox)

Для більшості середовищ Proxmox, які використовують NFS як ціль резервних копій або сховище ISO, почніть тут:

cr0x@server:~$ cat /etc/pve/storage.cfg
nfs: nas-backup
        export /export/proxmox-backup
        path /mnt/pve/nas-backup
        server 10.10.20.10
        content backup,iso,vztmpl
        options vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime,rsize=1048576,wsize=1048576
...output...

Розберемо важливі моменти:

• vers=4.1: v4.1 додає сесії і кращу семантику відновлення, ніж v4.0, і уникає деяких дивних речей ери v3. Це добрий «сучасний» вибір, якщо сервер його підтримує.
• proto=tcp: TCP краще справляється з втратою й перевантаженням, ніж UDP. Якщо ви досі на UDP — захоплююся вашою сміливістю й боюся вікна змін.
• hard: тримайте hard для дисків VM і для бекапів, якщо важлива коректність. Soft‑монти можуть повертати помилки I/O під час запису. Це не «обробка таймаутів», це «гра в корупцію».
• timeo=600,retrans=2: збільшує RPC‑таймаут (в десятих секунди, тож 600 = 60 с для багатьох операцій), зменшує кількість повторів до реєстрації повідомлення. Ця комбінація зменшує спам у логах і хаос під час відмов. Ви все ще блокуєтеся на hard‑монтах, але робите це ввічливіше.
• noatime,nodiratime: зменшують записи метаданих. Це не вирішення таймаутів, але усуває зайвий шум.
• rsize/wsize: використання 1M може зменшити накладні витрати RPC на сучасних мережах. Якщо бачите фрагментацію або дивні проблеми NIC, зменшіть значення.

Hard vs soft: оберіть відмову, з якою зможете жити

Це рішення, якого люди намагаються уникнути. Ви не зможете.

• hard означає: операції NFS повторюються вічно. Ваші процеси можуть зависнути. Ваші дані безпечніші.
• soft означає: після певної кількості повторів NFS повертає помилку. Процеси можуть швидко завершитися з помилкою. Дані можуть стати неконсистентними, якщо застосунок не очікував відмови під час запису.

Для дисків VM на NFS я наполегливо віддаю перевагу hard. Soft‑монтування може спричинити пошкодження файлової системи гостьової ОС, якщо записи не проходять.
Для цілей резервного копіювання hard зазвичай теж правильне рішення — якщо тільки ваша операційна модель не вимагає швидкого провалу завдань з повторною спробою пізніше
і ви свідомо приймаєте часткові невдачі бекапів. Багато організацій цього відкрито не визнають, але деякі так працюють.

intr і «чи можна перервати завислий монтувач?»

Історично intr дозволяв сигналам переривати операції NFS. У сучасних ядрах Linux його поведінка різниться або ігнорується залежно від версії та протоколу NFS.
Не ставте план реагування на інциденти на це. Плануйте безпечні шляхи перезавантаження/евакуації замість цього.

timeo і retrans: що вони справді роблять (і чого не роблять)

timeo — базовий RPC‑таймаут; retrans — скільки разів клієнт повторно відправляє RPC‑запит перед тим, як повідомити про таймаут у лог ядра.
При hard навіть після повідомлення про таймаут клієнт продовжує повторювати запити. Тож навіщо їх налаштовувати?

• Зменшити «штормову» поведінку: агресивні retrans можуть створювати RPC‑шторм під час глюків сервера, що сповільнює відновлення.
• Покращити спостережуваність: більший timeo зменшує хибні «server not responding» під час коротких мікросплесків.
• Зробити перемикання менш драматичним: якщо у вас HA NFS (або рух VIP), ви хочете, щоб клієнти витримали перехід без розплавлення.

actimeo / кешування атрибутів: ручка продуктивності, що може стати історією коректності

Кешування атрибутів зменшує круги з метаданими. Це може допомогти продуктивності, особливо при операціях із великою кількістю директорій.
Але для спільних директорій, де кілька клієнтів модифікують одні й ті ж шляхи (уявіть кеші шаблонів, деякі схеми ротації бекапів),
надто агресивне кешування може створити моменти «куди подівся мій файл?».

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

lookupcache=positive і чому це може зменшити біль

На NFSv3/v4 lookupcache=positive може зменшити негативні ефекти кешування відсутності файлів (коли клієнт надто агресивно памʼятає «файл не знайдено»).
Це допомагає, коли додатки створюють файли й одразу шукають їх з інших вузлів.
Це не магія, але один із небагатьох регуляторів, який може виправити проблему «застаріле уявлення» без змін на сервері.

nconnect: більше з’єднань, менше голів‑в‑черзі блокувань (іноді)

Linux підтримує nconnect для NFSv4.x у новіших ядрах, відкриваючи кілька TCP‑зʼєднань на монтування.
Це може покращити пропускну здатність і зменшити блокування, коли одне зʼєднання зазнає втрати.
Але це також може посилити навантаження на слабкий сервер і заставити ваші буфери комутаторів плакати.

Використовуйте його тільки після перевірки, що сервер має запас по CPU, NIC і сховищу. Почніть з nconnect=4, а не з 16.

Опції, яких варто уникати (якщо вам не подобається писати постмортеми)

• soft для дисків VM: це швидка доріжка до прихованого пошкодження за сприятливих умов відмови.
• proto=udp у сучасних мережах: це не 1999 рік, і ваші комутатори не в захваті.
• noac як «фікс» для застарілих уявлень: це може знищити продуктивність і підвищити навантаження на сервер; ставтеся до цього як до хіміотерапії.
• надто низький timeo: перетворює транзитну затримку на самостворені RPC‑шторми.

Жарт №2: Якщо ви ставите soft,timeo=1,retrans=1, щоб «уникнути зависань», вітаю — ваше сховище тепер швидко падає, як перше on‑call у стартапі.

Вибір правильної версії NFS (v3 vs v4.1) — серйозно

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

Коли NFSv4.1 — правильний дефолт

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

Коли NFSv3 все ще прийнятний

• Легіси NAS‑пристрої з кволими реалізаціями v4.
• Особливі вимоги сумісності (деякі корпоративні масиви мають «особливі» ідеї щодо функцій v4).
• Переваги відладки: v3 іноді простіший для аналізу в трасах пакетів через меншу складність.

Питання блокувань

Якщо ви зберігаєте образи VM на NFS, блокування мають значення. Для qcow2 особливо, одночасний доступ — катастрофа.
Переконайтесь, що ваша конфігурація забезпечує виключність: Proxmox робить свою частину, але семантика блокувань NFS все одно може впливати,
особливо під час відмов і відновлення.

Практичне правило

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

Реалії мережі: втрата пакетів, MTU, pause frame і чому «пінгується» — це нічого не значить

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

Що зазвичай спричиняє «server not responding» у стабільних датацентрах

• Втрата пакетів під навантаженням (проблемний кабель, оптика, перевантажений ToR, завантажений аплінк).
• Несумісність MTU (джамбо‑фрейми на одній стороні, а на іншій — ні). Працює, поки не перестає — тоді все ламається як фокус.
• Дивні прояви flow control / pause frame, що приводять до коротких затримок, які запускають каскади RPC‑таймаутів.
• Проблеми з хешуванням LACP, коли один лінк отримує все навантаження, а інші простоюють.
• Баги в NIC‑оптимізаціях (рідше зараз, але все ще реальні). Проблеми з TSO/GRO можуть виражатися як дивні латентні сплески.

Операційна позиція

Ставтеся до NFS як до трафіку збереження, а не як до «просто мережі». Розміщуйте його на передбачуваному шляху:
виділений VLAN, узгоджений MTU, узгоджена конфігурація бондингу, узгоджений QoS, якщо ви його використовуєте.
Якщо ви не можете ізолювати, принаймні вимірюйте.

Специфічні для Proxmox режими відмов: бекапи, міграція та проблеми кластера

Відносно vzdump бекапів на NFS: чому вони зависають інакше, ніж ви очікуєте

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

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

Диски VM на NFS: сплески латентності стають інцидентами для гостя

Навіть невеликі паузи NFS проявляються як затримки у гості. Бази даних помічають. Файлові системи помічають. Люди помічають.
Якщо ви розміщуєте диски VM на NFS, ви погоджуєтесь на:

• суворий контроль над поведінкою мережі,
• передбачувану продуктивність сервера,
• і опції монтування, обрані за коректність, а не за «щоб не зависало».

Ефекти в кластері: один поганий вузол може зіпсувати збори

У кластері Proxmox проблеми зі спільним NFS‑сховищем можуть проявлятися як:

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

Ваша ціль — зробити режим відмови передбачуваним. Передбачуване — відлагоджуване. Відлагоджуване — виправне.

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

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

Завдання 1: Підтвердіть, що Proxmox думає про NFS‑сховище

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196540280        90581232       96023420   46.07%
nas-backup        nfs     active       7812500000      2123456789     5600000000   27.18%
...output...

Що це означає: З точки зору Proxmox сховище «active». Це не гарантує, що воно відповідає; просто значить, що монтування існує і виглядає придатним.

Рішення: Якщо статус під час інциденту змінюється між active/inactive, підозрюйте флап монтування або проблеми доступності на сервері.

Завдання 2: Перевірте фактичні опції монтування

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/pve/nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21,local_lock=none
...output...

Що це означає: Підтверджує ефективні опції. «relatime» зʼявляється, бо ядро нормалізує поведінку atime.

Рішення: Якщо не бачите hard/timeo/vers як очікувалося, виправте storage.cfg або fstab і перемонтуйте навмисно.

Завдання 3: Дивіться, як ядро скаржиться в реальному часі

cr0x@server:~$ journalctl -kf | grep -i nfs
Dec 26 10:14:21 pve1 kernel: nfs: server 10.10.20.10 not responding, still trying
Dec 26 10:14:52 pve1 kernel: nfs: server 10.10.20.10 OK
...output...

Що це означає: Класичне поведінка retrans/таймаут з відновленням.

Рішення: Якщо «still trying» повторюється хвилинами без «OK», вважайте це реальним простоєм. Починайте ізоляцію: здоровʼя сервера vs мережа.

Завдання 4: Знайдіть заблоковані процеси (стан D) і визначте, хто застряг

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2=="D"{print}' | head
23145 D qemu-system-x86  nfs_wait_bit_killable       /usr/bin/kvm -id 102 -name vm102 ...
30411 D vzdump           rpc_wait_bit_killable       vzdump 102 --compress zstd --storage nas-backup
...output...

Що це означає: Процеси в стані D чекають на незупинюваний I/O. Вбити їх зазвичай не вдасться; вони застрягли в ядрі.

Рішення: Якщо QEMU заблоковано, очікуйте впливу на гостей. Розгляньте переміщення навантажень з цього вузла після відновлення NFS; не варто просто робити «kill -9» і сподіватися.

Завдання 5: Перевірте RPC‑статистику клієнта для retrans і таймаутів

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

Client nfs v4:
null         read         write        commit       open         open_conf    ...
0            48212        27111        135          324          0            ...
...output...

Що це означає: Пересилки — сильна підказка про втрату пакетів або проблеми з відповіддю сервера.

Рішення: Якщо retrans швидко зростає під нормальним навантаженням, віддавайте пріоритет мережевому розслідуванню. Якщо retrans низький, а продуктивність погана — дивіться на диск/CPU сервера.

Завдання 6: Перевірте стан і «вік» по монтуванню (корисно для «stale handle» історій)

cr0x@server:~$ cat /proc/mounts | grep nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21 0 0
...output...

Що це означає: Підтверджує, що це NFSv4 і показує основні опції. Швидка перевірка «що ми взагалі запускаємо?».

Рішення: Якщо ви очікували v4.1, а бачите v3 (або навпаки), ви знайшли дрейф конфігурації або проблему переговорів.

Завдання 7: Перевірте експорти NFS з перспективи клієнта

cr0x@server:~$ showmount -e 10.10.20.10
Export list for 10.10.20.10:
/export/proxmox-backup 10.10.20.0/24
/export/iso            10.10.20.0/24
...output...

Що це означає: Підтверджує видимість експорту. Це не повністю валідує поведінку простору імен NFSv4, але ловить явні зміни експорту.

Рішення: Якщо експорт не в списку або доступ раптово звузився, припиняйте налаштовувати монти й виправляйте експорти/ACL.

Завдання 8: Тест поведінки I/O безпосередньо на монтуванні (простий тест латентності)

cr0x@server:~$ time sh -c 'dd if=/dev/zero of=/mnt/pve/nas-backup/.iotest bs=1M count=256 conv=fdatasync status=none'
real    0m5.842s
user    0m0.012s
sys     0m0.221s
...output...

Що це означає: Це включає sync, щоб змусити сервер підтвердити запис. Якщо це зростає з секунд до хвилин — ви бачите проблему, а не марите.

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

Завдання 9: Перевірте лічильники помилок мережі на вузлі Proxmox

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210 12345678  0       124      0       112233
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109 11223344  0       0        0       0
...output...

Що це означає: RX‑dropи на трафіку збереження — погана новина. Втрачені пакети можуть породжувати retrans/таймаути.

Рішення: Якщо дропи зростають під час вікон бекапу, у вас проблема з перевантаженням або буфером NIC/комутатора. Розгляньте QoS, виділений VLAN або збільшення пропускної здатності.

Завдання 10: Перевірте MTU енд‑ту‑енд (пастка джамбо‑фреймів)

cr0x@server:~$ ping -c 3 -M do -s 8972 10.10.20.10
PING 10.10.20.10 (10.10.20.10) 8972(9000) bytes of data.
8972 bytes from 10.10.20.10: icmp_seq=1 ttl=64 time=0.431 ms
8972 bytes from 10.10.20.10: icmp_seq=2 ttl=64 time=0.438 ms
8972 bytes from 10.10.20.10: icmp_seq=3 ttl=64 time=0.422 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
...output...

Що це означає: Підтверджує, що джамбо‑фрейми працюють між клієнтом і сервером. Якщо воно падає з «Frag needed», у вас несумісний MTU.

Рішення: Якщо джамбо не працює, або виправте MTU скрізь, або опустіться до 1500 скрізь. Змішане MTU — податок на надійність.

Завдання 11: Підтвердіть, що NFS‑сервер відповідає на RPC/NFS‑запити

cr0x@server:~$ rpcinfo -t 10.10.20.10 nfs 4
program 100003 version 4 ready and waiting
...output...

Що це означає: NFS‑сервіс досяжний по TCP. Якщо це блокується або падає під час інциденту, то це або мережа, або тривога в RPC‑стеку сервера.

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

Завдання 12: Прослідкуйте один завислий процес, щоб підтвердити, що він застряг у NFS I/O

cr0x@server:~$ cat /proc/30411/stack
[<0>] rpc_wait_bit_killable+0x1d/0x60
[<0>] __rpc_execute+0x3a/0x90
[<0>] rpc_execute+0x44/0x50
[<0>] nfs4_call_sync+0x6a/0xa0
[<0>] nfs4_proc_write+0xa1/0x140
[<0>] nfs_file_write+0x10a/0x2a0
[<0>] vfs_write+0x1b4/0x2a0
[<0>] ksys_write+0x67/0xe0
[<0>] do_syscall_64+0x5b/0x110
...output...

Що це означає: Стек показує процес, який чекає в RPC/NFS‑шляху запису. Це не «повільність додатка». Це непрацюючий шлях сховища.

Рішення: Припиніть дискусії про налаштування додатка. Стабілізуйте шлях NFS і розгляньте паузу нових бекап‑завдань, поки не відновите службу.

Завдання 13: Перемонтуйте з безпечнішими опціями (контрольована зміна)

cr0x@server:~$ umount /mnt/pve/nas-backup
umount: /mnt/pve/nas-backup: target is busy.
...output...

cr0x@server:~$ fuser -vm /mnt/pve/nas-backup | head
                     USER        PID ACCESS COMMAND
/mnt/pve/nas-backup: root      30411 f.... vzdump
/mnt/pve/nas-backup: root      23145 f.... qemu-system-x86
...output...

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

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

Завдання 14: Перевірте логи завдань Proxmox на затримки, пов’язані зі сховищем

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/active
UPID:pve1:000076CB:0012ABCD:676D0B31:vzdump:102:root@pam:
status: running
starttime: 1766743800
...output...

Що це означає: Завдання «running», але без прогресу. Поєднайте це з перевірками D‑стану, щоб підтвердити блокування на збереженні.

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

Завдання 15: Перевірка на стороні сервера (на NFS‑сервері): насичення потоків nfsd

cr0x@server:~$ ps -eLo pid,cls,pri,rtprio,stat,comm | grep -E 'nfsd|rpc'
  8123 TS  19      - S    nfsd
  8124 TS  19      - R    nfsd
  8125 TS  19      - D    nfsd
...output...

Що це означає: Якщо потоки nfsd у стані D, вони, ймовірно, блокуються на серверному сховищі (локальний диск, ZFS, RAID‑контролер тощо).

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

Три міні‑історії з корпоративного життя (усі анонімізовані, але правдоподібні)

1) Інцидент через неправильне припущення: «NAS має резервні лінки, тож мережа не може бути причиною»

Компанія середнього розміру експлуатувала кластер Proxmox з бекапами на NFS. NAS мав подвійні NIC, обʼєднані через LACP.
Команда вважала, що резервність = стійкість. Бекапи виконувалися вночі і «переважно працювали», поки наприкінці кварталу пікове навантаження
не збільшилося й раптом бекапи почали зависати на двох з пʼяти вузлів.

Перше припущення: якщо NAS доступний, то він в порядку. Пінг працював. GUI завантажувався. Дашборд NAS показував «healthy».
Але на вузлах Proxmox в логах ядра повторювалися NFS «not responding». Деякі процеси vzdump застрягли в D‑стані.

Вони годинами налаштовували опції монтування — зменшували таймаути, підвищували їх, додавали soft на одному вузлі «просто щоб спробувати».
Той вузол перестав зависати… і почав виробляти часткові бекапи з помилками I/O. Вони ледь не просунули пошкоджену копію як «успішну», бо задача завершилася.
На щастя, система бекапів не мовчки корумпувала дані; вона падала гучно. Це було єдиною хорошою частиною.

Справжня причина — невідповідність хешування LACP: комутатор хешував по L3/L4, NAS по‑іншому, і більшість NFS‑трафіка потрапляла на один фізичний лінк.
Під піковим навантаженням той лінк втратив пакети у хвилях. TCP відновлювався, але латентність RPC підскакувала й запускала retrans та «not responding».

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

2) Оптимізація, що повернулась бумерангом: джамбо‑фрейми + «nconnect всюди»

Інша компанія хотіла швидших міграцій VM і чуйніших бекапів. Вони увімкнули джамбо‑фрейми (MTU 9000) на вузлах Proxmox і NAS,
і включили nconnect=8, бо хтось побачив графік бенчмарку. Перший день був чудовим.
Потім зʼявилися періодичні таймаути NFS під час важких вікон бекапу.

Складність була в тому, що це не була чиста відмова. Більшість часу все летіло. Іноді воно зупинялося.
Retrans зростали, але тільки під піком. Команда звинувачувала NAS.
NAS звинувачував Proxmox. Мережа — «невідомий трафік». Всі були частково праві, що найгірший вид правоти.

Прихована проблема — несумісність MTU: ToR‑комутатори підтримували джамбо, але один міжкомутаторний лінк у шляху лишився на 1500.
Більшість трафіка обходила його. Деякі потоки не обходили. Ці потоки страждали від фрагментації/чорної діри залежно від обробки ICMP.
З nconnect зʼявилось більше потоків, що підвищило імовірність попадання на поганий шлях. Оптимізація полегшила відтворення відмови.

Вони виправили MTU енд‑ту‑енд, потім знизили nconnect до 4 після спостереження підвищеного CPU на сервері.
Продуктивність залишилася гарною. Таймаути зникли. Ніхто не зміг залишити наратив «нам треба більше тюнінгу».

3) Нудна, але правильна практика, що врятувала день: консервативні монти та обмеження конкурентності

Компанія запускала нічні бекапи багатьох VM на NFS‑ціль. Спочатку вони помітили, що NAS іноді призупиняє відповіді на технічні роботи
і відгукується повільно хвилину чи дві. Вони прийняли це як реальність і спроектували систему під це.

Вони зробили три непоказні речі, що не потрапили б на конференцію:
стабільний NFSv4.1 через TCP з hard,timeo=600,retrans=2, виділене вікно резервних копій і суворе обмеження конкурентності, щоб лише кілька VM бекапились одночасно.
Також у них був дашборд, що відстежував retrans клієнта і затримку диска сервера поруч.

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

Післяінцидентний огляд був приємно нудним: підтвердити дропи, замінити підозрілу оптику, перевірити MTU і LACP — і все.
Система бекапів ніколи не стала заголовком новин. Оце й була ціль.

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

1) Симптом: «server not responding, still trying» під час бекапів; завдання висить годинами

Корінь проблеми: hard‑монтування + простій сервера або втрата пакетів. Клієнт робить правильну річ (повторює вічно).

Виправлення: тримайте hard, підніміть timeo (наприклад, 600), тримайте retrans низьким (2–3), виправте мережеві втрати і/або затримку серверного сховища. Зменшіть конкурентність бекапів.

2) Симптом: бекапи «завершуються», але відновлення не працює або файли відсутні

Корінь проблеми: soft‑монти повертають помилки I/O під час запису; інструменти бекапу не завжди трактують часткові записи так, як ви сподіваєтесь.

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

3) Симптом: проблеми з NFS є тільки на одному вузлі Proxmox

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

Виправлення: порівняйте лічильники ip -s link між вузлами; поміняйте кабелі/порти; перевірте режим бондингу і хешування; перевірте MTU.

4) Симптом: проблеми зʼявляються тільки в пікові часи

Корінь проблеми: перевантаження, мікросплески, чергові дропи, насичення CPU сервера або стрибки затримки диска.

Виправлення: вимірюйте retrans і RX‑дропи; обмежуйте конкурентність бекапів; розгляньте виділений VLAN/QoS; виправте вузькі місця сервера (диски, CPU, NIC).

5) Симптом: «stale file handle» після технічних робіт на сервері

Корінь проблеми: переміщення експорту, відтворення файлової системи, rollback знімка або зміни inode під шляхом експорту.

Виправлення: уникайте руйнівних операцій під експортами; використовуйте стабільні датасети/шляхи; перемонтуйте клієнти після критичних змін на сервері; для v4 забезпечте консистентні pseudo‑root експорти.

6) Симптом: міграція зависає, хоча сховище «спільне»

Корінь проблеми: спільне сховище присутнє, але має стрибки затримки або переривчасті RPC‑завмирання; міграція стикається із синхронним I/O.

Виправлення: стабілізуйте NFS (мережа, сервер), використовуйте NFSv4.1/TCP і уникайте героїчного тюнінгу. Якщо потрібно мігрувати під час нестабільності, зупиніться і виправте сховище спочатку.

7) Симптом: операції в GUI повільні, перевірки статусу сховища затримуються

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

Виправлення: тримайте проблемні NFS‑монти поза критичними шляхами; монтуйте лише там, де потрібно; забезпечте правильні опції монтування і стабільність сервера; не кладіть «усе» на один ненадійний NFS.

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

Покроково: стабілізувати існуюче NFS‑сховище бекапів у Proxmox

1. Визначте масштаб: один вузол чи багато? Використовуйте логи ядра і nfsstat -c.
2. Підтвердіть фактичні опції монтування: findmnt. Перестаньте довіряти лише конфігураційним файлам.
3. Забезпечте коректний протокол: віддавайте перевагу vers=4.1,proto=tcp, якщо немає вагомої причини інакше.
4. Встановіть консервативну поведінку таймаутів: hard,timeo=600,retrans=2 як базову для стабільності.
5. Зменшіть метадані‑шум: noatime,nodiratime.
6. Перевірте MTU енд‑ту‑енд: джамбо або працює скрізь, або не належить нікому.
7. Перевірте дропи: ip -s link на клієнтах; лічильники інтерфейсів на комутаторах (так, дивіться на них справді).
8. Обмежте конкурентність бекапів: менше паралельних vzdump‑завдань, особливо у відомі пікові вікна NAS.
9. Вимірюйте тренди retrans: якщо retrans зростає з навантаженням — припиніть звинувачувати опції монтування і виправляйте транспорт/сервер.
10. Тестуйте примусові sync‑записи: dd ... conv=fdatasync, щоб виявити затримки підтвердження запису.
11. Плануйте руйнівні серверні задачі: scrubs, snapshots, реплікація, дедуплікація — не накладайте їх на піки бекапу, якщо не любите ризику.
12. Документуйте обрану семантику: «hard‑монтування; таймаути означають фриз; план реакції — відновити сервіс, не вбивати процеси». Зробіть це явним.

Контрольний список: якщо ви зберігаєте диски VM на NFS (будьте чесні з собою)

• Виділений шлях збереження (VLAN або фізичний), узгоджений MTU.
• NFSv4.1 через TCP; розгляньте nconnect лише після базової стабільності.
• Hard‑монтування. Завжди. Якщо ви хочете soft — вам потрібна інша архітектура збереження.
• Сервер повинен мати передбачувану затримку під навантаженням синхронних записів.
• Моніторинг включає retrans, затримку диска сервера і дропи на комутаторі.
• Планована реакція на відмову NFS: що відбувається з гостями, що робити спочатку, чого ніколи не робити.

Контрольний список: мінімальний моніторинг, що ловить реальну проблему

• Швидкість зміни retrans на клієнті (з nfsstat -c або еквівалентами node exporter).
• RX/TX дропи і помилки на клієнті (з ip -s link).
• Затримка диска сервера і глибина черги (інструменти залежать від стеку сервера).
• Здоровʼя потоків NFS‑сервера (nfsd‑потоки не блоковані).
• Тривалість і конкурентність завдань бекапу.

FAQ

1) Чи варто використовувати soft, щоб уникнути зависань Proxmox?

Не для дисків VM. Для бекапів — тільки, якщо ви свідомо приймаєте часткові помилки і верифікуєте бекапи наскрізь.
Інакше тримайте hard і виправляйте основну нестабільність.

2) Які sane значення timeo і retrans для Proxmox?

Прагматична база — timeo=600,retrans=2 для монтувань, орієнтованих на стабільність. А потім вимірюйте.
Якщо у вас швидке перемикання і потрібне швидше виявлення, обережно зменшуйте timeo, але не створюйте штормів повторів.

3) Чи завжди NFSv4 кращий за NFSv3?

Ні. NFSv4.1 часто кращий при коректній реалізації, особливо щодо відновлення сесій і спрощеного фаєрволінгу.
Але стабільний NFSv3 обійде нестабільний NFSv4 у будь‑який день тижня.

4) Чи rsize/wsize виправляють таймаути?

Прямо — ні. Вони можуть зменшити накладні витрати RPC і підвищити пропускну здатність, що може зменшити повʼязані з перевантаженням паузи.
Але якщо у вас втрата пакетів або простій сервера, більші розміри можуть загострити симптоми.

5) Мій NFS‑монт «active» у Proxmox, але операції зависають. Чому?

«Active» означає, що змонтовано і базово доступно. NFS може бути змонтований і одночасно не відповідати на певні операції.
Використовуйте логи ядра, перевірки D‑стану і nfsstat -c, щоб підтвердити фриз.

6) Чи можна безпечно відмонтувати і перемонтувати NFS під час інциденту?

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

7) Що спричиняє «stale file handle» і як це запобігти?

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

8) Чи варто вмикати nconnect?

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

9) Чи потрібна виділена мережа збереження для NFS?

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

10) Яка найкраща перша дія, коли таймаути починаються посеред бекапу?

Перестаньте запускати нові бекапи. Зменшіть навантаження під час діагностики. Потім підтвердіть, чи проблема — retrans/drops (мережа) або затримка диска/перевантаження CPU (сервер).

Висновок: наступні кроки, що виживуть у продакшні

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

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

1. Закріпіть стабільне базове монтування: vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime, плюс розумні rsize/wsize.
2. Запустіть швидкий план діагностики під час наступного інциденту: підтвердіть D‑стан, підтвердіть retrans, перевірте дропи/MTU, потім перевірте затримку сервера.
3. Обмежте конкурентність бекапів і уникайте накладення важких серверних технічних завдань на вікна бекапу.
4. Інструментуйте retrans і дропи інтерфейсів як метрики першого класу. Якщо ви не бачите зростання retrans, ви дебагуєте в сліпу.
5. Коли потрібна більша продуктивність — додайте ємності або виправте топологію, перш ніж додавати хитрощі типу агресивного кешування або великого nconnect.

NFS може бути стабільним у Proxmox. Потрібні просто дорослі у кімнаті: консервативна семантика, виважений тюнінг і мережа, що не імпровізує.