Maximizando a taxa de transferência do S3 File Gateway

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

O S3 File Gateway fornece uma interface de arquivo para armazenar e recuperar objetos do Amazon S3 usando protocolos de arquivo NFS ou SMB padrão do setor, com um mapeamento 1:1 nativo entre arquivo e objeto. Você implanta o S3 File Gateway como uma máquina virtual localmente em seu ambiente VMware Microsoft Hyper-V ou Linux KVM, ou na nuvem AWS como uma instância da Amazon. EC2 O S3 File Gateway não foi projetado para atuar como um substituto completo do NAS corporativo. O S3 File Gateway emula um sistema de arquivos, mas não é um sistema de arquivos. Usar o Amazon S3 como armazenamento de back-end durável cria uma sobrecarga adicional em cada I/O operação, portanto, avaliar o desempenho do S3 File Gateway em relação a um NAS ou servidor de arquivos existente não é uma comparação equivalente.

Implante seu gateway no mesmo local que seus clientes

Recomendamos implantar seu dispositivo virtual S3 File Gateway 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 seu gateway, considere o seguinte:

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

• O S3 File Gateway 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 S3 File Gateway implantadas na 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 suas EC2 instâncias da Amazon no Guia do usuário do Amazon Elastic Compute Cloud.

Reduza os gargalos causados por discos lentos

Recomendamos monitorar a IoWaitPercent CloudWatch métrica para identificar gargalos de desempenho que podem resultar da lentidão dos discos de armazenamento no S3 File Gateway. Ao tentar otimizar os problemas de desempenho relacionados ao disco, considere o seguinte:

• IoWaitPercentinforma a porcentagem de tempo em que a CPU está aguardando uma resposta dos discos raiz ou de cache.

• Quando IoWaitPercent é maior que 5 a 10%, isso geralmente indica um gargalo no desempenho do gateway causado por discos com baixo desempenho. Essa métrica deve ser a 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 verificar IoWaitPercent a guia Monitoramento do console do Storage Gateway ou configurar CloudWatch os alarmes recomendados para notificá-lo automaticamente se a métrica ultrapassar um limite específico. Para obter mais informações, consulte Criação de CloudWatch alarmes recomendados para seu gateway.

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

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

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

• Aumente o número alocado CPUs para entre 16 e 48, dependendo do uso típico da CPU gerado pelo seu S3 File Gateway. Você pode monitorar o uso da CPU usando a UserCpuPercent métrica. Para obter mais informações, consulte Entendendo as métricas do gateway.

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

  nota

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

• Use NVMe nosso SSD para discos raiz e disco de cache e dimensione seus discos de cache para se alinharem ao conjunto máximo de dados de trabalho que você planeja gravar no gateway. Para obter mais informações, consulte as melhores práticas de dimensionamento de cache do S3 File Gateway no canal oficial da Amazon Web Services YouTube .

• Adicione pelo menos 4 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 você quiser implantar 12 TB de cache, você pode usar uma das seguintes configurações:

  • 4 discos de cache de 3 TB

  • 8 discos de cache de 1,5 TB

  • 12 discos 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 carga de trabalho muda, você pode aumentar incrementalmente 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 Decidindo a quantidade de armazenamento em disco local.

Ao implantar o S3 File Gateway como uma EC2 instância da Amazon, considere o seguinte:

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

• Para os tipos de EC2 instância da Amazon recomendados para o S3 File Gateway, consulte Requisitos para tipos de EC2 instância da Amazon.

• Você pode alterar o tipo de EC2 instância da Amazon que hospeda um S3 File Gateway ativo. Isso permite que você ajuste facilmente a geração de EC2 hardware e a alocação de recursos da Amazon para encontrar uma price-to-performance proporção ideal. Para alterar o tipo de instância, use o seguinte procedimento no EC2 console da Amazon:

  1. Pare a EC2 instância da Amazon.

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

  3. Ligue a EC2 instância da Amazon.

  nota

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

• A price-to-performance proporção de uma EC2 instância da Amazon se refere à quantidade de poder computacional que você obtém pelo preço pago. Normalmente, as EC2 instâncias Amazon de nova geração oferecem a melhor price-to-performance proporção, com hardware mais novo e desempenho aprimorado a um custo relativamente menor em comparação com as gerações anteriores. 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 carga de trabalho específica para otimizar a relação custo-benefício.

Ajuste o nível de segurança do SMB

O SMBv3 protocolo permite tanto a assinatura SMB quanto a criptografia SMB, que têm algumas desvantagens em desempenho e segurança. Para otimizar a taxa de transferência, você pode ajustar o nível de segurança SMB do gateway para 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, considere o seguinte:

• O nível de segurança padrão para o S3 File Gateway é Enforce encryption. Essa configuração impõe 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 AWS, que é sempre criptografado.

  O gateway limita cada conexão de cliente criptografada a uma única vCPU. Por exemplo, se você tiver apenas 1 cliente criptografado, esse cliente estará limitado a apenas 1 vCPU, mesmo que 4 ou mais v CPUs estejam alocados ao gateway. Por esse motivo, a taxa de transferência de conexões criptografadas de um único cliente para o S3 File Gateway normalmente fica entre 40 e 60 MB/s.

