Помилка Proxmox «не доступно на вузлі»: чому сховище існує, але ви не можете ним користуватися

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

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

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

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

Що насправді означає «не доступно на вузлі»

У Proxmox VE визначення сховищ — це об’єкти конфігурації в межах кластера, що зберігаються у /etc/pve/storage.cfg (файл, який обслуговується через кластерну файлову систему Proxmox). Коли ви визначаєте сховище з ім’ям fast-nfs, Proxmox пам’ятає його всюди. Це не означає, що кожен вузол справді може ним користуватися. Proxmox розрізняє:

Опис сховища існує: ID присутній у конфігурації і відображається в інтерфейсі.
Сховище активне на вузлі: вузол може дістатися до бекенду (монтування існує, пул імпортовано, Ceph здоровий, автентифікація працює, шлях існує, права доступа коректні).
Сховище підтримує потрібний вміст: ви пробуєте розмістити диски VM на сховищі, яке приймає лише ISO/шаблони, або навпаки.
Сховище дозволене на вузлі: сховище обмежене через параметр nodes, або ім’я вузла не відповідає тому, що очікує конфігурація.

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

Типові кореневі категорії

Більшість випадків потрапляє в один із цих кошиків:

Проблеми з обсягом / таргетингом: сховище налаштоване лише для підмножини вузлів або невідповідність імені вузла після перевстановлення/перейменування.
Проблеми з монтуванням/шляхом: NFS/CIFS не змонтовано, точка монтування відсутня, неправильний шлях, fstab не зберігає монтування, проблеми з порядком systemd.
Автентифікація/права: ключі Ceph, облікові дані SMB, права експорту NFS, Unix-володіння/режими.
Бекенд не в робочому стані: Ceph деградований/вимкнений, пул ZFS не імпортовано, LVM VG відсутній, iSCSI сесія померла, multipath зламаний.
Несумісність вмісту та формату: спроба зберегти images на dir, що не підтримує потрібний формат, або використання локального сховища для припущень HA.

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

Жарт #1: Сховище як кавоварка: всі помічають, коли вона не працює, а ніхто не пам’ятає, хто її встановлював.

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

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

Перше: підтвердити, чи навмисно виключено

Чи обмежене сховище певними вузлами в /etc/pve/storage.cfg?
Чи ім’я вузла співпадає з конфігурацією (особливо після перевстановлення)?
Чи немає роздвоєння мозку / проблем зв’язку кластера, коли /etc/pve відрізняється?

Якщо виключено — виправлення у конфігурації, а не інфраструктурі.

Друге: підтвердити, що ОС бачить/може змонтувати/імпортувати бекенд

NFS/CIFS: змонтовано? DNS резолюється? Чи ядро може досягти сервера?
ZFS: пул імпортовано? Є I/O помилки?
LVM: чи існує VG? Чи присутні PV?
Ceph: чи ceph -s показує здоров’я? Чи є монітори/кворум?
iSCSI: чи сесії залогінені? Multipath здоровий?

Якщо ОС не може його використати — Proxmox теж не зможе. Не налагоджуйте Proxmox, поки Linux не працює.

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

Чи дозволяє сховище images, rootdir, backup тощо?
Для dir-сховища: чи існує директорія і чи записувальна вона для root?
Для файлового сховища: чи є місце? Чи не вичерпані іноді?

Тут буває таке: «воно нормально змонтовано», але Proxmox відмовляється розміщувати диски VM на ISO-only сховищі або шлях змонтовано в режимі read-only.

Типи сховищ і їхні специфічні режими відмов

Dir-сховище (локальна директорія, NFS, змонтований у директорію тощо)

Чому це відмовляє: відсутня точка монтування, неправильні опції монтування, монтування лише для читання, проблеми з правами, невідповідний шлях, застарілі NFS дескриптори, або директорія існує, але на неправильному файловому розділі (ви думали, що це NFS; насправді — локальний root).

Що перевіряє Proxmox: що шлях існує, доступний і вузол дозволений. Він не буде перевіряти, що ви змонтували «правильну» річ — це на вашому боці.

NFS-сховище

