儲存

資料管理和儲存

使用 CSI 驅動程式將 AI 模型部署至 Pod

AI/ML 工作負載通常需要存取大型模型成品 （例如，經過訓練的權重、組態），而 Pod 需要可靠、可擴展的方式來存取這些成品，而無需將其內嵌在容器映像中，這可能會增加影像大小和容器登錄提取時間。為了降低管理磁碟區掛載的操作開銷，我們建議您使用各自的 CSI 驅動程式，將 Amazon 儲存服務 （例如 S3、FSx for Lustre、FSx for OpenZFS、EFS) 掛載為持久性磁碟區 (PVs)，以將 AI 模型部署至 Pod。如需實作詳細資訊，請參閱本節中的後續主題。

在 EKS 上最佳化 ML 模型快取的儲存體

利用最佳儲存解決方案對於將 Pod 和應用程式啟動延遲降至最低、減少記憶體使用量、取得所需的效能層級以加速工作負載，以及確保 ML 工作負載的可擴展性至關重要。ML 工作負載通常依賴模型檔案 （權重），這些檔案可能很大，需要跨 Pod 或節點共用存取資料。選取最佳儲存解決方案取決於工作負載的特性，例如單一節點效率、多節點存取、延遲要求、成本限制，以及資料整合要求 （例如使用 Amazon S3 資料儲存庫）。我們建議您使用工作負載對不同的儲存解決方案進行基準測試，以了解哪個解決方案符合您的需求，而且我們提供了下列選項，協助您根據您的工作負載需求進行評估。

EKS CSI 驅動程式支援下列 AWS Storage 服務，每個服務都有自己的 CSI 驅動程式，並為 AI 和 ML 工作流程提供自己的優勢：

• Amazon S3 掛載點

• Amazon FSx for Lustre

• Amazon FSx for OpenZFS

• Amazon EFS

• Amazon EBS

AWS Storage 服務的選擇取決於您的部署架構、規模、效能需求和成本策略。儲存 CSI 驅動程式需要安裝在 EKS 叢集上，這可讓 CSI 驅動程式在 Pod 生命週期外建立和管理持久性磁碟區 (PV)。使用 CSI 驅動程式，您可以將支援的 AWS Storage 服務的 PV 定義建立為 EKS 叢集資源。然後，Pod 可以透過為 PV 建立持久性磁碟區宣告 (PVC) 來存取其資料磁碟區的這些儲存磁碟區。視 AWS 儲存服務和部署案例而定，單一 PVC （及其相關聯的 PV) 可以連接到工作負載的多個 Pod。例如，對於 ML 訓練，共用訓練資料存放在 PV 上，並由多個 Pod 存取；對於即時線上推論，LLM 模型會快取在 PV 上，並由多個 Pod 存取。AWS Storage 服務的範例 PV 和 PVC YAML 檔案提供如下，以協助您開始使用。

監控效能 磁碟效能不佳可能會延遲容器映像讀取、增加 Pod 啟動延遲，以及降低推論或訓練輸送量。使用 Amazon CloudWatch 監控 AWS 儲存服務的效能指標。當您識別效能瓶頸時，請修改儲存組態參數以最佳化效能。

案例：多個 GPU 執行個體工作負載

Amazon FSx for Lustre：如果您有多個 EC2 GPU 運算執行個體環境具有延遲敏感和高頻寬輸送量動態工作負載，例如分散式訓練和模型服務，而且您需要原生 Amazon S3 資料儲存庫整合，我們建議您使用 Amazon FSx for Lustre。FSx for Lustre 提供全受管的高效能平行檔案系統，專為高效能運算 (HPC)、Machine Learning等運算密集型工作負載而設計。

您可以安裝 FSx for Lustre CSI 驅動程式，將 FSx 檔案系統掛載為持久性磁碟區 (PV)，然後將 FSx for Lustre 檔案系統部署為獨立高效能快取，或部署為 S3-linked檔案系統，以做為 S3 資料的高效能快取，提供跨 GPU 運算執行個體的資料存取快速 I/O 和高輸送量。FSx for Lustre 可以使用 Scratch-SSD 或 Persistent-SSD 儲存選項進行部署：

