«60% компаний выбирают отечественные СХД» — удобная цифра для презентации директору. Но без выборки, методики и первоисточника она ничего не доказывает. В закупочное обоснование её лучше не включать.
Проверяемые данные выглядят иначе. По обзору TAdviser, семь российских поставщиков СХД собственной разработки получили в 2024 году 42,56 млрд рублей выручки. У семи поставщиков сторонних решений — 9,37 млрд. Это подтверждает наличие рынка и доступных продуктов, но не отвечает на главный вопрос: какую систему брать под твои виртуальные машины, базы и резервные копии.
Разберём типовую компанию со 100 сотрудниками. У неё 18 виртуальных машин, две рабочие базы и 200 ТБ резервных копий. Задача — выбрать российское оборудование и принести директору спецификацию, в которой каждая строка привязана к нагрузке.
Продажи российских СХД выросли, но архитектуру определяет нагрузка
Российский рынок СХД достиг 50 млрд рублей в 2024 году. CNews оценивал объём 2025 года в 54 млрд — рост на 8%. Сами участники рынка давали прогнозы от 5 до 25%, поэтому планировать закупку по одной оценке роста нельзя. Цены, сроки поставки и доступность конкретной модели меняются не вслед за общей диаграммой рынка.
Переход к российским системам двигают не только предпочтения покупателей. CNews отмечает сокращение параллельного импорта и рост числа местных производителей. Для объектов критической информационной инфраструктуры требования технологической независимости задают постановление правительства № 1912 и указ президента № 166. Эти факторы собраны в обзоре российского рынка СХД TAdviser.
Если компания не относится к КИИ, происхождение оборудования остаётся вопросом поставок, совместимости и сервиса. Российский шильдик сам по себе не делает систему подходящей под PostgreSQL, 1С, VMware, zVirt или файловый архив.
Сначала выбирают класс хранения. Потом — производителя и модель.
Рабочие базы и резервные копии требуют разных систем
Виртуальным машинам и рабочим базам нужна предсказуемая задержка при чтении и записи. Для них в расчётной архитектуре используем двухконтроллерную блочную All-Flash СХД. Она обслуживает активные данные и снапшоты, а два контроллера и независимые пути доступа убирают одиночную точку отказа внутри системы.
Резервные копии и файловый архив растут иначе. Здесь важнее полезная ёмкость, схема защиты данных и возможность добавлять узлы или диски. Эту нагрузку отправляем в объектное хранилище.
Получаются две закупочные позиции:
- блочная All-Flash СХД под виртуальные машины и базы;
- объектный кластер под 200 ТБ резервных копий и архива.
Пытаться закрыть обе задачи одной системой — плохая экономия. Быстрые SSD уйдут под холодные копии, а рабочая база начнёт конкурировать с резервным заданием за диски и сеть.
Если нужно сверить классы систем перед разговором с поставщиком, смотри разбор видов СХД и их применения. Для этой конфигурации важна граница: активные блоковые данные лежат на All-Flash, растущий архив — в объектном хранилище.
Рынок тоже уходит от универсальных гибридных полок. По обзору CNews, сегмент систем, совмещающих SSD и SAS-диски на 10 000 об/мин, фактически исчез. Схема «немного SSD и быстрые HDD для всего» больше не выглядит отправной точкой закупки.
Российская платформа не отменяет проверку ПО и сервиса
Вклад управляющего ПО в развитие СХД большинство участников обзора TAdviser ставит выше вклада аппаратной части. Для покупателя это означает простое правило: проверяй не только процессоры, накопители и логотип на корпусе.
В тестовую программу перед приёмкой входят поддержка выбранного гипервизора и ОС, снапшоты, репликация, переключение после отказа контроллера и обновление без остановки рабочей нагрузки. Для объектной системы отдельно проверяют совместимость прикладного ПО с её S3-интерфейсом.
Выбор российских платформ уже не сводится к одному поставщику. YADRO выпускает корпоративные СХД. «Аквариус» предлагает All-Flash и гибридные системы, а его сервисная сеть насчитывает более 300 центров. ICL выпускает СХД с интеграцией российских ОС. ATLAS развивает модульные системы и собственное управляющее ПО. Такие характеристики приводит обзор отечественных вендоров Business Unit.
Это не рейтинг. Количество сервисных центров не заменяет SLA для твоего города, а заявленная совместимость не заменяет испытание на твоей версии гипервизора. Если рассматриваешь одну из линеек YADRO, отдельно сверь характеристики СХД ТАТЛИН с матрицей совместимости и условиями поддержки.
Локальная поставка снижает зависимость от параллельного импорта. Зато миграцию всё равно придётся проектировать, тестировать и проводить в согласованное окно. Около 20% участников рынка сообщили TAdviser о сложностях перехода на отечественные решения для объектов КИИ. Смета только на оборудование скрывает эту часть расходов.
Спецификация под задачу
Считаем конфигурацию для 18 виртуальных машин. Две из них обслуживают базы по 200 ГБ. Резервные копии и файловый архив занимают 200 ТБ. Это расчётный пример, а не статистика по компаниям: перед заказом его числа нужно заменить фактическими метриками.
Два узла виртуализации
Процессорную часть считаем от 18 ВМ по 4 vCPU:
18 × 4 = 72 vCPU
При переподписке 3:1 нагрузке нужны 24 физических ядра. Добавляем восемь ядер под гипервизор, фоновые операции и пики — получаем 32 ядра на кластер. Берём два узла по 16 физических ядер каждый.
Такое деление сохраняет вычислительную ёмкость при обслуживании одного узла, но не гарантирует работу всех ВМ после его отказа на полной скорости. Если кластер обязан пережить потерю узла без снижения производительности, каждый сервер нужно считать от нагрузки, которая останется на нём после переключения.
Память считаем отдельно:
18 × 8 ГБ = 144 ГБ
К ним добавляем 64 ГБ для двух ВМ с базами и 48 ГБ под гипервизоры и резерв. Получается 256 ГБ ECC RDIMM на кластер — по 128 ГБ на узел.
Итог по узлам:
- два стоечных сервера 2U;
- по одному процессору на 16 физических ядер в каждом;
- по 128 ГБ ECC RDIMM с незанятыми слотами;
- два независимых сетевых подключения к рабочей СХД;
- резервированные блоки питания;
- локальные загрузочные накопители с зеркальной защитой.
Частоту процессора и скорость сетевых интерфейсов нельзя честно назначить по числу ВМ. Для них нужны замеры рабочей нагрузки: профиль CPU, задержка хранилища и пиковый трафик. Поставщик должен подобрать конкретные значения по этим метрикам и подтвердить их испытанием.
All-Flash СХД под активные данные
Под рабочие ВМ, две базы и снапшоты закладываем 8 ТБ полезной ёмкости. Это допущение с большим запасом относительно двух баз по 200 ГБ: оставшееся место занимают системные диски ВМ, временные данные, снапшоты и рост нагрузки.
В спецификацию входят:
- два контроллера;
- не менее 8 ТБ полезной ёмкости на SSD;
- по два независимых пути доступа от каждого узла;
- репликация;
- свободные отсеки для расширения;
- резервированные блоки питания;
- горячая замена накопителей.
Число SSD нельзя получить из полезной ёмкости без данных конкретного вендора. На результат влияют схема защиты, резерв накопителей, служебная область и заявленный коэффициент полезной ёмкости. Эти параметры нужно взять из спецификации выбранной модели, а затем проверить на тестовом отказе накопителя и контроллера.
Объектный кластер под 200 ТБ копий
Для объекта считаем сырой объём отдельно. Принимаем коэффициент 1,5 на erasure coding, служебные данные и запас:
200 ТБ × 1,5 = 300 ТБ
Если в предложении стоят диски по 20 ТБ, минимальный расчёт даёт 15 дисков. Закладываем 18: получаем 360 ТБ сырой ёмкости и запас, равный вместимости трёх дисков.
И коэффициент 1,5, и ёмкость диска здесь — допущения. Поставщик обязан пересчитать полезный объём для своей схемы erasure coding, числа узлов, служебных данных и политики восстановления. Простого умножения количества дисков на их паспортную ёмкость для приёмки недостаточно.
Корпус выбираем стоечный 4U с горячей заменой дисков, резервированными блоками питания и свободными отсеками. Если архитектура поставщика распределяет диски между несколькими узлами, в спецификации фиксируем минимальное число узлов, при котором система сохраняет данные и доступ после отказа.
Три порога, после которых расчёт меняется
Если число активных баз вырастет с двух до четырёх, пересчитывай All-Flash СХД и нагрузку на серверы. Увеличение объектного кластера здесь не поможет: рабочие базы останутся на блочном хранении.
Если архив вырастет с 200 до 400 ТБ, при прежнем коэффициенте 1,5 понадобится 600 ТБ сырой ёмкости:
400 ТБ × 1,5 = 600 ТБ
При дисках по 20 ТБ это 30 накопителей без дополнительного резерва по вместимости. Значит, уже при первой закупке стоит проверить, можно ли расширить кластер без замены исходных корпусов и лицензий.
Если бизнес должен продолжить работу после отказа площадки, двух контроллеров и резервных блоков питания недостаточно. Понадобятся вторая площадка, репликация и план переключения. Одна стойка защищает от части аппаратных отказов, но не от потери электропитания, затопления или недоступности серверной.
Для смешанной нагрузки не нужно выбирать между российской СХД и объектным хранилищем. Бери блочную All-Flash систему под ВМ и базы, объектный кластер — под копии и архив. Принимай их по разным критериям.
Директору достаточно четырёх строк: рабочая нагрузка, полезная ёмкость, коэффициент защиты данных и условия восстановления. Доля рынка подтверждает, что класс российских решений существует. Конфигурацию она не обосновывает. И цифру про «60% компаний» лучше оставить за дверью переговорной, пока у неё не появятся выборка и методика.
