跳转至

Vertica 集成 Permabit Albireo Virtual Data Optimizer

技术探索目标

Vertica 工程师进行此次技术探索，旨在确定 Permabit 的 Virtual Data Optimizer（VDO）在典型的小型 Vertica 实现中的架构透明性，并报告关于如何将 VDO 最佳集成到 Vertica 环境中的任何观察结果。

该项目不是对 VDO 去重或压缩能力的探索。此外，该项目不应被理解为使用 LVM（逻辑卷管理）卷对 Vertica 进行的资格测试，LVM 是 VDO 的基础要求。Vertica 目前官方不支持 LVM 卷，但已列入未来版本的路线图。

结果总结见本文档末尾的"结果总结"部分。

截图

Permabit 概述

Albireo Virtual Data Optimizer（VDO）是一种块虚拟化技术，可创建去重化的块存储池。去重是一种通过消除重复块的多个副本来减少存储资源消耗的技术。VDO 不是多次写入相同的数据，而是检测每个重复块并将其记录为对原始块的引用。Albireo VDO 维护从逻辑块地址（由 VDO 上方的存储层使用）到物理块地址（由 VDO 下方的存储层使用）的映射。去重后，多个逻辑块地址可能映射到同一物理块地址；这些称为共享块。块共享对存储用户是透明的，用户可以像没有 VDO 时一样读取和写入块。当共享块被覆盖时，会分配新的物理块来存储新的块数据，以确保映射到该共享物理块的其他逻辑块地址不被修改。

Albireo VDO 提供内联、块级压缩作为单独许可的功能。压缩是一种数据缩减技术，适用于不一定表现出块级冗余的文件格式，如日志文件和数据库。

有关 Permabit VDO 的更多信息，请参阅 A look at VDO, the new Linux compression layer。

测试环境

Vertica 为此测试选择的硬件是裸机，典型用于小型 Vertica 实现。需要注意的是，该配置不一定对 VDO 性能最优，例如使用 SCSI 而非 SSD 驱动器。因为测试的主要重点是稳定性和从故障中恢复的能力，这种配置是可以接受的。

我们执行性能测试作为稳定性和恢复测试的基础。执行时间结果使用标准 ext4 文件系统和 VDO ext4 文件系统捕获。这纯粹是一次开箱即用的并排比较，以检查是否有任何重大性能时间差异需要注意。未进行任何调优或优化以影响结果。

硬件

所有测试使用 HP ProLiant DL360 Gen9 主机，规格如下：

  • CPU：Intel Xeon E5-2690 v3 @ 2.60GHz，2 个处理器，每 CPU 12 核，超线程 2，总计 48 个虚拟 CPU
  • 内存：264.4 GB，交换空间：2 GB
  • 存储：HP 759548-001 HP G8 G9 600-GB 12G 15K 2.5 SAS SC 磁盘，共 8 块，提供 4TB 存储，RAID 5 配置
  • CPU 频率缩放已禁用（Vertica 和 VDO 文档均推荐）

文件系统配置

设备 /dev/sdb 被分区为两个标准格式化的 ext4 分区（每个约 900 GB），以及一个 LVM 卷组下的两个 VDO 格式化的 ext4 分区（每个约 1 TB）。

分区 df 输出： 

Filesystem                             1K-blocks     Used   Available Use% Mounted on
/dev/sdb2                              1007245124    75208   955998104  1% /data1
/dev/sdb3                               912708596   176916   866162068  1% /data2
/dev/mapper/vdo_vol1                   1320986612    71768  1253805980  1% /vdo1
/dev/mapper/vdo_vol2                   1320986612    71768  1253805980  1% /vdo2
/dev/mapper/vdotest_vol_group-vdo_vol1--index  5160576   146884    4751548  3% /mnt/dedupe-index-vdo_vol1
/dev/mapper/vdotest_vol_group-vdo_vol2--index  5160576   146884    4751548  3% /mnt/dedupe-index-vdo_vol2

上述输出中，两个索引卷是在 VDO 格式化相应分区时自动创建的。这些是用于跟踪去重块引用的 VDO 索引。

sdb 设备的 IO 调度器设置为 deadline（Vertica 和 VDO 文档要求）。

VDO 分区格式化参数： - writePolicy：设置为 synchronous（默认），确保写入已提交并在意外停机时最小化数据丢失 - vdoLogicalSize：设置为 vdoPhysicalSize 的 1.25 倍，基于 VDO 分析工具显示预期去重/压缩小于 25% - VDO 卷创建参数（基于 Permabit 支持建议）： 

