vSAN アーキテクチャー編始めてみました。
vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。
今回は、Local-Log Structured Object Manager (略称LSOM)の紹介です。
<役割と紹介>
- ディスクIOの制御及びローカルディスク内の整合性の保証を行う
- コンポーネントはLSOMレイヤーに存在する
- LSOMはDOMよりIOを受信するとWriteオペレーションが終わるとDOMにAckを返します
- LSOMはRead時のデータ提供やWriteバッファリング、Readキャッシュ化、キャッシュTierからキャパシティ Tierへのでステージも担当している
- LSOMは分散、クォーラムやIOの同期などは把握しておらず、単純にIOのみを担当している
- LSOMはカーネルスペースに存在している
- ログはvmkernel.logを使うことで動作を把握できる
LSOM自体が直接物理的なドライブにアクセスが出来るレイヤーにいるため、次のようにハードウェアの認識系の情報をLSOMがハンドルしているように見えます。
次のログはvSAN Diagnostics and Troubleshooting Reference Manualより抜粋しております。(Page 63)
例えば、ディスクを抜いてみた際には次のようなイベントが発生する
– vmkernel.log –
2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiPath: 7028: Path lost for adapter vmhba0 target 1 channel 0 pun 0
2014-09-30T09:44:55.312Z cpu22:33441)WARNING: LSOMCommon: IORETRY_NotifyAPD:1647: Got APD event 1 on 0x410c0285ca90
2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiDevice: 8820: PDL set on VSAN device path “vmhba0:C0:T1:L0” […]
2014-09-30T09:44:59.317Z cpu22:33506)WARNING: LSOM: LSOMEventNotify:4581: VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
1行目ではvmhba0のtarget1のchannel0のpun0でパスのロスト発生を検出し、
2行目ではLSOMはこの症状をAPD(All Path down)として認識し
3行目ではLSOMはこの症状をPDL(Permanent Device Loss)として再評価している
4行目ではこれを受けて、デバイスがオフラインになったことを記載している
– vobd.log –
2014-09-30T09:44:59.317Z: [VsanCorrelator] 59865017530us: [vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
2014-09-30T09:44:59.317Z: [VsanCorrelator] 59867627549us:[esx.problem.vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
同時刻にディスクがオフラインになったことを示すイベントが出ています。
ちなみに、”527cfbf5-ae7a-33f6-78bc-beed2f1730dd”という値は、vSANに参加をしている物理ドライブのUUIDです。
またログ以外にもKBの内容からも、LSOMが物理ドライブのIOのリトライなどを制御しているように伺えます。
LSI 3108 チップセット ベースのコントローラに必要な vSAN および ESXi の構成 (2145639)
本KBでは、特定の条件のストレージコントローラーを利用してる場合は、LSOMが既定で持つタイムアウト値を修正するか、パッチ適用が必要ということが記載されています。
vSAN Observerでは、”VSAN Disks (deep-dive)”が、LSOMによってレポートされている情報です。
以上です。今後も追加情報があれば記載をしたいと思います。
コメント