На закупочном комитете звучит аргумент: «60% российских компаний выбирают отечественные СХД». Цифра выглядит убедительно, но подтвердить её нечем. Директор попросит ссылку, закупщик — основание для ТЗ, а инженер — результаты под своей нагрузкой. Тезис рассыплется на первом уточнении.

Проверяемые данные скромнее и полезнее. По оценке CNews, российский рынок СХД вырос с 50 млрд рублей в 2024 году до ожидаемых 54 млрд в 2025-м. Спрос на отечественные системы начального и среднего уровня в 2025–2026 годах может прибавлять 30–40% в год. Но рост рынка не доказывает, что конкретная система выдержит утренний пик 1С, запуск сотни виртуальных машин или ночное копирование 40 ТБ.

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

Проверяй модель в реестре, а не страну бренда

Российский бренд, локальная сборка и отечественное ПО не подтверждают производство по постановлению Правительства РФ № 719 от 17 июля 2015 года. Реестровый статус получает идентифицированное изделие, модификация или серия — не весь каталог производителя.

Перед закупкой сверяй изготовителя и точное обозначение модели с актуальной записью. Сертификат СТ-1, акт экспертизы ТПП и запись в реестре российского ПО её не заменяют. Такое разграничение следует из требований ПП № 719 и порядка включения оборудования в реестр.

Эта проверка закрывает формальную часть закупки. Производительность она не подтверждает: две модели из одного реестра могут различаться по контроллерам, дискам, сети и схеме защиты данных.

Архитектуру задаёт профиль ввода-вывода

Для СУБД и виртуальных машин нужен блочный доступ. Типовая нагрузка базы — случайные операции блоками 4–32 КБ с соотношением чтения и записи 70/30; базы часто размещают на SSD. Эти ориентиры приводит перформанс-инженер Сергей Качкин в материале YADRO о тестировании блочных СХД.

Значит, под 1С, PostgreSQL, MS SQL или кластер виртуализации нужно сравнивать all-flash-системы по IOPS и задержке p99. Средняя задержка скрывает редкие медленные операции, а именно они растягивают проведение документа или запуск виртуальной машины.

Для файловых каталогов и резервных копий важнее последовательное чтение и запись. Здесь NAS на HDD может оказаться рациональнее all-flash-массива: он даст нужное окно копирования без переплаты за случайные 4K-операции.

Для медиатеки, архива и приложений, которые работают через S3, подходит объектная архитектура. Она наращивает ёмкость узлами и обрабатывает запросы параллельно. Подробное сравнение архитектур есть в материале про виды СХД и их применение.

Рекламные IOPS без профиля теста бесполезны

Цифра «200 тысяч IOPS» ничего не говорит без размера блока, доли чтения, глубины очереди, числа клиентов и схемы защиты данных. Даже результат с полным описанием стенда нельзя переносить на другую модель как обещание.

В опубликованных тестах MountStor кластер из трёх узлов STOR-2U-24SSD показал 126 400 IOPS при профиле Ceph RBD, 4K random, чтение и запись 70/30. Задержка p99 составила 14,6 мс. На профиле виртуальных машин 8K 80/20 тот же класс стенда выдал 108 900 IOPS.

Для последовательной нагрузки HDD-система STOR-4U-60HDD показала 8,7 GiB/s на чтении и 5,3 GiB/s на записи. Объектный CLUSTOR-44U-384HDD достиг 24,6 GiB/s на GET и 13,2 GiB/s на PUT. Условия и профили опубликованы в методике испытаний MountStor.

Это ориентиры для ТЗ, а не рейтинг моделей. Сергей Качкин отдельно предупреждает: синтетический тест плохо воспроизводит рабочую нагрузку. Результат меняют Replica, erasure coding, RAIDZ, выбранный failure domain и фоновые операции восстановления.

Поэтому в приёмочной программе нужен не только прогон на исправном кластере. Повтори его после отказа диска, узла и сетевого подключения, а затем во время rebuild. СХД покупают для работы с отказами, а не для рекорда на пустом стенде.

Спецификация под задачу: объектное хранилище на 1 ПБ

Возьмём компанию, которой сейчас нужен 1 ПБ полезной ёмкости под S3. Данные растут на 30% в год, оборудование покупают на три года. Это расчётный сценарий: темп близок к прогнозу CNews по росту спроса на отечественные СХД, но не описывает каждую компанию.

