vSAN アーキテクチャ ー Distributed Object Manager(DOM)

vSAN アーキテクチャー編始めてみました。

vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。

 

今回は、Distributed Object Manager (略称DOM)の紹介です。

 

<役割と紹介>

  • オブジェクトの可用性の制御と初期IOのリクエストを担当している
  • オブジェクトはDOMレイヤーに存在しており、LSOMオブジェクトコンポーネントにDOMがvSANオブジェクトまたはVMDKを展開している
  • DOMは全てのミラー化されたコンポーネントに対しIOが同期されていることを保証する
  • DOM Clientにて受け取ったIOは、DOM Ownerに転送される
  • オブジェクトごとにDOM Ownerは1つであり、必ずオブジェクトのローカルに存在しているとは限らない
  • DOMはカーネルスペースに存在しており、監視用デーモンはなく、動作の再起動にはホストの再起動が必要である
  • 動作ログはvmkernel.logで追うことが出来る 

前回紹介をしました、”CLOM(Cluster Level Object Manager)”と名前が似ており、今回もオブジェクトにまつわるソフトウェアです。

前回のCLOMがポリシー通りの配置になるようにオブジェクトのケアをしていたのに対し、DOMはストレージIOを司ると理解すれば、違いは明確だと言えます。

DOMは全てのvSANノード上で動作をしており、4ノードvSANだったとすれば、4ノード全てでDOMは動作しているといえます。

また、DOMには細かく言えば3つのロールがあり、次の通りです。

  • DOM Client
    仮想マシンからのストレージIOを受信し、オブジェクトにそれを渡す際に、DOM Ownerに対し渡す役割を行う(DOM Ownerにとっての仮想マシンサイドのインターフェース役)
  • DOM Owner
    オブジェクトごとに存在するオーナーであり、ストレージパスやオブジェクトの再同期など、オブジェクトの管理を行う役目を果たす
    DOM Ownerがダウンする、あるいはネットワーク的に他ノードと疎通不可になる場合は、即座に他のDOMが新しいDOM Ownerとして選定される
    また、DOM Ownerは、CLOMと通信を行うためのインターフェースを/dev/dom(左記のものは、/dev/char/vmkdriver/domのシンボリックリンク)として持っている。
    例えば、仮想マシンの新規作成時には、CLOMがポリシー遵守出来るかをチェックし、其の結果問題無い場合は、CLOMがDOM Ownerに仮想マシン作成指示を出すが、その際の動きが、/var/log/clomd.logに記録される。
    (イベント事例としては、CLOMFetchDOMEventなどで検索をすれば表示されます)
  • DOM Component Manager – LSOMに対するフロントエンドの役割であり、DOM OwnerからのIOを受信し、LSOMにそれを渡す役目を果たす。

これらの位置関係としては、以下のようなイメージである。

[仮想マシン]→[vSCSI]→[DOM Client]→[DOM Owner]→[DOM Component Manager]→[LSOM]→[Physical Drives]

 

esxtopコマンドでxオプションを使えばDOMの上記3種のストレージアクティビティも関しが出来ますので、IOを司っている、と言われても至極当然な気がします。

vSAN Observerで見た場合には、次のように各DOMとLSOMに対するタブが存在します。

vSAN Observer上では、DOMのRole別の名称ではない名前でタブが存在します。

以上となります。やや難しめの記載もあったかもしれませんが、”オブジェクトレベルでのIO担当”がDOMと考えれば概要としてはバッチリかなと思います。

 

この役割ってハードウェアレイヤーではRAIDコントローラーのような役割とも表現が出来そうですね(パス提示と再同期およびIO担当という点より)

————————————————————————————————————

<備考:本記事で参考にした資料>

https://blogs.vmware.com/vsphere/files/2014/08/Monitoring-with-VSAN-Observer-v1.2.pdf

books.google.co.jp

books.google.co.jp

コメント