Назад | Перейти на главную страницу

Правильно ли KVM / QEMU поддерживает mdadm RAID5?

Я не могу приблизиться к полезной производительности, используя гостевой файл, расположенный в массиве mdadm RAID5. Я считал, что оптимизировал все параметры массива и файловой системы для лучшей производительности R5:

Производительность массива на хосте очень хорошая (105 МБ без кеша, 470 МБ с кешем). Он состоит из 4 жестких дисков, относительно медленный.

KVM / QEMU просто не очень хорошо работает с массивами RAID5 mdadm?

Похоже, это проблема задержки (похожая на то, что я видел на ESXi с локальными дисками).

Задержка почти 17 секунд и средняя скорость записи 1-10 МБ

Пример из virt 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>

Хост: Debian 9 stretch (ядро 4.9.0-8-amd64)

Вы упускаете несколько уловок. Вам необходимо убедиться, что весь стек хранилища выровнен для достижения оптимальной производительности. Вам нужно начать с размера ввода-вывода верхнего уровня и оттуда оптимизировать. Например, создайте гостевую файловую систему NTFS с кластерами 64 КБ, используйте блочные устройства LVM (обратите внимание на аномалии выравнивания LVM) и оптимизируйте свой программный RAID для блоков размером 64 КБ. Если вы должны использовать файлы для поддержки блочных устройств виртуальной машины, убедитесь, что файловая система выровнена таким же образом, особенно обращая внимание на размер вашей группы блоков (параметр -g в mkfs.ext *), чтобы гарантировать, что ваши группы блоков не все запускаются на одном диске. Если ваша рабочая нагрузка приложения верхнего уровня использует меньшие блоки, выравнивайте для меньших блоков, но принцип тот же.

Я написал статью о том, как обеспечить оптимальное выравнивание файловой системы для конкретной рабочей нагрузки, что может оказаться полезным.

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

  • Версия md (то есть ядра), KVM / QEMU и версия virsh
  • конфигурация кеша для вашего гостя (настройка кеширования в вашем XML-файле virsh)
  • Конфигурация MD, особенно stripe_cache и размер куска (должно быть установлено низкое значение - 64 КБ)
  • Оптимизировать файловую систему EXT4, например использовать noatime и в зависимости от резервного копирования ИБП и т. д. отключите ведение журнала и барьеры.

Я использовал стабильную версию Debian (9, Stretch), а это означает, что вы используете очень старую версию ядра, QEMU и virsh :-(

Я перешел на стабильную версию Ubuntu по той же причине, которая даст вам огромный скачок к новым версиям этих важных компонентов. На мой взгляд, стабильный Debian - действительно плохой выбор. Предполагается, что когда выйдет 10 / Buster, это будет нормально для периода, но рано или поздно у вас будет устаревшая система.

Во-вторых, было совершенно очевидно, что вам нужно использовать кеш страниц хост-системы. При использовании MD RAID5 происходит некоторое предварительное кэширование. Даже когда кеш заполнен, производительность очень хорошая. В моем случае скорость записи более 200 МБ / с на медленные диски, которые производят около 100 МБ / с в конфигурации JBOD.

Использование cache = none в XML и последующее использование кеша страниц гостевой системы Windows приведет к очень низкой производительности. SSD может быть отдельная история.

Не забудьте также поиграть с настройками кеширования страниц в гостевой системе Windows для текущего диска, чтобы получить наилучший результат.