RHEL 中逻辑卷的重复数据删除和压缩。

Red Hat Enterprise Linux 8

使用 VDO 来提高 LVM 存储容量

Red Hat Customer Content Services

摘要

本文档解释了如何在 LVM 中使用 Virtual Data Optimizer(VDO)功能来管理 RHEL 中对逻辑卷进行重复数据删除(deduplicate)和压缩。

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请让我们了解如何改进文档。要做到这一点:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. 在 Component 中选择 Documentation
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

第 1 章 LVM 的 VDO 介绍

Virtual Data Optimizer(VDO)为存储提供内联块级的重复数据删除(deduplication)、压缩和精简置备。您可以将 VDO 作为一个 LVM 逻辑卷类型(LV)来管理,类似于 LVM 精简置备的卷。

LVM(LVM-VDO)中的 VDO 卷由以下 LV 组成:

VDO 池 LV

这是用于 VDO LV 存储、重复数据删除和压缩的后端物理设备。VDO 池 LV 设置 VDO 卷的物理大小,即 VDO 可保存到磁盘中的数据量。

目前,每个 VDO 池 LV 只能有一个 VDO LV。因此,VDO 会单独压缩每个 VDO LV。换句话说,VDO 无法重复数据删除或压缩一些 VDO LV 共享的数据。

VDO LV
这是 VDO 池 LV 上的虚拟置备设备。VDO LV 设定 VDO 卷的置备和逻辑大小,即应用程序在重复数据删除和压缩发生前可写入卷的数据量。

表 1.1. LVM 和 LVM 精简置备的 VDO 组件的比较

 物理设备置备的设备

LVM 上的 VDO

VDO 池 LV

VDO LV

LVM 精简配置

精简池(thin poll)

精简卷(thin volume)

由于 VDO 是迅速置备的,所以文件系统和应用程序只会看到使用中的逻辑空间,且不知道可用的实际物理空间。使用脚本来监控实际可用空间并在使用超过阈值时生成警报:例如,当 VDO 池 LV 满率为 80% 时。

其它资源

第 2 章 LVM-VDO 要求

LVM 上的 VDO 对其放置和系统资源有一定要求。

2.1. VDO 内存要求

每个 VDO 卷有不同的内存要求:

VDO 模块

VDO 需要固定 38MB RAM 和几个变量数量:

  • 1.15 配置的块映射缓存大小为 1MB 的内存。块映射缓存最少需要 150MB RAM。
  • 每 1TB 逻辑空间为 1.6 MB RAM。
  • 每 1TB 物理存储由卷管理的每 1TB 物理存储的 RAM MB。

UDS 索引

通用重复数据删除服务(UDS)需要最少 250MB RAM,也是重复数据删除使用的默认数量。您可以在格式化 VDO 卷时配置值,因为值也会影响索引需要的存储量。

UDS 索引所需的内存由索引类型和重复数据删除窗口所需大小决定:

索引类型重复数据删除窗口备注

密度

每 1 GB RAM 为 1 TB

1GB 密度索引一般足以满足 4TB 物理存储空间。

稀疏

每 1 GB RAM 为 10 TB

1 GB 稀疏索引一般足以满足40TB 物理存储空间。

UDS 稀疏索引功能是 VDO 推荐的模式。它依赖于数据的区域位置,并尝试只保留内存中最相关的索引条目。使用稀疏索引,UDS 维护一个重复数据删除窗口,它是密度的10 倍,但使用相同数量的内存。

稀疏索引提供了最高的覆盖,但密度索引提供了更多的重复数据删除建议。对于大多数工作负载,如果内存量相同,则密度和稀疏索引间的重复数据删除率的不同会微不足道。

其它资源

2.2. VDO 存储空间要求

您可以将 VDO 卷配置为使用最多 256TB 物理存储。只有物理存储的某个部分可用来存储数据。本节提供了计算 VDO 管理的卷的可用空间大小的方法。

