Proxmox VE 9系環境におけるSnapshot as Voume Chainの性能影響評価

Last updated at 2025-10-02Posted at 2025-08-27

はじめに

これまでProxmox VE環境でのLVMスナップショット機能について、複数回にわたる検証を実施してきました。従来、iSCSI LUNに構成したLVMスナップショットは、Proxmox VEとしては非対応でしたが、LVMで手動実行することは可能でした。しかし、手動実行による検証では、スナップショット数の増加に伴い最大46.4倍という深刻な性能劣化が確認されており、実用に耐えるものではありませんでした。

一方、Proxmox VE 9.0で導入されたSnapshot as Volume Chain方式（Technology Preview）では、100GBディスクでのスナップショット作成・ロールバックがわずか2.7秒で完了する結果が確認されています。

本記事では、この新しいSnapshot as Volume Chain方式において、従来の手動LVMスナップショットで問題となっていたスナップショット数増加による性能影響がどの程度改善されているかを定量的に評価します。

✅ 本記事のポイント

Spapshot as Volume Chain方式でのスナップショット数による性能影響測定

従来の手動LVMスナップショットとの性能比較

Technology Preview機能としての制限事項と注意点の明確化

背景：従来の手動LVMスナップショットの課題

従来の手動LVMスナップショット方式の問題

これまでの検証で明らかになった手動LVMスナップショット方式の性能問題：

スナップショット数	ファイル作成速度	性能劣化率
0個	9,236.5 ファイル/秒	-
1個	313.5 ファイル/秒	29.5倍劣化
2個	199.2 ファイル/秒	46.4倍劣化

主要な問題点：

Copy-on-Write（CoW）メカニズムによる大きなオーバーヘッド
I/Oレイテンシの劇的増加（22.50ms → 309.85ms）
Write IOPSの大幅減少（3,675.78 → 1,323.55）
実用レベルで使用困難な処理時間

重要な背景：

iSCSI LUNに構成したLVMスナップショットは、従来Proxmox VEとして非対応
LVMコマンドによる手動実行は可能だったが、性能面で実用性に疑問
結果として、多くの環境でスナップショット機能が敬遠される状況

Snapshot as Volume Chain方式の導入

Proxmox VE 9.0のSnapshot as Volume Chain方式（Technology Preview）検証結果：

主要な結果：

スナップショット作成（100GB）：2.516秒
ロールバック（100GB）：2.697秒
ゼロクリア無効化により98%の処理時間短縮
実ファイルシステムでのデータ整合性確認

技術的特徴：

Chain方式による効率的な差分管理
ゼロクリア処理の最適化（saferemove 0設定）
大容量でも処理時間がほぼ一定

検証目的と仮説

検証の目的

Snapshot as Volume Chain方式でのスナップショット数による性能影響測定
- スナップショット0個、1個、2個での性能比較
- 従来の手動LVMスナップショットで確認された劣化パターンとの比較
実運用可能性の評価
- 適切なスナップショット運用戦略の検討
- 容量設計指針の確立

検証仮説

仮説1: Snapshot as Volume Chain方式では、スナップショット数増加による性能劣化が改善される
仮説2: 従来の手動方式で見られた29.5-46.4倍の劣化が軽減される
仮説3: 実用的なレベルでの性能を維持できる可能性がある

検証環境

システム構成

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

ハードウェア仕様

Proxmox VEホスト（tx1320m1）

CPU: Intel Xeon E3-1240 v3 @ 3.40GHz（8コア）
メモリ: 31.30 GiB
カーネル: Linux 6.14.8-2-pve
Proxmox VE: pve-manager/9.0.5

TrueNASホスト（iSCSIターゲット）- 仮想マシン環境

仮想化基盤: Proxmox VE 8.3.0上で動作
物理ホスト: AMD Ryzen 5 5600G with Radeon Graphics（12コア）
メモリ: 62.18 GiB

ストレージ構成

最適化された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  # ← Snapshot as Volume Chain有効化

4層仮想化ストレージアーキテクチャ

RHEL9アプリケーション（測定スクリプト）
    ↓ システムコール（write/read）
RHEL9ファイルシステム（ext4/xfs）
    ↓ ブロックI/O
Proxmox VE 9.0.5 LVM論理ボリューム（vm-105-disk-0）
    ↓ デバイスマッピング
iSCSI-LVM-VG（Volume Group）- Snapshot as Volume Chain方式
    ↓ 物理ボリューム
/dev/sdb（iSCSIデバイス）
    ↓ iSCSIプロトコル（ネットワーク）
TrueNAS仮想マシン（Proxmox VE 8.3基盤）
    ↓ 仮想化レイヤー
物理ストレージ（AMD Ryzen 5 5600G環境）

