SLES Thin Poolの容量不足：LVMを安全に拡張し、書き込みを復元する

SUSE Linux Enterprise Server のシンプロビジョニング ボリュームで「デバイスに空き容量がありません」というエラーが表示された場合は、まずシン プールの容量を確認してくださいData%。Meta%データ領域が満杯で、ボリューム グループに空きエクステントがある場合は、シン プールを拡張します。これは、シン 論理ボリュームの仮想サイズだけでlvextendなく、容量も拡張する必要があります。メタデータ領域が完全に満杯の場合は状況が異なります。通常の書き込みを再開する前に、オフライン修復が必要になる場合があります。

以下の手順では、Linux 用に文書化された LVM2 コマンドと、SUSE Linux Enterprise Server 15 SP7 ストレージ管理ガイドに記載されているストレージ モデルを使用します。コマンドの可用性やサービス構成は、別の SLES サービス パックまたはクラスタ構成では異なる場合があります。本番環境のストレージを変更する前に、アプリケーション整合性のあるバックアップを取得し、大量の書き込みを制限してください。

1. データ領域またはメタデータが枯渇していないか確認する

アクティブなシンプールを所有するホストで、以下のコマンドを実行してください。` vgdata<volume-group name>` の部分は、ご使用のボリュームグループ名に置き換えてください。

sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata

thin-poolの下にある行を探してくださいSegType。Data%は割り当てられたデータブロックを測定し、Meta%はプールのマッピングメタデータを測定します。これらは別々の容量制限です。Data%が 100 に近いが、Meta%が を十分に下回っている場合は、追加のデータ範囲が最も直接的な解決策です。 がMeta%100 の場合は、セクション 4 の復旧対策を使用してください。

仮に、容量vgdata/pool0が 100 GiB で、データ使用率が 98.12%、メタデータ使用率が 40.26% だとします。マウントされたシンボリューム内に十分な空き容量があると報告されていても、プールはすぐに危険にさらされます。SUSEの Expert Partitioner のドキュメントで説明されているdf -hように、シンボリュームの仮想サイズは、プールを支える物理容量を超える可能性があります。

また、最近のエラーも確認してください。

sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'

grepの結果が空だからといって、書き込み失敗が発生しなかったと解釈しないでください。特に、プールがいっぱいになったときにデータベースや仮想マシンが書き込みを行っていた場合は、アプリケーションのログも確認してください。

2. ボリュームグループに空き物理領域があることを確認します。

プールサイズを変更する前に、ボリュームグループが拡張費用を負担できるかどうかを確認してください。

sudo vgs -o vg_name,vg_size,vg_free vgdata

架空の例では、200 GiB のボリューム グループに 40 GiB の空き容量があります。したがって、割り当て制約とメタデータの増加に対応できる余裕があれば、20 GiB のプール拡張は原則として可能です。空きエクステントすべてをプールに割り当てるのではなく、ボリューム グループの一部領域を予備として確保しておきましょう。

VG_FREEがゼロの場合、lvextend物理容量を生成できません。正しく識別され、準備された物理ボリュームをVGに追加し、必要に応じて基盤となるストレージとそのLVM PVを拡張するか、再試行する前にブロックを解放してください。ボリューム グループのサイズ変更時に物理ボリュームを追加する方法については、SUSEのドキュメントを参照してください。検証されていないディスクに対して実行しないでくださいpvcreate。既存のストレージ メタデータが破壊される可能性があります。

3. 薄い体積ではなく、薄いプールを拡張する

制限要因が であり、メタデータが枯渇しておらず、十分な VG エクステントが空いている場合はData%、プール自体を拡張します。

sudo lvextend -L +20G vgdata/pool0

この+20G構文は、現在のプールサイズに20 GiBを追加するものであり、最終サイズを20 GiBに設定するものではありません。この例では、バッキングプールは100 GiBから120 GiBに拡張されます。割り当て済みのデータが変更されていない場合、使用中の98.12 GiBは、拡張後のプールの約81.8%に相当します。操作中に書き込みが継続される場合、実際の割合は異なる場合があります。

代用しないでくださいlvextend -L +20G vgdata/thin1。シンボリュームの仮想アドレス空間を拡張しても、必ずしもそのプールに物理データ容量が追加されるわけではありません。このコマンドはファイルシステムの仮想ブロックデバイスではなく、バッキングプールを拡張するため、この操作では通常、ファイルシステムのサイズ変更は必要ありません。LVMシンプロビジョニングの公式マニュアルには、シンプール拡張メカニズムとその制限事項が記載されています。

