Azure Stack Hub のコンピューティング能力

[アーティクル]
03/29/2024

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 を配置します。

Azure Stack Hub では、VM を配置する際に次の 2 つの点が考慮されます。 1 つ目は、その VM の種類に十分なメモリがホスト上にあるかどうかです。 2 つ目は、VM が可用性セットの一部であるか、仮想マシンスケールセットであるかです。

Azure Stack Hub 内でマルチ VM による運用ワークロードの高可用性を実現するために、仮想マシン (VM) は、複数の障害ドメインに分散される可用性セット内に配置されます。可用性セット内の障害ドメインは、スケールユニット内の 1 つのノードとして定義されます。 Azure Stack Hub では、Azure との一貫性がある最大 3 つの障害ドメインを持つ可用性セットを用意することをサポートしています。可用性セットに配置された VM は、複数の障害ドメイン (Azure Stack Hub ノード) にできる限り均等に分散させることによって、互いに物理的に分離されます。ハードウェア障害が発生した場合、障害が発生した障害ドメインの VM は、他の障害ドメインで再起動されます。可能であれば、これらは同じ可用性セット内の、他の VM とは別の障害ドメインに保持されます。ホストがオンラインに戻ると、高可用性を維持するために VM の再配置が行われます。

仮想マシンスケールセットは、バックエンド上で可用性セットを使用し、各仮想マシンスケールセットインスタンスが異なる障害ドメインに配置されていることを確認します。つまり、これらは別々の Azure Stack Hub インフラストラクチャノードを使用します。たとえば、4 ノードの Azure Stack Hub システムの場合、3 つのインスタンスの仮想マシンスケールセットの作成時に 4 ノードの容量が不足しているために 3 つの別々の Azure Stack Hub ノードに 3 つの仮想マシンスケールセットインスタンスを配置できない状況になる場合があります。さらに、Azure Stack Hub ノードは、配置を試行する前に、さまざまなレベルでいっぱいになることがあります。

Azure Stack Hub ではメモリがオーバーコミットされません。ただし、物理コア数のオーバーコミットは許可されています。

配置アルゴリズムでは、既存の仮想対物理コアのオーバープロビジョニングの比率を係数とみなさないため、各ホストの比率が異なる可能性があります。 Microsoft では、ワークロードやサービスレベルの要件に差異があるため、仮想対物理コアの比率に対するガイダンスは提供していません。

VM の合計数に関する考慮事項

作成できる VM の総数には制限があります。 Azure Stack Hub 上の VM の最大数は 700 個で、スケールユニットノードごとに 60 個です。たとえば、8 サーバーの Azure Stack Hub の場合、VM 数は 480 個 (8 * 60) に制限されます。 12 から 16 サーバーの Azure Stack Hub ソリューションの場合は、700 個に制限されます。この制限は、オペレーターがスタンプで維持したい回復性の予約や仮想と物理の CPU の比率など、コンピューティング容量に関するすべての考慮事項を念頭に置いて作成されています。

VM のスケールの上限に達すると、結果として次のエラーコードが返されます: VMsPerScaleUnitLimitExceeded、VMsPerScaleUnitNodeLimitExceeded。

Note

700 の VM (最大) のうちの一部は、Azure Stack Hub インフラストラクチャ VM 用に予約されています。詳細については、「Azure Stack Hub キャパシティプランニングツール」を参照してください。

VM のバッチデプロイに関する考慮事項

2002 以前のリリースでは、700 のスケールに到達するまで確実に VM をデプロイしようとすると、5 分間のバッチ間隔ではバッチあたり 2 から 5 の VM しかデプロイできませんでした。 Azure Stack Hub の 2005 バージョン以降では、バッチデプロイの間に 5 分間の間隔を空けた場合、バッチサイズ 40 で VM を確実にプロビジョニングすることができます。開始、停止、割り当て解除、更新の各操作は、バッチサイズ 30 で、各バッチの間隔を 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 ソフトウェアの修正プログラムの適用と更新中の 2 つ目の例。物理ホストを再起動する必要がある場合、そのホスト上で実行されている 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 でメモリが消費されます。しかし、portal/powershell/cli から停止 (割り当て解除) オプションを使用して割り当て解除された VM では、Azure Stack Hub のメモリは消費されません。
付加価値リソースプロバイダー (RP): SQL、MySQL、App Service などのアドオン RP 用にデプロイされた VM。

ポータルでメモリ消費量を把握する最善の方法は、Azure Stack Hub Capacity Planner を使用して、さまざまなワークロードの影響を確認することです。次の計算は、Planner によって使用されているものと同じです。

この計算では、テナントの VM 配置で使用できる、利用可能なメモリの合計が算出されます。このメモリ容量は、Azure Stack Hub スケールユニットの全体に対するものです。

VM の配置に利用可能なメモリ = ホストの合計メモリ - 回復性のための予約 - 実行中のテナント VM によって使用されているメモリ - Azure Stack Hub インフラストラクチャのオーバーヘッド ¹

ホストメモリの合計 = すべてのノードのメモリの合計
回復性のための予約 = H + R * ((N-1) * H) + V * (N-2)
テナント VM によって使われるメモリ = テナントのワークロードによって消費される実際のメモリ。これは、HA の構成に依存しません
Azure Stack Hub インフラストラクチャのオーバーヘッド = 268 GB + (4 GB x N)

各値の説明:

H = 単一サーバーのメモリサイズ

N = スケールユニットのサイズ (サーバーの数)

R = OS オーバーヘッドのためのオペレーティングシステムの予約 (この数式では 0.15)²

V = スケールユニット内の最大 HA VM

