Как ускорить бэкап и сэкономить место на сторадже: на примере ArenadataDB ddboost и СХД Dell EMC Data Domain

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

Несколько запусков этой утилиты на тестовой среде позволили определить целевые показатели по скорости записи (см. таблицу ниже).

Результаты синтетических тестов показали, что наибольшая скорость достигалась при определенной комбинации параметров: тестовый файл в 1 ГБ и 20 потоков. В 30 потоков скорость уже ощутимо меньше — на уровне 10 потоков.

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

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

Изолированный тест — это тестовая передача данных напрямую в систему хранения данных через плагин без обработки и передачи данных со стороны gpbackup (таких как подготовка данных таблиц с последующей передачей через стандартный ввод/вывод в плагин и тому подобное).

Идея теста заключается в проверке "чистой" производительности с исключением потенциального влияния операций, производимых утилитой gpbackup. Тестовый поток для данного теста представляет собой сгенерированные случайным образом двоичные данные (итоговый объем данных для записи — 200 ГБ одним файлом или разделенным на отдельные части, но таким же объемом). Эти данные перенаправляются напрямую через стандартный ввод/вывод в плагин. Схожим образом с плагинами работают gpbackup и gprestore.

Несколько запусков этого теста позволили определить следующие показатели скорости записи.

Один сервер — один поток

Показатель скорости записи в один поток в среднем составляет ~150 МБ/сек, итоговое время передачи 200 ГБ — ~22 минуты.

 
Один сервер — десять потоков

Из графика на приведенном выше рисунке видно, что при параллельной передаче с одного хоста десяти файлов скорость в среднем была чуть выше 1 ГБ/сек и по мере завершения отправки отдельных частей она снижалась. Итоговое время передачи 200 ГБ составило ~3.5 минуты.

В целом по мере завершения отправки отдельных частей падение общей скорости отправки чуть больше, чем обеспечивало одно соединение в единичном тесте. Например, для двух файлов можно было бы ожидать скорость порядка 300 МБ/сек, по факту видим ~235 МБ/сек. Возможно, это связано с пулом внутренних потоков библиотеки DD Boost и тем, как происходит распределение полосы пропускания между потоками внутри библиотеки.

 
Один сервер — двадцать потоков

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

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

Скорость записи в целом совпадает со скоростью в десять потоков с одного сервера, которую мы увидели в результатах на предыдущих тестах (~1.1 ГБ/сек). С двух серверов в среднем получили ~2 ГБ/сек на запись.

Суммарное значение скорости 2.2 ГБ/сек чуть выше, чем на двадцати соединениях с двух серверов, но уже можно предположить, что, начиная с четырех серверов, виден максимум на запись со стороны системы хранения и дедупликации. Скорость в пиках примерно соответствует максимуму, который достигается с 1-2 серверов, но в среднем видно, что полоса пропускания уже разделяется между всеми сорока соединениями с четырех серверов — по ~550 МБ/сек с сервера.

Дальнейшее падение скорости на запись с одного сервера при аналогичной общей скорости на запись (2.2 ГБ/сек) косвенно подтверждает гипотезу о максимуме на запись со стороны системы хранения и дедупликации. В подтверждение этой гипотезы говорит тот факт, что на синтетических тестах утилитой ddpconnchk со схожими параметрами (30 соединений/потоков) получен в целом аналогичный результат по максимальной скорости на запись (2560.00 МБ/сек).

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

Для серии итоговых тестов конфигурация тестового окружения была следующей:

Серия тестов производительности включала в себя:

* Объем фактически передаваемых данных на 30-40% больше из-за необходимости преобразования в CSV-формат.

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

Также были проведены несколько референсных тестов резервного копирования на локальную файловую систему с использованием плагина (8) и без (9), а также серия тестов локальных бэкапов (10-17) с различными настройками длины очереди подготовки таблиц к резервному копированию (copy-queue-size).

Выводы по проведенным тестам:

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

На рисунке ниже представлен график копирования данных одним из сегмент-хостов.