以下から更に引き続き、AIX編です。
シンプロとレクラメーションとSCSI UNMAP【その3 VMware編】
https://community.ibm.com/community/user/imwuc/blogs/keitaro-imai1/2020/05/21/scsi-unmap3-vmware
AIXですが、以下にまとまっていますので、こちらを読んでください。
Storage Space Unmap Support in AIX
以上！
・・・だと、手抜きすぎなので軽くかいつまんで和訳します。
AIX7.2 TL1以前だと、ファイルの削除はファイルシステムの層、ファイルシステム、LVの削除、縮小などはLVMの層までしか意識されませんでした。そのため、スペースの解放はddなどでディスクに0を書くしか方法がありませんでした。
AIX7.2 TL1以降では以下のオペレーションでディスクの領域解放をやってくれるようになりました。
・LV削除
・LVのミラー削除
・JFS2ファイルシステムの削除
・JFS2ファイルシステムの縮小
ちなみに、AIXの場合は、SCSI UNMAPでなく、WRITE SAMEを使用するそうです。初回の"シンプロとレクラメーションとSCSI UNMAP【その1 概要編】"ではUNMAPサポートと書いていましたが、訂正します。。。
この機能はLVMとデバドラが連携して機能します。デバドラがioctlコマンドで、LVMに対して、このディスクはシンプロ使ってますよ、使ってないですよと教えてあげます。
LVMのrmlv、rmlvcopyもしくはJFS2のrmfs、chfs(shrink)コマンドが実行されると、アロケートされているPPの領域が解放されるということです。
このレクラメーションの進捗具合は、lvmstatコマンドの新しいオプションの"-r"を使用することで判断でき、以下の様な項目が確認できます。
・Reclaim：ONの場合、レクラメーションがサポートされている
・Mb_freeed: 解放されたPPの容量
・Mb_pending: 解放待ちの容量
・Mb_success: 解放されたディスク上の容量
・Mb_failed: 解放に失敗したディスク上の容量
・Mb_reused: 解放なしに再利用されたPPの容量
レクラメーションのオペレーションはPPが削除された後、非同期で行われるため、"Mb_freeed"と"Mb_success"のサイズは先に"Mb_freeed"が大きくなり、それから"Mb_success"の値が増えていくようですね。
レクラメーションは、デフォルトで有効ですが、iooコマンドで"dk_lbp_enabled"の値を1から0に変えることで無効化出来ます。
また、レクラメーションには専用のバッファー領域を確保しますが、この容量が不足しているかどうかは、"/proc/sys/disk/lbp/statistics"ファイルの"Out-of-Memory counter"が0でないような場合は、"dk_lbp_num_bufs"を増やしたほうが良いかもしれません。この値はデフォルト64で、バッファーの数を示します。1バッファー512バイトなので、デフォルト32KBです。1～1024まで変更ができます。
なお、4KBのセクターサイズを提供するディスクには、"dk_lbp_buf_size"でバッファーのサイズを4KBに変更したほうが良いとのことですが、そもそも4KBセクターはあまり使われてないのでは、と思います(サポートしていないアプリケーションもあります)。
レクラメーションのKey Pointとして
・NPIVのディスクであればサポートされる
・DS8000/XIV/EMC Symmetrix/Storwizeがサポートされる
・必ずしも全ての容量が解放されるわけではない(ディスクの仕様やPPのサイズなどにより解放の挙動は異なる)
・パフォーマンスへ影響がないように、レクラメーションの優先度は抑えて行われる可能性がある
・LVMとデバドラはディスクがシンプロであることを動的に確認する。ただし、確認ができない場合はvaryoff/varyonして認識するようにする
・古いバージョンのOSレベルで作成されたVGをバージョンアップしても、レクラメーションは有効にならない。この場合はダミーのLVを作成・削除することで解放することができる。解放している最中にvaryoffやクラッシュなどで中断された場合にも、ダミーのLVを作成・削除してレクラメーションを行う
という感じでしょうか？
#AIX#scsi-unmap#thin-provisioning