В 2024 году открытые закупки S3-проектов оценивали в 310,2 млн рублей, в 2025-м — уже в 1,91 млрд. Рост в 6,16 раза выглядит как сигнал переносить данные в собственный кластер. Но рынок не знает твоего объёма, окна резервного копирования и стоимости эксплуатации.
Если компания хранит 300 ТБ резервных копий, локальный S3 уже пора считать. Не покупать — считать наравне с облаком. По проектному опыту К2Тех, примерно с этого объёма совокупные расходы на облачный сервис и свою инфраструктуру начинают сближаться. Ниже — расчёт ёмкости и базовая спецификация, с которой можно идти к поставщику.
Рост закупок показывает спрос, но не экономию
За последние три года локальные объектные хранилища выделились в самостоятельный сегмент. К2Тех связывает это с ростом числа российских продуктов и оценивает дальнейшее увеличение рынка более чем в 20% ежегодно. Открытые закупки при этом покрывают около 40% проектов, поэтому тендерная статистика показывает лишь часть спроса (данные К2Тех в публикации CIO).
S3 здесь — способ обращаться с файлами как с объектами через программный интерфейс. В такое хранилище складывают резервные копии, корпоративные файлы и данные внутренних сервисов. Например, производитель напитков перенёс 300 ТБ бэкапов из зарубежного облака в S3-хранилище «Софтлайн Облако».
После переноса расходы компании снизились на 30%, но этот результат нельзя переносить в чужой бюджет. Он зависел от прежнего тарифа, новой схемы оплаты и конкретного набора данных. Сама миграция заняла несколько месяцев (обзор российского рынка S3 от CNews).
Рост рынка отвечает на вопрос, покупают ли такие системы. На вопрос «нужна ли она тебе» отвечают четыре параметра: объём, темп роста данных, окно копирования и допустимое время восстановления.
При 300 ТБ нужно запросить два расчёта
Локальный кластер попадает в короткий список, если объём достиг 300 ТБ, растёт предсказуемо, а данные должны оставаться внутри инфраструктуры компании. У тебя появляется постоянная нагрузка, под которую можно посчитать оборудование на несколько лет.
Облако проще, если объём заметно меньше 300 ТБ или меняется скачками. Оно также снимает обслуживание физических узлов: не нужно держать запасные диски, обновлять платформу и восстанавливать кластер после отказа. Платой остаются тариф, пропускная способность канала и срок вывода сотен терабайт к другому поставщику.
Поэтому сравнивай не цену дисков с месячным счётом, а расходы за одинаковый срок. В локальный вариант входят серверы, сеть, стойка, питание, поддержка и работа администраторов. В облачный — хранение, передача данных, операции и миграция. Подход к такому сравнению уже разобран в материале о границе между облачной инфраструктурой и своим оборудованием.
Для 300 ТБ данных потребуется не 300 ТБ дисков
Посчитаем холодное хранилище резервных копий с эразир-кодированием 3+2. Такая схема делит данные на три части и добавляет две части для восстановления. Её использует холодный класс S3 в «Софтлайн Облако».
На каждые 3 ТБ полезных данных приходится 5 ТБ сырой ёмкости:
300 × 5 / 3 = 500 ТБ
К этому объёму добавляются метаданные — служебные сведения об объектах и их размещении. Руководство администратора «Кибер Хранилища» отводит под них 0,5–1% объёма данных и ещё 0,5% под резервные копии метаданных. При большом количестве объектов меньше 100 КБ расход может оказаться выше (требования «Кибер Хранилища» к объектному хранилищу).
Для верхней границы берём 1,5%:
300 × 1,5% × 5 / 3 = 7,5 ТБ
Стартовый расчёт даёт 507,5 ТБ сырой ёмкости. Если данные растут на 20% в год, к концу первого года потребуется:
507,5 × 1,2 = 609 ТБ
Это проектная нижняя граница на год, а не готовая корзина дисков. В неё не входит резерв на замену накопителей, замедление восстановления заполненного кластера и рост сверх принятого допущения.
Спецификация под задачу: кластер для 300 ТБ бэкапов
Считаем конфигурацию для 300 ТБ полезных данных, роста на 20% за год и суточного окна полного копирования. Объекты крупные: архивы и цепочки резервных копий, а не миллионы файлов по несколько килобайт.
«Кибер Хранилище» требует устанавливать объектное хранилище на физические серверы. Для пятиузлового кластера с высокой доступностью сервера управления производитель рекомендует по 16 процессорных ядер и 48 ГБ оперативной памяти на каждый узел.
Базовая конфигурация выглядит так:
| Компонент | Конфигурация | Почему столько |
|---|---|---|
| Узлы | 5 физических серверов | Соответствует пятиузловой схеме из требований «Кибер Хранилища» |
| Процессор | 16 ядер на узел | Рекомендованная конфигурация производителя для всех пяти серверов |
| Память | 48 ГБ ECC RDIMM на узел | Рекомендованный объём с учётом резервирования ресурсов при отказе |
| Диски данных | 8 HDD по 16 ТБ на узел | 40 дисков дают 640 ТБ сырой ёмкости: на 31 ТБ больше расчётных 609 ТБ |
| Системные диски | 2 SSD в RAID1 на узел | Система и журналы не делят ресурс с массивом объектов |
| Сеть | 2 порта 25 Гбит/с на узел | При 300 ТБ за 24 часа средний входящий поток равен 27,8 Гбит/с на кластер; два порта оставляют отдельный путь при отказе |
| Питание | 2 блока питания с горячей заменой | Отказ одного блока не выключает узел |
| Корпус | 2U, не менее 12 отсеков LFF | Восемь дисков работают сразу, четыре отсека остаются под расширение |
Сетевой расчёт начинается с принятого окна:
300 ТБ × 8 / 86 400 секунд = 27,8 Гбит/с
Это средняя скорость на весь кластер без учёта повторных передач, параллельного восстановления и служебного обмена. Поэтому 10 Гбит/с на узел хватит по арифметике, но оставит меньше пространства для восстановления после отказа. Пара 25-гигабитных портов — исходная конфигурация для испытания, а не обещание фактической скорости.
Восемь дисков по 16 ТБ дают каждому узлу 128 ТБ, всему кластеру — 640 ТБ. Запас к расчётным 609 ТБ составляет около 5%. Для второго года этого мало: при том же росте потребуется уже 730,8 ТБ. Если кластер должен работать без расширения два года, ставь по десять дисков на узел — 800 ТБ сырой ёмкости.
У такой конфигурации есть цена. Пять физических серверов занимают 10U, требуют десять блоков питания и сорок дисков уже на старте. Зато ёмкость распределена между узлами, а размещение данных остаётся под контролем компании.
Поставщик должен подтвердить скорость и отказоустойчивость
Название протокола S3 ничего не говорит о том, уложится ли копирование в 24 часа. Это покажет тест на твоём размере объектов, числе параллельных потоков и программе резервного копирования.
В запросе поставщику зафиксируй четыре результата:
- скорость записи полного и добавочного бэкапа;
- время чтения при тестовом восстановлении;
- поведение кластера при отключении одного узла;
- время возврата к нормальному состоянию после замены диска или сервера.
Для каждого результата нужны версия хранилища, версия программы резервного копирования и статус связки. Матрица MountStor, например, различает варианты «протестировано», «поддерживается при указанных условиях», «проектная проверка» и «не рекомендуется». Для бэкапов она фиксирует протокол, пропускную способность, дедупликацию, срок хранения и окно копирования (матрица совместимости MountStor).
Если предложение содержит только терабайты и цену, сравнивать его с облаком рано. Порядок испытаний и метрики для приёмки можно взять из разбора о том, как проверить СХД под своей нагрузкой.
Что включить в закупку
При 300 ТБ резервных копий запрашивай два предложения на одинаковый срок: облачный S3 и локальный пятиузловой кластер. Для схемы 3+2 локальному варианту нужно около 507,5 ТБ сырой ёмкости сейчас и 609 ТБ к концу первого года при росте данных на 20%.
Стартовая корзина — пять серверов по 16 ядер и 48 ГБ ECC, восемь HDD по 16 ТБ на узел, два системных SSD, пара портов 25 Гбит/с и резервные блоки питания. Если расширение в течение двух лет нежелательно, увеличивай корзину до десяти HDD на узел.
В коммерческом предложении должны стоять рядом пять величин: полезная и сырая ёмкость, схема избыточности, окно копирования, срок восстановления и время перестроения после отказа. Без них перед тобой цена оборудования, а не расчёт хранилища.
