Nutanixバイブル/NutanixBible_2-14J

• (2-14) スナップショットとクローン

NDFSは、VAAI,ODX,ncli,REST,PRISM等を通じて、負荷の掛からないスナップショット作成とクローン作成をネイティブにサポートしている。スナップショットとクローンの両方は、最も有効で効率的である redirect-on-write アルゴリズムを利用している。
Data Structureのセクションで説明した通り、仮想マシンは、Nutanix platform上のvDiskである ファイル(vmdk/vhdk)より構成されている。vDiskは、論理的に連続なデータの塊(chunk)であるextentsにより構成されており、これはストレージデバイス上のファイルとして物理的に連続なデータであるextent groupの中に保存されている。
スナップショット或いはクローンが作成される時、ベースとなるvDiskは変更不可(immutable)なものとしてマークされ、もう一方のvDiskがread/write可能なものとして作成される。 この時点で、両方のvDiskは同じblock map、即ち該当しているextentsへのvDiskのmetadataマッピングを持っている。読込み遅延を発生し得るスナップショット チェーンを辿る必要の有る伝統的なアプローチと異なり、各vDiskはそれ自身のblock mapを持っている。これにより、スナップショット チェーンが非常に深い場合に通常認められるオーバーヘッドを排除することができ、ユーザーが如何なるパーフォーマンス上の影響を受ける事無く連続にスナップショットを作成することが可能となる。
スナップショットが作成される場合に、それがどの様に動作しているかを以下に示す。
(注:最も明確な図を提供していると思われるのでNTAPに有る程度の信頼を置いている)

<<Fig.2-14-01>>

スナップショットやクローンが以前に作成されたvDiskに対し、更にスナップショットやクローンが作成される場合、同じ方法が使用される。

<<Fig.2-14-02>>

VMやvDiskのスナップショット或いはクローンが作成される場合に同じ方法が使用される。VM或いはvDiskのクローンが作成される場合、現在のblock mapはロックされてからクローンが作成される。 これらで更新されるのはmetadataだけであるため実質上I/Oは全く発生しない。
同じ方法は、クローンのクローンを作成する場合にも使用されている。 実質以前にcloneが作成されたVMが"base vDisk"として振舞い、クローン作成の間 block mapはロックされ、2つの"クローン"が作成される。 一つはクローンが作られている元のVMに対するものであり、もう一つは新たなクローンに対するものである。 それらはどちらも、以前のblock mapを継承し、新たに発生するwrite/updateはそれらの個々のblock map上に実行される。

<<Fig.2-14-03>>

以前に述べた通り、各VM/vDiskはそれ自身のblock mapを持っている。 そのため、先の例の通り、ベースVMから作成された全てのクローンは、今では自らのblock mapを持ち、如何なるwrite/updateはそれに対して発生する。 その振舞いがどの様に見えるのかを以下に示す。

<<Fig.2-14-04>>

その後に発生するVM/vDiskのクローン作成やスナップショット作成は、元々のblock mapにロックを発生させ、R/Wアクセスのために新しいblock mapを作成する。

Nutanixバイブル