网络存储：NFS、SMB 与对象存储

• policy 的 JSON 结构（Statement/Effect/Action/Resource）
• 用户、组、服务账号与 policy 的绑定
• 内置策略与自定义策略

MinIO 采用 S3 兼容的 IAM 策略实现 RBAC。策略是 JSON 文档，包含 Statement 数组，每个 Statement 有 Effect（Allow/Deny）、Action（如 s3:GetObject、s3:PutObject）、Resource（arn:aws:s3:::bucket/prefix/*）。通过 mc admin policy create 创建自定义策略，mc admin user add 建用户，mc admin policy attach 将策略绑定到用户或组。可使用内置策略（readonly、readwrite、consoleAdmin、diagnostics）或自定义细粒度策略。组可用于批量授权，服务账号（service account）用于程序访问。RBAC 通过"策略 + 用户/组/服务账号"组合实现最小权限控制。

MinIO RBAC = S3 兼容策略 + 用户/组/服务账号绑定，核心是 Action/Resource 的细粒度定义与最小权限原则。

• UDP 无连接、无重传、低延迟但有丢包风险
• TCP 可靠、面向连接、适合大流量与 WAN
• 现代 Linux NFS 默认 TCP

NFS over UDP：无连接、无拥塞控制，传输开销小、延迟低，但丢包时无重传（依赖上层重试），可靠性差，不适合大文件与不可靠网络，主要用于局域网内小负载或历史兼容。NFS over TCP：面向连接、可靠、有重传与拥塞控制，适合大文件传输、WAN、高负载与不可靠网络，是现代 Linux NFS 默认传输方式。UDP 在 MTU 分片、大 RPC 上也有问题，TCP 更稳定。选型：局域网小负载可用 UDP，生产与广域网用 TCP。

差异核心是"可靠 vs 低开销"，现代生产几乎都用 TCP，UDP 仅限特定低延迟小负载场景。

• ACL 的 Grantee 与 Permission 模型
• 桶/对象级 ACL 的适用
• 与 IAM policy 的关系（ACL 已基本被 IAM 取代）

S3 ACL（访问控制列表）为桶和对象提供基于"主体（Grantee）+ 权限（Permission）"的授权，如授予 READ、WRITE、READ_ACP、WRITE_ACP、FULL_CONTROL。Grantee 可以是 AWS 账号、canonical user、匿名用户（AllUsers）等。通过 aws s3api put-bucket-acl / put-object-acl 或控制台设置。现代 AWS 推荐用 IAM policy / bucket policy 而非 ACL，因为 ACL 粒度粗、难管理、存在匿名授权风险；ACL 主要用于对象级临时授权（如单个对象对外公开）或 S3 对象所有权模型。S3 默认禁用 ACL（Object Ownership 为 Bucket owner enforced），启用需显式开启。

ACL 是 S3 早期的授权模型，粒度粗、被 IAM/bucket policy 取代，仅保留对象级简易授权场景，且默认禁用。

• 分片上传原理与流程
• 分片并行、断点续传与校验
• 触发阈值与适用场景

S3 multipart upload 将大文件拆分为多个分片（part，每片 5MB-5GB，最多 10000 片），分片可并行上传、独立校验，最后用完成请求组装。流程：1) InitiateMultipartUpload 创建上传会话得到 uploadId；2) 每个分片 UploadPart 上传，记录 ETag；3) 全部完成后 CompleteMultipartUpload 组装。优势：支持大文件（>100MB 建议）、并行加速、断点续传（失败的分片可重试）、单分片失败不影响整体。失败可 AbortMultipartUpload 清理。SDK 与 CLI 会自动对大文件使用 multipart。

multipart 解决大文件上传的可靠性、并行性与断点续传，是 S3 大文件上传的标准机制。

• iSCSI 多路径（MPIO）聚合多个网卡/target
• multipath 配置与路径策略
• 故障切换与路径状态查看

iSCSI 多路径通过将多个 iSCSI 会话（不同网卡/多 target 端口）映射到同一 LUN，用 dm-multipath 聚合为单一逻辑设备，提升带宽与路径冗余。配置：1) 确认发起端连接到多个 target 端口（多个 session）；2) 配置 /etc/multipath.conf 设置 path_grouping_policy（如 failover 或 multibus）与 path_selector；3) multipath -ll 查看聚合设备与路径状态；4) 挂载 /dev/mapper/。故障切换：某条路径失效时，multipath 自动把 IO 切换到其他路径，业务无感知；配合 ALUA 或 active/passive 策略，路径恢复后自动回切。保障高可用。

iSCSI 多路径 = 多会话 + dm-multipath 聚合 + 路径策略，实现单路径故障无缝切换，是 SAN 存储高可用关键。

• 快照是时间点恢复点，依赖源存储
• 备份是独立可长期保留的恢复点
• 恢复点可用性与 RPO 差异

快照是源存储的某一时间点状态，恢复点（RPO）可做到极近（秒级），因为快照可高频创建、近零成本，能提供非常小的 RPO；但快照依赖源存储可用性，源故障时快照失效，恢复点受限。备份是独立副本，RPO 由备份频率决定（如每小时/每天），恢复点较粗，但备份独立于源，可长期保留、异地容灾，恢复点更可靠、可长期追溯。差异本质：快照提供"更近但依赖源"的恢复点，备份提供"更独立、可长期"的恢复点，二者互补（快照保高频 RPO，备份保可靠性）。

恢复点差异关键在"近端可用性 vs 独立性/保留期"，快照 RPO 小但依赖源，备份独立但 RPO 由频率决定。

• 首次从快照建 EBS 卷需懒加载（lazy load）导致延迟
• Fast Snapshot Restore 预填充数据块
• 适用场景与成本

从 EBS 快照创建新卷时，默认采用懒加载（lazy loading），数据块按需从 S3 拉取，首次访问某块有延迟，影响大规模并行恢复（如大数据集群、测试环境）。Fast Snapshot Restore 可对指定快照在指定可用区启用，系统会预先填充卷的数据块，使从快照创建的卷立即可用、无首访延迟。启用后首次创建即全速，适合频繁从同一快照恢复的规模化场景（如 CI 测试、云桌面、集群）。代价是额外存储/计算成本，且需在快照与可用区维度启用，并在不再需要时禁用以节省成本。

Fast Snapshot Restore 通过预填充数据块解决懒加载的首访延迟，以成本换恢复速度，适合高频、大批量快照恢复。

• AoE 在以太网上直接封装 ATA 命令
• 无 IP/TCP 层，轻量低延迟
• 仅限局域网（L2）分辨

AoE 将 ATA 命令直接封装在以太网帧（L2）上传输，不经过 IP/TCP 栈，因此开销低、延迟小，适合局域网内的块设备共享。客户端通过 AoE 驱动把远程设备当作本地块设备（/dev/etherd/...），配合 LVM 等使用。局限：仅支持二层以太网，无法跨路由（L3）传输，扩展性受限，且无内置认证加密（需在隔离网络中使用）。相比 iSCSI，AoE 更轻量但功能少，适合小型局域网存储虚拟化场景，现已较少使用。

AoE 的核心是"以太网帧直接封装 ATA 命令"，去掉网络层换低延迟，但被限制在 L2 局域网、缺少安全特性。

• 用户态实现 NFS 服务器，通过 FSAL 对接不同存储
• 支持 NFSv3/v4、pNFS 与高级特性
• 与内核态 NFS 的对比

NFS Ganesha 是用户空间（userspace）的 NFS 服务器，通过 FSAL（File System Abstraction Layer）插件对接多种后端（Lustre、Ceph、GPFS、本地文件系统等），在用户态实现 NFSv3/v4.0/v4.1/v4.2 协议与 pNFS、ACL、锁等高级特性。相比内核态 NFS，它更易扩展定制、可热插拔 FSAL、便于与分布式存储集成，但用户态有轻微性能开销与更高的内存占用。适用场景：需要与分布式存储（如 CephFS）提供 NFS 接口、或需要定制 NFS 特性的环境。

NFS Ganesha 的价值在"用户态 + FSAL 插件"，把 NFS 服务与后端存储解耦，便于对接分布式存储与扩展高级特性。

• hard 挂载：服务故障时无限重试，进程阻塞
• soft 挂载：超时后返回错误
• 选型：数据安全 vs 业务可用

NFS hard 挂载：服务故障时客户端进程无限重试挂起，不返回错误，适合对数据一致性要求高、可接受阻塞的场景（如数据库、应用数据目录），避免静默丢数据。soft 挂载：超过重试次数后返回 I/O 错误给应用，进程不长期阻塞，适合不关键、可容忍失败的场景，但可能因部分写入导致数据不一致。选型原则：核心数据用 hard 保证可靠性，临时/非关键数据用 soft 避免阻塞拖垮业务。生产环境数据库目录通常用 hard（或 hard,intr），因为静默失败比阻塞更危险。

hard 保"数据不丢"、soft 保"业务不阻塞"，是可靠性 vs 可用性的权衡，核心数据用 hard。

• lockd 提供 NLM 锁协议（内核锁）
• statd 在服务/客户端重启后恢复锁状态
• 锁的局限与 NFSv4 的改进

NFS 文件锁（NLM）由 lockd（内核锁守护进程）实现，负责在处理 NFS 锁请求时与对端交互，维护锁状态。statd（status monitor）监控网络状态，当 NFS 客户端或服务器重启后，通过 RPC 通知对端恢复/释放锁，避免锁永久残留导致"锁泄露"。传统 NLM 锁在崩溃/重启后需 statd 协商恢复，锁可能丢失或死锁。NFSv4 引入基于租约（lease）的锁机制，由内核持有锁状态，配合 lease 过期自动回收，比 NLM 更可靠。主要锁协议：NLM（NFSv3）与 NFSv4 locking。

lockd 实现锁、statd 负责崩溃恢复锁状态，NFSv4 用 lease 取代 NLM 的 statd 恢复机制，更可靠。

• 协议端口与状态
• 锁与回调机制
• 安全与兼容性

NFSv3：无状态，使用多个辅助端口（mountd、statd、lockd），锁由 NLM 提供，需 statd 恢复；扩展性差、安全较弱（依赖 rpcbind 协商端口）。NFSv4：有状态，使用单一 TCP 端口 2049，锁与 mount 整合进协议（避免 statd），支持 lease 自动回收锁、回调、复合操作（减少 RTT）、更强的安全（RPCSEC_GSS、Kerberos）。NFSv4 更安全、更高效、跨防火墙更简单。NFSv4.1 增加 pNFS、会话与并行，NFSv4.2 增加更高级特性。迁移 NFSv3→v4 需处理兼容性与挂载参数差异。

NFSv4 相对 v3 的核心改进是"有状态、单端口、锁内置、安全性、复合操作"，运维更简单更安全。

• v4.1：pNFS、会话、并行
• v4.2：clone、copy-offload、稀疏文件、加密
• 新特性对性能与功能的提升

NFSv4.1 引入 pNFS（并行 NFS），将数据与元数据分离，支持多存储节点并行访问，提升扩展性；加入会话（session）机制使协议有状态、可恢复，支持复合操作与更好的容错。NFSv4.2 增加：copy offload（服务端拷贝，无需客户端搬运数据）、clone（文件克隆）、稀疏文件原生支持、空间预留、应用层功能（如服务器端加解密原生支持）等，提升效率与功能。这些特性使 NFSv4.1/4.2 更适合大规模、高性能与分布式存储场景。

v4.1 主打 pNFS 并行与会话，v4.2 主打 copy offload/clone/稀疏文件等效率特性，是 NFS 迈向高性能分布式的关键。

• 基于清单（manifest）批量处理
• 支持的操作类型（复制、删除、标签、加密等）
• 批量任务的状态与监控

S3 Batch Operations 允许对海量对象执行批量操作，通过清单（manifest）指定目标对象（可由 S3 Inventory 生成或自定义 CSV），然后执行批量任务。支持的操作包括：复制（Copy）、删除（Delete）、设置标签/ACL/加密、调用 Lambda 函数（自定义处理）等。任务可配置完成报告、失败率阈值、权限角色，异步执行并监控进度。适合大规模数据治理、迁移、清理、加标签等场景。通过权限配置（IAM 角色）确保任务只操作授权对象。

Batch Operations 是"清单驱动 + 异步批量任务"，把海量对象的重复操作标准化、可监控，常与 Inventory 配合。

• 通过边缘节点（CloudFront 边缘）就近接入
• 优化跨区域/跨国传输
• 适用场景与成本

S3 Transfer Acceleration 利用 CloudFront 全球边缘节点，让客户端就近接入边缘节点，再通过优化后的 AWS 骨干网络传输到目标 S3 桶，从而减少跨区域/跨国传输的路径延迟与丢包，提升上传与下载速度。启用后通过专用加速端点（bucket.s3-accelerate.amazonaws.com）访问。适用场景：客户端与桶地域相距远、跨大陆传输、需要稳定高速的长距离传输。注意：加速对短距离/本地访问收益有限，且有额外费用，需评估收益。

Transfer Acceleration 的核心是"边缘就近接入 + AWS 骨干网优化"，解决长距离传输延迟，但需权衡成本与收益。

• Samba 实现 SMB/CIFS 协议
• 配置文件 smb.conf 的共享定义
• 用户认证与权限

Samba 在 Linux 上实现 SMB/CIFS 协议，使 Windows 客户端能访问 Linux 共享目录。配置：编辑 /etc/samba/smb.conf 定义共享段，如 [share] 设置 path、writable、guest ok、valid users 等；用 smbpasswd 添加 Samba 用户（使用系统用户或独立用户）；testparm 校验配置，systemctl restart smbd 生效。Windows 端通过 \\server\share 访问。权限由 Samba 配置+底层文件系统权限共同决定，支持共享级与用户级认证。可配置 browseable、read only、继承权限等。

Samba 通过 SMB 协议 + smb.conf 共享段 + smbpasswd 用户实现 Linux/Windows 互访，是异构文件共享的标准方案。

• 应用层协调（checkpoint/flush）
• 文件系统与卷的配合
• 与应用 agent 的协作

应用一致快照在文件系统一致的基础上，进一步协调应用（如数据库）达到一致状态。流程：1) 通过应用 agent（如 VSS writer、数据库集成）通知应用准备快照；2) 应用 flush 事务、完成 checkpoint、切换/归档日志，使内存与磁盘状态一致；3) 冻结文件系统（如 fsfreeze/quiesce）保证文件系统一致；4) 创建卷/存储快照；5) 解冻并通知应用继续。这样快照包含应用已提交的完整事务，恢复后应用能正常启动且数据一致。数据库（如 SQL Server VSS、Oracle 的 backup mode）必须应用一致才能作为可靠恢复点。

应用一致快照 = 应用协调（flush/checkpoint）+ 文件系统冻结 + 存储快照，需应用 agent 配合，是数据库快照的关键。

• MDS 负责 CephFS 的元数据缓存与目录管理
• 元数据动态子树分区与多 MDS
• 元数据与数据分离

CephFS 将元数据与数据分离：数据存储于 RADOS 对象存储，元数据由 MDS（Metadata Server）管理。MDS 维护目录树、inode 与文件元数据，提供 POSIX 语义（目录、权限、锁）。它把元数据缓存到内存并提供动态子树分区（dynamic subtree partitioning），支持多 MDS 并行管理不同目录子树，提升元数据吞吐。MDS 故障时由其他 MDS 接管（standby），元数据持久化存储于 RADOS（通过 Journal），保证高可用。MDS 是 CephFS 的元数据服务层，是性能与扩展的关键。

Ceph 架构"数据在 RADOS、元数据在 MDS"，MDS 用动态子树分区支持多 MDS 并行，是高可用与扩展的关键点。

• PG 作为对象到 OSD 的中间映射层
• CRUSH 算法决定 PG 到 OSD 的分布
• PG 数量与均衡的关系

Ceph 中对象先通过 hash 映射到 PG（Placement Group），再由 CRUSH 算法将 PG 映射到一组 OSD。PG 是对象与 OSD 之间的中间逻辑层，决定了数据分布的粒度。PG 数量影响均衡：PG 太少，数据分布粒度粗、均衡性差；PG 太多，元数据开销大。合理设置 PG 数量（按 OSD 数与复制级别）保证数据在 OSD 间均匀分布。CRUSH 基于集群拓扑与权重做伪随机映射，使 OSD 故障时数据只重分布受影响部分。ceph health 中的 PG 状态（peering、degraded、inactive）反映均衡与恢复。

Ceph 分布 = 对象→PG（hash）→OSD（CRUSH），PG 数量与 CRUSH 决定均衡性，是容量与性能规划关键。

• ceph health detail 查看详细状态
• PG 状态（active/clean、degraded、peering）
• OSD 状态与告警

ceph health 显示集群健康状态（HEALTH_OK/HEALTH_WARN/HEALTH_ERR），ceph health detail 给出具体告警。需关注：1) PG 状态：理想为 active+clean；degraded 表示有副本缺失、peering 表示正在同步、stuck 表示长时间卡住；2) OSD 状态：up/down、in/out，down 的 OSD 会导致 PG degraded；3) 空间：nearfull/backfillfull/full 表示容量告警；4) 其他：mon 状态、mds 状态、慢请求。定位流程：ceph health detail → ceph -s 看集群概览 → ceph osd tree 看 OSD → ceph pg dump 定位异常 PG → 修复（重启 OSD、调整权重、扩容）。

解读 Ceph health 的核心是看 PG 状态与 OSD 状态，结合 health detail 定位根因，从告警到 PG 到 OSD 逐层排查。

• FC 的专用协议与 HBA/交换机
• WWN 与 zoning
• 特点与适用场景

FC SAN 通过专用光纤通道基础设施（HBA、FC 交换机、光纤）构建高速块存储网络。节点有唯一 WWN（World Wide Name），通过分区（zoning）限制哪些主机可访问哪些存储端口，实现隔离与控制。FC 典型速率 8/16/32/64Gbps，延迟低、稳定、可靠，适合关键业务块存储（数据库、虚拟化）。FC 网络与业务网络物理隔离，安全与性能好，但成本高、需专用硬件。管理上通过 FC 交换机（Fabric）配置 zone 与 port，存储侧映射 LUN 给主机。

FC SAN 是"专用协议 + 专用硬件 + WWN/zoning"，提供高可靠低延迟块存储，但成本高。

• FCoE 在以太网上封装 FC 帧
• 需要无损以太网（DCB/PFC）支持
• 收敛网络与成本

FCoE 将 FC 帧封装在以太网帧中传输，使 FC 存储与以太网共用同一物理网络（网络收敛），减少专用 FC 硬件成本。但 FCoE 需要无损以太网来保证不丢包（依赖 DCB、PFC 优先级流控、ETS 等增强以太网特性），否则 FC 的丢包会严重影响存储。FCoE 可在 cNIC（converged NIC）上跑，需支持 FCoE 的交换机与 CNA。它保留了 FC 的 SCSI 块协议语义，但引入以太网管理与尾延迟问题，实际推广不如 FC 彻底，且现在多被 iSCSI/NVMe-oF 替代。

FCoE 的核心是"FC 帧过以太网 + 无损以太网保可靠"，实现网络收敛但复杂度高，逐渐被 iSCSI/NVMe-oF 取代。

• fsfreeze -f 冻结（阻断新写入）
• fsfreeze -u 解冻
• 配合存储快照实现一致快照

fsfreeze 挂起（冻结）或恢复（解冻）文件系统的写入，用于配合存储级快照创建一致性快照。流程：fsfreeze -f /mnt 冻结文件系统（阻断新写入，已挂起的写入排队），此时创建存储快照，快照反映文件系统一致状态；随后 fsfreeze -u /mnt 解冻恢复写入。它保证快照中的文件系统元数据一致（崩溃一致），但若要应用一致（如数据库），还需额外协调应用（先 flush 数据库再 freeze）。fsfreeze 常用于 xfs/ext4 等配合 LVM/存储阵列快照。

fsfreeze 提供文件系统一致的快照窗口，是"崩溃一致"快照的关键工具，应用一致还需配合应用层 flush。