• Se seus requisitos de segurança permitirem uma postura mais relaxada, você poderá alterar o nível de segurança para Negociado pelo cliente, o que desativará a criptografia SMB e aplicará somente a assinatura SMB. Com essa configuração, as conexões do cliente com o gateway podem utilizar vários vCPUs, o que normalmente resulta em maior desempenho de taxa de transferência.

  nota

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

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

É difícil obter o máximo desempenho de taxa de transferência com um gateway de arquivos 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 segmentos de cada cliente NFS ou SMB para gravar vários arquivos em paralelo e usar vários clientes NFS ou SMB simultaneamente no seu S3 File Gateway para maximizar a taxa de transferência do gateway.

O uso de vários encadeamentos 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 obter um melhor desempenho de taxa de transferência à medida que adiciona mais threads e clientes, até atingir as limitações máximas de hardware e largura de banda para seu gateway. Recomendamos experimentar diferentes contagens 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.

Considere as seguintes informações sobre ferramentas comuns que podem ajudá-lo a testar a configuração do thread e do cliente:

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

  Para usar vários encadeamentos com robocopy, adicione a /MT:n opção ao seu comando, onde n está o número de encadeamentos 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 a taxa de transferência máxima, 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 seus requisitos específicos de carga de trabalho.

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

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

  Esse exemplo de comando faz o seguinte:

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

  • Funciona por 300 segundos (-d300)

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

  • Usa 64 tópicos (-t64)

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

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

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

  Para obter mais informações, consulte Usar o DISKSPD para testar o desempenho do armazenamento da carga de trabalho no site do Microsoft Learn.

• O FIO usa o numjobs parâmetro 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

  Esse exemplo de comando faz o seguinte:

  • Executa um I/O teste aleatório (--rw=randrw)

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

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

  • Define a I/O profundidade para 64 (--iodepth=64)

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

  • Funciona por 5 minutos (--runtime=300)

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

  • Usa mecanismo assíncrono I/O () --ioengine=libaio

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

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

Desativar a atualização automática do cache

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

Para otimizar a taxa de transferência do gateway, recomendamos desativar esse recurso em implantações em que todas as leituras e gravações no bucket do Amazon S3 serão realizadas por meio do S3 File Gateway.

Ao configurar a atualização automática do cache, considere o seguinte:

• Se você precisar usar a atualização automática de cache porque os usuários ou aplicativos em sua implantação ocasionalmente gravam diretamente no Amazon S3, recomendamos configurar o maior intervalo de tempo possível entre as atualizações, o 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 para 24 horas, em vez de 5 minutos, se isso for tolerável para sua carga de trabalho.

• O intervalo mínimo de tempo é de 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.

Aumente o número de threads de upload do Amazon S3

Por padrão, o S3 File Gateway abre 8 threads para o upload de dados do Amazon S3, o que fornece 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, 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 paralelamente. Dependendo da largura de banda e de outros fatores específicos de sua implantação, isso pode aumentar significativamente o desempenho do upload e ajudar a reduzir a quantidade de armazenamento em cache necessária para suportar sua carga de trabalho.

Recomendamos usar a CachePercentDirty CloudWatch métrica para monitorar a quantidade de dados armazenados nos discos de cache do gateway local que ainda não foram enviados para o Amazon S3 e Suporte entrar em contato para ajudar a determinar se o aumento da contagem do pool de threads de upload pode melhorar a taxa de transferência do seu S3 File Gateway. Para obter mais informações, consulte Entendendo as métricas do gateway.

nota

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

Aumentar as configurações de tempo limite de SMB

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

Recomendamos estender a configuração de tempo limite da sessão SMB para seus clientes SMB para 20 minutos ou mais, 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 Sua tarefa de backup do gateway falha ou há erros ao gravar no gateway.

Ative o bloqueio oportunista para aplicativos compatíveis

O bloqueio oportunista, ou “oplocks”, é ativado por padrão para cada novo S3 File Gateway. Ao usar oplocks com aplicativos 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 aplicativos 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, os aplicativos que suportam oplocks normalmente abrirão arquivos grandes (50 MB ou mais) muito mais lentamente. Esse atraso ocorre porque o gateway envia dados em partes de 4 KB, o que resulta em alta I/O e baixa taxa de transferência.

Ajuste a capacidade do gateway de acordo com o tamanho do conjunto de arquivos de trabalho

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 Pequena, 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 cargas de trabalho, 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 um determinado momento em uma implantação típica. Esse grupo de arquivos é chamado de “conjunto de trabalho”.

Se sua carga de trabalho acessa regularmente um conjunto de arquivos de trabalho com mais de 5 milhões, 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 impactar negativamente o desempenho do gateway, pois o gateway busca novos dados do Amazon S3.

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

Recomendamos usar a ação da UpdateGatewayInformation API para aumentar a capacidade do gateway para corresponder ao número de arquivos em seu conjunto de trabalho 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.

Implemente vários gateways para cargas de trabalho maiores

Recomendamos dividir sua carga de trabalho em 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 de arquivos usados com menos frequência em outro gateway.

Ao planejar uma implantação com vários gateways e compartilhamentos de arquivos, considere o 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 S3 File Gateway são compartilhados em todos os compartilhamentos de arquivos, sem particionamento.

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

nota

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

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