> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/zh/mo-kuai-5-cun-chu/02-storage-tiers.md).

# 存储层级

## VergeOS 存储分层模型

VergeOS vSAN 将物理存储组织为 **5 个工作负载层级（1–5）加一个专用元数据层（第 0 层）**，每一层都针对特定类型的工作负载或数据类型设计。该分层架构使组织能够通过将 VM 虚拟磁盘配置到最适合其工作负载配置文件的层级上，在性能、容量和成本之间取得平衡。

### 第 0 层 — 元数据

vSAN 文件系统索引和各层设备映射。控制器节点必需。不是缓存——仅用于元数据。

### 第 1–3 层 — 性能

分别用于写密集型、混合型和读优化型工作负载的 NVMe 和 SSD 层。

### 第 4–5 层 — 容量

用于文件服务器、备份目标、合规归档和冷存储的 HDD 层。

与使用单一池并在后台移动数据的存储平台不同，VergeOS 让管理员明确控制数据所在位置。您在配置 VM 磁盘时选择层级，数据会在虚拟磁盘生命周期内保留在该层级上。

## 层级规格

下表概述了各层级的硬件类型、用途和典型用例：

| 层     | 介质类型         | 用途        | 典型用例                   |
| ----- | ------------ | --------- | ---------------------- |
| **0** | 高耐久 NVMe     | vSAN 元数据  | 文件系统索引、各层设备映射——控制器节点必需 |
| **1** | 高耐久 NVMe SSD | 写入密集型工作负载 | 高性能数据库、事务日志、写入密集型应用    |
| **2** | 中端 SSD       | 读写混合型工作负载 | 通用 VM、混合应用工作负载、开发/测试   |
| **3** | 读优化 SSD      | 读取密集型工作负载 | 内容分发、应用程序仓库、参考数据       |
| **4** | 大容量 HDD      | 大容量       | 文件服务器、备份目标、低频访问数据      |
| **5** | 归档级 HDD      | 冷存储 / 归档  | 合规归档、长期保留、监管数据         |

### 第 0 层：元数据层

第 0 层值得特别关注，因为它与工作负载层级根本不同。它存储 **仅** vSAN 元数据——文件系统索引以及用于推导块放置的各层设备映射。没有用于跟踪块位置或引用计数的中心表：放置是根据每个块的内容哈希与设备映射计算得出的，而引用计数由 vSAN Walk 重建。

**容量规划指南：** 大约分配 **每 1 TB 可用存储分配 5 GB 的第 0 层容量** （最低）或 **每 1 TB 10 GB** （推荐）分配到各工作负载层级。使用额定为 **3 DWPD 或等效指标（即 TBW）**。始终保持至少 **30% 的可用空间** 以避免元数据压力。

**硬件要求：** 使用企业级 NVMe 驱动器，最低要求 **3 DWPD** （每日驱动器写入量）耐久度。生产环境中不支持使用消费级 NVMe 驱动器作为第 0 层。

### 工作负载层级（1–5）

第 1 至第 5 层存储实际的 VM 数据。并非每个部署都需要全部五个工作负载层级——许多生产环境只使用两层或三层。层级编号是一种排序系统：数字越小表示性能越高（且通常每 GB 成本更高），数字越大表示容量越高（每 GB 成本更低）。

**常见部署模式：**

* **全闪存：** 第 0 层（元数据）+ 第 1 层或第 2 层（所有 VM 工作负载）
* **混合：** 第 0 层（元数据）+ 第 2 层（性能型 VM）+ 第 4 层（文件服务器、备份）
* **多层：** 第 0 层（元数据）+ 第 1 层（数据库）+ 第 2 层（通用 VM）+ 第 4 层（文件共享）+ 第 5 层（归档）

### 首选层级行为

在创建或修改 VM 虚拟磁盘时，您会设置一个 **首选层级**。大多数部署会将其保留为系统默认值，该默认值可在以下位置配置： **系统 > 系统设置 > 默认 VM 磁盘层级**。如果指定的层级在集群中不存在：