• Scratch-SSD 儲存：建議用於暫時性或短期 （小時） 的工作負載，並佈建每個 TiB 的固定輸送量容量。

• 持久性 SSD 儲存：建議用於需要最高水準可用性的任務關鍵型、長時間執行的工作負載，例如 HPC 模擬、大數據分析或Machine Learning訓練。使用持久性 SSD 儲存，您可以設定所需的儲存容量和輸送量容量 （每 TiB)。

效能考量：

• 管理 Pod 以管理 FSx for Lustre 檔案系統：設定已安裝 lustre 用戶端並掛載 FSx 檔案系統的「管理」Pod。這將使存取點能夠對 FSx 檔案系統進行微調，以及在您需要在啟動 GPU 運算執行個體之前，使用 ML 訓練資料或 LLM 模型預熱 FSx 檔案系統的情況下。如果您的架構使用 Spot 型 Amazon EC2 GPU/運算執行個體，其中您可以使用管理 Pod 將所需的資料「暖」或「預先載入」至 FSx 檔案系統，以便在執行 Spot 型 Amazon EC2 執行個體時準備好處理資料。

• Elastic Fabric Adapter (EFA)：持久性 SSD 儲存體部署類型支援 Elastic Fabric Adapter (EFA)，其中使用 EFA 是高效能和輸送量型 GPU 工作負載的理想選擇。請注意，FSx for Lustre 支援 NVIDIA GPUDirect Storage (GDS)，其中，GDS 是一種技術，可在本機或遠端儲存體與 GPU 記憶體之間建立直接資料路徑，以加快資料存取速度。

• 壓縮：如果您有可以壓縮的檔案類型，請在檔案系統上啟用資料壓縮。這有助於提高效能，因為資料壓縮可減少 FSx for Lustre 檔案伺服器和儲存體之間傳輸的資料量。

• Lustre 檔案系統分割組態：

  • 資料分割：允許 FSx for Luster 將檔案的資料分散到 Lustre 檔案系統中的多個物件儲存目標 (OSTs)，將平行存取和輸送量最大化，尤其是針對大規模 ML 訓練任務。

  • 獨立檔案系統分割：根據預設，會透過 FSx for Lustre 的漸進式檔案配置 (PFL) 功能為您建立 4 元件 Lustre 分割組態。在大多數情況下，您不需要更新預設 PFL Lustre 條紋計數/大小。如果您需要調整 Lustre 資料分割，您可以參考 FSx for Lustre 檔案系統的分割參數，手動調整 Lustre 分割。

  • S3-Linked檔案系統：使用原生 Amazon S3 整合 （資料儲存庫關聯或 DRA) 匯入 FSx 檔案系統的檔案不使用預設 PFL 配置，而是在檔案系統的 ImportedFileChunkSize 參數中使用配置。大於 S3-imported檔案ImportedFileChunkSize將存放在多個 OSTs 上，並根據ImportedFileChunkSize定義的值 （預設 1GiB) 具有條紋計數。如果您有大型檔案，建議您將此參數調校為較高的值。

  • 配置：在與運算或 GPU 節點相同的可用區域中部署 FSx for Lustre 檔案系統，以啟用資料的最低延遲存取，避免跨可用區域存取模式。如果您的多個 GPU 節點位於不同的可用區域，建議您在每個可用區域中部署 FSx 檔案系統，以實現低延遲的資料存取。

範例

FSx for Lustre 檔案系統的持久性磁碟區 (PV) 定義，使用靜態佈建 （其中已佈建 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

如需完整範例，請參閱 GitHub 中的 FSx for Lustre 驅動程式範例。使用 Amazon CloudWatch 監控 Amazon FSx for Lustre 效能指標。 Amazon CloudWatch 發現效能瓶頸時，請視需要調整您的組態參數。

案例：單一 GPU 執行個體工作負載

搭配 CSI 驅動程式的 Amazon S3 掛載點：您可以使用適用於 Amazon S3 CSI 驅動程式的掛載點，將 Amazon S3 儲存貯體掛載為 Pod 中的磁碟區。此方法允許精細存取控制 Pod 可以存取特定 S3 儲存貯體。每個 Pod 都有自己的掛載點執行個體和本機快取 (5-10GB)，在 Pod 之間隔離模型載入和讀取效能。此設定支援使用 IAM Roles for Service Accounts (IRSA) 進行 Pod 層級身分驗證，並支援不同模型或客戶的獨立模型版本控制。權衡是記憶體用量和 API 流量的增加，因為每個 Pod 都會發出 S3 API 呼叫並維護自己的快取。