Чому це відмовляє: права експорту, фаєрвол, DNS, сервер вниз, клієнт «залипає» через soft-mount, або systemd монтування не готове під час завантаження. Помилки NFS часто «працюють» до першого збою, бо кешована метадані маскує проблему.

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

CIFS/SMB-сховище

Чому це відмовляє: облікові дані закінчилися/змінені, невідповідність SMB-діалекту, проблеми з AD, або відсутній хелпер монтування. Також: файлові сервери Windows люблять «допоміжні» зміни.

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

ZFS (локальний)

Чому це відмовляє: пул не імпортований після перезавантаження, перейменування пристроїв, відсутні шляхи by-id, деградований пул з I/O помилками, або ви створили пул на одному вузлі й очікуєте, що він з’явиться на іншому (це не спільне сховище; це оптимізм).

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

LVM / LVM-thin (локальний блок)

Чому це відмовляє: відсутній VG через відсутній диск, зміна UUID PV, правила фільтрації в lvm.conf, або проблеми з активацією. Thin-пули також чудово ламаються, якщо метадані заповнюються.

Ceph (RBD/CephFS)

Чому це відмовляє: монітори без кворуму, OSD вимкнені, мережеві проблеми, невідповідні keyring, неправильний шлях до ceph.conf, або ви вказали вузлу неправильний cluster name/fSID. Ceph також відмовляє, коли «переважно здоровий», але повільний: ви бачите доступність, але не юзабельність.

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

iSCSI (часто з LVM зверху)

Чому це відмовляє: сесії падають, CHAP не співпадає, multipath неправильно налаштовано, змінюються LUN ID, або забувають про персистентність після перезавантаження. iSCSI любить ламатися о 02:00 — бо, звісно, так і буде.

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

Це перевірки рівня продакшену, які я виконую, коли з’являється «storage not available on node». Кожне завдання містить (a) команду, (b) що означає типовий вивід, та (c) рішення, яке слід ухвалити. Запускайте їх спочатку на ураженому вузлі.

Завдання 1: Запитайте Proxmox, що він вважає активним

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active        102334976       22110208        75053056    21.61%
fast-nfs         nfs      inactive               0              0               0     0.00%
ceph-rbd         rbd      active                0              0               0     0.00%

Значення: Менеджер сховищ Proxmox (pvesm) оголошує fast-nfs неактивним на цьому вузлі. Це канонічний сигнал: Proxmox не може його активувати.

Рішення: переходьте до перевірок монтування/бекенду. Якщо статус active, але GUI каже unavailable, підозрюйте обмеження вузла або невідповідність конфігурації кластера.

Завдання 2: Підтвердити визначення сховища і обмеження вузлів

cr0x@server:~$ grep -A5 -n "nfs: fast-nfs" /etc/pve/storage.cfg
27:nfs: fast-nfs
28:        export /exports/proxmox
29:        path /mnt/pve/fast-nfs
30:        server 10.20.30.40
31:        content images,backup,iso
32:        nodes pve01,pve02

Значення: Це сховище явно обмежене до pve01,pve02. Якщо ви на pve03, воно «не доступне» за задумом.

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

Завдання 3: Перевірити ім’я вузла, яке використовує Proxmox

cr0x@server:~$ hostname
pve03

Значення: Ім’я вузла — pve03. Якщо в storage.cfg вказано pve3 або старе ім’я, обмеження не співпадуть.

Рішення: виправте список вузлів для сховища або виправте ім’я хоста послідовно (перейменування вузла в Proxmox нетривіальне; краще правити конфігурацію).

Завдання 4: Перевірити, чи існує точка монтування і яка це файлова система

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

Значення: Воно змонтоване і це фактично NFS4 з очікуваного сервера/експорту. Гарний знак.

Рішення: якщо findmnt нічого не показує — монтування відсутнє; якщо показує ext4 або zfs, ви змонтували не те або не змонтували взагалі.

Завдання 5: Якщо його немає — перевірити systemd mount і порядок у fstab

