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

Ограничения VDO / Virtual Disk Optimizer в стеке хранилища

Что ж, RHEL 7.5 выпущен с важным дополнением, VDO, которое в основном добавляет сжатые и дедуплицированные тома с тонким выделением ресурсов, что здорово, и мы получим эти преимущества также с производными и другими дистрибутивами, поскольку технология была приобретена у Permabit и открытый источник.

Согласно официальным документам (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-qs-requirements), есть некоторые соображения (раздел документа «Размещение VDO в стеке хранилища»):

Как Общее Правило, вы должны разместить одни уровни хранения под VDO, а другие - над VDO:

  • Под VDO: DM-Multipath, DM-Crypt и программный RAID (LVM или mdraid).
  • В дополнение к VDO: кэш LVM, логические тома LVM, моментальные снимки LVM и тонкое предоставление LVM.

Ну, потому что это «общее» правило - я не вижу в этом проблем, и все в порядке. Далее видим следующее:

Следующие конфигурации не поддерживаются:

  • VDO поверх томов VDO: хранилище → VDO → LVM → VDO
  • VDO поверх снимков LVM
  • VDO поверх LVM Cache
  • VDO поверх устройства обратной петли
  • VDO поверх LVM Thin Provisioning
  • Зашифрованные тома поверх VDO: хранилище → VDO → DM-Crypt
  • Разделы на томе VDO: fdisk, parted и подобные разделы
  • RAID (LVM, MD или любой другой тип) поверх тома VDO

Это немного «пугает», и мы должны тщательно подходить к дизайну, потому что, похоже, следующее «не поддерживается»:

storage -> LVM PV -> LVM VG -> LVM Thin -> LVM LV -> Storage (in VM) -> VDO (in VM) -> EXT4 (in VM)

Обратите внимание, что VDO / EXT4, конечный результат находится в виртуальной машине, LVM LV напрямую привязан к виртуальной машине, и это похоже на:

storage -> LVM PV -> LVM VG -> LVM Thin -> LVM LV -> VDO -> Storage (in VM) -> EXT4 (in VM)
  1. Это действительно проблематично или опасно и не поддерживается?
  2. Зачем?

Создание всего на базовом устройстве - не всегда хороший вариант, но я не вижу четкого объяснения, почему у нас есть эти ограничения.

Может быть, потому что эти тома VDO будут доступны как для хоста, так и для гостя?

В чем смысл создания VDO поверх тонкого LVM? VDO уже имеет тонкое выделение ресурсов и работает с блоками размером 4 КБ.

  • VDO поверх томов VDO: хранилище → VDO → LVM → VDO - не имеет смысла дедуплицировать дедуплицированные данные
  • VDO поверх снимков LVM - не имеет смысла делать снимки дедуплицированных данных
  • VDO поверх LVM Cache - вам правда нужно дедуплицировать кеширование?
  • VDO поверх LVM Thin Provisioning - как я уже сказал выше, VDO - это уже тонкое устройство. Более того, сам VDO изменит состояние на чтение только в случае, если в базовом хранилище нет свободного места, а если вы поместите VDO поверх тонкого LVM, VDO не узнает, что пространство закончилось, это приведет к возможным повреждение данных
  • Зашифрованные тома поверх VDO: хранилище → VDO → DM-Crypt - по умолчанию дедупликация зашифрованных данных невозможна (очевидно, потому что для зашифрованных данных / устройства требуется полностью подготовленный размер) RAID (LVM, MD или любой другой тип) поверх тома VDO - зачем вам создавать группы RAID для дедуплицированных объектов?

Что касается вашего сценария, просто сделайте это так (LVM должен быть избыточным на физическом уровне):
хранилище → LVM PV → LVM VG → LVM LV → VDO → Storage (в VM) → EXT4 (в VM)

Я поместил несколько тестовых виртуальных машин в аналогичный сценарий, и все работает нормально.