4. OCI存储服务架构与部署

OCI 的存储体系并不是“一个存储服务配几种规格”，而是四类面向不同访问模型、不同生命周期阶段、不同持久性目标的服务组合。选型的核心不是比较单价，而是先确定数据被谁访问、以什么协议访问、访问频率如何、是否需要共享、能否容忍重建，再据此匹配服务。四类服务在 OCI 中的定位如下：块存储（Block Volume）面向单实例或集群的块设备，文件存储（File Storage）面向多客户端共享的 POSIX 文件系统，对象存储（Object Storage）面向 HTTP/REST 的海量非结构化数据，归档存储（Archive Storage）面向极少访问但需长期保留的数据。

块存储：性能可调的块设备

块存储以块设备形式挂载到计算实例，适合数据库数据文件、系统盘、日志盘以及需要低时延随机读写的场景。OCI 块存储的关键设计点是“性能与容量解耦”：卷的性能由卷性能单位（VPU，每 GB 的 VPU 数）和卷大小共同决定，而不是单纯由容量决定。例如一个 500 GB 的卷，若设置为 20 VPU/GB，则总 VPU 为 10000，对应更高的 IOPS 与吞吐上限；若设置为 10 VPU/GB，则性能减半。这意味着同一容量可以通过调整 VPU 获得不同性能档位，也可以在业务高峰前在线调整 VPU 而不必扩容容量。

部署块存储时，需要明确三个决策：第一，卷类型选择，Balanced 适合通用业务，Higher Performance 适合对 IOPS 敏感的数据库，Ultra High Performance 适合极低时延场景；第二，挂载方式，单实例读写用于常规数据库，多实例读写需要配合集群文件系统（如 OCFS2、GFS2）或 Oracle ASM，否则会出现数据损坏；第三，持久性设计，块存储本身在可用域内多副本保存，但副本不能防止误删和逻辑损坏，因此必须配合块存储备份策略或卷组快照。一个常见的教学示例是：为 1 TB 的 MySQL 数据盘选择 20 VPU/GB 的 Balanced 卷，配置每日自动备份保留 7 天，并在变更前手动创建卷备份作为回滚点。

文件存储：共享 POSIX 文件系统

文件存储通过 NFSv3 或 NFSv4.1 提供共享文件系统，多个计算实例可同时挂载同一文件系统，适合共享目录、容器持久卷、HPC 中间结果、应用配置文件等场景。与块存储不同，文件存储天然处理多客户端并发访问的一致性，不需要额外集群文件系统。OCI 文件存储支持快照和克隆，快照用于时间点恢复，克隆用于快速派生新环境。

部署文件存储时，先创建挂载目标（Mount Target），它决定了文件系统在哪个子网、通过哪个 IP 暴露 NFS 服务；再创建文件系统并关联导出路径；最后在客户端通过 mount 命令挂载。需要特别注意的是安全列表和导出选项：挂载目标所在子网的安全列表必须放行 NFS 端口（2049）和相关端口，导出选项要限制允许访问的客户端 CIDR，避免任意主机挂载。性能方面，文件存储的吞吐随文件系统容量和客户端并发提升，小文件密集场景应关注元数据操作开销，必要时通过多挂载目标分散负载。

对象存储：海量非结构化数据的默认选择

对象存储通过 HTTP REST API 访问，数据以“桶 + 对象”组织，天然适合图片、视频、备份、日志、数据湖等海量非结构化数据。它的持久性设计基于跨可用域冗余，标准层适合频繁访问，低频层适合每月少量访问，归档层适合极少访问。对象存储支持版本控制、生命周期规则、预签名 URL、跨区域复制等能力，是构建数据湖和备份归档的主力服务。

部署对象存储时，桶的命名空间选择很关键：默认桶在租户内全局唯一，若需要跨租户或公网可预测的访问路径，可选择对象存储命名空间。生命周期规则是成本控制的核心手段，例如“创建后 30 天转入低频层，90 天转入归档层，365 天删除”，规则按前缀或标签匹配对象。访问控制上，应优先使用 IAM 策略和预签名 URL，避免把桶设为公共读写。一个可参考的配置片段如下：

oci os bucket create --name app-logs --compartment-id <compartment_ocid> \
  --storage-tier Standard --versioning Enabled

oci os object put --bucket-name app-logs --file ./app.log \
  --name 2025/06/01/app.log

归档存储：长期留存的低成本层

归档存储面向极少访问但必须长期保留的数据，例如合规审计记录、历史影像、科研原始数据。它的成本显著低于标准对象存储，但代价是取回需要先解冻，且存在最低计费周期（通常 90 天），提前删除仍按最低周期计费。因此归档存储不适合任何需要即时读取的场景，也不适合频繁写入删除的临时数据。

部署归档存储时，通常不直接写入归档层，而是先写入标准层，再通过生命周期规则自动转入归档层，这样既保证写入性能，又降低长期成本。取回时需发起恢复请求，选择恢复时长（如 1 小时、5 小时、12 小时），恢复完成后对象在限定时间内可读，超时后重新回到归档状态。设计时要评估恢复时间目标（RTO）：如果业务要求分钟级恢复，归档层就不应作为唯一副本，而应保留标准层副本或使用跨区域复制。

选型与持久性设计的落地方法

把四类服务放在一起，选型可以按以下顺序推进：先判断访问协议——需要块设备选块存储，需要共享文件系统选文件存储，需要 HTTP 接口选对象存储；再判断访问频率——高频访问留在标准层，低频下沉到低频层，极少访问下沉到归档层；最后判断持久性要求——块存储和文件存储依赖备份与快照防误删，对象存储和归档存储依赖版本控制与跨区域复制防区域性故障。一个实用的判断表如下：

性能设计上，块存储关注 VPU 与容量配比，文件存储关注客户端并发与元数据开销，对象存储关注请求速率与分片上传，归档存储关注恢复时间而非在线性能。成本设计上，生命周期规则是把冷数据从标准层推向低频层和归档层的主要工具，但必须结合最低计费周期和恢复时间目标，避免为了省存储费而牺牲可恢复性。最终，四类存储不是互斥选择，而是同一数据生命周期中的不同阶段：热数据在块存储和文件存储上被频繁读写，温数据进入对象存储标准层，冷数据下沉到低频层和归档层，形成完整的存储分层架构。