cr0x@server:~$ systemctl status mnt-pve-fast\\x2dnfs.mount
● mnt-pve-fast\x2dnfs.mount - /mnt/pve/fast-nfs
     Loaded: loaded (/etc/fstab; generated)
     Active: failed (Result: exit-code) since Fri 2025-12-26 07:12:20 UTC; 3min ago
      Where: /mnt/pve/fast-nfs
      What:  10.20.30.40:/exports/proxmox
      Docs:  man:fstab(5)
             man:systemd-fstab-generator(8)
    Process: 1442 ExecMount=/usr/bin/mount 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs (code=exited, status=32)

Значення: Unit монтування завершився з помилкою; статус 32 зазвичай означає збій монтування (мережа, права, сервер).

Рішення: перевірте мережеву доступність і права експорту NFS наступними кроками.

Завдання 6: Перевірити мережеву доступність і розв’язування імен

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.462 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.417 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1012ms
rtt min/avg/max/mdev = 0.417/0.439/0.462/0.022 ms

Значення: Базова зв’язність в порядку. Це не доводить, що NFS працює, але швидко виключає «сервер зник».

Рішення: перевірте TCP/UDP порти і доступ до експорту.

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

cr0x@server:~$ showmount -e 10.20.30.40
Export list for 10.20.30.40:
/exports/proxmox 10.20.30.0/24

Значення: Експорт існує і надається вашій підмережі. Якщо вузол у іншій підмережі/VLAN — ви саме знайшли проблему.

Рішення: якщо список експорту пустий або доступ заборонено — виправте конфігурацію експорту NFS/фаєрвол на сервері.

Завдання 8: Спробувати ручне монтування з детальними помилками

cr0x@server:~$ mount -v -t nfs4 -o vers=4.2 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs
mount.nfs4: timeout set for Fri Dec 26 07:17:40 2025
mount.nfs4: trying text-based options 'vers=4.2,addr=10.20.30.40,clientaddr=10.20.30.53'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting 10.20.30.40:/exports/proxmox

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

Рішення: налаштуйте експорти на NFS-сервері; зміни в конфігурації Proxmox тут не допоможуть.

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

cr0x@server:~$ touch /mnt/pve/fast-nfs/.pve-write-test && echo "ok" || echo "fail"
ok

Значення: Монтування записувальне для root (або принаймні цей запис пройшов). Якщо помилка «Read-only file system» або «Permission denied» — Proxmox матиме проблеми.

Рішення: виправте опції монтування, права експорту на сервері або стан файлової системи.

Завдання 10: Перевірити права/володіння для шляхів dir-сховища

cr0x@server:~$ ls -ld /mnt/pve/fast-nfs
drwxr-xr-x 9 root root 4096 Dec 26 07:11 /mnt/pve/fast-nfs

Значення: Root має доступ. Це зазвичай достатньо, бо операції сховища Proxmox виконуються від root. Якщо ви бачите дивне володіння через squash або ACL — очікуйте помилок при створенні піддиректорій, таких як dump або template.

Рішення: забезпечте, щоб експорту NFS та права файлової системи дозволяли записи від root (або узгодьте UID/GID згідно з очікуваннями Proxmox).

Завдання 11: Підтвердити типи вмісту відповідають тим, що ви робите

cr0x@server:~$ pvesm config fast-nfs
content images,backup,iso
export /exports/proxmox
path /mnt/pve/fast-nfs
server 10.20.30.40
type nfs

Значення: Це сховище дозволяє VM-диски, бекапи і ISO. Якщо ваша помилка була «невдача створити CT volume», можливо відсутній rootdir.

Рішення: налаштуйте content належним чином. Не надавайте зайвих типів вмісту без потреби (це зменшує запобіжні заходи).

Завдання 12: Шукати логи Proxmox, які пояснюють помилки активації

cr0x@server:~$ journalctl -u pvedaemon -u pve-storage -n 80 --no-pager
Dec 26 07:12:21 pve03 pvedaemon[1321]: storage 'fast-nfs' is not online
Dec 26 07:12:21 pve03 pvedaemon[1321]: mount error: permission denied for 10.20.30.40:/exports/proxmox
Dec 26 07:12:22 pve03 pvedaemon[1321]: TASK ERROR: storage 'fast-nfs' is not available on node 'pve03'

Значення: Ви бачите реальну причину: помилка монтування — permission denied. GUI рідко показує це так чисто.