--vdoPhysicalSize=1T --vdoLogicalSize=1.25T
--albireoMem=0.25
--vdoSlabSize=2G --writePolicy=sync
--vdoReadCache=enabled --vdoReadCacheSize=20M --blockMapCacheSize=1.25G

Vertica 数据库

为此项目创建的 Vertica 数据库是一个 3 节点集群，K-safety=1（数据副本，节点偏移 1）。我们执行了所有预安装系统用户和操作系统配置要求。数据库安装顺利，没有警告或失败。（一个例外是关于 LVM 处于活动状态的警告。）

我们使用了所有开箱即用的 Vertica 配置和资源管理器设置，未进行任何性能调优。所有测试的 CATALOG 文件系统为标准 ext4。标准 ext4 测试将 DATA、TEMP 文件系统设置为两个标准 ext4 文件系统中的第一个（/data1），VDO 测试设置为两个 VDO ext4 文件系统中的第一个（/vdo1）。

标准 ext4 数据库存储配置： 

tpcds_data=> SELECT node_name,storage_path,storage_usage FROM disk_storage;
node_name               | storage_path                                                         | storage_usage
v_tpcds_data_node0001   | /catalog/vcatalog/tpcds_data/v_tpcds_data_node0001_catalog/Catalog   | CATALOG
v_tpcds_data_node0001   | /data1/vdata1/tpcds_data/v_tpcds_data_node0001_data                  | DATA,TEMP
v_tpcds_data_node0002   | /catalog/vcatalog/tpcds_data/v_tpcds_data_node0002_catalog/Catalog   | CATALOG
v_tpcds_data_node0002   | /data1/vdata1/tpcds_data/v_tpcds_data_node0002_data                  | DATA,TEMP
v_tpcds_data_node0003   | /catalog/vcatalog/tpcds_data/v_tpcds_data_node0003_catalog/Catalog   | CATALOG
v_tpcds_data_node0003   | /data1/vdata1/tpcds_data/v_tpcds_data_node0003_data                  | DATA,TEMP

VDO ext4 数据库存储配置： 

tpcds_vdo=> SELECT node_name,storage_path,storage_usage FROM disk_storage;
node_name              | storage_path                                                       | storage_usage
v_tpcds_vdo_node0001   | /catalog/vcatalog/tpcds_vdo/v_tpcds_vdo_node0001_catalog/Catalog   | CATALOG
v_tpcds_vdo_node0001   | /vdo1/vdata1/tpcds_vdo/v_tpcds_vdo_node0001_data                  | DATA,TEMP
v_tpcds_vdo_node0002   | /catalog/vcatalog/tpcds_vdo/v_tpcds_vdo_node0002_catalog/Catalog   | CATALOG
v_tpcds_vdo_node0002   | /vdo1/vdata1/tpcds_vdo/v_tpcds_vdo_node0002_data                  | DATA,TEMP
v_tpcds_vdo_node0003   | /catalog/vcatalog/tpcds_vdo/v_tpcds_vdo_node0003_catalog/Catalog   | CATALOG
v_tpcds_vdo_node0003   | /vdo1/vdata1/tpcds_vdo/v_tpcds_vdo_node0003_data                  | DATA,TEMP

测试套件

我们使用为 Vertica 环境配置的 TPC_DS 标准化测试套件的副本进行测试。TPC_DS 测试套件配置用于在 Vertica 数据库中生成、加载和查询数据。为本研究更改的配置设置包括：

  • 存储生成数据和查询的文件夹（标准 ext4 或 VDO ext4 文件系统）
  • 生成数据的大小
  • 执行查询的并发用户数
  • 加载线程数
  • 并发加载数
# 存储生成数据的文件夹
dataPath="/data2 or vdo2/tpc_ds/tpcds-source"
# 存储生成查询的文件夹
queriesPath="/data2 or vdo2/tpc_ds/tpcds-queries"
# 生成的数据量（GB）
size=850
# 测试用户数
# users="10 20 30"
users="1 5 10 15 20 25"
repetitions=1
# 每主机生成数据的进程数
loadThreads=24
# 复制测试脚本和 TPC_DS 文件夹的路径
tpcdsFolder="$HOME/tpcds_vertica"
# 每节点并发加载数
concurrentLoads=10

