Azure Stack Hub 計算能量

Azure Stack Hub 上支援的虛擬機器 (VM) 大小屬於 Azure 所支援 VM 大小的一小部分。 Azure 會在許多方面施加資源限制,來避免資源 (伺服器本機和服務層級) 過度耗用。 若未加以限制租用戶的耗用量,當其他租用戶過度耗用資源時,租用戶的體驗就會受到影響。 對於 VM 的網路輸出,在 Azure Stack Hub 上已有符合 Azure 限制的頻寬上限。 至於 Azure Stack Hub 上的儲存體資源,儲存體 IOPS 限制可避免租用戶為了存取儲存體而造成基本的資源過度耗用。

重要

Azure Stack Hub Capacity Planner 不會考量或保證 IOPS 效能。 系統管理員入口網站會在系統記憶體耗用量總計達到 85% 時,顯示警告警示。 您可以新增額外的容量或移除不再需要的虛擬機器,以補救此警示。

VM 放置

Azure Stack Hub 放置引擎會跨可用的主機來放置租用戶 VM。

在放置 VM 時,Azure Stack Hub 會使用兩個考量。 第一,主機上有足夠的記憶體可供該 VM 類型使用? 第二,VM 是可用性設定組的一部分或本身是虛擬機器擴展集

為了達到 Azure Stack Hub 中多 VM 生產工作負載的高可用性,會將虛擬機器 (VM) 放在可用性設定組中,此設定組會將 VM 分散在多個容錯網域中。 可用性設定組中的容錯網域會定義為縮放單位中的單一節點。 Azure Stack Hub 支援的可用性設定組最多可以有三個容錯網域 (與 Azure 一致)。 系統會將放在可用性設定組中的 VM 儘可能平均分散到多個容錯網域 (Azure Stack Hub 節點),讓這些 VM 在實體上彼此隔離。 如果發生硬體故障,失敗容錯網域中的 VM 將會在其他容錯網域中重新啟動。 如有可能,其會保留在相同可用性設定組中與其他 VM 不同的容錯網域中。 當主機回到線上時,系統會將 VM 重新平衡以保持高可用性。

虛擬機器擴展集會在後端使用可用性設定組,並確保每個虛擬機器擴展集執行個體都位於不同的容錯網域。 這表示擴展集會使用不同的 Azure Stack Hub 基礎結構節點。 例如,在 4 個節點的 Azure Stack Hub 系統中,具有 3 個執行個體的虛擬機器擴展集可能會在建立時發生失敗,原因是缺少 4 個節點的容量來將 3 個虛擬機器擴展集執行個體放到不同 Azure Stack Hub 節點上。 此外,Azure Stack Hub 節點可以先在不同層級上加以填滿,然後再嘗試放置。

Azure Stack Hub 不會過度分配記憶體。 不過,過度分配實體核心數目是允許的。

由於放置演算法不會將現有的虛擬至實體核心過度佈建比率視為因素之一,因此每部主機的比率可能各不相同。 Microsoft 不會提供實體對虛擬核心比率的指導方針,因為工作負載和服務層級需求會有變化。

虛擬機器總數的注意事項

可以建立的 VM 總數有上限。 Azure Stack Hub 的 VM 上限數為 700,每個縮放單位節點則為 60。 例如,8 伺服器 Azure Stack Hub VM 的限制會是 480 (8 * 60)。 針對 12 到 16 伺服器 Azure Stack Hub 解決方案,限制將會是 700。 建立此限制時已納入所有的計算容量考量,例如操作員想要在戳記上維護的復原保留和 CPU 虛擬對實體比率。

如果達到 VM 縮放限制,則會傳回下列錯誤碼:VMsPerScaleUnitLimitExceededVMsPerScaleUnitNodeLimitExceeded

注意

700 VM 最大值的一部分是保留給 Azure Stack Hub 基礎結構 VM。 如需詳細資訊,請參閱 Azure Stack Hub 容量規劃工具

批次部署 VM 的考量