Рішення: виправляйте бекенд. Перестаньте тикати по UI.

Завдання 13: Якщо це ZFS — підтвердити імпорт пулу і його стан

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

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          nvme0n1p3 ONLINE       0     0     0

errors: No known data errors

Значення: Пул здоровий. Якщо ваше сховище — пул ZFS з іменем tank, і він не відображається — він не імпортований.

Рішення: якщо відсутній — спробуйте zpool import і дослідіть шляхи пристроїв і стабільність by-id.

Завдання 14: Якщо ZFS відсутній — перелічити імпортовані пули

cr0x@server:~$ zpool import
  pool: tank
    id: 1234567890123456789
 state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          sdb       ONLINE

Значення: Пул існує, але не імпортований. Після перезавантаження це зазвичай означає, що автo-імпорт не відбувся або пристрої з’явилися пізніше.

Рішення: імпортуйте його (zpool import tank) і потім виправте порядок завантаження або іменування пристроїв, щоб уникнути повторення.

Завдання 15: Якщо LVM-thin — підтвердити наявність VG і thinpool

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve          1   2   0 wz--n-  930.00g  10.00g

Значення: VG існує. Якщо Proxmox каже, що LVM-сховище недоступне і vgs нічого не показує — диск/VG відсутній або відфільтрований.

Рішення: перевірте pvs, видимість дисків і фільтри в /etc/lvm/lvm.conf.

Завдання 16: Якщо Ceph — швидко перевірити здоров’я кластера

cr0x@server:~$ ceph -s
  cluster:
    id:     2f1d3b0a-6f6d-4a7b-a6b3-9a7b4a0d1c2e
    health: HEALTH_WARN
            1 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Значення: Ceph здебільшого в порядку; один мон упав, але кворум є і PGs чисті. Proxmox загалом має продовжувати використовувати RBD.

Рішення: якщо health — HEALTH_ERR, або ви бачите багато PGs не active+clean — розглядайте це як інцидент бекенду, а не проблему UI Proxmox.

Завдання 17: Підтвердити, що Proxmox може перелічити томи на сховищі

cr0x@server:~$ pvesm list fast-nfs | head
Volid                             Format  Type              Size VMID
fast-nfs:iso/debian-12.iso        iso     iso           657457152    0
fast-nfs:backup/vzdump-qemu-100.vma.zst vma.zst backup  1812034560  100

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

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

Завдання 18: Перевірити місце на диску та іноді inodes

cr0x@server:~$ df -h /mnt/pve/fast-nfs && df -i /mnt/pve/fast-nfs
Filesystem                         Size  Used Avail Use% Mounted on
10.20.30.40:/exports/proxmox       20T   19T  800G  96% /mnt/pve/fast-nfs
Filesystem                         Inodes  IUsed   IFree IUse% Mounted on
10.20.30.40:/exports/proxmox       120M    119M    1M   99% /mnt/pve/fast-nfs

Значення: Місця мало, але inodes практично закінчилися. Це може ламати бекапи, завантаження ISO та зберігання контейнерів так, ніби це помилки прав доступу.

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

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

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

1) Сховище відображається в UI, але на одному вузлі воно «не доступне»

Симптом: Сховище видно по кластеру; лише один вузол не може ним користуватися.

Корінна причина: обмеження вузла у storage.cfg або невідповідність імені вузла (вузол перевстановлено з іншим ім’ям).

Виправлення: оновіть nodes для цього сховища або виправте ідентичність вузла послідовно. Перевірте з pvesm status на кожному вузлі.

2) NFS-сховище «працює», доки не перезавантажити, потім стає недоступним

Симптом: Після перезавантаження Proxmox каже, що сховище недоступне; ручне монтування виправляє.

Корінна причина: монтування не персистентне або стартує раніше за мережу; відсутній параметр _netdev або проблеми з порядком systemd; іноді DNS не готовий.

Виправлення: переконайтесь, що fstab має _netdev, розгляньте systemd unit для монтування, і перевіряйте через systemctl status mnt-pve-*.mount. Зробіть монтування детерміністичним.

3) «Permission denied» при монтуванні, хоча експорт є