测试套件配置了以下功能： - 数据生成：为所有表生成随机数据，原始大小范围从 100 GB 到 750 GB - 数据加载：从生成的 .dat 文本文件加载数据。加载线程设置为 24（一半虚拟 CPU），并发加载数设置为 10 - 查询生成：生成 99 个不同复杂度的查询，由指定数量的用户执行指定次数的重复 - 查询执行：运行 99 个查询，并发用户数从 1 到 25 递增（步长 5） - 报告：收集用于生成结果报告的时间和资源数据。唯一的修改是禁用了 Vertica scrutinize 步骤，因为它为每次测试运行增加了大量时间且最终未用于分析测试结果

恢复测试包括： 1. 使用 admintools 优雅地关闭 node0003，删除数据文件系统下的所有文件，从头恢复，并确认恢复成功和数据一致性 2. 在密集加载期间，使用 HP 服务器的 iLo 接口强制立即关闭主机电源（模拟断电），然后重新启动节点，允许恢复，并确认恢复成功和数据一致性

性能测试包括： 1. 生成数据、加载数据、生成查询，并运行 5 个并发用户查询。显示时间差异以及这些差异是否线性 2. 已加载静态数据，生成查询，并运行递增数量的并发用户查询。显示时间差异以及这些差异是否线性

额外捕获的数据包括： - 在 Linux、vdoStats 和 Vertica 级别审查 750 GB 测试数据集源文件和已加载数据库数据文件的占用空间

测试说明

所有测试首先使用标准 ext4 文件系统（用于 TPC_DS 测试文件和 Vertica 数据库数据存储位置），然后使用 VDO ext4 文件系统重复测试。

每次测试运行之间，我们按以下方式清除 Linux 和 Vertica 缓存： 

$ echo 3 >/proc/sys/vm/drop_caches
$ vsql -A -w '$vertica$' -c "select clear_caches();"

VDO 评估指南建议在测试之间重新创建 VDO 卷。这很耗时。我们运行了在测试之间重新创建和不重新创建 VDO 卷的测试，结果相似。

测试结果

恢复测试

从头恢复测试： 数据库的第三个节点在并行加载过程中被优雅地关闭。我们删除了数据存储位置中的数据文件，然后重新启动该节点并监控其恢复和数据一致性。

数据文件系统类型 崩溃类型 恢复成功？ 说明
ext4 LoseDataDir 是 恢复后，加载到节点停止时的数据一致
VDO LoseDataDir 是 恢复后，加载到节点停止时的数据一致

iLo 强制断电恢复测试： 使用 HP 的 iLo 接口向第三个节点发送强制断电指令，模拟电源故障。使用 iLo Power On 重新启动故障节点，并监控其恢复和数据一致性。

数据文件系统类型 崩溃类型 恢复成功？ 说明
ext4 iLo 是 恢复后，加载到节点停止时的数据一致
VDO VDO 是 恢复后，加载到节点停止时的数据一致

在从头恢复和 iLo 强制断电恢复测试中，不需要重建 VDO 索引。正常重启和恢复后一切正常。

生成、加载和五并发用户查询测试

在生成、加载和五并发用户测试中，我们每次运行时增加测试数据的大小，从 250 GB 开始，到 750 GB 结束。这主要是为了观察增加数据大小是否会显著影响 VDO 环境中的性能。数据生成和查询时间在文件系统类型之间基本一致。随着数据量增加，VDO 似乎引入了一些性能延迟。额外测试的运行表明加载时间差异取决于数据大小和并发用户数。

截图

静态数据加载、生成查询和递增并发用户查询测试

此测试的目的是观察是否会增加打开和读取的文件数，以及这种增加是否会显著影响性能。结果显示影响不大。随着用户数增加，查询时间的偏差很小。

截图

捕获的占用空间信息

占用空间数据在标准 ext4 数据库和 VDO ext4 数据库的 750 GB 加载后捕获。由于 albscan 工具报告预计节省 3%，预期差异很小。

  • 标准 ext4：/data1 包含数据库存储容器文件，/data2 包含生成的查询和源数据文件
  • VDO ext4：/vdo1 包含数据库存储容器文件，/vdo2 包含生成的查询和源数据文件

df 命令输出： 

