Масштабирование СХД: вертикальный и горизонтальный рост в 2026 году

Что такое масштабирование СХД и зачем оно нужно в 2026 году

Масштабирование СХД - это рост ёмкости и производительности системы хранения при сохранении доступности данных. Направлений два. Вертикальное (scale-up) наращивает один массив: диски добавляются в существующий пул, к контроллеру подключаются новые полки расширения. Горизонтальное (scale-out) добавляет в кластер узлы, каждый со своими дисками, процессором и сетевыми портами.

Разница видна на первой цифре. Четыре диска по 20 ТБ в одном raidz1 дают около 60 ТБ полезной ёмкости, один корпус и один контроллер. Те же 60 ТБ в кластере Ceph из трёх узлов требуют трёх серверов, коммутатора 25 GbE и репликации 3x, то есть 180 ТБ сырых дисков. Зато потеря узла такому кластеру не страшна, а единственный контроллер без резервного остаётся точкой отказа.

Три факта 2026 года меняют привычные расчёты. OpenZFS 2.3 научился расширять существующий raidz-набор добавлением одного диска, а не только целого нового vdev. Сети 25 и 100 GbE подешевели, поэтому backfill в распределённых кластерах перестал быть многосуточной операцией на средних объёмах. Контейнеры и CSI-драйверы развязали хранилище и вычислительные узлы: ёмкость теперь наращивают отдельно от приложений.

Практический пример. Стартап начинает с 10 ТБ данных и одного сервера на 4 диска. Через два года данные занимают 100 ТБ: логи, бэкапы, снапшоты виртуальных машин, датасеты для аналитики. Если на старте не заложить свободные слоты, резервный контроллер и план расширения, второй год закончится либо покупкой нового массива с миграцией в выходные, либо переполненным пулом и отказом в записи.

Сценарии и критерии выбора разобраны в руководстве по вертикальному и горизонтальному масштабированию СХД, а типы массивов, уровни RAID и расчёт IOPS с примерами приведены в обзоре систем хранения данных 2026 года.

Вертикальное масштабирование СХД: добавление дисков, полок и расширение пулов

Вертикальный рост сводится к двум вопросам: есть ли свободные слоты в корпусе и сколько дисков выдержит контроллер. Если слоты есть, работа занимает один вечер: вставить диски, расширить массив, дождаться перестройки. Если слотов нет, нужна полка расширения, а вместе с ней проверка питания, охлаждения и совместимости по списку поддерживаемого оборудования.

Онлайн-расширение поддерживают не все схемы. Аппаратные RAID 5 и RAID 6 обычно умеют online capacity expansion: массив растёт без остановки сервисов. RAID 10 чаще приходится пересобирать. В Linux программный RAID расширяется командой «mdadm --grow», в ZFS ёмкость наращивают добавлением vdev или расширением raidz-набора. Общий порядок одинаков: сначала бэкап, потом проверка на стенде, потом продакшн.

Добавление дисков в пул ZFS: пошаговый пример

Сценарий: пул tank из четырёх дисков по 20 ТБ в raidz1 (около 60 ТБ полезной ёмкости), заполненность 70%. Нужно добавить 40-60 ТБ без остановки сервисов.

1. Снять состояние: «zpool status -v», «zpool list -v», «zfs list -o space», «iostat -x 5». Зафиксировать заполненность, средний размер блока, фрагментацию и среднюю задержку записи.
2. Выбрать тип vdev. Для HDD 16-24 ТБ рабочая практика - raidz2 из 6-8 дисков; mirror выбирают под базы данных и виртуальные машины, где важны IOPS. Ёмкость vdev считается по самому младшему диску, поэтому смешивать 18 и 20 ТБ в одном наборе нет смысла.
3. Расширить raidz-набор на один диск (OpenZFS 2.3 и TrueNAS SCALE 25.04+) или добавить новый vdev командой вида «zpool add tank raidz2». Первый путь экономит слоты, второй даёт прирост IOPS.
4. Запустить перестройку и наблюдать за ней: «zpool status» показывает resilver и остаток времени. Диск 20 ТБ при 150 МБ/с перестраивается 30-40 часов, и узким местом будут IOPS, а не пропускная способность.
5. Поднять приоритет resilver («zpool set resilver_priority» через модуль ZFS и параметр zfs_resilver_min_time_ms) и не запускать в это окно тяжёлые бэкапы.
6. Проверить результат: «zpool list», тест записи на 50-100 ГБ, расписание scrub, проверка SMART новых дисков.