Симптом: showmount -e показує експорт, але монтування припиняється з access denied.

Корінна причина: правила експорту не включають IP вузла, або очікування idmapping NFSv4 різняться, або фаєрвол блокує порти NFS.

Виправлення: виправте allowlist на сервері експорту, підтвердьте версію NFS і валідність з клієнта за допомогою verbose mount.

4) Сховище змонтовано, але Proxmox все ще каже недоступне

Симптом: findmnt показує монтування, але pvesm status показує inactive.

Корінна причина: Proxmox очікує сховище у /mnt/pve/<storageid>, а ви змонтували його в іншому місці, або шлях у storage.cfg неправильний, або монтування зависло/застаріло.

Виправлення: узгодьте path з реальним шляхом монтування; перевірте наявність застарілих NFS дескрипторів командою ls, що зависає; перемонтуйте за потреби.

5) Диски VM не створюються на сховищі, але ISO завантажуються

Симптом: ISO контент працює, але створення диска не вдається.

Корінна причина: відсутній images в content, або тип сховища не підтримує потрібний формат.

Виправлення: додайте потрібні типи вмісту, або перемістіть диски на блочне сховище (LVM/RBD), якщо потрібна інша семантика.

6) Ceph-сховище «не доступне» лише на одному вузлі

Симптом: Два вузли можуть використовувати RBD; один — ні.

Корінна причина: відсутні пакунки Ceph, відсутній keyring, неправильний ceph.conf, або мережа до моніторів заблокована на цьому вузлі.

Виправлення: перевірте ceph -s на тому вузлі; порівняйте /etc/ceph і keyrings; підтвердьте фаєрвол і доступ до моніторів.

7) LVM-thin сховище зникає після «чистки»

Симптом: LVM-сховище неактивне; vgs порожній.

Корінна причина: хтось видалив/змінив диск, змінено фільтри LVM, або переключили іменування пристроїв без стабільних ID.

Виправлення: відновіть видимість дисків, використовуйте стабільні шляхи by-id, і тримайте фільтри LVM консервативними та явними.

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

Чекліст A: Тріаж «сховище недоступне» на одному вузлі (10 хвилин)

Запустіть pvesm status. Визначте, які ID сховища неактивні на цьому вузлі.
Перевірте /etc/pve/storage.cfg на предмет обмежень nodes і налаштувань шляхів.
Порівняйте ім’я вузла з результатом hostname.
Якщо файлове сховище: перевірте монтування через findmnt.
Спробуйте базовий I/O: ls і touch у шляху сховища (стежте за зависаннями).
Перевірте логи: journalctl -u pvedaemon -u pve-storage на предмет явних помилок.
Якщо NFS/CIFS: спробуйте ручне монтування з детальним виводом.
Якщо Ceph: ceph -s на тому вузлі і перевірка наявності keyring.
Якщо ZFS/LVM: перевірте видимість пулу/VG і їхній стан.
Тільки після перевірок на рівні ОС: повторно перевірте GUI Proxmox і спробуйте операцію знову.

Чекліст B: Перевірка цілого кластера (30–60 хвилин, щоб уникнути повторів)

На кожному вузлі: запустіть pvesm status і порівняйте результати.
Переконайтесь, що кожне спільне сховище має однакові семантики монтування скрізь (той самий шлях, ті самі опції).
Уніфікуйте мережеві припущення вузлів: VLAN, правила фаєрволу, DNS, MTU, маршрутизація.
Для NFS: переконайтесь, що експорти явно включають усі Proxmox-вузли; уникайте «працює з однієї підмережі» сюрпризів.
Для Ceph: переконайтесь, що кожен вузол має правильні конфіги і keyrings у /etc/ceph; перевірте доступ до моніторів.
Перегляньте типи контенту для кожного сховища: тримайте їх суворими. «Усе всюди» швидко стає «все зламано всюди».
Додайте крок валідації після перезавантаження у ваш процес змін: монтування імпортовано, VGs активні, Ceph OK.

Чекліст C: Перед увімкненням HA або плануванням міграцій

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

Три міні-історії з корпоративного світу

Міні-історія 1: Інцидент через невірне припущення

