Proxmox VE 8系環境におけるLVMスナップショットの性能影響評価【再検証】

Last updated at 2025-08-27Posted at 2025-08-25

はじめに

本記事では、Proxmox VE 8系環境において、LVMスナップショット数の増加がファイルI/O性能とシステムリソースに与える影響を実測データで定量的に評価します。企業環境でのバックアップ戦略検討やシステム運用最適化の参考資料として、スナップショット0個、1個、2個の各設定での詳細な性能比較を行います。

昨日の検証においては、スナップショットサイズが少ないため、使用率が100%を超えていました。
このため、改めて検証を行いましたので結果を掲載します。

検証環境

ハードウェア構成

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
ブートモード: Legacy BIOS
ストレージ使用率: 0.32% (799.12 GiB / 2.53 TiB)

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

仮想化基盤: Proxmox VE 8.3.0/c1689ccb1065a83b上で動作
物理ホスト:
- CPU: AMD Ryzen 5 5600G with Radeon Graphics（12コア）
- メモリ: 62.18 GiB（使用率42.48%、26.41 GiB使用中）
- カーネル: Linux 6.8.12-4-pve
- ブートモード: EFI
- 稼働時間: 5日19時間16分12秒
TrueNAS仮想マシン:
- OS: TrueNAS-Scale
- 割り当て容量: 32.00 GiB（ブートディスク）
- iSCSIターゲット機能: 有効

3層ストレージアーキテクチャ

本検証環境では、以下の3層ストレージ構成を採用しています：

アーキテクチャ概要

第1層：TrueNAS仮想マシン（iSCSIターゲット層）
    ↓ 仮想化基盤（Proxmox VE 8.3）上で動作
    ↓ iSCSIプロトコル
第2層：Proxmox VE LVM（仮想化基盤ストレージ層）
    ↓ 仮想化
第3層：RHEL9仮想マシン（ゲストOS層）
    ↓ Proxmox VE 8.3で構築、9.0.5で動作継続

詳細なI/Oパス構成（4層仮想化アーキテクチャ）

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

各層の役割と特徴

第1層：TrueNAS仮想iSCSIターゲット層

役割: 仮想化されたiSCSIターゲットの提供
特徴: Proxmox VE 8.3基盤上でのブロックストレージ仮想化
影響範囲: 仮想化オーバーヘッド、ネットワークI/O、仮想ストレージ性能

第2層：Proxmox VE LVM仮想化基盤層

役割: 仮想マシン用ストレージの抽象化と管理
特徴: LVMによる論理ボリューム管理、スナップショット機能
影響範囲: 本検証の主要対象層（CoW処理によるオーバーヘッド）

第3層：RHEL9ゲストOS層

役割: アプリケーション実行環境
特徴: 仮想化されたブロックデバイスとしてストレージを認識
影響範囲: ファイルシステムレベルでの性能変動を体験

LVMスナップショット影響の伝播経路

直接影響（第2層）
- LVM層でのCopy-on-Write処理発生
- メタデータ更新オーバーヘッド
- 追加的なディスクI/O発生
間接影響（第3層への伝播）
- ゲストOSでのI/Oレスポンス時間増加
- ファイルシステムの待機時間増大
- アプリケーション処理速度の劣化
基盤影響（第1層での負荷）
- iSCSIネットワークトラフィック増加
- TrueNAS仮想マシンへの負荷増大
- 物理基盤（AMD Ryzen 5 5600G環境）への影響

Proxmox VE LVM構成（スナップショット1個時）

Volume Group (VG) 情報

root@tx1320m1:/tool/snapshot/bin# vgs
  VG           #PV #LV #SN Attr   VSize   VFree
  iSCSI-LVM-VG   1   2   1 wz--n- 379.99g 269.99g

Logical Volume (LV) 情報

スナップショット0個時:

root@tx1320m1:/tool/snapshot/bin# lvs
  LV            VG           Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  vm-101-disk-0 iSCSI-LVM-VG -wi-ao---- 100.00g