Ключевое ограничение: новый vdev не перебалансирует старые данные. ZFS пишет свежие блоки преимущественно в свободное место, поэтому полный прирост скорости вы увидите только после перезаписи данных или пересоздания пула. Удалить raidz-vdev из пула нельзя, «zpool remove» работает с top-level vdev типа mirror или одиночного диска. Сменить уровень RAID (например, перейти с raidz1 на зеркала) можно только пересозданием пула с копированием данных.

Пример по цифрам: пул из 4 x 20 ТБ raidz1 плюс второй vdev из 4 x 20 ТБ raidz1 дают около 120 ТБ полезной ёмкости, но отказоустойчивость остаётся на уровне одного диска на каждый vdev. В TrueNAS SCALE расширение делают через веб-интерфейс: Storage, затем Add Vdev или кнопка Expand для raidz-набора. Пошаговые команды и расчёт объёмов для ZFS, RAID и Ceph собраны в материале о расширении хранилища без простоя.

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

Полка расширения (JBOD) подключается к контроллеру по SAS, iSCSI или Fibre Channel. Для DAS-схем типичен SAS: одна линия 12 Гбит/с даёт около 1,1 ГБ/с, а 24 диска по 20 ТБ в последовательном чтении выдают 4-6 ГБ/с, поэтому нужны минимум четыре линии и два пути (multipath), иначе полка станет узким местом.

• Совместимость: сверьте полку, экспандер и диски со списком поддерживаемого оборудования вендора контроллера. Разные версии прошивок на полках дают отвал линков и деградацию массива.
• Лимиты контроллера: типовое ограничение - 4-8 полок. Четыре полки по 24 диска дают 96 дисков, при 24 ТБ каждый это около 2,3 ПБ сырой ёмкости на один массив.
• Питание и охлаждение: полка 4U на 24 диска потребляет 300-500 Вт и весит под 60 кг с дисками. Проверьте бюджет PDU, поток воздуха и температуру в стойке, HDD деградируют выше 30-35 C.
• Резервирование пути: два контроллера и два SAS-пути с multipath. Один путь и один контроллер превращают любую поломку в простой.
• Прошивка: обновляйте её до подключения полки, а не во время перестройки массива.

Ограничения вертикального масштабирования: когда рост упирается в потолок

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

Аппаратные. В типовом 2U корпусе 12-24 слота, в 4U - до 60-84. Домен SAS-3 адресует сотни устройств, но контроллер упирается раньше: 96-200 дисков. Процессор контроллера при загрузке выше 80% добавляет миллисекунды к каждой операции, кэш 2-8 ГБ переполняется на случайной записи, а без батареи кэша режим write-back отключается и запись падает в разы. Питание тоже считают: 96 HDD по 10 Вт это около 1 кВт только на диски, плюс пик раскрутки.

Программные. Теоретический лимит пула ZFS - 256 ЗиБ, практический потолок ниже и задаётся полосой пропускания контроллера и IOPS накопителей. Один raidz-vdev на мелких случайных операциях работает со скоростью одного диска: добавление диска в этот же vdev увеличит ёмкость, но не IOPS. Заполнение выше 80% снижает скорость записи из-за фрагментации и механики copy-on-write. Перестройка raidz1 или raidz2 на дисках 20-24 ТБ занимает сутки и больше, и всё это время массив работает без запаса по отказоустойчивости.

Экономические. Цена полезного терабайта растёт при каждом шаге. Полка, второй контроллер, кабели, PDU и работы поднимают стоимость ТБ на 20-40% относительно изначальной конфигурации. Смена уровня RAID означает пересоздание пула и копирование десятков терабайт, то есть простой или второй комплект железа.

