Масштабирование системы хранения без простоя: расширение ZFS, RAID, Ceph и полок

Почему масштабирование без простоя критичная задача

Час недоступности интернет-магазина с оборотом 1 млн рублей в сутки стоит около 42 000 рублей упущенной выручки. SLA 99,99% разрешает не больше 4 минут простоя за месяц, SLA 99,9% - примерно 43 минуты. Плановое окно на 6 часов, которое обычно выпрашивают у бизнеса, не влезает ни в один из этих договоров. SaaS-платформа теряет не только деньги: недоступность в момент отчётности или отгрузки бьёт по контрактам и репутации.

Отсюда практическое требование к любой системе хранения: она обязана увеличивать объём и производительность на работающих сервисах. ZFS добавляет диски в живой пул командой zpool add, mdadm перестраивает массив на лету через --grow, Ceph вводит новые OSD и запускает backfill без остановки клиентов, а SAS-полку подключают к работающему серверу, если HBA и бэкплейн поддерживают hot-plug.

Онлайн закрываются три задачи:

• объём: добавить диски в пул ZFS, расширить RAID-массив, подключить полку JBOD;
• производительность: распределить нагрузку по большему числу шпинделей в mdadm или Ceph;
• замена железа: вывести старые диски по одному, не выключая сервер.

Перед планированием разберите архитектуру программного хранилища: уровни дисков, RAID, пула, файловой системы и кэша определяют, какой метод расширения сработает в вашей конфигурации, а какой упрётся в ограничение технологии.

Расширение пула ZFS: добавление дисков и vdev

Пул ZFS собирается из vdev, а vdev из дисков. Ограничение жёсткое: добавить один диск в существующий RAIDZ vdev нельзя. Рабочих путей два, подключить новый vdev целиком или заменить все диски vdev на более ёмкие.

Добавление нового vdev в существующий пул

1. Соберите инвентарь: lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL и zpool status -v. Найдите новые устройства и убедитесь, что на них нет таблиц разделов и файловых систем.
2. Сотрите остатки старых метаданных, иначе ZFS или mdadm подхватит чужую подпись: wipefs -a /dev/sdX. Работайте по стабильным путям /dev/disk/by-id/ata-..., потому что имена /dev/sdX меняются после перезагрузки.
3. Добавьте vdev: zpool add tank raidz1 /dev/disk/by-id/ata-WDC_WD80...-1 /dev/disk/by-id/ata-WDC_WD80...-2 /dev/disk/by-id/ata-WDC_WD80...-3 /dev/disk/by-id/ata-WDC_WD80...-4. Ключ -f не нужен и опасен: ZFS выполнит команду без дополнительных вопросов.
4. Проверьте результат: zpool status tank и zpool list -v. Новый vdev появится в выводе, ёмкость пула вырастет сразу.

Пример из практики: пул tank из четырёх дисков 4 ТБ в RAIDZ1 даёт около 10,9 ТиБ полезного места. Добавление vdev RAIDZ1 из четырёх дисков 8 ТБ приносит ещё 21,8 ТиБ, итого около 32,7 ТиБ при той же схеме избыточности.

ZFS не перераспределяет уже записанные блоки. Новые данные ложатся пропорционально свободному месту, поэтому большой vdev начнёт заполняться быстрее, а старый останется с прежней заполненностью. В OpenZFS 2.3 появилась команда zfs rewrite, которая перезаписывает существующие блоки по актуальному распределению; на более старых версиях помогает перезаливка датасета через send/recv.

Второй vdev удваивает число точек отказа: пул жив, пока цел каждый vdev. Новый vdev без чётности (stripe) превращает отказ одного диска в потерю всего пула. Планируйте избыточность нового vdev не ниже, чем у существующего.

В TrueNAS SCALE действие выполняется через UI: Storage, выбранный пул, кнопка Add Vdev, выбор типа (Mirror, RAIDZ1, RAIDZ2) и дисков. Мастер покажет расчётную ёмкость до подтверждения, поэтому ошибка с типом vdev видна заранее. Если пул только предстоит создать, начните с руководства по созданию пула, томов и оптимизации под нагрузку.

Замена дисков на больший объём и авторасширение

