esxcli storage vmfsアンマップコマンドを使用してシン プロビジョニング LUN 上の VMFS 削除済みブロックを再クレームする。
search cancel

esxcli storage vmfsアンマップコマンドを使用してシン プロビジョニング LUN 上の VMFS 削除済みブロックを再クレームする。

book

Article ID: 340043

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

この記事でシン プロビジョニングデバイス用のVMFSデータストア上で不使用ストレージブロックを再クレームする為のesxcli storage vmfs unmap コマンドを使用した手順が提供されています。
vSphere 5.5 では、esxcli 名前空間で新しいコマンドが導入されました。これにより、VAAI UNMAP プリミティブをサポートするシン プロビジョニング LUN 上で、削除済みブロックが節約できます。

コマンドはメンテナンス期間を設けることなく実行でき、節約メカニズムは次のように拡張されました。
  • 節約サイズは、パーセント値ではなく、ブロック単位で指定することができます。これにより、さらに直感的に計算できるようになります。
  • デッド スペースは、すべて一度にではなく、段階的に節約されます。これにより、発生する可能性のあるパフォーマンスの問題が回避されます。
62 TB VMDK が導入され、UNMAP はさらに大きいデッド スペース領域を処理できるようになりました。ただし、UNMAP の操作は引き続き手動です。つまり、VMFS の Storage vMotion タスクまたはスナップショット統合タスクでは、アレイ LUN の領域が自動的に節約されません。

注：vmkfstools -y コマンドは、ESXi 5.5 で廃止されました。vSphere 5.0 および 5.1 での領域の節約の詳細については、「vmkfstools を使用したシン プロビジョニングされた LUN 上での VMFS 削除ブロックの再要求 (2097449)」を参照してください。

Symptoms:

免責事項：これは英文の記事 「Using esxcli in vSphere 5.5 and 6.0 to reclaim VMFS deleted blocks on thin-provisioned LUNs (2057513)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。


Environment

VMware vSphere ESXi 5.5
VMware vSphere ESXi 6.5
VMware vSphere ESXi 6.0

Resolution

シン プロビジョニング デバイス用に VMFS データストア上の未使用のストレージ ブロックを節約するには、次のコマンドを実行します。

esxcli storage vmfs unmap --volume-label=volume_label|--volume-uuid=volume_uuid --reclaim-unit=number

コマンドで使用できるオプションは次のとおりです。
  • -l|--volume-label=volume_label

    マップ解除する VMFS ボリュームのラベル。これは必須の引数です。この引数を指定する場合は、-u|--volume-uuid=volume_uuid を使用しないでください。

  • -u|--volume-uuid=volume_uuid

    マップ解除する VMFS ボリュームの UUID。これは必須の引数です。この引数を指定する場合は、-l|--volume-label=volume_label を使用しないでください。

  • -n|--reclaim-unit=number

    反復ごとにマップ解除する VMFS ブロックの数。これは、オプションの引数です。これを指定しないと、コマンドはデフォルトの値 200 を使用します。
たとえば、名前が MyDatastore で UUID が 509a9f1f-4ffb6678-f1db-001ec9ab780e の VMFS ボリュームの場合は、次のコマンドを実行します。

esxcli storage vmfs unmap -l MyDatastore

または

esxcli storage vmfs unmap -u 509a9f1f-4ffb6678-f1db-001ec9ab780e

注：
  • ほとんどの環境で、-n number または --reclaim-unit=number 引数にはデフォルト値の 200 が適していますが、一部のアレイ ベンダーではアレイが SCSI UNMAP コマンドを処理する方法に応じて、さらに大きい、または小さい値が提案される場合があります。

  • 前の vmkfstools -y メソッドと同様に、esxcli storage vmfs unmap コマンドは一時隠しファイルをデータストアの最上位レベルに作成しますが、その名前には .asyncUnmapFile というパターンが使用されます。デフォルトで、一時ファイルの領域予約は、基になる VMFS ファイル システムのブロック サイズに応じて異なります（デフォルトは --reclaim-unit=200）。

    • 1 MB ブロックの VMFS3 / VMFS5 では 200 MB
    • 4 MB ブロックの VMFS3 では 800 MB
    • 8 MB ブロックの VMFS3 では 1,600 MB

  • 使用例に応じて、たとえば、予約サイズが大きすぎると思われる場合や、アレイにオフロードするときに UNMAP プリミティブが予定どおりに完了しないおそれがある場合に、管理者は異なる --reclaim-unit 値を選択することができます。--reclaim-unit 値を手動で定義する場合の最適な値またはベスト プラクティスについて、vSphere 管理者がストレージ アレイ プロバイダに問い合わせることをお勧めします。

  • UNMAP 操作が中断された場合は（たとえば CTRL + C キーを押すなど）、一時ファイルが VMFS データストアのルートに残る場合があります。ただし、コマンドをもう一度データストアに対して実行する場合は、コマンドが正常に完了したときにファイルが削除されます。.asyncUnmapFile が --reclaim-unit サイズを超えて大きくなることはありません。

  • UNMAP 操作は、VMFS3 ファイル システムのアップグレードまたはサードパーティ ツールを使用してボリュームを再パーティショニングしたことが原因で、ボリューム パーティション テーブルまたはブロック アライメントまたはその両方が正しくない場合に、何もせずに終わるか、失敗する場合があります。詳細については、「シン プロビジョニングのブロック領域解放 (VAAI UNMAP) が機能しない (2096193)」を参照してください。

  • UNMAP 操作に失敗し、ロック ファイルまたはリソース ビジーのエラーが発生した場合は、以下を参照してください。



Additional Information

この記事の更新時にアラートを受信する場合は、[Actions] ボックスで Subscribe to Article をクリックしてください。

Powered by Wolken Software