Прямой доступ к диску KVM по сравнению с необработанными файлами
Мне нужно настроить 14 ТБ дискового пространства для рейда (которое отображается как / dev / sdb ). У меня вопрос:
Будет ли какое-либо влияние на производительность гостя kvm, если я создам ext4 непосредственно на этом большом диске, смонтирую его на хосте, например / mnt / kvms, а затем создам на нем необработанный образ диска kvm?
Было бы намного быстрее настроить / dev / sdb непосредственно на машине kvm?
Я считаю, что если что-то случится с этой большой областью хранения, я ничего не смогу с ней поделать, если буду использовать устройство напрямую, но, допустим, я создаю на нем файлы kvm raw-disk размером 2x7 ТБ, если 1 файл имеет проблема, по крайней мере, мои данные все еще доступны в другом.
Как вы думаете?
Есть ли какое-либо влияние на производительность гостя kvm, если я создаю ext4 непосредственно на этом большом диске, монтирую его на хосте, например / mnt / kvms, а затем создаю на нем необработанный образ диска kvm ?
Каждый раз, когда у ваших данных есть больше слоев, которые нужно пройти через процесс, снижение производительности и увеличение задержки будет появляться. Например:
- RAW-файл Qemu -> Ext4 -> LVM -> устройство RAID1 -> физическое устройство
- сырое устройство Qemu -> LVM -> устройство RAID1 -> физическое устройство
- сырое устройство Qemu -> устройство RAID -> физическое устройство
Было бы намного быстрее настроить / dev / sdb непосредственно на kvm-машине?
Только вы можете проверить это в своей рабочей нагрузке. С моими (файловыми серверами) производительность заметно выше при использовании (2).
Каждый раз, когда вы уходите с какого-либо уровня, вы теряете некоторую гибкость (снимки, базовое изображение, сжатие и т. Д.), Но вы получаете некоторую производительность, лично я как (2), из-за возможностей резервного копирования (время простоя менее 2 минут в день), гибкости размера и сбалансированной производительности, использование файлов также проще, например, вы можете mount --bind целиком / var / lib / libvirt из резервной копии (для отсрочки простоя) вместо исходных файлов за 10 секунд (с помощью одной команды) для запуска виртуальной машины из резервной копии, воссоздания блочных устройств, редактирования конфигурации виртуальной машины намного сложнее (с точки зрения необходимого времени).