ストレージのプール化、効率利用の要件が増えている昨今、外部ストレージのThin provisioning(シンプロ)機能を利用しているお客様は少なくないと思います。
シンプロ知らない！という方はググってください(^_^;)
イマイがストレージのコンサルをやっている中で多いのが、このシンプロを利用していてストレージの容量が足りなくなった！というお客様です。
物理的に搭載している容量よりデータを書き込もうとすれば、容量が足りなくなるのは当たり前のことです。
ただし、多くのお客様ではレクラメーションを行っておらず、本当は不要な領域を確保し続けた挙げ句に、容量不足となるケースがあります。
通常、OSのファイルシステムではデータを削除した場合、データの物理ブロックへのメタデータのみ削除します。
したがって、物理ディスク上ではデータは残り続けます。もちろん、OS的にはその物理ブロックは再利用可能なのですが、そこを再利用するかはファイルシステム次第です。
データが追記された場合に、消去した領域を再利用すれば良いのですが、新たな領域を使用しようとするファイルシステムもあります。
この場合、シンプロを使用している物理ディスク上では新たな領域をアロケートするため、より多くの容量が消費されます。
これが続くと最終的には、全ての容量が消費され、それ以上データが書き込めなくなってしまいます。(以下図1)
図1. レクラメーションなしの場合
これを解消するのがレクラメーションです。OSで削除した領域を解放することで、その領域を外でも再利用可能にします。(以下図2)
図2. レクラメーションありの場合
従ってレクラメーションのありとなしでは大きく使用容量が変わる可能性があります。
このレクラメーションですが、通常は、0データを書き込む(UNIX/Linuxではddコマンド、Windowsではsdeleteツールなど)ことで解放することが可能ですが、これにはユーザーのオペレーションが必要となります。
少し前からですが、OS、ファイルシステムによってはSCSI UNMAPというSCSIコマンドを発行して、自動(手動でも可)で実行することができるようになりました。
このSCSI UNMAPですが、OSが対応していることに加えて、ストレージ側でも対応している必要があります。
以下は、どのIBMストレージとOSがSCSI UNMAPに対応しているかを表しています。
・IBMストレージ
- DS8880 R8.2.3 以降
- XIV 11.2 以降 (ただしAsync Mirrorのボリュームは対象外)
- SVC/Storwize/FlashSystem V9000 v8.1.0 以降
- FlashSystem 900 1.2 以降
- FlashSystem A9000 Any version
・OS(詳細は各OSのベンダーにご確認ください)
- VMware ESX 5.0 以降
- Windows 2012 以降
- AIX 7.2 TL1 以降 (ただし、LVの削除(rmlv)、LM Mirrorの削除(rmlvcopy)、ファイルシステムの削除、縮小(rmfs、chfs)のみ対応。ファイルの削除は対象外)。AIXの場合はUNMAPでなくWRITE SAMEを使用。
- RHEL 6以降 (RHEL6はext4のみ、RHEL7はext4、XFS)
- SuSE 11 SP4以降(多分、ガイド上はこのバージョンしか見当たりませんでした)
シンプロを利用する場合は、上記を参考にしてSCSI UNMAPが使用できる環境でレクラメーションができるように実装ください。
次回以降でもう少しこのあたりに突っ込んでいきたいと思います。
#thin-provisioning#reclamation#scsi-unmap