Pod 部署 YAML 搭配 CSI 驅動程式的部分範例：

# 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 的掛載點可以快取內容，以降低成本並改善對相同檔案重複讀取的效能。如需快取選項和參數，請參閱快取組態。

• 物件部分大小：存放和存取大小超過 72GB 的檔案時，請參閱設定掛載點效能，了解如何設定 --read-part-size和 --write-part-size命令列參數以符合您的資料設定檔和工作負載需求。

• Shared-cache 專為大小上限為 1MB 的物件而設計。它不支援大型物件。使用本機快取選項在 NVMe 或 EKS 節點的 EBS 磁碟區中快取物件。

• API 請求費用：使用 S3 掛載點執行大量檔案操作時，API 請求費用可能會成為儲存成本的一部分。若要緩解這種情況，如果不需要強式一致性，請一律啟用中繼資料快取，並將 metadata-ttl API 操作次數設定為 S3。

如需詳細資訊，請參閱 Amazon EKS 官方文件中的 Amazon S3 CSI 驅動程式掛載點。如果發生瓶頸，我們建議您使用 Amazon CloudWatch 指標監控 Amazon S3 的效能指標 Amazon CloudWatch，並視需要調整您的組態。

Amazon FSx for OpenZFS 持久共用儲存

對於涉及多個 EC2 GPU 運算執行個體的案例，以及需要不同應用程式的高可用性、高效能、成本敏感度和多個 Pod 部署的延遲敏感工作負載，我們建議使用 Amazon FSx for OpenZFS。有些工作負載範例包括即時推論、強化學習和訓練生成對手網路。FSx for OpenZFS 特別適用於需要高效能存取聚焦目錄結構的工作負載，以及使用小型 IO 資料存取模式的小型檔案。此外，FSx for OpenZFS 提供獨立於儲存容量的彈性擴展效能，透過將儲存大小與實際需求配對，同時維持所需的效能等級，協助您達成最佳的成本效益

原生 FSx for OpenZFS CSI 驅動程式允許透過建立多個磁碟區，將多個 PVCs 建立到單一檔案系統。這可減少管理開銷，並透過單一檔案系統上的合併應用程式 Pod 部署，最大化檔案系統的輸送量和 IOPS 使用率。此外，它還包含企業功能，例如零複本快照、零複本複製，以及可透過 CSI 驅動程式動態佈建的使用者和群組配額。

FSx for OpenZFS 在建立時支援三種不同的部署類型：

• 單一可用區：具有低於毫秒延遲的最低成本選項，但檔案系統或可用區域層級不提供高可用性。建議用於開發和測試工作負載或在應用程式層具有高可用性的工作負載。

• 單一可用區 (HA)：在檔案系統層級以低於毫秒的延遲提供高可用性。建議用於需要高可用性的最高效能工作負載。

• 異地同步備份：在檔案系統層級以及跨可用區域提供高可用性。建議用於需要跨可用區域額外可用性的高效能工作負載。

效能考量：

• 部署類型：如果不需要跨可用區域的其他可用性，請考慮使用單一可用區 (HA) 部署類型。此部署類型提供高達 100% 的寫入輸送量、維持低於毫秒的延遲，而且 Gen2 檔案系統具有額外的 NVMe 快取，可儲存高達 TB 的經常存取資料。多可用區域檔案系統提供高達 75% 的寫入輸送量，延遲增加，以容納跨可用區域流量。

• 輸送量和 IOPS：針對檔案系統設定的輸送量和 IOPS 都可以在部署後向上或向下擴展。您可以佈建高達 10GB/s 的磁碟輸送量，提供高達 21GB/s 的快取資料存取。IOPS 可以從磁碟擴展到 400，000 個，快取可提供超過 100 萬個 IOPS。請注意，單一可用區檔案系統的輸送量擴展確實會導致檔案系統短暫中斷，因為沒有高可用性。單一可用區 (HA) 或多可用區檔案系統的輸送量擴展可以不中斷地完成。SSD IOPS 可以每六小時擴展一次。