* **请求的层级高于可用层级：** 系统会选择下一个更高（更慢）的层级。例如，在只有第 1 层和第 4 层的系统中请求第 3 层，会放置到第 4 层。
* **请求的层级低于可用层级：** 系统会选择下一个更低（更快）的层级。例如，在只有第 1 层和第 2 层的系统中请求第 3 层，会放置到第 2 层。

这种回退行为可确保即使没有精确请求的层级，也始终可以配置 VM。

## 无自动分层

这是理解 VergeOS 存储时最重要的概念之一：

{% hint style="danger" %}
**关键概念：无自动数据迁移**

VergeOS 并不 **不会** 根据访问模式执行自动冷热分层。不存在基于策略的数据迁移。数据会保留在其配置的层级上，除非管理员更改磁盘的首选层级——这会触发在线后台迁移且不会产生停机。层级分配是管理员的决策。
{% endhint %}

这种设计是有意为之，并带来多项优势：

* **可预测的性能** — 工作负载可获得一致的 I/O 特性，因为其数据不会意外迁移到更慢的介质
* **简单的容量规划** — 每个层级的容量只会被明确配置的工作负载消耗
* **无后台开销** — 没有分层引擎消耗 CPU、内存或 I/O 带宽来分析和移动数据
* **清晰的成本模型** — 存储成本可直接映射到已配置的层级

要更改工作负载的层级放置，管理员必须手动将 VM 的虚拟磁盘移动到其他层级。这是一项有意的运维决策，而不是自动化流程。

```mermaid
flowchart TB
    subgraph PROVISION["VM 磁盘配置"]
        ADMIN["管理员选择<br/>首选层级"] --> TIER{"层级<br/>可用？"}
        TIER -->|是| PLACE["数据放置在<br/>所选层级"]
        TIER -->|否| FALLBACK["选择最近可用的<br/>层级"]
        FALLBACK --> PLACE
    end

    subgraph LIFECYCLE["磁盘整个生命周期"]
        PLACE --> STAYS["数据保留在<br/>同一层级"]
        STAYS --> STAYS
    end

    STAYS -.->|"仅手动移动<br/>(管理员决策)"| MOVE["移动到<br/>其他层级"]

    style PROVISION fill:#e3f2fd,stroke:#1565c0
    style LIFECYCLE fill:#e8f5e9,stroke:#2e7d32
    style MOVE fill:#fff3e0,stroke:#e65100
```

## 驱动器分配规则

正确地将物理驱动器分配到各层级，对保持健康的 vSAN 至关重要。配置存储时请遵循以下规则：

### 规则 1：控制器节点需要第 0 层

控制器节点必须至少有一个第 0 层驱动器。第 0 层保存 vSAN 文件系统索引和各层设备映射（元数据），这些由控制器节点管理。横向扩展节点和仅存储节点提供工作负载层级（1–5），但不承载第 0 层；第 0 层仅存在于控制器节点上（N+1 为节点 1–2，N+2 为节点 1–3）。

第 0 层是 **必需的** — vSAN 将其文件系统索引和设备映射存放在那里，因此没有它，vSAN 无法挂载或运行。这就是为什么在使用任何工作负载层级之前，控制器节点必须先配置第 0 层驱动器；系统不存在可供应对的“无第 0 层”运行状态。

### 规则 2：同一层级内驱动器保持一致

同一层级内的所有驱动器应当具有 **相似的类型、容量和性能**。如果您向现有层级添加一个不同大小的驱动器，该层级将只能使用 **最小驱动器** 的容量。不建议在同一层级中混用 NVMe 和 SATA 驱动器。

### 规则 3：各节点驱动器数量一致

为了实现平衡的数据分布和最佳性能，每个存储节点应具有 **每个层级相同数量的驱动器**。例如，如果节点 1 有两块第 2 层驱动器，节点 2 也应具有两块相同类型和容量的第 2 层驱动器。

### 规则 4：每个层级跨节点分布

