KVM/QEMU правильно поддерживает mdadm RAID5?
Я не могу получить что-то близкое к полезной производительности, используя гостевой файл, расположенный в массиве mdadm RAID5. Я полагал, что оптимизировал все параметры массива и файловой системы для лучшей производительности R5:
- set bitmap = none
- установить stripe-cache=32768 (пробовал из 256-32768)
- Шаг EXT4 =128 / ширина полосы =384 (блок 512K, блок FS 4K, 3 диска с данными)
Производительность массива на хосте очень хорошая (105 МБ без кеша, 470 МБ с кешем). Он сделан из 4-х жестких дисков, относительно медленно.
- Это не делает различий, если файл изображения является сырым или qcow2
- Пробовал оба Virtio SCSI и Virtio SATA
- Перепробовал все комбинации кеша, в том числе и в самом госте (Windows 10 и Linux)
Разве KVM/QEMU не очень хорошо работает с массивами RAID5 mdadm?
Кажется, это проблема задержки (похожая на ту, что я видел в ESXi с локальными дисками).
Задержка почти 17 секунд и в среднем производительность записи 1-10 МБ
Пример из виртуального XML:
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='writeback'/>
<source file='/mnt/R5_DATA/data2.raw'/>
<target dev='sdd' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='3'/>
</disk>
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</controller>
1 ответ
После долгих испытаний можно получить очень хорошую производительность. Есть несколько обстоятельств, которые сильно отличают друг от друга:
- Версия md (т.е. ядро), KVM/QEMU и версия virsh
- конфигурация кеша для вашего гостя (настройка кеша в вашем XML-файле virsh)
- Конфигурация MD, особенно stripe_cache и размер чанка (следует установить низкое значение до 64K)
- Оптимизируйте файловую систему EXT4, например, используйте noatime, в зависимости от резервного копирования ИБП и т. Д. Отключите ведение журнала и барьеры.
Я работал под стабильным Debian (9, Stretch), а это значит, что вы используете очень старую версию ядра, QEMU и virsh:-(
Теперь я перешел на Ubuntu стабильный по той же причине, что даст вам огромный переход к более новым версиям этих важных компонентов. На мой взгляд, стабильный Debian это действительно плохой выбор. Когда выйдет 10/Buster, можно предположить, что для периода это будет хорошо, но рано или поздно у вас будет устаревшая система.
Во-вторых, было совершенно очевидно, что вам нужно использовать кеш страниц хост-системы. При использовании MD RAID5 происходит некоторое дополнительное кэширование. Даже когда кеш заполнен, производительность очень хорошая. В моем случае скорость записи более 200 МБ / с на медленных дисках, которые в конфигурации JBOD составляют около 100 МБ / с.
Использование cache=none в XML, а затем использование кеша страниц гостевой системы Windows даст вам очень низкую производительность. SSD может быть другой историей.
Не забудьте также поиграть с настройками кэша страниц в гостевой системе Windows для текущего диска, чтобы получить наилучший результат.
Вы упускаете несколько уловок. Вам необходимо обеспечить выравнивание всего стека хранения для достижения оптимальной производительности. Вам нужно начать с размера ввода-вывода верхнего уровня и оттуда оптимизировать. Например, создайте гостевую файловую систему NTFS с кластерами 64 КБ, используйте блочные устройства LVM (обратите внимание на аномалии выравнивания LVM) и оптимизируйте свой программный RAID для блоков размером 64 КБ. Если вы должны использовать файлы для поддержки блочных устройств ВМ, убедитесь, что файловая система выровнена таким же образом, особенно обращая внимание на размер вашей группы блоков (параметр -g в mkfs.ext*), чтобы убедиться, что ваши группы блоков не все запускаются на одном диске. Если ваша рабочая нагрузка приложения верхнего уровня использует меньшие блоки, выравнивайте для меньших блоков, но принцип тот же.
Я написал статью о том, как обеспечить оптимальное выравнивание файловой системы для конкретной рабочей нагрузки, которая может оказаться вам полезной.