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 serviços de armazenamento da Amazon (por exemplo, S3, FSx para Lustre, para FSx OpenZFS, EFS) como volumes persistentes () usando seus respectivos drivers CSI. PVs 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:

• Ponto de montagem para Amazon S3

• Amazon FSx para Lustre

• Amazon FSx para OpenZFS

• Amazon EFS

• Amazon EBS

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 o treinamento de ML, os 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.

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. Use CloudWatch a Amazon para monitorar as métricas de desempenho dos seus serviços de armazenamento da AWS. Ao identificar gargalos de desempenho, modifique seus parâmetros de configuração de armazenamento para otimizar o desempenho.

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 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. Monitore as métricas FSx de desempenho do Amazon for Lustre usando a Amazon CloudWatch. Quando forem identificados gargalos de desempenho, ajuste seus parâmetros de configuração conforme necessário.

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 FSx for OpenZFS: armazenamento compartilhado persistente

Para cenários envolvendo várias instâncias de computação de EC2 GPU com cargas de trabalho sensíveis à latência que exigem alta disponibilidade, alto desempenho, economia e várias implantações de pods para diferentes aplicativos, recomendamos a Amazon para OpenZFS. FSx Alguns exemplos de carga de trabalho incluem inferência em tempo real, aprendizado por reforço e treinamento de redes adversárias generativas. FSx para OpenZFS é particularmente benéfico para cargas de trabalho que precisam de acesso de alto desempenho a uma estrutura de diretórios focada com arquivos pequenos usando pequenos padrões de acesso a dados de E/S. Além disso, FSx o OpenZFS oferece a flexibilidade de escalar o desempenho independentemente da capacidade de armazenamento, ajudando você a obter a melhor eficiência de custos ao adequar o tamanho do armazenamento às necessidades reais e, ao mesmo tempo, manter os níveis de desempenho exigidos.

O driver CSI nativo FSx do OpenZFS permite a criação de vários PVCs sistemas de arquivos em um único, criando vários volumes. Isso reduz a sobrecarga de gerenciamento e maximiza a utilização da taxa de transferência e do IOPS do sistema de arquivos por meio de implantações consolidadas de pods de aplicativos em um único sistema de arquivos. Além disso, inclui recursos corporativos, como instantâneos com cópia zero, clones com cópia zero e cotas de usuários e grupos, que podem ser provisionadas dinamicamente por meio do driver CSI.

FSx para OpenZFS suporta três tipos diferentes de implantação após a criação:

• Single-AZ: opção de menor custo com latências inferiores a um milissegundo, mas não oferece alta disponibilidade no nível do sistema de arquivos ou da zona de disponibilidade. Recomendado para cargas de trabalho de desenvolvimento e teste ou aquelas que têm alta disponibilidade na camada de aplicação.

• Single-AZ (HA): fornece alta disponibilidade no nível do sistema de arquivos com latências inferiores a um milissegundo. Recomendado para cargas de trabalho de alto desempenho que exigem alta disponibilidade.

• Multi-AZ: fornece alta disponibilidade no nível do sistema de arquivos, bem como em todas as zonas de disponibilidade. Recomendado para cargas de trabalho de alto desempenho que exigem disponibilidade adicional em todas as zonas de disponibilidade.

Considerações de desempenho:

• Tipo de implantação: se a disponibilidade adicional nas zonas de disponibilidade não for um requisito, considere usar o tipo de implantação Single-AZ (HA). Esse tipo de implantação fornece até 100% da taxa de transferência para gravações, mantém latências inferiores a um milissegundo e os sistemas de arquivos Gen2 têm um NVMe cache adicional para armazenar até terrabytes de dados acessados com frequência. Os sistemas de arquivos Multi-AZ fornecem até 75% da taxa de transferência para gravações com uma latência maior para acomodar o tráfego entre AZ.

• Taxa de transferência e IOPS: tanto a taxa de transferência quanto a IOPS configuradas para o sistema de arquivos podem ser aumentadas ou reduzidas após a implantação. Você pode provisionar até 10% GB/s of disk throughput providing up to 21GB/s do acesso aos dados em cache. O IOPS pode ser escalado até 400.000 a partir do disco e o cache pode fornecer mais de 1 milhão de IOPS. Observe que o escalonamento da taxa de transferência de um sistema de arquivos Single-AZ causa uma breve interrupção do sistema de arquivos, pois não existe alta disponibilidade. O escalonamento da taxa de transferência de um sistema de arquivos Single-AZ (HA) ou Multi-AZ pode ser feito sem interrupções. O SSD IOPS pode ser escalado uma vez a cada seis horas.