在 2002 及之前的版本中,每批次 2-5 部 VM,各批次間隔 5 分鐘,可穩定部署 VM 達到 700 部 VM 的規模。 自 Azure Stack Hub 2005 版起,我們就可以穩定佈建每次間隔 5 分鐘、每批次 40 部 VM 的部署。 啟動、停止解除配置和更新作業應以 30 部 VM 的批次大小完成,且每批次間隔 5 分鐘。

GPU VM 的考量

Azure Stack Hub 會保留記憶體供基礎結構和租用戶 VM 進行容錯移轉。 和其他 VM 不同,GPU VM 是在非 HA (高可用性) 模式中執行,因此不會進行容錯移轉。 因此,僅限 GPU VM 戳記的保留記憶體對要進行容錯移轉的基礎結構而言為必要,而不是計入 HA 租用戶 VM 記憶體。

Azure Stack Hub 記憶體

Azure Stack Hub 的設計訴求是讓已成功佈建的 VM 持續執行。 例如,如果主機因為硬體故障而離線,Azure Stack Hub 會嘗試在另一部主機上重新啟動該 VM。 在 Azure Stack Hub 軟體修補和更新期間的第二個範例。 如果需要重新啟動實體主機時,系統會嘗試將該主機上執行的 VM 移到方案中另一個可用的主機上。

如果保留記憶體容量能夠允許重新啟動或執行移轉,才能管理或移動 VM。 整個主機記憶體中會有一部分加以保留,此部分無法用來放置租用戶 VM。

您可以在系統管理員入口網站中檢閱圓形圖,其中顯示 Azure Stack Hub 中可使用和已使用的記憶體。 下圖顯示 Azure Stack Hub 中 Azure Stack Hub 縮放單位上的實體記憶體容量:

Azure Stack Hub 縮放單位上的實體記憶體容量

已使用的記憶體包含數個元件。 下列元件會取用圓形圖中使用區段的記憶體:

  • 主機 OS 的使用或保留:主機作業系統 (OS)、虛擬記憶體頁面表格、主機 OS 上執行的程序及空間直接存取記憶體快取所使用的記憶體。 此值相依於主機上執行中的不同 Hyper-V 程序所使用的記憶體,因此會有變動。
  • 基礎結構服務:構成 Azure Stack Hub 的基礎結構 VM。 如先前所討論,這些 VM 是 700 VM 最大值的一部分。 我們一直在努力讓基礎結構服務變得更具擴充性和復原性,因此基礎結構服務元件的記憶體使用量可能會變更。 如需詳細資訊,請參閱 Azure Stack Hub 容量規劃工具
  • 復原保留:Azure Stack Hub 會保留一部分的記憶體,以在單一主機失敗期間維持租用戶可用性,以及在修補和更新期間讓 VM 順利地進行即時移轉。
  • 租用戶 VM:Azure Stack Hub 使用者建立的租用戶 VM。 除了執行 VM 以外,任何在網狀架構上登陸的 VM 也會取用記憶體。 這表示處在「建立中」或「失敗」狀態的 VM,或是從客體系統中關機的 VM,都會耗用記憶體。 不過,已從入口網站/powershell/cli 使用「停止解除配置項目」選項來解除配置的 VM,則不會從 Azure Stack Hub 中取用記憶體。
  • 加值資源提供者 (RP):針對加值 RP (如 SQL、MySQL、App Service 等) 部署的 VM。

在入口網站上了解記憶體耗用量的最佳方式是,使用 Azure Stack Hub Capacity Planner 來查看各種工作負載的影響。 下列計算方式與規劃工具所使用的方式相同。

此計算式可計算出能用來放置租用戶 VM 的可用記憶體總量。 此記憶體容量是供整個 Azure Stack Hub 縮放單位使用。

