Clusterd Shared Volumes ～クラスタの共有ボリューム～でわかってきたことその2

その１で、あらためて Clusterd Shared Volumes ＝ CSV ＝クラスタの共有ボリュームについて書きましたが、今回は複数のノードからアクセスできるロジックというか、排他制御のようなものをどうやって実現しているかについてかみ砕いてみます。

ーーー
さて、CSV には面白い特徴があります。それは、

2段階の所有者(オーナー)制

です。

2段階とは、

です。

図にするとこんな感じです。

緑色の枠はCSVで、CSV の所有者は HVR01です。

よって、新しく仮想マシンを作る時のような、CSV に何かを書き込む際には HVR01が実施します。

じゃあ、CSV に対するすべての処理を HVR01 がやるかというと違うんです。

それが2つ目の所有者でして、CSV の中に登録されている仮想マシンは、CSVとは別に所有者の割り当てが行われています。

例えば上図では、仮想マシンB に対して HVR02 が所有者になっているわけで、仮想マシンB に対する書き込みは HVR02が担うことになります。

ーーーー

もしかしたら、仮想マシンBのフォルダに対する権限の話し？かと思っている方もいらっしゃると思いますが、フォルダ内にWordのファイルをおいてもエラーが出ます。ちゃんと CSV への書き込みの仕組みが存在し、それを経由しないアクセスは正しく行われないのです。

よって、現時点では CSV は Hyper-V の Live Migration (もしくはQuick Migration) 用として実装されているとご理解ください。

ここでもう一段階深く理解するために、本社から落ちてきたCSVの２つのスライドを見てみましょう。

CSVに仮想マシンを作っているのがこちら↓で、

出来上がった仮想マシンにアクセスしているのがこちら↓です。

興味深いことがわかります。

これを見る限り、CSV へのすべてのアクセスには、CSV I/O Filter Driver が関与しています。そして、最初の仮想マシンの作成では NTFS というファイルシステムを経由していますが、それ以降の仮想マシンレベルの読み書きは NTFS を経由していないみたいです。

ま、今までのファイルシステムと同じではないということがこれでご理解いただけたことでしょう。

まだまだ、私も理解が足りないので、もう少し勉強をして、さらに分かりやすく解説出来るようになりたいと思ってます。