Хранилище для HA в Proxmox VE: глубокий технический обзор#
Оглавление#
- Роль хранилища в High Availability
- Сценарий: один узел + требование HA
- Сценарий: два узла + quorum / witness
- Сценарий: три и более узлов с общим хранилищем
- Hyperconverged storage (Ceph и др.)
- Внешние SAN/NAS решения
- Типы хранилищ, не подходящие для HA
- Рекомендации и best practices
- Заключение
1. Роль хранилища в High Availability#
В кластере Proxmox VE механизм High Availability (HA) обеспечивает автоматический перезапуск виртуальных машин или контейнеров на других узлах при выходе одного из серверов из строя. Работа HA напрямую зависит от того, какое хранилище используется.
Почему тип хранилища (storage) критичен для HA#
Когда один узел падает, другой должен:
- иметь доступ к дискам виртуальной машины (VM/CT);
- считать конфигурацию;
- запустить экземпляр без рассинхронизации данных.
Требования к хранилищу для HA-кластера#
- Shared access (общий доступ) — диск VM должен быть доступен с нескольких узлов.
- Кластерная согласованность — поддержка блокировок, защита от split-brain, синхронная/асинхронная репликация.
- Failover без ручного вмешательства — автоматический старт VM на другом узле.
- Сетевые требования — отдельная сеть для хранилища, минимум 10GbE желательно.
- Надёжность данных — RAID, репликация Ceph, DRBD, отказоустойчивые NAS/SAN.
- Поддержка Proxmox HA stack — Ceph, iSCSI, NFS, ZFS replication, GlusterFS (не поддерживается начиная с версии Proxmox VE9).
2. Сценарий: один узел + требование HA#
2.1. Локальное хранилище с ZFS RAID или аппаратным RAID#
- Плюсы: защита дисков, простота, производительность
- Минусы: нет failover, HA невозможен
2.2. Репликация ZFS на “пассивный” узел (ноду)#
- Позволяет иметь так называемый «cold standby», но не HA, нет автоматического старта VM
2.3. Репликация на внешний NAS/СХД#
- Подходит для резервного копирования, но NAS становится SPOF (единая точка отказа)
2.4. Snapshots + vzdump#
- Только восстановление данных, failover невозможен
Вывод: HA невозможен на одном узле, нужен минимум 2+ узла с общим хранилищем (хранилище).
3. Сценарий: два узла + quorum#
3.1. Проблема двух узлов: split-brain#
- Без третьего голоса (QDevice) HA не работает корректно.
Решение: QDevice#
- Варианты: отдельная VM, мини-PC, PBS, Raspberry Pi
- После добавления → 3 голоса, HA работает
3.2. Хранилище для HA в 2-узловом кластере#
| Storage | HA-совместимость | SPOF | Требуется QDevice | Производительность |
|---|---|---|---|---|
| ZFS Local + Replication | Да (частично) | Узел | Да | Средняя |
| NFS / iSCSI / NAS | Да | NAS | Да | Средняя |
| Ceph | Да | Нет | Да | Высокая |
| DRBD9 | Да | Нет | Да | Средняя |
4. Сценарий: три и более узлов с общим хранилищем#
4.1. Почему от 3 узлов всё проще#
- Кворум поддерживается нативно
- Нет split-brain при потере одного узла
- Простое управление HA
4.2. Shared storage#
4.2.1 NFS#
- Файловое подключение, подходит для VM/CT дисков и ISO
- NAS как SPOF (единая точка отказа). Потеря связи с NAS, все виртуальные машины выключются.
4.2.2 iSCSI#
- Блочный доступ, multipath для HA
- SPOF SAN возможен
4.2.3 SMB/CIFS#
- Только для ISO/шаблонов, не для дисков VM
4.3. Hyperconverged-хранилище#
- Ceph: RBD/FS, 3+ узла, self-healing, блочное хранилище
| Архитектура | SPOF | Производительность | Требования | Масштабируемость | HA совместимость |
|---|---|---|---|---|---|
| NFS | NAS | Средняя | Низкие | Средняя | Да |
| iSCSI | SAN | Высокая | Средние | Средняя | Да |
| Ceph | Нет | Высокая | Высокие | Отличная | Да |
5. Hyperconverged storage (Ceph и др.)#
5.1. Ceph#
- RBD для VM дисков
- CephFS для ISO, templates, backups
- Требует 3+ узла, отдельная сеть, SSD/NVMe
6. Внешние SAN/NAS решения#
| Тип | Описание | HA совместимость | Примечание |
|---|---|---|---|
| NAS (NFS/CIFS) | Файловое хранилище | Да (NFS) | CIFS только для ISO/шаблонов |
| SAN (iSCSI/Fibre Channel) | Блочный доступ | Да | Multipath обязателен |
| Unified Storage | NFS + iSCSI | Да | NAS/SAN кластеризация рекомендована |
Примеры подключения:
# NFS
Datacenter -> Storage -> Add -> NFS
Server: IP NAS
Export: /volume1/proxmox
Content: Disk image, ISO, backup
Nodes: все узлы
# iSCSI
Datacenter -> Storage -> Add -> iSCSI
Target: IQN LUN
Portal: IP SAN
Nodes: все узлы
Optionally: LVM over iSCSI
7. Типы хранилищ, не подходящие для HA#
| Storage | HA совместимость | Примечание | |
|---|---|---|---|
| Local LVM/Director | отсутствует | Только один узел | |
| CIFS/SMB | отсутствует | Только ISO/шаблоны | |
| ZFS локальный без replication | отсутствует | Требуется DR/репликация | |
| Rsync / ручная репликация | отсутствует | Нет автоматического failover |
8. Рекомендации и best practices#
Минимум 3 узла для кворума
Использовать shared или hyperconverged storage
Отдельная сеть для хранилища (10GbE)
Настройка HA группы в Proxmox
Регулярные бэкапы с помощью Proxmox Backup Server
Тестирование failover и мониторинг
Синхронная репликация для критично важных VM
Документирование архитектуры (чтобы не забыть что ты там себе напроектировал)
9. Заключение#
Один узел ≠ HA
Два узла требуют QDevice
Три и более узлов — оптимальная конфигурация
Выбор хранилища зависит от задач и бюджета: Ceph, GlusterFS, DRBD, NAS/SAN
Обязательно делаем бэкапы и сетевое резервирование
Следуя этим принципам, кластер Proxmox VE будет устойчивым, масштабируемым и обеспечит автоматический failover критичных VM и контейнеров.