0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Proxmox VE 9.0 Backing Chain LVM - 実運用検証:RHEL9による実践テスト

Posted at

はじめに

これまでの検証シリーズでは、Proxmox VE 9.0のBacking Chain LVM機能について段階的に検証を進めてきました。設定手順の確立、基本動作の確認、そしてゼロクリア最適化による大幅な性能向上を実証してきました。

今回は検証の集大成として、実際のOSインストールと実運用を想定した総合検証を実施します。RHEL9の完全インストール、ファイルシステムの実際の変更、そして最適化設定による高速スナップショット運用の実践的な検証を行います。

本記事のポイント

  • 実運用規模(100GB)でのBacking Chain LVM検証
  • RHEL9完全インストール環境での実践テスト
  • ゼロクリア無効化による高速化の実証
  • 重要な発見:容量不足時のスナップショット作成制限

これまでの検証結果サマリー

前回までの主要成果

第1回 - 設定手順編

  • iSCSI + LVM環境でのBacking Chain機能有効化
  • storage.cfg設定による機能の簡単な有効化を確認

第2回 - 動作確認(失敗編)

  • 100GBディスクでの容量問題と長時間処理の課題発見
  • 大容量環境での検証アプローチの重要性を確認

第3回 - 動作確認(成功編)

  • 1GBディスクでの基本機能完全動作確認
  • 約102秒のゼロクリア処理時間を測定

第4回 - ゼロクリア最適化検証

  • saferemove 0:98%の処理時間短縮(102秒→1.8秒)
  • saferemove_throughput 50M:70%の処理時間短縮(102秒→30秒)

今回の検証目的

検証スコープ

  1. 実運用規模での機能検証

    • 100GBディスクでのBacking Chain LVM動作確認
    • 実際のOS環境でのスナップショット運用
  2. 最適化設定の効果測定

    • saferemove 0設定での大容量処理時間短縮効果
    • 実用的なファイルシステム変更シナリオでの検証
  3. 実践的な運用シナリオ

    • OSインストール後のスナップショット取得
    • システム設定変更とロールバック
    • 実用的なワークフローの確立

検証環境

システム構成

Proxmox VE: 9.0
ノード名: tx1320m1
iSCSI Target: TrueNAS
テストVM: RHEL9-Production-Test (VM ID: 105)
仮想ディスク: 100GB(実運用規模)
OS: Red Hat Enterprise Linux 9

ストレージ設定

最適化されたstorage.cfg設定

lvm: iSCSI-LVM
        vgname iSCSI-LVM-VG
        base TrueNAS:0.0.0.scsi-36589cfc0000007974c3b8445544ea1fc
        content images,rootdir
        saferemove 0  # ← 最適化設定:ゼロクリア無効化
        shared 1
        snapshot-as-volume-chain 1

仮想マシン作成

qm create 105 --name "RHEL9-Production-Test" \
  --memory 8192 --cores 4 --sockets 1 --cpu host \
  --net0 virtio,bridge=vmbr0,firewall=1 \
  --scsi0 iSCSI-LVM:100,format=qcow2 \
  --scsihw virtio-scsi-single \
  --machine q35 \
  --ostype l26 --agent 1 \
  --ide2 local:iso/rhel-9.6-x86_64-dvd.iso,media=cdrom

作成結果

  Rounding up size to full physical extent <100.02 GiB
  Logical volume "vm-105-disk-0.qcow2" created.
Formatting '/dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=107374182400 lazy_refcounts=off refcount_bits=16
scsi0: successfully created disk 'iSCSI-LVM:vm-105-disk-0.qcow2,size=100G'

実践検証シナリオ

フェーズ1: RHEL9インストールとベースラインスナップショット

1-1. RHEL9インストール

実施内容

  • WebUIからRHEL9の標準インストールを実施
  • インストール完了後、VMをシャットダウン

1-2. インストール完了後のスナップショット作成

time qm snapshot 105 baseline-after-install --description "Clean RHEL9 installation baseline"

実行結果

snapshotting 'drive-scsi0' (iSCSI-LVM:vm-105-disk-0.qcow2)
  Renamed "vm-105-disk-0.qcow2" to "snap_vm-105-disk-0_baseline-after-install.qcow2" in volume group "iSCSI-LVM-VG"
  Rounding up size to full physical extent <100.02 GiB
  Logical volume "vm-105-disk-0.qcow2" created.
