さて、前回の続きです。
前回の記事を投稿まもなくお読みいただいた方は、画像のキャプチャを少し見やすいものにしましたので、再度記事を確認いただけると幸いです。
さて、今回はコントローラーがディスクを取り扱うモードを”RAIDモード”へ変更します。
まず、以下の図は”パススルーモード”にて各ディスクが認識されている図です。
ランタイム名のvmhbaxx:Cxx:Txx:LxxのTxxにて物理ロケーションがわかるという話でした。
この後、コントローラーがディスクを取り扱うモードを、パススルーモードからRAIDモードに変更し、このランタイム名が変化するかを見るという検証です。
こちらの図は、Dell PowerEdgeのiDRAC(Integrated Dell Remote Access Controller)よりディスクを確認している状況です。モード変更前ですから、”非RAID”モードとなっています。
iDRACよりディスクモードを変更します。こちらのページよりプルダウンで変更操作を行っていきます。(物理ディスク→セットアップ)
”RAIDに変換”をセットし、変更を適用するため再起動も行います。
再起動を経て、iDRAC上のディスクのステータスが、”非RAID”から”準備完了”に変化しました。（これは想定どおりの動きです）
RAID0をまだ組んでいないので、次のようにディスクがvmkernelから見えない状況です。（これも想定どおりの動きです）
ひとまず先ほど擬似障害を起こしたID 0のディスクを、RAID 0に設定してみます。
（RAID構成になったため、RAID参加後のステータスに変化しました）
RAID 0が構成された、ID 0のディスクは、”vmhba0:C2:T0:L0″であがってきました。
RAIDモード時のID 0のディスクのランタイム名：vmhba0:C2:T0:L0
パススルーモード時のID 0のディスクのランタイム名：vmhba0:C0:T0:L0
RAID構成になることで、チャネルIDだけが変わっているようです。
たまたまターゲットIDが同じだった可能性も考慮し、全部のディスクをRAID 0モードに設定してみます。
念のためRAID BIOSでも8本のRAID 0があることを確認します。
vSphere Clientから見てみた図がこちらです。やはり、ランタイム名で見た場合すべてがチャネル2であり、ターゲットIDは0~7です。
ランタイム名は、”ストレージLUNを、パス名で識別する”ことが目的のものとなりますので、例えばドライブの物理ロケーションが人為的な操作で入れ替えられると、実際それが元のデバイスかどうかはわかりません。
ですので、さらに念には念を入れて、”識別子”も使って本当にこのランタイム名が以前のパススルーモードのときと同じかを見てみます。
ここは残念ながら一致しておらず、RAIDを構成した段階でDellのPERCにより制御される形となり、識別子が新規に生成されてしまっています。ですので、識別子を用いてのディスクが同一かどうかは確認ができませんでしたので、シャーシから0番と5番を抜いて見ます。（ディスクはランダムに選んでみました)
これまでの流れでいえば、次のランタイム名のIDがグレーアウトすると予想できます。
- vmhba0:C2:T0:L0(ディスクID 0)
- vmhba0:C2:T5:L0(ディスクID 5)
予想通り、上記のランタイム名が2つともグレーアウトしました。
結論：ターゲットIDが物理的なロケーションと一致する
但し、VMwareでは以下にあるようにこの識別子は再起動ごとに変わるリスクがあることを説明しているため、今回のように実検証を予め行っておいたほうが、より確実だと言えます。
もちろん、vSphere Web Client上から、障害ドライブのLEDをブリンクさせることができれば、その方法が一番確実な障害ディスク確認手法としては適切であり、確実と言えます。
今回の手法は、あくまでも上記の手順が実施できない場合の対策として把握しておくとよいと言えます。
コメント