Azure Stack Hub のストレージ容量を管理する

[アーティクル]
01/30/2025

この記事では、Azure Stack Hub クラウドオペレーターが Azure Stack Hub デプロイのストレージ容量を監視および管理する方法について説明します。このガイダンスを使用して、ユーザーの VM で使用可能なメモリを理解できます。 Azure Stack Hub ストレージインフラストラクチャは、Azure Stack Hub デプロイの合計ストレージ容量のサブセットをストレージサービスとして割り当てます。ストレージサービスは、デプロイのノードに対応するボリューム上の共有にテナントデータを格納します。

クラウドオペレーターは、使用できるストレージの量が限られています。ストレージの量は、実装するソリューションによって定義されます。このソリューションは、マルチノードソリューションを使用する場合、または Azure Stack Development Kit (ASDK) をインストールするハードウェアによって提供される場合に、OEM ベンダーによって提供されます。

Azure Stack Hub では、追加のスケールユニットノードを追加することで、ストレージ容量の拡張のみがサポートされます。詳細については、Azure Stack Hubでのスケールユニットノードの追加に関するページを参照してください。ノードに物理ディスクを追加しても、ストレージ容量は拡張されません。

使用可能なストレージを監視し、効率的な操作が維持されるようにすることが重要です。ボリュームの残りの空き容量が制限された場合は、共有の容量不足を防ぐために、使用可能な領域を管理することを計画します。

容量を管理するためのオプションは次のとおりです。

容量の取り戻し。
ストレージオブジェクトの移行。

オブジェクトストアボリュームが 100% 使用されている場合、ストレージサービスはそのボリュームに対して機能しなくなります。ボリュームの操作の復元に関するサポートを受ける場合は、Microsoft サポートにお問い合わせください。

ディスク、コンテナー、ボリュームについて

テナントユーザーは、Azure Stack Hub ストレージサービスにディスク、BLOB、テーブル、キューを作成します。これらのテナントデータは、使用可能なストレージの上のボリュームに配置されます。

ディスク

VM は、仮想ディスク上のデータを格納および操作します。各 VM は、Marketplace イメージまたはプライベートイメージから作成された OS ディスクで始まります。 VM は、0 個以上のデータディスクを接続できます。 Azure Stack には、次の 2 種類のディスクが用意されています。

マネージドディスク、VM ディスクに関連付けられているストレージアカウントを管理することで、Azure IaaS VM のディスク管理を簡略化できます。必要なディスクのサイズを指定するだけで、Azure Stack Hub によってディスクが作成および管理されます。詳細については、「マネージドディスクの概要参照してください。

非管理対象ディスク は、Azure Stack ストレージアカウントのストレージコンテナーにページ BLOB として格納される VHD ファイルです。テナントによって作成されたページ BLOB は VM ディスクと呼ばれ、ストレージアカウントのコンテナーに格納されます。アンマネージドディスクは、Azure アンマネージドディスクのみをサポートするサードパーティ製ツールとの互換性が必要な VM にのみ使用することをお勧めします。

テナントへのガイダンスは、VM のパフォーマンスを向上させるために、各ディスクを個別のコンテナーに配置することです。

VM からディスクまたはページ BLOB を保持する各コンテナーは、ディスクを所有する VM に接続されたコンテナーと見なされます。
VM のディスクを保持していないコンテナーは、空きコンテナーと見なされます。

接続されているコンテナーの領域を解放するオプションは制限されています。詳細については、「アンマネージドディスクを配布する」を参照してください。

重要

管理を容易にするために、VM でマネージドディスクのみを使用することをお勧めします。マネージドディスクを使用する前に、ストレージアカウントとコンテナーを準備する必要はありません。マネージドディスクは、非管理対象ディスクと比較して同等以上の機能とパフォーマンスを提供します。アンマネージドディスクを使用する利点はなく、下位互換性のためにのみ提供されます。

マネージドディスクは、ストレージインフラストラクチャの配置を改善するために最適化され、管理オーバーヘッドが大幅に削減されます。ただし、マネージドディスクはシンプロビジョニングされており、作成時に最終的な使用が予測できないため、ディスクの配置が不均衡になると、ボリュームが過剰に使用される可能性があります。オペレーターは、ストレージ容量の使用状況を監視し、このような問題を回避する責任があります。

ARM テンプレートを使用して新しい仮想マシンをプロビジョニングするユーザーについては、「VM マネージドディスクテンプレートを使用する」を参照して、マネージドディスクを使用するようにテンプレートを変更する方法を理解してください。

VM ディスクは、記憶域インフラストラクチャにスパースファイルとして格納されます。ディスクには、ディスクの作成時にユーザーが要求するプロビジョニング済みサイズがあります。ただし、ディスクに書き込まれる 0 以外のページのみが、基になるストレージインフラストラクチャの領域を占有します。

