NetApp ONTAP：SAN環境でのUNMAP

UNMAPコマンドは、T10 SCSIコマンドセットの一部として標準化されており、SAN環境の細い月からデータストアにスペースを解放するために使用されます。 先ほど書いたように、SANとNASのプロトコルは次第にお互いから最高のものを借りてきました。 昔登場した便利な機能の1つは、以前はSANに欠けていた薄いブロックにリモートブロックを「戻す」ために、ストレージシステムとホスト間のフィードバックの可能性です。 UNMAPがSAN環境で使用されることはほとんどありませんが、仮想化環境と非仮想化環境の両方と組み合わせると非常に便利です。



UNMAPチームのサポートがなければ、ストレージ側で作成された薄い衛星は常にサイズが大きくなる だけでした 。 その成長は時間の問題であり、そのような薄い月が最終的にその全量を占めるという事実で常に無条件に終了しました。 彼は最終的に太くなるでしょう。











データストアに3台の仮想マシンがあり、それぞれが100GBを占有していると想像してください。 データストアは、300GBを占有する細い月にあります。 ストレージ側とESXiからの占有スペースは同じで、300GBです。 VMを1つ削除しても、ストレージ側からの月のサイズはまだ300GBであり、ハイパーバイザーの側から見ると、この月に存在するデータストアの占有スペースは200GBです。



これは、傷がホストとストレージシステムの間にフィードバックメカニズムを持っていなかったためです。 つまり、ホストが月に情報ブロックを記録すると、SHDはこのブロックを使用中としてマークしました。 さらに、ホストはこのブロックを削除できますが、ストレージシステムはそれをまだ知りませんでした。 UNMAPチームはこのフィードバックであり、月から不要になったブロックを加熱します。 最後に、私たちの薄い衛星は、獲得するだけでなく、ONTAP 8.2ファームウェアバージョン（クラスターデータ）から重量を減らすことも学びました。

VMware ESXiおよびUNMAP

バージョン5.0では、UNMAP機能が初めて導入され、デフォルトで有効になり、リモートブロックの設定値に達すると自動的に起動されました。以降のバージョンでは、メカニズムはデフォルトで無効になり、手動で開始されました。 VMFS-6（vSphere 6.5）以降、12時間以内にスペースが自動的に解放されます。必要に応じて、スペースの再利用を開始するための手動メカニズムも利用できます。 ここで説明するスペースのリリースは、ハイパーバイザーのレベルで行われることに注意することが重要です。 削除されたブロックは、ゲストOS内ではなく、仮想マシン全体または仮想ディスクを削除した後にのみ解放されます。



UNMAPサポートを備えたESXiおよびONTAPストレージが既にあるが、機能が有効になっていない場合



ストレージ側とハイパーバイザーの側から有効にする必要があります。 まず、月をオフラインにして、ストレージシステムのスペース割り当て機能をオンにします（VMが実行状態のままになっていると、VMが誤ってシャットダウンし、破損する可能性があるため、一時的にオフにするか、一時的に移行する必要があります）。

lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state offline lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -space-allocation enabled lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state online
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、ESXi側からマップ解除を有効にする必要があります。これを行うには、ESXiがUNMAPサポートを検出するようにデータストアをマップおよびマップする必要があります）：

 esxcli storage filesystem unmount -l myDatastore esxcli storage filesystem mount -l myDatastore esxcli storage vmfs unmap -l myDatastore
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、スペースを解放するために、定期的にコマンドを実行する必要があります。

 esxcli storage vmfs unmap -l myDatastore
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UNMAPは、1 MBの倍数のパーティションオフセットでフォーマットされた衛星に対してのみ機能することに注意することが重要です 。 これはどういう意味ですか？ つまり、一度VMFS3をVMFS5に変換した場合、UNMAPは機能しません。 これは簡単に確認でき、変換されたVMFS3にはMBR内訳テーブルがあり、再作成されたVMFS5にはGPTスプリットがあります。

 # esxcli storage core device partition showguid Example output: Device Partition Layout GUID ------------------------------------------------------------- naa.60a98000486e574f6c4a5778594e7456 0 MBR N/A naa.60a98000486e574f6c4a5778594e7456 1 MBR N/A naa.60a98000486e574f6c4a5052537a7375 0 GPT 00000000000000000000000000000000 naa.60a98000486e574f6c4a5052537a7375 1 GPT aa31e02a400f11db9590000c2911d1b8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[レイアウト]列に注意してください。