Filesystem                               1K-blocks     Used   Available Use% Mounted on
/dev/sdb2                                1007245124  196456840  759616472 21% /data1
/dev/sdb3                                 912708596  230539092  635799892 27% /data2
/dev/mapper/vdotest_vol_group-vdo_vol1--index  5160576  4542212    356220 93% /mnt/dedupe-index-vdo_vol1
/dev/mapper/vdotest_vol_group-vdo_vol2--index  5160576  4542212    356220 93% /mnt/dedupe-index-vdo_vol2
/dev/mapper/vdo_vol1                     1320986612  196454824 1057422924 16% /vdo1
/dev/mapper/vdo_vol2                     1320986612  230537268 1023340480 19% /vdo2

du 命令（Vertica 数据存储目录）： 

[dbadmin@partg9-004 ~]$ du -b --max-depth=1 /data1/vdata1/tpcds_data
201092244549 /data1/vdata1/tpcds_data/v_tpcds_data_node0001_data
[dbadmin@partg9-004 ~]$ du -b --max-depth=1 /vdo1/vdata1/tpcds_vdo
201092243589 /vdo1/vdata1/tpcds_vdo/v_tpcds_vdo_node0001_data

TPC_DS 加载源文件目录的 du 命令： 

[dbadmin@partg9-004 ~]$ du --max-depth=1 /data2/tpc_ds/tpcds-source
230400832 /data2/tpc_ds/tpcds-source
[dbadmin@partg9-004 ~]$ du --max-depth=1 /vdo2/tpc_ds/tpcds-source
230400832 /vdo2/tpc_ds/tpcds-source

VDO 工具报告（vdoStats）： 

[dbadmin@partg9-004 ~]$ sudo vdo-5.2.1.74/bin/vdoStats --human-readable --si /dev/mapper/vdo_vol1
Device             Size   Used      Available  Use%  Space saving%
/dev/mapper/vdo_vol1  1.1T  202.7G    896.9G     18%   11%

[dbadmin@partg9-004 ~]$ sudo vdo-5.2.1.74/bin/vdoStats --human-readable --si /dev/mapper/vdo_vol2
Device             Size   Used      Available  Use%  Space saving%
/dev/mapper/vdo_vol2  1.1T  240.0G    821.9G     22%   8%

Vertica PROJECTION_STORAGE 系统表（标准 ext4）： 

tpcds_data=> SELECT node_name, SUM(used_bytes) usedbytes, SUM(ros_used_bytes) rosbytes, SUM(ros_count) roscount FROM PROJECTION_STORAGE GROUP BY node_name ORDER BY node_name;
node_name               | usedbytes     | rosbytes      | roscount
v_tpcds_data_node0001   | 200553101330  | 200553101330  | 89
v_tpcds_data_node0002   | 200556649788  | 200556649788  | 89
v_tpcds_data_node0003   | 200556319255  | 200556319255  | 88

Vertica PROJECTION_STORAGE 系统表（VDO ext4）： 

tpcds_vdo=> SELECT node_name,SUM(used_bytes) usedbytes, SUM(ros_used_bytes) rosbytes, SUM(ros_count) roscount FROM PROJECTION_STORAGE GROUP BY node_name ORDER BY node_name;
node_name              | usedbytes     | rosbytes      | roscount
v_tpcds_vdo_node0001   | 200553100370  | 200553100370  | 89
v_tpcds_vdo_node0002   | 200556649691  | 200556649691  | 88
v_tpcds_vdo_node0003   | 200556318934  | 200556318934  | 89

结果总结

本次技术探索的重点是测试 VDO 在 Vertica 环境中的透明性。我们运行了数天的持续资源密集型测试，还运行了模拟系统和 Vertica 故障的特定测试。我们没有观察到任何异常结果。文件系统始终保持响应和稳定。除了安装时对 LVM 的检查外，VDO 服务和文件系统对 Vertica 是透明的。

在高并发查询情况下，小数据集的性能影响最小，但随着数据集大小的增加，性能影响也会增加。我们确定结果因许多调优因素和 Vertica 数据特征而异。一些 Linux 级别的操作显示出性能影响，例如挂载时的 discard/nodiscard 选项和 VDO 的 max_discard_sectors 参数对结果有一定影响。因此，观察到的性能影响不是 Vertica 特定的行为。

我们没有尝试完全优化，因为这超出了本次探索的范围。在生产环境中，系统管理员应根据该实现的特定情况优化 Vertica 和 VDO。

空间节省方面没有发现巨大收益。750 GB 运行的 vdoStats 显示使用的块节省了 11%，这比 VDO 分析工具报告的 3% 要好。结果可能因许多调优因素和 Vertica 设计及数据而异。

