VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

vmkドライバーとネイティブドライバーの違い

以前にESXiに対しインストール可能なデバイスドライバーには2種類が存在するという記事を寄稿しました。

 

InboxドライバーとAsyncドライバーの2種類で、VMwareご本家の提供かサードパーティベンダー提供かの違いという所で紹介致しました。

 

今回はちょっと違ったカットでの2種類、の紹介です。

”vmkドライバーとネイティブドライバーの違い”についてです。同じドライバーでも、冒頭に"net"と付くものとそうでないものが確認出来ます。これらの違いに迫ります。

f:id:instructor8010:20180903102820p:plain

なお本記事の技術的な話のソースは、次の2つのブログからの引用となります。

www.virtuallyghetto.com

www.virtuallyghetto.com

<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ドライバー”とした

f:id:instructor8010:20180903100353p:plain

William氏の記事から抜粋(新ドライバー開発に至った経緯が記述されている)

これらの点より、次のことが言える。

  • ドライバーの歴史的側面では、vmkドライバーの方が長く、Nativeドライバーは短い
  • 今後VMwareがリリースするであろう新機能などによってはNativeドライバーの利用が促される傾向が予測される

次のKBではNativeドライバーとvmkドライバーとでは、Nativeドライバーの場合では症状に問題ないことが言及されている。

https://kb.vmware.com/s/article/52980

f:id:instructor8010:20180903100957p:plain

直接的な表現こそ無いですが、各種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. 問題定義
  2. 原因調査
  3. ソリューション(アクション、対処とも言う)

1. 問題定義:特定ホストでの共有ストレージLUNマウント不可

f:id:instructor8010:20180806135822p:plain

まずは問題ですが、何が問題かといいますと、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を確認できました。

f:id:instructor8010:20180806140408p:plain

iDRACで見ています、リモートからログが閲覧出来るのは大変便利

このバスのうち、0:3:0はというと、どうやらShared PERC8コントローラーに接続をするためのメザニンカードであることが確認できました。

f:id:instructor8010:20180806140521p:plain

上のエラーの右端ですが、Mezzanine Bというコンポーネントでエラーが起きている模様

概ね原因箇所が洗い出せたので、次のトラブルシューティングを試みます。

  1. ブレードサーバーの搭載スロット位置の変更
  2. メザニンカードのスワップ

1で改善してしまえば、VRTX内部のミッドプレーン(各種サーバーやディスク群の搭載基盤)側の問題だと言えるでしょう。

2で改善してしまえば、メザニンというコンポーネントの問題だと言えるでしょう。

いずれでも改善しない場合は、可能性としてはバスを持つデバイスということで、同機種のマザーボードの可能性が高いと考えられます。

理由としては、他の2台のPowerEdgeでは該当の共有ストレージにアクセスができているため、VRTX側のRAIDコントローラーやディスク群には問題があるとは言い難い状態です。

補足としては、PowerEdge VRTX筐体上のShared PERC領域への接続には、PCI メザニンがあることでアクセスパスが提供される形となっています。

つまり、下図でいう赤色の経路上の問題であり、複数のサーバーでは以上が見られないため、”PCIe Switch 1"と”Integrated Storage Controller 1(Shared PERC8)”には障害がないのではないか?という見立てです。

f:id:instructor8010:20180806171625p:plain

https://qrl.dell.com/files/en-us/html/manuals/vrtx/mapping%20pcie%20expansion%20slots=guid-3476b49e-4110-4f4f-8b3f-9aa4f783e2ea=2=en-us=.html

ということで、早速、1と2の作業をしてみます。

まずはメンテナンスモードでホストの停止準備をします。

f:id:instructor8010:20180806142412p:plain

メンテナンスモード、忘れずに!

そして、ホストを停止します。

f:id:instructor8010:20180806142909p:plain

そして、電源が落ちたPowerEdgeを確認し....

f:id:instructor8010:20180806143904p:plain

今回の障害が発生しているホスト

f:id:instructor8010:20180806144011p:plain

電源LEDが消灯になりました、この状態であれば筐体から抜去できます

f:id:instructor8010:20180806145051p:plain

筐体からブレードを抜きます。筐体サイズは結構長いですね。

