Armazenamento - Amazon EKS
Gerenciamento e armazenamento de dados

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Armazenamento

Gerenciamento e armazenamento de dados

Implante modelos de IA em pods usando um driver CSI

As cargas de trabalho de IA/ML geralmente exigem acesso a grandes artefatos de modelos (por exemplo, pesos e configurações treinados), e os pods precisam de uma forma confiável e escalável de acessá-los sem incorporá-los às imagens do contêiner, o que pode aumentar o tamanho das imagens e os tempos de extração do Container Registry. Para reduzir a sobrecarga operacional do gerenciamento de montagens de volume, recomendamos implantar modelos de IA em pods montando os serviços de armazenamento da Amazon (por exemplo, S3, for FSx Lustre, EFS) como volumes persistentes (PVs) usando seus respectivos drivers CSI. Para obter detalhes sobre a implementação, consulte os tópicos subsequentes nesta seção.

Otimize o armazenamento para caches de modelos de ML no EKS

Aproveitar uma solução de armazenamento ideal é fundamental para minimizar a latência de inicialização do pod e do aplicativo, reduzir o uso de memória, obter os níveis desejados de desempenho para acelerar as cargas de trabalho e garantir a escalabilidade das cargas de trabalho de ML. As cargas de trabalho de ML geralmente dependem de arquivos de modelo (pesos), que podem ser grandes e exigir acesso compartilhado aos dados entre pods ou nós. A seleção da solução de armazenamento ideal depende das características da sua carga de trabalho, como eficiência de um único nó, acesso a vários nós, requisitos de latência, restrições de custo e também requisitos de integração de dados (como com um repositório de dados do Amazon S3). Recomendamos comparar diferentes soluções de armazenamento com suas cargas de trabalho para entender qual delas atende às suas necessidades, e fornecemos as seguintes opções para ajudá-lo a avaliar com base em suas necessidades de carga de trabalho.

O driver EKS CSI oferece suporte aos seguintes serviços de armazenamento da AWS, cada um com seu próprio driver CSI e vem com seus próprios pontos fortes para fluxos de trabalho de IA e ML:

A escolha do serviço de armazenamento da AWS depende da sua arquitetura de implantação, escala, requisitos de desempenho e estratégia de custo. Os drivers CSI de armazenamento precisam ser instalados em seu cluster EKS, o que permite que o driver CSI crie e gerencie volumes persistentes (PV) fora do ciclo de vida de um pod. Usando o driver CSI, você pode criar definições fotovoltaicas de serviços de armazenamento da AWS compatíveis como recursos de cluster do EKS. Os pods podem então acessar esses volumes de armazenamento para seus volumes de dados por meio da criação de uma reivindicação de volume persistente (PVC) para o PV. Dependendo do serviço de armazenamento da AWS e do seu cenário de implantação, um único PVC (e seu PV associado) pode ser conectado a vários pods para uma carga de trabalho. Por exemplo, para treinamento de ML, dados de treinamento compartilhados são armazenados em um PV e acessados por vários pods; para inferência on-line em tempo real, os modelos LLM são armazenados em cache em um PV e acessados por vários pods. Exemplos de arquivos YAML PV e PVC para os serviços de armazenamento da AWS são fornecidos abaixo para ajudar você a começar.

Cenário: carga de trabalho de várias instâncias de GPU

Amazon FSx for Lustre: em cenários em que você tem um ambiente de várias instâncias de computação de EC2 GPU com cargas de trabalho dinâmicas sensíveis à latência e com alta taxa de transferência de largura de banda, como treinamento distribuído e fornecimento de modelos, e precisa de integração nativa com o repositório de dados Amazon S3, recomendamos o Amazon for Lustre. FSx FSx for Lustre fornece um sistema de arquivos paralelo de alto desempenho totalmente gerenciado, projetado para cargas de trabalho com uso intensivo de computação, como computação de alto desempenho (HPC) e Machine Learning.

Você pode instalar o driver CSI for Lustre FSx para montar FSx sistemas de arquivos no EKS como um volume persistente (PV) e, em seguida, implantar o sistema de arquivos Lustre como um cache autônomo de alto desempenho ou como um sistema de arquivos vinculado ao S3 FSx para atuar como um cache de alto desempenho para dados do S3, fornecendo alta I/O e rápida taxa de transferência para acesso aos dados em suas instâncias de computação da GPU. FSx for Lustre pode ser implantado com opções de armazenamento Scratch-SSD ou SSD persistente:

  • Armazenamento SSD Scratch: recomendado para cargas de trabalho efêmeras ou de curta duração (horas), com capacidade de taxa de transferência fixa por TiB provisionada.

  • Armazenamento SSD persistente: recomendado para cargas de trabalho de missão crítica e de longa duração que exigem o mais alto nível de disponibilidade, por exemplo, simulações de HPC, análise de big data ou treinamento em Machine Learning. Com o armazenamento SSD persistente, você pode configurar a capacidade de armazenamento e a capacidade de taxa de transferência (por TiB) necessárias.