スナップショット1個時:

root@tx1320m1:/tool/snapshot/bin# lvs
  LV                                   VG           Attr       LSize   Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  vm-101-disk-0                        iSCSI-LVM-VG owi-aos--- 100.00g
  vm-101-disk-0-backup-20250825-203543 iSCSI-LVM-VG swi-a-s---  30.00g      vm-101-disk-0 36.10

スナップショット2個時:

root@tx1320m1:/tool/snapshot/bin# lvs
  LV                                   VG           Attr       LSize   Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  vm-101-disk-0                        iSCSI-LVM-VG owi-aos--- 100.00g
  vm-101-disk-0-backup-20250825-203543 iSCSI-LVM-VG swi-a-s---  30.00g      vm-101-disk-0 68.63
  vm-101-disk-0-backup-20250825-204843 iSCSI-LVM-VG swi-a-s---  30.00g      vm-101-disk-0 34.96

LVM構成詳細

iSCSI-LVM-VG ボリュームグループ仕様

総容量: 379.99GB（408.01GB環境での測定時）
空き容量: 269.99GB
使用率: 53%（運用環境）
Physical Volume数: 1（/dev/sdb - iSCSIデバイス）
Logical Volume数: 1-3（スナップショット数により変動）
スナップショット数: 0-2個（測定条件により変動）

Logical Volume構成

vm-101-disk-0: メインボリューム（100.00GB）
- 属性: owi-aos---（Origin, Write, Active, Open, Snapshot origin）
vm-101-disk-0-backup-20250825-203543: スナップショット1（30.00GB）
- 属性: swi-a-s---（Snapshot, Write, Active, Snapshot）
- データ使用率: 36.10%（1個時）/ 68.63%（2個時）
vm-101-disk-0-backup-20250825-204843: スナップショット2（30.00GB）
- 属性: swi-a-s---（Snapshot, Write, Active, Snapshot）
- データ使用率: 34.96%（2個時のみ存在）

4層仮想化ストレージ階層マッピング

RHEL9 (VM-101): /dev/vda (仮想ディスク)
    ↓ Proxmox VE 9.0.5仮想化層
Proxmox VE: vm-101-disk-0 (LVMボリューム)
    ↓ LVM抽象化層  
LVM: /dev/iSCSI-LVM-VG/vm-101-disk-0
    ↓ デバイスマッピング
Physical: /dev/sdb (iSCSIデバイス)
    ↓ iSCSIプロトコル（ネットワーク）
TrueNAS仮想マシン: iSCSIターゲット
    ↓ Proxmox VE 8.3仮想化層
AMD Ryzen 5 5600G物理基盤: 実際の物理ストレージ

仮想マシン仕様（測定対象）

OS: Red Hat Enterprise Linux 9
VM ID: 101
ディスク: vm-101-disk-0（100GB）
導入環境: Proxmox VE 8.3で初期構築
現在の動作環境: Proxmox VE 9.0.5（アップグレード後も継続使用）
用途: ファイルI/O性能測定環境

測定手法

使用スクリプト（GitHub flathill/Tools）

本検証では以下の3つのスクリプトを使用しました：

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

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

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

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

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

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

測定条件

測定データ仕様:
- 総データ量: 10GB
- ファイル数: 104,857個
- フォルダ数: 1,048個
- ファイルサイズ: 100KB（固定）
処理フロー:
1. 初回ファイル作成: 0x00パターンで全ファイル作成
2. 1回目更新処理: 0xffパターンで全ファイル更新
3. 2回目更新処理: 0x55パターンで全ファイル更新
4. 3回目更新処理: 0xaaパターンで全ファイル更新
スナップショット設定:
- パターン1: スナップショット0個（ベースライン）
- パターン2: スナップショット1個
- パターン3: スナップショット2個

測定結果

実測モニタリング期間

本検証では、2025年8月25日に以下の期間で連続的なシステムモニタリングを実施しました：

