通常のスナップショットシステムの仕組み：LVM、ZFS（ここでは、一般に、別の歌は真実ですが、原則は同じです）およびその他
- 現時点ではディスク（Dcurrent_real）があり、スナップショットを注文しました。 スナップショットがすぐに作成されます。
- スナップショット（デルタ）は、開始以降に発生した変更を保存するように設計されています。
- この場合、物理的にDcurrent_realディスクのみが存在します。まあ、どこかにデルタが書き込まれます
- スナップショット時のディスクは、スキームDpastVirtual = Dcurrent_real-deltaに従って取得されます。
- したがって、Dcurrent_realがあり、それが実際のデルタであるため、不要になるとすぐにクラッシュする可能性があります。
アマチュアが設計した紳士ゴビンダの仕事、XenServerのスナップショット
- Dcurrent_realディスクのスナップショットを注文します。 これ以降、同じ「ベースコピー」に名前が変更されるため、単に存在しなくなります。
- スナップショット（デルタ）も変更を保存するために呼び出されますが、変更は正反対の時間、つまり ディスクの現在の状態から過去へではなく、過去の状態から現在へ。
- この場合、物理的にDpast_realディスク（同じベースコピー）+デルタのスナップショットが書き込まれます。
- スナップショットの時点ですぐにディスクがあります-ここでは、Dpast_realです。 ただし、ディスクは現在、Dcurrent_virtual = Dpast_real + deltaを組み合わせて取得されています。
- 実際、実際にはこれはそれほど遅くなりません。なぜなら、システムは書き込みと読み取りの両方の場合に、まだデルタのデータを乗り越えなければならないからです。
- しかし、デルタをどう処理するかという疑問が生じます。彼を殺すことはできません。 Dcurrent_virtualは存在しなくなります。 そして彼は、DomUを通じて世界のデータを生活し、働き、提供しています。
- 思い出して、友人は合体葉ツールをリリースします。これは、Dpast_realとdeltaを組み合わせて、少なくとも一時的に苦痛を和らげるように設計されています。 そして、彼らはまた、それをすべて同じように見つける方法の点でカブを傷つけます。
しかし、なぜですか？ 結局のところ、LVMは非常に正しいスナップショットをサポートしています...そして、友人との傾向がこれであるため、すべて：XenServerユーザーを徐々にHyper-Vに移行します。 CitrixになったものはまもなくM $に分類され、誰もがこれを長い間知っていました。 その結果、最初はディスクの形式がMicrosoft VHDに変更され、LVMパーティションではなくファイルとしてローカルファイルリポジトリにこれらのディスクを保存する方が良いというヒントがありました。 どうやらHyper-Vにコピーしやすくするため。 このようなスキームの結果として、ファイル形式のストレージにスナップショットシステムを実装する必要があり、準備ができていなかったため、探究心はオプション2-dibilnyを提案しました。
これで話は終わり、Solaris XVMへの移行が始まります。このために、テスト用のサポートプランを購入しましたが、その結果についてお知らせします。 実際、バグ6882364を除き、XVMは常につまずきますが、XVMは安定しており、実稼働の準備が整っています。 ご清聴ありがとうございました。
PSしかし、インドがイギリスの植民地ではなかった場合、すべてが完全に異なっていた可能性があります...