f:id:instructor8010:20180806145608p:plain

赤い枠内に2つのメザニンカードが搭載されています。左側がB、右側がCです。

本当はせっかくブレードサーバーも開けたので、メザニンカードの抜き差しや、メザニンBとC間の入れ替えなど行いたかったのですが、一度に多くの作業を行ってしまうと、原因箇所特定が困難になりますので、まずはブレードスロットの入れ替えだけを行います。この後ブレードサーバーをスロット2に搭載し、電源起動します。

すると...

f:id:instructor8010:20180806150012p:plain

早速エラーが発生しています。液晶パネルのオレンジや、スロット2内のサーバーのLEDがオレンジ色です。

別スロット搭載時でも同じエラーが確認できました。つまりスロット依存ではない(筐体側の問題ではない)可能性が一段と上がりました。

f:id:instructor8010:20180806150301p:plain

起動自体がスタックかつスロット箇所変更後も同じPCI Bus Fatal Errorが発生

ここまで来れば、PowerEdge M620内のマザーボードまたはメザニンカードのいずれかが障害点であることまで絞り込めました。

ここで一応、メザニンカードを外した状態でブレードサーバーを再装着し、起動すると、すんなりESXiが起動してきました。起動のスタック自体の原因が、PCI Bus Fatal Errorによるものであることは確認が出来ました。

一応メザニンカード搭載箇所に、元メザニンCスロットにあったものを、Bスロットに搭載し、サーバーを再起動してみます。なお、この作業前に、iDRAC内のログを一旦削除し、新規でのPCIバスの問題がロギングされたらわかりやすいようにしておきます。

f:id:instructor8010:20180806153755p:plain

ログを削除した、という記録のみです。新規のエラーは一目瞭然です。


さて、メザニンBスロットとCスロットに搭載されていたメザニン カードをスワップしてみて再度サーバーを起動してみます。

f:id:instructor8010:20180806154949p:plain

また同じエラーが発生しました。

ここまで来ると、どうやらマザーボード一択のような気がするので、更に正常動作しているPowerEdge M620のメザニンを2枚借用し、起動を試しますが、結果としては同じでした(結論、マザーボードで確定でしょう)

逆に、問題が発生していたサーバーのメザニンカードを、正常動作サーバーに搭載した所エラーなく起動し、PERC配下のストレージ領域も確認が出来ていたため、メザニンカードも問題がないことがわかりました。

 

以上です。ブログを書きながらトラブルシューティングを行っていたので、かなり長文になってしまいました。主にハードウェアレベルでの話も多く見えますが、vMotionがあるおかげで、仮想マシンを単一ホストに寄せてハードウェア入れ替えなどの作業を手軽に試せたことは言うまでもありません。

 

ここまでで、原因=マザーボードという点までは絞れましたので、後は交換編です。

交換については後日必要パーツを準備後、交換の様子も記事にしてみたいと思います。

 

小規模vSphere クラスター環境構築 on PowerEdge VRTX(3) ESXi インストールとハードウェア更新

いよいよ前回調査した情報を元に導入に入ります。

前回調査した結果については、以下のリンクよりご確認ください

instructor8010.hatenablog.jp

 

まずハードウェア系の更新としては、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ベースのハードウェア ファームについてはWindowsLinux用のバイナリのみの提供しかないため、このままの形式で、vSphereに対しては利用ができません。

その代わり、iDRACやCMCでは、Windows用のUpdateバイナリが利用可能ですので、これらに対し更新パッケージをロードすればどんなOSであってもハードウェア更新が可能です。

f:id:instructor8010:20180805211939p:plain

iDRAC内ヘルプより抜粋

下図のように、ツリー内から”アップデートおよびロールバック”を選択すると、ファームウェアファイルを指定するボックスがありますので、そこで予めダウンロードしておいたファイルをしていします。

f:id:instructor8010:20180805212726p:plain


早速、ダウンロードしておいたファームウェアを指定し、iDRACに対しこのファイルをアップロードします。

アップロード中....

f:id:instructor8010:20180805213418p:plain

 

アップロードが完了すると、次のように現在のバージョンと、本更新パッケージでのバージョンが表示されます。

