в нашей компании у нас много клиентов kvm на нескольких серверах, большинство клиентов работают под управлением ubuntu 16.04, а также их хост-систем.
Выбранная файловая система стала EXT4 для клиентов и хостов. Недавно я использовал некоторые из замечательных функций моментальных снимков, предоставляемых BTRFS, для настройки сервера резервного копирования с добавочными резервными копиями.
Некоторые исследования показали, что нельзя использовать BTRFS для хоста KVM, потому что фрагментация FS замедляет работу клиентов, пока они, наконец, даже не зависнут.
Есть ли какие-либо рекомендации / делать / не использовать BTRFS на клиенте KVM?
Мы пересматриваем наш выбор FS для клиентов и хостов, есть ли преимущества при использовании XFS по сравнению с EXT4 (клиент / хост или только односторонний)?
В Google можно найти множество веб-сайтов, на которых рассказывается о производительности различных файловых систем с KVM.
Взгляните на это: ZFS, BTRFS, XFS, EXT4 и LVM с KVM - сравнение производительности хранилища
По словам автора Гионатана Данти:
Протестированные сценарии:
1) Бэкэнд Qcow2 поверх файловой системы XFS поверх необработанного MD-устройства. Были протестированы режимы тонкого и частичного (только для метаданных) предварительного распределения;
2) Бэкэнд Logical Volumes, как в классическом LVM (предварительное выделение жира), так и в тонком (тонкое целевое значение lvm). Более того, тонкий lvm анализировался как с включенным, так и с выключенным обнулением;
3) необработанные образы в XFS и EXT4 поверх классического LVM, обеспечивающие поддержку разреженных файлов файловой системы для тонкого выделения ресурсов;
4) необработанные образы в XFS и EXT4 поверх тонкого LVM, ретранслируя на тонкую цель lvm для тонкого предоставления. В этом случае обнуление LVM было отключено, так как блоки обнуления напрямую управляются внутри структур файловой системы;
5) необработанные образы BTRFS поверх его реализации с зеркалом + полосой (здесь нет MD). Я тестировал BTRFS с включенным и отключенным CoW (опция монтирования nodatacow)
6) необработанные образы ZFS поверх его зеркальной + полосовой реализации (снова без MD)
В заключение он сказал:
Что касается хранилища виртуальных машин, держитесь подальше от BTRFS: он не только отмечен как «Tech Preview» от RedHat (читай: не на 100% готов к производству), но и работает очень медленно при использовании в качестве хранилища образов виртуальных машин.
В другом блоге рассказывается о BTRFS, вы можете прочитать на многих форумах, что Copy On Write (COW) необходимо отключить для повышения производительности с KVM.
Крис Ирвин рассказывает о преимуществах BTRFS и об альтернативе:
Есть и другие инструменты, или вы можете запустить свою собственную cron-работу. Так что насчет ZFS? Я думал, что ZFS все это делает?
Да, почему бы просто не использовать ZFS?
Преуспевать
ссылка на сайт : жить с btrfs
Другой способ узнать, подходит ли это для вашего использования, - это протестировать самостоятельно, если производительность хорошая и надежна ли она без копирования при записи.
Если BTRFS вам не подходит, вы можете попробовать ZFS. У вас та же функциональность резервного копирования и множество других улучшений, но это немного сложно реализовать в Linux.
Мое предпочтительное решение для оркестровки KVM, oVirt, использует тома LVM, передаваемые виртуальным машинам как необработанные диски для максимальной производительности, масштабируемости и гибкости. Вы можете делать снимки как qcow2, так и LVM. Если вы создаете новое решение для хранения и хотите попробовать что-то в духе SDS и необычное, вы можете вместо этого использовать Ceph и RBD-доступ к томам.
Взгляните на официальный сайт Btrfs Gotchas на их собственной вики: https://btrfs.wiki.kernel.org/index.php/Gotchas
Особенно этот момент:
Фрагментация
Файлы с большим количеством случайных записей могут стать сильно фрагментированными (более 10000 экстентов), что приведет к перегрузке жестких дисков и чрезмерным многосекундным скачкам нагрузки на ЦП в системах с твердотельным накопителем или большим объемом ОЗУ. На серверах и рабочих станциях это влияет на базы данных и образы виртуальных машин. Опция монтирования nodatacow может быть здесь полезна с соответствующими ошибками.
Таким образом, одно это говорит против этого, какой смысл в файловой системе COW, если единственная функция, для которой вы хотите ее использовать, вообще не может использоваться с образами виртуальных хостов в быстром режиме? Если вы хотите использовать файловую систему COW, возьмите ZFS.
Также имейте в виду, что Coreos перешел с Btrfs на EXT4 в качестве файловой системы по умолчанию, потому что в то время она была слишком глючной много лет назад.
https://www.phoronix.com/scan.php?page=news_item&px=CoreOS-Btrfs-To-EXT4-OverlayFS
Так что, хотя Ext4 и не такие яркие, как мистер Модные штаны, это надежная и надежная рабочая лошадка. Если вы ищете файловую систему помимо Ext4 в Linux и не хотите использовать ZOL / переход на FreeBSD, возможно, стоит попробовать XFS.
Обратите внимание, что хотя я использую Btrfs на своем домашнем рабочем столе с Gentoo и довольно свежими ядрами, каждые несколько месяцев все еще возникают довольно неприятные ошибки, из-за которых система не загружается и требует ремонта вручную, что требует времени для исследования в Google и использования методом проб и ошибок, а если не работает, правильную резервную копию.
Настоящий вопрос, который вы должны задать себе, заключается в следующем: почему мы должны отказываться от Ext4? Кажется, он отлично подходит для вашего варианта использования. То, что вы читаете что-то о новой яркой вещи, не означает, что она вам действительно нужна. Подумай об этом.
CentOS отказывается от поддержки btrfs ref: https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/ так что для CentOS btrfs - не лучший выбор.
btrfs рассматривается как следующий стандарт FS, но ZFS также привлекает много внимания, в основном Ubuntu.
Большинство предупреждений против btrfs являются старыми и / или касаются конкретной конфигурации, такой как RAID6 (что означает более двух дисков)
openSUSE выбирает btrfs и хорошо его поддерживает. например, в каталоге / var / lib / libvirt они отключают COW, поэтому они, очевидно, сталкиваются с некоторыми проблемами и исправляют их.
Я запускаю openSUSE с btrfs на 2 SSD-накопителях как RAID1, который используется как root, где я размещаю 5 виртуальных машин (KVM) и 20 контейнеров (Docker).
Меня это вполне устраивает.