Системы хранения данных и резервного копирования часто выпускают разные вендоры, поэтому основная задача специалистов — обеспечить бесперебойную работу и выжать максимум скорости из тандема. Чем быстрее данные резервируются и восстанавливаются, тем лучше для бизнеса. В статье расскажем, как лучше всего настроить связку «Бересты» с системой хранения данных TATLIN.BACKUP под конкретные сценарии.
Архитектура интеграции
К TATLIN.BACKUP со стороны процессов «Береста» есть три режима доступа. Они позволяют выбрать оптимальный вариант для различных задач и сценариев развертывания (названия режимов приводятся в типах, которые определены в ПО «Береста).
TBFS — виртуальные файловые системы (VFS) c устройств TATLIN.BACKUP монтируются на cиловых серверах «Береста» по протоколу NFS. Для работы в этом режиме нужно установить на них NFS Client. Этот режим был первым шагом интеграции, и сейчас в основном может использоваться для работы устройств TATLIN.BACKUP без ПО «Береста» в автономном режиме.
TBOOST — режим подключения с монтированием виртуальных файловых систем TATLIN.BACKUP на cиловых серверах «Береста» с использованием программного модуля tb_agent, который использует технологию FUSE для доступа к VFS. Для работы в этом режиме необходимо установить на серверах пакет tb_agent.
Процессы дедупликации данных перенесены на источник: cиловой сервер «Береста», который также может быть установлен вместе с агентом «Береста» на прикладном сервере. Так можно повысить агрегированную пропускную способность работы с устройствами TATLIN.BACKUP за счет использования вычислительных ресурсов сервера и снизить требован��я к сетевой инфраструктуре для подключения серверов к системе хранения данных.
Этот режим является логичной альтернативой TBFS (NFS) с переносом функций по дедупликации потоков данных на уровень cиловых серверов. Параметры доступа к TATLIN.BACKUP определяются в одном экземпляре и разделяются между процессами на всех силовых серверах (режим доступа shared, то есть разделяемый).
Подробнее об архитектуре TATLIN.BACKUP можно прочитать в статье о создании дедуплицирующей файловой системы для СХД с нуля.
TBOOSTAPI — режим работы с виртуальными файловыми системами TATLIN.BACKUP за счет использования его программных библиотек TBoost SDK, встроенных в процессы силовых серверов «Береста». Этот режим работы — полный аналог технологий EMC DataDomain DDBoost или HPE StoreOnce (протокол Catalyst) для использования дедупликации на стороне процессов системы резервного копирования и восстановления данных (СРКиВД). Приоритетный для использования в ПО «Береста».
Ключевые преимущества:
дедупликация на источниках;
отсутствие точек монтирования, то есть прямого доступа к виртуальным файловым системам, защищает данные от повреждения даже при компрометации операционной системы;
режим не требует установки дополнительных агентов или клиентов (NFS Client, tb_agent).
Параметры доступа к TATLIN.BACKUP определяются в одном экземпляре и разделяются между процессами на всех силовых серверах.
Режимы работы и функционал ПО «Береста» и TATLIN.BACKUP:
Функционал | TBFS | T-BOOST | T-BOOSTAPI |
Подключение | NFS | TB_AGENT | SDK |
Дедупликация | На устройстве | На источнике | На источнике |
Доступность | NFS mount | FUSE mount | TCP (без mount) |
Уровень защиты | средний | средний | максимальный |
Как добавить устройства TATLIN.BACKUP
Настройка интеграции и добавление устройств TATLIN.BACKUP полностью реализовано в веб-интерфейс ПО «Береста» через визард создания нового устройства. Доступные типы подключения (режим работы) к устройствам TATLIN.BACKUP в веб-интерфейсе «Береста» при создании нового устройства:
На следующем шаге создания устройства назначаются разные параметры доступа. Основные:
URL управления: адрес для получения статистики – объем, коэффициенты дедупликации и сжатия. Адрес может отличаться от адреса, который используется для передачи данных.
Адрес TBoost: для чтения-записи с устройства TATLIN.BACKUP по протоколу T-BOOST.
Пользователь TBoost: для получения статистики с устройств TATLIN.BACKUP.
Токен TBoost: для работы по протоколу T-BOOST.
Последний шаг создания устройства — определить зоны доступности. Они нужны для разграничения доступа множества силовых серверов к устройствам TATLIN.BACKUP. За счет этого функционала можно определить группу серверов, которым разрешается чтение-запись на ресурсы TATLIN.BACKUP c использованием заданных параметров доступа (TBoost token).
В результате в списке устройств ПО «Береста» появляются устройства TATLIN.BACKUP, доступные для хранения резервных копий (в нашем примере созданы два устройства, подключенные в режимах TBOOST и TBOOSTAPI):
Дополнительные функции
Важная особенность интеграции — возможность прямого резервного копирования и восстановления данных на устройства TATLIN.BACKUP напрямую с прикладных серверов, то есть клиентов СРКиВД. Для этого после создания устройства достаточно установить агента и силовой сервер ПО «Береста» на прикладные хосты и добавить силовой сервер в «Зону доступности», включающую устройство TATLIN.BACKUP.
Для того, чтобы изолировать силовой сервер, установленный на прикладном хосте, от трафика РКиВД других агентов, в свойствах силового сервера прикладного хоста необходимо установить режим «Только для локальных агентов»:
Также интеграция поддерживает назначение лимитов свободной емкости для своевременного планирования доступных объемов на устройствах TATLIN.BACKUP и автоматическое переключение заданий резервного копирования на устройства со свободными емкостями.
Дополнительный функционал ПО «Береста» — ограничение (троттлинг) скорости удаления резервных копий после истечения срока хранения для «размазывания» нагрузки процессов garbage collection (сборки мусора) во времени и минимизации их влияния на приоритетные операции чтения-записи:
Централизованное управление и безопасность
Интеграция решений TATLIN.BACKUP и «Береста» построена по принципу настройки и управления из единого веб-интерфейса максимально нативным способом. «Береста» работает с TATLIN.BACKUP через специальный тип устройства, а не как с файловой системой. При этом не нужны «костыли» для подготовки необходимых точек монтирования на хостах СРКиВД или запуска дополнительных служебных скриптов для получения необходимой информации. Так, для получения списка всех резервных копий, хранящихся на определенном устройстве, достаточно выбрать опцию «Резервные копии»:
Параметры доступности и текущую статистику работы с устройством можно посмотреть в веб-интерфейсе в виде счетчиков реального времени (эта статистика также доступна в Rest API «Береста» для интеграции с системами мониторинга):
В случае потери метаданных по резервным копиям, которые хранятся на устройствах TATLIN.BACKUP, у ПО «Береста» есть функционал по автоматической инвентаризации устройства и воссозданию метаданных по резервным копиям с использованием опции «Инвентаризация»:
В рамках повышения безопасности и защиты от шифровальщиков в интеграции реализован режим «Карантин» (LockDown) — специальный режим работы, который со стороны ПО «Береста» активирует функционал регулярного создания снапшотов на уровне VFS TATLIN.BACKUP, блокирующий любые несанкционированные изменения в резервных копиях, обеспечивая надежную защиту и возможность восстановления в случае порчи исходной VFS.
В TATLIN.BACKUP реализованы снапшоты трех типов:
basic — управляются администратором, можно задавать срок жизни (retention) на каждый снимок;
secure — разрешение удалить выдает только специальный пользователь с ролью Security;
locked — снимок невозможно удалить или изменить, до истечения срока хранения.
Как реализованы снапшоты в TATLIN.BACKUP — читайте в статье Ростислава Ефремова, эксперта по разработке ПО отдела систем обработки данных в YADRO.
Тестируем производительность
Рассмотрим вопросы производительности при использовании устройств TATLIN.BACKUP в качестве устройств хранения резервных копий в ПО «Береста».
В качестве стендового оборудования используется устройство TATLIN.BACKUP с прошивкой v1.3.2-17-507a567, подключенное к инфраструктуре ПО «Береста» по двум сетевым интерфейсам 25 GbE (LACP Layer2+3). На устройстве созданы две тестовые VFS (testfs11, testfs12), доступные по протоколу TBoost.
Клиентами (аналог прикладных хостов) выступают два сервера (Ubuntu 22.04) с такими ресурсами:
Дисклеймер: Все показатели производительности зафиксированы на тестовых стендах в средней аппаратной конфигурации. При увеличении количества ресурсов, а именно — использовании более мощных инициаторов или максимальной конфигурации TATLIN.BACKUP показатели скорости могут быть выше.
Тестирование производительности будем проводить на основе потокового файлового резервного копирования, которое доступно после установки агента «Береста» на прикладной хост.
Начнем с резервного копирования данных на сервере user (физический хост). Для снятия ограничений по производительности блочных устройств, в качестве источника данных используется файловая система на базе ramfs (точка монтирования /data), в которой создан набор данных объемом 195,3 ГБ, которое содержит микс файлов, сгенерированных из /dev/urandom. Резервное копирование протестируем на устройстве TATLIN.BACKUP, которое подключено в режиме TBOOSTAPI (через TBoost SDK).
Ключевым преимуществом ПО «Береста» является возможность многопоточной передачи данных при резервном копировании и восстановлении данных. При этом для любого типа источника данных агент ПО «Береста» автоматически делит исходный объект копирования на равные (по объему и количеству файлов) потоки.
Запустим резервное копирования объекта /data в один поток:
Средняя скорость резервного копирования в один поток составила 141,9 МБ/с, общее время выполнения задания 23 мин 29 секунд. Вряд ли такие показатели кого-то устроят, а такие скорости — это удел СРКиВД, которые работают в однопоточном режиме.
Увеличим количество потоков до четырех и повторим задание на резервное копирование того же объекта:
Средняя скорость резервного копирования в четыре потока составила 709,8 МБ/с, а общее время выполнения задания сократилось до 4 мин 41 секунд. К слову, в этом — одно из главных преимуществ решения на рынке СРКиВД: оно обладает способностью параллелизации на всех слоях передачи данных (мультипроцессинг, мультитрединг, использование отдельных сетевых соединений для каждого потока данных и функционалом автоматического деления исходного набора данных на потоки). Однако полученная скорость также не позволяет передавать в окне резервного копирования значительные объемы данных: более 20 ТБ за 8 часов.
Увеличим количество потоков до 32-х и повторим тест:
Cредняя скорость резервного копирования в 32 потока составила 2,4 ГБ/с, общее время выполнения задания сократилось до 1 мин 22 секунд.
Увеличим количество потоков до 128 и повторим тест:
Два последовательно запущенных задания на резервное копирования не показали существенного прироста в скорости передачи данных: пиковые показатели и насыщение происходит примерно на 32-х потоках.
Отключим шифрование при передаче данных между силовым сервером и агентом «Береста» для оценки влияния на пропускную способность:
Cредняя скорость резервного копирования в 32 потока увеличилась до 2,7 ГБ/с, а общее время выполнения задания сократилось до 1 мин 13 секунд.
Посмотрим на график передачи данных последнего задания: скорость передачи данных в среднем составила 3,5–3,7 ГБ/с.
Такие результаты скорости передачи данных в рамках одного задания на одну VFS позволяют передавать 11,8 ТБ/ч, что, с нашей точки зрения, — хороший показатель.
Средняя скорость всего задания уменьшается до 2,7 ГБ/с за счет 8–10 секунд, которые уходят на подготовку и корректное завершения задания служебными процессами (включая подзадачу на автоматическое деление исходного набора данных на равные части). С увеличением объема исходных данных длительность этих о��ераций будет оказывать меньшее влияние на среднюю скорость выполнения задания в целом.
Теперь проверим скорость передачи данных на восстановление данных. Оно по умолчанию происходит с тем же количеством потоков, с которым выполнялось резервное копирование, то есть 32 потока:
Средняя скорость восстановления данных в 32 потока составила до 2,1 ГБ/с, а общее время выполнения задания — 1 мин 34 секунды. Ожидаемо, учитывая необходимость регидрации данных.
На графике выше видно, что реальная скорость передачи данных с устройства TATLIN.BACKUP на клиента составляла порядка 3–3,2 ГБ/c. Показатели также собраны с отключенным шифрованием, что в среднем на 10% повышает скорость передачи данных.
Сводная таблица результатов тестирования:
Операция | Время | Средняя скорость | Скорость передачи |
Резервное копирование (1 поток, 1xVFS, шифрование включено) | 23 мин 29 сек | 141,9 MБ/c | 218,4 MБ/c |
Резервное копирование (4 потока, 1xVFS, шифрование включено) | 4 мин 41 сек | 709,8 MБ/c | 880 МБ/c |
Резервное копирование (32 потока, 1xVFS, шифрование включено) | 1 мин 22 сек | 2,4 ГБ/c | 3,3 ГБ/c |
Резервное копирование (128 потоков, 1xVFS, шифрование включено) | 1 мин 18 сек | 2,5 ГБ/c | 3,4 ГБ/c |
Резервное копирование (32 потока, 1xVFS, шифрование выключено) | 1 мин 13 сек | 2,7 ГБ/c | 3,6 ГБ/c |
Восстановление данных (32 потока, 1xVFS, шифрование выключено) | 1 мин 34 сек | 2,1 ГБ/c | 3,1 ГБ/c |
В итоге подключение через TBOOSTAPI — наиболее приоритетный способ, так как позволяет достичь наибольшей производительности.
Планы по развитию
В дальнейшем мы сосредоточимся на следующих направлениях улучшения интеграции TATLIN.BACKUP и ПО «Береста»:
поддержка сквозной дедупликации при репликации резервных копий между устройствами TATLIN.BACKUP,
поддержка режима TBOOSTAPI over FC и WORM,
продолжение работы по оптимизации производительности в режиме TBOOSTAPI.
Если у вас есть вопросы — пишите в комментариях, с удовольствием ответим.
