Если живая миграция виртуальной машины в Proxmox завершается ошибкой storage is not shared, причина почти всегда одна: диски ВМ лежат на локальном хранилище узла, а кластер ожидает общее хранилище (shared storage), доступное всем нодам одновременно. Проверить это можно в веб-интерфейсе: откройте Datacenter → Storage и посмотрите, есть ли у нужного хранилища флаг Shared в колонке типа.
Общее хранилище — фундамент отказоустойчивого кластера Proxmox VE. Без него невозможны ни живая миграция без копирования дисков, ни механизм HA (High Availability), ни централизованное резервное копирование. В этой статье разберём, какие типы общих хранилищ поддерживает Proxmox, чем они отличаются, как подключить каждый из них и каких ошибок стоит избегать при проектировании.
Что такое общее хранилище и зачем оно нужно
Общим называется хранилище, к которому все узлы кластера обращаются по одному и тому же идентификатору и видят одни и те же данные. Когда диск виртуальной машины размещён на таком хранилище, гипервизору не нужно копировать гигабайты данных при миграции — достаточно передать управление ВМ другому узлу, и тот продолжит работу с тем же файлом или томом.
Локальные хранилища (local, local-lvm, директории на конкретной ноде) такой возможности не дают. Миграция с них технически выполняется, но с полным копированием диска по сети, что занимает заметное время и нагружает канал. Для HA локальные диски не подходят вовсе: при отказе узла кластер не сможет запустить ВМ на другом сервере, потому что её диски физически недоступны.
- 🚀 Живая миграция — перенос работающей ВМ за секунды, без копирования дисков.
- 🛡️ HA и fencing — автоматический перезапуск ВМ на живом узле при отказе сервера.
- 💾 Централизованные бэкапы — снапшоты и архивы доступны с любой ноды.
- 🧩 Гибкость ресурсов — ВМ не привязана к конкретному железу.
Типы общих хранилищ в Proxmox
Proxmox VE из коробки поддерживает несколько сетевых и распределённых технологий. Выбор зависит от бюджета, требований к производительности и того, есть ли у вас отдельное СХД или только сами серверы кластера.
| Тип | Уровень | Сложность | Кому подходит |
|---|---|---|---|
| NFS | Файловый | Низкая | Небольшие кластеры, есть NAS |
| iSCSI (+LVM) | Блочный | Средняя | СХД с таргетами iSCSI |
| Ceph (RBD) | Распределённый | Высокая | Гиперконвергентные кластеры |
| CIFS/SMB | Файловый | Низкая | Бэкапы, ISO-образы |
| GlusterFS | Распределённый | Средняя | Нишевые сценарии |
NFS — самый простой путь: любой NAS или Linux-сервер с nfs-server становится общим хранилищем за несколько минут. Поддерживает образы дисков (qcow2, raw), ISO, бэкапы и снапшоты на уровне файлов. iSCSI отдаёт блочное устройство, поверх которого обычно создаётся общий LVM; снапшоты в такой схеме ограничены, зато производительность предсказуемая. Ceph разворачивается прямо на дисках узлов кластера и даёт репликацию и самовосстановление, но требует минимум трёх узлов и быстрой сети.
Подключение NFS-хранилища
Перед настройкой убедитесь, что NFS-сервер доступен со всех узлов кластера и на нём создан экспорт с корректными правами. В веб-интерфейсе перейдите в Datacenter → Storage → Add → NFS и заполните поля: ID — имя хранилища в кластере, Server — адрес NFS-сервера, Export — путь экспорта, Content — типы содержимого (образы дисков, ISO, бэкапы).
То же самое выполняется из консоли любого узла:
pvesm add nfs vmdata --server 192.168.10.5 --export /export/vmdata --content images,iso,backupПосле добавления хранилище автоматически появится на всех нодах кластера — конфигурация /etc/pve/storage.cfg реплицируется через pmxcfs. Проверьте, что монтирование прошло успешно: в разделе хранилища должна отображаться ёмкость и статус active.
☑️ Проверка NFS-хранилища после подключения
Ceph: гиперконвергентный вариант
Ceph удобен тем, что не требует отдельного СХД: диски серверов объединяются в общий пул, а данные реплицируются между узлами. Proxmox включает встроенный мастер установки Ceph (Node → Ceph), который разворачивает MON, MGR и OSD прямо из веб-интерфейса. После создания пула RBD его можно добавить как хранилище типа RBD и размещать там диски ВМ с снапшотами.
⚠️ Внимание: Ceph критичен к качеству сети. Репликация между узлами генерирует постоянный трафик, поэтому для Ceph рекомендуется выделенная сеть (желательно 10 Гбит/с и выше) и не менее трёх узлов для корректного кворума мониторов. Запуск Ceph на двух узлах или через медленную сеть — частая причина деградации всего кластера.
Число копий данных (size пула) определяет отказоустойчивость: при size=3 кластер переживёт потерю двух копий, но занятое место утраивается. Это нормальная цена за надёжность, и её нужно закладывать при расчёте ёмкости дисков.
iSCSI и общий LVM
Если у вас классическая СХД с таргетами iSCSI, схема выглядит иначе: сначала добавляется сам таргет (Add → iSCSI), а затем поверх него создаётся хранилище LVM с включённым флагом shared. Диски ВМ в этом случае — логические тома LVM на общем блочном устройстве.
У такого подхода есть особенность, о которой часто забывают: на общем LVM нельзя делать снапшоты средствами Proxmox — функция снапшотов для shared LVM не поддерживается. Если снапшоты критичны, рассмотрите NFS с форматом qcow2 или Ceph RBD.
Типичные ошибки и их диагностика
Самая частая проблема — хранилище видно на одном узле, но неактивно на другом. Проверьте сетевую связность с сервером хранения с проблемной ноды и загляните в журнал: journalctl -u pve-storage либо общий лог через journalctl -xe. Для NFS также полезно вручную проверить экспорт командой showmount -e <сервер>.
⚠️ Внимание: не размещайте на одном и том же NFS-экспорте одновременно рабочие диски ВМ и бэкапы этих же машин. При отказе СХД вы потеряете и данные, и резервные копии. Бэкапы должны физически находиться на независимом носителе.
Вторая типичная ситуация — миграция падает с ошибкой о несовпадении хранилищ. Это происходит, когда на разных узлах созданы локальные хранилища с одинаковым именем, но без флага shared: Proxmox считает их разными. Лечится переносом диска ВМ на настоящее общее хранилище через Hardware → Move Disk.
Как проверить, является ли хранилище общим
Откройте файл /etc/pve/storage.cfg на любом узле. У общего хранилища в описании присутствует строка «shared 1», а в списке nodes не указано ограничение на конкретную ноду. Локальные хранилища либо привязаны к узлу, либо не имеют флага shared.
Рекомендации по выбору
Единственно верного варианта не существует — решение зависит от инфраструктуры. Для небольшого кластера с готовым NAS начните с NFS: это быстро, прозрачно и покрывает большинство задач. При наличии трёх и более серверов с запасными дисками и быстрой сетью Ceph даст максимальную автономность без внешнего СХД. Корпоративная СХД с iSCSI — повод использовать блочный доступ, приняв ограничения по снапшотам.
Частые вопросы
Можно ли использовать локальные диски как общее хранилище?
Нет. Локальные хранилища по определению доступны только своему узлу. Существуют обходные схемы вроде репликации ZFS между нодами, но это не настоящее shared-хранилище: миграция возможна лишь с задержкой на синхронизацию, а HA работает с потерей последних изменений.
Сколько узлов нужно для Ceph?
Минимальная рекомендуемая конфигурация — три узла: это обеспечивает кворум мониторов и репликацию данных. Меньшее число узлов технически возможно, но делает кластер уязвимым к отказу любой ноды.
Почему недоступны снапшоты на iSCSI+LVM?
Общий LVM не поддерживает снапшоты на уровне Proxmox из-за особенностей совместного доступа к томам. Альтернативы — NFS с форматом дисков qcow2 или Ceph RBD, где снапшоты реализованы нативно.
Подойдёт ли обычный домашний NAS для общего хранилища?
Для тестов и лаборатории — вполне, чаще всего через NFS. Для продуктивной нагрузки оценивайте производительность дисков и сети NAS: медленное хранилище станет узким местом всех ВМ одновременно.
Нужно ли настраивать хранилище на каждом узле отдельно?
Нет. Достаточно добавить хранилище один раз через веб-интерфейс или pvesm — конфигурация автоматически распространится на все узлы кластера через общий файл /etc/pve/storage.cfg.