I
самый-самый производительный вариант - отдавать диски или разделы напрямую в вм. но это менеджить неудобно.
Size: a a a
2020 October 27
I
на втором месте по производительности - lvm. менеджить удобно.
I
на lvm не нужно создавать фс и qcow2 хранить
СГ
Проблема такая: iowait на ВМ в 10Тб очень высокий 40-65%, причем постоянно.
Эта ВМ это сервер резервного копирования UrBackup. Сама ФС внутри ВМ - btrfs. Размер 10Тб, занято почти 100%. Я понимаю, что возможно из-за этого тормозит, но прежде чем расширять диск до 12Тб, я хочу точно понять как максимально повысить производительность диска внутри ВМ. Для этого я хочу выработать правильный подход к решению этой проблемы. Вот и пытаюсь понять как измерять производительность.
Структура диской системы:
На Proxmox 2 mdadm RAID массива:
1. mdadm RAID 1 из 2-х NVMe дисков по 2Tb SSD M.2 2280 Intel SSDPEKNW020T8X1 https://www.xcom-shop.ru/intel_ssdpeknw020t8x1_679766.html. На нем хранятся ВМ, которые требуют очень быстрого отклика диска.
2. mdadm RAID 6 из 4-х дисков WD Original WUH721414ALE6L4 14Tb https://topcomputer.ru/tovary/1212566/.
На рейдах LVM, На LVM файловая система ext4, на ней образы ВМ хранятся в qcow2.
lsblk на скриншоте ниже.
Эта ВМ это сервер резервного копирования UrBackup. Сама ФС внутри ВМ - btrfs. Размер 10Тб, занято почти 100%. Я понимаю, что возможно из-за этого тормозит, но прежде чем расширять диск до 12Тб, я хочу точно понять как максимально повысить производительность диска внутри ВМ. Для этого я хочу выработать правильный подход к решению этой проблемы. Вот и пытаюсь понять как измерять производительность.
Структура диской системы:
На Proxmox 2 mdadm RAID массива:
1. mdadm RAID 1 из 2-х NVMe дисков по 2Tb SSD M.2 2280 Intel SSDPEKNW020T8X1 https://www.xcom-shop.ru/intel_ssdpeknw020t8x1_679766.html. На нем хранятся ВМ, которые требуют очень быстрого отклика диска.
2. mdadm RAID 6 из 4-х дисков WD Original WUH721414ALE6L4 14Tb https://topcomputer.ru/tovary/1212566/.
На рейдах LVM, На LVM файловая система ext4, на ней образы ВМ хранятся в qcow2.
lsblk на скриншоте ниже.
ну btrfs не лучший выбор для ФС внутри ВМ. Ну вот в таком случае фиксируете текущие показатели внутри ВМ снятые через fio. Пусть даже те, которые уже получили. Далее вносите изменения в настройки виртуальной машины или в настройки ФС внутри ВМ и измеряете заново. Сравниваете.
1. А изменить тип ФС внутри ВМ вы сможете? Или это будет слишком "дорого"?
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
1. А изменить тип ФС внутри ВМ вы сможете? Или это будет слишком "дорого"?
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
СГ
Я готов все полностью переделать. Всю дисковую подсистему, чтобы производительность была максимальной. Только никак не найду самый оптимальный вариант.
но при этом сохранить btrfs внутри ВМ?
I
а еще можно увеличить io переходом в контейнер
Д
но при этом сохранить btrfs внутри ВМ?
Да. Дело в том, что разработчики UrBackup рекомендуют использовать btrfs или ZFS (в мануале и на форуме разработчиков).
СГ
Да. Дело в том, что разработчики UrBackup рекомендуют использовать btrfs или ZFS (в мануале и на форуме разработчиков).
вы бэкапите что-то и помещаете это внутри данной ВМ?
Д
вы бэкапите что-то и помещаете это внутри данной ВМ?
Эта ВМ исключительно для бэкапирования. UrBackup - программа резервного копировая, кстати очень хорошая! Система делает инкрементальные бэкапы как файлов, так и образов дисков. Именно поэтому нужна ФС btrfs или ZFS, т.к. снапшоты делаются средствами ФС.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
Д
ну btrfs не лучший выбор для ФС внутри ВМ. Ну вот в таком случае фиксируете текущие показатели внутри ВМ снятые через fio. Пусть даже те, которые уже получили. Далее вносите изменения в настройки виртуальной машины или в настройки ФС внутри ВМ и измеряете заново. Сравниваете.
1. А изменить тип ФС внутри ВМ вы сможете? Или это будет слишком "дорого"?
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
1. А изменить тип ФС внутри ВМ вы сможете? Или это будет слишком "дорого"?
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
Буду тестить:
1. Создать раздел LVM на том же массиве, что и ВМ, которая тормозит. Протестировать fio непосредственно сам раздел как устройство TEST_FNAME="/dev/vgsata1/lvfiotest1"
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
Спасибо!
1. Создать раздел LVM на том же массиве, что и ВМ, которая тормозит. Протестировать fio непосредственно сам раздел как устройство TEST_FNAME="/dev/vgsata1/lvfiotest1"
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
Спасибо!
R
Буду тестить:
1. Создать раздел LVM на том же массиве, что и ВМ, которая тормозит. Протестировать fio непосредственно сам раздел как устройство TEST_FNAME="/dev/vgsata1/lvfiotest1"
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
Спасибо!
1. Создать раздел LVM на том же массиве, что и ВМ, которая тормозит. Протестировать fio непосредственно сам раздел как устройство TEST_FNAME="/dev/vgsata1/lvfiotest1"
2. Или поднимите ещё одну ВМ на qcow2 на ext4, но внутри неё сделайте не btrfs, а ext4 - и померяйте там. Поймёте разницу между btrfs и ext4.
3. Или поднимите ещё одну ВМ, но НЕ на qcow2, а через LVM Volume - и сделайте внутри ext4 и тоже померяйте - поймёте разницу между qcow2/lvm для ext4 внутри ВМ
Спасибо!
Сжатие включено на btrfs? Ну и cow системы не любят, когда остаётся менее 20% места
R
Проблема такая: iowait на ВМ в 10Тб очень высокий 40-65%, причем постоянно.
Эта ВМ это сервер резервного копирования UrBackup. Сама ФС внутри ВМ - btrfs. Размер 10Тб, занято почти 100%. Я понимаю, что возможно из-за этого тормозит, но прежде чем расширять диск до 12Тб, я хочу точно понять как максимально повысить производительность диска внутри ВМ. Для этого я хочу выработать правильный подход к решению этой проблемы. Вот и пытаюсь понять как измерять производительность.
Структура диской системы:
На Proxmox 2 mdadm RAID массива:
1. mdadm RAID 1 из 2-х NVMe дисков по 2Tb SSD M.2 2280 Intel SSDPEKNW020T8X1 https://www.xcom-shop.ru/intel_ssdpeknw020t8x1_679766.html. На нем хранятся ВМ, которые требуют очень быстрого отклика диска.
2. mdadm RAID 6 из 4-х дисков WD Original WUH721414ALE6L4 14Tb https://topcomputer.ru/tovary/1212566/.
На рейдах LVM, На LVM файловая система ext4, на ней образы ВМ хранятся в qcow2.
lsblk на скриншоте ниже.
Эта ВМ это сервер резервного копирования UrBackup. Сама ФС внутри ВМ - btrfs. Размер 10Тб, занято почти 100%. Я понимаю, что возможно из-за этого тормозит, но прежде чем расширять диск до 12Тб, я хочу точно понять как максимально повысить производительность диска внутри ВМ. Для этого я хочу выработать правильный подход к решению этой проблемы. Вот и пытаюсь понять как измерять производительность.
Структура диской системы:
На Proxmox 2 mdadm RAID массива:
1. mdadm RAID 1 из 2-х NVMe дисков по 2Tb SSD M.2 2280 Intel SSDPEKNW020T8X1 https://www.xcom-shop.ru/intel_ssdpeknw020t8x1_679766.html. На нем хранятся ВМ, которые требуют очень быстрого отклика диска.
2. mdadm RAID 6 из 4-х дисков WD Original WUH721414ALE6L4 14Tb https://topcomputer.ru/tovary/1212566/.
На рейдах LVM, На LVM файловая система ext4, на ней образы ВМ хранятся в qcow2.
lsblk на скриншоте ниже.
Выкинуть файловую систему на lvm и отдавать в ВМ блочное устройство
СГ
Эта ВМ исключительно для бэкапирования. UrBackup - программа резервного копировая, кстати очень хорошая! Система делает инкрементальные бэкапы как файлов, так и образов дисков. Именно поэтому нужна ФС btrfs или ZFS, т.к. снапшоты делаются средствами ФС.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
вы меня простите, но бэкапить внутрь ВМ - это перебор, кмк. А как будете бэкапить эту виртуальную машину?
R
Эта ВМ исключительно для бэкапирования. UrBackup - программа резервного копировая, кстати очень хорошая! Система делает инкрементальные бэкапы как файлов, так и образов дисков. Именно поэтому нужна ФС btrfs или ZFS, т.к. снапшоты делаются средствами ФС.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
Сейчас порядка 40 машин бэкапим раз в сутки.
Занятый объем 9,9Тб. И все это будет расширяться по мене добавления новых машин для бэкапа.
В перспективе эта ВМ может занимать 60Тб. И пока она занимает 10Тб есть техническая возможность ее переносить. Поэтому нужно все спроектировать правильно сейчас.
Выкинуть идею с ВМ на 60ТБ и выделить под хранилку отдельный сервер. Либо несколько для отказоустойчивости
Д
вы меня простите, но бэкапить внутрь ВМ - это перебор, кмк. А как будете бэкапить эту виртуальную машину?
Нууу. Я не представляю как можно бэкапить ВМ на 10Тб? К тому же она сделала исключительно для бэкапов.
Это все равно что бэкапить ВМ, а потом еще раз бэкапить хранилище бэкапов, а потом его тоже... Ну в общем смысл такой
Это все равно что бэкапить ВМ, а потом еще раз бэкапить хранилище бэкапов, а потом его тоже... Ну в общем смысл такой
Д
Выкинуть файловую систему на lvm и отдавать в ВМ блочное устройство
Я пока к этому варианту склоняюсь
Д
Выкинуть идею с ВМ на 60ТБ и выделить под хранилку отдельный сервер. Либо несколько для отказоустойчивости
С ВМ удобно. Если что-то зависло или какие-то проблемы, то всегда есть возможность из vnc подключиться и починить
Плюс при обновлении или каких-то потенциально опасных действиях можно перед этим сделать снапшот, и если возникнут проблемы, то вернуться к нему.
А Если все в порядке, то удалить снапшот.
Плюс при обновлении или каких-то потенциально опасных действиях можно перед этим сделать снапшот, и если возникнут проблемы, то вернуться к нему.
А Если все в порядке, то удалить снапшот.
Д
Поэтому вариант с ВМ лучше.
DS
Поэтому вариант с ВМ лучше.
а вм с виндой?
Д
Нет, Debian 10.