在游戏开发中为 Perforce P4 选择合适的 AWS 存储后端
Choosing the right AWS storage backend for Perforce P4 in game development
在 Amazon Web Services (AWS) 上运行 Perforce P4 的游戏工作室面临一个关键的基础设施决策：为其 depot 卷选择哪种存储后端。答案取决于 depot 规模、团队规模，以及工作室如何在成本与运维复杂度之间取得平衡。
P4 在游戏开发中被广泛使用，因为它能在同一个仓库中同时管理大型二进制资产（纹理、网格、过场动画和完整引擎构建）与源代码。拥有数百名开发者同步多吉字节工作区的工作室会产生与典型软件开发不同的存储 I/O 模式。Depot 容量增长到数十甚至数百 TB，同步操作需要持续的顺序吞吐量，而持续集成和持续交付（CI/CD）构建集群会产生突发性的并行读取负载。
在本文中，我们比较了四种适用于 P4 depot 卷的 AWS 存储选项：Amazon Elastic Block Store（Amazon EBS）、Amazon FSx for NetApp ONTAP、Amazon Elastic File System（Amazon EFS） 以及 Amazon Simple Storage Service（Amazon S3） 归档 depot。我们将每种选项对照实际游戏开发工作负载进行评估，并提供一个决策框架以帮助您做出选择。
前提条件
要充分利用本文内容，您应具备：
- 一个具有存储服务配置权限的 AWS 账户
- 熟悉 Perforce P4（原 Helix Core）管理以及服务器部署包（SDP）
- 对 AWS 存储服务（Amazon EBS、Amazon FSx、Amazon EFS、Amazon S3）有基本了解
- 了解您当前的 depot 规模、增长趋势和团队规模
P4 如何使用存储
在比较各选项之前，了解 P4 如何组织其数据会很有帮助。Perforce 服务器部署包（SDP）定义了三个存储卷：
- /mnt/p4depots：归档文件（版本化的二进制和文本内容）、轮转日志和检查点。此卷存储了您的大部分数据，在 sync 操作期间会产生持续的顺序读取，在 submit 操作期间会产生顺序写入。
- /mnt/p4db：元数据库。相对于 depot 来说体积较小，但以随机 I/O 模式访问。此处低延迟至关重要。
- /mnt/p4logs：活动日志、服务器日志和临时存储。
存储库卷（/mnt/p4depots）是存储选型对成本、性能和运维复杂度影响最大的部分。由于元数据和日志卷对低延迟随机 I/O 的需求，在几乎所有情况下，Amazon EBS gp3 都是最佳选择。本文聚焦于存储库卷的选型决策。
Amazon EBS gp3
Amazon EBS gp3 卷提供挂载到单个 Amazon Elastic Compute Cloud（Amazon EC2） 实例的块级存储。对于 P4，EBS 是运维开销最小的起点。
性能特征
Amazon EBS gp3 卷提供 3,000 IOPS 和 125 MiBps 的基准吞吐量，可独立扩展至 80,000 IOPS 和 2,000 MiBps，最大卷容量为 64 TiB。延迟为低个位数毫秒。对于数据仓库低于 16 TB 的工作室，单个 gp3 卷即可为并发开发者同步和 CI/CD 读取提供足够的吞吐量，无需额外调优。
运维模型
Amazon EBS 卷一次只能挂载到一个实例。您的提交服务器及其高可用性（HA）备用副本各自需要一份独立的 depot 数据副本。P4 通过其内置的复制功能来处理这一点。备用副本维护元数据和归档文件的完整副本。灾难恢复使用复制到次要 AWS 区域的 EBS 快照。
何时选择 EBS
当您的 depot 小于 16 TB、团队规模较小或中等（并发开发者少于 100 人），且希望将运维开销降至最低时，请选择 Amazon EBS gp3。无论您使用什么方案来存储 depot，EBS 都是元数据（/mnt/p4db）和日志（/mnt/p4logs）卷的正确选择。
局限性
Amazon EBS 卷无法在多个实例之间共享。当 depot 大小超过 16 TB 时，您需要在提交服务器和每个备用副本上支付完整副本的费用。EBS 没有内置的存储效率功能，如去重或压缩。每个字节都按写入原样存储，不会有任何缩减。
FSx for ONTAP
FSx for ONTAP 是一项基于 ONTAP 文件系统构建的全托管共享文件和块存储服务。Perforce 和 AWS 均推荐对于超过 16 TB 的 depot 使用 FSx for ONTAP。（AWS 还将 Amazon FSx for OpenZFS 列为更大 depot 的选项；本文聚焦于 FSx for ONTAP。）
性能特征
FSx for ONTAP 在 SSD 层上提供亚毫秒级延迟。单个 HA 对可提供高达 6 GBps 的吞吐量（第一代文件系统为 4 GBps），配备多个 HA 对的横向扩展文件系统可达 72 GBps；远超 P4 depot 的需求。它支持 NFS、SMB 和 iSCSI 访问。对于 P4 depot 卷，Perforce 建议使用多连接的 iSCSI 以获得最大性能，或使用 nconnect 的 NFS 以在性能和较低运维开销之间取得平衡。
存储效率
这正是 FSx for ONTAP 在游戏开发工作负载中脱颖而出的地方。内联去重、压缩和压缩整理可减少物理存储占用。AWS 文档记载，通用文件共享的存储容量可节省高达 65%。P4 存储库的实际节省幅度在很大程度上取决于资产构成：已压缩的二进制文件（纹理、音频和视频）能带来的额外压缩空间有限，而对版本化文件的众多已存储修订版本进行去重则可以回收可观的空间。应测量您存储库的实际数据缩减比率，而非假定一个固定数值。
共享存储与高可用性
FSx for ONTAP 多可用区（AZ）部署提供单个共享的 /mnt/p4depots 卷，可从提交服务器及其 HA 备用服务器访问。这消除了 P4 在提交服务器和备用服务器之间复制存档文件的需求。lbr.replication 设置可以配置为 shared，从而实现更快的故障切换并减少复制带宽。
CI/CD 加速
ONTAP FlexClone 可即时创建空间高效的 depot 数据可写副本。构建集群可以在几秒内克隆 depot 快照，而无需立即消耗额外存储空间，然后针对该快照运行构建，最后丢弃克隆。这加速了构建验证并降低了并行构建环境的成本。
灾难恢复
ONTAP SnapMirror 提供高效的跨 Region 块级复制。结合自动数据分层（冷数据从 SSD 迁移到由更低成本存储支撑的容量池），DR 副本的成本可显著低于在次要 Region 中维护完整的 EBS 副本。
何时选择 FSx for ONTAP
当您的 depot 超过 16 TB、拥有 100 或更多并发开发人员、需要在 commit 服务器和 replica 服务器之间共享存储，或您的 CI/CD 流水线能从即时克隆中受益时，请选择 FSx for ONTAP。当存储效率节省抵消了较高的基础成本时，它也是正确的选择。
局限性
FSx for ONTAP 的初始配置复杂度高于 Amazon EBS。它为 depot 卷引入了网络附加存储延迟。对于 depot 访问的顺序 I/O 模式，此延迟可以忽略不计。定价包含 SSD 容量、容量池存储和吞吐量容量，这意味着需要管理的维度比 Amazon EBS 更多。
Amazon EFS
Amazon EFS 提供完全托管的弹性 NFS 文件存储，可自动扩展。它支持跨多个实例和可用区的共享访问。
性能特征
Amazon EFS 弹性吞吐量可提供超过 10 GBps 的读取吞吐量，Standard 存储类的读取延迟可低于 1 毫秒。然而，对于 P4 产生的 I/O 模式，其写入和随机 I/O 延迟均高于 Amazon EBS 和 FSx for ONTAP，且 EFS 不支持 iSCSI。
为何不推荐用于 P4 仓库
无论是 Perforce 部署指南还是 AWS 针对 P4 的指导文档，均未推荐将 EFS 用作仓库存储。原因如下：
- 不支持去重或压缩。每个存储字节都按每 GB 计费，且该费率在大规模场景下高于 FSx for ONTAP。
- 没有与 FlexClone 等效的功能用于 CI/CD 工作流。
- 对于 P4 在执行 p4 verify 或 p4 obliterate 等操作时产生的混合随机与顺序 I/O 模式，延迟更高。
- 仅支持 NFS，没有 iSCSI 选项。这限制了 P4 的调优选项。
EFS 可能适用的场景
Amazon EFS 可以作为 P4 辅助组件的共享存储：配置文件、共享脚本，或多个实例需要访问的 SDP 工具。它不适合作为主 depot 后端。
S3 归档 depot
P4 原生支持将 Amazon S3 用作归档 depot 的存储后端。这不是一种通用型 depot 方案，而是专门用于不频繁访问内容的离线存储。
工作原理
您在 P4 中配置一个 archive depot 类型，该类型将文件数据直接存储在 S3 桶中，而非本地文件系统中。文件使用 p4 archive 命令从活动 depot 归档到 archive depot，并使用 p4 restore 命令恢复。Mountpoint for Amazon S3 还可以通过读优化的文件接口呈现 S3 桶（它不实现完整的 POSIX 语义）。它针对顺序读取进行了优化，仅支持对新对象的顺序写入；不支持活动 P4 depot 所需的随机、就地写入。
成本优势
在这四个选项中，Amazon S3 在大规模场景下提供最低的每 TB 成本，其生命周期策略可自动将数据从 S3 Standard 分层至 S3 Glacier 存储类别，用于长期保留。对于因业务或合同原因必须保留历史资产版本的影视工作室，S3 归档仓库可提供以较低每 GB 成本进行的无限期保留。请参阅 Amazon S3 定价页面 了解您所在区域的当前费率。
何时选择 S3
使用 Amazon S3 归档仓库存储冷数据：已发行游戏的资源、已弃用的引擎版本或历史构建中开发者很少访问但必须保留的内容。将 S3 与 Amazon EBS 或 FSx for ONTAP 上的活动仓库结合使用。活跃开发运行在高性能存储上，而已完成的项目则迁移到 S3 进行长期归档。
局限性
Amazon S3 无法作为活动 depot 操作的主要存储。对象存储提供的是整对象写入，而非 P4 在活动存档文件上执行的随机、原地写入，并且不提供 POSIX 文件锁定。加上对于交互式使用而言过高的请求延迟，这些访问模式差异使得 S3 不适合作为活动 depot 后端。Amazon S3 自 2020 年 12 月起已为所有请求提供强读后写一致性，因此数据一致性并非限制因素；对象写入语义和延迟才是。
对比摘要
下表从对游戏开发工作负载重要的维度对比了四个选项。
| 维度 | Amazon EBS gp3 | Amazon FSx for ONTAP | Amazon EFS | Amazon S3 归档 |
|---|---|---|---|---|
| 推荐的存储库大小 | 16 TB 以下 | 16 TB 以上 | 不推荐 | 仅归档 |
| 最大吞吐量 | 2,000 MiBps | 最高 72 GBps（横向扩展）³ | 10+ GBps（读取） | 高（顺序读取） |
| 延迟 | 约 1 ms（个位数） | 亚毫秒（SSD 层） | 低个位数毫秒 | 数十毫秒 |
| 共享访问 | 否 | 是（NFS、iSCSI、SMB） | 是（NFS） | 是（读优化） |
| 存储效率 | 无 | 最高 65%（去重 + 压缩）¹ | 无 | 生命周期分层 |
| 高可用模型 | 完整 P4 复制 | 共享卷（多可用区） | 共享卷 | N/A |
| 灾备方案 | EBS 快照 | SnapMirror 跨区域 | 跨区域复制 | S3 跨区域复制 |
| CI/CD 克隆 | 不支持 | FlexClone（即时） | 不支持 | 不适用 |
| 运维复杂度 | 低 | 中 | 低 | 低 |
| 相对成本（50 TB 活跃数据） | 中偏高（完整副本）² | 中等（含效率优化）² | 最高（完整副本，无效率优化）² | 最低（冷数据）² |
¹ AWS 文档记载，通用文件共享的存储容量最多可节省 65%。P4 存储库的实际节省幅度因资产构成而异。
² 相对排名，而非绝对成本。按每 GB-月费用从低到高排列：Amazon S3、FSx for ONTAP SSD、Amazon EBS gp3、Amazon EFS Standard。该排名反映了 50 TB 活跃存储库在各服务 HA 模型下的总成本：EBS 无法共享，因此提交服务器和 HA 备用节点（以及任何 DR 副本）各自保存一份完整副本（2–3 倍），这压过了其较低的每 GB 费率；FSx for ONTAP 和 EFS 共享一个卷，FSx 还通过存储效率和冷块分层进一步缩减了存储占用。请在您所在区域的 EBS、FSx for ONTAP、EFS 和 S3 定价页面上核实当前费率。
³ 72 GBps 是横向扩展文件系统的最大值（最多 12 个 HA 对）。单个 HA 对——P4 提交服务器的典型配置——可提供最高 6 GBps（第一代文件系统为 4 GBps）的吞吐量，仍远超 depot 的吞吐量需求。
决策框架
请根据贵工作室的规模，参考以下指导。
【图 1 – 为 Perforce P4 选择 AWS 存储的决策框架 — 在此插入决策框架流程图】
小型工作室
三个 P4 卷均从 Amazon EBS gp3 起步。在此规模下，较低的操作开销足以抵消维护完整副本的成本。使用 EBS 快照进行灾难恢复。
中型工作室
使用 Amazon EBS gp3 存储元数据和日志。使用 FSx for ONTAP 作为 depot 卷。存储效率节省和共享存储高可用模型在此规模下同时降低了成本和故障切换复杂度。对于已发布的标题，可考虑使用 Amazon S3 归档 depot。
大型工作室
对于 depot 存储，FSx for ONTAP 是明确的选择。commit 与副本之间的共享存储、用于 CI/CD 的 FlexClone、用于灾难恢复的 SnapMirror 以及存储效率功能在此规模下产生叠加效应。实施带有生命周期策略的 Amazon S3 归档 depot，以长期保留冷资产。
所有工作室
无论规模大小，均使用 Amazon EBS gp3 作为 /mnt/p4db（元数据）和 /mnt/p4logs（日志文件和日志）的存储卷。这些卷需要低延迟随机 I/O，而块存储在这方面表现最佳。
结论
为 AWS 上的 P4 选择合适的存储后端并非一刀切的决策。Amazon EBS gp3 为较小的 depot 提供了最低开销的路径。FSx for ONTAP 提供了大型工作室所需的性能、效率和运维优势。Amazon S3 归档 depot 以较低的每 GB 成本实现长期保留。Amazon EFS 虽然是面向其他工作负载的可靠服务，但并非 P4 depot 卷的合适选择。
首先测量您的 depot 大小和增长趋势，然后将其与上一节中的决策框架进行匹配。随着您的工作室规模扩大，您可以将 depot 卷从 Amazon EBS 迁移到 FSx for ONTAP，而无需更改元数据或日志配置。由于 SDP 存储布局将 depot 卷与元数据卷和日志卷保持独立，此迁移过程无需重新配置这些卷。
有关更多信息，请参阅 Perforce P4 AWS 部署指南 和 在 AWS 上构建 Perforce P4 指南。如需开始参考部署，请浏览 GitHub 上的云游戏开发工具包。
我们期待听到您的声音。如果您对本篇文章有任何问题或反馈，请在下方留言。如果您正在评估 P4 部署的存储方案并希望讨论您的架构，请通过您的 AWS 客户团队或联系 AWS与我们联系。
来源：AWS for Games · 游戏技术与运营 · aws.amazon.com