VDO 需要为两种类型的 VDO 元数据和 UDS 索引进行存储:

  • 第一类 VDO 元数据对于每 4GB 物理贮存使用 1 MB,再加上每个 slab 的额外的 1 MB。
  • 第二类 VDO 元数据对于每 1GB 逻辑存储使用 1.25 MB,并舍入到最近的 slab。
  • UDS 索引所需的存储量取决于索引类型以及分配给索引的 RAM 量。对于每 1 GB RAM,密度 UDS 索引使用 17GB 存储,稀疏 UDS 索引使用 170 GB 存储。

其它资源

2.3. VDO 物理大小要求示例

下表根据基础卷的物理大小提供 VDO 的最大系统要求。每个表都列出了适合预定部署的要求,如主存储或备份存储。

具体数量取决于您的 VDO 卷的配置。

主存储部署

在主存储中,UDS 索引是物理大小的 0.01% 到 25%。

表 2.1. 主存储的存储和内存要求

物理大小RAM 使用量: UDSRAM 用量:VDO磁盘用量索引类型

10GB–1TB

250MB

472MB

2.5GB

密度

2–10TB

1GB

3GB

10GB

密度

250MB

22GB

稀疏

11–50TB

2GB

14GB

170GB

稀疏

51-100TB

3GB

27GB

255GB

稀疏

101–256TB

12GB

69GB

1020GB

稀疏

备份存储部署

在备份存储中,UDS 索引覆盖了备份组的大小,但小于物理大小。如果您预期备份集或物理大小在以后会增大,则需要把这个值加到索引大小中。

表 2.2. 备份存储的存储和内存要求

物理大小RAM 使用量: UDSRAM 用量:VDO磁盘用量索引类型

10GB–1TB

250MB

472MB

2.5 GB

密度

2–10TB

2GB

3GB

170GB

稀疏

11–50TB

10GB

14GB

850GB

稀疏

51-100TB

20GB

27GB

1700GB

稀疏

101–256TB

26GB

69GB

3400GB

稀疏

2.4. 将 LVM-VDO 放置到存储堆栈中

您必须将某些存储层放在 VDO 逻辑卷下,及其他存储层则位于它之上。

您可以将thick 置备的层放在 VDO 的顶部,但您不能依赖该情况下精简置备的保证。因为 VDO 层是精简置备的,精简置备的效果适用于所有在它上面的层。如果您不监控 VDO 卷,您可能会在 VDO 以上的 thick-provisioned 卷上运行物理空间。

支持的以下层放置在 VDO 下。不要将它们放在 VDO 之上:

  • DM Multipath
  • DM Crypt
  • Software RAID(LVM 或 MD RAID)

不支持 以下配置:

  • VDO 位于回送设备之上
  • 加密的卷位于 VDO 之上
  • VDO 卷中的分区
  • 位于 VDO 卷之上的 RAID,比如 LVM RAID、MD RAID 或者其它类型

其它资源

第 3 章 创建重复数据删除和压缩的逻辑卷

您可以创建使用 VDO 功能的 LVM 逻辑卷来重复数据删除和压缩数据。

3.1. LVM-VDO 部署情况

您可以以不同的方式部署 VDO on LVM(LVM-VDO)以提供重复数据删除的存储:

  • 块访问
  • 文件访问
  • 本地存储
  • 远程存储

因为 LVM-VDO 会将重复数据删除存储作为常规逻辑卷(LV)形式公开,所以您可以在标准文件系统、iSCSI 和 FC 目标驱动程序或者统一存储中使用它。

注意

目前不支持在 LVM-VDO 上部署 Ceph Storage。

KVM

您可以在配置了直接附加存储的 KVM 服务器中部署 LVM-VDO。

使用 KVM 部署 LVM-VDO

文件系统

您可以在 VDO LV 上创建文件系统,并将其公开给 NFS 或者带有 NFS 服务器或 Samba 的 CIFS 用户。

Deduplicated NAS

iSCSI 目标

您可以将 VDO LV 的整个导出为 iSCSI 目标到远程 iSCSI 启动器。

重复数据删除的块存储目标

加密

DM Crypt 等设备映射器(DM)机制与 VDO 兼容。加密 VDO LV 卷有助于确保数据安全性,且所有 VDO LV 以上的文件系统仍会重复使用。

使用加密的 LVM-VDO
重要