オフセットの確認も難しくありません。セクターの長さを調べます。 セクターが512バイトであることを思い出させてください。

 # esxcli storage core device partition list Example output: Device Partition Start Sector End Sector Type Size ------------------------------------------------------------------------------------- naa.60a98000486e574f6c4a5778594e7456 0 0 3221237760 0 1649273733120 naa.60a98000486e574f6c4a5778594e7456 1 128 3221225280 fb 1649267277824 naa.60a98000486e574f6c4a5052537a7375 0 0 3221237760 0 1649273733120 naa.60a98000486e574f6c4a5052537a7375 1 2048 3221237727 fb 1649272667648
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「Start Sector」列と「End Sector」列に注意してください。 したがって、最後のデバイスnaa.60a98000486e574f6c4a5052537a7375には1MBのオフセットがあります（2048セクター* 512 = 1048576バイト= 1024KB）。 ただし、2番目のデバイスnaa.60a98000486e574f6c4a5778594e7456のオフセットは1MBの倍数ではなく、明らかに小さいため、UNMAPは機能しません。



UNMAP（ Delete Status ）がサポートされているかどうかを確認できます：

 # esxcli storage core device vaai status get -d naa Example output: naa.60a98000486e574f6c4a5052537a7375 VAAI Plugin Name: VMW_VAAIP_NETAPP ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: supported
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

vSphere 6.5の自動再生スペース

vSphere 6.5以降では、ストレージ上の薄い月へのスペースの自動解放がサポートされています。 VMFS-6データストアごとに、12時間以内にストアに返されるHigh / Mid / Slowスペースのリリースに優先順位を付けることができます。 グラフィカルインターフェイスまたはコマンドラインから、スペースの再利用を開始し、VMFS-6データストアの優先順位を手動で構成することもできます。

 esxcli storage vmfs reclaim config get -l DataStoreOnNetAppLUN Reclaim Granularity: 248670 Bytes Reclaim Priority: low esxcli storage vmfs reclaim config set -l DataStoreOnNetAppLUN -p high
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゲストOSからUNMAP。

そのため、以前はデータストアから仮想マシンを削除することを検討しました。 仮想マシン全体またはそのディスクではなく、ゲストOS内からデータブロックを削除するときに同じことを行うのは論理的です。 UNMAPはONTAPでストレージ側でサポートされているため、VMDKからデータを削除するときにUNMAPメカニズムが機能します。 ゲストOSの内部から、ストレージ側から、追加の実装は必要ありません。UNMAPを有効にするには十分です。 ハイパーバイザーがこの情報を仮想マシンからストレージにブロードキャストできることが必要です。ストレージは完全にSCSIレベルで実行されます。 そのため、 ESXi 6.0以降では、ゲストOS内のリモートブロックに関する情報を送信できるようになりました。



仮想マシン内からUNMAPを機能させるには、次の条件が満たされている必要があります。

• 仮想ハードウェアバージョン11
• VMFS6
• vSphere 6.0 * / 6.5
• ムーンストレージは薄くする必要があります
• 仮想ディスクvirtualkaは薄いはずです
• ゲストOSファイルシステムはUNMAPをサポートする必要があります
• vSphere 6.0 CBTではオフにする必要があります
• 必要に応じて、ハイパーバイザーでUNMAPを有効にします。esxclistorage vmfs unmap -l myDatastore
• ストレージでUNMAPを有効にする

薄くて薄い

長年にわたり、すべてのストレージベンダーは、シンムーンにシン仮想ディスクを作成しないと言っていました。 しかし、現在はこれが変更されており、仮想マシン内からブロックを解放するには、ストレージシステムにシン仮想ディスクとシンムーンが必要です。 vSphere 6.0では、ゲストOS内部からリモートブロックを返す機能が実装されましたが、 UNMAPを使用する場合、Linuxマシンがサポートされないなど、 いくつかの制限がありました。 VMFSを備えたvSphere 6.0以前のバージョンでは、UNMAP機能が自動的に開始されないため 、コマンドを手動で実行する必要があります。