今回は別検証で最新BIOSを利用しておりました兼ね合いで、事実上ダウングレードを行う形となります。

※ハードウェアベンダーの側面で言えば、ダウングレードは通常推奨はされません。

※今回は複数の製品視点から、動作保証されている理想的な環境を構築するためダウングレード処理を行います。

ファームウェアによっては、ダウングレードが許可されないバージョンも存在します。

f:id:instructor8010:20180805213648p:plain

インストールして再起動をクリックすれば、クリック後にインストールが即座開始されます。

インストールして次回再起動をクリックすれば、次回のホスト再起動時に本アップデートが適用されます。(計画再起動時に予め更新を予約しておくイメージ)

今回は、試しに”インストールして次回再起動”を選択してみました。

この操作により、iDRAC内では”ジョブ”という形で将来のタスクが維持されます。

f:id:instructor8010:20180805214158p:plain

 

再起動を実際に行うと、サーバー上では、次のような画面で更新タスクが実施されます。上記機種ではないマシンで取得をした画像のため、ジョブに対するIDは異なりますが、本画面からどの処理が実施されているかを確認することができます。

f:id:instructor8010:20180805214326p:plain

プログレスバーが100%になると更新が完了し、製品が正常通り起動してきます。

結構幅広いファームウェア類の更新をサポートしていますので、例えばLinux系OSの管理経験が無い、Windows系管理者の方であっても、手軽に更新タスクを実行ができます。

f:id:instructor8010:20180805215001p:plain

 

次にハイパーバイザーのインストールを行います。

こちらもiDRACの機能である、イメージマウントを利用します。

f:id:instructor8010:20180805222126p:plain

CIFSまたはNFSで提供されるイメージファイルを、パス指定及び認証情報を入力すれば仮想ドライブにイメージをマウントしたことになります。

正しくマウントされると、ステータスが”接続”に変わりました。

f:id:instructor8010:20180816163558p:plain

ここからは通常通りのESXiのインストール タスクを行います。

インストール前に、RAIDボリュームの初期化も行っておきましょう。

f:id:instructor8010:20180805223523p:plain

マウントしたイメージは、”Virtual CD"として認識されているため、こちらを選択

f:id:instructor8010:20180805232537p:plain

こちらを選択すれば、後は以下のKBにあるインストーラーに従うだけでOKです。

VMware vSphere ESXi 6.xインストール手順 | Dell 日本

これと同じ作業を残りのホストにも行っていきます。せっかくなので、以前に投稿した内容に従い、BIOS上の電力管理設定もパフォーマンスモードに変更しておきます。

instructor8010.hatenablog.jp

f:id:instructor8010:20180805233707p:plain

”パフォーマンス”モードを選択しました

後は案外時刻設定なども、トラブルシュート時のロギングタイムの制御に重要なので合わせましょう。

今回はこれで以上となります。次回はvCenter Serverのデプロイ当たりを行きたいと思います。

 

小規模vSphere クラスター環境構築 on PowerEdge VRTX(2) 運用するvSphere バージョンの選定、決定方法

本記事は、次の記事の続編となります。シリーズの最初からご覧になりたい方は、以下のリンクをクリックください。

 

instructor8010.hatenablog.jp

さて、vSphere ESXiをインストールする作業は次のような操作だけなのでとても簡単です。

  • インストールメディア、イメージをマウントする
  • イメージブートをする
  • インストーラーに従い必要入力項目を入れる
    EULA承諾、インストール先指定、キーボード配列指定、rootパスワード設定)

概ねこんなものです。

インストーラーの画面キャプチャはこちらのURLをご覧ください。

VMware vSphere ESXi 6.xインストール手順 | Dell 日本

 

今回のテーマは、インストールをただ行うのではなく、その前後で必要となる重要なポイントのおさらいです。インストール前には次のような確認を常に行う必要があります。

  1. ハードウェアとvSphereの互換性の確認、インストールするバージョンの確認
  2. 必要に応じたハードウェア更新
  3. リリースノートの確認

今回は特に1と2で時間を取られました。(なにせしばらく使っていなかった機材でしたので、更新箇所が多かったです)今回は特に、このバージョン選定、決定の記事です。

 