Considerações de desempenho:

  • Pod administrativo FSx para gerenciar o sistema de arquivos Lustre: configure um pod “administrativo” que tenha o cliente Lustre instalado e tenha o sistema de FSx arquivos montado. Isso habilitará um ponto de acesso para permitir o ajuste fino do sistema de FSx arquivos e também em situações em que você precise pré-aquecer o sistema de FSx arquivos com seus dados de treinamento de ML ou modelos LLM antes de iniciar suas instâncias de computação de GPU. Isso é especialmente importante se sua arquitetura utiliza instâncias de GPU/computação da EC2 Amazon baseadas em Spot, nas quais você pode utilizar o pod administrativo para “aquecer” ou “pré-carregar” os dados desejados no FSx sistema de arquivos, para que os dados estejam prontos para serem processados quando você executar suas instâncias da Amazon baseadas em Spot. EC2

  • Elastic Fabric Adapter (EFA): os tipos de implantação de armazenamento SSD persistente oferecem suporte ao Elastic Fabric Adapter (EFA), onde o uso do EFA é ideal para cargas de trabalho baseadas em GPU de alto desempenho e taxa de transferência. Observe que FSx o Lustre oferece suporte ao NVIDIA GPUDirect Storage (GDS), em que o GDS é uma tecnologia que cria um caminho de dados direto entre o armazenamento local ou remoto e a memória da GPU, para permitir um acesso mais rápido aos dados.

  • Compressão: ative a compactação de dados no sistema de arquivos se você tiver tipos de arquivo que possam ser compactados. Isso pode ajudar a aumentar o desempenho, pois a compactação de dados reduz a quantidade de dados transferidos entre os servidores FSx de arquivos e o armazenamento Lustre.

  • Configuração de distribuição do sistema de arquivos Lustre:

    • Distribuição de dados: permite que FSx o Luster distribua os dados de um arquivo em vários destinos de armazenamento de objetos (OSTs) em um sistema de arquivos Lustre, maximizando o acesso e a taxa de transferência paralelos, especialmente para trabalhos de treinamento de ML em grande escala.

    • Distribuição autônoma do sistema de arquivos: por padrão, uma configuração de distribuição do Lustre de 4 componentes é criada para você por meio do recurso de layouts de arquivo progressivos (PFL) do Lustre. FSx Na maioria dos cenários, você não precisa atualizar a contagem/tamanho padrão de faixas do PFL Lustre. Se você precisar ajustar a distribuição de dados do Lustre, poderá ajustar manualmente a distribuição do Lustre consultando os parâmetros de distribuição de um FSx sistema de arquivos do Lustre.

    • Sistema de arquivos vinculado ao S3: os arquivos importados para o FSx sistema de arquivos usando a integração nativa do Amazon S3 (Data Repository Association ou DRA) não usam o layout PFL padrão, mas usam o layout no parâmetro do sistema de arquivos. ImportedFileChunkSize Arquivos importados do S3 maiores que o ImportedFileChunkSize serão armazenados em vários OSTs com uma contagem de faixas com base no valor ImportedFileChunkSize definido (padrão 1GiB). Se você tiver arquivos grandes, recomendamos ajustar esse parâmetro para um valor maior.

    • Posicionamento: implante um sistema de arquivos FSx for Lustre na mesma zona de disponibilidade dos nós de computação ou GPU para permitir o acesso de menor latência aos dados, evitando padrões de acesso entre zonas de disponibilidade. Se você tiver vários nós de GPU localizados em diferentes zonas de disponibilidade, recomendamos implantar um sistema de FSx arquivos em cada zona de disponibilidade para acesso a dados de baixa latência.

Exemplo

Definição de volume persistente (PV) FSx para um sistema de arquivos for Lustre, usando provisionamento estático (onde a FSx instância já foi provisionada).

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]

Exemplo

Definição de reivindicação de volume persistente para PV chamadafsx-pv:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fsx-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1200Gi
  volumeName: fsx-pv

Exemplo

Configure um pod para usar uma declaração de volume persistente defsx-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

Para obter exemplos completos, consulte os exemplos FSx de drivers do Lustre em GitHub.

Cenário: carga de trabalho de instância de GPU única

