Panoramica delle macchine virtuali serie HBv5

Si applica a: ✔️ Macchine virtuali Linux ✔️ Macchine virtuali Windows ✔️ Set di scalabilità flessibili ✔️ Set di scalabilità uniformi

Un server serie HBv5 è dotato di 4 CPU AMD EPYC™ di quarta generazione, ognuna con 96 core, per un totale di 384 core fisici "Zen4" e SMT (Simultaneous Multithreading) disabilitato. Questi 384 core sono suddivisi in sezioni di 48 Core Chiplet Dies (CCD) (12 per socket), e ciascun CCD contiene otto core del processore con accesso uniforme a una cache L3 da 32 MB. I server Azure HBv5 eseguono anche le seguenti impostazioni DEL BIOS AMD:

Nodes per Socket (NPS) = 4
L3 as NUMA = Disabled
Total NUMA domains within VM OS = 16 (4 per socket)
NUMA domains within VM OS = 4
C-states = Enabled
Determinism Mode = Power

Di conseguenza, il server viene avviato con 16 domini NUMA (4 per socket), ciascuno di 24 core. Ogni NUMA ha accesso diretto a due moduli HBM3 da 16 GB.

Per consentire all'hypervisor di Azure di funzionare senza interferire con la macchina virtuale, si riservano 4 core fisici per NUMA e 16 per server.

Topologia della macchina virtuale

Il diagramma seguente illustra la topologia del server. Questi 16 core dell’host hypervisor (giallo) vengono riservati simmetricamente, prendendo il primo core da CCD (Core Complex Die) specifici in ogni dominio NUMA, con i core rimanenti per la macchina virtuale serie HBv5 (verde).

Il limite CCD è diverso da un limite NUMA. In HBv5 un gruppo di sei (6) CCD consecutivi è configurato come dominio NUMA, sia a livello di server host che all'interno di una macchina virtuale guest. Di conseguenza, tutte le dimensioni delle macchine virtuali HBv5 espongono quattro domini NUMA uniformi che appaiono in un sistema operativo e un'applicazione come illustrato di seguito, ognuno con un numero diverso di core a seconda delle dimensioni specifiche della macchina virtuale HBv5.

Ogni dimensione di MACCHINA virtuale HBv5 è simile a quella del layout fisico, delle funzionalità e delle prestazioni di una CPU diversa rispetto a AMD EPYC 9V33X, come indicato di seguito:

La mappatura NUMA virtuale di ogni dimensione di VM HBv5 viene mappata alla sottostante topologia NUMA fisica. Non esiste alcuna potenziale astrazione fuorviante della topologia hardware.

La topologia esatta per le varie dimensioni della macchina virtuale HBv5 viene visualizzata come segue usando l'output di lstopo:

lstopo-no-graphics --no-io --no-legend --of txt

Rete InfiniBand

Le macchine virtuali HBv5 includono anche 4 schede NVIDIA Quantum-2 CX7 InfiniBand (NDR) che operano fino a 200 Gigabit/sec per un totale di 800 Gigabit/sec per ogni macchina virtuale. Una scheda di interfaccia di rete si connette a ognuna delle 4 CPU in ogni macchina virtuale. La scheda di interfaccia di rete viene passata alla macchina virtuale tramite SRIOV, consentendo al traffico di rete di ignorare l'hypervisor. Di conseguenza, i clienti caricano i driver standard Mellanox OFED sulle macchine virtuali HBv5 come farebbero in un ambiente fisico.

Le macchine virtuali HBv5 supportano il routing adattivo, il trasporto connesso dinamico (DCT, oltre ai trasporti standard RC e UD) e l'offload basato su hardware dei collettivi MPI al processore di bordo dell'adattatore ConnectX-7. Queste funzionalità migliorano le prestazioni, la scalabilità e la coerenza dell'applicazione e se ne consiglia l'uso.

Procedure consigliate per la configurazione di InfiniBand

• Usare un'immagine di macchina virtuale convalidata. Scegliere un'immagine con driver testati e software pronto per NDR InfiniBand:

  • Consigliato: AlmaLinux 8.10 dalla raccolta di immagini condivise di AlmaLinux HPC
    Il team di Azure HPC fornisce l'accesso a AlmaLinux 8.10 dalla raccolta di immagini condivise di AlmaLinux HPC e questa immagine viene compilata usando gli script di immagine di macchina virtuale HPC di Azure.
  • Supportato anche: immagini del marketplace HPC di Azure (Ubuntu-HPC 18.04, Ubuntu-HPC 20.04)

• Selezionare il protocollo di trasporto InfiniBand ottimale

  • Per i processi su scala ridotta:

    UCX_TLS=rc,sm
    

  • Per i processi su larga scala:

    UCX_TLS=dc,sm UCX_MAX_RNDV_RAILS=1
    

• Disabilitare il multi-rail per i processi multinodo

  export UCX_MAX_RNDV_RAILS=1
  

• Usare le versioni stabili più recenti

  • UCX: 1.14.0 rc4 (a partire da settembre 2025)
  • HPC-X MPI: hpcx-v2.18-gcc-mlnx_ofed-redhat8-cuda12-x86_64 (a partire da settembre 2025)

Procedure consigliate per l'esecuzione di processi MPI in HBv5

• Applicare il profilo ottimizzato hpc-compute, che è ottimizzato per i carichi di lavoro HPC:

  sudo dnf install -y tuned
  sudo systemctl enable --now tuned
  sudo tuned-adm profile hpc-compute
  

• Abilitare Transparent Huge Pages (THP) per migliorare l'efficienza della memoria per allocazioni di grandi dimensioni:

  echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
  echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
  

• Abilitare il bilanciamento NUMA per migliorare la localizzazione della memoria.

  echo 1 | sudo tee /proc/sys/kernel/numa_balancing
  

