次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

  • 容量の解放。
  • ストレージ オブジェクトの移行。

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

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

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

ディスク

VM では、仮想ディスクにデータを格納して操作します。 各 VM は、マーケットプレース イメージまたはプライベート イメージから作成された 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 とコンテナー

テナント ユーザーは、Azure BLOB を使用して大量の非構造化データを格納します。 Azure Stack Hub では、ブロック BLOB、追加 BLOB、ページ BLOB の 3 種類の BLOB をサポートしています。 異なる種類の BLOB の詳細については、「Understanding Block Blobs, Append Blobs, and Page Blobs」(ブロック BLOB、追加 BLOB、ページ BLOB について) をご覧ください。

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

コンテナーに BLOB が配置された後、その BLOB が増加してより多くの領域を使用する可能性があります。 新しい BLOB を追加するときに既存の BLOB が増加していると、そのコンテナーを保持しているボリュームの空き領域が少なくなります。

コンテナーは、単一のボリュームに限定されません。 コンテナー内の結合された 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 を使用する場合は、単一の共有を持つ単一のボリュームがあります。

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

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

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

テナント ユーザーによる Azure Stack Hub での BLOB ストレージの操作方法については、Azure Stack Hub ストレージ サービスに関する記事を参照してください。

ストレージの監視

Azure PowerShell または管理者ポータルを使用して共有を監視することで、空き領域が少なくなった場合にそれを把握できます。 ポータルを使用しているときは、領域が少なくなっている共有に関するアラートを受信します。

PowerShell の使用

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

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

  • 合計容量: 共有で使用できる合計容量 (バイト単位)。 この領域は、ストレージ サービスによって保持されるデータとメタデータ用に使用されます。
  • 使用済み容量: テナント データとそれに関連付けられているメタデータを格納するファイルのすべてのエクステントで使用されるデータの量 (バイト単位)。

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

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

  1. 管理者ポータル https://adminportal.local.azurestack.external にサインインします。

  2. [すべてのサービス]>[ストレージ]>[ファイル共有] を選択してファイル共有の一覧を開きます。そこで使用状況情報を確認できます。

    例: Azure Stack Hub 管理者ポータルでのストレージ ファイル共有のスクリーンショット。

    • Total: 共有で使用できる合計容量 (バイト単位)。 この領域は、ストレージ サービスによって保持されるデータとメタデータ用に使用されます。
    • 使用済み: テナント データとそれに関連付けられているメタデータを格納するファイルのすべてのエクステントで使用されるデータの量 (バイト単位)。

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

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

  • 現在のボリューム容量のポータルと の PowerShell。
  • 記憶域スペースのアラート。
  • ボリューム容量メトリック。

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