測定手法

使用スクリプト（従来検証と同一）

本検証では、従来の手動LVMスナップショット性能評価で使用したものと全く同じスクリプトを使用します：

1. ファイル作成スクリプト

機能: 指定されたディレクトリ構造（1,048フォルダ）に大量のファイル（104,857個）を作成
ファイルサイズ: 100KB固定
総データ量: 約10GB
測定項目: ファイル作成時間、作成速度（ファイル/秒）

2. ファイル更新スクリプト

機能: 作成済みファイルに対する段階的更新処理
更新パターン:
- 初回ファイル作成: 0x00パターン（全てゼロ）
- 1回目ファイル更新: 0xffパターン（全て1）
- 2回目ファイル更新: 0x55パターン（交互パターン1）
- 3回目ファイル更新: 0xaaパターン（交互パターン2）

3. リアルタイムモニタリングスクリプト

機能: システムリソース使用状況の継続監視
監視項目: CPU使用率、メモリ使用量、ディスクI/O統計
取得間隔: 1秒間隔
出力形式: CSV形式でのログ出力

スナップショット作成方法

従来検証では手動LVMコマンドを使用していましたが、今回はProxmox VEのコマンドラインでの統一的な操作を実施します：

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

# スナップショット一覧確認
qm listsnapshot <vmid>

# スナップショット削除
qm delsnapshot <vmid> <snapshot_name>

測定結果

スナップショット作成時間

Proxmox VE 9.0 Snapshot as Volume Chain方式におけるスナップショット作成時間：

# スナップショット1個目作成
root@tx1320m1:~# time qm snapshot 105 performance-test-1 --description "Performance test with 1 snapshot"
snapshotting 'drive-scsi0' (iSCSI-LVM:vm-105-disk-0.qcow2)
external qemu snapshot
Creating a new current volume with performance-test-1 as backing snap
  Renamed "vm-105-disk-0.qcow2" to "snap_vm-105-disk-0_performance-test-1.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_performance-test-1.qcow2 backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16

real    0m2.864s
user    0m0.861s
sys     0m0.331s

# スナップショット2個目作成
root@tx1320m1:~# time qm snapshot 105 performance-test-2 --description "Performance test with 2 snapshot"

real    0m2.828s
user    0m0.843s
sys     0m0.319s

結果: 100GBディスクでも約3秒でスナップショット作成が完了。従来検証で確認された2.5秒と同等の高速性能を維持。

ファイル作成性能測定結果

スナップショット数	作成時間	ファイル作成速度	前回比較
0個	9.29秒	11,288.2 ファイル/秒	ベースライン
1個	8.79秒	11,928.8 ファイル/秒	1.06倍
2個	9.59秒	10,928.6 ファイル/秒	0.97倍

結果: スナップショット数の増加による性能劣化がほとんど見られない。スナップショット1個時に若干の性能向上を確認。

システムリソース使用状況比較

項目	スナップショット0個	スナップショット1個	スナップショット2個
CPU使用率（平均）	2.56%	5.15%	5.19%
CPU使用率（最大）	37.5%	38.9%	38.2%
ロードアベレージ（平均）	0.60	0.94	1.09
ロードアベレージ（最大）	1.48	1.46	1.37
メモリ使用率	19.1%	21.5%	22.8%
メモリ使用量	1.11 GB	1.30 GB	1.40 GB
Write IOPS（平均）	1,457	3,617	3,538
I/Oレイテンシ（平均）	11.3ms	23.7ms	24.6ms
ディスク書き込み（平均）	108 MB/s	268 MB/s	261 MB/s

従来の手動LVMスナップショットとの比較

性能劣化パターンの違い

スナップショット数	手動LVM方式劣化率	Snapshot as Volume Chain方式劣化率	改善効果
0個	1.0倍	1.00倍	ベースライン
1個	29.5倍劣化	0.95倍（改善）	大幅改善
2個	46.4倍劣化	1.03倍劣化	大幅改善

ファイル作成速度の比較

スナップショット数	手動LVM方式	Snapshot as Volume Chain方式	性能比
0個	9,236 ファイル/秒	11,288 ファイル/秒	122.2%
1個	314 ファイル/秒	11,929 ファイル/秒	3,805.0%
2個	199 ファイル/秒	10,929 ファイル/秒	5,486.2%

I/Oレイテンシの改善効果

スナップショット数	手動LVM方式	Snapshot as Volume Chain方式	改善倍率
0個	22.5ms	11.3ms	2.0倍改善
1個	209.2ms	23.7ms	8.8倍改善
2個	309.9ms	24.6ms	12.6倍改善

性能劣化分析

1. 従来の手動LVMスナップショットの問題が大幅改善

