Ребята, спасибо за выпуск Proxmox Backup Server! PBS выглядит очень перспективно с точки зрения того, что нужно нашей компании:
- Инкрементные бэкапы виртуальных машин, например, каждые 15 минут
- Гибкий цикл хранения, например, хранить последние 8, хранить 22 часа и т.д.
- Один клиент PVE, который отправляет данные, и несколько серверов бэкапа, которые тянут данные через sync-задания
- В случае сбоя оператор выбирает бэкап (обычно последний, не старше 15 минут) и запускает процесс восстановления ВМ.
Сейчас мы оцениваем железо для сервера бэкапа. Производительность инкрементных бэкапов нормальная, даже на HDD — проблем нет.
Но время восстановления слишком большое: на нашем текущем хосте у Hetzner мы видим время восстановления от 1 часа 17 минут до 1 часа 21 минуты со средней скоростью 156–165 МБ/с для больших ВМ около 750 ГБ. Я хочу сократить время восстановления до примерно 0 часов 15–45 минут, для этого нужны скорости восстановления от 300 до 800 МБ/с.
Давайте сосредоточимся на скоростях восстановления ВМ в 750 ГБ. Вот характеристики нашего текущего хоста:
- Хост: выделенный сервер у Hetzner
- CPU: Intel® Xeon® CPU E5-1650 v3 (6 ядер, 12 потоков)
- Оперативная память: 256 ГБ
- Источник (PBS chunks): HDD 2 ТБ, Цель: тот же HDD. Скорость: 35 МБ/с
- Источник (PBS chunks): HDD 2 ТБ, Цель: SSD TOSHIBA_KHK61RSE1T92. Скорость: 139 МБ/с
- Источник (PBS chunks): SSD TOSHIBA_THNSN81Q92CSE, Цель: SSD TOSHIBA_KHK61RSE1T92. Скорость: 156–165 МБ/с
Потом я подумал, может NVMe смогут хотя бы 300 МБ/с, и провёл тесты на Amazon EC2 и Microsoft Azure.
- Хост: AWS EC2 i3.metal, выделенный экземпляр
- CPU: 80 x AMD EPYC 7551 32-Core Processor (2 сокета)
- Память: 512 ГБ
- Источник (PBS chunks): массив mdadm RAID0 из 2x 2 ТБ NVMe, цель — другой массив mdadm RAID0 из 2x 2 ТБ NVMe. Скорость: 140 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 8x 2 ТБ NVMe, цель — тот же массив. Скорость: 142 МБ/с
- Хост: Azure L80s_v2
- CPU: 72 x Intel® Xeon® CPU E5-2686 v4 @ 2.30GHz (2 сокета)
- Память: 640 ГБ
- Источник (PBS chunks): 2 ТБ NVMe, цель — другой 2 ТБ NVMe. Скорость: 204 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 2x 2 ТБ NVMe, цель — другой массив из 2x 2 ТБ NVMe. Скорость: 229 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 5x 2 ТБ NVMe, цель — другой массив из 5x 2 ТБ NVMe. Скорость: 208 МБ/с
Хосты могли скачать начальный бэкап ВМ со скоростью 1200–2200 МБ/с (10–18 Гбит/с), а данные fio говорят сами за себя (см. вложение).
В итоге тесты с NVMe-дисками не показали ожидаемых скоростей восстановления. AWS EC2 даже не смогла обогнать по производительности нашего E5-1650 v3 с Toshiba SSD...
Давайте посмотрим на htop во время восстановления:
Причина низкой скорости восстановления очевидна: /usr/bin/pbs-restore использует только один поток, что приводит к загрузке почти на 100% одного виртуального ядра.
Однопоточный процессор не справляется, чтобы заполнить очереди ввода-вывода моих NVMe.
При использовании SSD и NVMe узким местом в восстановлении становится производительность одного CPU-потока.
Поэтому я заглянул в репозиторий proxmox-backup-qemu, особенно в файл src/restore.rs.
В конструкторе pub fn new(setup: BackupSetup) инициализируется proxmox-restore-worker с builder.max_threads(6) и builder.core_threads(4), но восстановительные воркеры не работают параллельно при восстановлении одной ВМ: в функции pub async fn restore_image я не вижу параллелизма в цикле for pos in 0..index.index_count().
Возможно, я смотрю не в тот репозиторий или не в те строки кода, но...
Можете представить себе распараллеливание pbs-restore для восстановления одного бэкапа PBS ВМ, чтобы использовать преимущества современных SSD и NVMe?
Дополнительные ссылки:
- Инкрементные бэкапы виртуальных машин, например, каждые 15 минут
- Гибкий цикл хранения, например, хранить последние 8, хранить 22 часа и т.д.
- Один клиент PVE, который отправляет данные, и несколько серверов бэкапа, которые тянут данные через sync-задания
- В случае сбоя оператор выбирает бэкап (обычно последний, не старше 15 минут) и запускает процесс восстановления ВМ.
Сейчас мы оцениваем железо для сервера бэкапа. Производительность инкрементных бэкапов нормальная, даже на HDD — проблем нет.
Но время восстановления слишком большое: на нашем текущем хосте у Hetzner мы видим время восстановления от 1 часа 17 минут до 1 часа 21 минуты со средней скоростью 156–165 МБ/с для больших ВМ около 750 ГБ. Я хочу сократить время восстановления до примерно 0 часов 15–45 минут, для этого нужны скорости восстановления от 300 до 800 МБ/с.
Давайте сосредоточимся на скоростях восстановления ВМ в 750 ГБ. Вот характеристики нашего текущего хоста:
- Хост: выделенный сервер у Hetzner
- CPU: Intel® Xeon® CPU E5-1650 v3 (6 ядер, 12 потоков)
- Оперативная память: 256 ГБ
- Источник (PBS chunks): HDD 2 ТБ, Цель: тот же HDD. Скорость: 35 МБ/с
- Источник (PBS chunks): HDD 2 ТБ, Цель: SSD TOSHIBA_KHK61RSE1T92. Скорость: 139 МБ/с
- Источник (PBS chunks): SSD TOSHIBA_THNSN81Q92CSE, Цель: SSD TOSHIBA_KHK61RSE1T92. Скорость: 156–165 МБ/с
Потом я подумал, может NVMe смогут хотя бы 300 МБ/с, и провёл тесты на Amazon EC2 и Microsoft Azure.
- Хост: AWS EC2 i3.metal, выделенный экземпляр
- CPU: 80 x AMD EPYC 7551 32-Core Processor (2 сокета)
- Память: 512 ГБ
- Источник (PBS chunks): массив mdadm RAID0 из 2x 2 ТБ NVMe, цель — другой массив mdadm RAID0 из 2x 2 ТБ NVMe. Скорость: 140 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 8x 2 ТБ NVMe, цель — тот же массив. Скорость: 142 МБ/с
- Хост: Azure L80s_v2
- CPU: 72 x Intel® Xeon® CPU E5-2686 v4 @ 2.30GHz (2 сокета)
- Память: 640 ГБ
- Источник (PBS chunks): 2 ТБ NVMe, цель — другой 2 ТБ NVMe. Скорость: 204 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 2x 2 ТБ NVMe, цель — другой массив из 2x 2 ТБ NVMe. Скорость: 229 МБ/с
- Источник (PBS chunks): массив mdadm RAID0 из 5x 2 ТБ NVMe, цель — другой массив из 5x 2 ТБ NVMe. Скорость: 208 МБ/с
Хосты могли скачать начальный бэкап ВМ со скоростью 1200–2200 МБ/с (10–18 Гбит/с), а данные fio говорят сами за себя (см. вложение).
В итоге тесты с NVMe-дисками не показали ожидаемых скоростей восстановления. AWS EC2 даже не смогла обогнать по производительности нашего E5-1650 v3 с Toshiba SSD...
Давайте посмотрим на htop во время восстановления:
Причина низкой скорости восстановления очевидна: /usr/bin/pbs-restore использует только один поток, что приводит к загрузке почти на 100% одного виртуального ядра.
Однопоточный процессор не справляется, чтобы заполнить очереди ввода-вывода моих NVMe.
При использовании SSD и NVMe узким местом в восстановлении становится производительность одного CPU-потока.
Поэтому я заглянул в репозиторий proxmox-backup-qemu, особенно в файл src/restore.rs.
В конструкторе pub fn new(setup: BackupSetup) инициализируется proxmox-restore-worker с builder.max_threads(6) и builder.core_threads(4), но восстановительные воркеры не работают параллельно при восстановлении одной ВМ: в функции pub async fn restore_image я не вижу параллелизма в цикле for pos in 0..index.index_count().
Возможно, я смотрю не в тот репозиторий или не в те строки кода, но...
Можете представить себе распараллеливание pbs-restore для восстановления одного бэкапа PBS ВМ, чтобы использовать преимущества современных SSD и NVMe?
Дополнительные ссылки:
