共用方式為

HBv4 系列虛擬機器概觀

  • 發行項

適用於： ✔️ Linux VM ✔️ Windows VM ✔️ 彈性擴展集 ✔️ 統一擴展集

HBv4 系列伺服器具有 2 * 96 核心 EPYC 9V33X CPU，總共有 192 個實體「Zen4」核心和 AMD 3D V-Cache。 HBv4 上的同步多執行緒 (SMT) 已停用。 這些 192 核心分割為 24 個區段 (每個通訊端 12 個區段)，每個區段包含 8 個處理器核心，並且能統一存取 96 MB L3 快取。 Azure HBv4 伺服器也會執行下列 AMD BIOS 設定：

Nodes per Socket (NPS) = 2
L3 as NUMA = Disabled
NUMA domains within VM OS = 4
C-states = Enabled

如此一來，伺服器就會以 4 個 NUMA 網域啟動 (每個通訊端 2 個)，每個網域大小為 48 核心。 每個 NUMA 都能直接存取 6 個實體 DRAM 通道。

為了讓 Azure Hypervisor 擁有足夠空間，在不干擾 VM 的情況下運作，我們會為每個伺服器保留 16 個實體核心。

VM 拓撲

下圖說明伺服器的拓撲。 我們會在兩個 CPU 通訊端上以對稱方式保留這 16 個 Hypervisor 主機核心 (黃色)，從每個 NUMA 網域上的特定 Core Complex Dies (CCD) 中取用前 2 個核心，其餘核心用於 HBv4 系列 VM (綠色)。

HBv4 系列伺服器拓撲的螢幕擷取畫面

CCD 界限與 NUMA 界限不同。 在 HBv4 上，六個 (6) 連續 CCD 的群組會設為 NUMA 網域，並位於主機伺服器層級和客體 VM 內。 因此，所有 HBv4 VM 大小都會公開 4 個統一 NUMA 網域，並顯示在 OS 和應用程式中 (如下所示)，每個網域都有不同核心數目，取決於特定的 HBv4 VM 大小。

HBv4 系列 VM 拓撲的螢幕擷取畫面

每個 HBv4 VM 大小在實體配置、功能和效能上，與 AMD EPYC 9V33X 系列中不同的 CPU 相似，如下所示：

HBv4 系列 VM 大小 NUMA 網域 每個 NUMA 網域的核心 與 AMD EPYC 的相似性
Standard_HB176rs_v4 4 44 雙通訊端 EPYC 9V33X
Standard_HB176-144rs_v4 4 36 雙通訊端 EPYC 9V33X
Standard_HB176-96rs_v4 4 24 雙通訊端 EPYC 9V33X
Standard_HB176-48rs_v4 4 12 雙通訊端 EPYC 9V33X
Standard_HB176-24rs_v4 4 6 雙通訊端 EPYC 9V33X

注意

受限核心的 VM 大小只會減少向 VM 公開的實體核心數目。 所有全域共用資產 (RAM、記憶體頻寬、L3 快取、GMI 和 xGMI 連線能力、InfiniBand、Azure 乙太網路、本地 SSD) 均保持不變。 因此，客戶能根據特定的工作負載或軟體授權需求，挑選最適合的 VM 大小。

每個 HBv4 VM 大小的虛擬 NUMA 對應會對應至基礎實體 NUMA 拓撲。 對硬體拓撲沒有潛在的誤導性抽象概念。

使用 lstopo 的輸出，各 HBv4 VM 大小 的確切拓撲如下所示：

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

按一下即可檢視 Standard_HB176rs_v4 的 lstopo 輸出

HBv4-176 VM 的 lstopo 輸出

按一下即可檢視 Standard_HB176-144rs_v4 的 lstopo 輸出

HBv4-144 VM 的 lstopo 輸出

按一下即可檢視 Standard_HB176-96rs_v4 的 lstopo 輸出

HBv4-64 VM 的 lstopo 輸出

按一下即可檢視 Standard_HB176-48rs_v4 的 lstopo 輸出

HBv4-32 VM 的 lstopo 輸出

按一下即可檢視 Standard_HB176-24rs_v4 的 lstopo 輸出

HBv4-24 VM 的 lstopo 輸出

Infiniband 網路功能

HBv4 VM 也提供 NVIDIA Mellanox NDR InfiniBand 網路介面卡 (ConnectX-7)，最高能以 400 Gb/秒運作。NIC 會透過 SRIOV 傳遞至 VM，讓網路流量略過 Hypervisor。 因此，客戶能如同在裸機環境中一般，在 HBv4 VM 上載入標準的 Mellanox OFED 驅動程式。