放置 VM 的可用記憶體 = 主機記憶體總量 - 復原保留 - 執行中租用戶 VM 所使用的記憶體量 - Azure Stack Hub 基礎結構的額外負荷 1

  • 主機記憶體總計 = 所有節點記憶體的總和
  • 復原保留 = H + R * ((N-1) * H) + V * (N-2)
  • 租用戶 VM 所使用的記憶體 = 租用戶工作負載所耗用的實際記憶體,不相依於 HA 設定
  • 「Azure Stack Hub 基礎結構額外負荷」= 268 GB + (4 GB x N)

其中:

  • H = 單一伺服器記憶體的大小
  • N = 縮放單位大小 (伺服器數目)
  • R = 用於 OS 額外負荷的作業系統保留量,在此公式中為 .152
  • V = 縮放單位中最大的 HA VM

1 Azure Stack Hub 基礎結構額外負荷 = 268 GB + (4 GB x 節點數目)。 大約會使用 31 部 VM 來託管 Azure Stack Hub 基礎結構,總計耗用約 268 GB + (4 GB x 節點數目) 的記憶體和 146 顆虛擬核心。 使用這個數量 VM 的根本原因,是為了因應所需的服務區隔,以滿足安全性、延展性、維護及修補上的需求。 此內部服務結構可在未來研發出新的基礎結構服務時引入該服務。

2 用於額外負荷的作業系統保留量 = 15% (.15) 的節點記憶體。 作業系統保留值為估計值,會因為伺服器的實體記憶體容量和一般作業系統的額外負荷而異。

值 V (縮放單位中最大的 HA VM) 會隨最大的租用戶 VM 記憶體大小動態改變。 例如,最大的 HA VM 值至少為 12 GB (用於基礎結構 VM) 或 112 GB,或者 Azure Stack Hub 解決方案中任何其他支援的 VM 記憶體大小。 變更 Azure Stack Hub 網狀架構上最大的 VM,會導致復原保留量增加,也會使 VM 本身的記憶體增加。 請記住,GPU VM 是在非 HA 模式中執行。

範例計算

我們有小型四個節點的 Azure Stack Hub 部署,每個節點上都有 768 GB RAM。 我們計畫為具有 128 GB RAM (Standard_E16_v3) 的 SQL Server 放置虛擬機器。 VM 放置的可用記憶體為何?

  • 主機記憶體總量 = 所有節點記憶體的總和 = 4 * 768 GB = 3072 GB
  • 復原保留 = H + R * ((N-1) * H) + V * (N-2) = 768 + 0.15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 GB
  • 租用戶 VM 所使用的記憶體 = 租用戶工作負載所耗用的實際記憶體,不相依於 HA 設定 = 0 GB
  • 「Azure Stack Hub 基礎結構額外負荷」= 268 GB + (4GB x N) = 268 + (4 * 4) = 284 GB

放置 VM 可用的記憶體 = 主機記憶體總量 - 復原保留 - 執行中租用戶 VM 所使用的記憶體量 - Azure Stack Hub 基礎結構額外負荷

放置 VM 可用的記憶體 = 3072 - 1370 - 0 - 284 = 1418 GB

解除配置的注意事項

當虛擬機器的狀態為已解除配置時,就不會使用記憶體資源。 如此可提供空間,在系統中納入其他虛擬機器。

若之後要再次啟動已解除配置的虛擬機器,會以在系統中納入新虛擬機器的方式分配記憶體使用量或配置,使用可用的記憶體。 若沒有可用的記憶體,則 VM 不會啟動。

目前已部署的大型 VM 顯示的配置記憶體為 112 GB,但這些 VM 的記憶體需求約為 2-3 GB。

名稱 已指派的記憶體 (GB) 記憶體需求 (GB) ComputerName
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508 112 2.2392578125 LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4 112 2.2392578125 LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84 112 2.2392578125 LISSA01P-NODE04

使用公式 復原保留 = H + R * ((N-1) * H) + V * (N-2),有三種方法可以解除 VM 放置的記憶體配置:

  • 減少最大 VM 的大小
  • 增加節點的記憶體
  • 新增節點

減少最大 VM 的大小

將最大 VM 的大小縮減至戳記中第二小 VM 的大小 (24 GB),會減少復原保留的大小。

