Хранилище для HA в Proxmox VE#
Если вы уже прошли статью про сборку кластера Proxmox - QDevice, кворум, разное железо в нодах - у вас, скорее всего, возник следующий закономерный вопрос: а где, собственно, должны лежать диски виртуальных машин, чтобы вся эта конструкция с автоматическим перезапуском VM реально работала, а не просто красиво выглядела в интерфейсе? Вопрос не праздный - я сам не раз видел, как люди настраивают HA, проверяют “работает же!”, а потом теряют данные ровно в тот момент, когда падает нужный узел, потому что диск VM физически лежал только на нем одном.
В этой статье и видео разбираю, какие типы хранилищ в Proxmox вообще годятся для HA, какие только выглядят похожими на shared storage, но подведут в решающий момент, и что выбрать в зависимости от количества нод в кластере.
Если вам понравилась эта статья, то можете поддержать автора, став спонсором на бусти (ссылка есть и в разделе контактов).
Оглавление#
- Роль хранилища в High Availability
- Один узел + требование HA
- Два узла + quorum / witness
- Три и более узлов с общим хранилищем
- Hyperconverged storage, Ceph и альтернативы
- Внешние SAN/NAS решения
- Что для HA не годится вообще
- Рекомендации
- Заключение
1. Роль хранилища в High Availability#
В кластере Proxmox VE механизм High Availability (HA) должен автоматически перезапускать виртуальные машины и контейнеры на другом узле, если исходный узел вышел из строя. Звучит просто, но все держится ровно на одном условии: тип хранилища, на котором лежит диск VM.
Когда узел падает, соседний узел должен успеть:
- получить доступ к диску упавшей VM/CT - без переноса файлов, без “подождите, я скопирую”;
- прочитать актуальную конфигурацию;
- поднять машину без рассинхронизации данных - то есть без риска запустить VM со старой версией диска, пока где-то параллельно висит новая.
Если хранилище физически привязано к упавшему узлу (обычный локальный диск, LVM-thin на локальном SSD и т.п.) - вот и все, дальше можно даже не настраивать HA, она просто не сработает: сосед физически не может достать диск из мертвого сервера.
Что должно уметь хранилище для HA#
- Shared access - диск VM физически доступен с нескольких узлов одновременно, а не скопирован туда “на всякий случай”.
- Кластерная согласованность - блокировки, защита от split-brain, синхронная или как минимум близкая к синхронной репликация.
- Failover без ручных телодвижений - Proxmox сам стартует VM на другом узле, без вашего “ну сейчас я быстренько смонтирую диск руками”.
- Отдельная сеть под хранилище - трафик storage и трафик управления/VM лучше не смешивать, желательно 10GbE и выше, особенно для Ceph.
- Надежность на уровне данных - RAID, репликация Ceph, DRBD, отказоустойчивый NAS/SAN - что-то, что переживет не только падение узла, но и падение одного диска.
- Поддержка в самом Proxmox HA stack - Ceph, iSCSI, NFS, ZFS replication. GlusterFS в этот список я сознательно не включаю - ниже объясню почему.
GlusterFS как штатный тип хранилища в Proxmox больше не поддерживается, начиная с Proxmox VE 9 - разработчики Proxmox прямо объяснили это тем, что сам GlusterFS фактически не развивается апстримом. На Proxmox VE 8 плагин пока еще работает (поддержка 8-й ветки продлится примерно год после релиза 9.0), но заводить на нем новую инфраструктуру я бы не рекомендовал. Технически смонтировать Gluster-том и добавить его как directory storage все еще можно - но это уже не нативная интеграция с HA stack, а самодеятельность на свой риск.
2. Один узел + требование HA#
Периодически встречаю людей, которые искренне удивляются, почему HA не работает на единственном сервере. Разберем, почему так, на четырех вариантах, которые обычно и пробуют:
2.1. Локальное хранилище (ZFS RAID или аппаратный RAID)#
Плюсы понятны: защита от отказа отдельного диска, простота, хорошая производительность. Минус один, но фатальный для нашей темы: failover в принципе невозможен, потому что весь массив физически стоит в одном корпусе. Упал сервер - упал и RAID вместе с ним.
2.2. Репликация ZFS на “пассивный” узел#
ZFS-репликация в Proxmox копирует снапшоты диска на соседнюю ноду по расписанию (минимальный интервал - минуты, не секунды). Это дает вам “холодный резерв” - в случае аварии можно руками поднять VM на второй ноде с потерей данных за последний интервал репликации. Но это не HA: автоматического старта нет, восстановление - ручная операция, и вы теряете все, что записалось после последнего снапшота.
2.3. Репликация на внешний NAS#
Годная схема для бэкапов, но сам NAS в этом случае становится SPOF (single point of failure, единая точка отказа) - вы просто переносите риск с одного сервера на другой, а не убираете его.
2.4. Snapshots + vzdump#
Это резервное копирование, а не HA. Восстановление возможно, но не автоматическое и не мгновенное - пока вы разворачиваете бэкап, сервис уже недоступен, и это никак не соответствует смыслу High Availability.
Итог по разделу: на одном узле HA не бывает физически, точка. Минимум - два узла с общим доступом к хранилищу, и даже тут, как сейчас увидим, есть нюанс.
3. Два узла + quorum / witness#
3.1. Проблема двух узлов - split-brain#
Если у вас всего два узла и между ними пропадает связь, каждый из них видит ситуацию как “я один живой, второй, видимо, умер” - и оба могут попытаться поднять одну и ту же VM одновременно. Это классический split-brain, и именно кластерный кворум должен его предотвращать. Проблема в том, что у двух узлов кворума в чистом виде просто не существует - 1 голос против 1 голоса, большинства нет никогда.
Подробно про сам механизм кворума и голосов я разбирал в статье про сборку кластера Proxmox - здесь коротко: нужен третий голос.
Решение - QDevice#
QDevice - это внешний “судья”, который не хранит и не крутит VM, а просто участвует в голосовании. Вариантов, куда его посадить, много: отдельная легкая VM, мини-ПК, Raspberry Pi, тот же Proxmox Backup Server, если он у вас уже есть. Как только третий голос появляется - у кластера снова есть возможность набрать большинство (2 из 3), и HA начинает работать предсказуемо.
3.2. Хранилище для HA в 2-узловом кластере#
| Storage | Годится для HA | SPOF | Нужен QDevice | Производительность |
|---|---|---|---|---|
| ZFS Local + Replication | Частично (потеря данных за интервал репликации) | Узел | Да | Средняя |
| NFS / iSCSI / NAS | Да | NAS/SAN | Да | Средняя |
| Ceph | Да | Нет (при 3+ мониторах) | Да | Высокая |
| DRBD9 (через LINSTOR) | Да | Нет | Да | Средняя |
DRBD9 в Proxmox - не встроенный плагин. Работает он через отдельный продукт LINBIT под названием LINSTOR (плюс плагин linstor-proxmox), который нужно ставить и настраивать отдельно от самого Proxmox. Публичный репозиторий пакетов LINBIT можно использовать бесплатно для домашней лаборатории и тестов, но без SLA и гарантий - для продакшена LINBIT прямо рекомендует свои платные клиентские репозитории. Так что строка “DRBD9” в таблицах выше - это не “из коробки”, а “еще один компонент инфраструктуры, который вам предстоит поднять и поддерживать”.
Важный нюанс именно для Ceph в 2-узловом кластере: самому Ceph для кворума мониторов (ceph-mon) нужно нечетное количество голосов, а 2 узла этого не дают. На практике для такой схемы третий монитор Ceph поднимают на внешней машине (том же QDevice-хосте, например) - без полноценного узла с OSD, только под голосование мониторов.
4. Три и более узлов с общим хранилищем#
4.1. Почему от трех узлов все внезапно проще#
С тремя узлами кворум работает нативно и без костылей: большинство - это 2 из 3, split-brain при потере одного узла невозможен просто по арифметике голосов, никакого QDevice не требуется. HA-группы настраиваются штатно через интерфейс, без танцев с бубном.
4.2. Shared storage - файловый и блочный доступ#
NFS#
Файловое хранилище, подходит и под диски VM/CT, и под ISO/шаблоны. Настраивается за пару минут:
Datacenter → Storage → Add → NFS
Server: IP вашего NAS
Export: /volume1/proxmox
Content: Disk image, ISO image, Backup
Nodes: все узлы кластераМинус - сам NAS - SPOF. Если он лежит, ложатся все VM, у которых диск на этом NFS, независимо от того, сколько у вас нод в кластере Proxmox.
iSCSI#
Блочный доступ, а не файловый - производительность выше, чем у NFS. Для HA обязательно нужен multipath (несколько независимых сетевых путей до таргета), иначе один упавший сетевой линк положит доступ к дискам так же надежно, как упавший узел.
Datacenter → Storage → Add → iSCSI
Portal: IP вашего SAN
Target: нужный IQN
Nodes: все узлы кластера
Опционально: LVM over iSCSI - если нужны снапшоты и тонкое выделение местаРиск тот же, что у NFS - SPOF на стороне SAN, если он не резервирован сам по себе.
SMB/CIFS#
Только для ISO-образов и шаблонов контейнеров. Диски виртуальных машин на SMB работать не будут - Proxmox такое даже не даст подключить как storage для дисков.
4.3. Итоговое сравнение по производительности и рискам#
| Архитектура | SPOF | Производительность | Требования | Масштабируемость |
|---|---|---|---|---|
| NFS | NAS | Средняя | Низкие | Средняя |
| iSCSI | SAN (без резервирования) | Высокая | Средние | Средняя |
| Ceph | Нет | Высокая | Высокие (сеть, диски, узлы) | Отличная |
Ceph здесь выделяется не просто “хорошими цифрами в таблице” - это единственный вариант из трех, где при правильной настройке в принципе нет единой точки отказа: данные размазаны по всем узлам, а не лежат на одном внешнем устройстве.
5. Hyperconverged storage, Ceph и альтернативы#
Hyperconverged в данном контексте означает, что хранилище и вычисления живут на одних и тех же узлах кластера, без отдельного NAS/SAN как самостоятельного устройства.
Ceph - самый зрелый вариант такого рода в экосистеме Proxmox: RBD-тома для дисков VM, CephFS - для ISO, шаблонов и бэкапов. Данные распределяются между узлами и умеют “самоисцеляться” (self-healing) при выходе диска или узла из строя. Цена вопроса - минимум 3 узла, отдельная выделенная сеть под Ceph-трафик и желательно SSD/NVMe, а не HDD (Ceph на вращающихся дисках - это боль, о которой знает каждый, кто пробовал).
Если вы читаете это как владелец домашней лаборатории на 2-3 нодах и уже прикидываете, не поднять ли Ceph “чтобы было” - сначала прочитайте мою отдельную статью «Почему мне не нужен Ceph storage в Proxmox для домашнего сервера». Ceph - это осознанный выбор для инфраструктуры, где HA действительно критична, а не универсальный “правильный” ответ по умолчанию.
Альтернативы Ceph по духу (не по конкретной реализации) - тот же DRBD9/LINSTOR, разобранный в разделе про 2-узловые кластеры, только он масштабируется и на 3+ узлов.
6. Внешние SAN/NAS решения#
| Тип | Описание | Годится для HA | Примечание |
|---|---|---|---|
| NAS (NFS) | Файловое хранилище | Да | Годится и под диски VM, и под ISO |
| NAS (SMB/CIFS) | Файловое хранилище | Только для ISO/шаблонов | Диски VM через SMB не подключить |
| SAN (iSCSI/Fibre Channel) | Блочный доступ | Да | Multipath строго обязателен |
| Unified Storage (NFS + iSCSI) | Комбинированный | Да | Сам NAS/SAN должен быть отказоустойчивым (кластеризация на его стороне) |
Ключевая мысль этого раздела повторяется третий раз не случайно: HA вашего кластера Proxmox никогда не будет надежнее, чем то единственное устройство, на котором лежат диски VM, если это устройство - одна коробка без собственного резервирования. Кластер Proxmox из пяти нод с единственным несбойным NAS позади - это HA с одним большим, жирным SPOF.
7. Что для HA не годится вообще#
| Storage | Годится для HA | Причина |
|---|---|---|
| Local LVM / Directory | Нет | Виден только одному узлу |
| CIFS/SMB | Нет | Только ISO/шаблоны, не диски VM |
| ZFS локальный без репликации | Нет | Нужна как минимум репликация, а лучше - shared storage |
| Rsync / ручная репликация | Нет | Нет автоматического failover, все руками |
Если что-то из этой таблицы - основа вашего текущего хранилища, а HA в интерфейсе Proxmox при этом “включена” - она включена только формально. Реального failover не будет, вы узнаете об этом в самый неподходящий момент.
8. Рекомендации#
Если сводить всю статью до практических советов:
- Минимум 3 узла для нормального кворума без QDevice - двумя узлами можно обойтись, но с явным пониманием, что третий голос все равно нужен откуда-то.
- Используйте shared или hyperconverged storage - никаких “локальных дисков + надежда”.
- Отдельная сеть под хранилище, желательно 10GbE, особенно если это Ceph.
- Настройте HA-группы в самом Proxmox осознанно, а не “включил галочку и забыл”.
- Регулярные бэкапы через Proxmox Backup Server - HA защищает от падения узла, а не от человеческой ошибки внутри VM или от повреждения данных.
- Периодически проверяйте failover руками - выключите ноду намеренно и посмотрите, что произойдет. Лучше неприятный сюрприз на тесте, чем ночью на проде.
- Для критичных VM - синхронная репликация, а не “раз в час снапшотом”.
- Документируйте архитектуру - через полгода вы сами не вспомните, почему настроили именно так.
9. Заключение#
Если резюмировать: один узел - HA не бывает физически, два узла - нужен QDevice (и, если это Ceph, отдельный третий монитор), три и более - кворум работает сам, и именно с этой точки начинается по-настоящему предсказуемый HA. Конкретный тип хранилища - Ceph, DRBD9/LINSTOR, NAS/SAN - выбирается под бюджет и задачи, а не по принципу “у всех так, значит и мне надо” (GlusterFS как раз показал, к чему приводит ставка на угасающий проект - начиная с Proxmox VE 9 его штатно уже не будет).
Здесь показана база. Дальше - тестирование failover на живом кластере, мониторинг и постепенное усложнение схемы по мере роста инфраструктуры.
