SUSE Linux EnterpriseのLVMシンプロビジョニングにおける容量不足を安全に修正する

変更を加える前に、何を判断すべきでしょうか？

まず、シンプールがデータ領域、メタデータ領域、またはその両方を使い果たしたかどうかを判断します。この区別によって復旧計画が変わります。シンプールには、割り当てられたブロックを格納するデータ論理ボリュームと、それらの割り当てを追跡するメタデータ論理ボリュームが含まれています。シン論理ボリュームの仮想サイズはプールの物理容量を超えることがあり、これがシンプロビジョニングの目的であると同時に、オーバーコミットを監視する必要がある理由でもあります。

SUSE Linux Enterprise Server 15 SP7 のドキュメントでは、シンボリュームがオンデマンドでシンプールから領域を割り当て、その合計仮想サイズが使用可能な物理ストレージ容量を超過する可能性があることが確認されています。アップストリームの LVM シンプールに関するドキュメントには、重要な運用ルールが追加されています。それは、またはData%がMeta%100% に達する前にプールを拡張することです。詳細については、SUSE Linux Enterprise Server 15 SP7 ストレージ管理ガイドおよびLVM シンプロビジョニングマニュアルを参照してください。

1. データ領域がいっぱいなのか、それともメタデータがいっぱいなのか？

lvs一般的なディスク容量チェックに頼るのではなく、明示的な列を指定して実行してください。ファイルシステムは仮想領域に空きがあると報告する一方で、その下の物理的なシンプロビジョニングプールはほぼ枯渇している可能性があります。

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

キャプション：シンプールは、そのデータ％とメタ％の値によって識別する必要があります。ファイルシステムの空き容量だけでは、物理的なシンプールの枯渇はわかりません。

が100に近い場合Data%、プール内の新規書き込み用のブロックが不足しています。LVMの公式ドキュメントでは、データプールが枯渇すると書き込み時にエラーが発生する可能性があり、その結果ファイルシステムが損傷する可能性があると警告しています。がMeta%100に達した場合、メタデータ枯渇によってシンプールメタデータとファイルシステムの両方に不整合が生じる可能性があるため、より保守的な対応となります。

2. ボリュームグループにはまだ空き物理領域がありますか？

これが次の判断ポイントです。シンプールは、ボリュームグループに空きエクステントがある場合にのみ拡張できます。ただし、そのボリュームグループに物理ストレージを追加した場合は別です。

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

キャプション：VGの空き容量を確認することで、単純な薄型拡張と、先にストレージを追加する必要があるケースを区別できます。

VGに十分な空き容量がある場合は、通常、シンボリュームプールを直接拡張できます。空き容量VFreeがゼロまたは小さすぎる場合は、再試行を繰り返さずlvextend、不要なシンボリュームやスナップショットを削除できるか、破棄によってブロックを解放できるか、または新しい物理ボリュームを追加できるかを判断してください。

3．復旧前にアプリケーションを停止すべきでしょうか？

ストレージプールの使用率が既に100%に達している場合は、ストレージの変更を行う前に、書き込み負荷の高いアプリケーションを停止または静止状態にしてください。これにより、ストレージ層の障害発生時や修復中に、データベース、仮想マシン、コンテナ、その他のサービスが書き込み処理を継続する可能性を低減できます。

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

キャプション：アプリケーションを静止させることで、満杯または破損したシンプールの復旧中に発生する追加の書き込みを制限できます。

停止すべきサービスの一覧は一律ではありません。ワークロードのアーキテクチャとメンテナンス手順に従ってください。データベースや仮想マシンについては、プロセスを強制終了するのではなく、製品がサポートするシャットダウンまたは静止状態への移行方法を使用してください。

4. Data% が満杯で、VG に空き容量がある場合、プールを拡張するにはどうすればよいですか？

問題は物理的なプール容量の不足にあるため、仮想的なシンLVではなく、シンプール自体を拡張してください。例：

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

キャプション：薄型プールを拡張することで物理的な容量が増加します。新しいスペースが利用可能になれば、結果としてデータ使用率は低下するはずです。

lvextendのマニュアルには、シン プールの直接拡張と--poolmetadatasizeメタデータ用の個別のオプションが記載されています。実際の成長率と予約可能なストレージ容量に基づいて増分を選択してください。固定の例は、+20Gすべてのシステムに対するサイジングの推奨事項ではありません。

5. ボリュームグループに空き容量がない場合はどうすればよいでしょうか？

ストレージを追加する際は、対象のブロックデバイスが未使用であり、必要なデータが含まれていないことを確認してからにしてください。LVM物理ボリュームを作成すると、選択したデバイスにLVMメタデータが書き込まれるため、デバイス名を間違えるとデータが失われる可能性があります。

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

キャプション：VGがいっぱいになった場合、管理者が正しい未使用デバイスを確認した後、最初に新しい物理ストレージを追加できます。

SUSEのドキュメントによると、ボリュームグループはパーティションまたはディスク全体を追加することで拡張できます。マルチパス、SAN、RAID、暗号化、クラスタリング、またはクラウドベースのシステムでこれを行う前に、ストレージトポロジを確認してください。単純な例で示されている生ディスクが正しいデバイスレイヤーではない可能性があるためです。

