VMバックアップのフリーズがゲストI/Oによるものか、ホストストレージによるものかを見分ける方法
ゲストエージェントのフリーズのタイミングをホストのデータストア遅延と関連付けます。ホストの負荷上昇より前にフリーズするなら原因はゲスト側にあり、ゲスト全体で遅延が発生するならストレージが原因である可能性があります。
この判断が重要になるのは、スナップショットモードのバックアップ中にVMが一時停止したり応答しなくなったりする場合です。競合する状態は、ゲストのクエiesce、ファイルシステムまたはアプリケーションのフラッシュ遅延と、ホストのデータストア、スナップショット、ネットワークまたはバックアップ先の遅延です。保存済みの構成と使い捨てデータから始め、一度に1つの分岐だけを観察し、データ損失、権限または可用性のリスクが拡大する場合は停止してください。
ゲストのクエiesce、ファイルシステムまたはアプリケーションのフラッシュ遅延と、ホストのデータストア、スナップショット、ネットワークまたはバックアップ先の遅延を切り分ける
変更を加える前に、ソフトウェアとファームウェアのバージョン、デバイス識別情報、マウントまたはネットワークパス、空き容量、権限、確認できる症状など、環境を記録します。ベースラインには、スナップショットモードのバックアップ中にVMが一時停止したり応答しなくなったりする状態を再現できるだけの詳細を残してください。
最初の候補は、ゲストのクエiesce、ファイルシステムまたはアプリケーションのフラッシュ遅延です。2つ目は、ホストのデータストア、スナップショット、ネットワークまたはバックアップ先の遅延です。現在のProxmox vzdumpの動作は、テストで使用する仕組みまたはコマンドの境界を定義しますが、この特定のホームサーバーでの観察に取って代わるものではありません。
判別テストを実行する前に、合格条件と停止条件を書き出します。合格とは、一方の分岐が予測した証拠が変化し、無関係なサービスは変わらないことです。不合格の場合は、推測に基づく修正を連鎖的に行うのではなく、システムを保存済みの状態に戻します。
管理された判別テストを1つ実行する
次の判別テストを使用します。1回の管理されたバックアップ中に、フリーズまたは再開イベント、ゲストディスクの遅延、ホストストレージの遅延、その他のVMの挙動にタイムスタンプを付けます。結果を変更した変数に帰属できるよう、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。
QEMUゲストエージェントの状態を使用して、分岐を実際に切り分けられるフィールドを選びます。その後、タイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、遅延、転送バイト数、権限、復旧状態を取得します。コマンドが正常終了しただけでは、テスト対象が識別情報、耐久性またはアプリケーション状態に関する主張である場合に十分とは限りません。
そのイベントが元の条件の一部である場合は、再起動、再接続、再マウントまたはコールドキャッシュの後にテストを1回繰り返します。最初の実行が破壊的である場合、または環境を復元できない場合は停止し、代わりに使い捨てのコピーで再現してください。
journalctl -u qemu-guest-agent
pvesh get /nodes/NODE/status
# タイムスタンプをデータストアの遅延と関連付ける証拠がどちらの分岐を支持するか解釈する
合格: 1台のゲストだけがフリーズし、ホストは正常なままである場合、またはホストのキューと遅延の上昇に伴って複数のゲストが遅くなる場合です。結論が普遍的な主張にならないよう、合格した正確なバージョン、識別情報、ワークロードを記録し、条件付きの結論として残します。
不合格: バックアップ帯域幅とスナップショットメタデータが両方の兆候を生じさせる可能性があるため、使い捨ての状態でのみクエiesceを無効にして再テストします。不合格でも、ネットワーク、メモリ、権限またはソースの一貫性が両方に影響する可能性があるため、自動的に反対の分岐が証明されたことにはなりません。エスカレーションする前に、これらの共有依存関係を切り分けてください。
例外または不明確な結果: ストレージまたはエージェントの設定を変更する前に、以前のバックアップモードへ戻し、ゲストのフリーズを解除します。復元可能なコピーが存在するまで、ログを保存し、修復、プルーニング、破棄、再パーティション、再帰的な所有者変更コマンドを実行しないでください。
一致する対応を適用し、元の障害を再現する
観察された分岐に対応する処置を適用し、その後、簡略化した代替テストではなく元の条件を再現します。1台のゲストだけがフリーズしホストは正常なままであるか、複数のゲストがホストキューと遅延の上昇に伴って遅くなる状態が、2サイクルまたは該当する再起動、スリープ、中断、負荷遷移にわたって確認された場合にのみ、この判断は有効です。
Proxmoxバックアップモードを使用して、最も近い依存ワークフローを確認します。ただし、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、リカバリポイントでは、以前のアクセス状態とタイミングを維持する必要があります。
停止境界は明確です。バックアップ帯域幅とスナップショットメタデータが両方の兆候を生じさせる可能性がある場合は、使い捨ての状態でのみクエiesceを無効にして再テストします。最後に検証済みの構成へ戻し、証拠を保持し、分岐が再現可能な場合にのみ、より深いプラットフォームまたはハードウェアのテストへエスカレーションしてください。
対象の結果が得られたら、シャットダウンの依存関係と比較し、修正によって隣接するサービスへリスクが移っていないことを確認します。新たなバックアップ、識別情報、タイムアウトまたは可用性の障害が発生した場合、対象テストが成功していても変更は失敗です。
FAQ
VMバックアップのフリーズ診断では、通常、ゲストのフリーズを無効にするとエージェントの問題だと証明できるのか、1回のバックアップ中にすべてのVMが一時停止するのはなぜか、停止モードはいつ使用すべきか、という点が残ります。以下の回答では、これらのエッジケースを主要な判断から分けて扱います。
合格条件の境界は変わりません。1台のゲストだけがフリーズしホストは正常なままであるか、複数のゲストがホストキューと遅延の上昇に伴って遅くなることです。後続の条件によってファイルシステム、識別情報、ネットワークパスまたはアプリケーションのバージョンが変わる場合は、その変更の影響を受ける判別テストだけを繰り返します。
バックアップ帯域幅とスナップショットメタデータが両方の兆候を生じさせる可能性がある場合は、実験を広げるのをやめ、使い捨ての状態でのみクエiesceを無効にして再テストします。その時点で、ストレージまたはエージェントの設定を変更する前に以前のバックアップモードへ戻し、ゲストのフリーズを解除します。プラットフォーム、ストレージまたはハードウェアの担当者へエスカレーションする前に、証拠を保存してください。
ゲストのフリーズを無効にすると、エージェントが原因だと証明できますか？
クエiesceの経路を切り分けられますが、アプリケーションの一貫性が低下する可能性があります。管理されたテストとしてのみ使用してください。
なぜ1回のバックアップ中にすべてのVMが一時停止するのですか？
ホストのストレージキュー、スナップショットメタデータまたはバックアップ帯域幅が、共有データストアに影響している可能性があります。
停止モードはいつ使用すべきですか？
正常なシャットダウンが必要で、その停止時間が復旧目標に収まる場合です。
同じワークロードによって、ゲストのクエiesce、ファイルシステムまたはアプリケーションのフラッシュ遅延、あるいはホストのデータストア、スナップショット、ネットワークまたはバックアップ先の遅延に沿って証拠が変化し、一致する対応によって別の問題を発生させずに元の症状が解消されたとき、診断は完了です。どちらの分岐も再現性を保てない場合は、ログと保存済みの状態をそのまま維持してください。不確実性は、さらに修正を積み重ねる理由ではなく、エスカレーションする理由です。
おすすめ商品
サポートとヒント
もっと読む
ストレージ交換後もNAS共有に古いファイルが表示される場合の確認と対処法
ローカルストレージをアクティブな共有とクリーンなクライアントで比較します。古い状態だと証明されたレイヤーのみを修復し、再接続と再起動後も結果が維持されることを確認します。
ファン、通気口、熱性能の基準値に関するミニPC冷却メンテナンスガイド
再現可能なアイドル時と負荷時の測定値を使用してください。まず外部の通気を清掃し、ファンの動作を確認してください。管理された再テストでも問題の証拠が残る場合にのみ、シャーシを開けてください。
BIOS、起動順序、デバイスのホームサーバーファームウェア更新チェックリスト
バージョン、UEFIエントリ、ストレージ、パススルーの状態を最初に記録します。1度に1つのレイヤーだけを更新し、検証に合格するまでコンソールとロールバックへのアクセスを確保してください。
