Что такое vitiscale
Vitiscale — программно-определяемая система хранения данных (SDS) разработки компании datagarden, анонсированная в сентябре 2026 года. Продукт создаётся с 2022 года как полностью собственная разработка: по заявлению вендора, в архитектуре не использованы open-source готовые решения (но не исключает использование open-source библиотек), в отличие от значительной части рынка программных СХД, где ядром часто служит Ceph или аналогичные проекты.
Система внесена в реестр российского программного обеспечения (запись №23346 от 25.07.2024); запись в реестре радиоэлектронной продукции Минпромторга РФ ожидается в 2026 году. Формально продукт позиционируется и как ПО, и как программно-аппаратный комплекс (ПАК) на референсных серверах 2U.
Ключевая идея vitiscale — один распределённый слой данных под всеми протоколами доступа: блочными (NVMe-oF, iSCSI, Fibre Channel) и объектным (S3 API). Вместо того чтобы «пристраивать» объектное хранилище шлюзом поверх блочного ядра, как это реализовано у большинства конкурентов, S3 в vitiscale работает на тех же узлах, тех же дисках и через тот же путь данных, что и блочный доступ.
Архитектура: сетецентричность и симметричные узлы
В основе vitiscale — равноправные узлы кластера (symmetric active-active), отсутствие выделенных узлов метаданных и gateway-узлов, через которые обязан проходить трафик. Каждый узел может напрямую обслуживать запросы клиента к любым данным кластера — минимум архитектурных прослоек означает меньшие задержки и меньше точек отказа.
Кластер строится на двух физически разделённых сетях:
- Front-end сеть — обслуживает клиентские подключения. Поддерживает NVMe/TCP, NVMe/RDMA (RoCEv2 и InfiniBand), NVMe/FC, iSCSI, FC и S3 API, при этом разные протоколы могут работать через одни и те же порты СХД одновременно, без специализированных multipath-драйверов на стороне хоста (используются стандартный Native MultiPath или MultiPathD).
- Back-end сеть — объединяет узлы между собой по схеме full-mesh (минимум 2 порта на узел в двух коммутаторах), недоступна и не видна клиентским хостам. По ней идёт запись, чтение, фоновый ребилд/ребаланс кластера и служебный трафик.
Поскольку все пути к данным активны одновременно, полоса пропускания front-end сети растёт линейно с числом узлов: вендор приводит пример роста совокупной полосы с 2400 до 4000 ГБ/с при увеличении кластера с 3 до 5 узлов (по 2×400 Гбит/с порты на узел).
Размещение и защита данных
Тома состоят из экстентов данных, равномерно распределяемых по всем узлам и дискам кластера. У тома нет владельца: любой том использует производительность всей системы, а не одного контроллера или пары нод. Доступны схемы избыточности:
- Репликация: 2 или 3 копии данных;
- RAID VS (Variable Scheme) — схемы от 2+1 и 2+2 до 8+7 и 8+8, конкретная схема ограничена числом узлов в кластере.
При отказе диска или узла восстановление идёт фоново, за счёт свободного пространства всей системы, без выделенных hot-spare дисков или узлов. Скорость ребилда регулируется — можно выбрать, сколько производительности кластера отдать под восстановление, а сколько оставить сервисам. По заявлению вендора, система выдерживает одновременный отказ до 8 узлов или дисков в зависимости от выбранной схемы защиты.
От silent data corruption vitiscale защищается сквозным контролем целостности T10-PI (Protection Information добавляется к каждому блоку) и фоновым процессом проверки контрольных сумм.
Поведение при отказах
Вендор подчёркивает, что единичный отказ любого компонента — не аварийная ситуация, а штатный режим работы:
| Событие | Обнаружение / реакция | Влияние на производительность | Восстановление |
|---|---|---|---|
| Отказ SSD (один или несколько) | автоматически | ~90–99% от максимума | фоновое, автоматическое |
| Отказ порта / коммутатора | автоматически | ~50–99% | автоматическое переключение путей |
| Сбой сервиса на узле | автоматически | ~80–99% | автоматический перезапуск |
| Отказ узла (не лидер) | автоматически | ~80–99% | автоматическое переподключение |
| Отказ узла-лидера | автоматически | ~80–99% | переизбрание лидера, без остановки I/O |
Протоколы доступа: блок и объект на одном слое
Блочный доступ
Поддерживаются практически все распространённые блочные протоколы, доступные одновременно через одни и те же порты узла:
- NVMe over Fabrics: NVMe/RoCEv2, NVMe/InfiniBand, NVMe/TCP, NVMe/Fibre Channel;
- SCSI-протоколы: iSCSI, Fibre Channel.
Публикация тома отвязана от конкретной сети: кластерный сервис определяет, на каких интерфейсах и портах узлов том становится доступен, по какому протоколу и какому кругу хостов. Все пути активны одновременно — полоса тома складывается из всех путей, что даёт хосту через стандартный MPIO агрегированную пропускную способность нескольких узлов сразу как одно блочное устройство.
Объектный доступ (S3)
Datagarden противопоставляет свой подход типовым SDS: у большинства решений S3 — это шлюз или надстройка (S3-gateway со своей базой метаданных поверх ядра или поверх файловой системы), то есть отдельный слой в пути потока данных. В vitiscale S3-сервер работает на тех же узлах, что и блочные протоколы.
Заявленная совместимость с AWS S3 API:
| Категория | Поддерживаемые операции |
|---|---|
| Bucket | Create / Delete / Head / List, GetBucketLocation |
| Object | PUT / GET / HEAD / DELETE(s) / COPY / LIST |
| Multipart Upload | Create / Upload / Complete / Abort / List Parts / List Uploads |
| Versioning | до 2 000 версий объекта |
| Policy / ACL / Ownership | bucket policies, ACL, Ownership Controls |
| Lifecycle | Get / Put / Delete, устаревание объектов, очистка незавершённых MPU |
| Условные записи | CAS: If-Match / If-None-Match по ETag |
| Тегирование | Object + Bucket, до 10 тегов на объект |
| Уведомления | Bucket notifications о событиях |
Для сценариев сервис-провайдера и мультитенантных компаний один кластер может обслуживать множество изолированных S3-серверов — с изоляцией на выбор: логической (bucket policies в рамках общего сервера), физической (выделенный том данных под тенанта) или сетевой (выделенный публикатор со своими IP/FQDN). Lifecycle и версионирование настраиваются per-bucket, распределение S3-серверов по узлам можно менять на лету без миграции данных. А вот с защитой данных пока вопрос остаётся открытым — её просто нет. Хотя решение и позиционируется в качестве таргета для резервных копий, object lock, который мы недавно рассматривали, пока не поддерживается.
Производительность: заявленные цифры
Все результаты ниже — из тестовых стендов вендора, но дают представление о порядке величин, на которые рассчитан продукт.
Блочный доступ
Стенд: 6 узлов vitiscale (56 ядер, 256 ГБ RAM, 8×NVMe TLC Gen4 на узел), 3 сервера нагрузки, том с политикой RF-3 (3 копии), протокол NVMe/RDMA, коммутаторы Mellanox SN2700.
| Профиль нагрузки | IOPS / полоса | Средняя задержка |
|---|---|---|
| Чтение, 100% случайное 4K | 29,14 млн IOPS · 111 ГиБ/с | 0,084 мс |
| Запись, 100% случайная 4K | 4,72 млн IOPS · 20,7 ГиБ/с | 0,802 мс |
Объектный доступ (S3)
Стенд: 6 узлов, схема RAID VS 4+2, 48 SSD Gen4 (для тестов RPS/задержки) и 144 SSD Gen4 (для тестов полосы).
| Размер объекта | RPS | Задержка, мс | Полоса |
|---|---|---|---|
| 4 КБ (GET) | 292 тыс. | 0,5 | 1,1 ГиБ/с |
| 64 КБ (GET) | 288 тыс. | 1 | 17,2 ГиБ/с |
| 256 КБ (GET) | 182 тыс. | 2,1 | 43,4 ГиБ/с |
| 1 МБ (GET) | 42,9 тыс. | 6,8 | 39,9 ГиБ/с |
| 10 МБ (GET) | — | — | 105 ГиБ/с |
| 4 КБ (PUT) | 142 тыс. | 1,3 | 0,54 ГиБ/с |
| 64 КБ (PUT) | 73 тыс. | 1,4 | 4,3 ГиБ/с |
| 1 МБ (PUT) | 9,5 тыс. | 14,2 | 9,1 ГиБ/с |
| 4 МБ (PUT) | 2,9 тыс. | 48 | 11,3 ГиБ/с |
| 10 МБ (PUT) | — | — | 45 ГиБ/с |
Показательна логика масштабирования: добавление узла в vitiscale линейно увеличивает и IOPS/RPS, и полосу, и полезную ёмкость одновременно, вендором это противопоставляется «устаревшему scale-out», где после определённого числа узлов рост производительности выходит «на плато» из-за появления новых ролей (выделенных gateway- или metadata-узлов), которые нужно масштабировать отдельно.
Технические характеристики и лимиты
| Параметр | Значение |
|---|---|
| Количество узлов | от 3 до 512, шаг масштабирования — 1 узел |
| Ёмкость системы | сотни петабайт |
| Сырая ёмкость на узел | от 30,72 до 720 ТБ |
| Максимальный размер тома | 16 петабайт |
| Максимум томов | 65 535 |
| Объектов в системе / в одном bucket | десятки миллиардов / 1 миллиард (до 10 млрд в системе) |
| Максимальный объект (S3) | 5 ГБ одиночный, до 50 ТБ через Multipart Upload |
| Частей Multipart / размер части | до 10 000 частей, 5 МБ – 5 ГБ каждая |
| Версий объекта | до 2 000 |
| Локальных пользователей | до 10 000 |
| Форм-фактор узла | 2U, 2×CPU (x86), от 128 ГБ RAM |
| Накопители | SAS или NVMe, 8–24 накопителя на узел |
| Сетевые порты (Ethernet) | до 8×25/100 Гбит/с или до 4×400 Гбит/с |
| Порты Fibre Channel | до 2× FC 16 / 32 Гбит/с |
| Файловые системы томов | ext4, xfs |
| Лицензирование | по сырой ёмкости системы, шаг 1 ТБ |
Управление и эксплуатация
Система построена по принципу API-first: ядро управления — REST API, а Web UI и CLI реализованы как клиенты поверх него, то есть одинаковый набор операций доступен и в браузере, и в скриптах автоматизации.
- QoS на уровне тома — лимиты по max IOPS, max МБ/с, отдельно на чтение и запись
- CSI-драйвер для Kubernetes, блочные тома через NVMe/TCP в режиме RWO
- мониторинг — встроенный экспортер метрик узлов, стандартный формат для Prometheus, готовый дашборд Grafana
- обновление и масштабирование кластера без остановки сервисов
- безопасность — TLS/HTTPS с ротацией сертификатов без простоя, контроль доступа — RBAC, для S3 — IAM
Сценарии использования
Базы данных (OLTP, аналитика)
Заявленные цифры на тесте с 6 узлами: задержки около 0,2 мс при нагрузке в миллионы IOPS (NVMe over RDMA), 5,3 млн IOPS на смешанном профиле 8К (48 дисков), свыше 100 ГиБ/с чтения.
Резервное копирование и СРК
Для систем резервного копирования vitiscale позиционируется как тир для быстрого создания и восстановления резервных копий. Заявлена скорость записи бэкапа от 180 ТБ/ч (около 50 ГБ/с на 6 узлах), возможность тюнинга под запись или чтение и способность выдерживать массовое восстановление — множество операций случайного чтения при развёртывании множества машин одновременно (до 29,7 млн IOPS 4K random read в тесте на 6 узлах/48 дисках).
Файловая система для GPU, Lakehouse-аналитика, AI Inference, дообучение моделей
На презентации было очень много сказано по поводу поддержки Lustre, ClickHouse, KV-кэша, RAG, агентов ИИ и всего с этим связанного. Но я пока далёк от этой темы, чтобы как-то качественно рассказать об этом вам сегодня. Суть можно свести к простому — быстрое хранилище позволяет экономить вычислительные ресурсы, помогает увеличить отказоустойчивость вычислений и упрощает масштабирование систем. На мероприятии была видео-съёмка и я очень надеюсь, что выступление Филиппа Комиссарова о применимости vitiscale в этом направлении можно будет где-то посмотреть.
Чего же тут не хватает?
Я уже несколько месяцев хожу по рынку с вопросом — а чем же, собственно, можно заменить Minio сегодня в России? Пока ответа, кроме Tatlin.Object, у меня нет. Поэтому я шёл на данную презентацию в первую очередь с этой идеей. Если внимательно посмотреть на обзор, то можно уловить главную суть продукта — это про скорость и низкие задержки. А что же про классические HDD? Да, они поддерживаются, это решение работает, но это направление не является основным фокусом компании. Как я понял из разговора с Сергеем Мазниченко по окончании презентации — «медленные» диски не очень интересны компании, по крайней мере на сегодняшний день не планируется выпускать и ПАК с HDD. Возможно, в дальнейшем решение можно будет приобрести в качестве ПО для подобных инсталляций, но опять-таки, интерес для компании представляют проекты от 2 Пб. Хотя на мой взгляд, хорошего S3-решения для хранения архивов, резервных копий и прочих «холодных» данных на сегодняшнем российском рынке практически нет, и почему не попытаться занять и эту нишу, я не понимаю. Конечно, тут есть множество нюансов, как и в любом SDS-решении, продающихся как отдельно ПО для раскатывания на серверах заказчиков — поддержка, совместимость и т. д. Возможно, компания пока просто не готова настолько сильно углубляться в поддержку стороннего оборудования и будет концентрировать своё внимание именно на ПАК. Кстати, про ПАКи — они будут на базе отечественных решений, но о собственном производстве серверов речи не идёт, решение будет выпускаться в партнёрстве с кем-то из наших производителей (честно сказать — просто не запомнил, с кем именно).
Почему это делают именно сейчас?
Отдельная презентация datagarden объясняет архитектурные акценты продукта общими тенденциями индустрии хранения данных на фоне роста AI-инфраструктуры:
-
Memory wall. С 1998 по 2026 год вычислительная мощность выросла примерно в 300 000 раз, а пропускная способность памяти — только в 200 раз. Порог, после которого данные вытесняются из памяти на диск, сократился с 5 минут (1987) до 5 секунд (прогноз на 2026), т. е. хранилище всё чаще оказывается на пути «горячих» данных, а не только «холодных».
- Флеш стремится приблизиться к памяти по IOPS. Цель на один GPU — 200 млн IOPS, тогда как типичный SSD поколения Gen4 даёт около 1,2 млн, а лучшие современные SLC-накопители — порядка 10 млн. Разрыв закрывается ростом параллелизма систем хранения, а не только характеристиками одного диска.
-
Сеть перестала быть узким местом. Пропускная способность растёт кратно каждые два года, а доля Ethernet в AI-кластерах, по приводимым оценкам, обгоняет InfiniBand — во многом благодаря протоколам RDMA, которые перестают требовать выделенных lossless-сетей и более низкой стоимости.
- СХД становится новым тиром в иерархии памяти. Между локальным NVMe и классической СХД формируется промежуточный уровень с задержкой менее 1 мс при полосе в сотни ГБ/с — именно в эту нишу vitiscale и планирует попасть.
- Производительность хранилища напрямую конвертируется в экономику. Снижение задержек сети/СХД сопровождается измеримым ростом полезной загрузки CPU и снижением стоимости, поскольку дешевле быстро прочитать данные с СХД, чем пересчитать их заново.
Сравнение с другими российскими SDS-решениями
Ниже — сокращённое сопоставление vitiscale с другими системами хранения данных, представленными на российском рынке: «Кибер Хранилище» (Киберпротект), «Р-Хранилище» (Росплатформа), Mind uStor (MIND Software), TROK SDS (Группа Астра) и Vitastor (открытый проект Виталия Филиппова).
| Параметр | Vitiscale | Кибер Хранилище | Р-Хранилище | Mind uStor | TROK SDS | Vitastor |
|---|---|---|---|---|---|---|
| Год выхода | сент. 2026 | на рынке несколько лет | давно на рынке | май 2025 | осень 2025 | 2019 |
| Реестр российского ПО | да | да | да | да | да | нет |
| Мин. / макс. узлов | 3 / 512 | 3 / не ограничено | не регламентировано | 3 / 24 | 1 / «тысячи» | 1 / не ограничено |
| Блочный доступ | NVMe/TCP, RDMA, FC, iSCSI | iSCSI | iSCSI | iSCSI + проприетарный | iSCSI, NVMe-oF | QEMU, UBLK, NBD (iSCSI/NVMe-oF — roadmap) |
| Объектный доступ (S3) | есть | есть | есть | не заявлен | не заявлен | есть |
| Избыточность | репликация 2/3, RAID VS 2+1…8+8 | erasure coding, репликация | репликация | erasure coding, репликация | репликация | репликация, XOR, Reed-Solomon |
Roadmap
Вендор публично обозначает несколько направлений развития продукта:
- S3 over RDMA — прямой путь от объекта в память GPU, минуя CPU и TCP-стек
- LDAP/AD в IAM — корпоративная аутентификация
- гео-репликация bucket’ов между кластерами — катастрофоустойчивость
- data reduction для СРК — дедупликация и компрессия под задачи резервного копирования
- файловый доступ NFS/SMB — без появления отдельного продукта
Заключение
Vitiscale заходит на рынок программных СХД с заявкой на нишу, которая до недавнего времени была слабо закрыта отечественными решениями: полностью собственная, симметричная scale-out архитектура, одинаково сильная в блочном и объектном доступе, с показателями производительности и задержки, ориентированными не столько на классическое корпоративное хранение, сколько на нагрузки вокруг GPU-инфраструктуры — инференс, дообучение моделей, параллельные файловые системы, аналитику больших данных.