TROK: возможности российской системы хранения данных и руководство по выбору

TROK — российское программно-определяемое хранилище данных (SDS) от «Группы Астра». При выборе такой платформы важно оценивать не только объем доступного пространства, но и поведение инфраструктуры под нагрузкой, условия сопровождения и стоимость дальнейшего развития.

В этом обзоре разберем, что представляет собой TROK, какие характеристики опубликованы разработчиком и как подойти к оценке решения перед внедрением. Практическая часть поможет подготовить техническое задание, спланировать пилотный проект и сравнить предложения поставщиков по одинаковым критериям.

Что такое TROK и как устроен подход SDS

Аббревиатура SDS расшифровывается как Software-Defined Storage — программно-определяемое хранилище. В такой архитектуре программный слой отделяет управление ресурсами хранения от конкретной аппаратной платформы. Это позволяет рассматривать оборудование и программные средства управления как отдельные составляющие инфраструктуры. Подробнее принцип описан в обзоре SDS от IBM.

Для заказчика такой подход меняет логику выбора. Вместо одного вопроса «какой дисковый массив купить» появляются несколько связанных задач: определить профиль нагрузки, подобрать серверную конфигурацию, спроектировать сеть и согласовать правила эксплуатации.

Например, два проекта с одинаковым объемом данных могут требовать совершенно разных решений. В одном случае сотрудники редко открывают архивные документы. В другом — сотни пользователей одновременно работают с учетной системой. Количество терабайт совпадает, но требования к задержкам, скорости записи и восстановлению различаются.

Поэтому оценку TROK стоит начинать с описания приложений и бизнес-процессов. Оно станет основой для выбора оборудования, испытаний и расчета бюджета.

Заявленные возможности TROK

На официальной странице TROK разработчик указывает следующие характеристики и сценарии:

• сохранение доступности данных при выходе узлов из строя;
• использование для виртуализации, VDI, СУБД и хранения резервных копий;
• поддержку NVMe-oF и iSCSI;
• работу на стандартном серверном оборудовании и масштабирование;
• интеграцию с Astra Linux и продуктами экосистемы;
• российскую техническую поддержку с SLA.

Это отправная точка для оценки продукта. Конкретные показатели быстродействия, поддерживаемые сочетания версий и допустимые сценарии отказов следует фиксировать для выбранной конфигурации.

Далее приведена практическая методика выбора корпоративного хранилища. Перечисленные проверки и требования не означают, что соответствующая функция автоматически присутствует в каждой поставке trok.

Как оценивать хранилище под разные нагрузки

Инфраструктура виртуальных машин

Для проекта виртуализации полезно составить перечень виртуальных машин и разделить их по критичности. Тестовый сервер, система документооборота и основная учетная база обычно имеют разные требования к доступности.

В программу испытаний стоит включить одновременный запуск группы машин, выполнение резервного копирования в рабочее время и обслуживание одного из компонентов инфраструктуры. Важно проверить, остаются ли критичные приложения в согласованных пределах производительности.

Оценивать результат лучше по действиям пользователей: времени открытия формы, формирования отчета или завершения операции. Синтетические измерения дополняют эту картину, но сами по себе не описывают качество работы приложения.

Базы данных

Для базы данных заранее определите набор контрольных операций. Это могут быть проведение документов, загрузка пакета записей, расчет аналитического отчета или обработка нескольких параллельных запросов.

Сравнение будет полезным, если тестовая база сопоставима с рабочей по объему и структуре, а сценарий отражает реальную активность. Испытание на небольшой демонстрационной базе может дать результат, который трудно перенести на промышленную среду.

Отдельно согласуйте требования к корректности данных после аварийного перезапуска и процедуру проверки приложения после восстановления доступа.

Виртуальные рабочие места

В проекте VDI стоит воспроизвести начало рабочего дня: одновременное подключение сотрудников, загрузку профилей и запуск основных программ. Дополнительно полезно проверить периоды обновлений и массового завершения сеансов.

Критерием приемки может стать время готовности рабочего стола для заранее определенного числа пользователей. Такой показатель понятен и технической команде, и руководителю подразделения.

Резервное копирование

Для резервных копий проверяйте весь цикл: создание копии, хранение, поиск нужной версии и восстановление. В пилот стоит включить возврат отдельного файла и восстановление целого сервиса.

Заранее определите, какие данные нужны для успешного восстановления кроме самой копии: учетные записи, ключи, настройки сети, конфигурация приложения. Испытание должно показывать, когда пользователи действительно смогут вернуться к работе.

Протоколы доступа и производительность

Протокол доступа определяет способ взаимодействия сервера с хранилищем. NVMe over Fabrics расширяет использование NVMe на сетевые соединения.

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

Чтобы получить сопоставимые результаты, включите в отчет несколько групп показателей:

В протокол испытаний включайте сведения об оборудовании, заполненности хранилища, настройках защиты, числе клиентов и длительности теста. Без этих условий цифры трудно использовать для обоснованного сравнения.

