Maximizar o throughput do Gateway de Arquivos do S3 - AWS Storage Gateway
Implantar seu gateway no mesmo local que seus clientesReduzir os gargalos causados por discos lentosAjustar a alocação de recursos da máquina virtual para CPU, RAM e discos de cacheAjustar o nível de segurança do SMBUsar vários threads e clientes para paralelizar as operações de gravaçãoDesativar a atualização automática do cacheAumentar o número de threads do uploader do Amazon S3Aumentar as configurações de tempo limite do SMBAtivar o bloqueio oportunista para aplicações compatíveisAjustar a capacidade do gateway de acordo com o tamanho do conjunto de arquivos em usoImplementar vários gateways para workloads maiores

O Amazon FSx File Gateway não está mais disponível para novos clientes. Os clientes existentes do FSx File Gateway podem continuar usando o serviço normalmente. Para recursos semelhantes ao FSx File Gateway, visite esta postagem do blog.

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á.

Maximizar o throughput do Gateway de Arquivos do S3

As seções a seguir descrevem as práticas recomendadas para maximizar o throughput entre seus clientes NFS e SMB, o Gateway de Arquivos do S3 e o Amazon S3. A orientação fornecida em cada seção contribui de modo incremental para melhorar o throughput geral. Embora nenhuma dessas recomendações seja necessária e não sejam interdependentes, elas foram selecionadas e ordenadas de uma forma lógica que o Suporte utiliza para testar e ajustar as implementações do Gateway de Arquivos do S3. Ao implementar e testar essas sugestões, lembre-se de que cada implantação do Gateway de Arquivos do S3 é exclusiva, portanto, seus resultados podem variar.

O Gateway de Arquivos do S3 oferece uma interface de arquivo para armazenar e recuperar objetos do Amazon S3 utilizando protocolos de arquivo NFS ou SMB padrão do setor, com um mapeamento 1:1 nativo entre arquivo e objeto. É possível implantar o Gateway de Arquivos do S3 como uma máquina virtual on-premises no seu ambiente VMware, Microsoft Hyper-V ou Linux KVM, ou na Nuvem AWS como uma instância do Amazon EC2. O Gateway de Arquivos do S3 não foi projetado para atuar como um substituto completo do NAS empresarial. O Gateway de Arquivos do S3 emula um sistema de arquivos, mas não se trata de um. Usar o Amazon S3 como armazenamento de backend durável cria uma sobrecarga adicional em cada operação de E/S, portanto, avaliar o desempenho do Gateway de Arquivos do S3 em relação a um NAS ou servidor de arquivos existente não é uma comparação equivalente.

Implantar seu gateway no mesmo local que seus clientes

Recomendamos implantar seu dispositivo virtual do Gateway de Arquivos do S3 em um local físico com a menor latência de rede possível entre ele e seus clientes NFS ou SMB. Ao escolher um local para o gateway, pense no seguinte:

  • A menor latência de rede para o gateway pode ajudar a melhorar o desempenho de clientes NFS ou SMB.

  • O Gateway de Arquivos do S3 foi projetado para tolerar maior latência de rede entre o gateway e o Amazon S3 do que entre o gateway e os clientes.

  • Para instâncias do Gateway de Arquivos do S3 implantadas no Amazon EC2, recomendamos manter o gateway e os clientes NFS ou SMB no mesmo grupo de posicionamento. Para obter mais informações, consulte Grupos de posicionamento para as instâncias do Amazon EC2 no Guia do usuário do Amazon Elastic Compute Cloud.

Reduzir os gargalos causados por discos lentos

Recomendamos monitorar a métrica IoWaitPercent do CloudWatch para identificar gargalos de desempenho que podem ser causados pela lentidão dos discos de armazenamento em seu Gateway de Arquivos do S3. Ao tentar otimizar os problemas de desempenho relacionados ao disco, pense no seguinte:

  • IoWaitPercent informa a porcentagem de tempo que a CPU está aguardando uma resposta do disco de cache ou local.

  • Quando IoWaitPercent é maior que 5–10%, isso geralmente indica um gargalo no gateway causado por discos com desempenho insuficiente. Essa métrica deve ser o mais próxima possível de 0%, o que significa que o gateway nunca está esperando no disco, o que ajuda a otimizar os recursos da CPU.

  • Você pode conferir IoWaitPercent na guia Monitoramento do console do Storage Gateway ou configurar os alarmes recomendados do CloudWatch para notificar automaticamente se a métrica ultrapassar um limite específico. Para obter mais informações, consulte Criar alarmes recomendados do CloudWatch para o gateway.

  • Recomendamos usar NVMe ou SSD para os discos raiz e de cache do seu gateway a fim de minimizar IoWaitPercent.

