本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
存储
数据管理和存储
使用 CSI 驱动程序将 AI 模型部署到 Pod
AI/ML 工作负载通常需要访问大型模型工件(例如训练过的权重、配置),而 pod 需要一种可靠、可扩展的方式来访问这些工件,而无需将它们嵌入到容器镜像中,这可能会增加图像大小和容器注册表拉取时间。为了减少管理卷挂载的运营开销,我们建议使用相应的 CSI 驱动程序将 Amazon 存储服务(例如 S3、Lustre、OpenZFS、EFS)安装 FSx 为永久卷 PVs (),将 AI 模型部署到 pod 中。 FSx 有关实现的详细信息,请参阅本节的后续主题。
在 EKS 上优化 ML 模型缓存的存储
利用最佳存储解决方案对于最大限度地缩短 pod 和应用程序启动延迟、减少内存使用量、获得所需的性能水平以加速工作负载以及确保机器学习工作负载的可扩展性至关重要。机器学习工作负载通常依赖模型文件(权重),模型文件可能很大,需要在 Pod 或节点之间共享对数据的访问权限。选择最佳存储解决方案取决于您的工作负载的特征,例如单节点效率、多节点访问、延迟要求、成本限制以及数据集成要求(例如与 Amazon S3 数据存储库的集成)。我们建议根据您的工作负载对不同的存储解决方案进行基准测试,以了解哪一种解决方案符合您的要求,并且我们提供了以下选项来帮助您根据工作负载要求进行评估。
EKS CSI 驱动程序支持以下 AWS 存储服务,每种服务都有自己的 CSI 驱动程序,并且在 AI 和 ML 工作流程方面各有优势:
AWS 存储服务的选择取决于您的部署架构、规模、性能要求和成本策略。需要在您的 EKS 集群上安装存储 CSI 驱动程序,这允许 CSI 驱动程序在 Pod 生命周期之外创建和管理永久卷 (PV)。使用 CSI 驱动程序,您可以将支持的 AWS 存储服务创建为 EKS 集群资源的 PV 定义。然后,Pod 可以通过为 PV 创建永久卷声明 (PVC) 来访问这些存储卷作为其数据卷。根据 AWS 存储服务和您的部署方案,可以将单个 PVC(及其关联的 PV)连接到多个 Pod 以处理一个工作负载。例如,对于 ML 训练,共享的训练数据存储在 PV 上并由多个 Pod 访问;为了进行实时在线推理,LLM 模型缓存在一个 PV 上并由多个 Pod 访问。下面提供了 AWS 存储服务的示例 PV 和 PVC YAML 文件,以帮助您入门。
监控性能不佳的磁盘性能会延迟容器映像读取、增加 pod 启动延迟,并降低推理或训练吞吐量。使用 Amazon CloudWatch 监控您的 AWS 存储服务的性能指标。当您发现性能瓶颈时,请修改存储配置参数以优化性能。
场景:多个 GPU 实例工作负载
Amazon FSx for Lustre:如果您有多个 EC2 GPU 计算实例环境,其中包含对延迟敏感和高带宽吞吐量的动态工作负载(例如分布式训练和模型服务),并且需要原生 Amazon S3 数据存储库集成,我们建议使用 Amazon for Lustre。 FSx FSx for Lustre 提供了一个完全托管的高性能并行文件系统,专为高性能计算 (HPC)、Machine Learning 等计算密集型工作负载而设计。
您可以安装 for Lustre CSI 驱动程序,将 FSx 文件系统作为永久卷 (PV) 挂载到 EKS 上,然后将 Lustre 文件系统部署 FSx 为独立的高性能缓存或与 S3 关联的文件系统,以充当 S3 数据的高性能缓存,从而为通过 GPU 计算实例访问数据提供快速 I/O 而高的吞吐量。 FSx FSx for Lustre 可以使用 Scratch-SSD 或永久固态硬盘存储选项进行部署:
-
Scratch-SSD 存储:建议用于临时或短期(小时)的工作负载,每个 Tib 预配置的吞吐量容量是固定的。
-
永久固态硬盘存储:建议用于需要最高可用性的任务关键型、长时间运行的工作负载,例如 HPC 模拟、大数据分析或 Machine Learning 训练。使用永久 SSD 存储,您可以配置所需的存储容量和吞吐容量(每 TiB)。
性能注意事项:
-
要为 Lustre 文件系统管理 FSx 的管理 P od:配置一个 “管理” Pod,该容器安装了 lustre 客户端并安装了 FSx 文件系统。这将使接入点能够对 FSx 文件系统进行微调,也可以在需要在启动 GPU 计算实例之前使用 ML 训练数据或 LLM 模型对 FSx 文件系统进行预热的情况下。如果您的架构使用基于 Spot 的 Amazon EC2 GPU/Compute 实例,则这一点尤其重要,在这些实例中,您可以利用管理 Pod 将所需数据 “预热” 或 “预加载” 到 FSx 文件系统中,以便在运行基于 Spot 的 Amazon 实例时可以处理数据。 EC2
-
Elastic F@@ abric Adapter (EFA):永久固态硬盘存储部署类型支持弹性结构适配器 (EFA),其中使用 EFA 非常适合基于高性能和吞吐量的 GPU 工作负载。请注意, FSx Lustre 支持 NVIDIA GPUDirect 存储 (GDS),其中 GDS 是一种在本地或远程存储与 GPU 内存之间创建直接数据路径的技术,以实现更快的数据访问。
-
压缩:如果您的文件类型可以压缩,请在文件系统上启用数据压缩。这有助于提高性能,因为数据压缩可以减少在 Lustre 文件服务器和存储之间 FSx 传输的数据量。
-
Lustre 文件系统条带化配置:
-
数据条带化:允许 FSx Luster 在 Lustre 文件系统中的多个对象存储目标 (OSTs) 上分发文件数据,从而最大限度地提高并行访问和吞吐量,尤其是在大规模机器学习训练作业中。
-
独立文件系统条带化:默认情况下,将通过 for Lustre 的渐进式文件布局 (PFL) 功能为您创建一个 4 组件 Lustre 条带化配置。 FSx 在大多数情况下,你不需要更新默认的 PFL Lustre 条带数量/大小。如果需要调整 Lustre 数据条带,则可以通过参考 for Lustre 文件系统的条带化参数来手动调整 Lustre 条带。 FSx
-
S3 链接文件系统:使用原生 Amazon S3 集成(数据存储库关联或 DRA)导入 FSx 文件系统的文件不使用默认 PFL 布局,而是使用文件系统参数中的布局。
ImportedFileChunkSize
大于 s3 的导入文件ImportedFileChunkSize
将存储在多个文件中,条 OSTs 带数基于ImportedFileChunkSize
定义的值(默认为 1GiB)。如果您有较大的文件,我们建议将此参数调整为更高的值。 -
放置:将 for Lustre 文件系统部署在与计算或 GPU 节点相同的可用区中,以实现最低延迟的数据访问,避免跨可用区访问模式。 FSx 如果您有多个 GPU 节点位于不同的可用区,那么我们建议您在每个可用区部署一个 FSx 文件系统,以实现低延迟的数据访问。
-
示例
for Lustre 文件系统的永久卷 (PV) 定义,使用静态配置( FSx 实例已配置完毕)。 FSx
apiVersion: v1 kind: PersistentVolume metadata: name: fsx-pv spec: capacity: storage: 1200Gi volumeMode: Filesystem accessModes: - ReadWriteMany mountOptions: - flock persistentVolumeReclaimPolicy: Recycle csi: driver: fsx.csi.aws.com volumeHandle: [FileSystemId of FSx instance] volumeAttributes: dnsname: [DNSName of FSx instance] mountname: [MountName of FSx instance]
示例
PV 的永久容量声明定义为fsx-pv
:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: fsx-claim spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1200Gi volumeName: fsx-pv
示例
将 Pod 配置为使用永久卷声明fsx-claim
:
apiVersion: v1 kind: Pod metadata: name: fsx-app spec: containers: - name: app image: amazonlinux:2023 command: ["/bin/sh"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: fsx-claim
有关完整示例,请参阅中的 FSx Lustre 驱动程序示例。 GitHub
场景:单 GPU 实例工作负载
带有 CSI 驱动程序的 Amazon S3 的 Mountpoint:你可以使用 Moun tpoint for Amazon S3 CSI 驱动程序将 S3 存储桶作为卷挂载到你的 pod 中。此方法允许对哪些 Pod 可以访问特定的 S3 存储桶进行精细的访问控制。每个 Pod 都有自己的挂载点实例和本地缓存(5-10GB),从而隔离了 Pod 之间的模型加载和读取性能。此设置支持使用服务账户的 IAM 角色 (IRSA) 进行 pod 级身份验证,并支持针对不同模型或客户的独立模型版本控制。权衡是内存使用量和 API 流量增加,因为每个 pod 都会发出 S3 API 调用并维护自己的缓存。
示例使用 CSI 驱动程序的 Pod 部署 YAML 的部分示例:
# CSI driver dynamically mounts the S3 bucket for each pod volumes: - name: s3-mount csi: driver: s3.csi.aws.com volumeAttributes: bucketName: your-s3-bucket-name mountOptions: "--allow-delete" # Optional region: us-west-2 containers: - name: inference image: your-inference-image volumeMounts: - mountPath: /models name: s3-mount volumeMounts: - name: model-cache mountPath: /models volumes: - name: model-cache hostPath: path: /mnt/s3-model-cache
性能注意事项:
-
数据缓存:适用于 S3 的 Mountpoint 可以缓存内容以降低成本并提高重复读取同一文件的性能。有关缓存选项和参数,请参阅缓存配置
。 -
对象部分大小:存储和访问大小超过 72GB 的文件时,请参阅配置 Mountpoint 性能,了解如何配置
--read-part-size
和--write-part-size
命令行参数以满足您的数据配置文件和工作负载要求。 -
共享缓存
专为大小不超过 1MB 的对象而设计。它不支持大型对象。使用本地缓存选项缓 存 EKS 节点上的 EBS 卷中的对象 NVMe 或 EBS 卷。 -
API 请求费用:使用适用于 S3 的 Mountpoint 执行大量文件操作时,API 请求费用可能会成为存储成本的一部分。为了缓解这种情况,如果不需要强一致性,请务必启用元数据缓存,并将
metadata-ttl
时间设置为将 API 操作数量减少到 S3。
有关更多详细信息,请参阅亚马逊 EKS 官方文档中的 Mountpoint for Amazon S3 CSI 驱动程序。如果出现瓶颈,我们建议使用亚马逊指标监控 Amazon S3 的性能 CloudWatch 指标,并在需要时调整配置。
FSx 适用于 OpenZFS 的亚马逊永久共享存储
对于涉及多个 EC2 GPU 计算实例和延迟敏感型工作负载的场景,这些工作负载需要高可用性、高性能、成本敏感性,以及针对不同应用程序部署多个 Pod,我们建议使用 Amazon for OpenZFS。 FSx 一些工作负载示例包括实时推理、强化学习和训练生成对抗网络。 FSx for OpenZFS 对于需要高性能访问具有小文件且使用小 IO 数据访问模式的小文件的高性能目录结构的工作负载特别有用。此外,fo FSx r OpenZFS 提供了独立于存储容量扩展性能的灵活性,在保持所需性能水平的同时,将存储大小与实际需求相匹配,从而帮助您实现最佳成本效益
OpenZFS CSI 原生FSx 驱动程序
FSx 适用于 OpenZFS 在创建时支持三种不同的部署类型:
-
单可用区:成本最低的选项,延迟时间为亚毫秒,但在文件系统或可用区级别不提供高可用性。建议用于开发和测试工作负载或在应用程序层具有高可用性的工作负载。
-
单可用区 (HA):在文件系统级别提供高可用性,延迟为亚毫秒。建议用于需要高可用性的最高性能工作负载。
-
多可用区:在文件系统级别以及跨可用区域提供高可用性。建议用于需要跨可用区提高可用性的高性能工作负载。
性能注意事项:
-
部署类型:如果不需要跨可用区的额外可用性,请考虑使用单可用区 (HA) 部署类型。这种部署类型可提供高达 100% 的写入吞吐量,保持亚毫秒级的延迟,而且 Gen2 文件系统还有一个额外的 NVMe 缓存,用于存储高达 TB 的频繁访问数据。多可用区文件系统以更高的延迟为写入提供高达 75% 的吞吐量,以适应跨可用区的流量。
-
吞吐量和 IOPS:为文件系统配置的吞吐量和 IOPS 都可以在部署后向上或向下扩展。您最多可以配置 10% GB/s of disk throughput providing up to 21GB/s 的缓存数据访问权限。IOPS 可以从磁盘扩展到 400,000,缓存可以提供超过 100 万的 IOPS。请注意,由于不存在高可用性,单可用区文件系统的吞吐量扩展确实会导致文件系统短暂中断。可以无中断地扩展单可用区 (HA) 或多可用区文件系统的吞吐量。固态硬盘 IOPS 可以每六小时扩展一次。
-
存储类别: FSx 适用于 OpenZFS,支持固态硬盘存储类别和智能分层存储类别。对于 AI/ML 工作负载,建议使用固态硬盘存储类别,为工作负载提供稳定的性能,从而使 CPU/GPU 尽可能繁忙。
-
压缩:如果您的工作负载可以LZ4 压缩,请启用压缩算法。这减少了每个文件在缓存中消耗的数据量,从而可以直接从缓存中提供更多数据,因为网络吞吐量和 IOPS 可以减少 SSD 磁盘上的负载。
-
记录大小:保留默认的 128KiB 记录大小将使大多数 AI/ML 工作负载受益。只有当数据集由大文件(大于 10GiB)组成,且应用程序对小块的访问量始终低于 128KiB 时,才应降低此值。
创建文件系统后,服务会自动创建关联的根卷。最佳做法是将数据存储在文件系统上根卷的子卷中。使用FSx 适用于 OpenZFS 的 CSI 驱动程序
示例:
适用于 OpenZFS 的卷的存储类别 (SC) 定义,用于在现有文件系统上创建根卷 ($ROOT_VOL_ID) 的子卷,然后使用 NFS v4.2 协议将该卷导出到 VPC CIDR ($VPC_CIDR)。 FSx
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fsxz-vol-sc provisioner: fsx.openzfs.csi.aws.com parameters: ResourceType: "volume" ParentVolumeId: '"$ROOT_VOL_ID"' CopyTagsToSnapshots: 'false' DataCompressionType: '"LZ4"' NfsExports: '[{"ClientConfigurations": [{"Clients": "$VPC_CIDR", "Options": ["rw","crossmnt","no_root_squash"]}]}]' ReadOnly: 'false' RecordSizeKiB: '128' Tags: '[{"Key": "Name", "Value": "AI-ML"}]' OptionsOnDeletion: '["DELETE_CHILD_VOLUMES_AND_SNAPSHOTS"]' reclaimPolicy: Delete allowVolumeExpansion: false mountOptions: - nfsvers=4.2 - rsize=1048576 - wsize=1048576 - timeo=600 - nconnect=16 - async
针对上面创建的动态创建的永久卷声明 (PVC)。 fsxz-vol-sc注意,分配的存储容量为 1Gi,这是 OpenZFS 卷所必 FSx 需的,如 CSI
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dynamic-vol-pvc namespace: example spec: accessModes: - ReadWriteMany storageClassName: fsxz-vol-sc resources: requests: storage: 1Gi
使用以下内容的永久卷声明 (PVC) 配置 pod 以挂载卷 dynamic-vol-pvc:
kind: Pod apiVersion: v1 metadata: name: fsx-app namespace: example spec: volumes: - name: dynamic-vol-pv persistentVolumeClaim: claimName: dynamic-vol-pvc containers: - name: app image: amazonlinux:2023 command: ["/bin/sh"] volumeMounts: - mountPath: "/mnt/fsxz" name: dynamic-vol-pv
适用于共享模型缓存的 Amazon EFS
如果您有多 EC2 GPU 计算实例环境,并且动态工作负载需要跨多个节点和可用区共享模型访问权限(例如,使用 Karpenter 进行实时在线推理),且性能和可扩展性需求适中,我们建议通过 EFS CSI 驱动程序将 Amazon Elastic File System (EFS) 文件系统用作永久卷。Amazon EFS 是一个完全托管、高度可用且可扩展的基于云的 NFS 文件系统,它使具有共享文件存储的 EC2 实例和容器具有一致的性能,并且无需预先配置存储。使用 EFS 作为模型卷,并通过在 EKS 集群上定义永久卷将该卷作为共享文件系统挂载。由 EFS 文件系统支持的每个永久卷声明 (PVC) 都是作为 E FS 文件系统的 EFS 访问点创建的。EFS 允许多个节点和 pod 访问相同的模型文件,无需将数据同步到每个节点的文件系统。安装 EFS CSI 驱动程序,将 EFS 与 EKS 集成。
您可以使用以下吞吐量模式部署 Amazon EFS 文件系统:
-
突增吞吐量:根据文件系统大小扩展吞吐量,适用于偶尔出现突发的不同工作负载。
-
预配置吞吐量:专用吞吐量,非常适合在限制范围内具有可预测性能需求的一致机器学习训练作业。
-
弹性吞吐量(建议用于机器学习):根据工作负载自动扩展,针对不同的机器学习工作负载实现成本效益。
要查看性能规格,请参阅 Amazon EFS 性能规范。
性能注意事项:
-
使用弹性吞吐量处理不同的工作负载。
-
对活跃的 ML 工作负载使用标准存储类。
有关在 EKS 集群和 Pod 中使用 Amazon EFS 文件系统作为永久卷的完整示例,请参阅中的 EFS CSI 驱动程序示例 GitHub
使用 S3 Express One Zone 实现对延迟敏感的、面向对象的工作流程
对于 Amazon EKS AI/ML 上对延迟敏感的工作负载,例如大规模模型训练、推理或高性能分析,我们建议使用 S3 Express One Zon e 进行高性能模型存储和检索。S3 Express One Zone 提供了一个分层命名空间,比如文件系统,你只需在其中上传到目录存储桶,适合 “将所有内容放进去”,同时保持高速度。如果您习惯了面向对象的工作流程,则此功能特别有用。或者,如果您更习惯于文件系统(例如兼容 POSIX),则可能更喜欢使用亚马逊 FSx 来获取 Lustre 或 OpenZFS。Amazon S3 Express One Zone 使用目录存储桶将数据存储在单个可用区 (AZ) 中,并且延迟低于标准 S3 存储桶,后者将数据分发到多个可用区 (AZ)。 AZs为了获得最佳结果,请确保将 EKS 计算与您的 Express One Zone 存储桶放在同一个可用区中。要详细了解 S3 Express One Zone 的区别,请参阅目录存储桶的差异。
要使用文件系统语义访问 S3 Express One Zone,我们建议使用 Mountpoint S3 CSI 驱动程序,该驱动程序
性能优势
-
数据访问速度比 S3 标准版快 10 倍,延迟保持在个位数毫秒,请求成本最多可降低 80%。
-
可扩展到每个目录存储桶每秒处理数十万至数百万个请求,从而避免了在极端负载期间(例如,来自具有数万到数十万个 GPUs/CPUs 饱和网络的集群)在标准 S3 中出现的限流或停电。
-
使用基于会话的身份验证机制。进行一次身份验证即可获得会话令牌,然后高速重复执行操作,而不会产生每个请求的身份验证开销。这针对频繁的检查点操作或数据加载等工作负载进行了优化。
推荐用例
-
缓存:在 S3 Express One Zone 中使用 Mountpoint S3 CSI 驱动程序的首要用例之一是缓存。第一个实例从 S3 标准(通用)读取数据,将其缓存到延迟较低的 Express One Zone 中。其他客户端的后续读取可以更快地访问缓存的数据,这非常适合多个 EKS 节点读取相同数据(例如,共享训练数据集)的多节点场景。这可以将重复访问的性能提高多达 7 倍,并降低计算成本。对于需要完全符合 POSIX 标准的工作负载(例如文件锁定和就地修改),可以考虑将 Amazon for Lustre 或 OpenZFS FSx 作为替代方案。
-
大规模 AI/ML 训练和推理:非常适合具有数百或数千个计算节点的工作负载(例如, GPUs 在 EKS 集群中),在这些工作负载中,通用 S3 限制可能会导致延迟,浪费昂贵的计算资源。例如,法学硕士研究人员或运行每日模型的组织可以从快速、可靠的访问中 tests/checkpoints 受益,而不会破坏区域S3。对于规模较小的工作负载(例如 10 个节点),S3 标准或其他存储类别可能就足够了。
-
数据管道: Load/prepare 模型、存档训练数据或流检查点。如果您的团队更喜欢对象存储而不是传统文件系统(例如,由于熟悉 S3),请使用它来代替对符合 POSIX 的选项(例如 Lustre)进行工程更改。 FSx
注意事项
-
弹性:单可用区设计提供 99.999999999% 的持久性(与标准 S3 相同,通过可用区内的冗余),但与多可用区类别(99.99% 的可用性)相比,可用性较低(设计为 99.95%,服务级别协议 99.9%)(可用性为 99.99%)。它对可用区故障的弹性较差。用于可重新创建或缓存的数据。考虑对关键工作负载进行多可用区复制或备份。
-
API and Feature Support:支持 S3 的子集 APIs (例如,没有生命周期策略或复制);可能需要对应用程序进行细微更改才能进行会话身份验证或对象处理。
-
EKS 集成:将您的 EKS 与目录存储桶放在同一个可用区 pods/nodes 中,以最大限度地减少网络延迟。使用适用于 Amazon S3 的 Mountpoint 或 CSI 驱动程序进行 Kubernetes 原生访问。
-
测试:在非生产环境中测试检索延迟,以验证性能提升。监控标准 S3 场景(例如 GPU 饱和度高)中的限制并进行比较。
S3 Express One Zone 存储类可在多个区域使用,并与 EKS 集成,适用于需要访问对象而无需等待存储的工作负载。要了解更多信息,请参阅 S3 Express One 区域入门。