Хабр, привет! На связи Алексей Зотов из К2Тех. Поиск надежных альтернатив западным системам хранения по-прежнему актуален для нас и наших клиентов. Не так давно в инфраструктурную лабораторию К2Тех приехало железо от ведущего российского разработчика и производителя YADRO, которому я решил посвятить небольшой цикл статей. В первой части я рассказывал об универсальной СХД начального уровня TATLIN.FLEX. А сегодня, как и обещал, поделюсь результатами тестов специализированной СХД для резервного копирования с поддержкой глобальной дедупликации — TATLIN.BACKUP. Эта система позиционируется как отечественная альтернатива популярным решениям Dell DataDomain и HPE StoreOnce.

Мы проверили ее производительность, отказоустойчивость и эффективность оптимизации данных. Уделили внимание сравнению с западными аналогами и тестированию новой версии 1.1 с поддержкой T-Boost. Давайте узнаем, насколько эффективна TATLIN.BACKUP в реальных условиях.

Основные характеристики и особенности TATLIN.BACKUP

TATLIN.BACKUP от YADRO — специализированная СХД для хранения резервных копий с глобальной дедупликацией. Фактически это российский аналог Dell DataDomain. Обе системы имеют идентичную структуру как внешне (один контроллер и диски), так и внутренне (MTree → VFS, DDBoost → T-Boost и т. д.).

Аппаратная платформа TATLIN.BACKUP представляет собой 2U-шасси на базе двух процессоров Intel Xeon Gold третьего поколения, 2 ТБ памяти (32 модуля на 64 ГБ DDR4).

Подключение к системе возможно двумя способами: через выделенные management-порты со скоростью 1 Гбит/с или через две сетевые карты Ethernet с пропускной способностью 2 × 25 Гбит/с каждая. Однако к моменту публикации этой статьи, их разделили на сеть управления 1 Гбит/с и сеть данных — 10/25 Гбит/с. СХД работает по протоколам NFS и CIFS, обеспечивая хранение от 80 до 690 терабайт данных при максимальной скорости записи 15 терабайт в час.

Для хранения метаданных используется шесть NVMe-накопителей объемом 3,84 терабайта каждый. Основное хранилище поддерживает установку до 14 жестких дисков формата LFF емкостью 8 или 16 терабайт (1-4 полки 2U). 

Архитектура системы включает центральный контроллер и модули расширения. Подключение дополнительных модулей организовано по принципу последовательного соединения Daisy Chain через две независимые петли — это стандартная практика для СХД. Однако это ключевое архитектурное отличие TATLIN.BACKUP от Dell DataDomain. Там полки собираются в кольцо.

Подобно Dell DataDomain, TATLIN.BACKUP использует собственную виртуальную файловую систему — TBFS.

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

1. Дедупликация. Система анализирует входящий поток данных в режиме реального времени (Inline-режим), выявляя блоки переменной длины, идентичные уже хранящимся в системе. Обнаруженные дубликаты заменяются ссылками на существующие блоки. Использование блоков переменной длины повышает эффективность дедупликации по сравнению с фиксированным размером блока.

2. Компрессия. Каждый уникальный блок сжимается с помощью алгоритма ZSTD. Сжатые блоки группируются в контейнеры фиксированного размера для эффективного размещения на дисковом пространстве.

Защита данных в системе обеспечивается технологией T-RAID, причем здесь используются два типа пулов: на HDD и на NVMe. 

Пул на жестких дисках предназначен для хранения дедуплицированных блоков пользовательских данных. Защита от отказа реализована по схеме 10+2(2), что означает десять секций для данных, две для четности. Размер блока составляет 640 килобайт.

Пул на NVMe-накопителях обслуживает метаданные файловой системы TBFS. Защита от отказа до трех накопителей. Размер блока — 4 килобайта, что оптимально для работы с метаданными.

Технология T-RAID сегментирует адресное пространство на K-секции, создавая для каждого блока защитную цепочку формата K+M, где K — секции данных, а M — секции с избыточной информацией. Система поддерживает дополнительный резерв для восстановления данных и гарантирует размещение каждой секции цепочки на отдельном физическом диске, что повышает отказоустойчивость.

В качестве дополнительных механизмов защиты TATLIN.BACKUP использует еще три механизма:

• Система проверяет целостность данных методом сквозной верификации (end-to-end): контрольные суммы сверяются при записи из оперативной памяти во временное хранилище и при записи на диск.

• Copy-on-Write (COW): при изменении части файла система не удаляет старые данные, а записывает обновленный блок в новый контейнер.

• Упреждающую журнализацию (WAL): СХД сначала фиксирует все изменения в журнале, и только потом записывает их на диск.

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

Начало тестирования TATLIN.BACKUP

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

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

• ВМ на базе VMware;

• ВМ на базе zVirt;

• Файловая система на уровне агента внутри ВМ, куда была загружена максимально разрозненная информация с сервисного файлообменника — от логов и отчетов до образов систем и микрокодов.

