Übersicht über virtuelle Computer der HBv5-Serie

Gilt für: ✔️ Linux-VMs ✔️ Windows-VMs ✔️ Flexible Skalierungssätze ✔️ Einheitliche Skalierungssätze

Ein Server der HBv5-Serie verfügt über 4 * 96-Core AMD EPYC-CPUs™ der 4. Generation für insgesamt 384 physische "Zen4"-Kerne mit deaktiviertem gleichzeitigem Multithreading (SMT). Diese 384 Kerne sind in 48 Core Chiplet Dies (CCDs) unterteilt (12 pro Sockel), wobei jede CCD acht Prozessorkerne enthält, die einen einheitlichen Zugriff auf einen 32 MB großen L3-Cache haben. Azure HBv5-Server führen auch die folgenden AMD BIOS-Einstellungen aus:

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

Daher startet der Server mit 16 NUMA-Domänen (4 pro Socket), jeweils mit je 24 Kernen. Jede NUMA verfügt über direkten Zugriff auf zwei 16 GB HBM3-Module.

Um Platz für den Betrieb des Azure-Hypervisors bereitzustellen, ohne die VM zu beeinträchtigen, reservieren wir 4 physische Kerne pro NUMA und 16 pro Server.

Topologie des virtuellen Computers

In der folgenden Abbildung wird die Topologie für diesen Server veranschaulicht: Wir halten diese 16 Hypervisor-Host Kerne (gelb) frei, wobei der erste Kern aus bestimmten Core Complex-Matrizen (CCDs) für jede NUMA-Domäne mit den verbleibenden Kernen für die VM der HBv5-Serie (grün) genommen werden.

Die CCD-Grenze unterscheidet sich von einer NUMA-Grenze. Auf HBv5 wird eine Gruppe von sechs (6) aufeinander folgenden CCDs sowohl auf Hostserverebene als auch innerhalb einer Gast-VM als NUMA-Domäne konfiguriert. Daher machen alle HBv5-VM-Größen vier einheitliche NUMA-Domänen verfügbar, die für ein Betriebssystem und eine Anwendung angezeigt werden, wie unten dargestellt, jeweils mit unterschiedlicher Anzahl von Kernen abhängig von der spezifischen Größe der HBv5-VM.

Jede VM-Größe von HBv5 ähnelt dem physischen Layout, den Features und der Leistung einer anderen CPU vom AMD EPYC 9V33X wie folgt:

Die virtuelle NUMA-Zuordnung der einzelnen HBv5-VM-Größen wird der zugrunde liegenden physischen NUMA-Topologie zugeordnet. Es gibt keine potenzielle irreführende Abstraktion der Hardwaretopologie.

Die genaue Topologie für die verschiedenen HBv5-VM-Größen wird wie folgt mit der Ausgabe von lstopo angezeigt:

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

InfiniBand-Netzwerk

HBv5 VMs verfügen außerdem über 4 NVIDIA Quantum-2 CX7 InfiniBand (NDR)-Adapter, die jeweils mit bis zu 200 Gigabits/s pro VM betrieben werden. Eine NIC stellt eine Verbindung mit jedem der vier CPUs auf jedem virtuellen Computer her. Die NIC wird über SRIOV an die VM übergeben, sodass der Netzwerkdatenverkehr den Hypervisor umgehen kann. Daher laden Kunden Standard-Mellanox OFED-Treiber auf HBv5-VMs, als ob es sich um eine Bare Metal-Umgebung handelt.

HBv5-VMs unterstützen adaptives Routing, Dynamic Connected Transport (DCT, zusätzlich zu den standardmäßigen RC- und UD-Transporten) und hardwarebasiertes Offload von MPI-Kollektiven an den Onboard-Prozessor des ConnectX-7-Adapters. Diese Features verbessern die Anwendungsleistung, Skalierbarkeit und Konsistenz, und ihre Verwendung wird empfohlen.

Bewährte Methoden für die InfiniBand-Konfiguration

• Verwenden Sie ein überprüftes VM-Image. Wählen Sie ein Bild mit getesteten Treibern und NDR InfiniBand-fähiger Software aus:

  • Empfohlen: AlmaLinux 8.10 aus der gemeinsamen Bildergalerie von AlmaLinux HPC
    Das Azure HPC-Team bietet Zugriff auf AlmaLinux 8.10 über die freigegebene AlmaLinux HPC-Bildergalerie, und dieses Image wird mithilfe von Azure HPC VM Image-Skripts erstellt.
  • Außerdem unterstützt: Azure HPC Marketplace-Images (Ubuntu-HPC 18.04, Ubuntu-HPC 20.04)

• Auswählen des optimalen InfiniBand-Transportprotokolls

  • Für kleinere Aufträge:

    UCX_TLS=rc,sm
    

  • Für größere Aufträge:

    UCX_TLS=dc,sm UCX_MAX_RNDV_RAILS=1
    

• Deaktivieren von Multischienen für Aufträge mit mehreren Knoten

  export UCX_MAX_RNDV_RAILS=1
  

• Verwenden der neuesten stabilen Versionen

  • UCX: 1.14.0 rc4 (ab September 2025)
  • HPC-X MPI: hpcx-v2.18-gcc-mlnx_ofed-redhat8-cuda12-x86_64 (Stand: September 2025)