Признаки, что вертикальный рост закончился:

• свободных слотов нет, а новая полка с контроллером стоит больше 60% от цены нового массива;
• IOPS и p95 latency не меняются после добавления дисков;
• загрузка процессора контроллера держится выше 70-80%, кэш работает без запаса;
• rebuild длится больше суток, и вторую потерю диска массив не переживёт;
• один контроллер, один путь SAS, нет multipath, то есть точка отказа на всю систему;
• прогноз требует удвоения ёмкости за два года.

Как считать экономику двух вариантов, включая TCO и стоимость владения, разобрано в статье про аппаратную и программную СХД.

Горизонтальное масштабирование СХД: распределённые и кластерные решения

Scale-out строится на узлах. Каждый узел приносит диски, процессор и сетевые порты, данные распределяются между узлами, а отказоустойчивость обеспечивают репликация или erasure coding. Ёмкость и производительность растут вместе с числом узлов, но появляется сетевая нагрузка: клиенту достаточно 1-10 Гбит/с, а между узлами ходят десятки гигабит.

Пример с цифрами. Кластер Ceph из трёх узлов по 10 ТБ OSD с репликацией 3x даёт около 10 ТБ полезной ёмкости и переживает отказ одного узла. Четвёртый узел поднимает сырой объём до 40 ТБ и полезный примерно до 13 ТБ, а вместе с ёмкостью растут IOPS и пропускная способность. Альтернатива репликации - erasure coding 8+4: накладные расходы 1,5x вместо 3x и устойчивость к отказу четырёх фрагментов.

Требования к сети: 10 GbE как минимум, 25 GbE для комфортной работы, 100 GbE под NVMe. Backfill после добавления узла грузит и сеть, и диски, поэтому на время ребаланса ограничивают параллелизм восстановления. Эксплуатация сложнее, чем у одного массива: обновления, мониторинг, карта размещения данных, обучение команды.

Ceph, GlusterFS, MinIO: сравнение для практиков

Выбор проще делать по протоколу. Нужны S3 и объектные бакеты - MinIO. Нужен блочный доступ под виртуальные машины - Ceph RBD. Нужны общие файлы с большим числом клиентов - CephFS. Нужны SMB-шары для отдела - TrueNAS SCALE. Для Kubernetes все три первых варианта доступны через CSI-драйверы, и большинство команд выбирает ceph-csi для блоков и MinIO для объектных бакетов.

Кластерные СХД от вендоров: плюсы и минусы

Проприетарные кластерные массивы решают ту же задачу другим способом: узлы объединяются в кластер, а репликация, снапшоты и поддержка приходят вместе с железом. Dell PowerStore объединяет до четырёх устройств в кластер и даёт блочный и файловый доступ с NVMe. NetApp ONTAP в одной конфигурации собирает до 24 узлов, поддерживает SnapMirror и выгрузку холодных данных в объектное хранилище. Dell PowerScale рассчитан на сотни узлов и петабайты, HPE Alletra ориентирован на предсказуемую задержку под критичные базы данных.

Плюсы: поддержка 24/7 и SLA, интеграция с vSphere через VAAI, готовые снапшоты, репликация и шифрование, ёмкость и задержки ведут себя предсказуемо. Минусы: цена терабайта в 2-5 раз выше, чем у конфигурации на open source, лицензии на отдельные функции, вендор-лок и шаг масштабирования целым узлом.

Ориентир по выбору: SLA 99,99% и команда из двух-трёх человек, которые не готовы сопровождать Ceph, - берут вендорское решение. Есть инженеры с опытом Ceph и объём от 100 ТБ - open source даст ту же отказоустойчивость при меньшей цене за полезный ТБ, но ответственность за эксплуатацию останется на вас.

Как спланировать рост ёмкости и производительности без простоя