PowerShell の使用

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

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

  • 合計容量: 共有で使用できる合計領域 (GB 単位)。 この領域は、ストレージ サービスによって保持されるデータとメタデータ用に使用されます。
  • 残りの容量: テナント データとそれに関連付けられているメタデータを格納するための空き領域 (GB 単位)。

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

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

  1. Azure Stack Hub 管理者ポータル (https://adminportal.local.azurestack.external) にサインインします。

  2. [すべてのサービス]>[ストレージ]>[ボリューム] を選択してボリュームの一覧を開きます。そこで使用状況情報を確認できます。

    例: Azure Stack Hub 管理者ポータルでのストレージ ボリュームのスクリーンショット。

    • Total: ボリューム上の使用可能な合計領域。 この領域は、ストレージ サービスによって保持されるデータとメタデータ用に使用されます。
    • 使用済み: テナント データとそれに関連付けられているメタデータを格納するファイルのすべてのエクステントで使用されるデータの量。

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

管理者ポータルを使用しているときは、領域が少なくなっているボリュームに関するアラートを受信します。

重要

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

  • 警告: ファイル共有の使用率が 90% を超えると、管理者ポータルで "警告" アラートを受信します。

    例: Azure Stack Hub 管理者ポータルの [警告] アラートのスクリーンショット

  • 重大: ファイル共有の使用率が 95% を超えると、管理者ポータルで "重大" アラートを受信します。

    例: Azure Stack Hub 管理者ポータルの [重大] アラートのスクリーンショット

  • 詳細の表示: 管理者ポータルでアラートの詳細を開いて、軽減策を確認できます。

    例: Azure Stack Hub 管理者ポータルのアラートの詳細の表示のスクリーンショット

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

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

容量メトリック レポートを事前に確認して、ボリュームのリソース使用量を理解する必要があります。 ボリュームの使用率が 100% に近づいたら、クラウド オペレーターがリソースの種類の配分状況を分析し、領域を解放するための対応するアクションを判断できます。 オペレーターは、ボリュームが過剰にプロビジョニングされていることがプロビジョニング済みのディスク サイズで示された場合に、ボリュームのオーバー プロビジョニングを防ぐこともできます。

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

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

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

Azure Monitor でボリューム容量メトリックを表示するには、次の手順に従います。

  1. Azure PowerShell がインストールおよび構成されていることを確認します。 PowerShell 環境の構成方法については、「PowerShell for Azure Stack Hub をインストールする」をご覧ください。 Azure Stack Hub にサインインする場合は、オペレーター環境の構成と Azure Stack Hub へのサインインに関するページを参照してください。

  2. GitHub リポジトリからの Azure Stack Hub ツールをダウンロードします。 詳細な手順については、「GitHub からの Azure Stack Hub ツールのダウンロード」を参照してください。

  3. CapacityManagement で DashboardGenerator を実行して、容量ダッシュボードの json を生成します。

    .\CapacityManagement\DashboardGenerator\Create-AzSStorageDashboard.ps1 -capacityOnly $true -volumeType object

    名前が DashboardVolumeObjStore で始まる json ファイルが、DashboardGenerator の フォルダーに生成されます。

  4. Azure Stack Hub 管理者ポータル (https://adminportal.local.azurestack.external) にサインインします。

  5. [ダッシュボード] ページで、[アップロード] をクリックし、手順 3 で生成された json ファイルを選択します。

    例: ダッシュボード json をアップロードする。

  6. JSON がアップロードされると、新しい容量ダッシュボードに移動します。 各ボリュームには、ダッシュボードに対応するグラフが表示されます。 グラフの数は、ボリュームの数と等しくなります。

    例: ボリューム容量ダッシュボード。

  7. ボリュームのいずれかをクリックすると、特定のボリュームの 5 つの容量メトリックを詳細なグラフで確認できます。

    例: 詳細な容量メトリック。

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

ボリューム容量メトリックを確認すれば、クラウド オペレーターは、ボリューム容量の使用量と、領域の大部分を占有しているリソースの種類を理解できます。 領域の使用パターンは、次の種類にグループ化できます。オペレーターは、種類ごとに異なるアクションを実行する必要があります。

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

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

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

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

残りの容量が少ない場合は、ボリュームの使用率が 100% に近づいている状態を示します。 ボリュームの使用率が 100% になり、ストレージ サービスがブロックされるのを防ぐには、空き領域に対してオペレーターがすぐにアクションを実行する必要があります。 VM ディスクの使用済みの容量が高い場合、ボリューム使用量の大部分は VM ディスクです。 使用率が 100% のボリュームから使用可能な他のボリュームにディスクを移動して、領域を解放するには、ディスクの移行に関するページの手順を参照してください。

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

ボリュームの使用率が 100% になるリスクがあります。この場合、領域を解放するためにオペレーターがすぐにアクションを実行する必要があります。 他の使用容量が高い場合は、ボリューム容量の大部分がブロック/追加 BLOB またはテーブル/キューによって占有されていることを示します。 ボリュームの使用可能な容量が 20% 未満の場合、コンテナーのオーバーフローが有効になり、使用率がほぼ 100% のボリュームに新しい BLOB オブジェクトが配置されることはありません。 ただし、既存の BOLB はまだ増加する可能性があります。 継続的に増加している BLOB で容量が過剰に使用されないようにするには、Microsoft サポートにお問い合わせください。特定のボリュームの領域を占有しているコンテナーにクエリを実行し、領域を解放するために、それらのコンテナーのクリーンアップをテナントで実行する必要があるかどうかを判断できます。

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

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

ボリュームの領域を解放する必要がある場合は、最も影響が少ない方法を先に使用してください。 たとえば、マネージド ディスクの移行を選択する前に領域の回収を試してください。

容量の回収

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

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

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

"このオプションは、Azure Stack Hub 統合システムにのみ適用されます。 "

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

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

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

  • コンテナーがオーバーフロー モードに入り、BLOB が別のボリュームに配置されている場合、新しい共有には、オーバーフローされている BLOB を含む、移行するコンテナーに属するすべての BLOB を保持するのに十分な容量が必要です。

  • PowerShell コマンドレット Get-AzsStorageContainer は、コンテナーの初期ボリュームで使用されている領域のみを識別します。 このコマンドレットでは、別のボリューム上にオーバーフローされている BLOB によって使用されている領域は識別されません。 そのため、コンテナーのフル サイズがはっきりしないことがあります。 新しい共有でのコンテナーの統合によって、新しい共有がオーバーフロー状態になり、データが別の共有に配置される可能性があります。 その結果、共有を再調整する必要が生じる場合があります。

  • 特定のリソース グループへのアクセス許可がないために、PowerShell を使用してオーバーフロー データが配置されている別のボリュームのクエリを実行できない場合は、それらのリソース グループとコンテナーの所有者と協力して、移行するデータの合計容量を把握したうえでデータを移行します。

重要

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

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

  1. Azure PowerShell のインストールと構成が行われていることを確認します。 詳細については、「Azure PowerShell を使用した Azure リソースの管理」を参照してください。

  2. コンテナーを調べて、移行する予定の共有にどのようなデータがあるかを把握します。 ボリューム内の移行に最適な候補コンテナーを識別するには、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

    例: $containers

  3. 移行するコンテナーを保持するのに最適な移行先の共有を特定します。

    $destinationshare = ($shares | Sort-Object FreeCapacity -Descending)[0]

    $destinationshares を確認します。

    $destinationshares

    例: $destination 共有

  4. コンテナーの移行を開始します。 移行は非同期です。 最初の移行が完了する前に、別のコンテナーの移行を開始する場合は、ジョブ ID を使用してそれぞれの状態を追跡します。

    $job_id = Start-AzsStorageContainerMigration -StorageAccountName $containers[0].Accountname -ContainerName $containers[0].Containername -ShareName $containers[0].Sharename -DestinationShareUncPath $destinationshares[0].UncPath -FarmName $farm_name

    $jobId を調べます。 次の例の d62f8f7a-8b46-4f59-a8aa-5db96db4ebb0 を、調べるジョブ ID に置き換えてください。

    $jobId
d62f8f7a-8b46-4f59-a8aa-5db96db4ebb0

  5. ジョブ ID を使用して、移行ジョブの状態を確認します。 コンテナーの移行が完了すると、MigrationStatus が Completed に設定されます。

    Get-AzsStorageContainerMigrationStatus -JobId $job_id -FarmName $farm_name

    移行の状態を示すスクリーンショット。

  6. 実行中の移行ジョブを取り消すことができます。 取り消された移行ジョブは、非同期的に処理されます。 $jobid を使用して、取り消しを追跡できます。

    Stop-AzsStorageContainerMigration -JobId $job_id -FarmName $farm_name

    例:ロールバック状態

  7. 移行の状態が取り消し済みになるまで、手順 6 のコマンドをもう一度実行できます。

    取り消された移行の状態の例を示すスクリーンショット。

VM ディスクを移動する

"このオプションは、Azure Stack Hub 統合システムにのみ適用されます。 "

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

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

"このオプションは、Azure Stack Hub 統合システムにのみ適用されます。 "

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

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

重要

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

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

  1. Azure PowerShell がインストールおよび構成されていることを確認します。 PowerShell 環境の構成方法については、「PowerShell for Azure Stack Hub をインストールする」をご覧ください。 Azure Stack Hub にサインインする場合は、オペレーター環境の構成と Azure Stack Hub へのサインインに関するページを参照してください。

  2. マネージド ディスクを調べて、移行を計画するボリューム上のディスクを把握します。 ボリュームの移行に最適な候補ディスクを識別するには、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

  3. 移行するディスクが保持されている最善のボリュームを識別します。

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

  4. マネージド ディスクの移行を開始します。 移行は非同期です。 最初の移行が完了する前に、別のディスクの移行を開始する場合は、ジョブ名を使用してそれぞれの状態を追跡します。

    $jobName = "MigratingDisk"
Start-AzsDiskMigrationJob -Disks $Disks -TargetShare $MigrationTarget -Name $jobName

  5. ジョブ名を使用して、移行ジョブの状態を確認します。 ディスクの移行が完了すると、MigrationStatus が Completed に設定されます。

    $job = Get-AzsDiskMigrationJob -Name $jobName

    例:移行の状態

    1 つの移行ジョブで複数のマネージド ディスクを移行する場合でも、ジョブのサブタスクを確認できます。

    $job.Subtask

    例:移行サブタスクの状態

  6. 実行中の移行ジョブを取り消すことができます。 取り消された移行ジョブは、非同期的に処理されます。 移行ジョブの状態が Canceled であることを確認するまで、ジョブ名を使用して取り消しを追跡できます。

    Stop-AzsDiskMigrationJob -Name $jobName

    例:取り消し済みの状態

アンマネージド ディスクを分散させる

"このオプションは、Azure Stack Hub 統合システムにのみ適用されます。 "

領域を管理する最も極端な方法には、アンマネージド ディスクの移動が伴います。 テナントで多数のアンマネージド ディスクが 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 では、単一のホスト障害が発生したときにテナントの可用性を確保するために、およびパッチと更新プログラムの適用時に 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 + R * ((N-1) * H) + V * (N-2)

各値の説明:

H = 1 つのホスト メモリのサイズ

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

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

V = スケール ユニットで最大の VM (メモリごと)

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

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

値 V (スケール ユニット内の最大 VM) は、デプロイされた最大のテナント 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 のメモリがある場合、12ノードでホストあたり 384 GB (合計 4,608 GB) の Azure Stack では、回復性のために 2,137 GB が予約されると計算できます。

次に示すように、物理メモリの [容量] ブレードを見ると、 [使用済み] の値に回復性の予約が含まれます。 グラフは、4 ノードの Azure Stack Hub インスタンスのものです。

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

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

次のステップ

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