我们使用 Vertica 的 vioperf 工具检查磁盘 I/O 吞吐量是否满足 Vertica 要求。我们发现 vioperf 不能在 VDO 卷上运行，除非 VDO 卷创建时设置了 512 兼容模式。

截至本次测试（2017 年 1 月），Vertica 不支持 VDO 的基础要求 LVM。在 LVM 完全合格之前，我们不建议在生产环境中使用 LVM。

建议

根据测试结果，我们提出以下建议：

  1. LVM 兼容性：Permabit VDO 以 LVM2 为基础要求。截至 2017 年 1 月，Vertica 当前不支持使用 LVM。Vertica 服务器安装程序会检查活动的 LVM 文件系统，如果发现则会发出警报。您可以在激活 LVM 和安装 VDO 之前安装 Vertica，或者使用 install_vertica 的 -failure-threshold=NONE 参数绕过警告（前提是您已解决它可能报告的所有其他问题）。

  2. 寻求 Permabit 支持：在要求、容量规划、设置、配置和微调方面，尤其是处理索引、缓存和同步/异步 writePolicy 选项的最佳实践时，请咨询 Permabit 以获取帮助。

  3. VDO 卷参数：VDO 分析工具报告预期的去重和压缩空间节省。此工具可用于计算 VDO 卷创建参数值。如果将 logicalSize 设置为大于 physicalSize 的值，请按相同比例增加 blockMapCacheSize。我们建议每 1 TB 逻辑空间使用 1 GB 内存。例如，如果将 logicalSize 增加 25%，也应将 blockMapCacheSize 增加 25%： 

    --vdoPhysicalSize=1T
--vdoLogicalSize=1.25T
--blockMapCacheSize=1.25G

  4. 测试使用的 VDO 卷参数： 

    --vdoPhysicalSize=1T
--albireoMem=0.25
--vdoSlabSize=2G
--writePolicy=sync
--vdoReadCache=enabled
--vdoReadCacheSize=20M
--blockMapCacheSize=1.25G

  5. discard/nodiscard 选项：RHEL 6 中 ext4 的 discard/nodiscard 选项默认值为 nodiscard。本探索中的 VDO 文件系统挂载时使用了 discard，以确保在文件删除时丢弃未使用的块。discard 选项使 VDO 取消映射已丢弃的块并快速回收 VDO 卷上未使用的物理空间。discard 和 nodiscard 各有优缺点，如果在 Vertica 中实施，请审查这些结果。

  6. VDO 安装问题：如果 VDO 安装报错说构建或源目录中没有头文件，请尝试以下方法之一： 

    # 方法 1：为您的 RHEL 版本强制安装内核头文件
$ sudo yum install "kernel-devel-uname-r == $(uname -r)"

# 方法 2：安装以下内核版本对应的包
kernel-debug-devel.x86_64
kernel-headers.x86_64

  7. 重启后自动挂载：确保按照步骤设置 VDO 卷在主机重启时重新挂载。否则，您配置为使用这些卷的任何 Vertica 资源将无法找到它们，并会产生各种错误。

  8. K-safety 与去重：Vertica 用户可能认为如果数据库运行 K-safety=1 且有数据副本，可以获得很大的去重节省。但事实并非如此。目前，VDO 进程仅在其运行的主机上进行去重和压缩，没有集群范围的能力。

  9. vioperf 兼容性：如果对 VDO 卷运行，Vertica 的 vioperf I/O 基准测试工具会失败，显示 Error creating aligned memory。默认情况下，VDO 卷使用 4k 块格式化，而 vioperf 期望 512 字节块。因此，不能在默认的 VDO 4k 块卷上使用 vioperf。可以在 VDO 卷创建时启用兼容模式使其变为 512 字节，但这可能会影响性能。我们未测试此模式。

  10. 监控 VDO 卷空间：持续监控挂载在 VDO 卷上的文件系统的可用空间至关重要。如果卷空间耗尽，它将进入强制只读模式。此模式可能带来挑战。例如，如果您没有准备 LVM 和 VDO 以允许添加存储，并且空间耗尽进入只读模式，Vertica 将停止运行并且不会重新启动，直到您添加更多空间。准备工作以允许卷增长和监控使用情况对于文件系统的不间断使用至关重要。

原文来源：https://www.vertica.com/kb/Permabit-Tech-Exploration_HTML/Content/Partner/Permabit_Tech_Exploration.htm