• Classe de armazenamento: FSx para OpenZFS suporta tanto a classe de armazenamento SSD quanto a classe de armazenamento Intelligent-Tiering. Para AI/ML cargas de trabalho, é recomendável usar a classe de armazenamento SSD que fornece desempenho consistente à carga de trabalho, mantendo as CPUs/GPUs o mais ocupadas possível.

• Compressão: ative o algoritmo de LZ4 compactação se você tiver uma carga de trabalho que possa ser compactada. Isso reduz a quantidade de dados que cada arquivo consome no cache, permitindo que mais dados sejam fornecidos diretamente do cache como taxa de transferência de rede e IOPS, reduzindo a carga no disco SSD.

• Tamanho do registro: a maioria das AI/ML cargas de trabalho se beneficiará ao deixar o tamanho de registro padrão de 128 KiB. Esse valor só deve ser reduzido se o conjunto de dados consistir em arquivos grandes (acima de 10 GiB) com acesso consistente em pequenos blocos abaixo de 128 KiB do aplicativo.

Depois que o sistema de arquivos é criado, um volume raiz associado é criado automaticamente pelo serviço. É uma prática recomendada armazenar dados em volumes secundários do volume raiz no sistema de arquivos. Usando o driver CSI FSx para OpenZFS, você cria uma Declaração de Volume Persistente associada para criar dinamicamente o volume secundário.

Exemplos:

Uma definição de Classe de Armazenamento (SC) para um volume FSx para OpenZFS, usada para criar um volume secundário do volume raiz ($ROOT_VOL_ID) em um sistema de arquivos existente e exportar o volume para o VPC CIDR ($VPC_CIDR) usando o protocolo NFS v4.2.

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

Uma reivindicação de volume persistente (PVC) criada dinamicamente em relação à fsxz-vol-sc criada acima. Observe que a capacidade de armazenamento alocada é de 1Gi, isso é necessário FSx para volumes OpenZFS, conforme observado nas perguntas frequentes do driver CSI. O volume receberá a capacidade total provisionada ao sistema de arquivos com essa configuração. Se a capacidade do volume precisar ser restringida, você poderá fazer isso usando cotas de usuários ou grupos.

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

Configure um pod para montar um volume usando a Declaração de Volume Persistente (PVC) de 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 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 contínua: 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 Monitore as métricas de desempenho do Amazon EFS usando a Amazon CloudWatch. Quando forem identificados gargalos de desempenho, ajuste seus parâmetros de configuração conforme necessário.

Use o S3 Express One Zone para fluxos de trabalho orientados a objetos e sensíveis à latência

Para AI/ML cargas de trabalho sensíveis à latência no Amazon EKS, como treinamento de modelos em grande escala, inferência ou análise de alto desempenho, recomendamos usar o S3 Express One Zone para armazenamento e recuperação de modelos de alto desempenho. O S3 Express One Zone oferece um namespace hierárquico, como um sistema de arquivos, no qual você simplesmente faz o upload para um bucket de diretórios, adequado para “colocar tudo dentro” e, ao mesmo tempo, manter a alta velocidade. Isso é particularmente útil se você estiver acostumado com fluxos de trabalho orientados a objetos. Como alternativa, se você estiver mais acostumado com sistemas de arquivos (por exemplo, compatíveis com POSIX), você pode preferir o Amazon FSx for Lustre ou o OpenZFS. O Amazon S3 Express One Zone armazena dados em uma única zona de disponibilidade (AZ) usando buckets de diretório e oferecendo menor latência do que os buckets S3 padrão, que distribuem dados entre vários. AZs Para obter melhores resultados, certifique-se de colocar sua computação EKS na mesma AZ do bucket Express One Zone. Para saber mais sobre as diferenças do S3 Express One Zone, consulte Diferenças para buckets de diretório.

