В формуле идеального решения для резервного копирования данных enterprise-класса много переменных. Одна из ключевых — производительность решения, включая скорость копирования, нагрузку на сеть и потребление вычислительных ресурсов хранилища и источника данных.
Инженеры компаний YADRO и Киберпротект протестировали совместную работу системы резервного копирования Кибер Бэкап и системы хранения данных TATLIN.BACKUP в трех сценариях сохранения резервных копий виртуальных машин: с inline-дедупликацией, по протоколу NFS и агентом Tboost на узле хранения. Поделимся результатами тестирования совместного решения, а заодно предметно поговорим об организации правильной архитектуры с учетом особенностей конкретной инфраструктуры.
Содержание
Термины и определения в статье
Агент Кибер Бэкапа — модуль, который выполняет основные функции СРК при работе с защищаемыми объектами и резервными копиями:
резервное копирование,
восстановление,
репликация,
очистка хранилищ;
валидация резервных копий,
просмотр хранилищ и устройств защиты,
работа с платформами виртуализации,
работа со снапшотами уровня СХД.
Плагин TBoost — программная часть СХД TATLIN.BACKUP. Он устанавливается на стороне клиента — агента Кибер Бэкапа, который работает с хранилищем резервных копий. Позволяет обмениваться данными с хранилищем в оптимизированном формате по протоколу T-BOOST.
Протокол T-BOOST — протокол работы с хранилищем резервных копий, который выполняет функцию дедупликации и компрессии перед передачей резервных копий в хранилище.
Коротко про систему хранения данных TATLIN.BACKUP
В 2024 году компания YADRO выпустила на рынок специализированную систему хранения данных TATLIN.BACKUP. Это решение с глобальной в рамках СХД inline-дедупликацией и сжатием служит для хранения и восстановления больших массивов резервных копий объемом вплоть до 690 терабайт (до дедупликации и сжатия). Система работает на базе дисковых модулей, контроллера, программного обеспечения и других разработок YADRO, например T-RAID. Команда TATLIN.BACKUP регулярно добавляет новые возможности в СХД, актуальную информацию можно найти на странице продукта.
Как устроен T-RAID — RAID-массив в СХД TATLIN: читайте в статье Вячеслава Пачкова, ведущего инженера по разработке ПО в департаменте СХД YADRO.
В отличие от обычных СХД, TATLIN.BACKUP относится к классу PBBA (Purpose-Built Backup Appliance). Такие устройства созданы специально для работы с резервными копиями и учитывают их специфику. TATLIN.BACKUP можно интегрировать практически с любой популярной системой резервного копирования.
Одна из ключевых особенностей СХД — технология дедупликации с алгоритмом FastCDC, который разбивает данные на блоки переменной длины. Он решает проблему смещения границ (boundary-shift problem) в процессе добавления новых данных в файл. Также алгоритм помогает заметно повысить производительность системы за счет высокой скорости обработки потока байтов.
Дедупликация может выполняться:
На источнике. Данные обрабатываются в режиме реального времени перед передачей по сети на специальном агенте Tboost.
На СХД. Система осуществляет inline-дедупликацию после получения данных по сети.
Последняя версия TATLIN.BACKUP 1.2 с протоколом T-BOOST поддерживает оба типа дедупликации, а 1.1 — только на СХД. Давайте разберемся, чем отличаются эти версии СХД.
TATLIN.BACKUP v1.1. Здесь дедупликация происходит на самом контроллере. Система разбивает все поступающие по сети данные на блоки и ищет их дубликаты среди уже сохраненных.
Дедупликация использует вычислительные мощности контроллера, на который приходят все данные, независимо от их уникальности. Даже если во входящем потоке всего 10% уникальных данных, контроллеру все равно приходится обрабатывать весь поток. Также по сети приходится передавать полный массив данных для обработки, а это увеличивает нагрузку на нее.
TATLIN.BACKUP v1.2. В этой версии реализован протокол T-BOOST, который решает ряд задач. Основная из них — обеспечение inline-дедупликации на машине-хосте, где работает агент Tboost по этому протоколу.
На контроллере TATLIN.BACKUP используется файловая система TBFS с дедупликацией, компрессией и контролем целостности данных. В TBFS встроен сервис Tboost, которые обслуживает запросы агентов Tboost на проверку уникальности и сохранение блоков данных.
Благодаря новому протоколу снижается нагрузка на сеть, поскольку мы передаем только уникальные данные. Сеть разгружается пропорционально доле неуникальных данных в исходном массиве. Также мы разгружаем контроллер, так как дедупликация в случае использования протокола T-BOOST происходит на хосте. Однако работа агента требует достаточной вычислительной мощности от машины, на которой он установлен.
Что такое дедупликация, как она работает в TATLIN.BACKUP и какие задачи решает T-BOOST, читайте в статье.
В новые версии TATLIN.BACKUP мы планируем добавить public Rest API, снапшоты и репликацию данных, а также SDK T-BOOST для удобной интеграции в распространенные системы резервного копирования. Подробнее про развитие системы можно узнать из дорожной карты.
Возможности системы резервного копирования Кибер Бэкап
Кибер Бэкап — система резервного копирования с централизованным управлением, разработанная компанией Киберпротект. Решение подходит как для небольших офисов, так и для крупных компаний.
СРК обеспечивает резервное копирование и восстановление систем разных типов: физических и виртуальных машин, приложений, а также баз данных.
Помимо резервного копирования и восстановления, СРК включает ряд дополнительных функций. Сюда относятся механизмы управления нагрузкой и обеспечение возможности восстановления данных: в том числе механизмы репликации резервных копий, которые позволяют реализовать правило 3–2–1, а также функции проверки резервных копий на возможность восстановления из них.
Кибер Бэкап поддерживает отечественные и зарубежные системы: проприетарные и свободно распространяемые. Экосистема технологических партнеров, в которую входит и компания YADRO, позволяет обеспечивать совместимость с наиболее востребованными российскими операционными системами, платформами виртуализации, СУБД, приложениями, облачными средами и аппаратными комплексами.
Кибер Бэкап позволяет выполнять резервное копирование операционных систем, дисков, томов, папок и файлов на серверах и рабочих станциях под управлением Windows или Linux, включая наиболее распространенные российские дистрибутивы. Согласованность данных и оптимизации использования ресурсов достигается поддержкой создания моментальных снимков с использованием VSS для Windows или LVM Snapshot и Snap API для Linux.
СРК умеет защищать платформы виртуализации как на уровне гипервизора, в безагентном режиме, так и с помощью агентов, которые устанавливаются внутри гостевых ОС виртуальных машин.
Защита СУБД может быть реализована агентами, которые обеспечивают максимальное взаимодействие с сервером СУБД, использовать API и библиотеки вендора. Резервное копирование с поддержкой приложений нужно для того, чтобы обеспечить возможность восстановления данных без восстановления всей машины. Более подробно о защите СУБД мы уже писали, как и о реализации поддержки PostgreSQL.
Кибер Бэкап обеспечивает резервное копирование и гранулярное восстановление данных отечественных и зарубежных бизнес-приложений. Для этого используются специальные агенты, которые устанавливаются на хост почтового сервера или на удаленный хост.
О ключевых новинках в Кибер Бэкапе 17.2 читайте в статье, а в этой публикации вы найдете обзор возможностей версии 17.1. Узнать о новых возможностях Кибер Бэкапа 17.3 можно на вебинаре, который пройдет 17 апреля.
Интеграция TATLIN.BACKUP и Кибер Бэкап
Интеграция СРК Кибер Бэкап с TATLIN.BACKUP предназначена для разделения обязанностей и максимального использования плюсов каждой системы. Архитектурно правильное решение — поручить СРК управлять процессом резервного копирования/восстановления (оркестрация задач, планирование, чтение защищаемых данных и формирование архивов, которые будут размещены на системе хранения, слежение за версиями) и обеспечивать консистентность данных, например, создавать согласованные снапшоты баз данных или виртуальных машин. Хранение больших объемов резервных копий лучше доверить специализированному хранилищу. Такой подход позволяет достичь баланса: СРК будет сфокусирована на корректном создании резервных копий, а СХД — на их надежном хранении, дедупликации и компрессии.
Три сценария резервного копирования
Инженеры Киберпротекта и YADRO протестировали три сценария совместной работы решений. Два из них различаются способом использования протокола T‑BOOST, а в третьем протокол не используется. Все сценарии работоспособны, что подтверждает сертификат совместимости.
Сценарий 1. Стандартный режим с NFS-сервером: протокол T‑BOOST не используется
В этом сценарии данные без сжатия передаются по сети в хранилище TATLIN.BACKUP, где происходит дедупликация и компрессия. Этот сценарий подходит для случаев, когда нужно сберечь вычислительные ресурсы хоста: CPU и RAM, требуемые агенту Tboost для дедупликации и компрессии данных.
Особенность такого сценария — существенная нагрузка на сеть, ведь по ней передаются неуникальные и несжатые данные. Также контроллер TATLIN.BACKUP использует собственные вычислительные ресурсы для дедупликации и компрессии.
Сценарий 2. Дедупликация на источниках: агент Tboost работает на защищаемых хостах
Дедупликация и компрессия производятся на хостах с агентом Кибер Бэкапа, вычислительной мощности которых достаточно для корректной работы агента Tboost.
Этот сценарий позволяет:
снизить нагрузку на сеть; в хранилище передаются только уникальные и сжатые данные, а вместо уже записанных блоков передаются только их метаданные,
освободить вычислительные мощности контроллера TATLIN.BACKUP переносом выполнения задач дедупликации и сжатия на хост.
Сценарий 3. Агент Tboost установлен на узлах хранения Кибер Бэкапа
Это гибридный сценарий, который позволяет сэкономить вычислительные ресурсы защищаемого хоста и снизить нагрузку на сеть: в хранилище передаются только уникальные данные.
Резервные копии в полном объеме передаются по протоколам SMB/CIFS или NFS на локальный узел хранения, где установлен агент Tboost. Он выполняет дедупликацию и компрессию полученных данных, используя вычислительных мощности узла хранения. Затем сжатые и дедуплицированные данные передаются в хранилище TATLIN.BACKUP.
Сценарий помогает сберечь вычислительные ресурсы хоста и контроллера TATLIN.BACKUP, а также снизить нагрузку на сеть.
Как мы уже указывали выше, влияние inline-дедупликации на сетевую нагрузку и вычислительные мощности при использовании протокола T-BOOST зависит от доли неуникальных данных.
Тестирование вариантов организации резервного копирования виртуальных машин
Для оценки производительности резервного копирования специалисты YADRO и Киберпротекта развернули тестовый стенд на базе СРК Кибер Бэкап 17.2 и СХД TATLIN.BACKUP.M с протоколом T‑BOOST. Протестированы три сценария организации резервного копирования ВМ, в одном из которых реализованы два варианта на узлах хранения.
Для каждого сценария рассмотрим архитектуру и параметры стенда, объем переданных данных, время создания резервной копии и проанализируем причины отличий — узкие места и влияние нагрузки.
Конфигурация тестового стенда
Аппаратная часть
В качестве инфраструктуры использовали четыре сервера ESX, которые обозначены как ESX1–ESX4. Первичное хранилище для рабочих дисков виртуальных машин — система TATLIN.UNIFIED с пулом SSD, подключенная по iSCSI через 4×25 Гбит/с Ethernet.
Подключение каждого логического диска LUN`а с СХД к хостам виртуализации выполнено по 8 путям с режимом балансировки Round Robin чтобы обеспечить эффективное распределение I/O по всем 25-гигабитным каналам. Целевое хранилище для резервных копий — TATLIN.BACKUP с поддержкой дедупликации. У хранилища есть агрегированный канал 4×25 Гбит/с, при этом интерфейсы объединены в bond, суммарно до 100 Гбит/с.
Скрытый текст
Тестовый стенд
Для оценки результатов интеграции КиберБэкапа и TATLIN.BACKUP инженеры выбрали конфигурацию стенда, которая наиболее распространена у заказчиков — виртуальные машины на базе гипервизора VMware.
На каждом из четырех серверов ESX развернуто 8 тестовых виртуальных машин — итого их 32. Конфигурация каждой: 8 vCPU, 8 ГБ RAM и два диска — системный диск на 20 ГБ и дополнительный сгенерированный диск на 209 ГБ. Виртуальные машины размещены в хранилище на томах с TATLIN.UNIFIED и SSD POOL для обеспечения высокой скорости чтения.
Скрытый текст
Серверы ESX:
ESX1.kb.lab — VEGMAN R120 G2 Server / 021123063C,
ESX2.kb.lab — VEGMAN R120 G2 Server / 0212230150,
ESX3.kb.lab — VEGMAN S220 Server / 020421002D,
ESX4.kb.lab — Server YADRO X2-105 / 010523006B.
ПО для резервного копирования
В качестве системы управления резервным копированием использовали Кибер Бэкап 17.2, развернутый в виртуальной машине с 16 vCPU и 32 ГБ RAM. Для сценариев с узлами хранения использовали узел хранения также в виртуальной машине — 16 vCPU, 32 ГБ RAM с ОС Linux и сетевым адаптером VMXNET3. На нее установили агент Кибер Бэкап и агент Tboost v1.2.1 (настроен open_direct_io_mode=true).
В сценариях могут использоваться один или несколько таких узлов. Сеть передачи данных — 25 Гбит/с Ethernet. Для всех ВМ активирован драйвер VMXNET3, чтобы устранить возможные ограничения пропускной способности виртуального NIC.
Резервное копирование по протоколу NFS
В этом сценарии в качестве целевого хранилища выступает сервер TATLIN.BACKUP, который подключен по протоколу NFS. В Кибер Бэкапе сконфигурировано четыре NFS-хранилища и настроены четыре плана резервного копирования, как и в первом сценарии: для каждой группы из 8 ВМ на своем NFS-ресурсе. Агенты Tboost в данном сценарии не используются — передача данных осуществляется напрямую с хостов через NFS, то есть без дедупликации на источнике.
Скрытый текст
Результаты
Объем переданных Кибер Бэкапом данных:
резервная копия каждой ВМ занимает в среднем 131 ГБ,
четыре операции резервного копирования — по 8*131*4 = ~ 4 192 ГБ.
Итого: полное копирование ~ 4 192 ГБ за 15–16 минут. Резервные копии создавались консистентно на уровне ВМ.
Резервное копирование с помощью агента Кибер Бэкапа и агента Tboost внутри виртуальной машины
В этом сценарии выполняется резервное копирование с дедупликацией на лету внутри каждой ВМ. В каждую из 32 виртуальных машин установлены агенты Кибер Бэкапа, а также агенты Tboost. Каждый агент сохраняет резервную копию в локальную папку, подключенную к целевому хранилищу через T‑BOOST (точка монтирования /mnt/esxboost). В качестве хранилища резервных копий в Кибер Бэкапе указано 32 хранилища — по числу ВМ.
Для упрощения администрирования использован один план резервного копирования, включающий все машины. При его запуске бэкап выполняется параллельно для всех 32 ВМ.
Скрытый текст
Результаты
График показывает, что мы достигли ограничений оборудования: пропускной способности четырех портов Ethernet по 25 Гбит/с, через которые подключен диск TATLIN.UNIFIED к хостам виртуализации.
Совокупный объем данных, переданных Кибер Бэкапом для полного резервного копирования всех ВМ, аналогичен первому сценарию: ~ 4 192 ГБ (32 × 131 ГБ).
Параллельно выполнялись 32 операции резервного копирования. Время выполнения операций составило от 8 до 11 минут.
Скрытый текст
Итого: полное копирование ~ 4 192 ГБ за 11 минут. Резервные копии создавались консистентно на уровне ОС.
Два варианта организации резервного копирования на узлах хранения в виртуальной машине
В этом сценарии агент Tboost установлен на узлах хранения Кибер Бэкапа:
вариант 1: четыре узла хранения, которые установлены внутри виртуальных машин — на каждом хосте ESXi поднят свой узел хранения с агентом Tboost для резервного копирования ВМ этого хоста,
вариант 2: один узел хранения на все ВМ — все ВМ копируются через единый узел хранения, установленный внутри виртуальной машины с агентом Tboost и один поток на хранилище.
Вариант 1. Резервное копирование с помощью Virtual Appliance (агента Кибер Бэкапа для среды виртуализации) и узлов хранения в виртуальной машине
В этом варианте для каждого хоста ESX выделен свой узел хранения в виртуальной машине с агентом Tboost. В консоли управления Кибер Бэкап настроено 4 хранилища (каждое — на соответствующем узле хранения) и создано 4 плана резервного копирования — по одному на каждый хост ESX. Таким образом, резервные копии ВМ на каждом хосте отправляются на свой узел хранения. Расписание настроено так, чтобы все четыре плана резервного копирования запускались одновременно, суммарно выполняя параллельное копирование сразу 32 ВМ (по 8 потоков через каждый узел хранения).
Скрытый текст
Результаты
В этом сценарии тест также показал, что мы уперлись в ограничение оборудования: пропускную способности четырех портов Ethernet по 25 Гбит/с.
Скрытый текст
резервная копия каждой ВМ занимает в среднем 131 ГБ,
с одного хоста ESX передается 8*~131 = ~1 048 ГБ,
с четырех хостов ESX передается 32*~131 = ~4 192 ГБ.
Итого: полное копирование ~4 192 ГБ (32 ВМ) заняло 16 минут. Резервные копии создавались консистентно на уровне ВМ.
Вариант 2. Резервное копирование с помощью Virtual Appliance (агента Кибер Бэкапа для среды виртуализации) и одного узла хранения в виртуальной машине
В этом сценарии задействован единственный узел хранения в виртуальной машине с T‑BOOST, общий для всех хостов. В плане резервного копирования указано одно хранилище на базе этой ВМ. Один план резервного копирования, включающий все 32 ВМ, направляет потоки данных на данный узел. План запускается с максимальным параллелизмом (32 потока через один узел).
Скрытый текст
Результаты
Объем переданных Кибер Бэкапом данных:
резервная копия каждой ВМ занимает в среднем 131 ГБ,
с четырех хостов ESX передается 32*~131 = ~4 192 ГБ.
Скрытый текст
Итого: полное копирование ~4 192 ГБ за 32 минуты. Резервные копии создавались консистентно на уровне ВМ.
Заключение
Как видно из результатов тестов, совместное использование TATLIN.BACKUP с T‑BOOST и Кибер Бэкапа 17.2 позволяет эффективно обрабатывать резервные копии размером в несколько терабайт за минуты, при условии правильной организации архитектуры.
Выводы, которые мы сделали из результатов тестов:
тесты хорошо отработали в конфигурации с использованием отдельного узла хранения с установкой агента Tboost на каждый сервер виртуализации,
наилучший результат тесты показали при установке агента Tboost на каждый виртуальный сервер, но этот сценарий достаточно сложный с точки зрения администрирования,
наконец, сценарий, который позволит вам получить ускорение в обработке резервных копий и сократить расходы на их хранение без существенного усложнения администрирования системы — использование одного узла хранения и установка агента Tboost на несколько серверов виртуализации.
Для достижения наилучших результатов следует соотнести выбранный сценарий копирования с возможностями сети и сервера. Распределяя потоки между узлами или агентами, мы устраняем узкие места и добиваемся оптимальной скорости без избыточной нагрузки на отдельные компоненты системы. Такой подход позволяет подобрать решение под требования конкретной инфраструктуры, чтобы обеспечить как высокую скорость резервного копирования, так и рациональное использование ресурсов.
Киберпротект и YADRO продолжают работать над повышением функциональности и производительности совместного решения. У нас уже есть внутренние планы по развитию, которые гарантировано приведут к улучшениям в будущих версиях продуктов. Следите за нашими материалами и анонсами.
10 апреля совместно с компанией Киберпротект мы провели вебинар, на котором рассказали о возможностях СРК Кибер Бэкап и СХД TATLIN.BACKUP, сценариях совместного использования продуктов и продемонстрировали резервное копирование средствами Кибер Бэкапа на TATLIN.BACKUP с использованием технологии T-BOOST. Чтобы узнать больше, смотрите запись вебинара.