• 儲存類別：FSx for OpenZFS 同時支援 SSD 儲存類別和 Intelligent-Tiering 儲存類別。對於 AI/ML 工作負載，建議您使用 SSD 儲存類別，為 CPU/GPU 盡可能保持忙碌的工作負載提供一致的效能。

• 壓縮：如果您的工作負載可以壓縮，請啟用 LZ4 壓縮演算法。這可減少每個檔案在快取中耗用的資料量，允許直接從快取提供更多資料做為網路輸送量，並降低 SSD 磁碟上的負載 IOPS。

• 記錄大小：大多數 AI/ML 工作負載將受益於保留預設的 128KiB 記錄大小。只有在資料集由大型檔案 (10GiB 以上） 組成，且應用程式的一致性小區塊存取低於 128KiB 時，才應降低此值。

建立檔案系統後，服務會自動建立相關聯的根磁碟區。最佳實務是將資料存放在檔案系統根磁碟區的子磁碟區中。使用 FSx for OpenZFS CSI 驅動程式，您可以建立相關聯的持久性磁碟區宣告，以動態建立子磁碟區。

範例：

FSx for OpenZFS 磁碟區的儲存類別 (SC) 定義，用於在現有檔案系統上建立根磁碟區的子磁碟區 ($ROOT_VOL_ID)，並使用 NFS v4.2 通訊協定將磁碟區匯出至 VPC CIDR ($VPC_CIDR)。

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

針對上述建立的 fsxz-vol-sc 動態建立持久性磁碟區宣告 (PVC)。請注意，配置的儲存容量為 1Gi，FSx for OpenZFS 磁碟區為必要項目，如 CSI 驅動程式常見問答集中所述。磁碟區將獲提供使用此組態佈建至檔案系統的完整容量。如果需要限制磁碟區容量，您可以使用使用者或群組配額來執行此操作。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-vol-pvc
  namespace: example
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: fsxz-vol-sc
  resources:
    requests:
      storage: 1Gi

設定 Pod 以使用 dynamic-vol-pvc 的持久性磁碟區宣告 (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) 都會建立為 EFS 檔案系統的 EFS 存取點。EFS 允許多個節點和 Pod 存取相同的模型檔案，無需將資料同步到每個節點的檔案系統。安裝 EFS CSI 驅動程式，將 EFS 與 EKS 整合。

您可以使用下列輸送量模式部署 Amazon EFS 檔案系統：

• 爆量輸送量：擴展檔案系統大小的輸送量，適用於偶爾爆量的各種工作負載。

• 佈建輸送量：專用輸送量，非常適合具有可預測效能需求的一致 ML 訓練任務。

• 彈性輸送量 （建議 ML 使用）：根據工作負載、不同 ML 工作負載的成本效益自動擴展。

若要檢視效能規格，請參閱 Amazon EFS 效能規格。

效能考量：

• 將彈性輸送量用於不同的工作負載。

• 針對作用中 ML 工作負載使用標準儲存類別。

如需在 EKS 叢集和 Pod 中使用 Amazon EFS 檔案系統作為持久性磁碟區的完整範例，請參閱 GitHub 中的 EFS CSI 驅動程式範例。使用 Amazon CloudWatch 監控 Amazon EFS 效能指標。 Amazon CloudWatch 發現效能瓶頸時，請視需要調整您的組態參數。

將 S3 Express One Zone 用於延遲敏感的物件導向工作流程

對於 Amazon EKS 上的延遲敏感 AI/ML 工作負載，例如大規模模型訓練、推論或高效能分析，建議使用 S3 Express One Zone 進行高效能模型儲存和擷取。S3 Express One Zone 提供階層式命名空間，例如檔案系統，您只需上傳到目錄儲存貯體，適合「卡入所有內容」，同時維持高速。如果您熟悉物件導向工作流程，這特別有用。或者，如果您更習慣檔案系統 （例如 POSIX 相容），您可能偏好 Amazon FSx for Lustre 或 OpenZFS。Amazon S3 Express One Zone 使用目錄儲存貯體將資料存放在單一可用區域 (AZ)，並提供比標準 S3 儲存貯體更低的延遲，該儲存貯體會將資料分散到多個AZs。為了獲得最佳結果，請務必將 EKS 運算與 Express One Zone 儲存貯體位於相同的可用區域中。若要進一步了解 S3 Express One Zone 的差異，請參閱目錄儲存貯體的差異。

若要使用檔案系統語意存取 S3 Express One Zone，建議使用掛載點 S3 CSI 驅動程式，該驅動程式會將 S3 儲存貯體 （包括 Express One Zone) 掛載為本機檔案系統。這會將檔案操作 （例如，開啟、讀取、寫入） 轉換為 S3 API 呼叫，為多個用戶端的大量讀取工作負載和循序寫入新物件提供最佳化的高輸送量存取。如需支援的操作和限制的詳細資訊 （例如，沒有完整的 POSIX 合規，但附加和重新命名 Express One Zone 中支援），請參閱掛載點語意文件。