例: ストレージボリュームのスパースディスク。

ディスクは、多くの場合、プラットフォームイメージ、マネージドイメージ、スナップショット、またはその他のディスクからコピーすることによって作成され、スナップショットはディスクから取得されます。ストレージ容量の使用量を増やし、コピー操作時間を短縮するために、システムは ReFS で BLOB の複製を使用します。 BLOB の複製は、ファイル間の完全なバイト単位のコピーではなく、低コストのメタデータ操作です。ソースファイルとターゲットファイルは、同じエクステントを共有できます。同じデータが複数回物理的に格納されないため、ストレージ容量が向上します。

例: 記憶域ボリュームのエクステントを共有します。

容量の使用量は、ディスクが書き込まれるときにのみ増加し、同じデータが削減されます。イメージまたはディスクが削除されると、同じデータを保持し、領域を占有するディスクまたはスナップショットが作成される可能性があるため、領域がすぐに解放されない可能性があります。関連するすべてのエンティティが削除されると、領域が使用可能になります。

例: ディスク削除後のエクステント。

BLOB とコンテナー

テナントユーザーは、大量の非構造化データを Azure BLOB に格納します。 Azure Stack Hub では、ブロック BLOB、追加 BLOB、ページ BLOBの 3 種類の BLOB がサポートされています。さまざまな種類の BLOB の理解を深めるために、「ブロック BLOB、追加 BLOB、ページ BLOBについて」を参照してください。

テナントユーザーは、BLOB データの格納に使用されるコンテナーを作成します。ユーザーは BLOB を配置するコンテナーを決定しますが、ストレージサービスはアルゴリズムを使用して、コンテナーを配置するボリュームを決定します。アルゴリズムは、通常、使用可能な領域が最も多いボリュームを選択します。

BLOB がコンテナーに配置されると、BLOB の容量を増やすことができます。新しい BLOB を追加し、既存の BLOB を増やすと、コンテナーを保持するボリューム内の使用可能な領域が縮小されます。

コンテナーは 1 つのボリュームに限定されません。コンテナー内の結合された BLOB データが増加して使用可能な領域の 80% 以上を使用すると、コンテナーは "オーバーフロー" モードに入ります。オーバーフローモードでは、そのコンテナーに作成された新しい BLOB は、十分な領域を持つ別のボリュームに割り当てられます。時間の経過と同時に、オーバーフローモードのコンテナーには、複数のボリュームに分散される BLOB を含めることができます。

ボリューム内の使用可能な領域の 90% (および 95%) が使用されると、システム Azure Stack Hub 管理者ポータルでアラートが生成されます。クラウドオペレーターは、使用可能なストレージ容量を確認し、コンテンツの再調整を計画する必要があります。ディスクが 100% 使用され、追加のアラートが発生しない場合、ストレージサービスは動作を停止します。

ボリューム

ストレージサービス、使用可能なストレージを、システムデータとテナントデータを保持するために割り当てられた個別のボリュームにパーティション分割されます。ボリュームは記憶域プール内のドライブを組み合わせて、記憶域スペースダイレクトのフォールトトレランス、スケーラビリティ、およびパフォーマンスの利点をもたらします。 Azure Stack Hub のボリュームの詳細については、「Azure Stack Hubのストレージインフラストラクチャ管理する」を参照してください。

オブジェクトストアボリュームはテナントデータを保持します。テナントデータには、ページ BLOB、ブロック BLOB、追加 BLOB、テーブル、キュー、データベース、および関連するメタデータストアが含まれます。オブジェクトストアボリュームの数は、Azure Stack Hub デプロイ内のノードの数と同じです。

4 ノードのデプロイでは、4 つのオブジェクトストアボリュームがあります。マルチノード展開では、ノードが削除されたり、誤動作したりしても、ボリュームの数は減りません。
ASDK を使用する場合、1 つの共有がある単一のボリュームが存在します。

オブジェクトストアボリュームは、ストレージサービスを排他的に使用するためのボリュームです。ボリューム上のファイルを直接変更、追加、または削除することはできません。これらのボリュームに格納されているファイルでは、ストレージサービスのみが機能する必要があります。

ストレージオブジェクト (BLOB など) は 1 つのボリューム内に個別に含まれているため、各オブジェクトの最大サイズはボリュームのサイズを超えることはできません。新しいオブジェクトの最大サイズは、その新しいオブジェクトが作成されるときに未使用領域としてボリュームに残っている容量によって異なります。

オブジェクトストアボリュームの空き領域が少なく、領域を再利用アクションが成功または使用できない場合、Azure Stack Hub クラウドオペレーターは、ストレージオブジェクトをあるボリュームから別のボリュームに移行できます。

