Otimizar o desempenho

Esta página fornece detalhes sobre como otimizar o desempenho do Google Cloud NetApp Volumes.

Antes de começar

Antes de fazer mudanças nos volumes para otimizar a performance, consulte as considerações sobre a performance.

Ajustar as configurações de volume

Para otimizar o desempenho, ajuste as seguintes configurações de volume:

• Aumente a capacidade de volume: é possível aumentar a capacidade do nível de serviço Premium, Extreme ou Standard para melhorar a taxa de transferência de volume máxima. Para volumes do nível de serviço Flex, aumente a capacidade dos pools de armazenamento.

• Atualize o nível de serviço: é possível atualizar os volumes do nível de serviço Premium para o nível Extreme para melhorar a taxa de transferência. Recomendamos que você atribua o volume a um pool de armazenamento diferente com um nível de serviço diferente.

O aumento da capacidade do volume e a atualização dos níveis de serviço não interrompem as cargas de trabalho de E/S em processo no volume e não afetam o acesso ao volume de nenhuma forma.

Ajustar o cliente

Para melhorar a performance, ajuste as seguintes configurações no cliente:

• Colocalização de clientes: os resultados de latência são diretamente afetados pelos recursos e pela localização do cliente. Para melhores resultados, coloque o cliente na mesma região do volume ou o mais próximo possível. Teste o impacto da zona testando a latência de um cliente em cada zona e use a zona com a menor latência.

• Configurar o largura de banda da rede do Compute Engine: os recursos de rede das máquinas virtuais do Compute Engine dependem do tipo de instância usado. Normalmente, instâncias maiores podem gerar mais capacidade de rede. Recomendamos que você selecione uma máquina virtual cliente com um recurso de largura de banda de rede adequado, selecione a interface de rede NIC virtual do Google (gVNIC) e ative o desempenho Tier_1. Para mais informações, consulte a documentação do Compute Engine sobre largura de banda de rede.

• Abrir várias sessões TCP: se o aplicativo exigir alta taxa de transferência, você poderá saturar o único protocolo de controle de transmissão (TCP, na sigla em inglês) que é a base de uma sessão NFS e SMB normal. Para esses casos, aumente o número de sessões TCP usadas pela conexão NFS e SMB.

  Use uma das guias a seguir para ajustar o cliente com base no tipo de cliente:

  Linux

  Tradicionalmente, um cliente NFS usa uma única sessão TCP para todos os sistemas de arquivos montados em NFS que compartilham um endpoint de armazenamento. Usar a opção de montagem nconnect permite aumentar o número de sessões TCP com suporte até um máximo de 16.

  Recomendamos as práticas recomendadas abaixo para ajustar o tipo de cliente Linux e aproveitar ao máximo o nconnect:

  • Aumente o número de sessões TCP com nconnect: cada sessão TCP adicional adiciona uma fila para 128 solicitações pendentes, melhorando a possível simultaneidade.

  • Definir o parâmetro sunrpc.max_tcp_slot_table_entries: sunrpc.max_tcp_slot_table_entries é um parâmetro de ajuste no nível da conexão que pode ser modificado para controlar o desempenho. Recomendamos definir sunrpc.max_tpc_slot_table_enteries como 128 solicitações ou por conexão e não ultrapassar 10.000 slots para todos os clientes NFS em um único projeto que se conecta aos volumes NetApp. Para definir o parâmetro sunrpc.max_tcp_slot_table_entries, adicione-o ao arquivo /etc/sysctl.conf e recarregue o arquivo de parâmetro usando o comando sysctl -p.

  • Ajustar o valor máximo com suporte por sessão para 180: ao contrário do NFSv3, os clientes NFSv4.1 definem a relação entre o cliente e o servidor em sessões. Embora os volumes do NetApp ofereçam suporte a até 128 solicitações pendentes por conexão usando o NFSv3, o NFSv4.1 é limitado a 180 solicitações pendentes por sessão. Os clientes Linux NFSv4.1 usam o padrão 64 max_session_slots por sessão, mas você pode ajustar esse valor conforme necessário. Recomendamos mudar o valor máximo aceito por sessão para 180.

    Para ajustar max_session_slots, crie um arquivo de configuração em /etc/modprobe.d. Verifique se não há aspas (" ") inline. Caso contrário, a opção não vai entrar em vigor.

    $ echo "options nfs max_session_slots=180" > /etc/modprobe/d/nfsclient/conf
    $ reboot
    
    Use the systool -v -m nfs command to see the current maximum in use
    by the client. For the command to work, at least one NFSv4.1 mount
    must be in place.
    
    $ systool -v -v nfs
    {
    Module = "nfs"
    …
    Parameters:
    …
    Max_session_slots = "63" <-
    …
    }
    

  O gráfico de comparação nconnect do NFS a seguir demonstra o impacto do uso da configuração nconnect em uma carga de trabalho do NFS. Essas informações foram capturadas usando o Fio com as seguintes configurações:

  • Carga de trabalho de leitura de 100%

  • Tamanho de bloco de 8 KiB em um único volume

  • Máquina virtual n2-standard-32 usando o sistema operacional Red Hat 9

  • Conjunto de trabalho de 6 TiB

  O uso de um valor de nconnect de 16 resultou em cinco vezes mais desempenho do que quando ele não estava ativado.

  

  Windows

  Para clientes baseados no Windows, o cliente pode usar o SMB Multichannel com escalamento do lado do receptor (RSS, na sigla em inglês) para abrir várias conexões TCP. Para fazer isso, a máquina virtual precisa ter um adaptador de rede alocado com suporte a RSS. Recomendamos definir o RSS como quatro ou oito valores. No entanto, qualquer valor acima de um aumenta a taxa de transferência.

  O gráfico a seguir mostra a diferença que o uso da configuração RSS pode ter em uma carga de trabalho SMB. Essas informações foram capturadas usando o Fio com as seguintes configurações:

  • Carga de trabalho de leitura de 100%

  • Tamanho de bloco de 8 KiB em um único volume

  • Máquina virtual n2-standard-32 única executando um SO Windows 2022

  • Conjunto de trabalho de 6 TiB

  Oito trabalhos foram executados com apenas a opção RSS do cliente SMB mudando entre execuções de teste. O uso de valores de RSS de 4, 8 e 16 aumentou a performance em duas vezes em comparação com o uso de um valor de 1. Cada instância do RSS foi executada nove vezes com um parâmetro numjobs de 8. O parâmetro iodepth foi aumentado em cinco a cada execução até que a capacidade máxima fosse alcançada.

  

A seguir

Leia sobre os pools de armazenamento.