Esta página oferece orientações sobre como configurar o ambiente do Google Cloud Managed Lustre para ter o melhor desempenho.
Para conferir os números de desempenho específicos de cada nível, consulte Níveis de desempenho.
Desempenho após o aumento da capacidade
Aumentar a capacidade de armazenamento de uma instância aumenta a capacidade máxima de processamento e as IOPS, e possivelmente o desempenho dos metadados.
O desempenho da capacidade de processamento de leitura melhora gradualmente à medida que novos dados são gravados e redistribuídos no armazenamento adicional. O desempenho da capacidade de processamento de gravação aumenta imediatamente.
Utilização de alta capacidade
Quando a utilização da capacidade de armazenamento de uma instância atinge 90%, o desempenho dela pode ser reduzido. Considere aumentar a capacidade da instância do Managed Lustre. Talvez seja necessário solicitar mais cota antes da expansão.
Se você estiver recebendo No space left on device erros, mas a instância mostrar
capacidade restante, consulte No space left on device erros.
Unidade máxima de transmissão (MTU) da rede VPC
Ao criar a rede VPC, definir o valor de mtu
(unidade máxima de transmissão ou o tamanho do maior pacote IP que pode ser
transmitido nessa rede) como o valor máximo permitido de 8896 melhora o
desempenho em até 10% em comparação com o valor padrão de 1460 bytes.
É possível conferir o valor atual da MTU da rede com o comando a seguir:
gcloud compute networks describe NETWORK_NAME --format="value(mtu)"
O valor da MTU de uma rede pode ser atualizado após a criação dela, mas há considerações importantes. Consulte Alterar a MTU de uma rede para mais detalhes.
Tipos de máquina do Compute Engine
A capacidade de processamento da rede pode ser afetada pela escolha do tipo de máquina. Em geral, para ter a melhor capacidade de processamento:
- Aumentar o número de vCPUs. A largura de banda de saída máxima por instância geralmente é de 2 Gbps por vCPU, até o máximo do tipo de máquina.
- Selecione uma série de máquinas que ofereça suporte a limites de entrada e saída mais altos. Por exemplo, as instâncias C2 com rede Tier_1 oferecem suporte a até 100 Gbps de largura de banda de saída. As instâncias C3 com rede Tier_1 oferecem suporte a até 200 Gbps.
- Ative o desempenho de rede por VM de Tier_1 com tipos de máquinas maiores.
- Use a NIC virtual do Google (gVNIC). A gVNIC é a única opção para tipos de máquina de terceira geração e mais recentes. A gVNIC é necessária ao usar a rede Tier_1.
Para informações detalhadas, consulte Largura de banda de rede.
Configuração multi-NIC
Ao usar o recurso multi-rail integrado do Lustre, os clientes podem distribuir o tráfego de rede em várias placas de rede (multi-NIC). Isso agrega largura de banda para saturar instâncias do Managed Lustre de alta capacidade.
Para configurar a multi-NIC, é necessário:
- Selecionar um tipo de máquina com várias NICs físicas.
- Criar uma sub-rede para cada NIC e atribuir cada NIC à sub-rede.
- Siga as etapas da multi-NIC ao se conectar pelo Compute Engine ou GKE.
Verificar o balanceamento de tráfego
Depois de configurar a multi-NIC, verifique se os dados estão sendo balanceados corretamente.
Compute Engine
Verifique o balanceamento de dados diretamente na VM monitorando as interfaces de rede configuradas (por exemplo, eth0 e eth1) usando nload ao gerar tráfego para o back-end do Managed Lustre:
nload -m eth0 eth1
Em uma configuração multi-NIC bem-sucedida, as taxas de bits de saída precisam ser aproximadamente equivalentes em todas as interfaces configuradas.
GKE
Confirme se o tráfego de rede da carga de trabalho está balanceado em várias NICs implantando um pod de depurador de rede temporário no nó em que a carga de trabalho está programada:
Identifique o nó em que a carga de trabalho está programada:
kubectl get pod POD_NAME -o wideSubstitua POD_NAME pelo nome do pod. Na resposta ao comando, anote o nome na coluna
NODE.Inicie o depurador de rede nesse nó:
kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \ --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \ -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"Substitua NODE_NAME pelo nome do nó da etapa anterior.
Na saída, analise as taxas de bits da coluna Outgoing para
eth0eeth1. Se a configuração for bem-sucedida, as taxas de bits serão aproximadamente equivalentes. O resultado será o seguinte:Device eth0 [10.1.0.50] (1/2): ========================================================================== Incoming: Outgoing: Curr: 1.63 MBit/s Curr: 1.46 GBit/s Avg: 1.60 MBit/s Avg: 1.44 GBit/s Min: 1.40 MBit/s Min: 1.25 GBit/s Max: 1.64 MBit/s Max: 1.47 GBit/s Ttl: 590.94 GByte Ttl: 405.19 GByte Device eth1 [172.16.15.5] (2/2): ========================================================================== Incoming: Outgoing: Curr: 1.64 MBit/s Curr: 1.47 GBit/s Avg: 1.62 MBit/s Avg: 1.44 GBit/s Min: 1.42 MBit/s Min: 1.26 GBit/s Max: 1.66 MBit/s Max: 1.47 GBit/s Ttl: 587.68 GByte Ttl: 406.36 GByteSaia do depurador pressionando Ctrl+C.
Como solucionar gargalos comuns
Se o desempenho da carga de trabalho for significativamente menor do que o esperado para o nível de desempenho do Managed Lustre, verifique os seguintes problemas comuns:
Número insuficiente de máquinas cliente:uma única máquina cliente é limitada pela própria CPU virtual (vCPU) e pelos limites de processamento de rede de link único. Para saturar níveis de alta capacidade de processamento, é necessário distribuir a carga. Por exemplo, para saturar um sistema de arquivos do Managed Lustre de 100.000 MBps, geralmente são necessárias pelo menos 60 máquinas cliente padrão (ou 12 máquinas cliente configuradas para usar a rede de alta largura de banda de nível 1) gravando em paralelo. Para o tamanho máximo da instância de qualquer nível de desempenho, talvez sejam necessárias mais de 2.500 máquinas cliente configuradas para usar a rede de alta largura de banda de nível 1.
MTU de nuvem privada virtual (VPC) não ideal:por padrão, as redes VPC usam uma MTU de
1460(frames Ethernet padrão). Para armazenamento de alta performance, como o Managed Lustre, é necessário configurar frames jumbo com uma MTU de8896. A execução com uma MTU padrão de1460força a CPU a processar mais do que o dobro do número de pacotes de rede, adicionando sobrecarga de CPU e limitando a largura de banda máxima.Configuração de largura de banda de rede de nível 1 ausente:muitos tipos de máquina de alta performance exigem que você ative explicitamente a largura de banda de rede de nível 1.
- Nos pools de nós do Compute Engine e do GKE Standard, use a flag
--network-performance-configs=total-egress-bandwidth-tier=TIER_1durante a criação. Sem essa flag, uma VM ou um nó pode ser limitado a um limite de saída padrão mais baixo. - No GKE Autopilot, não é possível especificar essa flag diretamente. Em vez disso, selecione uma série de máquinas que ofereça suporte a maior largura de banda (como
c3) usando seletores de nós nas especificações do pod.
Para mais informações, consulte Tipos de máquina do Compute Engine.
- Nos pools de nós do Compute Engine e do GKE Standard, use a flag
Uso desequilibrado do destino de armazenamento de objetos (OST) do Lustre:o Managed Lustre divide os dados de arquivos em vários destinos de armazenamento de objetos (OSTs). Se o teste ou a carga de trabalho gravar em um único arquivo não distribuído ou se as tarefas do cliente gravarem padrões que sobrecarregam um único OST, esse OST se tornará um gargalo enquanto o restante do sistema de arquivos ficar inativo. Para evitar isso, equilibre a carga de gravação de maneira uniforme em todos os OSTs disponíveis (por exemplo, usando o modo de arquivo por processo em benchmarks).
Disputa de largura de banda de rede compartilhada:a largura de banda de saída em máquinas cliente (VMs do Compute Engine ou nós do GKE) é compartilhada em todas as operações de rede na máquina. Se as máquinas ou os pods do cliente estiverem fazendo o download de pacotes grandes simultaneamente, executando varreduras de registro pesadas ou se comunicando muito com outros nós do cluster, o desempenho do armazenamento será limitado à largura de banda de rede restante.