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に対するタブが存在します。
以上となります。やや難しめの記載もあったかもしれませんが、”オブジェクトレベルでのIO担当”がDOMと考えれば概要としてはバッチリかなと思います。
この役割ってハードウェアレイヤーではRAIDコントローラーのような役割とも表現が出来そうですね(パス提示と再同期およびIO担当という点より)
————————————————————————————————————
<備考:本記事で参考にした資料>
https://blogs.vmware.com/vsphere/files/2014/08/Monitoring-with-VSAN-Observer-v1.2.pdf
コメント