RAID в Proxmox: настройка отказоустойчивого хранилища данных

У вас Proxmox, десяток виртуальных машин, и всё крутится на одном массиве дисков. Пока всё работает — жизнь прекрасна. Но диски — штука смертная, причём умирают они без предупреждения и, как назло, в неподходящий момент. Вопрос не в том, откажет ли диск, а когда. И ответ на этот вопрос определяет, будете ли вы спокойно менять накопитель по hot-swap или судорожно восстанавливать данные из бэкапов (если они есть).

Proxmox VE предлагает три пути к отказоустойчивому серверу: ZFS — встроенный и рекомендованный разработчиками, mdadm — проверенный Linux software RAID, и аппаратный RAID — когда нужна сырая производительность с железным контроллером. Каждый из них решает задачу по-своему, и выбор зависит не от маркетинговых обещаний, а от конкретной нагрузки. Где-то побеждает ZFS с его снапшотами и интеграцией в кластер, где-то — контроллер с батарейным кэшем, который перемалывает random write в разы быстрее. Разберёмся, кому что подходит.

ZFS, mdadm, аппаратный RAID: кто есть кто

Proxmox VE рекомендует ZFS вместо аппаратного RAID для полной интеграции с гипервизором. Логика простая: ZFS даёт снапшоты, компрессию, дедупликацию и контроль целостности данных на уровне файловой системы — без внешних утилит и дополнительных слоёв абстракции. Но рекомендация — не приговор. Есть сценарии, где mdadm или аппаратный контроллер работают лучше.

Аппаратный RAID с батарейным кэшем (BBU) даёт до 4-кратного прироста производительности на базах данных относительно ZFS на отдельных дисках. Это не теория — форумы Proxmox полны бенчмарков, где HW RAID10 на контроллере MegaRAID с BBU показывает разницу в разы на random write. Причина проста: контроллер собирает случайные записи в кэше и сбрасывает их на диски последовательно. ZFS так не умеет — каждая транзакция должна быть атомарно записана.

Но у медали две стороны. ZFS видит каждый диск напрямую и контролирует целостность на уровне блоков. Аппаратный контроллер — это «чёрный ящик», и если он выходит из строя, вам нужен точно такой же (или совместимый) для восстановления массива. Потерял контроллер — потерял данные, даже если диски целы. Кроме того, ZFS поверх аппаратного RAID — спорная конфигурация: контроллер скрывает физические диски, и ZFS не может отслеживать ошибки на отдельных накопителях, теряя одно из главных преимуществ — end-to-end checksumming. Если уж используете аппаратный RAID — ставьте поверх него ext4 или xfs, а не ZFS.

ZFS в Proxmox: снапшоты, компрессия и RAIDZ-экспансия

ZFS в Proxmox — это не просто файловая система, а полноценный менеджер хранилища. Вы создаёте пул, и Proxmox сразу видит его как хранилище для VM-дисков, контейнеров и бэкапов. Снапшоты — атомарные и мгновенные, репликация между нодами кластера — встроенная. Для HA-кластера Proxmox это означает, что при сбое узла виртуальные машины могут автоматически мигрировать на другую ноду, если данные реплицированы через zfs send/receive.

Как это работает на деле: вы настраиваете репликацию VM между двумя нодами с интервалом, скажем, 15 минут. Proxmox автоматически делает инкрементальный ZFS-снапшот, передаёт дельту на вторую ноду, и при сбое первой HA-менеджер запускает VM на второй. Потеря данных — только за последний интервал репликации. Без ZFS такую схему пришлось бы городить через Ceph или shared storage, что на порядок сложнее для небольших инсталляций на 2–3 ноды.

Компрессия LZ4 — ещё один аргумент в пользу ZFS. Она практически бесплатна по CPU (сжатие на уровне 500+ МБ/с на одном ядре), а выигрыш в ёмкости зависит от данных: образы VM сжимаются на 20–40%, бэкапы — на 30–60%. Включается одной командой, и дальше работает прозрачно для всех операций с пулом.

Создание пула — пара команд:

# ZFS mirror (аналог RAID1) для двух дисков

zpool create -f -o ashift=12 rpool mirror /dev/sda /dev/sdb

# RAIDZ2 (аналог RAID6) для шести дисков — защита от двух отказов

zpool create -f -o ashift=12 tank raidz2 /dev/sd{a,b,c,d,e,f}

# Включить компрессию

zfs set compression=lz4 tank