測定日時: 2025年8月25日
データ取得間隔: 1秒間隔
データポイント数: 約59,000-61,000個（条件により変動）
測定対象: CPU使用率、メモリ使用量、ディスクI/O統計、システム負荷

条件別測定期間:

スナップショット0個: 21:09-21:14（約5分間、148データポイント）
スナップショット1個: 20:36-20:47（約11分間、325データポイント）
スナップショット2個: 20:48-21:03（約15分間、428データポイント）

ファイル作成性能比較

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

ファイル更新処理性能

スナップショット数	平均更新時間	劣化率
0個	94.91秒	-
1個	104.43秒	1.10倍
2個	106.42秒	1.12倍

総実行時間比較

スナップショット数	総実行時間	劣化率
0個	296.08秒	-
1個	647.80秒	2.19倍
2個	845.59秒	2.86倍

リアルタイムモニタリング結果

スナップショット0個時のシステム状況

CPU使用率

平均CPU使用率: 5.56%
最大CPU使用率: 33.80%
CPUアイドル率: 94.44%
ロードアベレージ: 平均1.08, 最大1.25

メモリ使用状況

メモリ使用率: 平均29.64%
使用メモリ: 平均0.79 GB
SWAP使用: 0GB（未使用）

ディスクI/O統計

Write IOPS: 平均3,675.78, 最大13,172.0
平均I/Oレイテンシ: 22.50ms, 最大24.20ms
ディスク書き込み: 平均271.36MB/s, 最大1,836.50MB/s

スナップショット1個時のシステム状況

CPU使用率

平均CPU使用率: 2.58%
最大CPU使用率: 7.20%
CPUアイドル率: 97.42%
ロードアベレージ: 平均1.72, 最大2.56

メモリ使用状況

メモリ使用率: 平均30.10%
使用メモリ: 平均0.78 GB
SWAP使用: 0GB（未使用）

ディスクI/O統計

Write IOPS: 平均1,709.31, 最大3,591.0
平均I/Oレイテンシ: 209.18ms, 最大507.90ms
ディスク書き込み: 平均124.26MB/s, 最大221.20MB/s

スナップショット2個時のシステム状況

CPU使用率

平均CPU使用率: 2.20%
最大CPU使用率: 6.20%
CPUアイドル率: 97.80%
ロードアベレージ: 平均2.14, 最大2.88

メモリ使用状況

メモリ使用率: 平均32.18%
使用メモリ: 平均0.86 GB
SWAP使用: 0GB（未使用）

ディスクI/O統計

Write IOPS: 平均1,323.55, 最大3,664.0
平均I/Oレイテンシ: 309.85ms, 最大838.40ms
ディスク書き込み: 平均94.67MB/s, 最大221.90MB/s

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

項目	0個	1個	2個
CPU使用率（平均）	5.56%	2.58%	2.20%
CPU使用率（最大）	33.80%	7.20%	6.20%
Load Average（平均）	1.08	1.72	2.14
Load Average（最大）	1.25	2.56	2.88
メモリ使用率	29.64%	30.10%	32.18%
メモリ使用量	0.79 GB	0.78 GB	0.86 GB
Write IOPS（平均）	3,675.78	1,709.31	1,323.55
I/Oレイテンシ（平均）	22.50ms	209.18ms	309.85ms
ディスク書き込み（平均）	271.36MB/s	124.26MB/s	94.67MB/s
ファイル作成速度	9,236.5/秒	313.5/秒	199.2/秒

スナップショット容量設計の重要性

スナップショット容量拡張による改善効果

本再検証では、前回検証時の課題を踏まえ、スナップショット容量を10.00GBから30.00GBに拡張して実施しました。この変更により、以下の重要な改善効果が確認されました。

前回検証との比較

前回検証（スナップショット10.00GB）:

スナップショット使用率: 100.00%（容量満杯）
属性: swi-I-s---（Invalid状態）
問題: スナップショット容量不足による性能への追加的影響

