☰

存储堆栈中的 VDO/虚拟磁盘优化器限制

tag-icon • tag-icon centos7 storage rhel7 thin-provisioning
存储堆栈中的 VDO/虚拟磁盘优化器限制

好吧，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
  • LVM 快照上的 VDO
  • LVM 缓存上的 VDO
  • 环回设备顶部的 VDO
  • LVM 精简配置上的 VDO
  • VDO 上的加密卷：存储 → VDO → DM-Crypt
  • VDO 卷上的分区：fdisk、parted 和类似的分区
  • VDO 卷上的 RAID（LVM、MD 或任何其他类型）

这有点“可怕”，我们应该小心设计，因为看起来以下内容不会“受支持”：

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

请注意，VDO/EXT4 的最终结果在 VM 中，LVM LV 直接连接到 VM，类似于：

storage -> LVM PV -> LVM VG -> LVM Thin -> LVM LV -> VDO -> Storage (in VM) -> EXT4 (in VM)
  1. 这真的有问题或危险并且不受支持吗？
  2. 为什么？

在底层设备上创建所有内容并不总是一个好的选择，但我不明白为什么我们会有这些限制。

可能是因为这些 VDO 卷将暴露给主机和客户机？

答案1

在精简 LVM 上创建 VDO 有什么意义？VDO 已经是精简配置的，并且在 4kb 块上工作。

  • VDO 卷上的 VDO：存储 → VDO → LVM → VDO- 对已删除重复数据进行重复数据删除毫无意义
  • LVM 快照上的 VDO- 对重复数据进行快照毫无意义
  • LVM 缓存上的 VDO- 你真的需要进行重复数据删除缓存吗？
  • LVM 精简配置上的 VDO- 正如我上面所说，VDO 已经是精简设备。此外，如果底层存储上没有可用空间，VDO 本身将更改为只读状态，而如果你将 VDO 放在 LVM 精简之上，VDO 将不知道空间已用完，这可能会导致数据损坏
  • VDO 上的加密卷：存储 → VDO → DM-Crypt- 根据设计，无法对加密数据进行重复数据删除（显然是因为加密数据/设备需要完全配置的大小）VDO 卷顶部的 RAID（LVM、MD 或任何其他类型）- 为什么需要为重复数据删除对象创建 RAID 组？

关于您的场景，只需这样做（LVM 在物理级别上必须是冗余的）：
存储 → LVM PV → LVM VG → LVM LV → VDO → 存储（在 VM 中）→ EXT4（在 VM 中）

我将一些测试虚拟机放在类似的场景中，一切运行正常。

相关内容