Через три года потребуется:

1 ПБ × 1,3³ = 2,197 ПБ

Округляем до 2,2 ПБ полезной ёмкости. Допустим, защита данных, служебные области и резерв свободного места добавят 50% к полезному объёму:

2,2 ПБ × 1,5 = 3,3 ПБ raw

Коэффициент 1,5 нельзя автоматически переносить в договор. Поставщик должен пересчитать его под выбранную схему Replica или EC, число отказоустойчивых зон и допустимый уровень заполнения.

Спецификация для этого сценария выглядит так:

Распределённое S3-хранилище минимум из трёх узлов. Точное число узлов определяет схема защиты и требуемый failure domain.
Не менее 2,2 ПБ полезной и 3,3 ПБ сырой ёмкости по принятому допущению.
Масштабирование дисками или модулями расширения без замены всей системы. Такой способ наращивания поддерживают отечественные СХД, опрошенные CNews.
Два независимых сетевых подключения на каждый узел. Скорость портов рассчитывает поставщик под требуемые GET и PUT, а затем подтверждает на стенде.
Два блока питания на узел с раздельным подключением.
ECC RDIMM, процессоры, HBA и сетевые адаптеры — строго в конфигурации, на которой пройдёт приёмочный тест. Задавать объём памяти и модель CPU без данных о SDS, EC и числе потоков было бы выдумкой.
На полном кластере — не ниже 24,6 GiB/s для GET и 13,2 GiB/s для PUT как стартовый ориентир. Если рабочее окно требует записать 300 ТБ за восемь часов, порог нужно считать от задачи: 300 ТБ ÷ 28 800 секунд ≈ 10,4 ГБ/с полезного потока, плюс запас на протокол и фоновые операции.
Тот же профиль нагрузки — при отказе диска, узла и сетевого линка, а также во время восстановления данных.
В протоколе испытаний — модель платформы, CPU, RAM, диски, версии прошивок, HBA/NIC, топология сети, число клиентов и версия SDS. Такой состав стенда фиксирует методика MountStor.

Эта конфигурация дороже системы, рассчитанной ровно на сегодняшний 1 ПБ. Зато рост не вынудит покупать новые узлы через год. Если бюджет сократить за счёт запаса, в финансовую модель нужно сразу заложить следующее расширение.

При другом росте меняется ёмкость, а не принцип расчёта

Формула для пересчёта:

текущий объём × (1 + годовой рост)^число лет × коэффициент защиты

При росте 15% в год и том же коэффициенте 1,5 потребуется:

1 × 1,15³ × 1,5 = 2,28 ПБ raw

При росте 40%:

1 × 1,4³ × 1,5 = 4,12 ПБ raw

Разница между сценариями — 1,84 ПБ сырой ёмкости. Поэтому прогноз роста нужно закрепить в обосновании закупки, а не прятать внутри таблицы поставщика.

Если основная нагрузка — СУБД и виртуальные машины, эту спецификацию использовать нельзя. Переноси закупку в класс блочных all-flash-СХД, задавай профиль 4K 70/30 или 8K 80/20 и фиксируй предел p99.

Для крупных файлов и резервных копий проверяй последовательные чтение и запись, а также длительность полного окна копирования. Высокие 4K IOPS здесь не окупят лишние SSD.

Что включить в ТЗ и приёмочную программу

Перед отправкой запроса поставщику проверь семь строк:

точная модель и модификация есть в актуальной записи реестра;
полезная и сырая ёмкость рассчитаны на названный срок и темп роста;
указаны Replica или EC, число допустимых отказов и failure domain;
заданы GET/PUT либо IOPS, профиль чтения и записи, размер блока и предел p99;
тест повторяется при отказе и во время rebuild;
конфигурация стенда раскрыта до версий прошивок, сети и SDS;
в предложении видно, сколько свободных отсеков, слотов памяти и сетевых портов останется после запуска.

«Российская» отвечает на вопрос о происхождении конкретной модели. Архитектура — о пригодности под данные. Приёмочный тест — о скорости после отказа. Убери один пункт, и перед директором останется не обоснование, а обещание поставщика.

Характеристики отдельной отечественной линейки можно посмотреть в разборе СХД ТАТЛИН. Используй их только для сравнения: результаты одной модели не доказывают возможности другой.