В качестве основных систем резервного копирования в рамках теста использовали Кибер Бэкап 17.0 и Vinchin 8. Дополнительно проверили совместимость СХД с ПО РК Береста последней версии. 

RuBackup пришлось исключить из тестирования, так как на момент тестирования версия 2.2 не позволяла отключить свой встроенный механизм дедупликации. На сегодняшний день это возможно в версии 2.3, но система хранения уже возвращена производителю.

Проверка эффективности TATLIN.BACKUP

СХД показала высокую эффективность при резервном копировании виртуальных машин. Гигабитные каналы в первой лаборатории она загружает легко и обеспечивает коэффициент оптимизации 20x.

При параллельном выполнении нескольких задач резервного копирования система распределяет нагрузку на несколько потоков записи. На основной площадке при пропускной способности 1 Гбит/с мы получили следующие показатели:

Чтобы сильнее загрузить TATLIN.BACKUP, мы подключили дополнительную лабу с каналом 10 Гбит/с и начали заливать сложные для обработки данные, которые плохо сжимаются: сервисные образы операционных систем и файлы журналов.

Кибер Бэкап 17.0 не подходит для решения такой задачи из-за однопоточной архитектуры, так что этот тест проводили при помощи Vinchin. Мы настроили задание на сканирование и передачу данных через 32 параллельных потока. В такой конфигурации скорость резервного копирования достигла 800 Мбайт/с.

Если запустить это же задание в один поток, скорость снижается в четыре раза, до 200 Мбайт/с. Загрузка неоптимальных данных изначально снизила коэффициент сжатия до 9:1. После обработки данных системой дедупликации показатель вырос до 12:1 в течение двух дней.

Тестируем сборщик мусора

Производитель предупреждает о высокой нагрузке на систему во время очистки данных. Мы протестировали этот процесс, удалив три крупных виртуальных файловых хранилища (VFS) с резервными копиями виртуальных машин. 

Во время работы сборщика мусора (garbage collection) пиковая нагрузка на процессор достигла 20%. Такой уровень потребления ресурсов может снизить производительность параллельных операций резервного копирования.

Система обработала более 30 ТБ виртуальных данных, но физически удалила только 1 ТБ благодаря эффективной дедупликации. После завершения сборки мусора коэффициент сжатия данных снизился до 6х.

Проверки на отказоустойчивость

Мы провели для TATLIN.BACKUP стандартное тестирование отказоустойчивости по нашей методике — имитировали выход из строя зарезервированных компонентов: дисков метаданных, дисков данных, системных дисков, блока питания, карт расширения и сетевых интерфейсов.

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

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

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

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

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

Экспорт тоже пришлось перенастраивать, но вендор уже исправил эту ошибку, так что новые пользователи TATLIN.BACKUP с ней не столкнутся.

Тестирование силовых и сетевых компонентов показало высокую надежность системы. При отключении одного из блоков питания или сетевых интерфейсов система сохранила стабильную производительность без снижения показателей нагрузки. Только показания по шуму выросли с базовых  94 дБ до 103 дБ возле системы и 87 дБ до 96 дБ около стойки.

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

Сравнительный тест: TATLIN.BACKUP VS другие СХД

Для сравнительного тестирования мы использовали три СХД и одну классическую систему резервного копирования:

• TATLIN.BACKUP, физическое устройство, версия 1.0.0-68-90c8be4

• Dell DataDomain VE, ВМ, версия 8.0.0.20-1107705

• ExaGrid EX18, физическое устройство, версия 6.1.0.P09 (build 2014)

• Veritas Netbackup, ВМ, версия 10.1

Тестовая среда включала виртуальные машины общим объемом 1 терабайт. В качестве программного обеспечения для резервного копирования выбрали Vinchin из-за поддержки многопоточной обработки данных. Обеспечить единые условия и связность 10 Гбит/с для всех СХД оказалось проблемно, оборудование находилось в разных помещениях, поэтому мы не стали оценивать производительность. Вместо этого провели два теста: 

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

• На втором этапе повторили тестирование с разными наборами виртуальных машин. Использовали как различные виртуальные машины внутри одной платформы виртуализации, так и машины с разных платформ.

Результаты первого теста

В таблице представлены результаты первого сравнительного теста. Имейте в виду, что Vinchin использует неотключаемую оптимизацию. Поэтому фактический 1 ТБ референсных данных на СХД весит примерно 570 ГБ.

Параметры немного разные, но эти данные позволяют корректно сравнивать СХД между собой. Как видите, TATLIN.BACKUP жмёт данные на уровне западных аналогов, а порой и превосходит их.

Результаты второго теста

Второй этап тестирования был направлен на проверку эффективности оптимизации при работе с различными наборами данных. Из-за ограничений лабораторной среды мы не смогли обеспечить максимальную нагрузку на систему: часть лабораторных виртуальных машин — это сервера резервного копирования со своей оптимизацией, виртуальные апплаенсы, VTL. Поэтому мы провели пять тестов с разными виртуальными машинами общим объемом около 1 терабайта.

