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

Azure Stack Hub 上でサポートされる仮想マシン (VM) サイズは、Azure 上でサポートされている VM サイズのサブセットです。 Azure では、リソース (サーバーのローカルおよびサービス レベル) の過剰消費を防ぐため、多くのベクターに沿ってリソースの制限を適用します。 テナントの消費量にいくつかの制限を適用しないと、あるテナントでリソースが過剰消費された場合に、別のテナントのエクスペリエンスに影響します。 VM からのネットワーク エグレスの場合、Azure Stack Hub では、Azure の制限と一致する帯域幅の上限が設けられます。 Azure Stack Hub のストレージ リソースの場合、ストレージ IOPS を制限することにより、テナントがストレージ アクセスのために使用するリソースの基本的な過剰消費を防ぎます。

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。

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 スケール ユニット上の物理メモリ容量を示しています。

メモリ使用量は、いくつかのコンポーネントで構成されます。 次のコンポーネントでは、円グラフの使用セクションでメモリを消費します。

• ホスト 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 です。

回復性のための予約 = H + R * ((N-1) * H) + V * (N-2) の数式を使用して、VM 配置用のメモリの割り当てを解除する方法は 3 つあります。

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

最大 VM のサイズを減らす

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

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

ノードを追加する

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

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

各ノードのメモリを 512 GB に増やす

各ノードのメモリを増やすと、使用可能なメモリの合計が増えます。

回復性のための予約 = 512 + 230.4 + 224 = 966.4 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) のみでした。

次のステップ

Azure Stack Hub ストレージについて確認する