Mountpoint para Amazon S3 com driver CSI: você pode montar um bucket S3 como um volume em seus pods usando o driver Mountpoint for Amazon S3 CSI. Esse método permite um controle de acesso refinado sobre quais pods podem acessar buckets específicos do S3. Cada pod tem sua própria instância de ponto de montagem e cache local (5 a 10 GB), isolando o carregamento do modelo e o desempenho de leitura entre os pods. Essa configuração oferece suporte à autenticação em nível de pod com funções do IAM para contas de serviço (IRSA) e controle de versão independente de modelos para diferentes modelos ou clientes. A desvantagem é o aumento do uso de memória e do tráfego da API, pois cada pod emite chamadas de API do S3 e mantém seu próprio cache.

Exemplo parcial de um YAML de implantação de pod com driver 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

Considerações de desempenho:

  • Cache de dados: o Mountpoint for S3 pode armazenar conteúdo em cache para reduzir custos e melhorar o desempenho de leituras repetidas no mesmo arquivo. Consulte Configuração de cache para ver as opções e os parâmetros de armazenamento em cache.

  • Tamanho parcial do objeto: ao armazenar e acessar arquivos com mais de 72 GB, consulte Configurando o desempenho do Mountpoint para entender como configurar os parâmetros e a --write-part-size linha de comando para atender aos requisitos de perfil de dados --read-part-size e carga de trabalho.

  • O cache compartilhado foi projetado para objetos de até 1 MB de tamanho. Ele não suporta objetos grandes. Use a opção Cache local para armazenar objetos em cache NVMe ou volumes do EBS no nó EKS.

  • Cobranças de solicitação de API: ao realizar um grande número de operações de arquivo com o Mountpoint for S3, as cobranças de solicitação de API podem se tornar uma parte dos custos de armazenamento. Para mitigar isso, se uma consistência forte não for necessária, sempre ative o cache de metadados e defina o metadata-ttl período para reduzir o número de operações de API para o S3.

Para obter mais detalhes, consulte o driver Mountpoint for Amazon S3 CSI na documentação oficial do Amazon EKS. Recomendamos monitorar as métricas de desempenho do Amazon S3 com as CloudWatch métricas da Amazon se ocorrerem gargalos e ajustar sua configuração quando necessário.

Amazon EFS para caches de modelos compartilhados

Em cenários em que você tem um ambiente de várias instâncias de computação de EC2 GPU e tem cargas de trabalho dinâmicas que exigem acesso compartilhado ao modelo em vários nós e zonas de disponibilidade (por exemplo, inferência on-line em tempo real com o Karpenter) com necessidades moderadas de desempenho e escalabilidade, recomendamos usar um sistema de arquivos Amazon Elastic File System (EFS) como um volume persistente por meio do driver EFS CSI. O Amazon EFS é um sistema de arquivos NFS baseado em nuvem totalmente gerenciado, altamente disponível e escalável que habilita EC2 instâncias e contêineres com armazenamento compartilhado de arquivos, com desempenho consistente e onde não é necessário provisionamento antecipado de armazenamento. Use o EFS como o volume do modelo e monte o volume como um sistema de arquivos compartilhado por meio da definição de um volume persistente no cluster EKS. Cada reivindicação de volume persistente (PVC) apoiada por um sistema de arquivos EFS é criada como um ponto de acesso EFS ao sistema de arquivos EFS. O EFS permite que vários nós e pods acessem os mesmos arquivos de modelo, eliminando a necessidade de sincronizar dados com o sistema de arquivos de cada nó. Instale o driver EFS CSI para integrar o EFS com o EKS.

Você pode implantar um sistema de arquivos Amazon EFS com os seguintes modos de taxa de transferência:

  • Taxa de transferência intermitente: dimensiona a taxa de transferência de acordo com o tamanho do sistema de arquivos, adequada para cargas de trabalho variadas com picos ocasionais.

  • Taxa de transferência provisionada: taxa de transferência dedicada, ideal para trabalhos consistentes de treinamento de ML com necessidades de desempenho previsíveis dentro de limites.

  • Taxa de transferência elástica (recomendada para ML): escala automaticamente com base na carga de trabalho e na relação custo-benefício para cargas de trabalho de ML variáveis.

Para ver as especificações de desempenho, consulte as especificações de desempenho do Amazon EFS.

Considerações de desempenho:

  • Use o Elastic Throughput para cargas de trabalho variadas.

  • Use a classe de armazenamento padrão para cargas de trabalho de ML ativas.

Para obter exemplos completos do uso do sistema de arquivos Amazon EFS como um volume persistente em seu cluster e pods do EKS, consulte os exemplos de drivers CSI do EFS em. GitHub

Desempenho de monitoramento O baixo desempenho do disco pode atrasar a leitura da imagem do contêiner, aumentar a latência de inicialização do pod e diminuir a taxa de transferência de inferência ou treinamento. Recomendamos os seguintes métodos para monitorar as métricas de desempenho do respectivo serviço de armazenamento da AWS se ocorrerem gargalos e ajustar sua configuração quando necessário.