(この質問は Hyper-v に特化していますが、Hyper-v に特有の回答がこのような一般的な説明に当てはまらない限り、私が実際に興味を持っているのは一般的な VM スナップショットの回答です。)
私は、かなり大きな VM インフラストラクチャ (数千台の VM) を備えた大企業で働いています。サーバー エンジニアの 1 人が、VM スナップショットの保存は長期間許可されていないと言っています。VM に大幅な変更を加える前に、フォールバックとしてスナップショットを作成することは許可されますが、変更後すぐに (数日後、変更によって何も壊れていないことが確認できたら) 削除する必要があります。
その手順には問題ありません。スナップショットが実際のバックアップなどの代理として機能するとは思っていません。また、環境内のスペースを節約したいという彼らの希望は尊重できます。私が同意できないのは、彼の理由です。後でスナップショットを削除する必要がある理由は、「スナップショットは無制限に大きくなる可能性があり、HDD に書き込むたびに、スナップショットに追加のデータが無制限に書き込まれるためです。これは、元の仮想 HDD をプロビジョニングする場合とは異なります。この場合は最大サイズを指定できます。スナップショットの最大サイズを指定することはできません。」
私の理解では、スナップショット イメージは親ディスク イメージからの DELTA です。たとえば、元のイメージに次のようなブロックがあるとします。
0101 0101 0101
...そして、中間部分を次のように書き直します。
0101 1111 0101
...スナップショットには2つの違いのみが保存されます（データ構造のオーバーヘッドも加わり、複雑さは増しますが、ストレージの観点からは重要ではありません）。さらに、リライトこれらのブロックを元の状態に戻すと、デルタはそのブロックを破棄します (そのため、そのブロックの将来の読み取りでは元のイメージが読み取られます)。
(スナップショットが差分を保存する方法についてはよく知りません。すべてを整理するには非常に複雑な構造が必要であることは確かです。差分を保存するという原則にのみ興味があり、変更の「実行履歴」には興味がありません。)
彼によると、スナップショットはそのような動作をしないそうです。つまり、データ ブロックがある場合、それを変更し、その後元に戻すと、これを行うたびにスナップショットが大きくなり、最終的に大量のディスク領域を消費することになるそうです。
私の理解では、スナップショットは元のイメージのサイズを超えることはなく (たとえば、HDD 上のすべてのビットを文字通り反転すると、デルタはそれを保存します)、一定のオーバーヘッド サイズも発生する可能性があります。彼は、これは真実ではなく、仮想 HDD への書き込みが増えるにつれて VM スナップショットは無制限に大きくなると考えているようです。
VM スナップショットの仕組みについて何か誤解しているのでしょうか?
答え1
エンジニアは適切な方法に従っていますが、その理由は間違っています。VHDX (または使用されている仮想ディスク テクノロジ) が次のことを実現するという点では正しいです。
- 書き直すときは、書き直しの際、新しく書き直すのではなく、書き直したブロックを再利用する
- 親仮想ディスクの最大構成サイズと同じハード サイズ制限を設定します。スナップショットの最大サイズを指定できないのは、親 VHDX で既に最大サイズが指定されているためです。
ただし、ブロックが元の状態に戻された場合に、以前に書き込まれたデルタを破棄するメカニズムは知りません。ソース ブロックとデルタ ブロックで差分アルゴリズムを実行する場合と、ブロック書き込みの単純な記録を保持する場合のパフォーマンス オーバーヘッドは、比較的小規模であってもかなり大きくなります。
ただし、VM のディスクの入れ替えがそれほど多くない限り、スナップショットがひどく大きくなることはおそらくないでしょう。
単一のスナップショットを持つ VM でもパフォーマンスの大幅な低下はありませんが、そのことについてはどこにも言及されていません。
スナップショットには、3 つの非常に現実的な問題があります。
- 環境の問題により、AVHDXディスクが孤立する可能性がある
- スナップショットが存在する毎分ごとに、それは「価値」から「責任」へとスペクトルに沿って移動する。
- データは重複しない
また、スナップショットは本質的には無制限に拡大することはできませんが、スナップショットに対する制御がない環境を想像してみてください。理論上は、1 つのスナップショットが親の割り当てサイズの 2 倍に拡大する可能性があります。Microsoft は VM ごとに 50 スナップショットのハード キャップを設定しましたが、これは「まあ、あなたはただの愚か者だ」という一種のフェイルセーフとしてのみであり、テクノロジで必要なためではありません。したがって、VM の理論上の上限は、割り当てサイズの 51 倍です。これは起こりそうにありませんが、複数のスナップショットを持つ VM がいくつかあるだけでも、ストレージ管理者が頭を悩ませる可能性があることはわかります。これは、合理的なスナップショットの使用制限を設定することのメリットになります。
スナップショットの環境問題
このカテゴリの問題の根本原因としては、さまざまなことが考えられます。すべては、1つの根本的な問題に集約されます。親VHDXがどれでもそうしないと、AVHDX は完全に無効になり、まったく役に立たなくなります。所有 VM の電源がオンになっている場合、このような変更は非常に困難になります。ただし、所有 VM の電源がオフになっている場合、親 VHDX は単なるファイルです。Hyper-V または他のシステムは、子 AVHDX にアクセスしようとするまで、何も問題がないことを認識しません。
スナップショットの存続期間が長くなるほど、特に複数の管理者がいる環境では、問題が発生する可能性が高くなります。VM に複数のスナップショットがある場合、問題が複雑化する可能性があります。
この問題はスナップショットに特有のものではなく、どの仮想ディスク差分システムでも発生する可能性があります。
スナップショットは年月とともに価値が下がる
これがスナップショットを長期間保存しない主な理由です。あなたが正しく推測したように、差分メカニズムはない変更の履歴記録を保持します。ブロックへの最新の変更のみが保持されます。したがって、スナップショット後の形式で現在存在する仮想マシンと、スナップショットが取得されたときに存在していた VM のみが存在します。古い状態に戻すか、新しい状態を維持するかを選択できます。中間はありません。
議論のために (そして実際に起こったこととして)、すべてが 1 台の仮想マシンで実行される小規模な Exchange 環境があるとします。Exchange 2013 から Exchange 2016 にアップグレードする前にスナップショットを作成します。その後、1 年間実行します。そのスナップショットは何の役に立つでしょうか。そのスナップショットに戻しますか。削除すると、そのマージにどのくらいの時間がかかるか推測できますか。
スナップショットはデータを複製しない
スナップショットの目的は、仮想マシンを特定の時点にすばやく戻すことです。これは、仮想マシンの状態を直接変更することによって行われます。データの複製は作成されません。AVHDX が破損した場合、有効な情報は親のみに保持され、スナップショット以降の変更は失われます。親 VHDX が破損した場合、両方のファイルは役に立ちません。また、AVHDX にアクセスして変更されたデータのみを取り出すことができるツールは知りません。したがって、意味のある期間にわたってさまざまな状態を維持するには、バックアップが最適なオプションです。スナップショットほど高速でも便利でもありませんが、他のすべての問題に対処します。