ハードウェア互換性ですが、今回利用する環境には、”PowerEdge M520"と”PowerEdge M620”という2種のブレードがあります。

早速ですが、定番の互換性リストで確認をしてみましょう。

VMware Compatibility Guide - System Search

f:id:instructor8010:20180805165107p:plain

ESXi 6.7環境を構築しようとワクワクしていたものの、6.5 U2までという事実を叩きつけられます。しょうがない、ということで今回は6.5 U2で行きましょう。

※M520の場合は2.4.2との記載がありました。

加えまして、BIOSの動作確認済みバージョンは2.5.4かつShared PERC8(VRTX右側のドライブ郡のRAIDコントローラー)についてのドライバーバージョンについての言及を発見しました。

f:id:instructor8010:20180805172123p:plain

更にShared PERC8の互換性についても確認をします。

f:id:instructor8010:20180805172617p:plain

詳細確認のためにコントローラー名をクリックし、サポートされるファームウェアバージョンを確認します。

f:id:instructor8010:20180805172703p:plain

一覧に基づくと、動作サポートされるファームウェアは23.14.06.0013


ここから更に、PowerEdge VRTX側のマニュアルも確認します。

VRTXに存在する共有PERCには、関連するハードウェアのファームウェアのバージョンを一定のバージョンに揃える”ベースライン”という考え方が存在するため、それに揃えるようにファームウェアを確認します。

https://topics-cdn.dell.com/pdf/poweredge-vrtx_compatibility-matrix7_en-us.pdf

2018/08/05時点では、第7世代のベースラインまでが開放されているようです。
本ベースライン環境のための一致させるべき各種バージョンを確認してみると...

f:id:instructor8010:20180805173542p:plain

あれ、vSphere 6.5 U2どこいった・・・・?

あれ、6.5 U1までしか記載が...(この段階で既に6.5 U2のインストール イメージを用意済み)

という事で、急遽インストール予定のESXiを6.5 U1に変更します。

 

せめてvCenter Serverくらいは最新 6.7で行こうと思い、念の為こちらはVMware 製品相互間マトリックスを確認します。

f:id:instructor8010:20180805173811p:plain

よし、6.7.0はESXi 6.5 U1に対し互換性有りであることを確認ができました。

なにげに初めて6.7.0を実環境導入します。新UIがとても楽しみでなりません。

大まかなトポロジーが見えてきました。

f:id:instructor8010:20180806080042p:plain

vCenter SererはWindows Server版ではなく、Photon OSベースの所謂仮想アプライアンス版を利用します。ご存知の方も多いですが、Windows版vCenterは今後リリースされない予定です。かつアプライアンスベースのvCenterは既にWindows版のvCenterを遥かに上回る拡張性、機能、コスト利点を持ちます。

blogs.vmware.com

以下のリンクからダウンロードしましょう。

https://my.vmware.com/jp/web/vmware/details?downloadGroup=VC670C&productId=742&rPId=24881

 

ここまで決定した各種構成情報をまとめると次のようになります。

列挙してみると、情報量自体は10行行かない程度ですが、ここまで相互完成をベンダーを超えて合わせて決定するにはかなりの時間を使いました(知っている製品だからサクサク探せますが、初めて製品を触る人は結構探すのがたいへんですね)

※結線や設定がないから楽ちんだと選んだVRTXですが、まさかの互換性チェックで数時間取られました。執筆や画像キャプチャも結構時間がかかるんですよね。

*上記互換性セットは、2018年8月上旬時点での情報となりますので、それ以降は互換性については製品の更新に伴い変更する可能性があります点をご留意ください。本記事の主目的である、どのように製品間互換性を合わせるか、の手順を覚えて頂ければ検索も問題ないと思います。

以上です。次回は、実際のインストールや更新編となります。乞うご期待ください!

小規模vSphere クラスター環境構築 on PowerEdge VRTX(1) リモートアクセス コントローラー設定

久しぶりのブログ更新となりました。お久しぶりです。

気がつけばブログアクセス数も、本記事時点で85,000を超えるブログになっており、大変うれしく思います。

※しばらく社内トレーニングが立て込んでおり、執筆活動ができておりませんでした。

 

