Problemas conhecidos com VMs da série H e da série N

Aplica-se a: ✔️ VMs do Linux ✔️ VMs do Windows ✔️ Conjuntos de dimensionamento flexíveis ✔️ Conjuntos de dimensionamento uniformes

Este artigo tenta listar problemas comuns recentes e suas soluções ao usar as VMs HPC e GPU da série H e da série N.

Topologia de cache em Standard_HB120rs_v3

lstopo exibe a topologia de cache incorreta no tamanho da VM Standard_HB120rs_v3. Ele pode mostrar que há apenas 32 MB L3 por NUMA. No entanto, na prática, há de fato 120 MB L3 por NUMA, conforme esperado, uma vez que os mesmos 480 MB de L3 para a VM inteira estão disponíveis da mesma forma que com os outros tamanhos de VM HBv3 de núcleo restrito. Esse é um erro superficial na exibição do valor correto que não deve afetar as cargas de trabalho.

Restrição de acesso qp0

Para evitar o acesso de hardware de baixo nível que pode resultar em vulnerabilidades de segurança, o par de filas 0 não está acessível para VMs convidadas. Isso deve afetar apenas as ações normalmente associadas à administração do ConnectX InfiniBand NIC e à execução de alguns diagnósticos do InfiniBand, como ibdiagnet, mas não aos aplicativos do usuário final.

Instalação do MOFED no Ubuntu

Em imagens de VM do marketplace baseadas no Ubuntu-18.04 com versão de kernel 5.4.0-1039-azure #42 e mais recente, alguns Mellanox OFED mais antigos são incompatíveis, causando um aumento no tempo de inicialização da VM de até 30 minutos em alguns casos. Isso foi relatado para as versões do Mellanox OFED 5.2-1.0.4.0 e 5.2-2.2.0.0. O problema é resolvido com o Mellanox OFED 5.3-1.0.0.1. Se for necessário usar o OFED incompatível, uma alternativa é usar a imagem da VM do marketplace Canonical:UbuntuServer:18_04-lts-gen2:18.04.202101290 ou mais antiga e não atualizar o kernel.

Rede acelerada em HB, HC, HBv2, HBv3 e NDv2

A Rede Acelerada do Azure agora está disponível nos tamanhos de VM compatíveis com RDMA e InfiniBand e habilitados para SR-IOV HB, HC, HBv2, HBv3 e NDv2. Esse recurso agora permite taxa de transferência (até 30 Gbps) e latências aprimoradas na rede Ethernet do Azure. Embora isso seja separado dos recursos RDMA na rede InfiniBand, algumas alterações de plataforma nesse recurso podem afetar o comportamento de determinadas implementações de MPI ao executar trabalhos na InfiniBand. Especificamente, a interface da InfiniBand em algumas VMs podem ter um nome ligeiramente diferente (mlx5_1 as opposed to earlier mlx5_0). Isso pode exigir um ajuste nas linhas de comando da MPI, principalmente ao usar a interface UCX (normalmente com OpenMPI e HPC-X).

A solução mais simples atualmente é usar o HPC-X mais recente nas imagens de VM CentOS-HPC em que renomeamos as interfaces InfiniBand e Rede Acelerada de acordo ou para executar o script para renomear a interface InfiniBand.

Mais detalhes sobre isso estão disponíveis neste artigo do TechCommunity com instruções sobre como resolver problemas observados.

Instalação do driver InfiniBand em VMs que não são do SR-IOV

Atualmente, H16r, H16mr e NC24r não estão habilitados para SR-IOV. Para obter mais informações sobre a bifurcação da pilha InfiniBand, consulte Tamanhos de VM do Azure – HPC. A InfiniBand pode ser configurada em tamanhos de VM habilitados para SR-IOV com os drivers OFED, e os tamanhos de VM que não são de SR-IOV exigem drivers ND. Esse suporte da IB está disponível adequadamente para CentOS, RHEL e Ubuntu.

MAC duplicado com cloud-init no Ubuntu nas VMs da série H e da série N

Há um problema conhecido com o cloud-init em imagens de VM Ubuntu, pois ele tenta abrir a interface IB. Isso pode ocorrer na reinicialização da VM ou ao tentar criar uma imagem da VM após a generalização. Os logs de inicialização da VM podem mostrar um erro como este:

