LINE2017.06.23さて、前回の続きです。instructor8010.hatenablog.jp前回の記事を投稿まもなくお読みいただいた方は、画像のキャプチャを少し見やすいものにしましたので、再度記事を確認いただけると幸いです。今回はコントローラーがディスクを取り扱うモードを”RAIDモード”へ変更します。以下の図は”パススルーモード”にて各ディスクが認識されている図です。ランタイム名のvmhbaxx:Cxx:Txx:LxxのTxxにて物理ロケーションがわかるという話でした。この後、コントローラーがディスクを取り扱うモードを、パススルーモードからRAIDモードに変更し、このランタイム名が変化するかを見るという検証です。Controller)よりディスクを確認している状況です。モード変更前ですから、”非RAID”モードとなっています。iDRACよりディスクモードを変更します。こちらのページよりプルダウンで変更操作を行っていきます。(物理ディスク→セットアップ)”RAIDに変換”をセットし、変更を適用するため再起動も行います。再起動を経て、iDRAC上のディスクのステータスが、”非RAID”から”準備完了”に変化しました。(これは想定どおりの動きです)RAID0をまだ組んでいないので、次のようにディスクがvmkernelから見えない状況です。0のディスクは、”vmhba0:C2:T0:L0′′であがってきました。0のディスクのランタイム名:vmhba0:C0:T0:L0RAID構成になることで、チャネルIDだけが変わっているようです。0モードに設定してみます。0があることを確認します。Clientから見てみた図がこちらです。ランタイム名で見た場合すべてがチャネル2であり、ターゲットIDは0~7です。ランタイム名は、”ストレージLUNを、パス名で識別する”ことが目的のものとなりますので、例えばドライブの物理ロケーションが人為的な操作で入れ替えられると、実際それが元のデバイスかどうかはわかりません。念には念を入れて、”識別子”も使って本当にこのランタイム名が以前のパススルーモードのときと同じかを見てみます。ここは残念ながら一致しておらず、RAIDを構成した段階でDellのPERCにより制御される形となり、識別子が新規に生成されてしまっています。識別子を用いてのディスクが同一かどうかは確認ができませんでしたので、シャーシから0番と5番を抜いて見ます。(ディスクはランダムに選んでみました)これまでの流れでいえば、次のランタイム名のIDがグレーアウトすると予想できます。5)予想通り、上記のランタイム名が2つともグレーアウトしました。結論:ターゲットIDが物理的なロケーションと一致する但し、VMwareでは以下にあるようにこの識別子は再起動ごとに変わるリスクがあることを説明しているため、今回のように実検証を予め行っておいたほうが、より確実だと言えます。Client上から、障害ドライブのLEDをブリンクさせることができれば、その方法が一番確実な障害ディスク確認手法としては適切であり、確実と言えます。今回の手法は、あくまでも上記の手順が実施できない場合の対策として把握しておくとよいと言えます。編>こちらも備忘録です。本日は分散ルーティング、L3レイヤーをやりました。概ね以下のブログの内容と同じです。Manageをはじめました。今まで6.0の提供だけでしたので、色々と変更点も多く楽しくトレーニング初日を迎えました。Manageのトレーニング提供です。やるたびやるたび話したい内容が増えていきます。(InboxとAsyncドライバーについて)ハードウェアサポートの方から根強く頂く質問に、”ESXiとドライバー”に関するものが多くあります。今回からは何点かよく聞かれる内容を挙げてみたいと思います。ESXiでは2種類のドライバーが存在します。2018を頂きました皆様、お久しぶりです。2018に選ばれました。