1. ONTAP存储协议全景
NetApp ONTAP 的一个核心设计理念是"统一存储"（Unified Storage）：同一套 HA Pair 控制器、同一个聚合（Aggregate）、甚至同一个 SVM（Storage Virtual Machine，存储虚拟机），可以同时对外提供文件访问与块访问。理解这一点，是理解后续所有协议细节的前提——协议不是彼此孤立的插件，而是 ONTAP 在 WAFL 文件系统之上叠加的不同"访问语义层"。
一、文件协议与块协议在 ONTAP 中的定位
ONTAP 的底层是 WAFL（Write Anywhere File Layout）文件系统，它管理物理磁盘、SSD 与聚合，并向上提供逻辑存储单元。文件协议与块协议都构建在这一层之上，但它们的"数据组织方式"完全不同：
- 文件协议（NAS）：NFS、SMB/CIFS。客户端看到的是目录树与文件，ONTAP 以"卷（Volume）"为容器，卷内是文件系统语义。访问单位是文件与目录操作（open/read/write/close）。
- 块协议（SAN）：iSCSI、FC、FCoE、NVMe-oF。客户端看到的是 LUN（逻辑单元号），本质是一段可随机读写的块地址空间。访问单位是 SCSI 或 NVMe 命令，主机侧通常还要叠加自己的文件系统（如 ext4、NTFS、VMFS）。
关键区别在于"谁管文件系统"：NAS 由 ONTAP 管，SAN 由主机管。这直接决定了共享方式、性能特征与运维边界。
二、协议栈分层
从下往上看，ONTAP 的协议栈大致分为四层：物理/介质层（磁盘、SSD、NVMe 盘）→ 聚合与 WAFL 层 → 卷与 LIF 层 → 协议服务层。协议服务层再分为 NAS 与 SAN 两条分支，各自封装不同的网络与传输语义。下图给出这一全景结构，并标注了各协议对应的典型客户端与访问单位。
三、典型应用场景
选型的第一步是判断"谁需要共享文件系统"。以下场景在实践中非常典型：
- NFS：Linux/Unix 服务器、HPC 计算节点、AI 训练数据、Kubernetes 持久卷（配合 Trident）。特点是多客户端共享同一目录树，权限由 UID/GID 控制。
- SMB：Windows 文件共享、AD 域环境、Office 文档协作、用户主目录。特点是依赖 AD/LDAP 认证与 ACL 权限。
- iSCSI：中小规模虚拟化、Windows 集群、数据库裸设备。基于以太网，成本低，配置灵活。
- FC：核心数据库（Oracle、SQL Server）、高要求虚拟化。低延迟、高可靠，需要专用 HBA 与交换机。
- NVMe-oF：对延迟极敏感的场景，如实时分析、高频交易、AI 推理。基于 NVMe 命令集，延迟显著低于 SCSI。
四、选型依据
选型不是"哪个协议更好"，而是"哪个协议匹配当前需求"。可以从四个维度判断：
| 维度 | 倾向文件协议 | 倾向块协议 |
|---|---|---|
| 共享方式 | 多客户端共享同一目录树 | 单主机独占 LUN，或集群文件系统共享 |
| 文件系统归属 | 由 ONTAP 管理，运维简单 | 由主机管理，需自行维护 |
| 性能特征 | 元数据操作多，适合大文件吞吐 | 随机 IOPS 高，适合数据库与虚拟化 |
| 网络要求 | 标准以太网即可 | iSCSI 用以太网；FC 需专用网络；NVMe-oF 需 RoCE/FC |
五、一个简单的选型示例
假设某企业需要部署一套新业务：10 台 Linux 应用服务器共享日志与配置文件，2 台数据库服务器需要低延迟块设备，另有 50 名员工需要 Windows 共享盘。可以这样规划：
# 示例规划（参数为教学假设，非实测）
SVM: svm-prod
NAS LIF: 10.0.10.21 -> 导出 /vol/app_share (NFS v4.1)
NAS LIF: 10.0.10.22 -> 共享 \\svm-prod\home (SMB 3.1.1)
SAN LIF: 10.0.20.31 -> iSCSI，映射 LUN db_lun_01 (500 GB)
SAN LIF: 10.0.20.32 -> iSCSI，映射 LUN db_lun_02 (500 GB)
卷规划：
vol_app_share 2 TB NFS
vol_home 1 TB SMB
vol_db 1 TB iSCSI LUN 容器
判断是否达成目标，可以观察三点：Linux 节点能否挂载 NFS 并读写；Windows 客户端能否通过 AD 认证访问共享；数据库主机能否识别 LUN 并完成格式化与挂载。三者都正常，说明协议层规划基本正确。