Bewährte Methoden zum Ausführen von MPI-Aufträgen auf HBv5

• Wenden Sie das abgestimmte hpc-compute Profil an, das für HPC-Workloads optimiert ist:

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

• Aktivieren Sie Transparent Huge Pages (THP), um die Speichereffizienz bei großen Speicherzuweisungen zu verbessern:

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

• Aktivieren Sie DEN NUMA-Ausgleich für eine bessere Speicherlokalität:

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

• Legen Sie Caches vor dem Ausführen von Aufträgen ab, da dies die Variabilität verringert und die Konsistenz verbessert:

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

• Verwenden Sie die HPCX MPI-Bibliothek für azure HPC-optimierte Bilder:

  module load mpi/hpcx
  

• MPI-Prozessplatzierung und Kernaffinität
  • MPI-Prozesse an physische Kerne binden
  • Überbuchung vermeiden
  • Symmetrische Rangverteilung pro CCD verwenden (1–7 Rangfolgen pro CCD)
    • Jede HBv5-VM verfügt über 48 CCDs. Zu den unterstützten Konfigurationen gehören:
      48, 96, 144, 192, 288, 336 ranks per VM
  • Beispielbefehl:

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

Die optimale Konfiguration hängt von der Arbeitsauslastung ab. Symmetrische Rangverteilung funktioniert in der Regel am besten, aber einige Workloads können von der Verwendung aller 368 Kerne pro VM profitieren. Vergleichen Sie mehrere Konfigurationen, um die beste Einstellung zu ermitteln.
(Topologiereferenz: 16 NUMA-Regionen, 48 CCDs pro VM.)

• Deaktivieren Sie für Multi-VM-Aufträge im großen Maßstab mehrere Schienen in UCX, indem Sie Folgendes verwenden:

  export UCX_MAX_RNDV_RAILS=1
  

Temporärer Speicher

HBv5-VMs verfügen über 9 physisch lokale NVMe-SSD-Geräte. Ein Gerät ist vorformatiert, um als Seitendatei zu dienen und in Ihrer VM als generisches SSD-Gerät angezeigt. 8 weitere, größere SSDs werden als unformatierte Block-NVMe-Geräte bereitgestellt.

Da das NVMe-Blockgerät den Hypervisor umgeht, weist es eine höhere Bandbreite, höheren IOPS und eine geringere Wartezeit pro IOP auf. Bei der Kopplung in einem gestreiften Array wird erwartet, dass die NVMe-SSD bis zu 50 GB/s Lesebandbreite und 30 GB/s Schreibbandbreite für große Blockgrößen bereitstellt.

Kombiniert bieten die 8 NVMe-Geräte 15 TiB gesamt lokalen Speicher pro VM.

Hardwarespezifikationen

Softwarespezifikationen

Bekannte Probleme mit IB RDMA und NUMA Node Affinity

Problemübersicht

Auf bestimmten virtuellen Computern (VMs) stimmen die InfiniBand RDMA-Gerätenamen (z. B. mlx5_[0-3]) möglicherweise nicht ordnungsgemäß mit ihren jeweiligen NUMA-Knotenaffinitäten überein. Im Idealfall sollte jedes RDMA-Gerät wie folgt zugeordnet werden:

• mlx5_0 befindet sich auf DEM KNOTEN NUMA: 0
• mlx5_1 befindet sich auf DEM NUMA-Knoten: 4
• mlx5_2 befindet sich auf NUMA-Knoten: 8
• mlx5_3 befindet sich auf NUMA-Knoten: 12

Ein Beispiel für eine falsche Zuordnung könnte jedoch sein:

• mlx5_0 befindet sich auf NUMA-Knoten: 4
• mlx5_1 befindet sich auf NUMA-Knoten: 8
• mlx5_2 befindet sich auf NUMA-Knoten: 12
• mlx5_3 befindet sich auf DEM NUMA-Knoten: 0

Diese Fehlausrichtung kann zu Leistungsbeeinträchtigungen führen, insbesondere beim Ausführen von Multimode-MPI-Workloads.

Überprüfen des RDMA-Geräts zur NUMA-Knotenzuordnung

Führen Sie das folgende Skript aus, um zu bestätigen, ob Ihre RDMA-Geräte ordnungsgemäß NUMA-Knoten zugeordnet sind:

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

Vergleichen Sie die Ausgabe mit der oben aufgeführten idealen Abbildung.

Lösung: Persistente Gerätebenennung mit Udev-Regeln

Führen Sie die folgenden Schritte aus, um das Problem mit der Fehlausrichtung zu beheben:

1. Erstellen Sie eine neue Datei in /etc/udev/rules.d/, z. B.: 99-rdma-persistent-naming.rules
2. Fügen Sie der Datei die folgenden Zeilen hinzu:

   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. Laden Sie udev-Regeln neu, und lösen Sie Geräteereignisse aus:

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

Diese Lösung stellt sicher, dass die Benennung von RDMA-Geräten über VM-Neustarts hinweg beibehalten wird.

Nächste Schritte

• Informieren Sie sich über die neuesten Ankündigungen, HPC-Workloadbeispiele und Leistungsergebnisse in den Tech Community-Blogs zu Azure Compute.
• Eine allgemeinere Übersicht über die Architektur für die Ausführung von HPC-Workloads finden Sie unter High Performance Computing (HPC) in Azure.