ESXi ストレージ パスの見え方, 考え方(Dell Storage ME編)
最近Dell EMCでは新たなエントリーモデルのストレージとして、”PowerVault ME4”シリーズをリリースしました。
リリース間もないこともあり、まだまだ情報が少ない状況です。
そこで本ブログ恒例の”ESXi ストレージ パスの見え方、考え方”シリーズで本ストレージを取り扱おうと思います。
さて、まずは恒例の物理トポロジーの確認からです。今回はFibre ChannelベースでのPowerVault ME4024という機種で検証を行いました。今回の構成図は次の通りです。
<ホワイトボード記述への補足>
- 1ホスト辺りFCポートはシングル構成(勿論高可用性のためには冗長化がより望ましい)
- スイッチもシングル構成(勿論高可用性のためには冗長化がより望ましい)
- オレンジの枠内の数字はWWNの一部を抜粋したものです
- SP=ストレージ プロセッサの略称です。人によってはRCM(RAID Controller Module)と呼ぶ人もいます。
本ストレージは2つのストレージプロセッサを2つ搭載しており、両方からLUNへのアクセスが可能です。ホワイトボードの図に従えば、緑、赤、青、紫の4つのケーブルがスイッチに伸びており、各ホストからは1つの結線だけが伸びているので、1ホスト辺り4パスが見えているはずです。
それでは本当にそうなっているか、vSphere上でのランタイム名を確認してみましょう。
- vmhba - FCアダプター上のポートを示す
今回の構成ではシングルポートのFC HBAです。vmhba3が、まさにこのコントローラーのポートだと確認が出来ます。恐らく複数枚のHBAを搭載した場合は、vmhba4など別番号が割り振られる形になると予測出来ます。
ということで試してみました。
2枚目のFC HBA(正確にはConverged Network Adapter)を搭載してみた図がこちらです。
緑がもともと搭載していたシングルポートのFC HBAです。
赤が追加搭載をしてみたデュアルポートのFC HBAです。(CNA)
ポート単位でvmhbaとしてそれぞれが独立した番号で管理されているのがわかります。 - Channel - 本製品の場合は特定のパスを識別するのには利用されていない模様
今回はいずれのパスでも共通のチャネル番号0番が割り振られています。
環境によっては、特定の範囲を本チャネルとして定義をしますが、今回の構成ではチャネルを用いて独立したパスを示す様子は確認が出来ませんでした。 - Target - Dell Storage MEのFCポートを示す
この事例では、本システムはTarget IDを使い、ストレージ ターゲットサイドのIOポートを区別していることがわかります。ME4のFibre Channelベースのコントローラーの場合、最大でシステム辺り8ポート(SP当たり4ポート)まで最大で構成ができるので、最大構成の場合は8種類のターゲット番号までが確認出来ることが予想出来ます。
- LUN - Dell Storage ME内のLUN(ボリューム)を示す
これは、他のストレージシステムとも同様で、ストレージ内部のボリューム(ホストにマウントする単位)の識別子である。
これらを総括して見ますと、次のようなレイヤー構造が見えてきます。
特に右側の紫のvmhba/Channel/Target/LUNを意識してご覧頂くと、上図の解説がわかりやすいと思います。
物理ストレージシステムのIOポート自体が単一のターゲットとして振る舞うため、そこまでの道筋の番号をチャネルで表現しているのがDell Storage MEと言えます。
今回は以上となります。
おまけ:Dell PowerVault ME4の管理画面
今回のME4の管理画面です、管理画面名はMESMといいます。(ME Storage Manager)
上図赤枠内に全部で8ポートが確認出来ますが、今回リンクアップしているのは各コントローラー当たり2ポートずつです。
(Converged Network Controllerというコントローラーで、2ポートはFC、2ポートはiSCSIという設定になっています)
マウスをアイコン上に乗せると、詳細がポップアップされます。
ポップアップされたIDより、ポートレベルでのWWNが確認出来ました。
<追記>
Youtube上で公開されているDell EMCの公式動画より、ME4ストレージへのiSCSI接続の紹介動画です。
本同が内の6分40秒のタイミングで、ランタイム名の確認が可能です。
ここで見た場合、FCの場合と異なり、ターゲットではなくチャネルによる識別でパスの違いを確認が出来ました。
プロトコルの違いにより表記のされ方に差異が出るようですので、この点は一つ注意点であると言えます。
Dell / Dell EMC所属のvExpertのご紹介、に掲載されました!!
この度所属しているDellのフォーラム上で、vExpert紹介記事にて取り上げて頂きました。
Dell / Dell EMC所属のvExpertのご紹介 | Dell 日本
同じ職場に強力な仲間がいることは活動の励みになりますね!今年は他にもメディア活動の場を多く頂いているので、また外部記事についても本ブログで紹介させていただこうと思います。
また、この場を借りまして、月間アクセスがいよいよ12,000HITまで成長できたことをご報告いたします。毎月記録更新が出来ており大変うれしい限りです:)
vmkドライバーとネイティブドライバーの違い
以前にESXiに対しインストール可能なデバイスドライバーには2種類が存在するという記事を寄稿しました。
InboxドライバーとAsyncドライバーの2種類で、VMwareご本家の提供かサードパーティベンダー提供かの違いという所で紹介致しました。
今回はちょっと違ったカットでの2種類、の紹介です。
”vmkドライバーとネイティブドライバーの違い”についてです。同じドライバーでも、冒頭に"net"と付くものとそうでないものが確認出来ます。これらの違いに迫ります。
なお本記事の技術的な話のソースは、次の2つのブログからの引用となります。
<vmkドライバーについて>
- ESXi 5.5以前までは、ドライバーはvmkドライバーというものしか存在していない
- vmk ドライバー=Linux OS向けに提供されているドライバーである
- ESXi=Linuxではない、VMware開発のオリジナルOSである
- vmkernel(ESXi)とLinux用ドライバー(vmkドライバー)との間に、抽象化レイヤーを介在させ、これによりLinux用のドライバーをESXiで利用していた
Linuxと言えば、有名なあのオープンソースOSのことであり、当然ユーザー数や利用実績も多くあるため、ユーザー、コミュニティ、企業などにより多くのフィードバックを受け、日々改良がなされていると言える。一方で、元々Linuxのために作成されたドライバーである点から、パフォーマンス、拡張性、機能面ではESXiに最適化されているとは言いづらい状況です。
このため、VMwareではvSphere 5.5から、"ESXiのためのドライバー”を作成し、それを今後”Nativeドライバー”とした
これらの点より、次のことが言える。
- ドライバーの歴史的側面では、vmkドライバーの方が長く、Nativeドライバーは短い
- 今後VMwareがリリースするであろう新機能などによってはNativeドライバーの利用が促される傾向が予測される
次のKBではNativeドライバーとvmkドライバーとでは、Nativeドライバーの場合では症状に問題ないことが言及されている。
https://kb.vmware.com/s/article/52980
直接的な表現こそ無いですが、各種VMware製品がNativeを基準とし製品動作を確認してリリースしているように見えなくもないです(この一文は私個人の見識です)
また別角度で言えば、これらのKB内部にも2つのドライバーに対する言及もなされており、基本的に5.5以降ではネイティブ ドライバーがデフォルトでカーネルに対してロードされる形となっています。
ESXi 5.5 以降でのネイティブ ドライバのトラブルシューティング
https://kb.vmware.com/s/article/2044993?lang=ja
ESXi 6.5 におけるネイティブ ドライバの有効化と無効化 (2149345)
https://kb.vmware.com/s/article/2149345
上記のKBでは、環境や条件によっては、必ずしもネイティブ ドライバーが適さない可能性もあるため、トラブルシュートや問題の恒久対策も見据え、vmkドライバーへの切り替え手法が紹介されています。
運用者の立場としては、ドライバーを一本化してくれて問題がない、というのが最も理想だと言えます。最終的にはネイティブ ドライバーのみですべてのことが出来るようになればな、と思います。
小規模vSphere クラスター環境構築 on PowerEdge VRTX(番外編) 共有ストレージのトラブルシューティング
今回、環境構築の早期の段階で、共有ストレージへの接続性についての問題が発生したため、備忘録かつトラブルシューティングのアプローチ手法を確認頂くために、記事にまとめて見ます。
まず前提として、トラブルへの対処手順は複数存在するということです。
記事をお読み頂いた方の中には、”もっと自分なら違う方法がある”という方もおられるかもしれません。今回はトラブルシュートの基本を学びたい方向けの記事であることを先んじてご了承ください。
さて、まずトラブルシュートの基本は私は3段階だと捉えています。
- 問題定義
- 原因調査
- ソリューション(アクション、対処とも言う)
1. 問題定義:特定ホストでの共有ストレージLUNマウント不可
まずは問題ですが、何が問題かといいますと、3ノードで構成されたクラスターノードのうち、1ノードだけが共有ストレージ領域であるLUNをマウントできていないということです。今回は、VRTXシャーシ内 Slot 4に搭載されたPowerEdge M620でのみ発生している問題です。
2. 原因調査
この問題の原因を探るべく、次の事を実施してみました。
- 該当ホスト上でのストレージ アダプター、VMFS、デバイスのスキャン → 同事象継続
- 該当ホストのハイパーバイザー自体の再起動 → 同事象継続
- 該当ホストのログ調査 → 複数回PCI バスに関連するエラーを確認
- 該当ホストでのESXi再インストール → 同事象継続
- 共有ストレージのマウント解除及び再マウント → 同事象継続
- ファームウェア類の更新 → 最新版適用をしてみても同事象継続
- 他2台のサーバーを停止し、本機だけを起動した状態でのアクセス確認 → 同事象継続
- 3台のサーバーでBIOSやホストの設定を比較 → BIOSもホストの設定も3台全て共通
上記作業では改善が見られませんでしたが、ログ調査ではPCIバス 0:3:0と3:0:0でのBus Fatal Errorを確認できました。
このバスのうち、0:3:0はというと、どうやらShared PERC8コントローラーに接続をするためのメザニンカードであることが確認できました。
概ね原因箇所が洗い出せたので、次のトラブルシューティングを試みます。
1で改善してしまえば、VRTX内部のミッドプレーン(各種サーバーやディスク群の搭載基盤)側の問題だと言えるでしょう。
2で改善してしまえば、メザニンというコンポーネントの問題だと言えるでしょう。
いずれでも改善しない場合は、可能性としてはバスを持つデバイスということで、同機種のマザーボードの可能性が高いと考えられます。
理由としては、他の2台のPowerEdgeでは該当の共有ストレージにアクセスができているため、VRTX側のRAIDコントローラーやディスク群には問題があるとは言い難い状態です。
補足としては、PowerEdge VRTX筐体上のShared PERC領域への接続には、PCI メザニンがあることでアクセスパスが提供される形となっています。
つまり、下図でいう赤色の経路上の問題であり、複数のサーバーでは以上が見られないため、”PCIe Switch 1"と”Integrated Storage Controller 1(Shared PERC8)”には障害がないのではないか?という見立てです。
ということで、早速、1と2の作業をしてみます。
まずはメンテナンスモードでホストの停止準備をします。
そして、ホストを停止します。
そして、電源が落ちたPowerEdgeを確認し....
本当はせっかくブレードサーバーも開けたので、メザニンカードの抜き差しや、メザニンBとC間の入れ替えなど行いたかったのですが、一度に多くの作業を行ってしまうと、原因箇所特定が困難になりますので、まずはブレードスロットの入れ替えだけを行います。この後ブレードサーバーをスロット2に搭載し、電源起動します。
すると...
別スロット搭載時でも同じエラーが確認できました。つまりスロット依存ではない(筐体側の問題ではない)可能性が一段と上がりました。
ここまで来れば、PowerEdge M620内のマザーボードまたはメザニンカードのいずれかが障害点であることまで絞り込めました。
ここで一応、メザニンカードを外した状態でブレードサーバーを再装着し、起動すると、すんなりESXiが起動してきました。起動のスタック自体の原因が、PCI Bus Fatal Errorによるものであることは確認が出来ました。
一応メザニンカード搭載箇所に、元メザニンCスロットにあったものを、Bスロットに搭載し、サーバーを再起動してみます。なお、この作業前に、iDRAC内のログを一旦削除し、新規でのPCIバスの問題がロギングされたらわかりやすいようにしておきます。
さて、メザニンBスロットとCスロットに搭載されていたメザニン カードをスワップしてみて再度サーバーを起動してみます。
ここまで来ると、どうやらマザーボード一択のような気がするので、更に正常動作しているPowerEdge M620のメザニンを2枚借用し、起動を試しますが、結果としては同じでした(結論、マザーボードで確定でしょう)
逆に、問題が発生していたサーバーのメザニンカードを、正常動作サーバーに搭載した所エラーなく起動し、PERC配下のストレージ領域も確認が出来ていたため、メザニンカードも問題がないことがわかりました。
以上です。ブログを書きながらトラブルシューティングを行っていたので、かなり長文になってしまいました。主にハードウェアレベルでの話も多く見えますが、vMotionがあるおかげで、仮想マシンを単一ホストに寄せてハードウェア入れ替えなどの作業を手軽に試せたことは言うまでもありません。
ここまでで、原因=マザーボードという点までは絞れましたので、後は交換編です。
交換については後日必要パーツを準備後、交換の様子も記事にしてみたいと思います。
小規模vSphere クラスター環境構築 on PowerEdge VRTX(3) ESXi インストールとハードウェア更新
いよいよ前回調査した情報を元に導入に入ります。
前回調査した結果については、以下のリンクよりご確認ください
まずハードウェア系の更新としては、Dell EMCの場合はCMC(Chassis Management Controller)やiDRAC(Integrated Dell Remote Access Controller)などのハードウェアベースのリモートコントローラーから実施が可能です。
※この機能の可否はファームウェアのライセンス グレードに依存します
BIOSは2.5.4というバージョンに対し互換性があるとの事でしたので、まずは該当のBIOSをサポートサイトから確認します。
Dell Server PowerEdge BIOS M620 Version 2.5.4 | Dell 日本
Dell EMCの場合、vSphereベースのハードウェア ファームについてはWindowsとLinux用のバイナリのみの提供しかないため、このままの形式で、vSphereに対しては利用ができません。
その代わり、iDRACやCMCでは、Windows用のUpdateバイナリが利用可能ですので、これらに対し更新パッケージをロードすればどんなOSであってもハードウェア更新が可能です。
下図のように、ツリー内から”アップデートおよびロールバック”を選択すると、ファームウェアファイルを指定するボックスがありますので、そこで予めダウンロードしておいたファイルをしていします。
早速、ダウンロードしておいたファームウェアを指定し、iDRACに対しこのファイルをアップロードします。
アップロード中....
アップロードが完了すると、次のように現在のバージョンと、本更新パッケージでのバージョンが表示されます。
今回は別検証で最新BIOSを利用しておりました兼ね合いで、事実上ダウングレードを行う形となります。
※ハードウェアベンダーの側面で言えば、ダウングレードは通常推奨はされません。
※今回は複数の製品視点から、動作保証されている理想的な環境を構築するためダウングレード処理を行います。
※ファームウェアによっては、ダウングレードが許可されないバージョンも存在します。
インストールして再起動をクリックすれば、クリック後にインストールが即座開始されます。
インストールして次回再起動をクリックすれば、次回のホスト再起動時に本アップデートが適用されます。(計画再起動時に予め更新を予約しておくイメージ)
今回は、試しに”インストールして次回再起動”を選択してみました。
この操作により、iDRAC内では”ジョブ”という形で将来のタスクが維持されます。
再起動を実際に行うと、サーバー上では、次のような画面で更新タスクが実施されます。上記機種ではないマシンで取得をした画像のため、ジョブに対するIDは異なりますが、本画面からどの処理が実施されているかを確認することができます。
プログレスバーが100%になると更新が完了し、製品が正常通り起動してきます。
結構幅広いファームウェア類の更新をサポートしていますので、例えばLinux系OSの管理経験が無い、Windows系管理者の方であっても、手軽に更新タスクを実行ができます。
次にハイパーバイザーのインストールを行います。
こちらもiDRACの機能である、イメージマウントを利用します。
CIFSまたはNFSで提供されるイメージファイルを、パス指定及び認証情報を入力すれば仮想ドライブにイメージをマウントしたことになります。
正しくマウントされると、ステータスが”接続”に変わりました。
ここからは通常通りのESXiのインストール タスクを行います。
インストール前に、RAIDボリュームの初期化も行っておきましょう。
マウントしたイメージは、”Virtual CD"として認識されているため、こちらを選択
こちらを選択すれば、後は以下のKBにあるインストーラーに従うだけでOKです。
VMware vSphere ESXi 6.xインストール手順 | Dell 日本
これと同じ作業を残りのホストにも行っていきます。せっかくなので、以前に投稿した内容に従い、BIOS上の電力管理設定もパフォーマンスモードに変更しておきます。
後は案外時刻設定なども、トラブルシュート時のロギングタイムの制御に重要なので合わせましょう。
今回はこれで以上となります。次回はvCenter Serverのデプロイ当たりを行きたいと思います。
小規模vSphere クラスター環境構築 on PowerEdge VRTX(2) 運用するvSphere バージョンの選定、決定方法
本記事は、次の記事の続編となります。シリーズの最初からご覧になりたい方は、以下のリンクをクリックください。
さて、vSphere ESXiをインストールする作業は次のような操作だけなのでとても簡単です。
概ねこんなものです。
インストーラーの画面キャプチャはこちらのURLをご覧ください。
VMware vSphere ESXi 6.xインストール手順 | Dell 日本
今回のテーマは、インストールをただ行うのではなく、その前後で必要となる重要なポイントのおさらいです。インストール前には次のような確認を常に行う必要があります。
- ハードウェアとvSphereの互換性の確認、インストールするバージョンの確認
- 必要に応じたハードウェア更新
- リリースノートの確認
今回は特に1と2で時間を取られました。(なにせしばらく使っていなかった機材でしたので、更新箇所が多かったです)今回は特に、このバージョン選定、決定の記事です。
ハードウェア互換性ですが、今回利用する環境には、”PowerEdge M520"と”PowerEdge M620”という2種のブレードがあります。
早速ですが、定番の互換性リストで確認をしてみましょう。
VMware Compatibility Guide - System Search
ESXi 6.7環境を構築しようとワクワクしていたものの、6.5 U2までという事実を叩きつけられます。しょうがない、ということで今回は6.5 U2で行きましょう。
※M520の場合は2.4.2との記載がありました。
加えまして、BIOSの動作確認済みバージョンは2.5.4かつShared PERC8(VRTX右側のドライブ郡のRAIDコントローラー)についてのドライバーバージョンについての言及を発見しました。
更にShared PERC8の互換性についても確認をします。
詳細確認のためにコントローラー名をクリックし、サポートされるファームウェアバージョンを確認します。
ここから更に、PowerEdge VRTX側のマニュアルも確認します。
VRTXに存在する共有PERCには、関連するハードウェアのファームウェアのバージョンを一定のバージョンに揃える”ベースライン”という考え方が存在するため、それに揃えるようにファームウェアを確認します。
https://topics-cdn.dell.com/pdf/poweredge-vrtx_compatibility-matrix7_en-us.pdf
2018/08/05時点では、第7世代のベースラインまでが開放されているようです。
本ベースライン環境のための一致させるべき各種バージョンを確認してみると...
あれ、6.5 U1までしか記載が...(この段階で既に6.5 U2のインストール イメージを用意済み)
という事で、急遽インストール予定のESXiを6.5 U1に変更します。
せめてvCenter Serverくらいは最新 6.7で行こうと思い、念の為こちらはVMware 製品相互間マトリックスを確認します。
よし、6.7.0はESXi 6.5 U1に対し互換性有りであることを確認ができました。
なにげに初めて6.7.0を実環境導入します。新UIがとても楽しみでなりません。
大まかなトポロジーが見えてきました。
vCenter SererはWindows Server版ではなく、Photon OSベースの所謂仮想アプライアンス版を利用します。ご存知の方も多いですが、Windows版vCenterは今後リリースされない予定です。かつアプライアンスベースのvCenterは既にWindows版のvCenterを遥かに上回る拡張性、機能、コスト利点を持ちます。
以下のリンクからダウンロードしましょう。
https://my.vmware.com/jp/web/vmware/details?downloadGroup=VC670C&productId=742&rPId=24881
ここまで決定した各種構成情報をまとめると次のようになります。
- PowerEdgeのBIOSバージョン 2.5.4&2.4.2
- Chassic Management Controllerのファームウェアバージョン 3.00
- Chassis インフラストラクチャのファームウェアバージョン 2.21
- Shared PERC8のファームウェアバージョン 23.14.06.0013
- Shared PERC8のドライババージョン 06.806.90.003
- 内蔵SASエクスパンダのファームウェアバージョン 2.0
- vSphere ESXiのバージョン 6.5 Update 1
- VMware vCenter Serverのバージョン 6.7.0
列挙してみると、情報量自体は10行行かない程度ですが、ここまで相互完成をベンダーを超えて合わせて決定するにはかなりの時間を使いました(知っている製品だからサクサク探せますが、初めて製品を触る人は結構探すのがたいへんですね)
※結線や設定がないから楽ちんだと選んだVRTXですが、まさかの互換性チェックで数時間取られました。執筆や画像キャプチャも結構時間がかかるんですよね。
*上記互換性セットは、2018年8月上旬時点での情報となりますので、それ以降は互換性については製品の更新に伴い変更する可能性があります点をご留意ください。本記事の主目的である、どのように製品間互換性を合わせるか、の手順を覚えて頂ければ検索も問題ないと思います。
以上です。次回は、実際のインストールや更新編となります。乞うご期待ください!