Vertica RAID 存储方案

编译：JiangChong

原文：RAID Storage for Vertica（2023-06-01）

📝 文章说明：本文基于 Vertica 官方 KB 原文翻译整理。原文发布于 2023 年，仅讨论了 Enterprise 模式下的 RAID 存储方案（RAID 0/1+0/5/5+0、硬件 vs 软件 RAID），未涉及 Eon 模式 Depot 缓存存储的配置策略。译者根据当前 Vertica v26.2 技术架构与 vault 已有技术笔记，补充了 Eon 模式 Depot 存储配置（NVMe 直挂 vs RAID、Depot 容量规划、缓存命中率监控、Depot 禁用评估）。新增内容位于「Eon 模式 Depot 存储配置」章节。

适用版本： 本文基于 Enterprise Mode 本地部署编写。Eon Mode 计算节点也需本地磁盘（depot），但容量需求不同。示例硬件 HPE DL380 Gen9 为 2014–2017 代产品，当前应参考 硬件与虚拟机配置资源 获取最新推荐。vioperf 在两模式下均适用。

1. Vertica 存储选项

Vertica 支持的存储选项包括：

• 内部硬件存储阵列
• SAN（存储区域网络）
• NAS（网络附加存储）
• DAS（直连存储）机箱

每种存储选项应向集群中的每个主机提供一个单一的本地文件系统。此外，存储必须根据 Vertica 知识库中 Vertica Hardware Guide 推荐的指南提供足够的带宽。

Vertica 采用高并发、横向扩展的 shared-nothing 集群架构。虽然某些集群环境可以使用共享存储设备，但对于 Vertica 来说，共享存储会显著限制性能。

本文帮助你理解不同 RAID 存储选项之间的性价比权衡。选择共享存储是一个重要决策，因为某些设备会影响性能。

2. RAID 存储

2.1 RAID 架构对比

下图展示了 RAID 0、RAID 1+0、RAID 5 和 RAID 5+0 架构之间的主要差异。每种 RAID 架构将多个独立磁盘组合成操作系统看到的单个逻辑卷。除 RAID 0 外，所有 RAID 选项都提供一定程度的磁盘保护。

RAID 不是数据备份的一种形式。RAID 提高的是磁盘故障时存储阵列的可用性。在任何服务器或存储系统中，机械磁盘比 CPU 或内存芯片更容易发生故障。请务必按照 Vertica 文档中 备份与恢复数据库 的说明定期备份数据。

3. RAID 存储方案选择

每种 RAID 存储方案在成本、性能和可用性之间提供不同的平衡。没有任何 RAID 方案能同时优化这三者。下表描述了每种方案及其优缺点。

注意： 硬件选型和组合涉及磁盘、RAID 控制器、服务器和操作系统的广泛搭配。请始终查阅 硬件与虚拟机配置资源 获取最新推荐。

RAID 方案	优点	缺点	说明
RAID 0	成本低、I/O 性能好	无数据保护	不要对 Vertica 集群使用 RAID 0。选择其他 RAID 方案。
RAID 1+0	磁盘故障时数据保护、整体性能好、磁盘重建时间短、写性能好	—
RAID 5	磁盘故障时数据保护、可用容量高、相比同容量 RAID 1+0 成本更低	写性能差、磁盘重建时间长、重建期间性能下降、校验数据损坏时存在数据损坏风险、同一 RAID 组中可能发生多盘故障	如果选择 RAID 5，应配备热备盘以应对 RAID 组中需要替换的故障磁盘。
RAID 5+0	磁盘故障时数据保护、RAID 0 条带化、性能/成本/可用性/容量的平衡	并非所有硬件 RAID 阵列都支持

4. 硬件 RAID vs 软件 RAID？

对于 Vertica 集群，应使用带有专用控制器的硬件 RAID。 硬件 RAID 控制器管理一组磁盘，并将其作为单个大卷呈现给主机。

软件 RAID 将 RAID 任务置于操作系统和 CPU 上运行。软件 RAID 会给 Vertica 主机带来显著开销——高达 40%——因此不适合 Vertica。此外，软件 RAID 的性能低于专用硬件 RAID 控制器。在软件 RAID 配置中，操作系统管理每个独立磁盘，导致 CPU 负载增加。

在虚拟环境中，由于磁盘设备大小可能受限，使用软件 RAID 可能是合适的。

5. 推荐的 RAID 配置

下图展示了 Vertica 节点的推荐大小和卷配置（以 HPE ProLiant DL380 Gen9 24-SFF 服务器为例）：