今回検証（スナップショット30.00GB）:

スナップショット1個時使用率: 36.10%（余裕のある状態）
スナップショット2個時使用率: 68.63%（適切な使用率）
属性: swi-a-s---（Active状態）
改善: 容量不足による性能劣化要因を排除

容量設計の指針

推奨スナップショット容量算出:

基本容量 = データ変更量 × 1.5～2.0倍
安全マージン = 基本容量 × 1.3～1.5倍
最終容量 = 基本容量 + 安全マージン

本検証での実例:

想定データ変更量: 約10GB（全ファイル新規作成）
基本容量: 10GB × 1.5 = 15GB
安全マージン: 15GB × 2.0 = 30GB
結果: 30GBスナップショット容量で68.63%使用率（適切範囲）

容量不足が性能に与える影響

容量満杯時の追加オーバーヘッド:

スナップショット領域の競合: 限られた容量での書き込み競合
メタデータ処理負荷: 容量管理のための追加処理
I/O待機時間増加: 容量チェックとガベージコレクション処理
システム安定性への影響: Invalid状態への遷移リスク

適切な容量での効果:

スナップショット機能本来の性能特性での評価が可能
容量不足による誤差要因の排除
長期運用での安定性確保

性能劣化分析

1. ファイル作成性能の大幅劣化

スナップショット1個: 29.5倍の性能劣化
スナップショット2個: 46.4倍の性能劣化
主要因: Copy-on-Write（CoW）メカニズムによるオーバーヘッド

実測データに基づく詳細分析

Write IOPS性能劣化:

スナップショット0個 → 1個: 3,675.78 → 1,709.31（53.5%減少）
スナップショット1個 → 2個: 1,709.31 → 1,323.55（22.6%追加減少）
総合劣化率: 64.0%減少（0個 → 2個）

I/Oレイテンシ増加:

スナップショット0個 → 1個: 22.50ms → 209.18ms（829.8%増加）
スナップショット1個 → 2個: 209.18ms → 309.85ms（48.1%追加増加）
総合増加率: 1,277.3%増加（0個 → 2個）

ディスク書き込みスループット劣化:

スナップショット0個 → 1個: 271.36MB/s → 124.26MB/s（54.2%減少）
スナップショット1個 → 2個: 124.26MB/s → 94.67MB/s（23.8%追加減少）
総合劣化率: 65.1%減少（0個 → 2個）

3層構成でのCoW影響解析

第3層（RHEL9）: アプリケーションからの書き込み要求
    ↓ 通常の仮想化オーバーヘッド
第2層（Proxmox LVM）: ★CoW処理発生層★
    ├── 元データの読み取り（iSCSI経由）
    ├── スナップショット領域への書き込み
    └── 新データの書き込み
    ↓ 3倍のI/O発生（1回→3回）
第1層（TrueNAS）: 物理ストレージでの実際のI/O処理

CoW処理による追加オーバーヘッド：

通常時: アプリケーション書き込み → 1回の物理I/O
スナップショット1個: アプリケーション書き込み → 3回の物理I/O
スナップショット2個: アプリケーション書き込み → 5回の物理I/O

2. システムリソース使用率の変化

CPU使用率: 5.56% → 2.58% → 2.20%（測定期間の差による変動）
Load Average: 1.08 → 1.72 → 2.14（スナップショット数に比例して増加）
I/Oレイテンシ: 22.50ms → 209.18ms → 309.85ms（大幅な増加）
影響: ディスクI/O処理の大幅な遅延による全体的な性能低下

3. 更新処理への影響

軽微な劣化: 更新処理（0xff→0x55→0xaa）は比較的影響が少ない
理由: 既存ファイルの内容更新はCoWの影響を受けにくい
パターン別影響: 各更新パターン（0xff、0x55、0xaa）で同様の軽微な劣化傾向

3層構成での更新処理フロー