Para acessar o S3 Express One Zone com a semântica do sistema de arquivos, recomendamos usar o driver Mountpoint S3 CSI, que monta buckets S3 (incluindo Express One Zone) como um sistema de arquivos local. Isso traduz operações de arquivo (por exemplo, abertura, leitura, gravação) em chamadas de API do S3, fornecendo acesso de alto rendimento otimizado para cargas de trabalho com muita leitura de vários clientes e gravações sequenciais em novos objetos. Para obter detalhes sobre as operações e limitações suportadas (por exemplo, sem conformidade total com POSIX, mas anexos e renomeações compatíveis com o Express One Zone), consulte a documentação semântica do Mountpoint.

Benefícios de desempenho

• Fornece acesso aos dados até 10 vezes mais rápido do que o S3 Standard, com latência consistente de um dígito em milissegundos e custos de solicitação até 80% menores.

• É escalável para lidar com centenas de milhares a milhões de solicitações por segundo por bucket de diretório, evitando limitações ou interrupções observadas no S3 padrão durante cargas extremas (por exemplo, de clusters com dezenas a centenas de milhares de redes saturadas). GPUs/CPUs

• Usa um mecanismo de autenticação baseado em sessão. Autentique-se uma vez para obter um token de sessão e, em seguida, execute operações repetidas em alta velocidade sem sobrecarga de autenticação por solicitação. Isso é otimizado para cargas de trabalho, como pontos de verificação frequentes ou carregamento de dados.

Casos de uso recomendados

• Cache: Um dos principais casos de uso do driver Mountpoint S3 CSI com o S3 Express One Zone é o armazenamento em cache. A primeira instância lê dados do S3 Standard (uso geral), armazenando-os em cache na Express One Zone de baixa latência. As leituras subsequentes de outros clientes acessam os dados em cache mais rapidamente, o que é ideal para cenários de vários nós em que vários nós EKS leem os mesmos dados (por exemplo, conjuntos de dados de treinamento compartilhados). Isso pode melhorar o desempenho em até 7 vezes para acessos repetidos e reduzir os custos de computação. Para cargas de trabalho que exigem total conformidade com POSIX (por exemplo, bloqueio de arquivos e modificações no local), considere o Amazon FSx for Lustre ou o OpenZFS como alternativas.

• AI/ML Treinamento e inferência em grande escala: ideais para cargas de trabalho com centenas ou milhares de nós de computação (por exemplo, GPUs em clusters EKS) em que a limitação de uso geral do S3 pode causar atrasos, desperdiçando recursos computacionais caros. Por exemplo, pesquisadores de LLM ou organizações que executam o modelo diário tests/checkpoints se beneficiam de um acesso rápido e confiável sem quebrar o S3 regional. Para cargas de trabalho de menor escala (por exemplo, dezenas de nós), o S3 Standard ou outras classes de armazenamento podem ser suficientes.

• Pipelines de dados: Load/prepare modelos, arquive dados de treinamento ou pontos de verificação de fluxo. Se sua equipe prefere o armazenamento de objetos em vez dos sistemas de arquivos tradicionais (por exemplo, devido à familiaridade com o S3), use isso em vez de fazer alterações de engenharia para opções compatíveis com POSIX, como o Lustre. FSx

Considerações

• Resiliência: o design Single-AZ fornece 99,999999999% de durabilidade (a mesma do S3 padrão, por meio de redundância dentro do AZ), mas menor disponibilidade (99,95% projetado, 99,9% de SLA) em comparação com as classes Multi-AZ (disponibilidade de 99,99%). É menos resistente às falhas do AZ. Use para dados recriáveis ou armazenados em cache. Considere a replicação ou os backups Multi-AZ para cargas de trabalho críticas.

• Suporte de API e recursos: suporta um subconjunto do S3 APIs (por exemplo, sem políticas de ciclo de vida ou replicação); pode exigir pequenas alterações no aplicativo para autenticação de sessão ou manipulação de objetos.

• Integração com o EKS: coloque seu EKS pods/nodes na mesma AZ do bucket de diretórios para minimizar a latência da rede. Use o Mountpoint para Amazon S3 ou drivers CSI para acesso nativo do Kubernetes.

• Teste: teste a latência de recuperação em um ambiente de não produção para validar os ganhos de desempenho. Monitore a aceleração em cenários S3 padrão (por exemplo, alta saturação de GPU) e compare.

A classe de armazenamento S3 Express One Zone está disponível em várias regiões e se integra ao EKS para cargas de trabalho que precisam de acesso a objetos sem esperar pelo armazenamento. Para saber mais, consulte Introdução ao S3 Express One Zone.