“Starting Network Service...RuntimeError: duplicate mac found! both 'eth1' and 'ib0' have mac”.

Esse “MAC duplicado com cloud-init no Ubuntu” é um problema conhecido. Isso será resolvido nos kernels mais recentes. Se esse problema for encontrado, a solução alternativa será:

  1. Implantar a imagem da VM do Marketplace (Ubuntu 18.04)
  2. Instalar os pacotes de software necessários para habilitar a IB (instrução aqui)
  3. Editar waagent.conf para alterar EnableRDMA = y
  4. Desabilitar rede no cloud-init
    echo network: {config: disabled} | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
    
  5. Editar o arquivo de configuração de rede do netplan gerado pelo cloud-init para remover o MAC
    sudo bash -c "cat > /etc/netplan/50-cloud-init.yaml" <<'EOF'
    network:
      ethernets:
        eth0:
          dhcp4: true
      version: 2
    EOF
    

DRAM em VMs da série HB

No momento, as VMs da série HB só podem expor 228 GB de RAM para VMs convidadas. Da mesma forma, 458 GB em VMs HBv2 e 448 GB em VMs HBv3. Isso ocorre devido a uma limitação conhecida do hipervisor do Azure para impedir que as páginas sejam atribuídas ao DRAM local do AMD CCX (domínios NUMA) reservado para a VM convidada.

Proxy GSS

O proxy GSS apresenta um bug conhecido no CentOS/RHEL 7.5 que pode se manifestar como uma perda significativa em capacidade de resposta e desempenho quando usado com o NFS. Isso pode ser reduzido com:

sed -i 's/GSS_USE_PROXY="yes"/GSS_USE_PROXY="no"/g' /etc/sysconfig/nfs

Limpeza de cache

Em sistemas HPC, geralmente é útil limpar a memória após a conclusão de um trabalho antes que o mesmo nó seja atribuído ao próximo usuário. Depois de executar aplicativos no Linux, você pode descobrir que a memória disponível se reduz à medida que a memória do buffer aumenta, mesmo sem executar nenhum aplicativo.

Captura de tela do prompt de comando antes da limpeza

O uso do numactl -H mostrará com quais NUMAnodes a memória é armazenada em buffer (possivelmente todos). No Linux, os usuários podem limpar os caches de três maneiras para retornar memória armazenada em buffer ou em cache para o estado “livre”. Você precisa ser usuário raiz ou ter permissões sudo.

echo 1 > /proc/sys/vm/drop_caches [frees page-cache]
echo 2 > /proc/sys/vm/drop_caches [frees slab objects e.g. dentries, inodes]
echo 3 > /proc/sys/vm/drop_caches [cleans page-cache and slab objects]

Captura de tela do prompt de comando após a limpeza

Avisos do kernel

Você pode ignorar as seguintes mensagens de aviso do kernel ao inicializar uma VM da série HB no Linux. Isso ocorre devido a uma limitação conhecida do hipervisor do Azure que será abordada ao longo do tempo.

[  0.004000] WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:376 topology_sane.isra.3+0x80/0x90
[  0.004000] sched: CPU #4's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
[  0.004000] Modules linked in:
[  0.004000] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 3.10.0-957.el7.x86_64 #1
[  0.004000] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 05/18/2018
[  0.004000] Call Trace:
[  0.004000] [<ffffffffb8361dc1>] dump_stack+0x19/0x1b
[  0.004000] [<ffffffffb7c97648>] __warn+0xd8/0x100
[  0.004000] [<ffffffffb7c976cf>] warn_slowpath_fmt+0x5f/0x80
[  0.004000] [<ffffffffb7c02b34>] ? calibrate_delay+0x3e4/0x8b0
[  0.004000] [<ffffffffb7c574c0>] topology_sane.isra.3+0x80/0x90
[  0.004000] [<ffffffffb7c57782>] set_cpu_sibling_map+0x172/0x5b0
[  0.004000] [<ffffffffb7c57ce1>] start_secondary+0x121/0x270
[  0.004000] [<ffffffffb7c000d5>] start_cpu+0x5/0x14
[  0.004000] ---[ end trace 73fc0e0825d4ca1f ]---

Próximas etapas