Как и у каждой уважающей себя техподдержки, у инженеров Veeam есть свой список самых популярных поводов позвонить им в любое время дня и ночи. Это и вечно молодое “У вас неправильно работает ретеншн”, и никогда не стареющее “У меня место на дисках кончилось, что делать?”, и прорва других.

Однако среди них есть простой, казалось бы, вопрос. Он объясняется за 5 минут, но вот парадокс: его объяснение вылетает из головы в течение следующих тридцати секунд. Звучит этот чудо-вопрос примерно так: “После бекапа Veeam нарисовал мне непонятный график и написал, что у меня загрузка сорса 63%, прокси 48%, сети 99%, а таргета 0! А потом ещё и обозвал этот сорс ботлнеком, а у меня там ого-го какая железяка! И что вообще означают эти проценты?”

Сегодня объясню в текстовом виде, чтобы было куда возвращаться и перечитывать на досуге.

Bottleneck (бутылочное горлышко, если переводить в лоб) - самая медленная часть вашей бекапной инфраструктуры. Узкое место или слабое звено, если хотите. Тот самый нехороший человек, которого семеро ждать не должны, но получается, что ждут. Если переключиться на более технический язык, то эта та часть инфраструктуры, в которой данные в среднем проводят больше всего времени. То есть обрабатываются дольше всего. Получается, что это чистой воды вопрос производительности (перфоманса, как принято говорить). И знание ответа на этот вопрос позволит нам понять, какую часть в цепочке обработки данных надо ускорить, дабы повысить общую скорость процесса.

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

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

Поэтому давайте немного посмотрим на суть происходящих процессов. Как уже неоднократно говорилось, процесс любого бекапа связан с работой двух агентов: так называемого сорсного и таргетного. Один данные откуда-то читает и передаёт второму, который эти данные куда-то записывает. Если мы говорим про классический бэкап VMware, то сорсной агент читает блоки данных с VMFS, сжимает их при необходимости, дедуплицирует в рамках одного диска, шифрует и пуляет по сети в сторону таргетного агента. Таргетный, в свою очередь, читает данные, прилетающие по сети, сжимает или разжимает их (да, в этом мире всякое может быть), дедуплицирует ещё раз, но уже на уровне разных дисков, и записывает их на диск или шару, именуемые бэкапным репозиторием. И так до конца создания бекапа.

Специфика работы агентов сильно (очень!) различается в зависимости от типа джобы и её настроек, но в упрощённом виде каждый агент делает три последовательных операции: Чтение > Обработка > Запись. Соответственно, нас интересуют четыре метрики, которые могут сильно меняться в зависимости от настроек джобы. Они же и есть те самые ботлнеки:

Source: время, затраченное на получение данных от хоста.
Proxy: время, потраченное на всякие вспомогательные операции на наших прокси, т.е. на дедупликацию, шифрование, сжатие и т.д.
Network: сколько затрачено времени на передачу данных от сорсного агента к таргетному.
Target: как долго мы писали данные в файл бекапа.

Однако, чтобы не усложнять себе жизнь с абсолютными значениями, проще придумать неких “процентных попугаев” - то есть шкалу, где 0% - это практически полное отсутствие загрузки, и 99% - это когда можно шутить про шутер, превратившийся в пошаговую стратегию (то есть данный элемент загружен полностью и тормозит работу остальной системы). Поэтому откровение номер два: ботлнеки измеряются сразу на трёх уровнях: на уровне всей джобы, отдельной таски и так называемых PEX (на всякий случай, это по-английски написано “пекс”).

Джоба

В логах каждой уважающей себя джобы можно найти что-то вроде такого:

[08.10.2020 05:02:37] <01> Info     [JobSession] Completing session '220209b6-8b62-4b0e-b66a-0b55d7dc3c07'
[08.10.2020 05:02:37] <01> Info     Load: Source 78% > Proxy 67% > Network 48% > Target 0%
[08.10.2020 05:02:37] <01> Info     Primary bottleneck: Source
[08.10.2020 05:02:37] <01> Info     Backuped size: 258,3 MB, total backuped size: 84,2 GB
[08.10.2020 05:02:37] <01> Info     Job session '220209b6-8b62-4b0e-b66a-0b55d7dc3c07' has been completed, status: 'Success', '100 GB' of '100 GB' bytes, '1' of '1' tasks, '1' successful, '0' failed, details: '', PointId: [cac85195-54b9-49b4-a8c7-2baaa9bfd607]
[08.10.2020 05:02:37] <01> Info     [BackupJobPostActivity] JobSession '220209b6-8b62-4b0e-b66a-0b55d7dc3c07' PostActivity: 'AskService'