1. Включите автоматическое расширение до начала работ: zpool set autoexpand=on tank.
2. Замените один диск: zpool replace tank /dev/disk/by-id/ata-OLD /dev/disk/by-id/ata-NEW.
3. Дождитесь resilver: zpool status tank покажет прогресс в процентах. Диск 8 ТБ на SATA перестраивается обычно 6-12 часов, на SAS 12 Гбит/с быстрее, при активной записи медленнее.
4. Повторите шаги для каждого диска vdev. Пул расширится после замены последнего диска, новый объём появится в zpool list и в датасетах.

В TrueNAS SCALE после замены последнего диска в разделе Storage появляется кнопка Expand для пула: она делает то же, что autoexpand, но по явному действию администратора.

Главная опасность этапа resilver: в RAIDZ1 во время перестроения остаётся одна копия данных, и второй отказ диска уничтожает пул. Для дисков от 8 ТБ схему RAIDZ2 или mirror выбирают осознанно, а замену проводят в часы минимальной нагрузки. Диск с ошибками чтения может затянуть resilver на сутки: проверьте smartctl -a /dev/sdX заранее, рост Reallocated_Sector_Ct и Current_Pending_Sector говорит о том, что диск не доживёт до конца операции.

Расширение RAID-массива без остановки

Программный RAID на Linux расширяется на лету, аппаратный зависит от возможностей контроллера. Перед началом нужна свежая резервная копия: онлайн-операции не отменяют правило «нет бэкапа, нет данных».

Онлайн-расширение программного RAID (mdadm)

1. Посмотрите текущий состав: mdadm --detail /dev/md0 и cat /proc/mdstat.
2. Добавьте новый диск: mdadm --add /dev/md0 /dev/sdX. Устройство получит метку spare и станет резервным.
3. Расширьте массив: mdadm --grow /dev/md0 --raid-devices=5. Для RAID1 команда увеличивает число зеркал, для RAID5 и RAID6 запускает reshape.
4. Следите за прогрессом: cat /proc/mdstat покажет проценты и скорость. Ускорить или притормозить процесс можно через /proc/sys/dev/raid/speed_limit_max и speed_limit_min, значения в КБ/с, верхний предел по умолчанию 200 000 КБ/с.
5. Расширьте файловую систему: resize2fs /dev/md0 для ext4 или xfs_growfs /mountpoint для XFS.

Reshape RAID5 из четырёх дисков в пять на объёмах 8 ТБ идёт от 12 часов до суток, RAID6 дольше, потому что пересчитываются две чётности. Массив остаётся доступным на чтение и запись, но производительность падает, иногда в разы. Если массив собран из разделов, порядок другой: сначала расширяется раздел (parted, growpart), затем массив, затем файловая система. Пошаговые команды для mdadm, ZFS и LVM с примерами замены диска собраны в руководстве по программным RAID-массивам.

Аппаратный RAID: возможности и ограничения

Контроллеры LSI/Broadcom и Adaptec поддерживают Online Capacity Expansion (OCE) и смену уровня RAID на работающей системе. Для storcli расширение массива с добавлением диска выглядит так: storcli /c0/v0 start migrate type=raid5 add. Утилита MegaCli решает ту же задачу командой с флагом -LDRecon.

Ограничения и риски:

• часть контроллеров и прошивок не умеет OCE, проверьте матрицу поддержки для своей модели и версии прошивки;
• на время миграции кэш записи часто переводят в режим write-through, дисковые операции замедляются;
• некоторые модели требуют перезагрузки или остановки виртуальных дисков, и тогда простоя не избежать;
• прерывание миграции питанием оставляет массив в промежуточном состоянии, поэтому ИБП обязателен.

Проверка после операции: storcli /c0/v0 show all, затем mdadm --detail /dev/md0 для программных массивов и df -h для файловой системы.

Подключение дополнительных полок хранения

Полка JBOD расширяет систему без замены сервера. Требования к железу: HBA в режиме IT (например, LSI 9300-8e), внешние кабели SAS SFF-8644, экспандер в самой полке и диски из списка совместимости производителя. Диски SATA в SAS-экспандере работают, но hot-plug для них поддерживается не везде.

Порядок подключения к работающему серверу:

1. Подключите полку к HBA внешним SAS-кабелем, затем включите питание полки.
2. Проверьте обнаружение: dmesg -T | tail -50 и lspci -vv | grep -i sas. Ошибки I/O error и таймауты говорят о проблемах с кабелем или прошивкой.
3. Убедитесь, что диски не собрались в чужой массив автоматически: lsblk и cat /proc/mdstat. Остатки старых метаданных снимаются командой wipefs -a /dev/sdX.
4. Добавьте диски в существующий пул ZFS, в новый RAID или отдайте их под отдельные тома.

Настройка multipath для отказоустойчивости

Два пути к одному устройству закрывают отказ кабеля или порта. Пакет multipath-tools собирает пути в одно устройство /dev/mapper/mpathX. В /etc/multipath.conf настраивают три блока: blacklist (локальные диски по wwid, чтобы система их не трогала), defaults (path_checker tur, failback immediate) и devices (параметры конкретной модели полки).

После правки конфигурации: multipath -r для перезагрузки правил и systemctl restart multipathd, затем проверка multipath -ll. У активного устройства должно быть два и более пути, часть в состоянии active ready running, остальные ghost или standby. Если виден один путь, второй кабель, порт или зона на коммутаторе не работают.

У ZFS отдельное требование: пул собирают по стабильным путям, а multipath-устройства используют, когда нужна отказоустойчивость каналов. Смешивать пути к одному диску в одном пуле нельзя, иначе ZFS увидит два разных устройства и повредит данные.

Расширение кластера Ceph

Ceph масштабируется горизонтально: добавление OSD и узлов не останавливает сервисы, но запускает backfill. Данные перераспределяются по CRUSH-карте, и процесс конкурирует с рабочей нагрузкой за диски и сеть.

Добавление OSD на существующих узлах

1. Проверьте здоровье: ceph -s и ceph osd tree. Новые OSD вводите в статусе HEALTH_OK.
2. Очистите диск от старых метаданных: ceph-volume lvm zap /dev/sdX --destroy.
3. Создайте OSD: ceph-volume lvm create --data /dev/sdX или в кластере под управлением cephadm: ceph orch daemon add osd node1:/dev/sdX.
4. Проверьте результат: ceph osd tree и ceph osd df. Новый OSD получит вес по размеру диска, при необходимости скорректируйте: ceph osd crush reweight osd.12 7.2 (вес в ТБ).
5. Следите за backfill: ceph -s показывает объекты в состоянии recovery и backfill, ceph pg stat - число активных PG.

Число PG планируют заранее: ориентир 100 PG на OSD с учётом репликации. Для 24 OSD и трёх реплик получается около 800 PG, на практике берут 1024. Модуль pg_autoscaler в современных выпусках считает это сам, но в маленьких кластерах (меньше 5 OSD) автоматику лучше отключить.

Добавление нового узла в кластер

1. Подготовьте сервер: та же версия Ceph, доступ по SSH с ключом кластера, синхронизированное время (chrony), отдельные сети public и cluster.
2. Добавьте узел: ceph orch host add node4 10.0.10.24.
3. Убедитесь, что узел в списке: ceph orch host ls, затем разверните на нём OSD.
4. Проверьте распределение: ceph osd tree, ceph -s, ceph health detail.

Сетевые требования к расширению: public-сеть обслуживает клиентов и мониторы, cluster-сеть несёт репликацию и backfill. Для дисковых узлов 25 Гбит/с или 2x10 Гбит/с с LACP - рабочий минимум, иначе добавление даже одного узла перегрузит сеть. MTU 9000 снижает накладные расходы на репликацию.

Ребалансировку ограничивают параметрами osd_max_backfills (по умолчанию 1) и osd_recovery_max_active (по умолчанию 3). Не добавляйте десять OSD за раз: backfill пойдёт по всем сразу и положит отзывчивость кластера. На время пиковой нагрузки процесс останавливают флагами ceph osd set norebalance и norecover, а затем снимают их ночью.

Миграция данных и обновление конфигурации

Использование ZFS send/recv для миграции

