В сентябре 2026 года datagarden выводит Vitiscale на российский рынок. Минимальная конфигурация — три узла. Максимальная — 512 узлов с расширением по одному без остановки сервисов. Такие параметры приводит анонс datagarden, опубликованный CNews и Byte Magazine.
Для проекта 1С цифры ставят практический вопрос: запрашивать испытания Vitiscale или оставить локальные NVMe. Ответ зависит не от заявленных миллионов IOPS, а от устройства вашей инфраструктуры. Одному серверу СУБД отдельный кластер хранения чаще добавит сложность. Ферме СУБД или общей платформе для нескольких систем он может пригодиться.
Опубликованных испытаний Vitiscale с платформой 1С пока нет. В материалах не указаны версия 1С, СУБД, размер базы, число пользователей и профиль операций. Поэтому рекомендовать эту СХД для 1С по одному анонсу рано.
Что datagarden выводит на рынок
Vitiscale — горизонтально масштабируемая СХД собственной разработки datagarden. По данным Byte Magazine и CNews, команда создаёт её с 2022 года.
Кластер построен из равноправных узлов. Каждый узел обслуживает запросы напрямую, без отдельного контроллера метаданных. Netwell, интегратор Vitiscale, называет этот режим symmetric active-active.
Для серверов СУБД предназначен блочный доступ. Vitiscale поддерживает NVMe over Fabrics по TCP, RDMA и Fibre Channel, а также iSCSI и FC. Для объектных данных предусмотрен S3 API.
СХД можно подключить и к Kubernetes. В публичном репозитории datagarden описан CSI-драйвер csi-forca для томов Vitiscale через NVMe/TCP. В документации перечислены Kubernetes 1.28–1.31, файловые системы ext4 и XFS, а также режим Raw Block.
| Заявленная возможность | Что меняется в инфраструктуре | Чего публикации не доказывают |
|---|---|---|
| Кластер от 3 до 512 узлов | Ёмкость наращивается по одному узлу | Что малой установке выгодны три узла вместо локальных дисков |
| Расширение без остановки сервисов | Для добавления узла не требуется плановый простой СХД | Что 1С не заметит перераспределения данных |
| Отказ узла не прерывает обслуживание | Хранилище продолжает принимать запросы при одиночном сбое | Как меняется задержка записи в деградированном режиме |
| QoS для отдельных томов | Нагрузкам можно назначить разные политики обслуживания | Какие настройки нужны серверу СУБД с базой 1С |
| NVMe over Fabrics, iSCSI и FC | СУБД получает блочные тома по выбранной фабрике | Какие сочетания ОС, СУБД и адаптеров прошли проверку |
| S3 API | В одном кластере можно держать объектные данные | Подходит ли S3-контур для конкретной схемы резервирования |
| Prometheus и Grafana | Метрики СХД попадают в общую систему наблюдения | Какие пороги предупреждают о проблемах именно с 1С |
Спецификация описывает устройство СХД. Результат на нагрузке 1С она не подтверждает.
Что может пригодиться серверной 1С
Главный сценарий для 1С — общие блочные тома для нескольких серверов СУБД. Такое хранилище отделяет данные от конкретного сервера: вычислительный узел можно обслуживать или заменять без переноса всей базы на его локальные накопители.
Это преимущество появляется только там, где серверов действительно несколько. Если 1С и СУБД работают на одной машине, локальные NVMe короче по цепочке: нет отдельного кластера хранения, фабрики доступа и ещё одной системы управления.
Vitiscale хранит две или три копии данных, утверждает Netwell. Этот выбор прямо влияет на полезную ёмкость.
Возьмём условный кластер с 30 ТБ сырой ёмкости. При двух копиях теоретический верхний предел составит 15 ТБ: 30 / 2. При трёх копиях останется 10 ТБ: 30 / 3.
Это расчёт, а не характеристика готовой системы. Фактическая ёмкость окажется ниже из-за служебного резерва и выбранной защиты. Для другого объёма разделите сырую ёмкость на число копий, затем запросите у поставщика размер резерва.
| Сырая ёмкость | Число копий | Верхний предел полезной ёмкости | Что уточнить перед расчётом бюджета |
|---|---|---|---|
| 30 ТБ | 2 | 15 ТБ | Служебный резерв и запас под восстановление |
| 30 ТБ | 3 | 10 ТБ | Размещение копий при отказе узла |
| Любой объём | 2 | Сырая ёмкость / 2 | Допустимый уровень защиты |
| Любой объём | 3 | Сырая ёмкость / 3 | Цена дополнительной копии и узлов |
Третья копия сокращает доступную ёмкость на треть относительно схемы с двумя копиями. Платите вы не только за терабайты, но и за выбранный уровень защиты.
При сбое Vitiscale восстанавливает повреждённые данные из зарезервированного пространства. Netwell также указывает настройку скорости восстановления и сервисного окна. Это полезно для СУБД: фоновое восстановление можно ограничить, чтобы оно не забрало весь ввод-вывод у рабочей базы.
Но сам механизм ещё не отвечает на вопрос о поведении 1С. Нужен замер задержки транзакций во время отказа и восстановления. Средняя скорость за спокойный час здесь мало что скажет.
QoS решает соседнюю задачу. Если один кластер обслуживает СУБД, Kubernetes и резервные копии, для томов можно задать разные политики качества обслуживания. До испытаний остаётся неизвестным, удержит ли политика нужную задержку записи под вашей смешанной нагрузкой.
Почему миллионы IOPS ничего не обещают базе 1С
Byte Magazine и CNews приводят заявленную производительность Vitiscale: десятки миллионов IOPS и сотни тысяч запросов к объектному хранилищу в секунду. Переносить эти цифры в проект 1С нельзя.
В публикациях нет конфигурации узлов, размера блока и соотношения чтения к записи. Не указаны глубина очереди, задержка и условия деградации. Без этих данных число IOPS нельзя сопоставить даже с другим тестом СХД.
Нет и сценария 1С. Проведение документа, фоновое задание, построение отчёта и массовая загрузка создают разные профили обращений к СУБД. Итог зависит также от блокировок, настроек СУБД и работы процессора.
| Что опубликовано | Чего не хватает для проекта 1С | Предварительный вердикт |
|---|---|---|
| Десятки миллионов IOPS | Методика, размер блока, задержка и профиль записи | Не использовать число при выборе конфигурации |
| Фермы СУБД названы целевой нагрузкой | Перечень проверенных СУБД и версий | Запросить матрицу совместимости |
| Отказ узла не останавливает обслуживание | Задержка и пропускная способность после отказа | Проверить на копии рабочей базы |
| Управляемое восстановление после сбоя | Влияние восстановления на транзакции СУБД | Испытать с рабочими ограничениями QoS |
| Сценарий резервного копирования заявлен | Совместимость с вашим программным обеспечением и регламентом | Провести восстановление тестовой копии |
| Поддерживаются Prometheus и Grafana | Состав метрик и готовые правила оповещения | Сопоставить метрики с регламентом эксплуатации |
| Масштабирование идёт без остановки | Поведение задержки при добавлении узла | Замерить во время расширения кластера |
До таких испытаний Vitiscale остаётся кандидатом, а не готовой рекомендацией для 1С.
Один сервер 1С: оставить локальные NVMe
Если у вас один сервер приложений и одна СУБД, опубликованных оснований менять локальные NVMe на три узла Vitiscale нет. Вы получите отдельную сеть хранения, новые точки настройки и ещё один контур обновлений.
Отказоустойчивость тоже нельзя оценивать только по СХД. База останется недоступной при отказе единственного сервера СУБД, даже если хранилище продолжит работать. Потребуется второй вычислительный узел и проверенная процедура переключения.
Сначала определите конфигурацию самого сервера. Для крупной односерверной установки пригодится разбор сервера для 1С на 100 пользователей. Если выбор ещё идёт между своим оборудованием и размещением вне офиса, сравните, когда выделенный сервер лучше облака.
Локальные NVMe не закрывают отказ всего сервера. Этот риск снимают резервная копия, отдельное место её хранения и проверенное восстановление. Покупка кластерной СХД не заменяет ни один из этих пунктов.
Несколько серверов СУБД: включить Vitiscale в испытания
Vitiscale стоит внести в короткий список, если несколько серверов СУБД должны получать общие блочные тома. Второе условие — расширение хранилища нельзя проводить с остановкой сервисов.
В таком проекте минимальные три узла уже работают на понятную задачу. Они дают общий контур хранения и переживают отказ отдельного узла по заявлению поставщика. Однако окончательное решение всё равно принимает испытание.
Возьмите копию рабочей базы и воспроизведите типичный день. Отдельно запустите тяжёлую регламентную операцию, резервное копирование и восстановление данных внутри СХД. Затем отключите один узел и повторите нагрузку.
Смотрите не на максимальные IOPS, а на задержку синхронной записи СУБД. Зафиксируйте также время перестроения, загрузку сети и накопителей, ошибки на стороне СУБД. Порог задаёт ваш регламент, а не презентация поставщика.
Общая платформа для СУБД, Kubernetes и S3: архитектура подходит, проверка остаётся
Vitiscale объединяет блочный доступ, S3 API и тома для Kubernetes. Поэтому продукт интересен компании, которая не хочет держать три отдельных хранилища для СУБД, контейнеров и объектов.
У такого объединения есть цена. Ошибка настройки или обновления затронет сразу несколько систем. Команда эксплуатации должна проверить разграничение ресурсов, резервирование и порядок восстановления каждого типа данных.
Публичный CSI-драйвер datagarden подтверждает возможность выдавать Kubernetes постоянные тома через NVMe/TCP. Он не подтверждает совместную работу Kubernetes и нагруженной базы 1С на одном кластере. Для этого нужен смешанный тест с включёнными политиками QoS.
Какие условия записать до запроса коммерческого предложения
Испытание теряет смысл, если критерии успеха придумывают после получения графиков. Запишите их до встречи с поставщиком.
Проверьте пять пунктов:
- СУБД и её версия входят в матрицу совместимости.
- Задержка записи укладывается в ваш порог на обычной и пиковой нагрузке.
- После отказа узла база сохраняет тот же допустимый порог.
- Восстановление данных завершается внутри сервисного окна.
- Резервная копия разворачивается на отдельном контуре и проходит проверку.
Если Vitiscale выполняет все пять условий, её можно сравнивать по стоимости с действующим хранилищем. Если провален хотя бы один пункт, оставьте текущую схему или меняйте требования проекта.
Для одного сервера 1С предварительный вердикт другой: не закладывать Vitiscale только из-за анонса. Три узла повышают сложность, а опубликованных испытаний с 1С нет.
Для фермы СУБД, общего хранилища нескольких систем или роста без остановки Vitiscale стоит испытать. Подобрать точную схему без данных о базе, СУБД и допустимом простое нельзя. Эти параметры можно сверить на консультации по архитектуре сервера 1С уже после первичного отбора.