Это самая натуральная средняя температура по больнице, которая высчитывается на основе данных от всех объектов в бекапе. То есть если в рамках одной джобы вы бекапите машину с быстрого хоста и машину с медленного хоста, да ещё и на удалённой площадке, качество этих данных будет примерно никакое. По этому куску лога видно, что бекапится одна машина ('1' of '1' tasks, '1' successful, '0' failed,) и данной статистике можно верить.

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

Тут надо сделать важное отступление, которое называется Veeam Agent for %%%%. В силу особенностей своей работы агенты зачастую неспособны адекватно оценивать возникающие задержки. Так что на данные из их логов нужно смотреть с достаточной долей скепсиса. Например, загрузка прокси — для агента это загрузка CPU на бэкапируемой машине. И что там будет с локальными задачами на момент запуска бэкапа — тайна великая, а проценты загрузки непредсказуемы. А как мы помним, ботлнеком назначается та часть цепочки передачи данных, которая показала наибольшую задержку в процентах.

Возникает вопрос: как именно считается усреднение? Отвечаем: работает принцип наследования.

В рамках джобы усредняется значение всех тасок внутри неё.
В рамках каждой таски усредняются значения по всем дискам машины.
Функции, где нет взаимодействия с машинами (File to Tape, File Copy, Backup Copy etc) считают средние значения для обрабатываемых файлов.

Task

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

[05.10.2020 05:01:49] <06> Info     Using changed block tracking for disk '[vuesx02-ds1] vudc01/vudc01.vmdk'
[05.10.2020 05:01:52] <39> Info                   [AP] (6dea) output: --asyncNtf:disk_capacity: '107374182400'
[05.10.2020 05:01:54] <39> Info                   [AP] (5613) output: --size: 107374182400
[05.10.2020 05:01:54] <26> Info                   [AP] (5613) output: --pex:0;1048576;0;1048576;0;32;98;0;0;0;0;0;132463369144510000
[05.10.2020 05:01:57] <26> Info                   [AP] (5613) output: --asyncNtf:--fsaware_skip:45828014080:0
[05.10.2020 05:01:57] <26> Info     Skipping deleted file blocks: source '5613', message '45828014080:0'
[05.10.2020 05:01:57] <39> Info                   [AP] (ff74) output: --asyncNtf:--fsaware_skip:45828014080:0
[05.10.2020 05:01:57] <26> Info                   [AP] (5613) output: --pex:100;107374182400;591396864;60954771456;591396864;164645529;74;64;44;98;64;0;132463369178880000
[05.10.2020 05:01:59] <12> Info                   [AP] (5613) output: <VCPCommandResult result="true" exception="" />
[05.10.2020 05:01:59] <07> Info                   [AP] (5613) output: <VCPCommandArgs />
[05.10.2020 05:01:59] <07> Info                   [AP] (5613) output: >

Итак, у нас есть интересующая нас строчка: [05.10.2020 05:01:57] <26> Info AP output: --pex:100;107374182400;591396864;60954771456;591396864;164645529;74;64;44;98;64;0;132463369178880000

Давайте разбираться в этом заборе из цифр:

100 – Текущий % переданных данных от объёма диска.
107374182400 – Сколько данных было прочитано и обработано (в байтах)
591396864 – Сколько из них оказалось полезными (не нулями). Тоже в байтах.
60954771456 – Количество пропущенных данных (в байтах)
591396864 – Сколько данных было реально прочитано после пропуска пустых блоков и не изменившихся в соответствии с CBT (тоже в байтах)
164645529 – Количество переданных байт. В нормальных условиях всегда будет меньше, чем количество прочитанных, т.к. передача осуществляется после дедупликации и сжатия.
- 74 – Загрузка сорсного агента при операциях чтения (в %)
- 64 – Загрузка CPU на машине с сорсным агентом (в %) (среднее значение)
- 44 – Загрузка сорсного агента при передаче данных (в %)
- 98 – Загрузка таргетного агента при приёме данных (в %)
- 64 – Загрузка CPU на машине с таргетным агентом (в %) (Среднее значение)
- 0 – Загрузка таргетного агента при операциях записи(в %)
132463369178880000 – Количество затраченного времени

Как мы видим, по сумме значений основным ботлнеком, кажется, получается сорсной агент. Это же будет отображено в интерфейсе. Однако пара значений 44-98 - это сеть между сорсом и таргетом. Поэтому интерпретировать ситуацию надо следующим образом: сеть между сорсом и таргетом весьма медленная относительно возможностей сорса читать, а таргета — записывать. Таргет бы и рад писать больше (у него загрузка 0%), но данные не успевают приходить. Сорсной агент читает данные достаточно близко к своим возможностям (74 и 64), а вот его сеть откровенно бездельничает больше половины времени.

