Otimize o desempenho

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

Antes de começar

Antes de fazer alterações aos seus volumes para otimizar o desempenho, reveja as considerações de desempenho.

Ajuste as definições de volume

Pode otimizar o desempenho ajustando as seguintes definições de volume:

• Aumente a capacidade do volume: pode aumentar a capacidade do volume do nível de serviço Premium, Extreme ou Standard para melhorar o débito máximo alcançável do volume. Para volumes do nível de serviço Flex, aumente a capacidade dos conjuntos de armazenamento.

• Atualize o seu nível de serviço: pode atualizar os volumes do seu nível de serviço Premium para o nível de serviço Extreme para melhorar o débito. Recomendamos que atribua o volume a um conjunto de armazenamento diferente com um nível de serviço diferente.

O aumento da capacidade de volume e a atualização dos níveis de serviço não são disruptivos para as cargas de trabalho de E/S em processamento no volume e não afetam o acesso ao volume de forma alguma.

Ajuste o cliente

Pode melhorar o desempenho ajustando as seguintes definições no cliente:

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

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

• Abrir várias sessões TCP: se a sua aplicação exigir um débito elevado, pode eventualmente saturar a sessão do protocolo de controlo de transmissão (TCP) única que está na base de uma sessão normal de NFS e SMB. Para estes casos, aumente o número de sessões TCP que a sua ligação NFS e SMB usa.

  Use um dos seguintes separadores para ajustar o seu cliente com base no tipo de cliente:

  Linux

  Tradicionalmente, um cliente NFS usa uma única sessão TCP para todos os sistemas de ficheiros montados em NFS que partilham um ponto final de armazenamento. A utilização da opção de montagem nconnect permite aumentar o número de sessões TCP suportadas até um máximo de 16.

  Recomendamos as seguintes práticas recomendadas para ajustar o tipo de cliente Linux de modo a tirar total partido do nconnect:

  • Aumente o número de sessões TCP com nconnect: cada sessão TCP adicional adiciona uma fila para 128 pedidos pendentes, o que melhora a simultaneidade potencial.

  • Defina o parâmetro sunrpc.max_tcp_slot_table_entries: sunrpc.max_tcp_slot_table_entries é um parâmetro de ajuste ao nível da ligação que pode modificar para controlar o desempenho. Recomendamos que defina sunrpc.max_tpc_slot_table_enteries para 128 pedidos ou por ligação e não exceda 10 000 espaços para todos os clientes NFS num único projeto que se ligam a volumes NetApp. Para definir o parâmetro sunrpc.max_tcp_slot_table_entries, adicione-o ao ficheiro /etc/sysctl.conf e recarregue o ficheiro de parâmetros através do comando sysctl -p.

  • Ajuste o valor máximo suportado 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 NetApp suportem até 128 pedidos pendentes por ligação através do NFSv3, o NFSv4.1 está limitado a 180 pedidos pendentes por sessão. Os clientes Linux NFSv4.1 têm como predefinição 64 max_session_slots por sessão, mas pode ajustar este valor conforme necessário. Recomendamos que altere o valor máximo suportado por sessão para 180.

    Para otimizar max_session_slots, crie um ficheiro de configuração em /etc/modprobe.d. Certifique-se de que não aparecem aspas (" ") no texto. Caso contrário, a opção não é aplicada.

    $ 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 de NFS nconnect seguinte demonstra o impacto que a configuração nconnect pode ter numa carga de trabalho de NFS. Estas informações foram capturadas através do Fio com as seguintes definições:

  • 100% da carga de trabalho de leitura

  • Tamanho do bloco de 8 KiB em relação a um único volume

  • n2-standard-32 máquina virtual com o SO Red Hat 9

  • Conjunto de trabalho de 6 TiB

  A utilização de um valor de nconnect de 16 resultou num desempenho cinco vezes superior ao quando não estava ativado.

  

  Windows

  Para clientes baseados no Windows, o cliente pode usar o SMB Multichannel com o Receive Side Scaling (RSS) para abrir várias ligações TCP. Para alcançar esta configuração, a sua máquina virtual tem de ter um adaptador de rede atribuído que suporte RSS. Recomendamos que defina o RSS para quatro ou oito valores. No entanto, qualquer valor superior a um deve aumentar a taxa de transferência.

  O gráfico seguinte apresenta a diferença que a configuração RSS pode ter numa carga de trabalho SMB. Estas informações foram capturadas através do Fio com as seguintes definições:

  • 100% da carga de trabalho de leitura

  • Tamanho do bloco de 8 KiB em relação a um único volume

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

  • Conjunto de trabalho de 6 TiB

  Foram executados oito trabalhos com apenas a opção RSS do cliente SMB a mudar entre as execuções de teste. A utilização de valores RSS de 4, 8 e 16 aumentou o desempenho duas vezes em comparação com a utilização de um valor de 1. Cada instância de RSS foi executada nove vezes com um parâmetro numjobs de 8. O parâmetro iodepth foi aumentado em cinco em cada execução até atingir o débito máximo.

  

O que se segue?

Leia sobre os conjuntos de armazenamento.