さてさて、既にもう8月という事で、訳あって久しぶりにvSphere環境を自分用に物理で構築しようと思い、自宅から社内ラボに接続し、この2日間、せっせとリモートで作業をしていました。

今回は久々にPowerEdgeサーバーに対し、ESXiの導入を行いましたので、その際に使ったツールや、設定のポイントを実際の画面をキャプチャしながら解説をしたいと思います。

 

物理サーバーには、Dell EMC PowerEdge VRTXを利用します。

f:id:instructor8010:20180805154225p:plain

PowerEdge VRTX、4ノードのハーフハイトブレードとSASディスクの共有ストレージが含まれます

理由:手元にあったから/共有DASストレージが筐体内に組み込まれていて展開が楽ちん

PowerEdge VRTXは本格的なラックや電源環境などが存在しないオフィスファシリティで手軽にエンタープライズレベルの環境を構築ができるのが魅力ですね。

もちろん、シャーシ全体に対する影響については、何らかの対障害プランを検討は必要です。今回は私のトレーニングや検証という名目なので、ビジネスクリティカルなアプリケーションはありませんので、この環境で申し分ありません。

 

設計概要としては、まずはマルチノードクラスターとし、vSphere HAで仮想マシンを保護するようにします。あとあと細かな要件は足していきたいと思います。

 

まずは初めに、リモートでも作業が出来るようにサーバーならではの機能であるリモートアクセスコントローラーに対しIP設定を行います。

Dell EMCではiDRAC(Integrated Dell Remote Access Controller)です。他社にも似たようなソリューションはありますね。これがあるおかげで、リモートからのサーバーに対する電源操作やエラー確認、リモートコンソール機能も利用が可能となります。

f:id:instructor8010:20180805160748p:plain

Dell EMCのiDRAC、一画面で多くの操作、確認が可能です

ブレードサーバーの場合、ブレードエンクロージャー自体にも、エンクロージャー全体の管理用のコントローラーがあります。名称は”Chassis Management Controller"です。

f:id:instructor8010:20180805161232p:plain

通称CMC、1画面でブレードサーバー全体の様子が確認可能


今回用意できたブレードサーバーが3台、エンクロージャーが1台なので、合計4つのIPアドレスを消費しました。ちなみにDellブレードサーバーには、”Quick Deploy"という機能があるので、サーバーを搭載した箇所に応じて、自動的にIPアドレスが割り当てられるように設定しました。

Quick Deployの詳細はこちらのブログを参照ください。

ブレードの効率的な管理(シャーシ管理) - PowerEdgeサーバ - Wiki - PowerEdgeサーバ - Dell コミュニティ

f:id:instructor8010:20180805161611p:plain

上図の設定であれば、IPアドレスは第4オクテットが11,12,13,14が順次割り当てられます

上記設定の有効化には、ブレードサーバーの再装着が必要となるため、再装着を行い変更を適用します。試しに想定どおりのIPアドレスアサインされたか確認してみましょう。

f:id:instructor8010:20180805162847p:plain

バッチリ、スロット1には第4オクテットが11のIPアドレスが付帯されました

最後に、Web GUIもアクセス出来るか確認してみましょう。

f:id:instructor8010:20180805163208p:plain

Quick Deployにて設定されたIPで、正常にアクセス可能

リモートコンソール機能もバッチリ利用できました、これで自宅からも作業が可能です。

f:id:instructor8010:20180805163633p:plain

iDRACのリモートコンソール機能は本記事寄稿時点では、Active X(IE), Java(Firefox, Chrome), HTML5(HTML5対応ブラウザ)にて利用可能です。

※iDRACで動作しているファームウェアのバージョンにも依存

 

最近は私もプラグインのバージョン管理工数を考え、HTML5を利用することが多いです。

さて、これにて管理のための環境は最低限整いました。次からいよいよ実践的な設定面に入ります。

ゲスト イントロスペクションのライセンス まとめ(NSX for vShield Endpointについて)

NSXには無償版ライセンスがあるのか?”

NSXと連携できるアンチウィルスの機能は無償?”

と、最近ちらほら質問されることがあります。

 

この点について今回は順を追って説明をしたいと思います。

 

【本質問に至る背景】

VMware NSXがデプロイされた環境において、”ゲスト イントロスペクション(以下GI)”というエージェントレス セキュリティ機能を利用される環境があります。

