3. Purity操作系统与存储服务模型

Pure Storage 全闪存阵列的软件核心是 Purity 操作系统。理解 Purity，不能只把它当成一个“存储固件”，而应把它看作一套把物理闪存资源抽象为可用存储服务、并对外提供统一管理入口的运行环境。它同时承担三件事：向下管理闪存介质与控制器硬件，向中间组织卷、文件系统与数据服务，向上暴露管理界面与 API。本节围绕 Purity 运行架构、卷与文件系统抽象、数据服务层、管理接口与 API 体系四条主线展开。

一、Purity 运行架构：双控制器与 Purity 实例

在典型的双控制器全闪存阵列中，两个控制器各自运行一个 Purity 实例，二者通过内部互连形成高可用对。每个 Purity 实例内部可划分为若干逻辑层次：最底层是面向 NVMe 或 SAS 闪存盘的介质管理层，负责盘位发现、磨损均衡与介质健康监控；其上是数据布局与元数据层，管理数据在闪存上的分布、校验与垃圾回收；再往上是数据服务层，提供精简置备、快照、复制、去重与压缩等能力；最上层是协议前端与管理服务，对外呈现块、文件或对象接口，并接受管理指令。

两个控制器之间并非简单主备，而是通过心跳与镜像路径协同工作。主机多路径软件可同时看到两个控制器的前端端口，I/O 可经任一控制器进入。当某个控制器故障时，其上的卷会由对端接管，主机侧表现为路径切换而非数据丢失。这一架构决定了后续卷、快照与复制等对象都必须在“控制器对”这一粒度上考虑可用性。

二、卷与文件系统抽象

Purity 对外提供的最基本块对象是“卷”。卷是一个逻辑块设备，具有容量、块大小与访问路径。创建卷时，Purity 默认采用精简置备：卷的声明容量可以远大于实际占用，只有真正写入的数据才会占用闪存空间。例如创建一个声明容量 10 TiB 的卷，初始实际占用可能只有几 MB 元数据；随着写入增长，占用逐步上升。这一特性直接影响容量规划——不能把声明容量简单相加当作物理需求。

卷通过“主机连接”暴露给主机。管理员需要把卷与主机对象或主机组关联，并指定 LUN 号。主机侧多路径软件会看到来自两个控制器的路径，形成一条聚合设备。卷还可以被快照：快照不是完整复制，而是记录某一时刻的数据视图，后续写入采用写时重定向，因此快照创建几乎瞬时完成，占用空间只随被修改的数据块增长。

在文件侧，Purity 提供文件系统抽象，通过 NFS 或 SMB 对外共享。文件系统建立在卷或目录之上，支持配额、快照与目录级管理。块与文件并非两套割裂体系，而是共享同一套底层数据服务：去重、压缩、快照与复制对两者都适用。理解这一点，有助于在设计时统一考虑容量效率与保护策略。

三、数据服务层：效率与保护能力

数据服务层是 Purity 最具价值的部分，它在数据写入路径上完成多项处理。去重以固定块为单位识别重复数据，只保留一份副本；压缩进一步缩减数据体积；二者结合可显著降低实际占用。需要注意的是，去重与压缩的效果高度依赖数据特征：虚拟机镜像、备份数据通常收益明显，而已经加密或已压缩的数据收益有限。

快照与复制构成保护能力。快照用于本地快速恢复，复制用于异地容灾。复制以快照为基础，把增量数据传送到远端阵列。设计时应明确恢复点目标与恢复时间目标：快照频率决定可恢复的时间点密度，复制带宽与链路质量决定远端数据的新旧程度。

四、管理接口与 API 体系

Purity 提供三类管理入口：图形界面、命令行与 REST API。图形界面适合日常查看与简单操作；命令行适合批量与脚本化；REST API 则是自动化集成的核心。三者操作的是同一套对象模型，因此理解对象关系比记住界面位置更重要。

REST API 采用资源化风格，常见资源包括卷、主机、主机组、快照、保护组与复制链路。典型调用流程是：先认证获取会话令牌，再对目标资源发起创建、查询、修改或删除请求。下面是一个创建卷的请求示例，参数为示例值：

POST /api/1.19/volume
Authorization: Bearer <session-token>
Content-Type: application/json

{
  "name": "vol-app-01",
  "provisioned": 10737418240,
  "source": null
}

返回结果中会包含卷的标识、声明容量与实际占用等字段。判断创建是否成功，应同时检查 HTTP 状态码与返回体中的对象状态，而不是只看界面是否出现新条目。对于批量场景，建议把卷名、容量、主机映射等参数放入外部清单，由脚本读取后循环调用 API，从而保证命名与容量的一致性。