ここ最近Hyper-V2.0新機能のベースとして備わっているCluster Shared Volumeについてちょっとあれこれ考えてみた。

参考情報はないかーと色々漁ってみたのだけど、どうやら以下の情報が頼りになりそう。

NetApp社のブログ？

SEの雑記

そんで、分かったことを簡単に列挙してみた。

• 通常、Shared可能なクラスタボリュームを構成するにはファイルシステムを対応させることが多い（例えばOCFSなんかがそうだよね）のだけど、どうやらファイルシステムは特にいじらない模様。
• CSVを実現するために、CSVFilter.sysと呼ばれるファイルシステムミニフィルタドライバが使用される。
• ノードはコーディネータノードと非コーディネータノードに分類される。
  • コーディネータノードとは、所謂オーナーノードである。ディスクの実質の所有権を握るノードである。
  • 非コーディネータノードとは、コーディネータノードを除くすべてのノードである。
  • 所有権を握るコーディネータノードがディスクを実際にマウントしており、コーディネータノードからのアクセスは通常のディスクアクセスと変わらないアクセスを行う。
• 非コーディネータノードは以下のようにしてディスクアクセスを行う。
  • メタデータ（ファイルの属性・プロパティ）に対する変更は、ネットワークを経由し、共有フォルダを操作するのと同じ要領でコーディネーターノードに対して変更依頼を転送する。これを受けてコーディネーターノードはマウントしている自らのボリュームに対してアクセスし、メタデータ変更要求の反映を行う。
  • 実データに対する変更は、CSVFilter.sysを介して直接ディスククラスドライバ（disk.sys)に対して読み書きを行うとのこと。この間に本来介在するローカルファイルシステム・ボリューム・パーティションに対するアクセスは全てバイパスされる。

過去、複数ノードから同時にアクセスを試みてファイル破損が発生するケースって、大抵データそのものと言うよりはNTFSのメタデータ破損が多いように感じる。特に、ACL情報の破損なんかが非常に多い。

こうした、破損しやすいメタデータの更新は共有フォルダアクセスによってコーディネーターノードにて一元管理とし、実データの更新はCSVFilter.sysによるブロック制御要求を直接disk.sysに展開することによって、元々共有アクセスに対応していないNTFSに対して迷惑をかけることなく整合性の保たれたアクセスを可能としているのではないかと考えられる。メタデータアクセスと実データアクセスを分けて考えて、それぞれ独自のアプローチをとることで、整合性を担保しているってぇのは面白いなぁと。

そうした特殊な制御をしている分、これまで通り行えてきたデータアクセスが難しくなり、例えばバックアップの手立てを失っている・・・ということなんだろうな。きっと。