每个层级跨越 **所有参与存储的节点上**。块分布、冗余副本和 I/O 负载均衡在每个层级内独立运行。这意味着：

* 第 4 层驱动器故障不会影响第 1 层或第 2 层
* 一个层级上的故障不会影响其他层级的冗余——每个层级的冗余都独立跟踪。集群级冗余级别（N+1 或 N+2）统一适用于所有层级。
* 容量和性能按层级独立扩展

```mermaid
flowchart TB
    subgraph NODE1["节点 1"]
        T0_N1["第 0 层<br/>NVMe 400GB"]
        T2_N1["第 2 层<br/>SSD 1.92TB x2"]
        T4_N1["第 4 层<br/>HDD 8TB x4"]
    end
    subgraph NODE2["节点 2"]
        T0_N2["第 0 层<br/>NVMe 400GB"]
        T2_N2["第 2 层<br/>SSD 1.92TB x2"]
        T4_N2["第 4 层<br/>HDD 8TB x4"]
    end
    subgraph NODE3["节点 3"]
        T0_N3["第 0 层<br/>NVMe 400GB"]
        T2_N3["第 2 层<br/>SSD 1.92TB x2"]
        T4_N3["第 4 层<br/>HDD 8TB x4"]
    end

    T0_N1 <--> T0_N2
    T0_N2 <--> T0_N3
    T2_N1 <--> T2_N2
    T2_N2 <--> T2_N3
    T4_N1 <--> T4_N2
    T4_N2 <--> T4_N3

    style T0_N1 fill:#fff3e0,stroke:#e65100
    style T0_N2 fill:#fff3e0,stroke:#e65100
    style T0_N3 fill:#fff3e0,stroke:#e65100
    style T2_N1 fill:#e3f2fd,stroke:#1565c0
    style T2_N2 fill:#e3f2fd,stroke:#1565c0
    style T2_N3 fill:#e3f2fd,stroke:#1565c0
    style T4_N1 fill:#e8f5e9,stroke:#2e7d32
    style T4_N2 fill:#e8f5e9,stroke:#2e7d32
    style T4_N3 fill:#e8f5e9,stroke:#2e7d32
```

## 存储扩展

vSAN 支持两种扩展方式，并且每个层级都可独立扩展：

### 垂直扩展（向上扩展）

向现有节点的某个层级中添加更多驱动器。这会增加该层级的容量和聚合吞吐量，而无需增加新硬件。

**向上扩展的关键要求：**

