Тестируем систему контроля информационного обмена «Синоникс» с VEGMAN R220 G3 и TATLIN.BACKUP.M

«Синоникс» — это система контроля информационного обмена (СКИО). С ней можно автоматизировать передачу данных и файлов между узлами двух сетей, скрывая при этом информацию об их окружении. СКИО интересны в первую очередь компаниям с изолированными сегментами сети: энергетика, промышленность, госсектор.

Важный аргумент при выборе СКИО — это ее скорость. Для оценки возможного максимума нужно, чтобы «железо» не стало узким горлышком в бенчмарке. Мы развернули инфраструктуру с гарантированным запасом аппаратных мощностей на основе серверов VEGMAN R220 G3, СХД TATLIN.BACKUP.M и в этой статье покажем, на что способен «Синоникс» в реальных сценариях.

Зачем нужен «Синоникс»

О физических угрозах IT-инфраструктуре мы все знаем из новостей. Так что обратим внимание на другой фактор. С 24 августа 2026 года действует указ президента №604 о временном управлении объектов критической инфраструктуры. Вкратце: согласно указу такие объекты могут быть переданы во временное управление Росимущества, если для них не была обеспечена безопасность на должном уровне. Список объектов не зафиксирован. Оценивают безопасность по двум основным критериям: приняты ли меры защиты и как быстро восстановлена работа объекта.

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

Цели тестирования и общая концепция решения

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

• скорость передачи данных между сегментами сети;

• производительность при параллельной нагрузке: много одновременных потоков и большие объемы данных;

• поведение под длительной нагрузкой: стабильная скорость и работа в принципе.

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

• DR (Disaster Recovery). Синхронная реплика продуктива на уровне массива на резервную площадку, асинхронный съезд — через систему резервного копирования. Обмен двусторонний, состав повторяет основной ЦОД. DR закрывает угрозу отказа инфраструктуры и потери основной площадки.

• Сейф на основе третьего асинхронного ЦОД. Аппаратно состав решения тот же, но принимающая сторона доступна в сети только на прием данных и только во время передачи данных. Такой однонаправленный шлюз обеспечивает полную изоляцию. Сейф закрывает угрозу обратного воздействия из продуктива и компрометации СРК.

• Хранилище судного дня. Размещается на удаленной стационарной площадке или в защищенном контейнере. СРК хранилища сама забирает копии через однонаправленный шлюз — основного ЦОД, площадки DR или Сейфа. Внутри хранилища — собственная проверка безопасности с клоном read-only.

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

«Синоникс» входит в состав каждого участка: в DR, Сейфе и Хранилище и на границе контура он работает как контролируемый обмен, отделяет сети заказчика и его данные от описанной выше инфраструктуры. СРК ходит в основное хранилище по двустороннему протоколу и наследует его ключевой риск, досягаемость для команды удаления. Иммутабельные ленты и WORM-политики здесь могут закрыть только часть возможных лазеек для двустороннего доступа. Хранилище снимает эту угрозу с помощью однонаправленного шлюза.

Оборудование стенда

В основе тестового стенда — четыре сервера VEGMAN R220 G3 с двумя Intel Xeon Gold 6438Y+ и 768 ГБ DDR5-4800 на борту каждого:

• На трех серверах — DIODE-A, DIODE-CORE, DIODE-B — развернута ОС Astra Linux 1.8.6 с ядром 6.12, в максимально защищенной редакции «Смоленск» без графического интерфейса. При установке добавлен пакет ПО ssh server, а после — ethtool, lshw, iperf и fio в последних версиях из официального репозитория Astra.

• На четвертом сервере — T-REX — развернута Ubuntu и генератор трафика Cisco TRex. Через этот сервер мы настраивали и запускали тесты.

На всех серверах применены настройки UEFI для эффективной работы CPU с приоритетом на производительность (Efficiency Favor Performance), в том числе включен Turbo mode.

В тестах использовали СХД TATLIN.BACKUP.M: 2 TB RAM, 16 ТБ SAS 7200 об/мин, дисковый модуль расширения L12, базовый кеш для метаданных. Предустановленное ПО TATLIN.BACKUP с включенным протоколом T-BOOST, выполняющим часть процесса дедупликации и сжатия на источнике передачи данных. T-BOOST в разы снижает нагрузку на сеть и увеличивает скорость записи резервных копий.

Площадки стенда соединены между собой через обычные двухсторонние сети: Ethernet (L2/L3), MPLS L3VPN, IPsec VPN over WAN, OTN/SDH. Сервера DIODE-A и DIODE-B подключены к DIODE-CORE и напрямую не связаны.

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

По ходу тестов мы имитировали работу описанного выше Хранилища судного дня. Воспроизводили одни и те же тесты записи по двум схемам: в TATLIN.BACKUP через «Синоникс» или в TATLIN.BACKUP напрямую. Каждый тест повторили при MTU 1500 и MTU 9000 (jumbo). MTU переключался на всех участках пути — сервер, коммутатор, СХД — чтобы jumbo-кадры реально ходили end-to-end. Каждую комбинацию повторили под двумя профилями нагрузки, в итоге получилось восемь прогонов.

Дисковую нагрузку генерировали с помощью fio: последовательная запись блоками по 1 МБ, несколько параллельных потоков, каждый держит свою очередь запросов фиксированной глубины. В конце прогона — принудительный сброс на носитель (end_fsync).

Нагрузку разделили по двум профилям:

• «Легкий» сценарий (qd4) шел в 4 потока с очередью 4, то есть 16 запросов в нагрузке. Прогон занимал пять часов. Этот сценарий имитирует умеренное копирование одной-двух систем.

• «Тяжелый» сценарий (qd4) шел в 16 потоков с очередью 16, то есть 256 запросов в нагрузке. Прогон занимал один час, Этот сценарий имитирует массовый одновременный бэкап.

Что говорят цифры

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

В сравнительно более легком профиле «Синоникс» не приносит штрафа для нагрузки, а даже наоборот. На тяжелой нагрузке прямая схема при MTU 9000 дает 683, через шлюз — 495 МиБ/с. То есть шлюз отнимает 27% от производительности прямого тракта. При MTU 1500 разница скромнее — около 6%.

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

Общие выводы

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

Мы не гнались за максимальной нагрузкой тракта. Для нашей задачи — измерения влияния шлюза — можно было обойтись стандартными сценариями. Добавление шлюза «Синоникса» на передачу данных TATLIN.BACKUP заметно влияет только в «тяжелых» сценариях. Поэтому оценивать применение этой СКИО при нагрузке, приближенной к этому тестовому сценарию, стоит в каждом случае отдельно. Каналы связи на больших расстояниях очень зависят от конкретной инфраструктуры. Компромисс между скоростью и надежностью неизбежен, и в каждом проекте его приходится искать заново.