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 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 NVMe di dimensioni maggiori vengono fornite come dispositivi a blocchi non formattati.

Poiché il dispositivo NVMe a blocchi bypassa l'hypervisor, offre una maggiore larghezza di banda, IOPS più elevati e una latenza inferiore per IOP. Se abbinate in una matrice con striping, le unità SSD NVMe offrono fino a 50 GB/s di larghezza di banda di lettura e 30 GB/s di larghezza di banda di scrittura per dimensioni di blocco di grandi dimensioni.

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

Specifiche hardware

Specifiche software

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.