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年８月上旬時点での情報となりますので、それ以降は互換性については製品の更新に伴い変更する可能性があります点をご留意ください。本記事の主目的である、どのように製品間互換性を合わせるか、の手順を覚えて頂ければ検索も問題ないと思います。
以上です。次回は、実際のインストールや更新編となります。乞うご期待ください！
小規模vSphere クラスター環境構築 on PowerEdge VRTX(1) リモートアクセス コントローラー設定
久しぶりのブログ更新となりました。お久しぶりです。
気がつけばブログアクセス数も、本記事時点で85,000を超えるブログになっており、大変うれしく思います。
※しばらく社内トレーニングが立て込んでおり、執筆活動ができておりませんでした。
さてさて、既にもう8月という事で、訳あって久しぶりにvSphere環境を自分用に物理で構築しようと思い、自宅から社内ラボに接続し、この2日間、せっせとリモートで作業をしていました。
今回は久々にPowerEdgeサーバーに対し、ESXiの導入を行いましたので、その際に使ったツールや、設定のポイントを実際の画面をキャプチャしながら解説をしたいと思います。
物理サーバーには、Dell EMC PowerEdge VRTXを利用します。
理由：手元にあったから/共有DASストレージが筐体内に組み込まれていて展開が楽ちん
PowerEdge VRTXは本格的なラックや電源環境などが存在しないオフィスファシリティで手軽にエンタープライズレベルの環境を構築ができるのが魅力ですね。
もちろん、シャーシ全体に対する影響については、何らかの対障害プランを検討は必要です。今回は私のトレーニングや検証という名目なので、ビジネスクリティカルなアプリケーションはありませんので、この環境で申し分ありません。
設計概要としては、まずはマルチノードクラスターとし、vSphere HAで仮想マシンを保護するようにします。あとあと細かな要件は足していきたいと思います。
まずは初めに、リモートでも作業が出来るようにサーバーならではの機能であるリモートアクセスコントローラーに対しIP設定を行います。
Dell EMCではiDRAC(Integrated Dell Remote Access Controller)です。他社にも似たようなソリューションはありますね。これがあるおかげで、リモートからのサーバーに対する電源操作やエラー確認、リモートコンソール機能も利用が可能となります。
ブレードサーバーの場合、ブレードエンクロージャー自体にも、エンクロージャー全体の管理用のコントローラーがあります。名称は”Chassis Management Controller"です。
今回用意できたブレードサーバーが3台、エンクロージャーが1台なので、合計4つのIPアドレスを消費しました。ちなみにDellのブレードサーバーには、”Quick Deploy"という機能があるので、サーバーを搭載した箇所に応じて、自動的にIPアドレスが割り当てられるように設定しました。
Quick Deployの詳細はこちらのブログを参照ください。
ブレードの効率的な管理（シャーシ管理） - PowerEdgeサーバ - Wiki - PowerEdgeサーバ - Dell コミュニティ
上記設定の有効化には、ブレードサーバーの再装着が必要となるため、再装着を行い変更を適用します。試しに想定どおりのIPアドレスがアサインされたか確認してみましょう。
最後に、Web GUIもアクセス出来るか確認してみましょう。
リモートコンソール機能もバッチリ利用できました、これで自宅からも作業が可能です。
iDRACのリモートコンソール機能は本記事寄稿時点では、Active X(IE), Java(Firefox, Chrome), HTML5(HTML5対応ブラウザ)にて利用可能です。
※iDRACで動作しているファームウェアのバージョンにも依存
最近は私もプラグインのバージョン管理工数を考え、HTML5を利用することが多いです。
さて、これにて管理のための環境は最低限整いました。次からいよいよ実践的な設定面に入ります。
ゲスト イントロスペクションのライセンス まとめ(NSX for vShield Endpointについて)
”NSXには無償版ライセンスがあるのか？”
”NSXと連携できるアンチウィルスの機能は無償？”
と、最近ちらほら質問されることがあります。
この点について今回は順を追って説明をしたいと思います。
【本質問に至る背景】
VMware NSXがデプロイされた環境において、”ゲスト イントロスペクション(以下GI)”というエージェントレス セキュリティ機能を利用される環境があります。
数百台、数千台規模で管理される仮想マシン環境において、全台の仮想マシン内のセキュリティアプリケーションの管理をするのは大変困難です。
セキュリティ機能を特別なVMとして実装し、それによりハイパーバイザー上の仮想マシンの保護を行う考え方が”エージェントレス セキュリティ”です。
※ゲスト イントロスペクションの詳細説明はこちらのリンクを参照ください。
このGIという機能は、これまで存在していた"vShield"という機能がベースであり、
旧vShieldのあり方については本記事寄稿時点とリリース当初とでは異なります。
- 本記事機構時点：vSphereに付属する機能である
- リリース当初：vCloud Networking and Security(以下vCNS)に付属する機能である
VMware社は、vCNSの販売終了をきっかけとし、このGIという機能の大本となる"vShield Endpoint”という機能のあり方を上記のように変更しています。
※次のリンク内より抜粋 https://kb.vmware.com/s/article/2146576
さらにですが、このGIを管理するためには、"VMware NSX"が必要となります。
これらをサマライズすると次の通りです。
- GIの大本となる機能はvShieldと呼ばれる機能である（あった）
- vShieldは現在はvSphere Essentials Plus以上に含まれている機能である
- GIを実装するには、”NSX(6.2.4以降)"が必要である
- ここで言う”NSX"が必要＝NSX Managerが必要、ということである
これらの点を受け、”GIを含むNSXは無償で利用できるのか？”という解釈に至るわけです。
あくまでもGI自体はサード パーティ パートナーのセキュリティ ソリューションと連携するためのインフラであり、別途サード パーティー パートナーの製品ライセンスは必要となります。(それ自体だけでアンチウィルスなどのセキュリティを提供するわけではありません)
【結論】
VMware NSXにはライセンス エディションは4段階存在している。
そのうち有償製品エディションが3つ(Standard, Advanced, Enterprise)、
そのうち無償製品エディションが1つ(vShield Endpoint)
しかしその際、ライセンス インストールを無しで運用をした場合”NSX for vShield Endpoint"という無償ライセンスで可動し、Guest Introspectionに対応したサードパーティ ソリューションの機能提供用のインフラを提供してくれます。vShieldのGuest Introspectionを利用するには、NSX Manager 6.2.4以降のデプロイが必要です。
VMware NSX for vSphere 6.2.4 リリース ノート
【関連記事】
- VMware vShield
- ゲスト イントロスペクションのアーキテクチャ
- vShield Endpoint（vCNS）からNSX for vShield Endpointへのアップグレード手順
- NSX for vShield Endpoint から NSX for vSphereへのアップグレード手順
- VMware NSX for vSphereへの移行 - Japan Cloud Infrastructure Blog - VMware Blogs
- VMware vCloud Networking and Security 5.5.x の販売終了および一般サポートの終了 (2145636)
- FAQ：vCNS の EOA 以降における vShield Endpoint の実装 (2146576)
- vSphere 6.x の各エディションにおける機能一覧 (2111426)
- エージェントレス型ウィルス対策の仕組みは？ ~ VMware vSphere環境との連携 - Trend Micro Deep Security特集 - テックセンター - Blog - テックセンター - Dell コミュニティ
- エージェントレス型セキュリティ対策のVMware社コンポーネントの変更について~NSX for vShield Endpoint~
