Otimizar o Gateway de Arquivos do S3 para backups de banco de dados SQL Server - AWS Storage Gateway
Implantar um gateway no mesmo local que os servidores SQLReduzir os gargalos causados por discos lentosAjustar a alocação de recursos da máquina virtual do Gateway de Arquivos do S3 para CPU, RAM e discos de cacheMelhorar o throughput de clientes SMB ajustando o nível de segurança do Gateway de Arquivos do S3Melhorar o throughput de clientes SMB dividindo os backups do SQL em vários arquivosAumentar as configurações de tempo limite do SMB para evitar falhas de cópia de arquivos grandesAumentar o número de threads do uploader do Amazon S3Desativar a atualização automática do cacheImplantar vários gateways para comportar o workloadRecursos adicionais para workloads de backup de banco de dados

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

Otimizar o Gateway de Arquivos do S3 para backups de banco de dados SQL Server

Os backups de banco de dados são um caso de uso comum e recomendado para o Gateway de Arquivos do S3, que fornece retenção econômica de curto e longo prazo ao armazenar backups de banco de dados no Amazon S3, com a capacidade de ciclo de vida para níveis de armazenamento de menor custo, conforme necessário. Com essa solução, você pode reduzir a necessidade de aplicações de backup empresarial utilizando ferramentas integradas, como o SQL Server Management Studio e o Oracle RMAN.

As seções a seguir descrevem as práticas recomendadas para ajustar sua implantação do Gateway de Arquivos do S3 a fim de obter desempenho otimizado e suporte econômico para centenas de terabytes de backups de banco de dados SQL. 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 um gateway no mesmo local que os servidores SQL

Recomendamos implantar o 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 os servidores SQL. Ao escolher um local para o gateway, pense no seguinte:

  • Uma latência de rede menor para o gateway pode ajudar a melhorar o desempenho de clientes SMB, como servidores SQL.

  • 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 servidores SQL 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 do Gateway de Arquivos do S3 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.

Melhorar o throughput de clientes SMB ajustando o nível de segurança do Gateway de Arquivos do S3

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.

Melhorar o throughput de clientes SMB dividindo os backups do SQL em vários arquivos

  • É difícil ter o desempenho máximo de throughput com um Gateway de Arquivos do S3 que usa somente um servidor SQL para gravar um arquivo por vez, porque a gravação sequencial de um único servidor SQL é uma operação de thread único. Em vez disso, recomendamos usar vários threads de cada servidor SQL para gravar vários arquivos em paralelo e usar vários servidores SQL simultaneamente no Gateway de Arquivos do S3 a fim de maximizar o throughput do gateway. Com os backups do SQL, dividir os backups em vários arquivos permite que cada arquivo utilize um thread separado, que gravará vários arquivos simultaneamente no compartilhamento de arquivos do Gateway de Arquivos do S3. Quanto mais threads você tiver, maior será o throughput que poderá alcançar, até os limites do gateway.

  • O servidor SQL é compatível com a gravação em vários arquivos ao mesmo tempo durante uma única operação de backup. Por exemplo, é possível especificar vários destinos de arquivos usando comandos T-SQL ou o SQL Server Management Studio (SSMS). Cada arquivo usa um thread separado para enviar dados do servidor SQL ao compartilhamento de arquivos do gateway. Essa abordagem permite um melhor throughput de E/S, o que pode melhorar significativamente a velocidade e a eficiência do backup.

Ao configurar os backups do servidor SQL, pense no seguinte:

  • Ao dividir os backups em vários arquivos, os administradores do servidor SQL podem otimizar os tempos de backup e gerenciar backups de grandes bancos de dados com maior eficiência.

  • O número de arquivos usados depende da configuração de armazenamento e dos requisitos de desempenho do servidor. Para bancos de dados grandes, recomendamos dividir os backups em vários arquivos menores entre 10 GB e 20 GB cada.

  • Não há limite estrito para quantos arquivos o servidor SQL pode gravar durante um backup, mas considerações práticas, como arquitetura de armazenamento e largura de banda da rede, devem orientar essa escolha.

Para obter mais informações, consulte:

Aumentar as configurações de tempo limite do SMB para evitar falhas de cópia de arquivos grandes

Quando o Gateway de Arquivos do S3 copia arquivos grandes de backup do SQL 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 do servidor SQL, 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.

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 servidores SQL a uma taxa maior do que consegue fazer upload 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.

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 servidores SQL. 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.

Implantar vários gateways para comportar o workload

É possível que o Storage Gateway seja compatível com backups do SQL para grandes ambientes com centenas de bancos de dados SQL, vários servidores SQL e centenas de terabytes de dados de backup dividindo a workload em vários gateways.

Ao planejar uma implantação com vários gateways e servidores SQL, pense no seguinte:

  • Normalmente, um único gateway pode fazer upload de até 20 TB por dia, com recursos de hardware e largura de banda suficientes. Você pode aumentar esse limite para até 40 TB por dia aumentando o número de threads de upload do Amazon S3.

  • Recomendamos realizar um teste-piloto para medir o desempenho e pensar em todas as variáveis em sua implantação. Depois de determinar o throughput máximo da sua workload de backup do SQL, você pode escalar o número de gateways para atender aos seus requisitos.

  • Recomendamos projetar sua solução pensando no crescimento, pois o número e o tamanho dos bancos de dados podem aumentar com o tempo. Para continuar a escalar e comportar uma workload crescente, você pode implantar gateways adicionais conforme necessário.

Recursos adicionais para workloads de backup de banco de dados