Otimizando o S3 File Gateway para backups de bancos de dados do SQL Server

Os backups de banco de dados são um caso de uso comum e recomendado para o S3 File Gateway, 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 aplicativos de backup corporativo usando ferramentas integradas, como o SQL Server Management Studio e o Oracle RMAN.

As seções a seguir descrevem as melhores práticas para ajustar sua implantação do S3 File Gateway para desempenho otimizado e suporte econômico para centenas de terabytes de backups de bancos de dados SQL. 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 SQL Servers

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 servidores SQL. 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 SMB, como servidores SQL.

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

Melhore a taxa de transferência do cliente SMB ajustando o nível de segurança do seu S3 File Gateway

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.

Melhore a taxa de transferência do cliente SMB dividindo os backups SQL em vários arquivos

• É difícil obter o desempenho máximo de taxa de transferência com um gateway de arquivos S3, em que apenas um servidor SQL grava 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 S3 File Gateway para maximizar a taxa de transferência do gateway. Com os backups do SQL, dividir os backups em vários arquivos permite que cada arquivo utilize um encadeamento separado, que gravará vários arquivos simultaneamente no compartilhamento de arquivos do S3 File Gateway. Quanto mais threads você tiver, maior será a taxa de transferência que poderá alcançar, até os limites do gateway.

• O SQL Server oferece suporte à gravação em vários arquivos ao mesmo tempo durante uma única operação de backup. Por exemplo, você pode especificar vários destinos de arquivo usando comandos T-SQL ou SQL Server Management Studio (SSMS). Cada arquivo usa um encadeamento separado para enviar dados do servidor SQL para o compartilhamento de arquivos do gateway. Essa abordagem permite uma melhor I/O taxa de transferência, o que pode melhorar significativamente a velocidade e a eficiência do backup.

Ao configurar seus backups do SQL Server, considere o seguinte:

• Ao dividir os backups em vários arquivos, os administradores do SQL Server podem otimizar os tempos de backup e gerenciar backups de grandes bancos de dados com mais 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 SQL Server pode gravar durante um backup, mas considerações práticas, como arquitetura de armazenamento e largura de banda de rede, devem orientar essa escolha.

Para obter mais informações, consulte:

• Faça backup do SQL Server 43-67% mais rápido gravando em vários arquivos

• Armazene facilmente seus backups do SQL Server no Amazon S3 usando o Gateway de Arquivos

Evite falhas de cópia de arquivos grandes aumentando as configurações de tempo limite de SMB

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

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 servidores SQL a uma taxa maior do que a capacidade de 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, 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.

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

Implemente vários gateways para suportar a carga de trabalho

É possível que o Storage Gateway ofereça suporte a backups SQL para grandes ambientes com centenas de bancos de dados SQL, vários SQL Servers e centenas de terabytes de dados de backup dividindo a carga de trabalho em vários gateways.

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

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

• Recomendamos realizar um proof-of-concept teste para medir o desempenho e considerar todas as variáveis em sua implantação. Depois de determinar a taxa de transferência máxima da sua carga de trabalho de backup do SQL, você pode escalar o número de gateways para atender às suas necessidades.

• 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 suportar uma carga de trabalho crescente, você pode implantar gateways adicionais conforme necessário.

Recursos adicionais para cargas de trabalho de backup de banco de dados

• Armazene backups do SQL Server no Amazon S3 usando AWS Storage Gateway

• Armazene facilmente seus backups do SQL Server no Amazon S3 usando o Gateway de Arquivos

• Usando AWS Storage Gateway para armazenar backups de bancos de dados Oracle no Amazon S3

• Fazendo backup de bancos de dados Oracle no Amazon S3 em grande escala

• Integre um banco de dados SAP ASE ao Amazon S3 usando AWS Storage Gateway

• Como um AWS herói usa AWS Storage Gateway para backup na nuvem

• Melhores práticas de dimensionamento de cache do S3 File Gateway