テナントユーザーが Azure Stack Hub で BLOB ストレージを利用する方法については、Azure Stack Hub ストレージサービスを参照してください。

ストレージの監視

Azure PowerShell または管理者ポータルを使用して共有を監視し、空き領域が制限されている場合を理解できるようにします。ポータルを使用すると、領域が不足している共有に関するアラートが表示されます。

PowerShell を使用する

クラウドオペレーターは、PowerShell Get-AzsStorageShare コマンドレットを使用して共有のストレージ容量を監視できます。このコマンドレットは、各共有の合計、割り当て済み、および空き領域をバイト単位で返します。

例: 共有の空き領域を返します。

容量の合計: 共有で使用可能な合計領域 (バイト単位)。この領域は、ストレージサービスによって管理されるデータとメタデータに使用されます。
使用容量: テナントデータと関連するメタデータを格納するファイルのすべてのエクステントによって使用されるデータの量 (バイト単位)。

管理者ポータルを使用する

クラウドオペレーターは、管理者ポータルを使用して、すべての共有のストレージ容量を表示できます。

https://adminportal.local.azurestack.externalで管理者ポータルにサインインします。
ストレージファイル共有すべてのサービスを選択してファイル共有の一覧を開き、使用状況情報を表示できます。
- 合計: 共有で使用可能な合計領域 (バイト単位)。この領域は、ストレージサービスによって管理されるデータとメタデータに使用されます。
- 使用: テナントデータと関連するメタデータを格納するファイルのすべてのエクステントによって使用されるデータの量 (バイト単位)。

Azure PowerShell または管理者ポータルを使用して、プロビジョニング済みおよび使用済み容量を監視し、システムの継続的な正常な運用を確保するために移行を計画します。

ボリューム容量を監視するための 3 つのツールがあります。

現在のボリューム容量のポータルとの PowerShell。
ストレージ領域のアラート。
ボリューム容量メトリック。

このセクションでは、これらのツールを使用してシステムの容量を監視する方法について説明します。

PowerShell を使用する

クラウドオペレーターは、PowerShell Get-AzsVolume コマンドレットを使用して、ボリュームのストレージ容量を監視できます。このコマンドレットは、各ボリュームの合計領域と空き領域をギガバイト (GB) 単位で返します。

例: ボリュームの空き領域を返します。

容量の合計: 共有上の使用可能な領域の合計 (GB 単位)。この領域は、ストレージサービスによって管理されるデータとメタデータに使用されます。
残りの容量: テナントデータと関連するメタデータを格納するための空き領域の量 (GB 単位)。

管理者ポータルを使用する

クラウドオペレーターは、管理者ポータルを使用して、すべてのボリュームのストレージ容量を表示できます。