Ajustar a alocação de recursos da máquina virtual para CPU, RAM e discos de cache

Ao tentar otimizar o throughput do Gateway de Arquivos do S3, é importante alocar recursos suficientes para a VM do gateway, incluindo CPU, RAM e discos de cache. Os requisitos mínimos de 4 CPUs, 16 GB de RAM e 150 GB de armazenamento em cache para recursos virtuais geralmente são adequados apenas para workloads menores. Ao alocar recursos virtuais para workloads maiores, recomendamos o seguinte:

  • Aumente o número alocado de CPUs para algo em torno de 16 e 48, dependendo do uso típico da CPU gerado pelo seu Gateway de Arquivos do S3. Você pode monitorar o uso da CPU usando a métrica UserCpuPercent. Para obter mais informações, consulte Noções básicas sobre as métricas de gateway.

  • Aumente a RAM alocada para algo entre 32 e 64 GB.

    nota

    O Gateway de Arquivos do S3 não pode utilizar mais de 64 GB de RAM.

  • Use NVMe ou SSD para discos raiz e disco de cache, e dimensione seus discos de cache para se alinharem ao pico do conjunto de dados em uso que você planeja gravar no gateway. Para obter mais informações, consulte S3 File Gateway cache sizing best practices no canal oficial da Amazon Web Services no YouTube.

  • Adicione pelo menos quatro discos de cache virtual ao gateway, em vez de usar um único disco grande. Vários discos virtuais podem melhorar o desempenho mesmo que compartilhem o mesmo disco físico subjacente, mas as melhorias geralmente são maiores quando os discos virtuais estão localizados em discos físicos subjacentes diferentes.

    Por exemplo, se quiser implantar 12 TB de cache, poderá utilizar uma das seguintes configurações:

    • 4x disco de cache de 3 TB

    • 8x disco de cache de 1,5 TB

    • 12x disco de cache de 1 TB

    Além do desempenho, isso permite um gerenciamento mais eficiente da máquina virtual ao longo do tempo. Conforme sua workload muda, você pode aumentar de modo incremental o número de discos de cache e sua capacidade geral de cache, mantendo o tamanho original de cada disco virtual individual para preservar a integridade do gateway.

    Para obter mais informações, consulte Determinar o volume de armazenamento do disco local.

Ao implantar o Gateway de Arquivos do S3 como uma instância do Amazon EC2, pense no seguinte:

  • O tipo de instância que você escolher pode afetar significativamente o desempenho do gateway. O Amazon EC2 oferece ampla flexibilidade para ajustar a alocação de recursos para sua instância do Gateway de Arquivos do S3.

  • Para conferir os tipos de instância do Amazon EC2 recomendados para o Gateway de Arquivos do S3, consulte Requisitos para tipos de instância do Amazon EC2.

  • Você pode alterar o tipo de instância do Amazon EC2 que hospeda um Gateway de Arquivos do S3 ativo. Isso permite que você ajuste facilmente a geração de hardware e a alocação de recursos do Amazon EC2 para encontrar o custo-benefício ideal. Para alterar o tipo de instância, use o seguinte procedimento no console do Amazon EC2:

    1. Interrompa a instância do Amazon EC2.

    2. Altere o tipo de instância do Amazon EC2.

    3. Ative a instância do Amazon EC2.

    nota

    A interrupção de uma instância que hospeda um Gateway de Arquivos do S3 interromperá temporariamente o acesso ao compartilhamento de arquivos. Agende uma janela de manutenção, se necessário.

  • O custo-benefício de uma instância do Amazon EC2 se refere à quantidade de poder computacional que você recebe pelo preço pago. Normalmente, as instâncias do Amazon EC2 de nova geração oferecem o melhor custo-benefício, com hardware mais novo e desempenho aprimorado por um custo relativamente menor em comparação às gerações anteriores. Alguns fatores, como tipo de instância, região e padrões de uso, afetam essa proporção, por isso é importante selecionar a instância certa para sua workload específica a fim de otimizar o custo-benefício.

Ajustar o nível de segurança do SMB

O protocolo SMBv3 permite tanto a assinatura do SMB quanto a criptografia do SMB, que apresentam algumas vantagens e desvantagens em termos de desempenho e segurança. Para otimizar o throughput, você pode ajustar o nível de segurança do SMB do gateway a fim de especificar quais desses recursos de segurança são aplicados às conexões do cliente. Para obter mais informações, consulte Definir um nível de segurança para seu gateway.

