Veeam Enterprise Manager: ускоряем задания тенантов
Я стал редко рассказывать о кейсах, с которыми сталкиваюсь по своей работе. Проблема не в том, что их нет, а в том, что среди них нет ничего интересно или полезного для всех. Но на днях я столкнулся с проблемой скорости, которая затрагивает всех, и о решении которой (как, возможно, и о самой проблеме) знают не все.
ps 2021-10-04: вышла официальная KB4217
Начну с самого начала: заказчик хочет самостоятельно делать резервное копирование VM, которые находятся под его управлением в vCloud Director. Здесь проблем нет, Veeam предоставляет такой функционал посредствам self-service портала, входящего в Veeam Enterprise Manager. Создаём в Veeam Enterprise Manager соответствующего тенанта с квотой и полным доступом и передаём управление заказчику. Он самостоятельно создаёт задания, прикручивает к ним расписание и всё работает. Через пару дней работы решил оценить статистику и был очень удивлён крайне низкому processing rate и рваному графику (к сожалению, в history Veeam не показывает график, а скриншота у меня не сохранилось, поэтому только статистика).
Я понимаю, что для нашей конфигурации — это очень низкая скорость. Свежая инсталляция Veeam Backup & Replication 10 (но на тот момент ещё без второго патча, но это не важно) и Veeam Enterprise Manager, быстрая продуктивная СХД с низкой нагрузкой и быстрая СХД под бекапы, так же с низкой загруженностью и физический прокси для бекапа по SAN. Прокси имеет 16 ядер, так что в 16 потоков скорость записи должна быть просто отличная, а мы имеем по 10-12МБ/с на диск, и при этом Veeam считает узким местом именно целевую СХД. Я стал разбираться в инфраструктуре, с СХД, сервером и сетью, но не смог найти ничего, что бы могло негативно влиять на скорость. Я стал думать — по сути задание, созданное через self-service портал — это самое обычное задание VBR, с теми же дефолтными настройками, может ли что-то влиять на уровне самого Veeam? Задавшись этим вопросом, я создал точно такое же тестовое задание, но уже через консоль самого VBR…и получил processing rate на уровне 800МБ/с. Чем же эти задания могут отличаться? Я вспомнил только об одном — настройки квоты для тенанта. В документации я не нашёл описания, как именно работает механизм квотирования и, собственно, со своей этой информацией и логами обоих заданий, отправился в саппорт. А саппорт при помощи логов уже подтвердил мою теорию:
Storage size quota exceeded. Waiting for quota increase. Wait timeout: [3600] seconds.
Собственно, что происходит — во время работы задания и записи на бекапа на таргет, VBR выдаёт этому заданию (а он знает, что это задание с self-service портала) квоту в 512МБ раз в 10 секунд. Соответственно, если у нас низкая скорость чтения на сорсе, то этого можно и не заметить, но на высоких скоростях такой механизм квотирования является узким местом. При этом квотирование для тенанта на уровне Enterprise Manager отключить нельзя.
Теперь у нас есть 2 варианта:
1 — если у вас всё ещё VBR 9.5: можно увеличить размер квоты, который VBR выдаёт для задания:
Путь: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Тип: REG_DWORD
Имя: VcdBackupQuantSizeMb
Default value: 512
мы попробовали значение в 4096 и получили processing rate на уровне 600МБ/с
2 — если вы уже обновились до VBR10: можно изменить механизм работы выделения квоты в котором агент, отвечающий за запись данных на таргет, будет сам запрашивать необходимые ему ресурсы:
Путь: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Name: CloudConnectQuotaAllocationMode
Type: DWORD
Value: 1
второй вариант дал больший результат и мы получили processing rate на уровне 800МБ/с
Вот такая небольшая история, которая, надеюсь, окажется полезна тем, кто использует self-service портал и, возможно, даже не задумывался, что его задания могут выполняться быстрее.