(https://adminportal.local.azurestack.external) で Azure Stack Hub 管理者ポータルにサインインします。
ストレージボリュームすべてのサービスを選択して、使用状況情報を表示できるボリュームの一覧を開きます。
- 合計: ボリュームで使用可能な合計領域。この領域は、ストレージサービスによって管理されるデータとメタデータに使用されます。
- 使用済み: テナントデータとそれに関連付けられているメタデータを格納するファイルのすべてのエクステントで使用されるデータの量。

記憶域スペースのアラート

管理者ポータルを使用すると、領域が不足しているボリュームに関するアラートが表示されます。

重要

クラウドオペレーターは、共有が完全に使用されないようにする必要があります。共有が 100% 使用されると、ストレージサービスはその共有に対して機能しなくなります。 100% 利用されている共有に対する空き領域の回復と復元操作については、Microsoft サポートにお問い合わせください。

警告: ファイル共有が 90% を超えると、管理者ポータルで警告アラートが表示されます。
重要な: ファイル共有が 95% を超えると、管理者ポータルに重大なアラートが表示されます。
詳細の表示: 管理者ポータルで、アラートの詳細を開いて軽減策のオプションを表示できます。

のスクリーンショット

ボリューム容量メトリック

ボリューム容量メトリックでは、さまざまな種類のオブジェクトに対してプロビジョニングされた容量と使用容量に関する詳細情報が提供されます。メトリックデータは 30 日間保持されます。バックグラウンド監視サービスは、ボリューム容量メトリックデータを 1 時間ごとに更新します。

容量メトリックレポートを事前に確認して、ボリュームのリソース使用量を理解する必要があります。空き領域に対応するアクションを決定するために、クラウドオペレーターは、ボリュームがいっぱいになったときにリソースの種類の分布を分析できます。また、ディスクのプロビジョニング済みサイズがボリュームの過剰プロビジョニングを示している場合に、ボリュームが過剰に使用されないようにすることもできます。

Azure Monitor には、ボリューム容量の使用状況を示す次のメトリックが用意されています。

ボリュームの合計容量 には、ボリュームの合計ストレージ容量が表示されます。
ボリュームの残存容量 は、ボリュームの残りのストレージ容量を示します。
ボリューム VM ディスクの使用容量 は、VM ディスク関連オブジェクト (ページ BLOB、マネージドディスク/スナップショット、マネージドイメージ、プラットフォームイメージを含む) によって占有されている合計スペースを示します。 VM ディスクの基になる VHD ファイルは、イメージ、スナップショット、またはその他のディスクと同じエクステント (ディスクのを参照) を共有できます。この数は、個々のすべての VM ディスク関連オブジェクトの使用容量の合計よりも小さくすることができます。
ボリュームその他の使用容量 は、ブロック BLOB、追加 BLOB、テーブル、キュー、BLOB メタデータなど、ディスク以外のオブジェクトの合計使用サイズです。
ボリューム VM ディスクプロビジョニング容量 は、ページ BLOB とマネージドディスク/スナップショットのプロビジョニングされた合計サイズです。このサイズは、特定のボリューム上のすべてのマネージドディスクとページ BLOB を拡張できる合計ディスク容量の最大値です。

例: ボリューム容量メトリック。

Azure Monitor でボリューム容量メトリックを表示するには:

Azure PowerShell がインストールされ、構成されていることを確認します。 PowerShell 環境を構成する手順については、「Azure Stack Hub用の PowerShell のインストール」を参照してください。 Azure Stack Hub にサインインするには、「オペレーター環境を構成し、Azure Stack Hubにサインインする」を参照してください。
GitHub リポジトリから Azure Stack Hub ツールダウンロードします。詳細な手順については、「GitHubから Azure Stack Hub ツールをダウンロードする」を参照してください。
CapacityManagementで次のコマンド実行して、Capacity Dashboard JSON ファイルを生成します。
```
.\CapacityManagement\DashboardGenerator\Create-AzSStorageDashboard.ps1 -capacityOnly $true -volumeType object
```
このコマンドは、DashboardGeneratorのフォルダー内で、DashboardVolumeObjStore で始まる json ファイルを作成します。
(https://adminportal.local.azurestack.external) で Azure Stack Hub 管理者ポータルにサインインします。
ダッシュボードで[のアップロード]選択し、手順 3 で生成された JSON ファイルを選択します。
JSON がアップロードされると、新しい容量ダッシュボードが表示されます。各ボリュームには、ダッシュボードに対応するグラフがあります。グラフの数は、ボリュームの数と等しくなります。
いずれかのボリュームをクリックすると、詳細なグラフで特定のボリュームの 5 つの容量メトリックを確認できます。

ボリュームの使用パターン

ボリューム容量メトリックを確認することで、クラウドオペレーターは、ボリュームの容量の使用量と、領域の大部分を占めるリソースの種類を把握します。領域の使用パターンは次の型にグループ化され、演算子は型ごとに異なるアクションを実行できます。

例: ボリュームの使用パターン。

プロビジョニング不足の予備容量: ボリュームに十分な空き容量があり、このボリューム上にあるすべてのディスクのプロビジョニング済み容量の合計は、使用可能な合計容量よりも小さくなります。ボリュームは、ディスクとその他のオブジェクト (ブロック/追加 BLOB、テーブル、キュー) の両方を含む、より多くのストレージオブジェクトで使用できます。ボリュームを操作するためにアクションを実行する必要はありません。

過剰プロビジョニング、予備容量: ボリュームの残りの容量は高いですが、VM ディスクのプロビジョニングされた容量は既にボリュームの合計容量を超えています。このボリュームには、さらに多くのストレージオブジェクトを格納するスペースが残っています。ただし、このボリュームにある VM ディスク内のデータが格納される可能性があります。このボリュームの使用状況の傾向を注意深く監視する必要があります。過剰プロビジョニング 低容量パターンに変更された場合は、領域を解放するためのアクションを実行する必要がある場合があります。

過剰プロビジョニング、低容量: ボリュームの残りの容量が少なくなっています。また、VM ディスクのプロビジョニング容量と使用容量の両方が高くなっています。

残りの容量が少ない場合は、ボリュームが完全な使用量に達していることが示されます。オペレーターは、ボリュームが 100% 使用されるのを防ぐために、領域を解放するために直ちにアクションを実行する必要があります。これにより、ストレージサービスがブロックされます。 VM ディスクの使用率が高い場合、ボリューム使用量の大部分が VM ディスクであることが示されます。ディスクを移行して、ディスクをフルボリュームから他の使用可能なボリュームに空き領域に移動するを参照してください。

プロビジョニング不足、容量不足、高いブロック BLOB: ボリュームの残り容量が少なく、VM ディスクのプロビジョニング容量と使用容量の両方が低いものの、他の使用容量が高くなっています。

ボリュームが完全に使用される恐れがあるため、オペレーターは直ちに空き領域を確保するための措置を講じる必要があります。その他の使用率が高い容量は、ほとんどのボリューム容量がブロック/追加 BLOB またはテーブル/キューによって使用されていることを示します。ボリュームの使用可能な容量が 20%未満の場合、コンテナーオーバーフローが有効になり、このほぼ完全なボリュームに新しい BLOB オブジェクトが配置されません。ただし、既存の BLOB は引き続き増加する可能性があります。増え続ける BLOB が容量を使い過ぎないようにするには、Microsoft サポートに問い合わせて、特定のボリューム上の領域を占有しているコンテナーにクエリを実行し、領域を解放するためにテナントがそれらのコンテナーのクリーンアップを行う必要があるかどうかを判断できます。

過剰にプロビジョニング、低用量、高ブロック BLOB: ボリュームの残りの容量が少なく、ディスクの使用済み/プロビジョニング済み容量と他の使用済み容量の両方が高くなっています。このボリュームでは、ディスクやその他のストレージオブジェクトによる領域の使用量が多くなります。ボリュームが完全に満杯にならないように、領域を解放する必要があります。ディスクを完全なボリュームから他の使用可能なボリュームに移動するには、「ディスクを移行する」の手順に従うことをお勧めします。また、Microsoft サポートに問い合わせて、特定のボリューム上の領域を占有しているコンテナーに対してクエリを実行し、領域を解放するためにテナントがそれらのコンテナーのクリーンアップを行う必要があるかどうかを判断することもできます。

使用可能な領域を管理する

ボリューム上の領域を解放する必要がある場合は、最初に最も低い侵入方法を使用します。たとえば、マネージドディスクの移行を選択する前に、領域を再利用してみてください。

キャパシティの回復

削除されたテナントアカウントによって使用される容量を回収できます。この容量は、データ保持期間に達すると自動的に回収されるか、すぐに回収できます。

詳細については、「Azure Stack Hub ストレージアカウントの管理」の「容量の回収」セクションを参照してください。

ボリューム間でコンテナーを移行する

テナントの使用パターンにより、一部のテナント共有では他のテナントよりも多くの領域が使用されます。これにより、一部の共有は、比較的使用されていない他の共有よりも前に領域が不足する可能性があります。

一部の BLOB コンテナーを別の共有に手動で移行することで、過剰に使用された共有の領域を解放できます。複数の小さなコンテナーを、それらすべてを保持する容量を持つ 1 つの共有に移行できます。移行を使用して、"空の" コンテナーを移動できます。空きコンテナーは、VM のディスクを含まないコンテナーです。

移行により、コンテナーのすべての BLOB が新しい共有に統合されます。

コンテナーがオーバーフローモードになり、BLOB を他のボリュームに配置する場合、新しい共有には、オーバーフローした BLOB を含め、移行するコンテナーに属するすべての BLOB を保持するのに十分な容量が必要です。
PowerShell コマンドレット Get-AzsStorageContainer は、コンテナーの初期ボリュームで使用されている領域のみを識別します。コマンドレットは、追加のボリュームにオーバーフローされた BLOB が使用する領域を特定しません。そのため、コンテナーのフルサイズは明らかでない可能性があります。新しい共有上のコンテナーを統合すると、その新しい共有がオーバーフロー状態に送信され、そこでデータが追加の共有に配置される可能性があります。その結果、株式の再調整が必要になる場合があります。
特定のリソースグループに対するアクセス許可がなく、PowerShell を使用してオーバーフローデータの追加ボリュームのクエリを実行できない場合は、それらのリソースグループとコンテナーの所有者と協力して、移行する前に移行するデータの総量を把握してください。

重要

コンテナーの BLOB の移行は、PowerShell を使用する必要があるオフライン操作です。移行が完了するまで、移行するコンテナーのすべての BLOB はオフラインのままであり、使用できません。また、進行中のすべての移行が完了するまで、Azure Stack Hub のアップグレードは避ける必要があります。

PowerShell を使用してコンテナーを移行する

Azure PowerShell がインストールされており、構成されていることを確認します。詳細については、「Azure PowerShellを使用した Azure リソースの管理」を参照してください。
コンテナーを調べて、移行する予定の共有上のデータを理解します。ボリューム内の移行に最適な候補コンテナーを特定するには、Get-AzsStorageContainer コマンドレットを使用します。
```
$farm_name = (Get-AzsStorageFarm)[0].name
$shares = Get-AzsStorageShare -FarmName $farm_name
$containers = Get-AzsStorageContainer -ShareName $shares[0].ShareName -FarmName $farm_name
```
次に、$containersを調べます。
```
$containers
```
移行するコンテナーを保持するための最適な宛先共有を特定します。
```
$destinationshare = ($shares | Sort-Object FreeCapacity -Descending)[0]
```
次に、$destinationsharesを調べます。
```
$destinationshares
```
を共有する例: $destination
コンテナーの移行を開始します。移行は非同期です。最初の移行が完了する前に別のコンテナーの移行を開始する場合は、ジョブ ID を使用して各コンテナーの状態を追跡します。
```
$jobId = Start-AzsStorageContainerMigration -StorageAccountName $containers[0].Accountname -ContainerName $containers[0].Containername -ShareName $containers[0].Sharename -DestinationShareUncPath $destinationshares[0].UncPath -FarmName $farm_name
```
次に、$jobIdを調べます。次の例では、調べたいジョブ ID に <job_id> を置き換えてください。
```
$jobId <job_id>
```
ジョブ ID を使用して、移行ジョブの状態を確認します。コンテナーの移行が完了すると、MigrationStatus が Completeに設定されます。
```
Get-AzsStorageContainerMigrationStatus -JobId $jobId -FarmName $farm_name
```
実行中の移行ジョブを取り消すことができます。取り消された移行ジョブは非同期的に処理されます。 $jobidを使用してキャンセルを追跡できます。
```
Stop-AzsStorageContainerMigration -JobId $jobId -FarmName $farm_name
```
移行の状態が [キャンセル済み]になるまで、手順 6 のコマンドをもう一度実行できます。

VM ディスクの移動

領域を管理するための最も極端な方法は、VM ディスクの移動です。接続されているコンテナー (VM ディスクを含むコンテナー) の移動は複雑であるため、この操作を行うには Microsoft サポートにお問い合わせください。

ボリューム間でマネージドディスクを移行する

テナントの使用パターンにより、一部のテナントボリュームでは他のボリュームよりも多くの領域が使用されます。その結果、比較的使用されていないボリュームよりも前に領域が不足する可能性があります。

一部のマネージドディスクを別のボリュームに手動で移行することで、過剰に使用されたボリュームの領域を解放できます。複数のマネージドディスクを、すべてを保持する容量を持つ 1 つのボリュームに移行できます。移行を使用して、マネージドディスク オフライン 移動します。オフラインマネージドディスクは、VM に接続されていないディスクです。

重要

マネージドディスクの移行は、PowerShell を使用する必要があるオフライン操作です。移行ジョブを開始する前に、候補ディスクの所有者 VM の割り当てを解除するか、移行の候補ディスクを所有者 VM からデタッチする必要があります (移行ジョブが完了したら、VM を再割り当てするか、ディスクを再アタッチできます)。移行が完了するまで、移行するすべてのマネージドディスクは予約済みまたはオフライン状態のままであり、使用できません。そうしないと、移行ジョブは中止され、すべての未移行ディスクは元のボリュームに残ります。また、進行中のすべての移行が完了するまで、Azure Stack Hub のアップグレードは避ける必要があります。

PowerShell を使用してマネージドディスクを移行するには

Azure PowerShell がインストールされ、構成されていることを確認します。 PowerShell 環境を構成する手順については、「Azure Stack Hub用の PowerShell のインストール」を参照してください。 Azure Stack Hub にサインインするには、「オペレーター環境を構成し、Azure Stack Hubにサインインする」を参照してください。

マネージドディスクを調べて、移行する予定のボリューム上のディスクを理解します。ボリューム内の移行に最適な候補ディスクを特定するには、Get-AzsDisk コマンドレットを使用します。

$ScaleUnit = (Get-AzsScaleUnit)[0]
$StorageSubSystem = (Get-AzsStorageSubSystem -ScaleUnit $ScaleUnit.Name)[0]
$Volumes = (Get-AzsVolume -ScaleUnit $ScaleUnit.Name -StorageSubSystem $StorageSubSystem.Name | Where-Object {$_.VolumeLabel -Like "ObjStore_*"})
$SourceVolume  = ($Volumes | Sort-Object RemainingCapacityGB)[0]
$VolumeName = $SourceVolume.Name.Split("/")[2]
$VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
$MigrationSource = "\\SU1FileServer."+$VolumeName+"\SU1_"+$SourceVolume.VolumeLabel
$Disks = Get-AzsDisk -Status OfflineMigration -SharePath $MigrationSource | Select-Object -First 10

次に、$Disksを調べます。

$Disks

例: $Disks

移行するディスクを保持するのに最適な宛先ボリュームを特定します。

$DestinationVolume  = ($Volumes | Sort-Object RemainingCapacityGB -Descending)[0]
$VolumeName = $DestinationVolume.Name.Split("/")[2]
$VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
$MigrationTarget = "\\SU1FileServer."+$VolumeName+"\SU1_"+$DestinationVolume.VolumeLabel

マネージドディスクの移行を開始します。移行は非同期です。最初の移行が完了する前に他のディスクの移行を開始する場合は、ジョブ名を使用して各ディスクの状態を追跡します。
```
$jobName = "MigratingDisk"
Start-AzsDiskMigrationJob -Disks $Disks -TargetShare $MigrationTarget -Name $jobName
```
ジョブ名を使用して、移行ジョブの状態を確認します。ディスクの移行が完了すると、MigrationStatus が Completeに設定されます。
```
$job = Get-AzsDiskMigrationJob -Name $jobName
```
1 つの移行ジョブで複数のマネージドディスクを移行する場合は、ジョブのサブタスクを確認することもできます。
```
$job.Subtask
```
実行中の移行ジョブを取り消すことができます。取り消された移行ジョブは非同期的に処理されます。ジョブ名を使用して、移行ジョブのキャンセルを追跡できます。ステータスが キャンセル済みと確認されるまでです。
```
Stop-AzsDiskMigrationJob -Name $jobName
```

アンマネージドディスクを配布する

領域を管理するための最も極端な方法には、アンマネージドディスクの移動が含まれます。テナントが非管理対象ディスクを 1 つのコンテナーに追加した場合、コンテナーの合計使用容量は、コンテナーがオーバーフローモードに入る前に、コンテナーを保持するボリュームの使用可能な容量を超えて増加する可能性があります。 1 つのコンテナーでボリュームの領域が使い果たされないように、テナントは、1 つのコンテナーの既存のアンマネージドディスクを別のコンテナーに分散できます。接続されたコンテナー (VM ディスクを含むコンテナー) の配布は複雑であるため、この操作を行うには Microsoft サポートにお問い合わせください。

VM で使用可能なメモリ

Azure Stack Hub は、コンピューティングとストレージのハイパーコンバージドクラスターとして構築されています。この収束により、スケールユニットと呼ばれる、ハードウェアの共有が可能になります。 Azure Stack Hub では、スケールユニットによってリソースの可用性とスケーラビリティが提供されます。スケールユニットは、ホストまたはノードと呼ばれる一連の Azure Stack Hub サーバーで構成されます。インフラストラクチャソフトウェアは一連の VM 内でホストされ、テナント VM と同じ物理サーバーを共有します。すべての Azure Stack Hub VM は、スケールユニットの Windows Server クラスタリングテクノロジと個々の Hyper-V インスタンスによって管理されます。スケールユニットにより、Azure Stack Hub の取得と管理が簡素化されます。また、スケールユニットを使用すると、Azure Stack Hub、テナント、インフラストラクチャ全体のすべてのサービスの移動とスケーラビリティを実現できます。

管理者ポータルで、Azure Stack Hub の空きメモリと使用済みメモリを示す円グラフを確認できます。例えば：

Azure Stack Hub 上の物理メモリ

次のコンポーネントは、円グラフの使用セクションのメモリを消費します。

ホスト OS の使用状況または予約: ホスト上のオペレーティングシステム (OS) によって使用されるメモリ、仮想メモリページテーブル、ホスト OS で実行されているプロセス、およびスペースダイレクトメモリキャッシュ。この値は、ホストで実行されているさまざまな Hyper-V プロセスによって使用されるメモリに依存するため、変動する可能性があります。
インフラストラクチャサービス: Azure Stack Hub を構成するインフラストラクチャ VM。これには、242 GB + (4 GB x ノード数) のメモリを占有する約 31 個の VM が必要です。インフラストラクチャサービスコンポーネントのメモリ使用量は、インフラストラクチャサービスのスケーラビリティと回復性の向上に取り組むにつれて変化する可能性があります。
回復性の予約: Azure Stack Hub では、1 つのホスト障害時、および修正プログラムと更新プログラムの実行中に VM のライブマイグレーションを成功させるために、テナントの可用性を有効にするためにメモリの一部が予約されます。
テナント VM: Azure Stack Hub ユーザーによって作成された VM。 VM の実行に加えて、ファブリックに配置されるすべての VM によってメモリが消費されます。つまり、作成中 または失敗状態の VM、またはゲスト内からシャットダウンされた VM で引き続きメモリが消費されます。ただし、Azure Stack Hub ユーザーポータル、PowerShell、または Azure CLI の "割り当て解除の停止" オプションを使用して割り当てが解除された VM は、Azure Stack Hub のメモリを消費しません。
アドオンリソースプロバイダー: SQL、MySQL、App Service などのアドオンリソースプロバイダー用にデプロイされた VM。

4 ノードの Azure Stack Hub のブレードで使用される容量

VM 配置に使用可能なメモリ

Azure Stack Hub のクラウドオペレーターとして、VM ごとに割り当てられたメモリを自動で確認する方法はありません。ユーザー VM にアクセスし、割り当てられたメモリを手動で計算できます。ただし、割り当てられたメモリには実際の使用量は反映されません。この値は、割り当てられた値よりも小さくすることができます。

VM で使用可能なメモリをトレーニングするには、次の式が使用されます。

VM 配置 = Total Host Memory--Resiliency Reserve--Memory used by running tenant VMs - Azure Stack Hub Infrastructure Overhead に使用可能なメモリ

レジリエンス予備

どこ：

H = 単一ホストメモリのサイズ

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

R = ホスト OS によって使用されるオペレーティングシステムの予約/メモリ(この数式では .15)

V = スケールユニット内の最大 VM (メモリ単位)

Azure Stack Hub インフラストラクチャオーバーヘッド = 242 GB + (4 GB x ノード数)。このアカウントは、Azure Stack Hub のインフラストラクチャをホストするために約 31 台の VM を使用します。

ホストOSが使用しているメモリ = ホストメモリの 15% (0.15)。オペレーティングシステムの予約値は見積もりであり、ホストの物理メモリ容量と一般的なオペレーティングシステムのオーバーヘッドによって異なります。

スケールユニット内で最大の VM Vの値は、デプロイされた最大のテナント VM に基づいて動的に行われます。たとえば、最大の VM 値は、7 GB または 112 GB、または Azure Stack Hub ソリューションでサポートされているその他の VM メモリサイズです。この大規模な VM のライブマイグレーションが失敗しないように十分なメモリを予約するには、最大の VM のサイズを選択します。 Azure Stack Hub ファブリックで最大の VM を変更すると、VM 自体のメモリの増加に加えて、回復性予約が増加します。

たとえば、12 ノードスケールユニットの場合:

スタンプの詳細	価値観
sts (N)	12
ホストあたりのメモリ (H)	384
スケールユニットの総メモリ	4608
OS 予約 (R)	15%
最大の VM (V)	112
回復性のための予約 =	H + R * ((N-1) * H) + V * (N-2)
レジリエンシー予備	2137.6

この情報を使用すると、最大の VM に 112 GB のメモリがある場合、ホストあたり 384 GB (合計 4,608 GB) の 12 ノード (合計 4,608 GB) の Azure Stack Hub に回復性のために 2,137 GB が予約されていることを計算できます。

次の図を参照して物理メモリの [容量] ブレードを確認すると、Used の値には回復性のリザーブが含まれています。このグラフは、4 つのノードの Azure Stack Hub インスタンスから取得したものです。

4 ノードの Azure Stack Hub での容量使用量の

Azure Stack Hub の容量を計画するときは、これらの考慮事項に留意してください。さらに、Azure Stack Hub Capacity Planner ツールを使用することもできます。

次の手順

ユーザーに VM を提供する方法の詳細については、「Azure Stack Hubのストレージ容量を管理する」を参照してください。

次の方法で共有

Azure Stack Hub のストレージ容量を管理する

ディスク、コンテナー、ボリュームについて

ディスク

BLOB とコンテナー

ボリューム

ストレージの監視

PowerShell を使用する

管理者ポータルを使用する

PowerShell を使用する

管理者ポータルを使用する

記憶域スペースのアラート

ボリューム容量メトリック

ボリュームの使用パターン

使用可能な領域を管理する

キャパシティの回復

ボリューム間でコンテナーを移行する

PowerShell を使用してコンテナーを移行する

VM ディスクの移動

ボリューム間でマネージドディスクを移行する

PowerShell を使用してマネージドディスクを移行するには

アンマネージドディスクを配布する

VM で使用可能なメモリ

VM 配置に使用可能なメモリ

次の手順

フィードバック

その他のリソース

次の方法で共有

Azure Stack Hub のストレージ容量を管理する

ディスク、コンテナー、ボリュームについて

ディスク

BLOB とコンテナー

ボリューム

ストレージの監視

PowerShell を使用する

管理者ポータルを使用する

PowerShell を使用する

管理者ポータルを使用する

記憶域スペースのアラート

ボリューム容量メトリック

ボリュームの使用パターン

使用可能な領域を管理する

キャパシティの回復

ボリューム間でコンテナーを移行する

PowerShell を使用してコンテナーを移行する

VM ディスクの移動

ボリューム間でマネージド ディスクを移行する

PowerShell を使用してマネージド ディスクを移行するには

アンマネージド ディスクを配布する

VM で使用可能なメモリ

VM 配置に使用可能なメモリ

次の手順

フィードバック

その他のリソース

ボリューム間でマネージドディスクを移行する

PowerShell を使用してマネージドディスクを移行するには

アンマネージドディスクを配布する