ãvShieldãã®ç»åæ¤ç´¢çµæf:id:instructor8010:20180528223746p:plain

数百台、数千台規模で管理される仮想マシン環境において、全台の仮想マシン内のセキュリティアプリケーションの管理をするのは大変困難です。

セキュリティ機能を特別なVMとして実装し、それによりハイパーバイザー上の仮想マシンの保護を行う考え方が”エージェントレス セキュリティ”です。

ゲスト イントロスペクションの詳細説明はこちらのリンクを参照ください。

 

このGIという機能は、これまで存在していた"vShield"という機能がベースであり、

旧vShieldのあり方については本記事寄稿時点とリリース当初とでは異なります。

  • 本記事機構時点:vSphereに付属する機能である
  • リリース当初:vCloud Networking and Security(以下vCNS)に付属する機能である

VMware社は、vCNSの販売終了をきっかけとし、このGIという機能の大本となる"vShield Endpoint”という機能のあり方を上記のように変更しています。

f:id:instructor8010:20180528225504p:plain
※次のリンク内より抜粋 https://kb.vmware.com/s/article/2146576

 

さらにですが、このGIを管理するためには、"VMware NSX"が必要となります。

f:id:instructor8010:20180528225943p:plain

 

これらをサマライズすると次の通りです。

  • 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以降のデプロイが必要です。

f:id:instructor8010:20180528231227p:plain

VMware NSX for vSphere 6.2.4 リリース ノート

 

項目 以前 現在
vShieldはどの製品の位置付けか? vCloud Network and Securityの一部 vSphereの一部
vShieldを管理、機能提供してくれる
モジュールは?
・vCloud Network and Security Manager(旧vShield Manager)
VMware Toolsに含まれるvShield Endpoint Driver
・ESXi上で動作するvShield Endpoint ESXモジュール
NSX Manager
・ゲスト イントロスペクション サービス仮想マシン
VMware Toolsに含まれるGI Agent
・ESXi上で動作するGI ESXiモジュール
備考 vCNSを利用していたユーザーは、
継続的にvShieldを利用する場合、VMware NSXへの移行が必要である
VMware NSXは6.2.4以降である必要がある
NSX Managerをデプロイした段階で、
既にNSX for vShieldというライセンスが適用された状態である
vSphereはEssentials Plus以降のライセンスである必要がある

 

【関連記事】

ESXi ホストの電源管理による仮想マシンのパフォーマンス向上

今回は久しぶりにvSphereのお話です。

案外知られていない小ネタとしまして、vSphereでは仮想マシンのパフォーマンスを最大限に発揮をするために、電源ポリシーのセッティングについてベンダーごとに指定があることをご存知でしょうか?

f:id:instructor8010:20180423215533p:plain

最近のx86サーバーやコンピューターはプロセッサによる電力管理機能が搭載されており、それらは主に省エネを目的としています。

しかしながら、仮想マシン上のアプリケーションに対し、最高のパフォーマンスを期待する場合、時にこれらの機能が阻害要因となるケースがあります。

大雑把に言えば、仮想マシンのパフォーマンス向上のために、電力を最大限に利用するポリシー設定にしましょうというものになります。

以下のKBでは、HPとDellサーバーを例に挙げた形で、BIOS画面上でパフォーマンスを最大限に発揮するための設定値の紹介がなされています。

 

Virtual machine application runs slower than expected in ESXi (1018206)

https://kb.vmware.com/s/article/1018206

ESXiでの仮想マシンのアプリケーションが予想よりも遅く実行されます (2032716)

https://kb.vmware.com/s/article/2032716

Configuring Power Management Options in Dell PowerEdge servers specific to VMware vSphere Environment

http://en.community.dell.com/techcenter/b/techcenter/archive/2013/06/04/dell-poweredge-powermanagement-options-in-vmware-esxi-environment

 

勿論この設定自体は、パフォーマンスの最大化のために行うものであり、電力を消費する行為は、電気代を始めとしたコストと引き換えとなりますのでご注意下さい。

Vmware Vsphere 6.5 Host Resources Deep Dive

Vmware Vsphere 6.5 Host Resources Deep Dive