Планирование начинается со сбора метрик, а не с выбора железа. Нужны заполненность пулов за 30 дней, пиковые IOPS и p95 latency в 10-минутных окнах, темп роста данных по типам (логи, бэкапы, снапшоты, VM), а также износ SSD по TBW.

Расчёт запаса ёмкости и производительности

Формула: требуемая ёмкость = текущая ёмкость x (1 + темп роста) в степени числа лет x коэффициент запаса.

Пример расчёта. Данных 50 ТБ, рост 30% в год, горизонт три года: 50 x 1,3 x 1,3 x 1,3 = 110 ТБ полезных данных. Запас 25% под пики и снапшоты даёт 137 ТБ. Оверхед raidz2 на восьми дисках равен 1,33, значит нужно 183 ТБ, а правило 80% заполнения ZFS поднимает требование до 229 ТБ сырой ёмкости, то есть до 12 дисков по 20 ТБ. При росте 40% в год за три года требуется уже в 2,7 раза больше ёмкости, чем сейчас.

Производительность считают по пикам, а не по средним. Запас 30-40% по IOPS, ориентиры задержки: 1-5 мс для NVMe и 10-20 мс для HDD на случайных операциях. Для баз данных и etcd задержка важнее объёма: хранилище под них не стоит строить на одном raidz-vdev. Алерты ставят на 80% заполнения, на рост p95 latency, на SMART и на остаток ресурса SSD.

В расчёт TCO входят диски, полки, контроллеры, коммутаторы, электроэнергия в кВт·ч, охлаждение, лицензии, окна обслуживания и время инженера. Жизненный цикл HDD - около 5 лет, SSD - 3-5 лет, поэтому холодный резерв на складе закладывают заранее. Часть холодных копий дешевле держать вне своей стойки: например, Timeweb Cloud даёт S3-совместимое объектное хранилище и диски, объём которых меняется без замены железа, что удобно для бэкапов и архивов.

Минимизация простоя при масштабировании

Онлайн выполняются: добавление vdev и расширение raidz-набора в ZFS, online capacity expansion аппаратных RAID 5 и 6, подключение полки по SAS с горячей заменой, добавление узла или OSD в кластер Ceph. Простоя требуют смена уровня RAID, пересоздание пула, переезд с raidz на зеркала, замена или обновление прошивки контроллера.

Порядок работ, который снижает риск:

1. Сделать бэкап и проверить восстановление: снапшот плюс реплика на второй массив, тестовое восстановление одного файла или базы.
2. Повторить операцию на стенде с теми же версиями прошивок и файловой системы.
3. Зарезервировать окно обслуживания даже для онлайн-работ: перестройка снижает производительность.
4. Ограничить фоновые задачи: в Ceph выставить лимиты backfill и recovery, на время работ включить noscrub и nodeep-scrub; в ZFS поднять приоритет resilver.
5. После расширения 24-48 часов наблюдать за задержками, ошибками чтения и состоянием SMART, затем запустить scrub.
6. Зафиксировать новую конфигурацию в документации: топология vdev, схема путей, версии прошивок.

При росте массивов данных отдельный пласт работы - миграция: как переносить десятки терабайт и не потерять целостность, разобрано в руководстве по хранению и миграции больших данных.

Типичные ошибки и риски при масштабировании СХД

