Freigeben über

Übersicht über virtuelle Computer der HB-Serie

  • Artikel

Gilt für: ✔️ Virtuelle Linux-Computer ✔️ Virtuelle Windows-Computer ✔️ Flexible Skalierungsgruppen ✔️ Einheitliche Skalierungsgruppen

Die Maximierung der Leistung von HPC-Anwendungen (High Performance Computing) für AMD EPYC erfordert ein durchdachtes Konzept für die Lokalität des Arbeitsspeichers und die Prozessplatzierung. Im Anschluss finden Sie einen Überblick über die AMD EPYC-Architektur sowie über unsere Implementierung in Azure für HPC-Anwendungen. Die Benennung „pNUMA“ wird verwendet, um auf eine physische NUMA-Domäne zu verweisen. „vNUMA“ verweist auf eine virtualisierte NUMA-Domäne.

Physisch handelt es sich bei einem Server der HB-Serie um zwei EPYC 7551-CPUs mit jeweils 32 Kernen, wodurch sich eine Gesamtanzahl von 64 physischen Kernen ergibt. Diese 64 Kerne sind in 16 pNUMA-Domänen (acht pro Socket) unterteilt, die jeweils vier Kerne umfassen und als CPU-Komplex (CPU Complex, CCX) bezeichnet werden. Jeder CCX verfügt über einen eigenen L3-Cache, so dass ein Betriebssystem eine pNUMA/vNUMA-Grenze erkennt. Ein Paar von benachbarten CCXs teilt sich jeweils den Zugriff auf zwei Kanäle des physischen DRAM. (Server der HB-Serie verfügen über 32 GB DRAM.)

Damit der Azure-Hypervisor über genügend Platz verfügt, um ohne Beeinträchtigung des virtuellen Computers agieren zu können, wird die physische pNUMA-Domäne 0 (der erste CCX) reserviert. Anschließend werden die pNUMA-Domänen 1–15 (die verbleibenden CCX-Einheiten) für den virtuellen Computer zugewiesen. Der virtuelle Computer sieht Folgendes:

(15 vNUMA domains) * (4 cores/vNUMA) = 60 Kerne pro virtuellem Computer

Dem virtuellen Computer ist nicht bekannt, dass ihm pNUMA 0 nicht zugewiesen wurde. Der virtuelle Computer interpretiert pNUMA 1–15 als vNUMA 0–14 – mit sieben vNUMA-Instanzen auf vSocket 0 und 8 vNUMA-Instanzen auf vSocket 1. Ihr Betriebssystem sollte trotz dieser Asymmetrie normal starten und funktionieren. Im weiteren Verlauf dieses Leitfadens erfahren Sie, wie Sie MPI-Anwendungen in diesem asymmetrischen NUMA-Layout am besten ausführen.

Eine feste Prozesszuordnung (Process Pinning) funktioniert bei virtuellen Computern der HB-Serie, da der zugrunde liegende Chip unverändert für den virtuellen Gastcomputer verfügbar gemacht wird. Aus Leistungs- und Konsistenzgründen wird dringend empfohlen, Prozesse fest zuzuordnen.

Das folgende Diagramm zeigt die Trennung zwischen den Kernen, die für den Azure-Hypervisor reserviert sind, und den Kernen für den virtuellen Computer der HB-Serie:

Trennung zwischen den Kernen, die für den Azure-Hypervisor reserviert sind, und den Kernen für den virtuellen Computer der HB-Serie

Hardwarespezifikationen

Hardwarespezifikationen Virtueller Computer der HB-Serie
Kerne 60 (SMT deaktiviert)
CPU AMD EPYC 7551
CPU-Frequenz (ohne AVX) ~2,55 GHz (einzeln + alle Kerne)
Arbeitsspeicher 4 GB/Kern (240 GB insgesamt)
Lokaler Datenträger 700 GB SSD
InfiniBand 100 GBit EDR Mellanox ConnectX-5
Netzwerk 50-GBit-Ethernet (davon 40 GBit nutzbar); Azure-SmartNIC der zweiten Generation

Softwarespezifikationen

Softwarespezifikationen Virtueller Computer der HB-Serie
Maximale MPI-Auftragsgröße 18000 Kerne (300 VMs in einer einzelnen VM-Skalierungsgruppe mit singlePlacementGroup=true)
MPI-Unterstützung HPC-X, Intel MPI, OpenMPI, MVAPICH2, MPICH, Platform MPI
Zusätzliche Frameworks UCX, libfabric und PGAS
Azure Storage-Unterstützung Standard- und Premium-Datenträger (maximal 4 Datenträger)
Betriebssystemunterstützung für SR-IOV/RDMA RHEL 7.6 und höher, Ubuntu 18.04 und höher, SLES 15.4, WinServer 2016 und höher
Orchestratorunterstützung CycleCloud, Batch und AKS (Clusterkonfigurationsoptionen)

Wichtig

Dieses Dokument verweist auf eine Releaseversion von Linux, die sich dem Ende des Lebenszyklus (End of Life, EOL) nähert oder es erreicht hat. Erwägen Sie ein Update auf eine aktuellere Version.

Nächste Schritte