Ao ajustar o nível de segurança do SMB, pense no seguinte:

  • O nível de segurança padrão para o Gateway de Arquivos do S3 é Aplicar criptografia. Essa configuração aplica criptografia e assinatura para conexões de clientes SMB com compartilhamentos de arquivos do gateway, o que significa que todo o tráfego do cliente para o gateway é criptografado. Essa configuração não afeta o tráfego do gateway para a AWS, que é sempre criptografado.

    O gateway limita cada conexão de cliente criptografada a uma única vCPU. Por exemplo, se você tiver apenas um cliente criptografado, esse cliente estará limitado a apenas uma vCPU, mesmo que quatro ou mais vCPUs estejam alocadas para o gateway. Por esse motivo, o throughput de conexões criptografadas de um único cliente para o Gateway de Arquivos do S3 normalmente fica entre 40 e 60 MB/s.

  • Se seus requisitos de segurança permitirem um procedimento mais relaxado, você poderá alterar o nível de segurança para Cliente negociado, o que desabilitará a criptografia do SMB e aplicará somente a assinatura do SMB. Com essa configuração, as conexões de clientes com o gateway podem utilizar várias vCPUs, o que normalmente ocasiona melhor desempenho de throughput.

    nota

    Depois de alterar o nível de segurança do SMB do seu Gateway de Arquivos do S3, você deve esperar que o status do compartilhamento de arquivos mude de Atualizando para Disponível no console do Storage Gateway, depois desconectar e reconectar seus clientes SMB para que a nova configuração entre em vigor.

Usar vários threads e clientes para paralelizar as operações de gravação

É difícil ter o máximo desempenho de throughput com um Gateway de Arquivos do S3 que usa somente um cliente NFS ou SMB para gravar um arquivo por vez, porque a gravação sequencial de um único cliente é uma operação de thread único. Em vez disso, recomendamos usar vários threads de cada cliente NFS ou SMB para gravar vários arquivos em paralelo e usar vários clientes NFS ou SMB simultaneamente no seu Gateway de Arquivos do S3 a fim de maximizar o throughput do gateway.

O uso de vários threads pode melhorar significativamente o desempenho. No entanto, o uso de mais threads requer mais recursos do sistema, o que pode afetar negativamente o desempenho se o gateway não for dimensionado para atender ao aumento da carga. Em uma implantação típica, você pode esperar ter um desempenho de throughput melhor à medida que adiciona mais threads e clientes, até atingir as limitações máximas de hardware e largura de banda para o gateway. Recomendamos experimentar diferentes quantidades de threads para encontrar o equilíbrio ideal entre velocidade e uso de recursos do sistema para sua configuração específica de hardware e rede.

Confira as seguintes informações sobre ferramentas comuns que podem ajudar você a testar a configuração de threads e clientes:

  • Você pode testar o desempenho de gravação em vários threads utilizando ferramentas, como robocopy, para copiar um conjunto de arquivos em um compartilhamento de arquivos no seu gateway. Por padrão, robocopy usa 8 threads ao copiar arquivos, mas você pode especificar até 128.

    Para usar vários threads com robocopy, adicione a opção /MT:n ao seu comando, em que n é o número de threads que você deseja usar. Por exemplo:

    robocopy C:\source D:\destination /MT:64

    Esse comando usará 64 threads para a operação de cópia.

    nota

    Não recomendamos usar o Windows Explorer para arrastar e soltar arquivos ao testar o throughput máximo, pois esse método é limitado a um único thread e copia os arquivos sequencialmente.

    Para obter mais informações, consulte robocopy no site do Microsoft Learn.

  • Você também pode realizar testes usando ferramentas comuns de benchmarking de armazenamento, como DISKSPD ou FIO. Essas ferramentas têm opções para ajustar o número de threads, a profundidade de E/S e outros parâmetros de acordo com os requisitos da sua workload específica.

    DiskSpd permite controlar o número de threads utilizando o parâmetro -t. Por exemplo:

    diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

    Este exemplo de comando faz o seguinte:

    • Cria um arquivo de teste de 10 GB (-c1G).

    • Funciona por 300 segundos (-d300).

    • Executa um teste de E/S aleatório com 50% de leituras e 50% de gravações (-r -w50).

    • Usa 64 threads (-t64).

    • Define a profundidade da fila para 32 por thread (-o32).

    • Usa um tamanho de bloco de 1 MB (-b1M).

    • Desativa o armazenamento em cache de hardware e software (-h -L).

    Para obter mais informações, consulte Use DISKSPD to test workload storage performance no site do Microsoft Learn.

  • FIO usa o parâmetro numjobs para controlar o número de threads paralelos. Por exemplo:

    fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

    Este exemplo de comando faz o seguinte:

    • Executa um teste de E/S aleatório (--rw=randrw).

    • Executa 70% de leituras e 30% de gravações (--rwmixread=70).

    • Usa um tamanho de bloco de 1 MB (--bs=1M).

    • Define a profundidade de E/S como 64 (--iodepth=64).

    • Testa em um arquivo de 10 GB (--size=10G).

    • É executado por 5 minutos (--runtime=300).

    • Cria 64 trabalhos paralelos (threads) (--numjobs=64).

    • Usa um mecanismo de E/S assíncrono (--ioengine=libaio).

    • Agrupa os resultados para facilitar a análise (--group_reporting).

    Para obter mais informações, consulte fio na página do manual do Linux.