手動LVM方式の課題：

スナップショット1個で29.5倍の性能劣化
スナップショット2個で46.4倍の性能劣化
Copy-on-Write処理による深刻なI/Oボトルネック
実用レベルでの使用が困難な処理遅延

Snapshot as Volume Chain方式での改善：

スナップショット数による性能劣化がほぼ解消
スナップショット1個時に若干の性能向上（0.95倍）
I/Oレイテンシの大幅改善（8.8-12.6倍）
実用レベルでの性能を実現

2. 技術的改善点

Chain方式の効率性：

従来CoW方式: 毎回の書き込み時に重複処理
Snapshot as Volume Chain方式: 効率的な差分管理による軽量処理

ゼロクリア最適化の効果：

saferemove 0設定により不要な処理をスキップ
メタデータ管理の最適化
物理I/O負荷の軽減

3. 実運用への影響

運用面での改善：

スナップショット機能の実用的な活用が可能
バックアップ戦略の選択肢拡大
システム変更作業の安全性向上
障害復旧時間の短縮

技術的背景の変化：

従来: iSCSI LUNでのLVMスナップショットはProxmox VE非対応、手動実行も実用性に疑問
現在: Snapshot as Volume Chain方式により正式サポート予定であり、実用レベルの性能を達成

実運用での検討事項

スナップショット運用戦略

容量設計指針（重要な制約事項）：

推奨VG容量 = ディスクサイズ × (計画スナップショット数 + 1) × 1.5
例：100GBディスク、2スナップショット想定
    → 450GB以上のVG容量を確保

運用フロー：

事前容量確認: vgsコマンドで十分な空き容量を確認
スナップショット作成: qm snapshotで作成
作業実施: システム変更作業を実行
結果確認: 問題なければ運用継続、問題あればロールバック
定期クリーンアップ: 不要なスナップショットの削除

監視・アラート設定

重要な監視項目：

VG空き容量の継続監視
スナップショット使用率の追跡
I/Oレイテンシの異常検知

制限事項と注意点

Technology Preview機能としての制限

開発段階の機能
- Proxmox VE 9.0でのTechnology Preview機能
- 本番環境導入前に十分な検証期間が必要
- 想定外のバグが存在する可能性
容量制約（重要）
- Snapshot as Volume Chain方式でも、スナップショット作成時には元ディスクサイズ分の空き容量が必要
- 容量不足時は作成エラーとなるため、事前の容量設計が必須
セキュリティ考慮事項
- saferemove 0設定により、削除データが物理的に残存
- 単一テナント環境では問題ないが、マルチテナント環境では要検討

検証環境の特殊性

4層仮想化環境での測定結果
iSCSI経由でのストレージアクセス
TrueNAS仮想マシンによるストレージ提供

一般的な物理環境や直接接続ストレージでは、異なる結果となる可能性があります。

まとめ

検証成果の総括

今回の検証により、Proxmox VE 9.0 Snapshot as Volume Chain方式が従来の課題を改善する有望な技術であることが確認されました。

主要な成果：

スナップショット性能問題の大幅改善
- 従来の29.5-46.4倍劣化 → ほぼ劣化なし
- ファイル作成速度で大幅な性能向上
- I/Oレイテンシで8.8-12.6倍の改善
実運用可能性の確認
- スナップショット機能の実用的な活用が可能
- システム変更作業の安全性向上
- 障害復旧時間の短縮
運用選択肢の拡大
- スナップショットを活用する運用の検討が可能
- バックアップ戦略の選択肢拡大
- 従来の制約からの解放

技術的意義

Snapshot as Volume Chain方式による改善：

従来: iSCSI LUNでのLVMスナップショットはProxmox VE非対応、手動実行も実用性に疑問
現在: Snapshot as Volume Chain方式により正式サポートされ、実用レベルの性能を達成

今後の展望と注意点

Technology Preview機能としての位置づけ：

現時点では開発段階の機能であり、想定外のバグが存在する可能性
本番環境での使用前に、十分な検証期間と慎重な評価が必要
今後の正式版リリースでの更なる改善が期待される

実運用での検討事項：

適切な容量設計の重要性
継続的な監視・メンテナンスの必要性
環境固有の特性を考慮した検証の実施

最終的な評価

Proxmox VE 9.0 Snapshot as Volume Chain方式は、従来の課題を改善する有望な技術ですが、Technology Preview段階であることを十分に理解した上で、慎重な検証を経て導入を検討することを推奨します。

適切な容量設計と十分な検証を行えば、従来の制約を大幅に改善し、運用効率と安全性の向上を期待できる技術であることが確認できました。

この検証結果が、Proxmox VE環境でのストレージ運用の参考となることを期待しています。