プールをすぐに拡張できない場合

シンファイルシステムから既にファイルが削除されており、スタック全体で破棄がサポートされている場合は、破棄されたブロックを再利用することを検討してください。

sudo fstrim -v /srv/data

シンボリュームの実際のマウントポイントを使用し、シンプールデバイスは使用しないでください。トリムが正常に完了すると容量が減少する可能性がありますData%が、ファイルを削除するだけでは、通常、ブロックがプールに戻されません。シンスナップショットは共有ブロックを保持できるため、破棄を無視するように設定されたプールではメリットがありません。特に書き込みが失敗し始めた場合は、トリムを物理容量の信頼できる緊急代替手段として扱わないでください。古いスナップショットは、所有権、依存関係、および保持要件を確認してから削除してください。スナップショットの削除は元に戻せません。

4. メタデータ領域全体が復旧条件であるかのように扱う

使用率が100%に達した場合はMeta%、アプリケーションの書き込みを停止し、計画的なシステム停止を実施してください。LVMは、メタデータの枯渇により、シンプールのメタデータとファイルシステムに不整合が生じる可能性があると警告しています。プールのデータサイズを増やす、書き込みを再試行する、または強制的にアクティベーションを行うだけでは、このリスクは解消されません。

文書化された復旧手順は、影響を受けるプールをオフラインで非アクティブ化し、を使用してその薄いメタデータを修復しlvconvert --repair VG/ThinPool、を使用してメタデータ容量を拡張しlvextend --poolmetadatasize、その後、適切なオフラインツールを使用して影響を受ける各ファイルシステムをチェックすることです。たとえば、メタデータLVが2 GiB未満のプールでは、次のようなターゲットをレビューする必要がある場合があります。

sudo lvextend --poolmetadatasize 2G vgdata/pool0

これは、アクティブな破損したプールに対して無闇に実行するコマンドではありません。そのサイズは例であり、普遍的な要件ではありません。まず、現在のメタデータサイズ、使用可能なエクステント、正しい非アクティブ化、リカバリメディア、およびバックアップを確認してください。lvconvert --repairダウンタイムとリカバリの専門知識を考慮して計画する必要があります。LVM マニュアルには、失敗する可能性があり、データが回復できない場合があると記載されています。プールとファイルシステムが検証されるまで、古いメタデータ LV を保持してください。LVM 構成のバックアップではvgcfgbackup、シン プールのメタデータはバックアップされません。ビジネス上重要なデータについては、修復を試みる前に、SUSE サポートまたはストレージリカバリチームにご相談ください。

5. 自動拡張を有効にしてから、書き込みを確認します。

システムが安定したら、activationの セクションでプロアクティブな成長ポリシーを設定します/etc/lvm/lvm.conf。この例では、使用率が 70% のときに拡張を開始し、20% の成長を要求します。書き込みレートと利用可能な VG 容量に合わせて、これらの値を調整してください。

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

設定が正しい構成範囲に適用され、プールが監視されていることを確認してください。

sudo lvchange --monitor y vgdata/pool0

自動シンプール拡張は、LVM イベント監視 ( dmeventd) と十分な空きエクステントに依存します。SLES インストールで提供される監視サービス (たとえば、systemctl status lvm2-monitorそのユニットが存在する場所) を確認し、ログを確認してください。書き込みが拡張容量を超えた場合、または VG が既に満杯の場合は、しきい値によって保護が保証されません。LVMマニュアルの自動拡張ガイダンスとlvchange 監視オプションを参照してください。

修正がうまくいったことを確認してください。

プールの利用状況とVGの残容量の両方を読み取ってください。

sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata

Data%データプール拡張後には容量が減少しているはずでありMeta%、容量不足の状態を維持している必要があり、プールは新たなI/Oエラーなくアクティブな状態である必要があります。ファイルシステムの状態とアプリケーションログを確認し、一時停止中のワークロードを解放する前に、アプリケーションに適した小規模な書き込みおよび読み取りテストを実行してください。空き容量が確保された後もエラーが続く場合は、ファイルシステムとアプリケーションの整合性が評価されるまで、影響を受けるワークロードをオフラインのままにしてください。容量を増やしても、既に失敗または失われた書き込みを元に戻すことはできません。