WindowsゲストOSサポート

WindowsゲストOS内からスペースを解放するには、NTFSファイルシステムを64KBの割り当てユニットサイズでフォーマットする必要があります。

LinuxゲストOS SPC-4サポート

SPC -4をサポートし、vSphere 6.5で実行されているLinux仮想マシンも、仮想マシンの内部から解放されたスペースをストレージに戻すことができるようになりました。

Linuxマシンがスペースのリリースをサポートしているかどうかを確認する方法は？







VMwareハイパーバイザーはUNMAPを非同期的に 、つまり遅延して開始することを覚えておくことが重要です。 これは、実際には、ゲストOS内/ハイパーバイザーデータストア上およびストレージムーン上に、1：1の占有スペースがほとんどないことを意味します。

Vvol

vSphere 6.0以降のVVOLテクノロジー、VMハードウェアバージョン11、およびNTFSファイルシステムを備えたWindows 2012 GOSは、この仮想マシンが配置されている外部ストレージ上のシンムーン内のスペースの自動解放をサポートしています。



vSphere 6.5のVMハードウェアバージョン11にインストールされたSPC -4をサポートするLinux GOSは、仮想マシン内からストレージの薄いスペースにスペースを戻すこともできます。



これにより、Thing Provisioningとハードウェアアシスタントスナップショットを使用して、SANインフラストラクチャで使用可能なスペースの使用率が大幅に向上します。



ONTAP用のESXi 6.xのチューニングの詳細。

Windows（ベアメタル）

このOSファミリのUNMAPコマンドのサポートは、NTFSファイルシステムを備えたWindows Server 2012から始まりました。 自動UNMAPを有効にするには、Windows Host Utility 6.0.2以降またはONTAP DSM 4.0以降を使用します。 UNMAPが有効になっているかどうかを確認するには、 fsutil behavior query disabledeletenotify



。 DisableDeleteNotify = 0の状態は、 UNMAPがインバンドでブロックを返すことを意味します。 ホストに複数のストレージシステムから接続された複数の衛星があり、そのうちのいくつかがUNMAPをサポートしていない場合は、オフにすることをお勧めします。



Windows Server for ONTAPのチューニングの詳細をご覧ください。

Linux（ベアメタル）

LinuxディストリビューションはUNMAPをサポートしています。 NetAppは、 mountコマンドの-o discardスイッチとfstrimユーティリティを使用して、RHELバージョン6.2以降を公式にサポートしています。 詳細については、 RHEL6 Storage Admin Guideを参照してください 。



Linux Server for ONTAPのチューニングの詳細をご覧ください。

ゾンビ

ONTAP 9より前のファイル削除操作では、いわゆるゾンビメッセージが生成されていました。

ONTAP 9でのファイルの削除と優先順位付け

ONTAP 9は2016年5月にリリースされたことを思い出してください。このバージョンのZombieソフトウェアでは、スペースを解放するためのメッセージは生成されなくなり、代わりにファイルに削除のマークが付けられます。 これに関連して、スペースを解放する作業のロジックが大幅に変更されました。

• 最初に、データはバックグラウンドで削除されます
• 第二に、より多くを必要とするボリューム、つまりスペースで終わるボリュームからのスペースの解放を優先することが可能になりました。

結論

ゲストOS、ホスト、およびNetAppストレージ側の両方でUNMAPサポートが実装されているため、シンプロビジョニングを使用してSAN環境のスペースをより合理的に使用でき、その結果、ハードウェアスナップショットでストレージスペースをより合理的に使用できます。 ハイパーバイザーレベルでのUNMAPのサポート、およびゲストOS内でのサポートは、これら2つの一般的なテクノロジーの使用を大幅に促進します。



テキストのエラーに関するメッセージをLANに送ってください。 反対の記事に関するコメント、追加、質問はコメントしてください。