如果对数据进行了重复数据删除,则在应用 VDO LV 上面应用加密层不会产生太大效果。在 VDO 可以对它们进行重复数据删除前,加密会使重复数据块不同。

始终将加密层放在 VDO LV 下。

3.2. LVM-VDO 卷的物理和逻辑大小

这部分论述了 VDO 可以使用的物理大小、可用物理大小和逻辑大小。

物理大小

这与分配给 VDO 池 LV 的物理扩展大小相同。VDO 使用这个存储用于:

  • 用户数据,这些数据可能会进行重复数据删除和压缩
  • VDO 元数据,如 UDS 索引
可用物理大小

这是 VDO 可用于用户数据的物理大小的一部分。

它等同于物理大小减去元数据的大小,再减去将卷根据指定的 slab 的大小分为 slab 后剩余的值。

逻辑大小

这是 VDO LV 出现在应用程序中置备的大小。它通常大于可用的物理大小。

如果您没有指定 --virtualsize 选项,VDO 将卷置备为 1:1 比例。例如,如果您将 VDO LV 放在 20GB VDO 池 LV 的上面,如果使用默认索引大小,VDO 为 UDS 索引保留 2.5 GB。剩余的 17.5 GB 为 VDO 元数据和用户数据提供。因此,要消耗的可用存储不超过 17.5 GB,且可能会因为组成实际 VDO 卷的元数据而减少。

VDO 目前支持任意逻辑卷大小最多为物理卷的 254 倍,但不能超过 4 PB。

其它资源

3.4. VDO 中的 Lab 大小

VDO 卷的物理存储被分成几个 slab。每个 slab 都是物理空间的连续区域。给定卷的所有 slab 的大小相同,可以是基于 128 MB 的 2 的指数的任何值,最大值为 32 GB。

默认的 slab 大小为 2 GB,用于在较小的测试系统中评估 VDO。单个 VDO 卷最多可有 8192 个 slabs。因此,在使用 2GB slab 的默认配置中,允许的最大物理存储为 16 TB。当使用 32GB 的 slab 时,允许的最大物理存储为 256 TB。VDO 总是保留至少一个整个 slab 来保存元数据,因此预留 slab 无法用于存储用户数据。

slab 大小不影响 VDO 卷的性能。

表 3.1. 根据物理卷大小推荐的 VDO slab 大小

物理卷大小推荐的 slab 大小

10–99 GB

1 GB

100 GB – 1 TB

2 GB

2–256 TB

32 GB

您可以通过为 vdo create 命令提供 --vdoSlabSize=megabytes 选项来控制 slab 大小。

3.5. 安装 VDO

此流程安装创建、挂载和管理 VDO 卷所需的软件。

流程

  • 安装 vdokmod-kvdo 软件包:

    # yum install vdo kmod-kvdo

3.6. 创建 LVM-VDO 卷

这个过程在 VDO 池 LV 中创建 VDO 逻辑卷(LV)。

先决条件

流程

  1. 为您的 VDO LV 选择一个名称,如 vdo1。您必须为系统中的每个 VDO LV 使用不同的名称和设备。

    在以下步骤中,将 vdo-name 替换为实际名称。

  2. 创建 VDO LV:

    # lvcreate --type vdo \
               --name vdo-name
               --size physical-size
               --virtualsize logical-size \
               vg-name
    • 使用您要放置 VDO LV 的现有 LVM 卷组的名称替换 vg-name
    • 用 VDO LV 使用的逻辑存储数量替换 logical-size
    • 如果物理大小大于 16TiB,请添加以下选项以将卷的 slab 大小增加到 32GiB:

      --config 'allocation/vdo_slab_size_mb=32768'

      如果您在大于 16TiB 的物理大小中使用 2GiB 的默认 slab 大小,lvcreate 命令会失败并显示以下错误:

      ERROR - vdoformat: formatVDO failed on '/dev/device': VDO Status: Exceeds maximum number of slabs supported

    例 3.1. 为容器存储创建 VDO LV

    例如,要为 1TB VDO 池中的容器存储创建 VDO LV,您可以使用:

    # lvcreate --type vdo \
               --name vdo1
               --size 1T
               --virtualsize 10T \
               vg-name
    重要

    如果在创建 VDO 卷时发生故障,请删除要清理的卷。

  3. 在 VDO LV 上创建文件系统:

    • 对于 XFS 文件系统:

      # mkfs.xfs -K /dev/vg-name/vdo-name
    • 对于 ext4 文件系统:

      # mkfs.ext4 -E nodiscard /dev/vg-name/vdo-name