• SMR-диски в ZFS. Черепичная запись даёт многократное усиление записи, resilver растягивается на недели или падает. Проверяйте CMR перед покупкой, отдельно для дисков 2-8 ТБ.
• Смешивание моделей и размеров в одном vdev. Ёмкость считается по младшему диску, скорость по худшему, а очереди растут.
• Работы без бэкапа. Добавление vdev копию данных не создаёт, а во время resilver массив работает без запаса по отказоустойчивости.
• RAIDZ1 на дисках 16-24 ТБ. Перестройка занимает 20-40 часов, вторая ошибка за это время означает потерю пула целиком. Для таких дисков разумный минимум - raidz2.
• Питание и охлаждение без запаса. Просадка при раскрутке дисков и температура выше 30-35 C вызывают ошибки чтения и отвалы дисков.
• Прошивки и совместимость. Полки, экспандеры и диски вне списка поддерживаемого оборудования дают нестабильные линки и деградацию массива.
• Один путь и один контроллер. Без multipath и второго контроллера любая поломка приводит к простою.
• Заполнение выше 80-90%. ZFS теряет скорость записи из-за фрагментации и механики copy-on-write.
• Мониторинг после работ. Без алертов на SMART, расписания scrub и контроля задержек первая ошибка обнаружится по жалобе пользователя.
• Ожидание линейного роста IOPS от добавления диска в raidz. IOPS растут с числом vdev, а не с числом дисков внутри одного набора.
• Экономия на накопителях под виртуализацию. SATA 7200 об/мин на десятках виртуальных машин даёт очереди и задержки выше 20 мс.
• Перестройка в часы пик. Resilver и backfill конкурируют с рабочей нагрузкой и приводят к нарушению SLA.

Влияние масштабирования СХД на виртуализацию и Kubernetes

vSphere: том VMFS6 ограничен 64 ТБ, расширяют его онлайн добавлением extent или ростом LUN на массиве; уменьшить datastore нельзя. После расширения полезно выполнить UNMAP, чтобы освободить неиспользуемые блоки. NFS-хранилища растут на стороне массива, гипервизор видит новую ёмкость сразу. В Proxmox пул LVM-thin, ZFS или Ceph RBD расширяют на стороне хранилища, после чего увеличивают диски виртуальных машин.

Kubernetes: рост хранилища виден через CSI-драйвер. Чтобы Persistent Volume Claim можно было расширить, в StorageClass нужен параметр allowVolumeExpansion со значением true, а драйвер должен поддерживать resize (ceph-csi, longhorn и большинство современных реализаций это умеют). Уменьшение тома не поддерживается ни одним драйвером, планировать ёмкость нужно с запасом. После добавления OSD в Ceph дождитесь ребаланса CRUSH и проверьте, что новые PV создаются на новых дисках.

MinIO расширяют добавлением нового пула дисков и перезапуском развёртывания; старые объекты остаются на месте, а новые распределяются по всем пулам. Для баз данных и etcd проверяйте задержку хранилища после каждого расширения: именно fsync и p99 latency определяют, выдержит ли приложение новый профиль нагрузки.

Итог: как выбрать стратегию масштабирования СХД

Ориентиры по выбору выглядят так. До 100 ТБ, есть свободные слоты, загрузка контроллера ниже 60%, сервис допускает окно обслуживания - вертикальный рост дешевле и быстрее. От 100 ТБ, нужен линейный рост IOPS и SLA 99,9% и выше - переходите на горизонтальную схему: Ceph под блоки и файлы, MinIO под объекты, вендорский кластер при требовании поддержки 24/7. Файловый сервер на 20-50 человек закрывает TrueNAS SCALE с вертикальным расширением.

Чек-лист перед решением:

1. Соберите метрики за 30 дней: заполненность, пиковые IOPS, p95 latency, темп роста данных.
2. Посчитайте прогноз на три года с запасом 25-30% и переведите его в сырую ёмкость с учётом оверхеда RAID.
3. Проверьте три признака потолка: нет слотов, процессор контроллера выше 70%, rebuild дольше суток.
4. Сравните TCO двух сценариев, включая питание, охлаждение, лицензии, обучение и стоимость простоя.
5. Протестируйте расширение на стенде, сделайте бэкап и зарезервируйте окно работ.
6. Настройте алерты на 80% заполнения, на задержку и на SMART до, а не после расширения.

В 2026 году распределённые и кластерные схемы дешевеют вместе с сетью 25-100 GbE, а расширение raidz в OpenZFS продлило жизнь вертикальному пути. Практический шаг сегодня: снять метрики за месяц и посчитать, при каком объёме ваш массив упрётся в контроллер. Если до этой точки меньше двух лет, планировать переход на scale-out нужно уже сейчас, полное сравнение подходов с чек-листом остаётся в руководстве по масштабированию СХД.