Факт: В Proxmox VE 9 с ZFS 2.3.3 появилась RAIDZ-экспансия — добавление дисков в существующий RAIDZ vdev командой zpool attach без пересоздания пула и без простоя.

Экспансия RAIDZ — одна из тех фич, которую сообщество ждало годами. Раньше, чтобы расширить RAIDZ, приходилось создавать новый vdev и добавлять его в пул, что давало неравномерное распределение данных. Теперь можно добавить один или несколько дисков прямо в существующий vdev:

# Добавить диск в существующий RAIDZ vdev

zpool attach tank raidz2-0 /dev/sdg

# Проверить статус экспансии

zpool status tank

Нюанс: после экспансии пул получает feature flag raidz_expansion, и импортировать его на системах со старой версией ZFS (до 2.3) уже не получится. Учитывайте это при планировании миграций.

Выбор уровня RAID для VM-хранилища

Два фаворита для хранения виртуальных машин в Proxmox — RAID10 (striped mirrors) и RAIDZ2. Выбор между ними — это компромисс между производительностью и ёмкостью.

Если на вашем отказоустойчивом сервере крутятся базы данных или VM с интенсивной записью — RAID10. IOPS на записи у зеркал кратно выше, потому что нет вычисления паритета. Каждая запись уходит только на два диска (оригинал + зеркало), а не рассчитывается через XOR/синдромы с распределением по всему массиву. В реальной нагрузке шесть дисков в RAID10 (три зеркальных пары) дают IOPS, сопоставимые с тремя отдельными дисками, тогда как те же шесть дисков в RAIDZ2 работают как один — каждая запись блокирует весь vdev.

RAIDZ2 хорош для хранения больших объёмов с умеренной нагрузкой на запись: PBS (Proxmox Backup Server), файловые хранилища, ISO-образы. И у него есть козырь — защита от двух одновременных отказов. Для массивов из 6–8 дисков, где ребилд занимает часы, вероятность потерять второй диск во время восстановления — не теоретическая угроза, а вполне реальный сценарий, особенно если диски из одной партии.

Для крупных инсталляций (12+ дисков) стоит посмотреть в сторону dRAID — distributed RAID, появившийся в ZFS 2.1 и поддерживаемый в Proxmox VE 9. dRAID распределяет «запасные» диски по всему пулу, что кратно ускоряет ребилд: вместо записи на один hot-spare данные восстанавливаются параллельно на все диски. Для массива из 24 HDD время ребилда сокращается с десятков часов до нескольких — а это прямо влияет на окно уязвимости, когда массив работает в деградированном состоянии.

mdadm: когда простота — это преимущество

Не всем нужен ZFS. Если задача — зеркалирование boot-дисков или создание простого массива без накладных расходов на ARC и чексуммы, mdadm справляется отлично. У него нет снапшотов, нет компрессии, нет контроля целостности на уровне блоков — зато нет и требований к ECC RAM, а потребление памяти измеряется килобайтами, а не гигабайтами.

Типичный сценарий: RAID1 для корневого раздела Proxmox на двух SSD. Система грузится с любого из дисков, при сбое одного — второй продолжает работать. Proxmox при установке умеет настраивать ZFS mirror для root-раздела, но если вы предпочитаете ext4 или xfs — mdadm ваш вариант.

# Создать RAID1 из двух дисков

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

# Сохранить конфигурацию

mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# Настроить автоматическую ресинхронизацию и мониторинг

mdadm --monitor --daemonise --mail=admin@example.com /dev/md0

mdadm позволяет настраивать software RAID без аппаратных контроллеров, с автоматической ресинхронизацией и уведомлениями о сбоях. Для boot-дисков этого достаточно. Ещё один плюс mdadm — совместимость. Если диск из массива вставить в другой сервер с Linux, mdadm подхватит метаданные и соберёт массив автоматически. С аппаратным RAID такой трюк не пройдёт — нужен совместимый контроллер.

Для хранилища VM лучше использовать ZFS — вы получите снапшоты и репликацию, которых у mdadm нет. А вот гибридная схема — mdadm RAID1 на root, ZFS-пул на отдельных дисках для данных — встречается часто и работает стабильно.

Железо: HBA, ECC RAM и кэширующие SSD

Выбор железа определяет, как будет вести себя RAID в Proxmox под нагрузкой. Несколько правил, которые сэкономят нервы.