1. Создайте снапшот: zfs snapshot tank/data@migrate-2026-09-11.
2. Передайте его на новый пул: zfs send tank/data@migrate-2026-09-11 | zfs recv newpool/data. Для шифрованных датасетов добавьте -w, чтобы передать поток в исходном виде.
3. Для повторных проходов используйте инкремент: zfs send -i tank/data@prev tank/data@current | zfs recv newpool/data. Разница между снапшотами переносится за минуты, даже если датасет занимает терабайты.
4. Проверьте целостность и переключите клиентов на новый пул.

Снапшот фиксирует состояние файловой системы, но не состояние приложения: база данных может содержать незавершённые транзакции. Для СУБД делайте логический дамп или останавливайте запись на время снапшота. Подробные сценарии переноса пулов и обновления железа без простоя разобраны в руководстве по миграции данных в TrueNAS и ZFS.

Для файловых хранилищ без ZFS подходит rsync -aHAX --numeric-ids --delete, для блочных устройств dd или pv с контролем скорости. Конфигурацию правят в трёх местах: /etc/fstab (монтирование по UUID, а не по /dev/sdX), /etc/multipath.conf (новые wwid полок) и ceph.conf (сети и параметры OSD). ZFS и mdadm обновляют свою конфигурацию сами при добавлении устройств, ручная правка zpool.cache не требуется.

Риски и чек-лист перед масштабированием

Метод расширения выбирают по инфраструктуре и допустимому влиянию на производительность:

Чек-лист, который стоит пройти до нажатия Enter:

1. Свежий бэкап критичных данных и проверенное восстановление. Расширение пула не заменяет резервное копирование.
2. Инвентаризация: модель, serial, прошивка HBA и дисков, свободные слоты и мощность питания полки.
3. SMART всех дисков до начала: smartctl -a /dev/sdX. Растущие Reallocated_Sector_Ct, Current_Pending_Sector и UDMA_CRC_Error_Count означают, что диск нельзя ставить в новый vdev.
4. Запас свободного места под ребалансировку: в Ceph нужно 20-30% свободного объёма, иначе backfill встанет в HEALTH_ERR.
5. Окно работ в часы низкой нагрузки и план отката: какие команды выполнить, если процесс зависнет.
6. Мониторинг на время операции: zpool status, cat /proc/mdstat, ceph -s, iostat -x 5, алерты по задержкам дисков.
7. Проверка на тестовом стенде для необратимых операций, особенно для OCE и reshape RAID6.

Типичные ошибки: добавление vdev-страйпа без чётности, игнорирование backfill в Ceph, работа с дисками по именам /dev/sdX, отсутствие бэкапа перед reshape и попытка расширить RAIDZ добавлением одного диска. Если диски переезжают в другую систему или пул разбирается, сначала пройдите процедуру безопасного удаления пула ZFS и подготовки дисков к повторному использованию: она снимает риск выбрать не то устройство.

Проверка после расширения

Успешное завершение команды ещё не значит, что хранилище здорово. Проверьте четыре группы параметров.

• Ёмкость и состояние: zpool status -v и zpool list -v показывают новые vdev, размер и отсутствие ошибок; mdadm --detail /dev/md0 и cat /proc/mdstat - новый состав и завершённый reshape; ceph -s, ceph osd tree и ceph df - число OSD, распределение и свободное место.
• Целостность: zpool scrub tank запускает проверку контрольных сумм, в Ceph её выполняет ceph osd scrub или deep-scrub по расписанию. Скруб на объёме 30 ТБ идёт десятки часов и заметно снижает производительность, поэтому его ставят в ночное окно.
• Файловая система: df -h и lsblk -f подтверждают, что новый объём виден и смонтирован, а записи в /etc/fstab идут по UUID.
• Производительность: iostat -x 5 и fio для контрольного замера, dmesg -T на предмет ошибок ввода-вывода, алерты мониторинга по задержкам дисков и заполнению пула.

После расширения обновите пороги алертов: прежние значения по свободному месту и задержкам станут ложными на новом объёме. Если физических слотов и бюджета на новые полки больше нет, часть данных переносят в облако: виртуальные диски и объектное хранилище масштабируются без выезда инженера в дата-центр, например на инфраструктуре Timeweb Cloud с серверами, хранилищем и Kubernetes в одном кабинете. Гибридная схема закрывает пиковые объёмы без закупки железа.