Desativar a atualização automática do cache

O recurso de atualização automática de cache permite que o Gateway de Arquivos do S3 atualize seus metadados automaticamente, o que pode ajudar a capturar quaisquer alterações que usuários ou aplicações façam em seu conjunto de arquivos ao gravar diretamente no bucket do Amazon S3, em vez de por meio do gateway. Para obter mais informações, consulte Atualizar o cache de objetos do bucket do Amazon S3.

Para otimizar o throughput do gateway, recomendamos desativar esse recurso nas implantações em que todas as leituras e gravações no bucket do Amazon S3 serão realizadas por meio do Gateway de Arquivos do S3.

Ao configurar a atualização automatizada de cache, pense no seguinte:

  • Se você precisar usar a atualização automática de cache porque os usuários ou as aplicações em sua implantação gravam diretamente no Amazon S3 de vez em quando, recomendamos configurar o maior intervalo de tempo possível entre as atualizações que ainda seja prático para suas necessidades comerciais. Um intervalo maior de atualização do cache ajuda a reduzir o número de operações de metadados que o gateway precisa realizar ao navegar em diretórios ou modificar arquivos.

    Por exemplo: defina a atualização automática do cache como 24 horas, em vez de 5 minutos, se isso for tolerável para sua workload.

  • O intervalo de tempo mínimo é 5 minutos. O intervalo máximo é de 30 dias.

  • Se você optar por definir um intervalo de atualização de cache muito curto, recomendamos testar a experiência de navegação em diretórios para seus clientes NFS e SMB. O tempo necessário para atualizar o cache do gateway pode aumentar substancialmente, dependendo do número de arquivos e subdiretórios em seu bucket do Amazon S3.

Aumentar o número de threads do uploader do Amazon S3

Por padrão, o Gateway de Arquivos do S3 abre 8 threads para upload de dados do Amazon S3, o que oferece capacidade de upload suficiente para a maioria das implantações típicas. No entanto, é possível que um gateway receba dados de clientes NFS e SMB a uma taxa maior do que a que pode ser carregada para o Amazon S3 com a capacidade padrão de 8 threads, o que pode fazer com que o cache local atinja seu limite de armazenamento.

Em circunstâncias específicas, o Suporte pode aumentar a contagem do pool de threads de upload do Amazon S3 para seu gateway de 8 para 40, o que permite que mais dados sejam carregados em paralelo. Dependendo da largura de banda e de outros fatores específicos de sua implantação, isso pode aumentar significativamente o desempenho de upload e ajudar a reduzir a quantidade de armazenamento em cache necessária para comportar sua workload.

Recomendamos usar a métrica CachePercentDirty do CloudWatch para monitorar a quantidade de dados armazenados nos discos de cache do gateway local que ainda não foram enviados ao Amazon S3 e entrar em contato com o Suporte para ajudar a determinar se o aumento da contagem do pool de threads de upload pode melhorar o throughput do seu Gateway de Arquivos do S3. Para obter mais informações, consulte Noções básicas sobre as métricas de gateway.

nota

Essa configuração consome recursos adicionais da CPU do gateway. Recomendamos monitorar o uso da CPU do gateway e, se necessário, aumentar os recursos alocados da CPU.

Aumentar as configurações de tempo limite do SMB

Quando o Gateway de Arquivos do S3 copia arquivos grandes para um compartilhamento de arquivos SMB, a conexão do cliente SMB pode expirar após um longo período.