Контроллер для ZFS — только HBA в режиме JBOD (IT-mode). Серия LSI 9300/9400 (переименованная в Broadcom) или их аналоги — стандарт индустрии. FakeRAID на чипсетах Intel (RST) или AMD — категорически не подходит: Proxmox не увидит отдельные диски, а ZFS не сможет контролировать их напрямую. Если у вас есть аппаратный RAID-контроллер, а ZFS нужен — перепрошейте контроллер в IT-mode (для карт на чипах LSI это штатная процедура, инструкции есть на форумах ServeTheHome и STH). Диски после перепрошивки станут видны ОС как обычные SATA/SAS-устройства.

Совет: ECC RAM для ZFS — не опция, а необходимость. ARC (кэш чтения) живёт в оперативке, и ошибка в бите может тихо повредить данные до записи на диск.

SSD для ускорения ZFS используются в двух ролях. L2ARC — кэш второго уровня для чтения, полезен когда рабочий набор данных не помещается в RAM. SLOG (отдельный лог устройства для ZIL) — ускоряет синхронную запись, что критично при работе с NFS или iSCSI. Без NFS/iSCSI SLOG не даёт заметного эффекта — ZFS и так буферизует записи в RAM перед коммитом.

Для аппаратного RAID ситуация другая: тут важен сам контроллер с BBU или NVRAM-кэшем. Broadcom MegaRAID 9560 или Adaptec SmartRAID — примеры карт с защищённым кэшем. Контроллер без батарейки в Write-Back режиме — это рулетка: при отключении питания данные из кэша не дойдут до дисков.

Мониторинг и обслуживание: scrub, замена дисков, уведомления

RAID любого типа — это не «настроил и забыл». Без мониторинга вы узнаете о проблеме, когда откажет второй диск в массиве с одной паритетной группой. А это уже потеря данных. Особенно коварна ситуация с «тихой деградацией»: диск формально в строю, S.M.A.R.T. не ругается, но отдельные секторы уже нечитаемы. Без регулярных проверок вы об этом не узнаете до момента ребилда после отказа другого диска — и тогда ребилд упадёт с ошибкой.

Для ZFS — zpool scrub раз в одну-две недели. Scrub проходит по всем блокам пула, проверяет чексуммы и исправляет ошибки, если есть избыточная копия данных. Это единственный способ поймать silent data corruption (тот «bit rot», о котором многие слышали, но мало кто видел — пока не столкнулся).

# Запустить scrub вручную

zpool scrub tank

# Автоматизировать через cron (каждое воскресенье в 2:00)

echo "0 2 * * 0 root /sbin/zpool scrub tank" >> /etc/crontab

# Проверить результаты

zpool status tank

ZED (ZFS Event Daemon) отправляет уведомления при ошибках чтения/записи, деградации пула или завершении scrub. Настройка — в /etc/zfs/zed.d/zed.rc, где указывается email-адрес для алертов. Если вы используете Zabbix или Prometheus — парсите результат zpool status и zpool list через кастомные скрипты: ключевые метрики — health (ONLINE/DEGRADED/FAULTED), capacity (процент заполнения пула, ZFS начинает деградировать по производительности при заполнении выше 80%) и errors (количество ошибок чтения/записи/чексумм по каждому диску).

Замена диска в ZFS — онлайн-операция:

# Заменить сбойный диск на новый

zpool replace tank /dev/sdd /dev/sdh

# Следить за ресинхронизацией

zpool status tank

Для mdadm — аналогичный процесс через mdadm --manage /dev/md0 --remove /dev/sda1 и --add. Мониторинг — через mdadm --monitor или интеграцию с Zabbix/Prometheus через парсинг /proc/mdstat.

Что дальше

RAID в Proxmox — это фундамент, на котором стоит отказоустойчивый сервер. ZFS с интеграцией в Proxmox, репликацией и снапшотами — выбор для тех, кто строит HA-кластер и хочет управлять хранилищем из одного места. Аппаратный RAID с BBU — для нагрузок, где критичен каждый IOPS на записи, и вы готовы привязаться к конкретному контроллеру. mdadm — для простых сценариев, где надёжность нужна без накладных расходов и дополнительных требований к оперативной памяти.

Гибридные схемы тоже работают: mdadm на boot, ZFS на данных, аппаратный контроллер в JBOD-режиме для проброса дисков. Не бойтесь комбинировать — лучшая архитектура хранилища та, которая учитывает вашу конкретную нагрузку, бюджет и навыки команды.

А какую бы технологию вы ни выбрали — настройте мониторинг и регулярные scrub/проверки. Массив без наблюдения деградирует тихо, и вы об этом узнаете в тот день, когда уже будет поздно.