Formatting '/dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2', fmt=qcow2 cluster_size=131072 extended_l2=on preallocation=metadata compression_type=zlib size=107374182400 backing_file=snap_vm-105-disk-0_baseline-after-install.qcow2 backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16

real    0m2.516s
user    0m0.837s
sys     0m0.293s

重要なポイント

  • 処理時間:2.516秒 - 100GBでも非常に高速
  • スナップショット作成時にゼロクリア処理は発生しない

フェーズ2: ファイルシステム変更とロールバック検証

2-1. VM起動とファイル作成

実施内容

  • VM起動後、ファイルシステムにテストファイルを作成
  • ホームディレクトリに「TESTFILE」を作成し存在確認

2-2. ロールバック実行

time qm rollback 105 baseline-after-install

実行結果

  Logical volume "vm-105-disk-0.qcow2" successfully removed.
  Rounding up size to full physical extent <100.02 GiB
  Logical volume "vm-105-disk-0.qcow2" created.
Formatting '/dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2', fmt=qcow2 cluster_size=131072 extended_l2=on preallocation=metadata compression_type=zlib size=107374182400 backing_file=snap_vm-105-disk-0_baseline-after-install.qcow2 backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16

real    0m2.697s
user    0m0.855s
sys     0m0.356s

重要なポイント

  • 処理時間:2.697秒 - 100GBでも超高速
  • ゼロクリア処理が完全にスキップされている

2-3. 復旧確認

結果

  • VM起動後、作成したTESTFILEが完全に削除されていることを確認
  • システムがインストール直後の状態に完全復旧
  • データ整合性も完全に保持

フェーズ3: 容量制限の発見

3-1. 重要な発見:容量不足時のスナップショット作成制限

検証前のストレージ状況

vgs
  VG           #PV #LV #SN Attr   VSize   VFree
  iSCSI-LVM-VG   1   4   0 wz--n- 379.99g <78.96g

追加スナップショット作成の試行

time qm snapshot 105 baseline-after-install2 --description "Clean RHEL9 installation baseline"

エラー結果

snapshotting 'drive-scsi0' (iSCSI-LVM:vm-105-disk-0.qcow2)
  Renamed "vm-105-disk-0.qcow2" to "snap_vm-105-disk-0_baseline-after-install2.qcow2" in volume group "iSCSI-LVM-VG"
  Rounding up size to full physical extent <100.02 GiB
  Renamed "snap_vm-105-disk-0_baseline-after-install2.qcow2" to "vm-105-disk-0.qcow2" in volume group "iSCSI-LVM-VG"
snapshot create failed: starting cleanup
lvcreate 'iSCSI-LVM-VG/vm-105-disk-0.qcow2' error:   Volume group "iSCSI-LVM-VG" has insufficient free space (20213 extents): 25604 required.

real    0m1.490s
user    0m0.706s
sys     0m0.248s

重要な発見

  • Backing Chain方式でも、スナップショット作成時には元ディスクサイズと同等の空き容量が必要
  • 100GBディスクの場合、VGに100GB以上の空きが必要
  • 容量不足の場合、自動的にcleanup処理が実行される

フェーズ4: スナップショット削除とストレージ回復

4-1. スナップショット削除

time qm delsnapshot 105 baseline-after-install

実行結果

vm-105-disk-0.qcow2: deleting snapshot 'baseline-after-install' by commiting snapshot 'current'
running 'qemu-img commit /dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2'
Image committed.
delete vm-105-disk-0.qcow2
  Logical volume "vm-105-disk-0.qcow2" successfully removed.
rename snap_vm-105-disk-0_baseline-after-install.qcow2 to vm-105-disk-0.qcow2
  Renamed "snap_vm-105-disk-0_baseline-after-install.qcow2" to "vm-105-disk-0.qcow2" in volume group "iSCSI-LVM-VG"

重要なポイント

  • ゼロクリア処理が完全にスキップ(saferemove 0設定の効果)
  • 削除処理も数秒で完了
  • qemu-img commit処理により、変更内容が正しく統合

4-2. ストレージ容量の回復確認