* 确保 vSAN **30% 的可用容量** 再添加驱动器（除非您要将驱动器数量加倍）
* 新驱动器必须与该层级现有驱动器的类型、容量和性能匹配
* 向以下对象添加相同数量的驱动器 **每个存储节点** 以保持平衡分布
* 在开始向上扩展之前拍摄系统快照
* 请遵循 [vSAN 向上扩展 SOP](https://docs.verge.io/product-guide/operations/vsan-scale-up-sop/) 以了解完整流程

### 水平扩展（横向扩展）

向集群添加新节点。这会同时增加容量、计算资源和聚合 I/O 带宽。

**横向扩展的关键要求：**

* 新节点应具有 **相同的驱动器配置** 与现有节点在每个层级上保持一致
* 在添加节点之前必须验证网络连接（Core Fabric）
* 新节点通过 USB 安装并加入现有集群
* 加入后，vSAN 会自动开始向新节点分发数据
* 请遵循 [vSAN 横向扩展指南](https://docs.verge.io/implementation-guide/scale-out-nodes/) 以了解完整流程

### 扩展决策矩阵

| 因素       | 向上扩展（添加驱动器） | 横向扩展（添加节点）    |
| -------- | ----------- | ------------- |
| **容量增加** | 仅限各层级       | 所有层级 + 计算资源   |
| **性能提升** | 中等（更多盘片）    | 显著（更多节点）      |
| **计算资源** | 无变化         | 额外的 CPU + RAM |
| **故障域**  | 无变化         | 更好的分布         |
| **复杂度**  | 更低          | 更高            |
| **典型用例** | 某一层级空间不足    | 需要更多总体容量      |

## 容量规划

主动进行容量规划可防止性能下降，并确保 vSAN 在健康参数范围内运行。

### 推荐的可用空间阈值

| 层           | 最低可用空间 | 原因                    |
| ----------- | ------ | --------------------- |
| **0 层**     | 30%+   | 元数据压力会影响全系统的所有 I/O 操作 |
| **第 1–3 层** | 20–30% | 性能层需要预留空间用于去重操作和写入    |
| **第 4–5 层** | 15–20% | 容量层需要预留空间用于快照保留       |

### 需要监控的关键指标

在 VergeOS 存储仪表板中跟踪这些指标，以保持各层级健康运行：

* **每个层级的容量利用率** — 随时间趋势，用于预测何时需要扩展
* **I/O 性能（IOPS 和延迟）** — 识别可能成为工作负载瓶颈的层级
* **重复数据删除比率** — 了解每个层级的有效容量节省与原始容量节省
* **驱动器错误率** — 驱动器即将故障的早期预警
* **重建状态** — 监控驱动器更换后的自愈进度

### RAM 要求

vSAN 需要专用 RAM 来进行存储操作。请规划 **每 1 TB 原始存储配备 1 GB RAM** （最低）或 **每 1 TB 1.5 GB** （推荐）分配到每个参与存储的节点上。此 RAM 由 VergeOS 主机占用，VM 不可用。

## 与快照和克隆的集成

存储层级与 vSAN 的快照和克隆功能以重要方式交互：

* **快照感知层级** — 具有第 2 层磁盘的 VM 快照会引用第 2 层上的块。快照元数据记录在第 0 层，但数据块仍保留在其原始层级。
* **克隆引用相同层级** — 当您克隆 VM 时，克隆初始会引用同一层级上的相同数据块。克隆产生的新写入会在与原始对象相同的层级上消耗空间。
* **去重按层级运行** — 基于哈希的去重引擎在每个层级内对所有数据进行处理，节省的空间会按层级独立跟踪和报告。
* **复制针对带宽进行了优化** — 在站点同步复制期间，仅传输唯一块（感知去重），并对传输流应用压缩以减少 WAN 带宽。

{% hint style="info" %}
**来自 VMware 或 Nutanix？**

VergeOS 不会在层级之间自动提升或降级块。放置在配置时按每个 VM 磁盘明确指定，并在磁盘生命周期内保持不变。

VergeOS 提供 5 个工作负载层级（1–5）加一个专用元数据层（第 0 层）。权衡：可预测的性能（不会意外降级），代价是由管理员驱动放置。
{% endhint %}

## 要点总结

| 概念        | 摘要                                                                      |
| --------- | ----------------------------------------------------------------------- |
| **层级模型**  | 5 个工作负载层级（1–5）加一个专用元数据层（第 0 层）；第 1–3 层 = 性能（NVMe/SSD）；第 4–5 层 = 容量（HDD） |
| **无自动分层** | 数据保留在已配置的层级上——没有冷热迁移引擎                                                  |
| **首选层级**  | 按每个 VM 磁盘设置；如果请求的层级不存在，则回退到最近可用层级                                       |
| **驱动器规则** | 每层使用相似的驱动器，各节点驱动器数量相等，控制器节点需要第 0 层                                      |
| **扩展**    | 垂直（添加驱动器）或横向（添加节点）——每个层级独立扩展                                            |
| **容量规划**  | 第 0 层保留 30%+ 空闲，工作负载层级保留 20–30% 空闲，每 1 TB 原始存储配备 1 GB RAM               |
| **快照集成**  | 快照感知层级；去重按层级运行；复制针对带宽进行了优化                                              |

## 下一步

在了解存储层级如何组织和管理之后，下一部分将介绍文件级存储访问： [**NAS 服务与共享**](/learn-the-platform/zh/mo-kuai-5-cun-chu/03-nas-shares.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/zh/mo-kuai-5-cun-chu/02-storage-tiers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.