И надо замолвить пару слов про альтернативный формат, который был представлен в Veeam Agent for Linux 3.х. Этот формат для простоты называется pex\vpex:

VPEX формат используется при volume-level бекапе с использованием veeamsnap модуля
PEX формат используется при file-level бэкапах (не важно, с или без veeamsnap модуля) и при работе с BTRFS дисками.

Записи в логах выглядят примерно так:

[14.02.2019 20:39:54] <140192883136256> lpbcore|  vpex: 5498732544/5498732544/0/5498732544/2893106400 / 88/47/10/90/56/9

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

Примеры

Теперь давайте рассмотрим несколько показательных вариантов ботлнеков.

0;12;99;99;0;1 - Сеть с обеих сторон загружена на максимум. Типичная картина при Backup Copy на удалённую площадку. Делаем канал шире или экспериментируем с WAN Accelerator.
0;75;98;98;0;1 - Практически то же самое, только загружен процессор у сорсного агента. Значит, можно попробовать получить прирост за счёт добавления процессорной мощности прокси, и/или выставить режим сжатия послабее. Однако со вторым вариантом есть нюанс — может подскочить нагрузка на сеть, и всё станет хуже, чем было.
0;12;99;0;0;99 – Ботлнек здесь репозиторий. Если в его качестве используется CIFS на удалённой площадке, то первое дело для исправления ситуации — расположить там же таргетный прокси (т.к. при записи на сетевую шару таргетный агент запускается на прокси, а не на самом сервере).
75;56;78;32;16;78 – На первый взгляд кажется, что здесь вся инфраструктура нагружена довольно равномерно. Однако вполне можно обнаружить, что диски могли бы работать быстрее, в то время как мы тратим мощности на какие-то сторонние операции.
99;12;0;0;0;1 – Диски хоста — явный ботлнек. Вернее, не сами диски, а скорость чтения данных. Стоит проверить, в нужном ли месте расположена ваша прокси и в каком режиме она читает данные. Но совсем откидывать версию, что диски фуфло, тоже не стоит ;)
0;0;0;45;90;45 – Прокси на таргете утыкается в процессор. Просто добавь CPU (воды). Типичная картина для больших Full бэкапов.
79;22;85;17;10;95 – А это типичный вид инкрементального бекапа (или реверс-инкремента, не суть) при слабом репозитории. Пока сорс активно читает данные, а сеть их активно передаёт, репозиторий не успевает их записывать.

Инструменты для тестирования инфраструктуры

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

Начнём с начала, то есть с источника данных (аkа сорса). В большинстве случаев это будет VMware или Hyper-V хост. И, само собой, для их тестирования используются разные инструменты.

Когда речь идёт про vSphere, тут лучший тестировочный инструмент — это VixDiskLibSample. Это простенькая C++ программа, идущая в комплекте с VMWare VDDK, которая использует библиотеку vixDiskLib. То есть более корректные результаты, чем она, вряд ли кто покажет. Про эту тулу не так давно была целая статья, так что всем интересующимся обязательно к ознакомлению.

А когда речь заходит про Hyper-V, то тут есть целая россыпь доступных инструментов. Поскольку диски самих машин лежат на обычных виндовых дисках, достаточно будет классического DiskSpd, про использование которого у нас есть отдельная КВ статья. Правда, в ней есть одна то ли бага, то ли военная хитрость — было замечено, что при записи рандомных данных она может генерить, скажем так, недостаточно рандомные данные. Поэтому в отчётах может не сильно, но подвирать.

Другая классика жанра — это iostat и iometer.

Вариантами использования второго уже весь интернет исписан, включая наш блог.
А первый — это просто утилита для мониторинга загруженности дисков, которую достаточно просто запустить.

Причём гонять тесты этими тулами можно смело и на сорсе, и на таргете. Если говорить о предпочтениях, то я бы сказал так: на виндовых машинах с помощью Diskspd хорошо тестировать NFS и SMB шары, а на линуксе есть встроенный dd, которого в большинстве случаев хватает за глаза.

Ещё остаётся вопрос тестирования дедуплицирующих стораджей, но это какой-то ненаучный пласт знаний сродни астрологии. То есть там имеются некие тесты и методики, которые показывают какие-то числа, но верить им или нет — выбор исключительно ваш.

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

На этом на сегодня всё. Следите за нагрузками и да прибудут с вами быстрые бекапы.

Почему твой бекап недостаточно быстр?