儲存 - Amazon EKS
資料管理和儲存

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

儲存

資料管理和儲存

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

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

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

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

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

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 檔案提供如下，以協助您開始使用。

案例：多個 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 儲存 (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) 具有條紋計數。如果您有大型檔案，建議您將此參數調校為較高的值。

    • 配置：將 FSx for Lustre 檔案系統部署在與運算或 GPU 節點相同的可用區域中，以啟用資料的最低延遲存取，避免跨可用區域存取模式。如果您的多個 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 驅動程式範例。

案例：單一 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 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 驅動程式範例。

監控效能 磁碟效能不佳可能會延遲容器映像讀取、增加 Pod 啟動延遲，以及降低推論或訓練輸送量。如果發生瓶頸，我們建議您使用下列方法來監控個別 AWS Storage 服務的效能指標，並視需要調整您的組態。