Recomendamos estender para 20 minutos ou mais a configuração de tempo limite da sessão SMB para seus clientes SMB, dependendo do tamanho dos arquivos e da velocidade de gravação do seu gateway. O padrão é 300 segundos ou 5 minutos. Para obter mais informações, consulte O trabalho de backup do gateway falha ou há erros ao gravar no gateway.

Ativar o bloqueio oportunista para aplicações compatíveis

O bloqueio oportunista, ou “oplocks”, é habilitado por padrão para cada novo Gateway de Arquivos do S3. Ao usar oplocks com aplicações compatíveis, o cliente agrupa várias operações menores em outras maiores, o que é mais eficiente para o cliente, o gateway e a rede. Recomendamos manter o bloqueio oportunista ativado se você usar aplicações que aproveitam o cache local do lado do cliente, como o Microsoft Office, o Adobe Suite e muitos outros, pois isso pode melhorar significativamente o desempenho.

Se você desativar o bloqueio oportunista, as aplicações compatíveis com oplocks normalmente demorarão muito mais para abrir arquivos grandes (50 MB ou mais). Esse atraso ocorre porque o gateway envia dados em partes de 4 KB, o que gera alta E/S e baixo throughput.

Ajustar a capacidade do gateway de acordo com o tamanho do conjunto de arquivos em uso

O parâmetro de capacidade do gateway especifica o número máximo de arquivos para os quais seu gateway armazenará metadados em seu cache local. Por padrão, a capacidade do gateway é definida como Pequeno, o que significa que o gateway armazena metadados de até 5 milhões de arquivos. A configuração padrão funciona bem para a maioria das workloads, mesmo que haja centenas de milhões ou até bilhões de objetos no Amazon S3, porque somente um pequeno subconjunto de arquivos é acessado ativamente em determinado momento em uma implantação típica. Esse grupo de arquivos é chamado de “conjunto em uso”.

Se sua workload acessa regularmente um conjunto em uso com mais de 5 milhões de arquivos, seu gateway precisará realizar remoções frequentes de cache, que são pequenas operações de E/S armazenadas na RAM e persistentes no disco raiz. Isso pode afetar negativamente o desempenho do gateway, pois ele busca novos dados do Amazon S3.

Você pode monitorar a métrica IndexEvictions para determinar o número de arquivos cujos metadados foram removidos do cache a fim de abrir espaço para novas entradas. Para obter mais informações, consulte Noções básicas sobre as métricas de gateway.

Recomendamos usar a ação de API UpdateGatewayInformation a fim de aumentar a capacidade do gateway para corresponder ao número de arquivos em seu conjunto em uso típico. Para obter mais informações, consulte UpdateGatewayInformation.

nota

Aumentar a capacidade do gateway requer capacidade adicional de RAM e disco raiz.

  • “Pequeno” (5 milhões de arquivos) requer pelo menos 16 GB de RAM e 80 GB de disco raiz.

  • “Médio” (10 milhões de arquivos) requer pelo menos 32 GB de RAM e 160 GB de disco raiz.

  • “Grande” (20 milhões de arquivos) requer 64 GB de RAM e 240 GB de disco raiz.

Importante

A capacidade do gateway não pode ser reduzida.

Implementar vários gateways para workloads maiores

Recomendamos dividir sua workload entre vários gateways quando possível, em vez de consolidar muitos compartilhamentos de arquivos em um único gateway grande. Por exemplo, você pode isolar um compartilhamento de arquivos muito usado em um gateway e agrupar os compartilhamentos utilizados com menor frequência em outro gateway.

Ao planejar uma implantação com vários gateways e compartilhamentos de arquivos, pense no seguinte:

  • O número máximo de compartilhamentos de arquivos em um único gateway é 50, mas o número de compartilhamentos de arquivos gerenciados por um gateway pode afetar o desempenho do gateway. Para obter mais informações, consulte Orientação de desempenho para gateways com vários compartilhamentos de arquivos.

  • Os recursos em cada Gateway de Arquivos do S3 são compartilhados entre todos os compartilhamentos de arquivos, sem particionamento.

  • Um único compartilhamento de arquivos com uso intenso pode afetar o desempenho de outros compartilhamentos no gateway.

nota

Não recomendamos a criação de vários compartilhamentos de arquivos que são mapeados para o mesmo local do Amazon S3 de vários gateways, a menos que pelo menos um deles seja somente leitura.

Gravações simultâneas de vários gateways no mesmo arquivo são consideradas um cenário de vários gravadores, o que pode causar problemas de integridade de dados.