Виртуальные машины на zVirt сильно сжимались после бэкапа, так что фактическая нагрузка на СХД заметно снизилась. В результате исходный объем данных в 1 терабайт после резервного копирования сокращался до нескольких сотен гигабайт.

В таблице вы видите детальную статистику производительности TATLIN.BACKUP. Мы пришли к выводу, что эффективность распознавания и оптимизации различных типов данных у TATLIN.BACKUP, Dell DataDomain ExaGrid EX18 и Veritas Netbackup на сопоставимом уровне. Максимальное отклонение в показателях между системами не превысило 10%.

Мы пришли к выводу, что эффективность распознавания и оптимизации различных типов данных у TATLIN.BACKUP, Dell DataDomain ExaGrid EX18 и Veritas Netbackup на сопоставимом уровне. Максимальное отклонение в показателях между системами не превысило 10%.

Проверка влияния сжатия через КБ17 на оптимизацию TATLIN.BACKUP

В ходе тестов мы хотели определить оптимальные параметры хранения данных в TATLIN.BACKUP применительно к российским реалиям. Один из самых популярных продуктов сейчас - это решение Кибер Бэкап, поэтому мы отдельно протестировали работу СХД с этим продуктом. 

Архитектура тестового стенда была построена на распределении виртуальных машин между несколькими виртуальными агентами. Мы развернули их, чтобы обеспечить множество параллельных сессий. Задания резервного копирования настроили для обработки виртуальных машин со всех VA параллельно. Обеспечили равномерное распределение нагрузки: на каждую политику резервного копирования и апплаенс приходилось около 700 ГБ данных.

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

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

Статистика по времени выполнения одной полной копии:

Для анализа производительности мы использовали усредненные показатели времени выполнения операций. Например, резервное копирование виртуальной машины VM-01 с отключенной оптимизацией стабильно выполнялось за 1 час 20 минут.

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

Выявленные ошибки

Во время тестирования TATLIN.BACKUP зафиксировали несколько типов ошибок. После анализа, проведенного совместно с производителем, выяснилось, что большинство сбоев связано с ошибками контрольных сумм (CRC) при чтении архивов. Однако мы не склонны винить в них TATLIN.BACKUP. Источником проблем могут оказаться и банальные сетевые неполадки.

Отдельно стоит подсветить лишь некоторые проблемы с NFS. Например, после очистки хранилища по NFS все еще видны резервные копии (хотя по факту все удалено и запущен GC). При этом SMB отображает корректную информацию.

Испытываем T-Boost

В конце сентября производитель выпустил для TATLIN.BACKUP крупный апдейт версии 1.1 с поддержкой нового экспериментального дедупликационного протокола. Основное нововведение в том, что он работает прямо на клиенте.

Такой подход позволяет снизить объем передаваемых данных. Но насколько? И как этот прокол влияет на потребление процессорных мощностей? Мы решили проверить.

Мы активировали технологию T-Boost на TATLIN.BACKUP через интерфейс командной строки и настроили параметры экспорта данных. Развернули отдельную ВМ на AstraLinux 1.7 с ролью узла хранения и клиента с характеристиками 4/16 и добавили: data — локальное хранилище (шара с EG18) и tboost — экспорт vfs при помощи tb_agent.

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

root@cb17sn-astra:/# seq 2 | xargs -P0 -n1 md5sum /dev/zero.

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

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

Далее изменили хранилище на sntest-tboost и запустили резервное копирование повторно:

Статистика по процессам:

Без синтетики:

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

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

Подведем итоги

TATLIN.BACKUP от YADRO показала себя как зрелое решение для резервного копирования данных. Она не уступает западным аналогам, а в некоторых сценариях превосходит их.

Сильные стороны СХД:

• Высокая производительность.

• Эффективная оптимизация данных с высокими коэффициентами дедупликации.

• Стабильная работа под нагрузкой.

• Отличная отказоустойчивость большинства компонентов.

Точки роста:

• Отсутствие поддержки VTL, интеграции с ПО резервного копирования через плагины (только CIFS/NFS, протокол Т-Boost пока работает как файловая система).

• Присутствуют 2 точки отказа: HDD 0 и LCC.

Отдельно отмечу появление протокола T-Boost. Несмотря на экспериментальный статус, он уже показывает результаты на уровне DDBoost от Dell. Не хватает только более глубокой интеграции с ПО для резервного копирования.

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

P.S. Хорошая новость для инженеров по резервному копированию: мы расширяем команду! Если вас увлекает работа с современными системами резервного копирования и хочется создавать технологии будущего, напишите мне в личные сообщения. Кроме того, буду рад ответить на ваши вопросы в комментариях или по электронной почте alzotov@k2.tech. Делитесь своим опытом использования подобных систем — это поможет другим читателям сделать правильный выбор.

Больше про бэкапы и СХД:

Путешествие внутрь YADRO. Часть 1: распаковка и тест-драйв TATLIN.FLEX.ONE

От лент до облаков: какие устройства выбрать для бэкапа и как рассчитать стоимость хранения

От носителей до регламентов: как построить безопасную архитектуру бэкапов