每个节点包含两个内部镜像磁盘，用于存放操作系统、/opt 目录下的 Vertica 软件以及 catalog 磁盘。操作系统磁盘可使用 300 GB 或 600 GB 的磁盘，采用 RAID 1 镜像。

/data 卷通常容量为 6–10 TB，使用最多 24 块磁盘构建为 RAID 1+0。Vertica 数据库文件存放在此区域。I/O 性能非常重要，每个 CPU 核心至少应达到 60–80 MB/s 的吞吐量。例如，24 核节点应提供 1.4 GB/s 到 1.9 GB/s 的读写 I/O 吞吐量。

5.1 缓存设置

对于 HPE P840 PCIe 卡，将读缓存设为 10%，写缓存设为 90%。对于其他类型的存储，始终运行 vioperf（Vertica I/O 性能测试）来验证每种配置。

5.2 块大小

256 KB 到 512 KB 的大块顺序 I/O 读取效果最佳。8–32 KB 的小块适用于事务性工作负载，但不适合 Vertica 数据库。

版本说明： 以上 RAID 配置针对 Enterprise Mode 本地部署。Eon Mode 中 /data 目录用作 depot（本地缓存），容量可按热数据比例调整，不强制要求 6–10 TB。建议始终运行 vioperf 验证实际 I/O 性能。

---

6. Eon 模式 Depot 存储配置

本章为补充内容。原文基于 Enterprise 模式，仅讨论 RAID 作为持久数据存储方案。但在 Eon 模式存算分离架构下，节点本地磁盘的角色从「永久数据存储」转变为「Depot 缓存」——这意味着 存储选型逻辑发生根本性变化：不需 RAID 冗余保护（数据已在公共存储持久化），重在 I/O 性能与容量匹配工作集。

6.1 架构差异：Enterprise 存储 vs Eon Depot

维度	Enterprise Mode	Eon Mode
本地存储角色	数据永久存储	Depot 缓存（LRU 淘汰）
数据持久性保障	本地磁盘 + RAID 冗余	公共存储（S3/HDFS/GCS）
磁盘故障影响	可能丢数据（无 RAID）→ 需恢复	节点不可用，数据仍在公共存储
RAID 必要性	必须（数据保护）	不建议（额外开销，无收益）
推荐硬件	HDD RAID 10（原文推荐） / NVMe RAID 10	NVMe SSD 直挂 ext4，不用 RAID/LVM
容量规划依据	全量数据 / 压缩比	热数据工作集 × 1.67（含 40% catalog+临时空间）
I/O 关注点	读写吞吐（顺序读写为主）	读吞吐为主（Depot 命中时） + 公共存储延迟（未命中时）

核心原则：Depot 不是备份，RAID 保护不必要。RAID/LVM 的额外管理开销会拖慢 I/O 路径，抵消 NVMe 的低延迟优势。 来源：Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践

6.2 Depot 存储硬件选型

6.2.1 NVMe SSD 直挂（推荐）

Eon 节点本地 Depot 应使用 NVMe SSD 直接以 ext4 分区挂载，原因：

• 数据已在公共存储持久化：RAID 的磁盘冗余保护完全多余。节点本地磁盘故障时，数据从公共存储重新拉取即可
• RAID/LVM 有额外处理开销：RAID 控制器或软件 RAID 对每个 I/O 需计算校验/条带映射，增加延迟
• NVMe PCIe Gen4/Gen5 吞吐：顺序读 ≥3000 MB/s，远超原文中 HDD 阵列的 1.4–1.9 GB/s 目标，且队列深度更大、延迟更低

来源：Vertica 官方 KB 明确建议 "avoid RAID or LVM for depot. Use as an ext4 partition." — Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践

6.2.2 多盘场景处理

Vertica 每个节点仅允许一个 Depot 存储位置。如果节点配有多块 NVMe SSD，需在创建数据库之前将其合并为单个文件系统：

策略	做法	说明
单盘大容量（推荐）	一块大容量 NVMe（如 7.68 TB）挂载为单一 Depot 路径	最简单、性能最优
LVM 聚合	多块 NVMe 用 LVM 合并为单个逻辑卷 → ext4 挂载	可行但 LVM 有额外开销，Vertica 不建议
md RAID 0	多块 NVMe 用 mdadm RAID 0 条带化	容量聚合，无冗余；RAID 开销抵消 NVMe 低延迟优势

来源：v26.2 官方文档明确 "Vertica allows a single DEPOT storage location per node."（17-03-projections-and-storage.md）。因此强烈建议优先选大容量单盘，避免 LVM/RAID 引入的额外 I/O 开销。