削除後の容量状況

vgs
  VG           #PV #LV #SN Attr   VSize   VFree
  iSCSI-LVM-VG   1   3   0 wz--n- 379.99g 178.97g

容量回復の確認

  • 削除前:78.96GB空き → 削除後:178.97GB空き
  • 約100GB の容量が正常に回復

検証結果の総合評価

処理時間測定結果

操作 処理時間 備考
スナップショット作成(100GB) 2.516秒 -
ロールバック(100GB) 2.697秒 ゼロクリア無効化効果
スナップショット削除(100GB) 数秒 ゼロクリア無効化効果

機能検証結果

検証項目 結果 備考
RHEL9インストール環境でのスナップショット作成 ✅ 成功 2.5秒で完了
実ファイル変更後のロールバック ✅ 成功 2.7秒で完了、データ完全復旧
データ完全性の確認 ✅ 成功 作成したファイルの削除を確認
スナップショット削除とクリーンアップ ✅ 成功 容量完全回復
容量不足時の動作 ⚠️ 制限あり 空き容量不足時はスナップショット作成不可

重要な発見と知見

1. 容量設計の重要性

発見した制約

  • Backing Chain方式でも、スナップショット作成時には元ディスクサイズ分の空き容量が必要
  • 100GBディスクなら、VGに100GB以上の空きが必須
  • 容量不足時は自動的にcleanup処理が実行され、エラーで終了

実運用への影響

推奨容量設計:
- 単一スナップショット運用:ディスクサイズの2倍以上
- 複数スナップショット運用:ディスクサイズ × (スナップショット数 + 1) + α

2. 最適化設定の効果実証

saferemove 0の効果

  • 100GBディスクでのロールバック:2.7秒
  • 100GBディスクでの削除:数秒
  • 実運用レベルでの劇的な効率化を実証

3. データ整合性の確認

実ファイルシステムでの検証結果

  • 作成したファイルの削除確認

実運用での推奨事項

1. 運用手順の確立

スナップショット作成前の確認

# 1. 容量確認
vgs

# 2. スナップショット作成
qm snapshot <vmid> <name> --description "<description>"

# 3. 結果確認
qm listsnapshot <vmid>

定期的なクリーンアップ

# 古いスナップショットの削除
qm delsnapshot <vmid> <old_snapshot>

# 容量確認
vgs

2. 監視・アラート設定

容量監視の重要性

  • VG空き容量の定期監視
  • 閾値を下回った場合のアラート
  • 自動クリーンアップ機能の検討

注意事項と制限事項

技術的制限事項

  1. 容量制約

    • スナップショット作成時に元ディスクサイズ分の空き容量が必要
    • 容量不足時はスナップショット作成が失敗
  2. Technology Preview段階

    • Proxmox VE 9.0での試験機能
    • 本番環境導入時は十分な検証が必要
  3. セキュリティ考慮

    • saferemove 0設定によりデータが物理的に残存
    • 単一テナント環境では許容可能

まとめ

検証成果の総括

今回の実運用検証により、Proxmox VE 9.0のBacking Chain LVM機能の実用性と制約の両方が明確になりました。

主要な成果

  1. 100GB実運用環境での安定動作確認
  2. ゼロクリア無効化による処理時間短縮効果(数十分 → 数秒)
  3. 実ファイルシステムでのデータ整合性確認
  4. 重要な容量制約の発見と対策指針の確立

実運用価値の評価

劇的な運用改善効果

  • スナップショット運用の心理的ハードル完全除去
  • システム変更作業の安全性大幅向上
  • 障害復旧時間の革命的短縮
  • ただし、適切な容量設計が前提条件

関連記事・参考情報

本シリーズ記事

  • 第1回:「Proxmox VE 9.0 Backing Chain LVM - 設定手順編」
  • 第2回:「Proxmox VE 9.0 Backing Chain LVM - 動作確認(失敗編)」
  • 第3回:「Proxmox VE 9.0 Backing Chain LVM - 動作確認(成功編)」
  • 第4回:「Proxmox VE 9.0 Backing Chain LVM - ゼロクリア最適化検証」
  • 第5回:「Proxmox VE 9/0 Backing Chain LVM - RHEL9による実践テスト」
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?