¹ Azure Stack Hub インフラストラクチャのオーバーヘッド = 268 GB + (4 GB x ノード数)。約 31 個の VM が Azure Stack Hub のインフラストラクチャをホストするために使用され、合計で約 268 GB + (4 GB x ノード数) のメモリと 146 個の仮想コアが消費されます。この VM の数の論理的根拠は、セキュリティ、スケーラビリティ、サービス提供および修正プログラムの適用に関する要件を満たすために必要なサービス分離を行うことです。この内部サービス構造により、今後、新しいインフラストラクチャサービスが開発されたときに、そのサービスを導入できるようになります。

² オーバーヘッドのためのオペレーティングシステムの予約 = ノードメモリの 15%。オペレーティングシステムの予約値は概算であり、サーバーおよび一般的なオペレーティングシステムのオーバーヘッドの物理メモリ容量によって異なります。

値 V (スケールユニット内の最大 HA VM) は、最大テナント VM メモリサイズに動的に基づきます。たとえば、最大の HA VM 値は、最小の 12 GB (インフラストラクチャ VM を考慮します)、または 112 GB、または Azure Stack Hub ソリューション内でサポートされているその他の VM メモリサイズです。 Azure Stack Hub ファブリック上で最大の HA VM を変更すると、VM 自体のメモリが増加するだけでなく、回復性のための予約も増加します。 GPU VM は非 HA モード内で実行されることに注意してください。

計算の例

小さな 4 ノードの Azure Stack Hub のデプロイがあり、各ノードの RAM は 768 GB です。 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 + (4 GB x N) = 268 + (4 * 4) = 284 GB

VM の配置に利用可能なメモリ = ホストの合計メモリ - 回復性のための予約 - 実行中のテナント VM によって使用されているメモリ - Azure Stack Hub インフラストラクチャのオーバーヘッド

VM の配置に使用できるメモリ = 3072 - 1370 - 0 - 284 = 1418 GB

割り当て解除に関する考慮事項

VM が割り当て解除済みの状態にある場合、メモリリソースは使用されていません。このため、他の VM をシステムに配置できます。

その後、割り当てが解除された VM が再起動されると、メモリの使用量または割り当てはシステムに配置された新しい VM と同じように扱われ、使用可能なメモリが消費されます。使用可能なメモリがない場合、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 配置用のメモリの割り当てを解除する方法は 3 つあります。

最大 VM のサイズを減らす
ノードのメモリを増やす
ノードを追加する

最大 VM のサイズを減らす

最大 VM のサイズを、スタンプ内で次に小さい VM のサイズ (24 GB) に減らすと、回復性のための予約のサイズが減ります。

VM のサイズを減らす

回復性のための予約 = 384 + 172.8 + 48 = 604.8 GB

メモリの合計	インフラストラクチャ GB	テナント GB	回復性のための予約	予約済みのメモリの合計	配置に使用可能な GB の合計
1,536 GB	258 GB	329.25 GB	604.8 GB	258 + 329.25 + 604.8 = 1168 GB	約 344 GB

ノードを追加する

Azure Stack Hub ノードを追加すると、2 つのノード間でメモリが均等に分配され、メモリの割り当てが解除されます。

ノードを追加する

回復性のための予約 = 384 + (0.15) ((5)*384) + 112 * (3) = 1008 GB

メモリの合計	インフラストラクチャ GB	テナント GB	回復性のための予約	予約済みのメモリの合計	配置に使用可能な GB の合計
1,536 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

メモリの合計	インフラストラクチャ GB	テナント GB	回復性のための予約	予約済みのメモリの合計	配置に使用可能な GB の合計
2048 (4*512) GB	258 GB	505.75 GB	966.4 GB	1730.15 GB	約 318 GB

よく寄せられる質問

Q: テナントで新しい VM がデプロイされました。管理者ポータルの容量グラフで残存容量を表示するのにかかる時間はどれくらいですか?

A: 容量ブレードは 15 分ごとに更新されるため、それを考慮してください。

Q: 使用可能なコアと割り当てられたコアを確認するにはどうすればよいですか?

A: 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

Q: Azure Stack Hub にデプロイされている VM の数は変更されていませんが、容量は変動しています。なぜですか?

A: VM の配置で使用できるメモリには複数の依存関係があり、1 つはホスト OS の予約です。この値は、定数値ではない、ホストで実行されている別の Hyper-V プロセスで使用されるメモリに依存します。

Q: メモリを消費する場合、テナント VM はどの状態である必要がありますか?

A: 実行中の VM だけでなく、ファブリック上に配置されているすべての VM もメモリを消費します。つまり、"作成中" または "失敗" 状態の VM では、メモリが消費されます。また、portal/powershell/cli から停止 (割り当て解除) されたものではなく、ゲスト内からシャットダウンされた VM でも、メモリが消費されます。

Q: 4 ホストの Azure Stack Hub があります。テナントには VM が 3 つあり、それぞれ 56 GB の RAM (D5_v2) が消費されています。 VM の 1 つが 112 GB RAM (D14_v2) にサイズ変更されており、ダッシュボードの使用可能なメモリレポートの結果、容量ブレードの使用量が 168 GB に急増しました。その後、他の 2 つの D5_v2 VM を D14_v2 にサイズ変更すると、それぞれ RAM が 56 GB だけ増えました。これはなぜですか?

A: 使用可能なメモリは、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 のサイズが構成可能である場合にのみ、最小要件となります。 Azure Stack Hub にパブリック IP アドレスをさらに追加する方法については、「パブリック IP アドレスの追加」を参照してください。

次のステップ