# 单块大容量 NVMe（如 7.68 TB）挂载为 depot 路径
# /dev/nvme0n1 → /depot（ext4）
$ /opt/vertica/bin/admintools -t create_db -d eondb \
  --hosts=node1,node2,node3 \
  --shard-count=6 \
  --depot-path=/depot

6.2.3 何时仍用 SSD RAID（边缘场景）

以下场景可能仍需为 Depot 配置 RAID：

• SATA SSD 容量不足：多块小容量 SATA SSD 需 RAID 0 拼凑容量，但 NVMe 大容量单盘通常更优
• 运维习惯/采购约束：仅提供 RAID 卡服务器且不能改造时，优先使用 RAID 卡的 JBOD/passthrough 模式直通磁盘；若不支持，可退而将每块盘配置为单盘 RAID 0（不做数据保护，仅绕过 RAID 固件限制）

---

6.3 Depot 容量规划

6.3.1 核心公式（N ≤ S 场景适用）

当节点数不超过分片数（每个节点至少承担一个完整分片）时：

来源：Vertica v26.2 官方文档 + Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 + Vertica 节点与集群规模规划指南

① 每节点 Depot 大小 = 压缩后工作数据集 / 子集群节点数
② 每节点本地存储 ≥ max(Depot / 60%, 2 TB)

注意：当 N > S（ECS 弹性扩展）时，每个节点只承担部分分片。此时 6.3.1 公式会严重低估 Depot 需求，应改用 6.3.2 以分片粒度估算。

Step ② 的 × 1.67 系数：Depot 默认占文件系统的 60%（其余 40% 用于 catalog + 查询 Spill 临时空间）。计算后取 max(结果, 2 TB)，因为官方最低要求每节点本地存储 ≥ 2 TB。

6.3.2 以分片粒度估算（N ≥ S 场景）

当节点数 ≥ 分片数时：

每节点 Depot = (总压缩数据 / 分片数 S) × 每节点计划缓存的分片数

实际中一个节点通常至少缓存 2 个分片以留余量。例如总压缩数据 1.2 TB、S=6 → 每分片 200 GB，每节点缓存 2 个分片 → Depot ≈ 400 GB。

6.3.3 容量示例

场景	压缩工作集	子集群节点	每节点 Depot	每节点本地存储（≥）
小型	3 TB	3	1 TB	2 TB（最低要求兜底）
中型	12 TB	6	2 TB	4 TB
大型	48 TB	12	4 TB	8 TB
超大型	192 TB	12	16 TB	32 TB

每节点本地存储 ≥ 2 TB 为官方最低要求。上表小型场景计算值 1.7 TB 低于底线，取 2 TB。超大型场景演示节点数不足时每节点 Depot 需求急剧上升（192 TB / 12 节点 = 16 TB/节点），实际应通过增加节点数或使用 ECS 弹性扩展来分摊。

6.3.4 Depot 关键约束

• 规划目标：工作集完整缓存。Depot 应容纳全量热数据，避免查询时从公共存储拉取。缓存未命中导致查询延迟大幅上升
• Depot 不能超过文件系统的 80%（--depot-size 硬上限）
• 默认值：不指定 --depot-size 时，Depot 自动占文件系统的 60%

---

6.4 Depot 配置操作示例

6.4.1 创建数据库时指定 Depot（admintools）

# S3 公共存储（如 AWS）
$ /opt/vertica/bin/admintools -t create_db -d eondb \
  --hosts=node1,node2,node3 \
  --communal-storage-location=s3://my-vertica-bucket \
  --depot-path=/data/depot \
  --depot-size=400G \
  --shard-count=6

# HDFS 公共存储
$ /opt/vertica/bin/admintools -t create_db -d eondb \
  --hosts=node1,node2,node3 \
  --communal-storage-location=webhdfs://namenode:50070/vertica \
  --depot-path=/data/depot \
  --depot-size=60% \
  --shard-count=6

6.4.2 运行时调整 Depot 大小（SQL）

-- 修改所有节点的 Depot 容量上限（空字符串 = 所有节点）
SELECT ALTER_LOCATION_SIZE('depot', '', '500G');

-- 针对特定节点修改
SELECT ALTER_LOCATION_SIZE('depot', 'v_eondb_node0001', '50%');

-- 针对整个子集群修改
SELECT ALTER_LOCATION_SIZE('depot', 'query_subcluster', '75%');

参数说明（来源：v26.2 SQL Reference ALTER_LOCATION_SIZE）：