HBv4 VM 支援自適性路由、動態連線傳輸 (DCT，除了標準 RC 和 UD 傳輸以外)，以及 MPI 集合硬體型卸載至 ConnectX-7 介面卡的板面處理器。 這些功能會增強應用程式效能、可擴縮性和一致性，我們建議使用這些功能。

暫存位置

HBv4 VM 具有 3 個實體的本地 SSD 裝置。 系統會將裝置預先格式化作為分頁檔，在您的 VM 中顯示為一般「SSD」裝置。

另外兩個較大的 SSD，會透過 NVMeDirect 提供為未格式化的區塊 NVMe 裝置。 當區塊 NVMe 裝置略過 Hypervisor 時，會有更高的頻寬與 IOPS，以及較低的每 IOP 延遲。

在等量陣列中配對時，NVMe SSD 最多能提供 7 GB/秒的讀取和 12 GB/秒的寫入，以及最高 186,000 IOPS (讀取) 和 201,000 IOPS (寫入)，可取得較深的佇列深度。

硬體規格

硬體規格 HBv4 系列 VM
核心 176、144、96、48 或 24 (停用 SMT)
CPU AMD EPYC 9V33X
CPU 頻率 (非 AVX) 2.4 GHz 基底、3.7 GHz 尖峰提升
記憶體 768 GB (每個核心的 RAM 取決於 VM 大小)
本機磁碟 2 * 1.8 TB NVMe (區塊)、480 GB SSD (分頁檔)
InfiniBand 400 Gb/秒 Mellanox ConnectX-7 NDR InfiniBand
網路 80 Gb/秒 乙太網路 (40 Gb/秒 可用) Azure 第二代 SmartNIC

軟體規格

軟體規格 HBv4 系列 VM
MPI 工作大小上限 52,800 核心 (singlePlacementGroup=true 的單一虛擬機器擴展集中的 300 個 VM)
MPI 支援 HPC-X (2.13 或更高版本)、Intel MPI (2021.7.0 或更高版本)、OpenMPI (4.1.3 或更高版本)、MVAPICH2 (2.3.7 或更高版本)、MPICH (4.1 或更高版本)
其他架構 UCX、libfabric、PGAS 或其他以 InfiniBand 為基礎的執行階段
Azure 儲存體支援 標準和進階磁碟 (最多 32 個磁碟)、Azure NetApp Files、Azure 檔案儲存體、Azure HPC Cache、Azure Managed Lustre 檔案系統
支援和已驗證的 OS AlmaLinux 8.6、8.7、Ubuntu 20.04+
效能建議作業系統 AlmaLinux HPC 8.7、Ubuntu-HPC 20.04+
協調器支援 Azure CycleCloud、Azure Batch、AKS；叢集設定選項

注意

  • 這些 VM 僅支援第二代。
  • AMD 的官方核心層級支援從 RHEL 8.6 和 AlmaLinux 8.6 (RHEL 的衍生版本)。
  • HBv4 和其他具有超過 64 個 (虛擬或實體) 核心的 VM 均不支援 Windows Server 2012 R2。 如需詳細資訊，請參閱 Windows Server 上 Hyper-V 支援的 Windows 客體作業系統。 Windows Server 2022 需要 144 和 176 核心大小，Windows Server 2016 也適用於 24、48 和 96 核心大小，Windows Server 僅適用於 24 和 48 核心大小。

重要

建議的映像 URN：almalinux:almalinux-hpc:8_7-hpc-gen2:8.7.2023060101，若要透過 Azure CLI 部署此映像，請確定已包含下列參數 --plan 8_7-hpc-gen2 --product almalinux-hpc --publisher almalinux。 如需調整測試，請使用建議的 URN 和新 HPC-X Tarball。

注意

  • NDR 支援會新增在 UCX 1.13 或更新版本。 較舊的 UCX 版本會回報上述執行階段錯誤。 UCX 錯誤：不正確使用中速度 [1677010492.951559] [updsb-vm-0:2754 :0] ib_iface.c:1549 UCX ERROR Invalid active_speed on mlx5_ib0:1: 128。
  • Ibstat 顯示低速 (SDR)：較舊的 Mellanox OFED (MOFED) 版本不支援 NDR，而且可能回報較慢的 IB 速度。 請使用 MOFED 5.6-1.0.3.3 版本或更新版本。

下一步