第3層（RHEL9）: ファイル内容更新（0x00→0xff→0x55→0xaa）
    ↓ 既存ブロックの上書き
第2層（Proxmox LVM）: 
    ├── 初回更新時のみCoW発生（0x00→0xff）
    └── 2回目以降は直接更新（0xff→0x55→0xaa）
    ↓ CoW影響は初回のみ
第1層（TrueNAS）: 通常の上書きI/O処理

更新処理でのCoW最適化：

初回更新: CoW処理が発生（元データのスナップショット保存）
2回目以降: 既にスナップショット済みのため直接上書き
結果: 更新処理は作成処理に比べて影響が軽微

4. 実測データに基づく短時間集中測定の特性

各条件5-15分間の集中的なモニタリングにより、以下の重要な知見が得られました：

メモリ使用量の安定性

実測値: スナップショット数に関係なく0.78-0.86GB範囲で安定
変動幅: ±0.08GB以内の微小な変動
特徴: LVMスナップショット数の増加がメモリ使用量に与える影響は軽微

CPU使用率のピーク特性

最大値: スナップショット0個時に最大33.80%を記録
発生タイミング: 大量ファイル作成処理時の瞬間的なスパイク
平均値との差: 平均5.56%に対して6.1倍の瞬間的な負荷増大

システム負荷の短時間集中測定による傾向

測定期間: 各条件5-15分間の集中測定による性能劣化パターンの確認
劣化パターン: スナップショット数に比例した一定の性能劣化を維持
安定性: 短時間測定期間中は性能特性が一定で、変動は最小限
リソース競合: I/Oレイテンシの大幅増加が最も顕著な影響要因として確認

運用への示唆

1. バックアップ戦略の最適化（3層構成特有の考慮点）

推奨: 短時間でのスナップショット取得・削除
回避: 長期間の複数スナップショット保持
代替案: 外部ストレージへの即座のバックアップ転送

3層構成でのバックアップ最適化戦略

物理基盤層での対策：
├── 高速ストレージの使用（AMD Ryzen 5 5600G環境）
├── 十分なメモリ確保（62.18 GiB）
└── CPU使用率の監視

TrueNAS仮想化層での対策：
├── 仮想マシンリソースの最適化
├── iSCSI接続の帯域確保
└── ネットワークレイテンシーの最小化

Proxmox VE層での対策：
├── スナップショット保持期間の短縮
├── 複数スナップショットの回避
├── バックアップ完了後の即座削除
├── 適切なスナップショット容量設計（データ量の2-3倍）
└── LVM性能チューニング

ゲストOS層での対策：
├── 大量ファイル処理のスケジューリング
├── バックアップ時間帯の調整
└── アプリケーション処理の分散

2. システム監視の重要性

監視項目: I/Oレイテンシ、Load Average、Write IOPSの継続監視
閾値設定: I/Oレイテンシ100ms超過、Load Average 2.0超過での警告設定
自動化: 性能劣化検知時の自動スナップショット削除

3. 運用タイミングの最適化

実行時間: 業務時間外でのスナップショット運用
バッチ処理: 大量ファイル処理前のスナップショット整理
リソース確保: 十分なディスクI/O帯域の確保

結論

Proxmox VE環境でのLVMスナップショット使用は、ファイル作成性能に対して29.5倍～46.4倍の大幅な性能劣化を引き起こすことが実証されました。特に大量の小さなファイルを扱うワークロードでは、スナップショット数の増加に比例して性能が劣化します。

企業環境での運用においては、バックアップの重要性とシステム性能のバランスを考慮し、適切なスナップショット容量設計と管理戦略の策定が不可欠です。本検証結果を参考に、各環境に最適化されたバックアップ・復旧戦略の構築を推奨します。

参考資料

測定スクリプト: GitHub flathill/Tools
Proxmox VE Documentation: LVM Storage Management
Red Hat Enterprise Linux: Performance Tuning Guide
検証環境: TrueNAS Scale + Proxmox VE 8系

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up