• 第 1 参数：'depot' 关键字（也可用 depot 绝对路径，但关键字更简洁）
• 第 2 参数：'' = 所有节点 / 节点名 / 子集群名
• 第 3 参数：整数%（文件系统百分比）或 整数{K|M|G|T}（绝对大小），上限 80%

---

6.5 监控 Depot 缓存命中率

Depot 命中率是 Eon 模式性能的核心指标。监控方法详见于 Vertica 监控最佳实践 第 11.3 节，以下列出关键查询。

6.5.1 Depot 容量使用

-- 每个节点的 Depot 容量与使用率
SELECT node_name, location_path,
       (current_usage_bytes / 1073741824.0)::NUMERIC(10,2) AS usage_gb,
       (max_size_bytes / 1073741824.0)::NUMERIC(10,2) AS max_gb,
       ROUND(current_usage_bytes * 100.0 / max_size_bytes, 1) AS pct_used
FROM v_monitor.depot_sizes
ORDER BY node_name;

告警：pct_used 持续 >90% → Depot 不足，考虑扩容。来源：DEPOT_SIZES

6.5.2 从公共存储拉取频率（反映缓存未命中）

SELECT node_name,
       COUNT(*) AS fetch_count,
       (SUM(file_size_bytes) / 1048576.0)::NUMERIC(12,2) AS total_mb
FROM v_monitor.depot_fetches
WHERE start_time > SYSDATE - INTERVAL '1 hour'
GROUP BY node_name
ORDER BY fetch_count DESC;

fetch_count 高 → 频繁从公共存储拉取。可能原因：Depot 不足、工作负载变化、节点重启后冷启动。来源：DEPOT_FETCHES

6.5.3 逐出命中次数推算缓存效率

SELECT node_name,
       COUNT(*) AS eviction_count,
       SUM(number_hits) AS total_hits,
       ROUND(AVG(number_hits), 1) AS avg_hits_per_object
FROM v_monitor.depot_evictions
WHERE start_time > SYSDATE - INTERVAL '24 hours'
GROUP BY node_name
ORDER BY eviction_count DESC;

number_hits 高的对象被逐出 = 热数据被挤出（Depot 不够大）。近似命中率：hit_rate ≈ 1 - (fetch_count / (fetch_count + total_hits))。来源：DEPOT_EVICTIONS

---

6.6 Depot 禁用评估

当公共存储延迟极低时（如 Pure Storage FlashBlade 本地对象存储），可考虑禁用 Depot：

-- 禁用 Depot 读取（数据直接从公共存储读取）
ALTER DATABASE DEFAULT SET PARAMETER UseDepotForReads = 0;

关键指标（来源：v26.2 官方文档 09-eon-mode.md）：

• 禁用 Depot 后查询性能下降 30%–4000%（取决于工作负载）
• 仅在显著减少本地存储需求且性能影响可接受时才考虑
• 生产环境禁用前必须做 PoC，使用相同工作负载验证

典型适用场景：FlashBlade 本地部署 + 读写负载极低 + 硬件预算严格受限。绝大多数场景下 不建议禁用 Depot。

---

6.7 Enterprise vs Eon 存储选型决策框架

是否需要本地数据持久化？
├── 是（Enterprise Mode）
│   ├── 预算充足、性能优先 → NVMe SSD RAID 10（推荐）
│   ├── 预算受限、大容量 → HDD 阵列 RAID 10（≥20 盘）
│   └── 虚拟化环境 → 软件 RAID（受限于虚拟磁盘大小）
│
└── 否（Eon Mode，数据在公共存储）
    ├── 通用场景 → NVMe SSD 直挂 ext4（Depot 缓存）
    │   ├── 单盘 ≥ 2 TB → 单一 Depot 路径，直接挂载
    │   └── 多盘小容量 → 大容量单盘优先；必要时 LVM/RAID0 合并（有开销）
    ├── 公共存储低延迟（FlashBlade 等）
    │   ├── 工作负载重 → Depot 保留（调小 Depot 至最小值即可）
    │   └── 硬件预算极端受限 → 评估 Depot 禁用（先 PoC！）
    └── Depot 容量确定
        ├── N ≥ S → Depot = (总压缩数据/S) × 2 分片
        ├── N < S → Depot = 总压缩数据/N（全量缓存）
        └── 最终值 = max(计算值, 200 GB)

---

扩展阅读

• Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 — Eon Depot 选择核心指南
• Vertica 节点与集群规模规划指南 — 含 Eon Depot 容量规划详细公式
• Vertica 监控最佳实践 — Depot 命中率监控与告警（§11.3）
• Vertica 节点与集群规模推荐