У них був акуратний тривузловий кластер Proxmox і один NFS-сервер. Сховище було визначене один раз, видно всюди, і команда вирішила, що це означає «спільне». Воно в основному працювало — поки не настав перший форс-мажор.

Один хост почав кидати ECC помилки. On-call правильно зробив — евакуювати VM на інші вузли. Але кілька VM відмовились мігрувати. UI люб’язно повідомив, що вузол-приймач не може використовувати сховище. Це було заплутано, бо сховище «було там».

Корінь проблеми не в Proxmox. NFS-сервер експортував шар лише в конкретну підмережу, а один із Proxmox-вузлів жив у іншому VLAN через минуле «тимчасове» мережеве рішення. Опис сховища існував, але вузол ніколи фактично не був авторизований.

Виправлення було нудним: оновили allowlist експорту NFS, вирівняли мережеве розміщення і додали просту перевірку «тест монтування + touch file» до процесу комісії вузла. Після цього міграції запрацювали — і команда перестала сприймати GUI як доказ реальності.

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

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

Інша компанія хотіла швидших I/O для дисків VM, тож «оптимізувала» опції монтування NFS. Вони перейшли на агресивні таймаути і додали опції, що мали зменшити зависання при втраті пакетів. На папері виглядало відповідально: уникати завислих процесів, зберегти відповідність вузла.

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

Причина була в поведінці монтування під час транзитної помилки. Опції монтування перетворювали тимчасовий збій на помітні для додатків помилки. Для дисків VM це не «дрібна незручність». Це подія цілісності даних із супровідною паперовою роботою.

Вони відкотилися до більш безпечних параметрів монтування для дисків і розділили використання: один NFS-шлях для бекапів (де допустимі повторні спроби) і інший бекенд для VM-дисків. Оптимізація була розумною ідеєю, застосованою до неправильної задачі.

Жарт #2: Нічого так не говорить «висока доступність», як налаштування таймаутів до того моменту, поки ваше сховище не стане котом Шредінгера.

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

Ще одна команда використовувала RBD на Ceph для дисків VM і окремий NFS-шар для бекапів. Вони також мали нудну звичку: після кожного оновлення Proxmox або перезавантаження вузла робили короткий скрипт валідації — pvesm status, невеликий тест створення/видалення RBD і тест запису бекапу на NFS.

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

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

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

Цікаві факти та трохи історії (що справді допомагає)

Факт 1: Proxmox зберігає конфігурацію кластера у спеціальній файловій системі під /etc/pve, яка реплікується подібно до бази даних. Ось чому ID сховищ швидко з’являються всюди.
Факт 2: Точки монтування під /mnt/pve умовно керуються плагінами сховищ Proxmox; невідповідність шляху — часта самозавдана рана.
Факт 3: NFS існує з 1980-х і досі живить сучасні віртуалізаційні стеки, бо простий, діагностований і «достатній», якщо його грамотно спроектувати.
Факт 4: Зрушення індустрії від файлових VM-дисків до блочних (LVM, RBD, iSCSI) відбулося через передбачуваність затримки та семантику блокувань під навантаженням.
Факт 5: Ceph став популярним у віртуалізації, бо дає спільне блочне сховище без традиційного SAN, але він міняє простоту обладнання на операційну складність.
Факт 6: «Сховище визначене» проти «сховище змонтоване» віддзеркалює класичний поділ: plane керування проти data plane. Багато відмов — це одне плече, що бреше іншому.
Факт 7: Вичерпання inode — реальний продакшен-режим відмови на NFS-шарах з великим обсягом бекапів, особливо коли політики збереження створюють багато дрібних файлів.
Факт 8: Узгодженість імен хостів важлива в кластерах, бо ідентичність впливає на контролі доступу, таргетинг вузлів, сертифікати і іноді списки дозволів сховищ. Перейменування рідко є «лише косметикою».
Факт 9: Генерація systemd mount unit з /etc/fstab може змінити поведінку порядку завантаження так, що це здивує людей, звичних до старших init-систем.

Цитата про надійність, яку варто засвоїти

Парафразована ідея, приписана John Allspaw: надійності не досягають звинуваченням людей; її досягають покращенням системи, яка дозволила помилку статися.

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

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