• Eliminare le cache prima di eseguire i processi in quanto ciò riduce la variabilità e migliora la coerenza:

  echo 3 | sudo tee /proc/sys/vm/drop_caches
  

• Usare la libreria MPI HPCX nelle immagini ottimizzate per HPC di Azure:

  module load mpi/hpcx
  

• Posizionamento del processo MPI e affinità di base
  • Aggiungere processi MPI a core fisici
  • Evitare l'oversubscription
  • Usare la distributiva simmetrica degli intervalli per CCD (1-7 intervalli per CCD)
    • Ogni macchina virtuale HBv5 ha 48 CCD, quindi le configurazioni supportate includono:
      48, 96, 144, 192, 288, 336 ranks per VM
  • Comando di esempio:

    mpirun -np <number_of_ranks> \
      --map-by ppr:<ranks_per_CCD>:l3cache \
      --rank-by slot \
      --bind-to core \
      <other_options> <executable> <arguments>
    

La configurazione ottimale dipende dal carico di lavoro. La distribuzione della classificazione simmetrica offre in genere prestazioni ottimali, ma alcuni carichi di lavoro possono trarre vantaggio dall'uso di tutti i 368 core per macchina virtuale. Eseguire il benchmark di più configurazioni per determinare l'impostazione migliore.
(Informazioni di riferimento sulla topologia: 16 aree NUMA, 48 CCD per macchina virtuale).

• Per i processi con più macchine virtuali su larga scala, disabilitare multi rail in UCX usando:

  export UCX_MAX_RNDV_RAILS=1
  

Archiviazione temporanea

Le macchine virtuali HBv5 presentano 9 dispositivi SSD NVMe fisicamente locali. Un dispositivo è preformattato per fungere da file di pagina e viene visualizzato nella macchina virtuale come dispositivo SSD generico. Altre 8 unità SSD di dimensioni maggiori vengono fornite come dispositivi NVMe non formattati.

Poiché il dispositivo NVMe a blocchi ignora l'hypervisor, ha una larghezza di banda maggiore, operazioni di I/O al secondo più elevate e una latenza inferiore per IOP. Se abbinato in una matrice con striping, l'unità SSD NVMe dovrebbe fornire fino a 50 GB/s di larghezza di banda di lettura e 30 GB/s di larghezza di banda di scrittura per blocchi di grandi dimensioni.

Combinati, i 8 dispositivi NVMe forniscono 15 TiB di spazio di archiviazione locale totale per macchina virtuale.

Specifiche hardware

Specifiche software

Problemi noti relativi all'affinità dei nodi IB RDMA e NUMA

Panoramica dei problemi

In determinate macchine virtuali (VM), i nomi dei dispositivi RDMA InfiniBand (ad esempio mlx5_[0-3]) potrebbero non essere allineati correttamente alle rispettive affinità dei nodi NUMA. Idealmente, ogni dispositivo RDMA deve essere mappato come segue:

• mlx5_0 si trova nel nodo NUMA: 0
• mlx5_1 si trova nel nodo NUMA: 4
• mlx5_2 si trova nel nodo NUMA: 8
• mlx5_3 si trova nel nodo NUMA: 12

Tuttavia, un esempio di mapping non corretto potrebbe essere:

• mlx5_0 si trova nel nodo NUMA: 4
• mlx5_1 si trova nel nodo NUMA: 8
• mlx5_2 si trova nel nodo NUMA: 12
• mlx5_3 si trova nel nodo NUMA: 0

Questo disallineamento può causare una riduzione delle prestazioni, in particolare quando si eseguono carichi di lavoro MPI multimodo.

Verifica della mappatura del dispositivo RDMA al nodo NUMA

Per verificare se i dispositivi RDMA sono mappati correttamente ai nodi NUMA, eseguire lo script seguente:

for d in /sys/class/infiniband/*;
do
dev=$(basename "$d")
node=$(cat "$d/device/numa_node")
echo "$dev is on NUMA node: $node"
done

Confrontare l'output con il mapping ideale elencato in precedenza.

Soluzione: denominazione permanente dei dispositivi con regole Udev

Per correggere il problema di allineamento non corretto, seguire questa procedura:

1. Creare un nuovo file in /etc/udev/rules.d/, ad esempio: 99-rdma-persistent-naming.rules
2. Aggiungere le righe seguenti al file:

   ACTION=="add", SUBSYSTEMS=="pci", KERNELS=="0101:00:00.0", PROGRAM="rdma_rename %k NAME_FIXED mlx5_ib0"
   ACTION=="add", SUBSYSTEMS=="pci", KERNELS=="0102:00:00.0", PROGRAM="rdma_rename %k NAME_FIXED mlx5_ib1"
   ACTION=="add", SUBSYSTEMS=="pci", KERNELS=="0103:00:00.0", PROGRAM="rdma_rename %k NAME_FIXED mlx5_ib2"
   ACTION=="add", SUBSYSTEMS=="pci", KERNELS=="0104:00:00.0", PROGRAM="rdma_rename %k NAME_FIXED mlx5_ib3"
   

3. Ricaricare le regole udev e attivare gli eventi del dispositivo:

   # udevadm control --reload
   # udevadm trigger --type=devices --action=add
   

Questa soluzione garantisce che la denominazione dei dispositivi RDMA persiste tra i riavvii delle macchine virtuali.

Passaggi successivi

• Per informazioni sugli annunci più recenti, sugli esempi di carico di lavoro HPC e sui risultati delle prestazioni, vedere i Blog della community tecnica di Calcolo di Azure.
• Per un quadro generale sull'architettura per l'esecuzione di carichi di lavoro HPC, vedere HPC (High Performance Computing) in Azure.