其它资源

  • lvmvdo(7) man page

3.7. 挂载 LVM-VDO 卷

这个过程会在 LVM-VDO 卷中手动挂载文件系统,也可以永久挂载文件系统。

先决条件

流程

  • 要手动将文件系统挂载到 LVM-VDO 卷中,请使用:

    # mount /dev/vg/vdo-name mount-point
  • 要将文件系统配置为在引导时自动挂载,请在 /etc/fstab 文件中添加一行:

    • 对于 XFS 文件系统:

      /dev/vg/vdo-name mount-point xfs defaults,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0
    • 对于 ext4 文件系统:

      /dev/vg/vdo-name mount-point ext4 defaults,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0

    如果 LVM-VDO 卷位于需要网络的块设备中,如 iSCSI,请添加 _netdev 挂载选项。

其它资源

  • 有关 iSCSI 挂载选项的详情请参考 systemd.mount(5) man page。_netdev

3.8. 更改 LVM-VDO 卷中的压缩和重复数据删除设置

此流程启用或禁用 VDO 池逻辑卷(LV)的压缩和重复数据删除。

注意

默认启用压缩和重复数据删除。

先决条件

  • 您的系统中有 LVM-VDO 卷。

流程

  1. 要找出在逻辑卷中是否启用或禁用压缩和重复数据删除:

    # lvs -o+vdo_compression,vdo_deduplication
  2. 查找正在运行的活跃 VDOPoolLV 的 deduplication 索引的压缩和状态:

    # lvs -o+vdo_compression_state,vdo_index_state

    vdo_index_state 可以显示为 errorcloseopeningclosingonlineoffline

  3. 启用或禁用 VDOPoolLV 的压缩:

    # lvchange --compression y|n  vgname/vdopoolname
  4. 为 VDOPoolLV 启用或禁用 deduplication:

    # lvchange --deduplication y|n vgname/vdopoolname

其它资源

  • 详情请查看 lvmvdo(7) man page。

第 4 章 LVM-VDO 卷中的 TRIM 选项

您可以使用 VDO 卷中的 discard 选项让块设备重新声明未使用的空间。另一个选项是使用 fstrim 应用程序(按需丢弃),或使用 mount -o discard 命令进行立即丢弃。当使用 fstrim 应用程序时,管理员需要调度并监控额外进程,同时使用 mount -o discard 命令可尽可能立即恢复空间。

请注意,目前建议使用 fstrim 应用程序丢弃未使用的块,而不是 discard 挂载选项,因为这个选项对性能的影响可能非常严重。因此, nodiscard 是默认设置。

4.1. 在 VDO 上启用丢弃挂载选项

此流程在 VDO 卷中启用 discard 选项。

先决条件

  • 您的系统中有 LVM-VDO 卷。

流程

  • 在您的卷中启用 discard:

    # mount -o discard /dev/vgname/vdoname mount-point

其它资源

  • xfs(5) man page
  • mount(8) man page
  • lvmvdo(7) man page

4.2. 设置定期 TRIM 操作

这个过程在您的系统中启用调度的 TRIM 操作。

先决条件

  • 您的系统中有 LVM-VDO 卷。

流程

  • 启用并启动计时器:

    # systemctl enable --now fstrim.timer

验证

  • 验证是否启用了计时器:

    # systemctl list-timers fstrim.timer

    例 4.1. 验证过程的可能输出

    # systemctl list-timers fstrim.timer
    NEXT                         LEFT         LAST  PASSED  UNIT         ACTIVATES
    Mon 2021-05-10 00:00:00 EDT  5 days left  n/a   n/a     fstrim.timer fstrim.service
注意

您将不会看到对 VDO 卷的任何引用,因为 fstrim.timer 在所有挂载的文件系统中运行。

其它资源

  • fstrim(8) man page

法律通告

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.