1) Чому сховище відображається в GUI, якщо воно непридатне?

Тому що GUI показує об’єкти конфігурації кластера. ID сховища існує у /etc/pve/storage.cfg. Доступність є специфічною для вузла і залежить від монтувань, пристроїв, автентифікації та здоров’я.

2) Чи завжди «не доступно на вузлі» означає реальний інцидент?

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

3) Який найшвидший спосіб дізнатися реальну помилку за повідомленням GUI?

Перевірте логи на ураженому вузлі: journalctl -u pvedaemon -u pve-storage. Там часто є підкинута помилка монтування/автентифікації/бекенду.

4) Чи можу я це виправити перезапуском сервісів Proxmox?

Іноді це маскує транзиторні проблеми, але зазвичай це не перший крок. Якщо ОС не може змонтувати або побачити бекенд, перезапуск сервісів лише відтворить помилку з явнішою упевненістю.

5) Чому це стається тільки після перезавантаження?

Через порядок завантаження і персистентність. Мережа може бути ще не готова коли стартують монтування, ZFS-пули можуть не автоімпортуватися через пізню появу пристроїв, iSCSI сесії можуть не залогінитись, або правила фаєрволу змінюються під час завантаження.

6) Я можу `ping` NFS-сервер — чому ж сховище все ще недоступне?

ping доводить дуже мало, окрім ICMP-доступності. NFS потребує RPC-служб, правильних експорту, автентифікації і відкритих портів. Використовуйте showmount -e і докладний mount -v.

7) Для HA і живої міграції мені потрібно спільне сховище?

Для живої міграції без переміщення сховища — так. Інакше потрібна стратегія: реплікація (ZFS replication), міграція сховища з простоєм, або розподілене сховище (Ceph). Виберіть свідомо.

8) Чому Proxmox каже, що сховище активне, але операції все одно падають?

«Active» може означати, що воно змонтовано і базові перевірки пройдені. Операції все одно можуть падати через права в піддиректоріях, заповнені inode, режим read-only, застарілі NFS дескриптори або обмеження типу вмісту.

9) Чи безпечно класти диски VM на NFS dir-сховище?

Може бути безпечно, якщо інженерно правильно налаштовано (стабільна мережа, відповідні опції монтування, правильна конфігурація сервера і реалістичні очікування). Але для передбачуваної низької латентності і менше крайових випадків блочні сховища (Ceph RBD, LVM на SAN) зазвичай поводяться стабільніше під навантаженням.

10) Як запобігти повторенню цієї категорії проблем?

Стандартизувати комісію вузлів: перевіряти монтування/імпорт, валідацію активації сховища через pvesm status, і робити тест читання/запису. Автоматизуйте це як перевірку після перезавантаження.

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

«Не доступно на вузлі» — це точне повідомлення у не зовсім конкретній оболонці. Опис сховища існує; вузол не може його активувати — або йому це заборонено. Ваше завдання — припинити гадати і довести, який шар зламався: охоплення конфігурації, доступ на рівні ОС чи здоров’я бекенду.

Зробіть ось це, в порядку:

Запустіть pvesm status на ураженому вузлі і підтвердіть, що неактивне.
Перевірте /etc/pve/storage.cfg щодо nodes і коректності шляхів.
Провалідуйте бекенд з Linux: монтування, пули, VGs, Ceph health, iSCSI сесії.
Скористайтесь логами, щоб знайти реальний рядок помилки і виправляйте бекенд, а не UI.
Після виправлення підтвердіть, перелічивши вміст сховища і зробивши невеликий запис.
Інституціоналізуйте нудну перевірку: валідація сховищ після перезавантаження на кожному вузлі.

Якщо ви хочете менше нічних сюрпризів, ставтесь до сховища як до першокласної продакшен-системи: явний доступ вузлів, узгоджені шляхи, детерміністичні монтування і health-check-и, що запускаються, коли ніхто не дивиться.

Схожі статті

Proxmox “qemu-img: Could not create”: права доступу, шляхи та виправлення файлової системи, які справді працюють wp-admin WordPress не відкривається: справжні причини та виправлення