3. Alletra OS与数据服务基础

Alletra OS 是运行在 Alletra 存储阵列上的操作系统层，它把物理介质、控制器、缓存和网络端口组织成可被上层协议访问的数据服务。理解 Alletra OS 的关键，不是记住它有哪些进程，而是看清一条数据从主机写入到落盘、再到被快照或克隆复用的完整路径。本节围绕四个核心问题展开：Alletra OS 提供哪些核心服务、文件系统与块卷如何抽象、数据缩减在何处生效、快照与克隆能力如何通过协议暴露给主机。

一、Alletra OS 的核心服务分层

Alletra OS 内部可粗略分为四层。最底层是介质与 RAID 层，负责把 NVMe SSD 或 SAS SSD 组成 RAID 组或盘池，处理坏块重映射与介质健康。其上是数据服务层，包含精简配置、数据缩减、快照、克隆、远程复制等能力，这些能力以“卷”或“文件系统”为操作对象。再往上是协议服务层，把块卷通过 FC、iSCSI、NVMe-oF 暴露为 LUN，把文件系统通过 NFS、SMB 暴露为共享目录。最上层是管理与遥测层，提供 REST API、CLI、GUI 以及性能与容量遥测。

需要强调的是，数据服务层与协议服务层是解耦的。同一个卷既可以作为 FC LUN 映射给主机，也可以作为 iSCSI Target 暴露；同一个文件系统既可以走 NFSv3，也可以走 NFSv4.1 或 SMB 3.1。协议只是“接入方式”，数据缩减、快照、克隆等能力在卷或文件系统层面生效，与协议选择无关。这一点决定了后续配置时，协议参数与数据服务参数应分开考虑。

二、文件系统与块卷的抽象差异

块卷是 Alletra OS 中最基础的存储对象。创建卷时，管理员指定容量、精简配置开关、数据缩减策略、所属盘池或性能策略。卷在阵列内部表现为一个逻辑地址空间，主机通过 LUN 或命名空间看到它，并在其上建立自己的文件系统（如 ext4、XFS、NTFS、VMFS）。块卷不感知文件语义，它只处理固定大小的块读写，因此延迟低、并发高，适合数据库、虚拟机和容器持久卷。

文件系统则是 Alletra OS 直接管理的对象。管理员创建文件系统时指定容量、协议（NFS 或 SMB）、导出策略、权限模型和快照策略。文件系统内部维护目录树、inode、配额和 ACL，主机通过挂载或映射直接访问目录，不需要再格式化。文件系统适合共享目录、用户主目录、媒体库和 AI 训练数据集等场景。

两者的关键差异在于“谁管理文件语义”。块卷把文件语义交给主机，阵列只保证块级可靠性与性能；文件系统把文件语义收进阵列，主机只做协议客户端。选择时先看主机侧是否已有成熟文件系统与共享需求：若多台主机需要同时读写同一份数据，文件系统更直接；若主机需要低延迟块设备或已有集群文件系统，块卷更合适。

三、数据缩减的生效位置与观察方式

Alletra OS 的数据缩减通常由压缩和去重两部分组成。压缩在数据写入时对数据块进行编码，减少物理占用；去重在后台或在线识别重复数据块，只保留一份副本。两者可以独立开启，也可以组合使用。缩减生效的位置在数据服务层，对卷或文件系统透明，主机侧看到的逻辑容量不变，但阵列侧物理占用下降。

观察缩减效果时，不要只看“缩减比”一个数字。应同时关注逻辑已用容量、物理已用容量、压缩比、去重比和总缩减比。例如一个 10 TiB 精简卷，主机写入 4 TiB 数据，其中压缩后为 2.4 TiB，去重后为 1.8 TiB，则总缩减比约为 4 / 1.8 ≈ 2.22:1。这个比值会随数据类型变化：文本、日志、虚拟机镜像通常缩减明显，已压缩的媒体文件或加密数据缩减有限。配置时应根据数据特征选择策略，而不是对所有卷一律开启最强缩减。

四、快照与克隆如何通过协议暴露

快照是某一时间点卷或文件系统的只读或可写副本，通常采用写时重定向或写时复制实现。创建快照后，源卷继续接受写入，快照保留创建时刻的数据视图。克隆则是基于快照或源卷生成一个独立可写的卷或文件系统，拥有自己的地址空间，后续写入互不影响。

快照与克隆通过协议暴露的方式有两种。第一种是“阵列侧暴露”：把快照或克隆直接映射为新的 LUN 或新的 NFS/SMB 共享，主机像访问普通卷或目录一样访问它。这种方式对主机透明，适合备份、测试、开发环境快速拉起。第二种是“主机侧触发”：通过 REST API 或 CLI 在主机备份脚本中调用快照创建接口，再通过协议挂载快照 LUN 进行备份读取。这种方式把快照纳入主机备份流程，适合与备份软件集成。

实际配置时，需要关注三个参数：快照保留策略、快照空间上限和克隆的父卷关系。保留策略决定快照自动过期时间；空间上限决定快照可占用的额外容量，超过后旧快照可能失效；克隆的父卷关系决定克隆是否依赖源卷，若源卷删除，部分实现会要求先断开克隆关系。建议在创建克隆后尽快将其转为独立卷，避免长期依赖父卷。

五、配置示例：从卷到协议暴露

以下示例展示一个典型流程：创建一个 2 TiB 精简卷，开启压缩与去重，创建快照，再通过 iSCSI 暴露给主机。命令为示意格式，具体参数以实际环境为准。

# 创建精简卷并开启数据缩减
volume create --name vol_db01 --size 2TiB --thin --compression on --dedup on

# 创建快照
snapshot create --volume vol_db01 --name snap_db01_20250601

# 将快照克隆为独立卷
clone create --source snap_db01_20250601 --name vol_db01_test

# 创建 iSCSI Target 并映射 LUN
iscsi target create --name tgt_db01 --portal 10.0.0.10
lun map --target tgt_db01 --volume vol_db01 --lun-id 0
lun map --target tgt_db01 --volume vol_db01_test --lun-id 1

主机侧执行发现与登录后，会看到两个 LUN：LUN 0 对应生产卷，LUN 1 对应测试克隆。此时可在测试克隆上挂载文件系统进行验证，而不影响生产卷。验证完成后，删除测试克隆即可释放空间。整个过程体现了“数据服务层创建对象、协议层暴露对象、主机层使用对象”的分工。

六、判断与排障要点

当主机无法看到卷时，先确认协议层映射是否存在，再确认主机侧发现与登录是否成功，最后检查卷是否已创建并处于在线状态。当缩减比低于预期时，先确认数据类型是否可压缩，再检查去重是否已开启并完成扫描。当快照占用空间增长过快时，检查写入量和保留策略，必要时缩短保留时间或增加快照空间上限。当克隆性能下降时，检查克隆是否仍依赖父卷，以及父卷是否负载过高。