6. もしMeta%が100%に達したらどうなるでしょうか？

メタデータ枯渇は、単にデータ容量を追加するのではなく、オフライン修復のケースとして扱ってください。LVM シンプール マニュアルには、メタデータ枯渇によってシンプール メタデータとファイルシステムに不整合が生じる可能性があることが明記されています。マニュアルに記載されている復旧手順は、プールを非アクティブ化し、修復を行いlvconvert --repair、メタデータを拡張してから、ファイルシステムをチェックすることです。

アプリケーションを停止した後、ファイルシステムをアンマウントするか、プールを使用してシン論理ボリュームを非アクティブ化します。その後、以下のような制御されたメンテナンス手順に従ってください。

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

キャプション：メタデータが満杯の状態では、単にデータエクステントを増やすだけでなく、オフラインでのシンプール修復と追加のメタデータ領域が必要になります。

図+1Gはあくまで一例です。メタデータのサイズは、プールサイズ、チャンクサイズ、スナップショットの使用状況、および割り当て動作によって異なります。修復後、システムログを確認し、I/Oエラーが発生した場合は、ファイルシステム固有のサポートされているチェックまたは修復手順を実行してください。マウントされたファイルシステムに対して、ファイルシステム修復ツールを安易に実行しないでください。

ファイルを削除することで、シンプールを即座に解放できますか？

必ずしもそうとは限りません。ファイルを削除するとファイルシステム内の空き領域は確保されますが、シン プールは破棄情報がプールに到達した場合にのみ物理的なチャンクを解放します。LVM のドキュメントにfstrimは、このようなブロックを解放できると記載されていますが、スナップショットはブロックを参照し続け、ブロックが解放されるのを妨げる可能性があります。プールが破棄を無視するように構成されている場合、trim はブロックを解放しません。

ファイルシステムとワークロードが対応している場合は、破棄動作を確認し、プールが十分に安定して動作できる状態になってからのみトリムを実行します。

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

古いシン・スナップショットを削除すると、それらのスナップショットがブロックへの残りの参照となっている場合、ストレージ容量を解放できることがあります。スナップショットを削除する前に、バックアップと保持に関する要件を確認してください。

7. このような事態が再発しないようにするにはどうすればよいでしょうか？

LVM シンプール監視を有効にして検証し、VG に十分な空き容量がある状態で自動拡張を設定します。アップストリーム LVM はdmeventd、通常はlvm2-monitorサービスを介して、データまたはメタデータの使用量が設定されたしきい値を超えた場合に反応します。

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

キャプション：自動拡張は、アクティブな監視、適切なしきい値、およびボリュームグループ内に残っている空きエクステントに依存します。

LVMのマニュアルによると、しきい値を100に設定すると自動拡張が無効になり、有効な最小しきい値は50です。しきい値を低く設定すると、書き込み速度が非常に速いプールでもLVMが対応できる時間が長くなります。拡張率は、ポリシーがトリガーされたときにプールがどれだけ拡張されるかを決定します。

代表的な構成例は/etc/lvm/lvm.conf以下のとおりです。

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

これらの値は例であり、普遍的なデフォルト値ではありません。書き込みバースト率、監視間隔、ストレージプロビジョニングのリードタイム、および利用可能なVG空き容量に応じて、安全マージンのサイズを設定してください。VG自体が既に満杯の場合は、自動拡張は役に立ちません。

8. 回復が本当にうまくいったことを、どうやって確認するのですか？

複数のシグナルを確認してください。プールには十分な余裕があり、VGには想定される成長に対応できる十分な空き容量があり、アプリケーションは正常に書き込みができ、ログには継続的なシンプールI/Oエラーやメタデータエラーが表示されないことを確認してください。

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

キャプション：プール使用率に余裕があり、VGが使用可能な空き容量を保持し、監視レポートで継続的なI/Oエラーがないことが確認された場合、復旧が確定します。

アプリケーションを段階的に再起動し、実際のワークロードが回復するまでシンプールを監視してください。Data%シンプールが再び異常に急速に増加する場合は、プールを拡張することで一時的な障害は解消されたものの、キャパシティプランニングの問題は解決されていない可能性があります。

いつ停止して別の復旧方法に切り替えるべきでしょうか？

避けるべきことは何ですか？

• df -h薄いプールには物理的な空きストレージがあるとは限らないという前提を置いてはいけません。
• 未使用であることを確実に確認するまでは、新しいデバイスを初期化しないでくださいpvcreate。
• メタデータ枯渇を、通常のデータ枯渇と同じ問題として扱わないでください。
• VGに空き領域を確保せずに自動拡張に頼らないでください。
• ファイルシステムベンダーがその操作を明示的にサポートしていない限り、マウントされたファイルシステムに対してファイルシステム修復コマンドを実行しないでください。
• 警告を抑制するためだけに監視を無効にしないでください。警告は、書き込みが失敗する前にプールを拡張できる最後の機会となる場合が多いからです。

公式および主要な参考文献

• SUSE Linux Enterprise Server 15 SP7 ストレージ管理ガイド
• SUSE SLES 15 SP7 Expert Partitioner のドキュメント
• LVMシンプロビジョニングマニュアル
• LVM lvextend マニュアル