Отказоустойчивость и защита данных

Требование «система должна быть отказоустойчивой» слишком общее для технического задания. Его лучше заменить перечнем проверяемых событий и ожидаемых результатов.

Для согласования с поставщиком можно использовать такие вопросы:

• Что происходит при потере одного накопителя?
• Как меняется доступ к данным при отключении сервера?
• Как обрабатывается потеря сетевого соединения?
• Какие действия выполняются автоматически, а какие требуют администратора?
• Какие ограничения действуют во время восстановления?
• Какой дополнительный отказ система способна выдержать в этот период?

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

Почему нужен отдельный план резервного копирования

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

В такой ситуации необходимо определить, из какой сохраненной версии восстанавливать сервис, кто принимает решение и сколько времени занимает процедура. Эти вопросы следует проработать независимо от испытаний на отключение оборудования.

Для бизнеса удобно сформулировать два требования: какой объем последних изменений допустимо потерять и за какое время необходимо вернуть сервис. В проектной документации для них обычно используют обозначения RPO и RTO.

Оборудование и совместимость: что проверить заранее

При подборе оборудования для TROK запросите подтвержденную спецификацию под вашу нагрузку. Формулировка о работе на стандартных серверах не должна становиться основанием для закупки произвольного набора компонентов.

В спецификации полезно зафиксировать:

• количество узлов и их роли;
• модели процессоров и объем оперативной памяти;
• модели, количество и характеристики накопителей;
• сетевые адаптеры и схему подключения;
• версии операционной системы, драйверов и прошивок;
• необходимый резерв ресурсов;
• варианты последующего расширения.

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

Для программной совместимости составьте таблицу точных версий: операционная система, платформа виртуализации, система резервного копирования и остальные компоненты проекта. Ответ «совместимо с продуктом» желательно дополнить перечнем проверенных сценариев и ограничений.

Как рассчитать емкость хранилища

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

Для предварительной оценки потребности можно использовать простую модель:

Прогнозируемый объем данных = текущий объем × (1 + годовой темп роста)^{число лет}.

Предположим, сейчас приложения занимают 40 ТБ, ежегодный рост ожидается на уровне 25%, а горизонт планирования составляет три года. Тогда прогноз равен:

40 × 1,25³ = 78,125 ТБ.

Это условный пример расчета пользовательских данных. Он не определяет физический объем оборудования для TROK. К прогнозу потребуется добавить ресурсы, предусмотренные выбранной схемой защиты, эксплуатационный резерв и дополнительные потребности проекта.

Отдельно учтите временное место для миграции, тестовых копий и операций обслуживания, если они предусмотрены вашей архитектурой. Попросите указать порог заполнения, после которого необходимо начинать расширение, и реальный срок поставки дополнительных компонентов.

Практичный результат расчета — таблица емкости на старте, через год и к концу планового периода. Она помогает заранее согласовать бюджет и избежать экстренного расширения.

Лицензирование TROK и техническая поддержка

Согласно странице продукта, доступны бессрочная лицензия и подписка на 12, 24 или 36 месяцев. Указаны единицы тарификации 10 ТБ и 1 ПБ. Поддержка представлена вариантами 8/5 и 24/7. Для хранения 17 ТБ разработчик приводит пример покупки двух единиц по 10 ТБ.

Перед заказом уточните, какая именно емкость подлежит лицензированию в вашей конфигурации и как учитывается расширение. Попросите включить правила расчета в коммерческое предложение.

Для сопровождения согласуйте время реакции на обращения разной критичности, порядок эскалации и состав включенных работ. Время первого ответа и срок восстановления сервиса следует обсуждать отдельно.

Полезно также определить границы ответственности: кто диагностирует сетевую проблему, кто взаимодействует с производителем сервера и кто координирует инцидент, затрагивающий несколько продуктов.

Из чего складывается стоимость TROK

На официальной странице заявлено снижение совокупной стоимости владения до 50%. Эту оценку следует рассматривать как заявление разработчика, а не как гарантированную экономию для любого проекта.

Для собственного расчета сравните варианты на одинаковом горизонте, например на три или пять лет. Включите в бюджет следующие статьи:

1. Программное обеспечение: первоначальные лицензии, подписки и расширение.
2. Оборудование: серверы, накопители, сеть и запасные компоненты.
3. Внедрение: обследование, проектирование, настройка и испытания.
4. Миграция: подготовка, перенос и временная параллельная эксплуатация.
5. Сопровождение: техническая поддержка и плановые работы.
6. Эксплуатация: трудозатраты команды, размещение и энергопотребление.

Чтобы сравнение оставалось корректным, во всех вариантах используйте одинаковые требования к полезной емкости, производительности и восстановлению. Иначе более низкая цена может объясняться меньшим объемом включенных ресурсов или услуг.

Запросите два сценария бюджета: при ожидаемом росте и при его ускорении. Это покажет, насколько чувствительны расходы к увеличению объема данных.

Как сравнить TROK с другими системами хранения