效能優勢

• 提供比 S3 Standard 快 10 倍的資料存取，具有一致的單一位數毫秒延遲和高達 80% 的請求成本。

• 擴展以處理每個目錄儲存貯體每秒數十萬到數百萬個請求，避免在極端載入期間在標準 S3 中看到限流或中斷 （例如，從具有數十到數十萬GPUs/CPUs 飽和網路的叢集）。

• 使用工作階段型身分驗證機制。驗證一次以取得工作階段字符，然後以高速執行重複操作，而不會產生每次請求身分驗證的額外負荷。這針對頻繁檢查點或資料載入等工作負載進行了最佳化。

建議的使用案例

• 快取：搭配 S3 Express One Zone 使用掛載點 S3 CSI 驅動程式的其中一個主要使用案例是快取。第一個執行個體會從 S3 Standard （一般用途） 讀取資料，並在低延遲的 Express One Zone 中快取資料。其他用戶端後續讀取會更快地存取快取的資料，這非常適合多個 EKS 節點讀取相同資料 （例如，共用訓練資料集） 的多節點案例。對於重複存取和降低運算成本，這可以提高效能高達 7 倍。對於需要完全 POSIX 合規的工作負載 （例如檔案鎖定和就地修改），請將 Amazon FSx for Lustre 或 OpenZFS 視為替代方案。

• 大規模 AI/ML 訓練和推論：非常適合具有數百個或數千個運算節點 （例如 EKS 叢集中的 GPUs) 的工作負載，其中一般用途 S3 限流可能會導致延遲，浪費昂貴的運算資源。例如，執行每日模型測試/檢查點的 LLM 研究人員或組織受益於快速、可靠的存取，而不會破壞區域 S3。對於較小的工作負載 （例如 10 個節點），S3 Standard 或其他儲存類別可能已足夠。

• 資料管道：載入/準備模型、封存訓練資料或串流檢查點。如果您的團隊偏好物件儲存，而非傳統檔案系統 （例如，由於熟悉 S3)，請針對 FSx for Lustre 等 POSIX 相容選項，使用此選項而非工程變更。

考量

• 彈性：單一可用區設計提供 99.999999999% 的耐用性 （與標準 S3 相同，透過 AZ 中的備援），但相較於多可用區類別 (99.99% 的可用性），可用性較低 (99.95% 的設計、99.9% 的 SLA)。它對 AZ 故障的彈性較低。使用 可重新建立或快取的資料。考慮對關鍵工作負載進行多可用區複寫或備份。

• API 和功能支援：支援 S3 API 的子集 （例如，沒有生命週期政策或複寫）；可能需要對工作階段身分驗證或物件處理進行次要應用程式變更。 APIs

• EKS 整合：將 EKS Pod/節點與目錄儲存貯體位於相同的 AZ 中，以將網路延遲降至最低。使用適用於 Amazon S3 或 CSI 驅動程式的掛載點進行 Kubernetes 原生存取。

• 測試：在非生產環境中測試擷取延遲，以驗證效能提升。在標準 S3 案例中監控限流 （例如高 GPU 飽和度） 並比較。

S3 Express One Zone 儲存類別可在多個區域使用，並針對需要物件存取的工作負載與 EKS 整合，而無需等待儲存。若要進一步了解，請參閱 S3 Express One Zone 入門。