Общее хранилище для кластера: NFS, iSCSI или Ceph

MAATRIX

Кластер виртуализации без общего хранилища — это просто несколько отдельных серверов, которые умеют показывать одну веб-панель. Живая миграция не поедет, потому что диск виртуалки физически лежит на одном узле. HA не подхватит упавшую ноду, потому что данные для перезапуска VM просто недоступны на других узлах. Рано или поздно вопрос «а на чём хранить диски виртуалок» встаёт ребром, и тут начинается спор между NFS, iSCSI и Ceph — у каждого варианта своя цена простоты, скорости и надёжности.

Зачем общее хранилище нужно именно для кластера

Смысл кластера виртуализации — не «несколько серверов в одной панели», а возможность переносить нагрузку между узлами без простоя и переживать падение одного из них. Оба этих механизма требуют, чтобы диск виртуальной машины был физически доступен сразу с нескольких узлов одновременно.

Живая миграция копирует память процесса на другой узел, пока сама VM продолжает работать — но если диск виртуалки лежит только на локальном хранилище исходного узла, миграция либо невозможна, либо превращается в полное копирование образа диска по сети (долго, с простоем). Подробно про механику самого переноса памяти — в статье про живую миграцию виртуалок. HA работает иначе: если узел упал, кластер должен перезапустить VM на другом узле — а значит, диск этой VM должен быть доступен и с узла, который её никогда не запускал.

Отсюда требование: хранилище должно отдавать одни и те же данные сразу нескольким гипервизорам. Локальный диск, LVM-thin или ZFS на одном узле для этого не годятся в принципе — это по-прежнему привязка к конкретному серверу, о чём подробнее в статье про типы хранилищ в Proxmox. Значит, нужен либо сетевой файловый доступ (NFS), либо сетевой блочный доступ (iSCSI), либо распределённая система хранения (Ceph). У всех трёх разная цена в настройке, разная производительность и — что критичнее всего для продакшна — разное отношение к отказоустойчивости самого хранилища.

NFS: проще всего настроить, но со своей ценой

NFS — файловый протокол: сервер отдаёт по сети каталог, а клиенты монтируют его как обычную папку. Для Proxmox это буквально пара минут настройки: на сервере хранилища поднимаете экспорт, на узлах кластера добавляете NFS-хранилище через веб-интерфейс — и всё, диски виртуалок лежат в общем каталоге как файлы .qcow2 или .raw.

Пример экспорта на стороне сервера хранилища (Debian/Ubuntu):

apt install nfs-kernel-server
mkdir -p /export/vm-storage
echo "/export/vm-storage 10.0.10.0/24(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports
exportfs -ra
systemctl restart nfs-kernel-server

На стороне Proxmox — либо через pvesm, либо в /etc/pve/storage.cfg:

nfs: shared-nfs
    export /export/vm-storage
    path /mnt/pve/shared-nfs
    server 10.0.10.5
    content images,iso
    options vers=4.1

Плюсы очевидны: минимальный порог входа, знакомая любому админу файловая модель, простая диагностика («не видно диск» — почти всегда вопрос монтирования или прав, а не экзотика). Из минусов — производительность NFS обычно скромнее, чем у блочных протоколов, особенно на случайной записи мелкими блоками (типичная нагрузка баз данных внутри VM), и почти всегда упирается в возможности одного сервера-экспортёра.

Главная же проблема — отказоустойчивость. NFS-сервер в базовом варианте один. Если он падает — падают диски всех виртуалок сразу, независимо от того, сколько у вас узлов гипервизора и насколько хорошо настроен HA. Получается парадокс: вы строите отказоустойчивый кластер поверх одной точки отказа. Для тестового стенда или некритичной нагрузки это осознанный и разумный компромисс. Для продакшна нужно либо смириться (и понимать риск), либо городить отдельную отказоустойчивость самого NFS-сервера — кластерную файловую систему под экспортом, DRBD, corosync+pacemaker с плавающим IP и так далее, — а это уже отдельный проект сложности, сравнимой с тем, от чего вы пытались уйти.

iSCSI: блочный доступ, обычно быстрее NFS

iSCSI — тоже сетевой протокол, но блочный: сервер (target) отдаёт клиентам (initiator) не файлы, а «диск» на уровне блоков, как будто это локальный SCSI-накопитель. Для виртуализации это обычно даёт лучшую производительность, чем файловый NFS, — меньше накладных расходов протокола, ближе к «сырому» доступу к блочному устройству.

Настройка на стороне сервера (Linux LIO через targetcli):

apt install targetcli-fb
targetcli
/> backstores/block create vm-lun0 /dev/sdb
/> iscsi/ create iqn.2026-08.local:storage.vm
/> iscsi/iqn.2026-08.local:storage.vm/tpg1/luns create /backstores/block/vm-lun0
/> iscsi/iqn.2026-08.local:storage.vm/tpg1/acls create iqn.2026-08.local:initiator.node1
/> iscsi/iqn.2026-08.local:storage.vm/tpg1/acls create iqn.2026-08.local:initiator.node2
/> saveconfig

В Proxmox добавляете iSCSI-хранилище (это отдаёт «сырой» LUN), а поверх него — LVM (не thin, обычный), чтобы несколько узлов могли безопасно делить один LUN на тома для разных VM:

iscsi: shared-iscsi
    portal 10.0.10.6
    target iqn.2026-08.local:storage.vm
    content none

lvm: shared-lvm
    vgname vg-vm-storage
    base shared-iscsi:0.0.0.scsi-...
    content images
    shared 1

Сложность настройки заметно выше, чем у NFS: нужно понимать IQN, ACL, LUN-мэппинг, а поверх ещё LVM с флагом shared — забыть его выставить в кластере с несколькими узлами означает риск повреждения данных при одновременной записи с разных нод. Диагностика проблем тоже требует больше специфичных знаний (iscsiadm, состояние сессий, multipath при нескольких путях к таргету).

Отказоустойчивость самого хранилища — та же история, что с NFS: если iSCSI-таргет не является сам по себе распределённым или кластерным, это снова единая точка отказа, просто на уровне блочного, а не файлового протокола. Готовые СХД со встроенным iSCSI обычно уже решают эту задачу дублированием контроллеров, но самодельный Linux-таргет на одном сервере — нет.

Ceph: без единой точки отказа, но с ценой в сложности

Ceph — распределённая система хранения: данные реплицируются между несколькими узлами (обычно по умолчанию в три копии), и хранилище в целом переживает отказ отдельного узла или диска без вмешательства администратора и без единой точки отказа «из коробки». Именно это отличает Ceph от NFS и iSCSI в базовой конфигурации — там отказоустойчивость самого хранилища нужно строить отдельно, а в Ceph она встроена в саму архитектуру за счёт репликации.

В Proxmox Ceph интегрирован нативно — поднимается прямо из веб-интерфейса или через pveceph:

pveceph init --network 10.0.20.0/24
pveceph mon create
pveceph mgr create
pveceph osd create /dev/sdb

После создания OSD на нужном числе узлов и настройки пула создаётся RBD-хранилище:

pveceph pool create vm-pool --size 3 --min_size 2

Здесь size 3 — три реплики каждого блока данных, min_size 2 — минимум живых копий, при котором пул ещё принимает запись (если реплик остаётся меньше, Ceph уходит в защитный read-only, чтобы не потерять консистентность).

Цена этой отказоустойчивости — операционная сложность, причём заметно выше, чем у NFS и iSCSI вместе взятых. Ceph требует отдельной понимания архитектуры (MON, OSD, MGR, PG, crush map), отдельного мониторинга состояния кластера (ceph -s, health warnings), внимания к балансировке и производительности сети между узлами (трафик репликации сам по себе ощутимый), и в целом заметно большей экспертизы для повседневной эксплуатации и troubleshooting, чем «просто смонтировать NFS». Для маленького кластера (условно 3 узла с ограниченным числом дисков) Ceph технически работает, но накладные расходы на репликацию и обслуживание чувствуются острее, чем в крупной инсталляции — это стоит учитывать при выборе для небольших сред.

Также важно: Ceph — это не только хранилище виртуалок, а полноценная распределённая система со своей философией эксплуатации. Она хорошо окупается там, где отказоустойчивость самого хранилища действительно критична для бизнеса, и плохо — там, где кластер собран «для порядка» на паре недорогих серверов.

Матрица выбора: что важно для решения

Таблица намеренно не содержит точных цифр производительности — они сильно зависят от дисков, сети (1GbE против 10GbE и выше) и профиля нагрузки внутри VM, а гадать про конкретные IOPS без реальных измерений на вашем железе смысла нет. Относитесь к строке «производительность» как к порядку величин, а не гарантии.

Практические сценарии: что выбрать в вашем случае

Если кластер тестовый, учебный или для нагрузки, простой не критичен — NFS часто самый разумный практичный выбор, несмотря на компромисс с единой точкой отказа. Час на настройку, минимум движущихся частей, понятная диагностика. Риск падения NFS-сервера здесь осознанно принимается как приемлемый — вы теряете время на восстановление, но не бизнес.

Если нужна лучшая производительность блочного доступа (например, база данных внутри VM с активной случайной записью), а сложность Ceph пока избыточна или нет ресурсов на его освоение — iSCSI хороший промежуточный вариант. Он не решает вопрос отказоустойчивости самого хранилища «из коробки», но даёт выигрыш в производительности по сравнению с NFS при сопоставимой (хоть и более высокой) сложности настройки.

Если кластер продакшн-уровня и отказоустойчивость самого хранилища критична — то есть падение одного сервера хранилища не должно останавливать бизнес, — Ceph оправдывает свою сложность. Именно здесь окупается время, вложенное в изучение архитектуры, мониторинга и повседневной эксплуатации: вы получаете хранилище, которое переживает отказ узла так же, как сам кластер виртуализации переживает отказ узла-гипервизора при HA. Но заходить в Ceph «на всякий случай» на паре серверов без реальной потребности в такой отказоустойчивости — плохой размен сложности на пользу.

Отдельно стоит помнить про кворум: для кластера, где решается вопрос отказоустойчивости, важно не только хранилище, но и число управляющих узлов — два узла кластера сами по себе не защищают от split-brain, минимум для честного кворума — три, подробнее в статье про кворум и зачем нужен третий узел и про то, почему кластер из двух узлов — плохая идея.

Частые вопросы