縮減 VM 大小

復原保留 = 384 + 172.8 + 48 = 604.8 GB

記憶體總計 Infra GB 租用戶 GB 復原保留 保留的記憶體總計 可供放置的 GB 總計
1536 GB 258 GB 329.25 GB 604.8 GB 258 + 329.25 + 604.8 = 1168 GB ~344 GB

新增節點

新增 Azure Stack Hub 節點會將記憶體平均分配給兩個節點,藉此解除記憶體配置。

新增節點

復原保留 = 384 + (0.15) ((5)*384) + 112 * (3) = 1008 GB

記憶體總數 Infra GB 租用戶 GB 復原保留 保留的記憶體總計 可供放置的 GB 總計
1536 GB 258 GB 329.25 GB 604.8 GB 258 + 329.25 + 604.8 = 1168 GB ~ 344 GB

將每個節點的記憶體增加到 512 GB

增加每個節點的記憶體會增加可用的記憶體總數。

增加節點的大小

復原保留 = 512 + 230.4 + 224 = 966.4 GB

記憶體總數 Infra GB 租用戶 GB 復原保留 保留的記憶體總計 可供放置的 GB 總計
2048 (4*512) GB 258 GB 505.75 GB 966.4 GB 1730.15 GB ~ 318 GB

常見問題集

:我的租用戶部署了新的 VM,系統管理員入口網站上的容量圖表要多久才會顯示剩餘容量?

:[容量] 刀鋒視窗每 15 分鐘會重新整理一次,這一點要考慮進去。

:如何查看可用的核心和指派的核心?

:在 PowerShell 執行 test-azurestack -include AzsVmPlacement -debug 中,會產生如下輸出:

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

:Azure Stack Hub 上部署的 VM 數目並未變更,但容量卻有變動。 為什麼?

:VM 放置的可用記憶體相依於多個因素,其中之一就是主機的 OS 保留。 此值相依於主機上執行中的不同 Hyper-V 程序所使用的記憶體,而這個數量不是固定值。

:租用戶 VM 必須處於何種狀態才能取用記憶體?

:除了正在執行的 VM 以外,只要登陸網狀架構的 VM 都會取用記憶體。 這表示處在「建立中」或「失敗」狀態的 VM 會耗用記憶體。 從客體內關機而非從入口網站/powershell/cli 停止解除配置項目的 VM,也會耗用記憶體。

:我有一個四主機的 Azure Stack Hub。 租用戶中有 3 個 VM,各會取用 56 GB 的 RAM (D5_v2)。 其中一個 VM 的大小調整為 112 GB RAM (D14_v2),而且儀表板上的可用記憶體報告會導致 [容量] 刀鋒視窗上產生 168 GB 的使用量高峰。 後續將另外兩個 D5_v2 VM 的大小調整為 D14_v2 時,各自只導致增加 56 GB 的 RAM。 為何會如此?

:可用記憶體是 Azure Stack Hub 所保持的復原保留函式。 復原保留量是 Azure Stack Hub 戳記上最大 VM 大小的函式。 一開始,戳記上的最大 VM 是 56 GB 記憶體。 當 VM 調整大小後,戳記上的最大 VM 就變成 112 GB 記憶體,這不只會增加該租用戶 VM 所使用的記憶體,也會增加復原保留量。 此變更已導致增加 56 GB (租用戶 VM 記憶體從 56 GB 增加至 112 GB),以及增加 112 GB 復原保留記憶體。 後續 VM 重新調整大小時,最大的 VM 大小仍維持為 112 GB VM,因此沒有增加任何復原保留量。 記憶體取用量增加的部分,只增加在租用戶 VM 記憶體 (56 GB)。

注意

因為只能設定公用 VIP 的大小,網路方面的容量規劃需求很少。 如需如何將更多公用 IP 位址新增到 Azure Stack Hub 的相關資訊,請參閱新增公用 IP 位址

下一步

了解 Azure Stack Hub 儲存體