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