Для выбора между TROK, другой SDS-платформой и аппаратной СХД полезнее составить общую оценочную матрицу, чем сопоставлять рекламные описания. Каждому поставщику следует передать одинаковый набор исходных требований.

Если рассматривается переход с самостоятельно сопровождаемой SDS, включите в сравнение текущие трудозатраты команды. Оцените, какие работы после внедрения нового решения останутся у администраторов, а какие войдут в договор сопровождения.

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

Как провести пилотный проект TROK

Пилот должен завершаться решением, которое можно обосновать измерениями. Для этого критерии успеха следует согласовать до начала установки.

1. Зафиксировать исходные требования

Соберите объем данных, темп роста, список критичных приложений, периоды пиковой активности и допустимые окна обслуживания. Назначьте владельцев контрольных сценариев со стороны бизнеса.

2. Согласовать тестовую конфигурацию

Опишите состав оборудования и отличия пилота от будущей промышленной системы. Если стенд меньше проектной конфигурации, отдельно обозначьте, какие выводы по его результатам делать нельзя.

3. Подготовить критерии приемки

Используйте измеримые условия: конкретное время выполнения операции, количество одновременных пользователей, длительность восстановления или допустимое число ошибок. Формулировки «быстро» и «стабильно» замените согласованными значениями.

4. Выполнить рабочие и аварийные сценарии

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

5. Проверить эксплуатационные процедуры

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

6. Подготовить итоговый отчет

В отчете разделите выполненные требования, обнаруженные ограничения и вопросы, требующие доработки. Укажите окончательную конфигурацию и условия, при которых результаты пилота применимы к промышленному внедрению.

Как подготовить миграцию на TROK

План миграции следует составлять для сервисов целиком. Кроме данных, в него входят зависимости приложений, настройки подключения, права доступа и порядок переключения пользователей.

Рабочая последовательность может выглядеть так:

1. Инвентаризация: определить данные, приложения, владельцев и взаимосвязи.
2. Выбор способа переноса: согласовать инструменты и ограничения исходной системы.
3. Подготовка восстановления: проверить актуальность копий и возможность их использования.
4. Пробная миграция: перенести тестовый сервис и измерить длительность операций.
5. Проверка: подтвердить целостность данных и выполнение прикладных сценариев.
6. Промышленное переключение: выполнить перенос в согласованное окно.
7. Наблюдение: проконтролировать работу сервиса после запуска.

До переключения установите условия отката. Определите, кто принимает решение, до какого момента возврат возможен и как обрабатываются изменения, появившиеся после запуска новой системы.

Вывод исходного хранилища из эксплуатации лучше выделить в отдельный этап с собственными критериями завершения.

Что спросить у поставщика перед покупкой

• Какая конфигурация предлагается под наш профиль нагрузки и чем обоснован ее выбор?
• Сколько полезной емкости будет доступно на старте?
• Как рассчитывается лицензируемый объем?
• Какие версии компонентов проверены совместно?
• Какие отказы допускает предложенная архитектура?
• Как изменится производительность во время восстановления?
• Как проходит расширение и требуется ли остановка сервисов?
• Какие операции сопровождения выполняет заказчик?
• Что входит в SLA и как устроена эскалация?
• Какой способ миграции предлагается и какие ограничения у него есть?
• Какие документы подтверждают выполнение обязательных требований нашего проекта?
• Какова полная стоимость эксплуатации на выбранный период?

Ответы желательно получить в составе спецификации, технического предложения или программы испытаний. Это упростит приемку и уменьшит количество разночтений после поставки.

Частые вопросы о TROK

С чего начать оценку TROK для своей компании?

Составьте краткое описание нагрузки: приложения, текущий объем данных, прогноз роста, число пользователей и требования к восстановлению. На этой основе запросите конфигурацию и программу пилота.

Можно ли подобрать систему только по количеству терабайт?

Для обоснованного выбора этого недостаточно. Добавьте требования к скорости прикладных операций, допустимым отказам, совместимости и сопровождению. Затем проверьте предложенное решение на согласованном сценарии.

Как узнать цену TROK?

Запросите коммерческое предложение с отдельными строками для программного обеспечения, поддержки, оборудования и работ. Укажите горизонт расчета и ожидаемое расширение, чтобы получить бюджет всего проекта.

Что важнее в пилоте: IOPS или скорость приложения?

Критерий приемки лучше связать с работой приложения. IOPS, пропускную способность и задержки используйте для объяснения результата и сопоставления одинаковых тестовых конфигураций.

Можно ли заранее обещать миграцию без простоя?

Такое условие следует подтверждать после обследования исходной инфраструктуры и пробного переноса. В техническом плане должны быть указаны инструменты миграции, зависимости и порядок переключения.

Как проверить требования к безопасности и документам?

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

Когда можно считать выбор хранилища обоснованным?

Когда зафиксированы конфигурация и бюджет, подтверждены критичные сценарии, согласованы ограничения и подготовлен план эксплуатации. Такой набор результатов дает основу для решения о внедрении TROK и последующей приемки системы.