VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

6回目:V4HでHorizon RDSホストの監視

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携
#6…V4HでHorizon RDSホストの監視

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、番外編として、VMware vRealize Operations for Horizon (V4H)の「Horizon RDSホスト」の監視を取りあげます。なぜ追加で取りあげることになったのか?
RDSホスト(RDSH)を使用する環境で、V4Hのよさを伝えるためにはどうしたらよいかとご相談を受けたからです。その相談に回答するように、RDSHの監視のポイントをご紹介します。

◆V4Hでは何を監視する?
最新のV4Hが使いやすくなっている!」でお伝えした通り、V4Hはセッションやログオン時間などユーザーに関連するデータを監視します。
RDS(リモートデスクトップサービス)は、セッションの仮想化(Server Based Computing)とも言いますから、RDSホストをV4Hで監視するのは適していますね。

◆SBC(Server Based Computing)とVDI(Virtual Desktop Infrastructure)の違いは?
左図がSBC、右図がVDIの違いを説明するイメージ図です。では、これらの環境を準備する目的は何でしょうか?
「OS/アプリケーションの運用管理コストを削減したい」「働き方変革に取り組みたい」というご要望から、OS/アプリケーションの仮想化が検討されます。そして、その環境をユーザーへ提供するための方法として、SBCまたはVDIが選択肢にあげられますね。

1

先の目的をふまえ、ユーザーがアプリケーションを使用するための接続先として、次の3つがあげられます。「仮想マシンベースのデスクトップ」「セッションベースのデスクトップ」「セッションベースのアプリケーション」です。この環境があれば、ユーザーは場所を意識することなく、業務を実施することができます。

VMware Horizon 6.x以降では、「セッションベースのデスクトップ」はRDSデスクトッププールで、「セッションベースのアプリケーション」はアプリケーションプールで構成します。RDS(リモートデスクトップサービス)はWindows Server 2008 R2以降から提供されているサービスです。それ以前はターミナルサービスと呼ばれていました。
そして、RDSのサービスの1つである「RDSホスト(RDセッションホスト)」が、ユーザーにデスクトップセッションアプリケーションセッションを提供します。

各種プールをまとめます!

  • 「手動/自動デスクトッププール」は、物理/仮想マシンが対象であり、デフォルトは1台のマシンに1人のユーザーがリモートアクセス可能です。「仮想マシンのデスクトップ」を提供する方法です。
  • 「RDSデスクトッププール」はセッションが対象であり、RDSホストにおけるデスクトップセッションをユーザーに提供します。RDSホスト上のデスクトップセッションは複数のユーザーによる同時利用が可能です。
  • 「アプリケーションプール」もセッションが対象であり、複数のユーザーにアプリケーション配布が可能です。アプリケーションは、ファーム内のRDSホスト上で実行されます。

RDS環境で、「OS/アプリケーションの仮想化」を運用管理する場合、セッションがポイントとなりますね!

では、V4Hの画面から、RDSに関するどんな情報が得られるのかを、ダッシュボードごとに確認します。

◆Horizon RDS プール
「Horizon RDS プール」タブでは、「ファーム」「RDSデスクトッププールと「アプリケーションプール」のセッション数を確認することが可能です。
ファームは、RDSホストの集まりです。ユーザーが接続すると、ファーム内のRDSホストが選択され、セッションが提供されます。ファーム内のRDSホストの数は、ロードバランスの可否や提供したいアプリケーションによって検討する必要があります。
下図では、ファーム内でデスクトップとアプリケーション(ここではInternet Explore)のセッションが1つずつ提供されています。RDSホストの最大セッション数(接続数)は、デフォルト150です。設定値を無制限にすることも可能です。設定値は、RDSホストのキャパシティに応じて決めることをお勧めします。V4Hを導入後、最適な値を設定するのも一つの方法です。

2

キャパシティを判断する際に参考になるのが、同じタブ内にある次の情報です。
ヒートマップの健全性、トップN のCPUワークロードやPCoIP遅延などのリソース状況です。この情報から、現在のキャパシティに適した接続数であるかを判断できますね。
ファーム内に複数のRDSホストが追加されている場合は、ロードバランス(負荷分散)されます。ユーザーに新規セッションが提供される際、ファーム内で利用可能なセッション数が多いRDSホストや、CPU/メモリの負荷が低いRDSホストが選択されます。リソースでのロードバランスは、事前にスクリプトを構成する必要があります。

https://pubs.vmware.com/horizon-7-view/index.jsp#com.vmware.horizon-view.administration.doc/GUID-54966EA2-8542-43B1-A5D4-60C8B21C0AC8.htm


3

◆Horizon RDS ホストの詳細
「Horizon RDS ホストの詳細」タブでは、各RDSホストの情報が得られます。
V4Hは同じデータの視点を変えて表示されます。RDSホストのキャパシティに関する情報はこちらのタブの方が多くを確認できますね。

4

また、ユーザーがどの程度リソースを使用しているかは、管理者にとって気になるところです。「RDSホストのプロセスとユーザー」では、「サーバーサービス」「サーバープロセス」「サーバーユーザー」のリソース使用状況を取得できます。下図は、「サーバーユーザー」を取得した画面ショットです。

「ユーザーリソース消費量」では、デスクトップセッションとアプリケーションセッションを別に確認することも可能です。


5

6

◆Horizon アプリケーション
「Horizon アプリケーション」タブでは、アプリケーションプールで構成したアプリケーションの状況を確認することができます。
左の「アプリケーションプール」では、アプリケーションのインスタンス数(起動数)と起動平均時間(秒)、相関関係の情報を得られます。「アプリケーションプールの関係」では、そのアプリケーションセッションを利用するユーザー名や提供するRDSホストが存在するファームの名前を確認することができます。


7

「アプリケーションインスタンス」では、アプリケーションセッションを提供するRDSホストの名前や、そのセッションのリソース使用状況を確認することができます。

8

◆セッション
最後に、セッションのカウント方法をご紹介します。接続するRDSホストの数=セッション数です。
たとえば、左図は複数のアプリケーションが1台のRDSホストで提供されているパターンです。アクセスするRDSホストは1台ですから、セッションは「1」です。
右図は、各アプリケーションが各RDSホストで提供されているパターンです。接続するRDSホストごとにセッションをカウントしますから、セッションは「2」です。

9

次は、ファームで提供するアプリケーションが異なるパターンです。これは上図のパターン2と同様の考え方です。アクセスするRDSホストは2台ですから、セッションは「2」です。セッション数のカウント方法はシンプルですね!


10

◆まとめ
V4Hでの監視対象はおもにユーザーセッション関連です。
仮想デスクトップもRDSHも、セッションやPCoIP遅延の情報を監視するのは同じです。異なるのは、基盤の部分です。
仮想デスクトップは1ユーザーにつき仮想マシンが1台提供され、RDSは複数のユーザーにRDSホストのセッションが提供されます。
vROpsは仮想マシンのリソース状況を監視しますね。V4Hは、vROpsで対象となる仮想マシンを、提供するサービスによって「仮想デスクトップ」や「RDSホスト」と呼び、セッション状況を監視します。
1ユーザーが使用する仮想マシン(仮想デスクトップ)のセッション/リソース状況を確認するのか、複数ユーザーが使用する仮想マシン(RDSホスト)のセッション/リソース状況を確認するのか、の違いです。
呼び方が変わる、機能がAdd-Onされると、複雑に感じますね。しかし、何を監視対象としているのかの区別がつけばシンプルになります。
アプリケーションの仮想化は、働き方改革により注目されていますね!
VMware Horizon環境下で、RDSHを使用する場合は、合わせてV4Hでの運用管理も検討いただければと思います。

nakagawa

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!

voa

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

2回目:仮想スイッチのお作法#2 (分散スイッチはいつ使用する?)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、仮想スイッチの歴史とロードバランスの1つであるポートIDベースについてとりあげました。なぜポートIDベースについてとりあげたのか?
それは、なぜその設定が必要なのか、なぜその機能が追加されたのかを理解するためには、ポートIDベースを理解することが早道だからです。
現在、NICチーミングをデフォルト設定のまま構成することは少なくなりましたね。それらの設定を変更する際、状況に応じては、分散スイッチを選択する方が運用管理の煩雑さを避けることができます。今回は、あらためて分散スイッチのよさと、いつ使うのがよいのかをご紹介します。

◆標準スイッチと分散スイッチの違い
最初に、標準スイッチと分散スイッチの異なるところ/同じところを復習します。

<異なるところ>
異なるところは、ネットワークポリシーを管理する場所です。ネットワークポリシーには、「セキュリティ」「トラフィックシェーピング」「NICチーミング」があります。
「標準スイッチ」は各ESXiホストで作成しますが、ネットワークポリシーも各ESXiホストで管理します。

1

「分散スイッチ」は複数のESXiホストにまたがって作成され、ネットワークポリシーはvCenterサーバーで一元管理します。仮想マシンを複数のホスト間で移行する場合でも、仮想マシンに対して一貫したネットワーク構成を提供することができます。
ポリシーは各ESXiホストにプッシュインストールされます。vCenterサーバーとの通信が遮断されたとしても、ポリシーで設定した動作に支障がない仕組みを持っています。


2

<同じところ>
構成するコンポーネントの概念は同じです。先に、標準スイッチからコンポーネントの名前を確認します。


3

Port/Port Group
仮想NICが接続する仮想スイッチのポート(出入口)です。ポートには、「仮想マシンポートグループ」と「VMkernelポート」があります。仮想マシンポートグループは、名前の通り複数の仮想マシン用のポートです。

vmk#(0
から連番)
VMkernelポートに接続されている仮想NICには、「vmk#」という特別な名前が付けられます。ESXiホストが通信するために、vmk#にIPアドレスを付与します。

Uplink Port

物理NIC(Uplink)が接続する仮想スイッチのポート(出入口)です。

vmnic#(0から連番)
物理NICのことです。

Port/Port Group
の識別名:
左図では、MGMT/Production/vMotionが該当します。ネットワークポリシーの識別名でもあります。

次に分散スイッチです。


4

分散スイッチが標準スイッチと異なるのは次の2つです。

dvPort Group
分散スイッチのポートグループをdvPort Groupと呼びます。ポートは複数のESXiホストに分散配置されます。

dvUplink Ports
論理的な物理NICのポートです。論理的と表現したのは、複数のESXiホストの物理NICをグループ化し、1つのdvUplink Portに割り当てるからです。
分散スイッチでは、いくつの物理NICを割り当てるかを、「dvUplink Ports」の数として指定します。そして各dvUplink PortsにESXiホストの該当物理NICをアサインします。左図では、dvUplink Port 1に3台のESXiホストのvmnic2が割り当てられています。

※dvは「Distributed Virtual」の略

図3と図4の仮想マシンポートグループ「Production」に注目してください。
標準スイッチと分散スイッチを構成するPortとUplink Port(dvUplink Ports)は、同じ構成(図形)で描かれています。標準スイッチと分散スイッチは、単体のESXiホストで構成されるのか、複数のESXiホストにまたがって構成されるかだけの違いです!

本題に入ります!

◆vMotionを例にしたネットワークポリシー設定
前回のBlogで、下図のようにvMotion用にNICチーミングを構成することで、冗長化だけではなく、パフォーマンスの向上も期待できることをご紹介しました。それは2つの物理NICを活用できるからでしたね。

5

vMotionで必要な設定は次の通りです。

6

ESXiホストの台数が多くなると、なかなか煩雑な作業です。
たとえば、2つの物理NICを割り当てた標準スイッチで、vMotion用の設定を10台のESXiホストで構成するとなると・・・標準スイッチで、vMotion用のVMkernelポートを2つ作成し、各々でNICチーミングの設定をします。これを10回繰り返すことになります。
入力ミスや設定ミスが生じるかもしれません。分散スイッチであれば、ESXiホストが何台であろうと、ネットワークポリシーの設定は1回の作業で完了します。
管理するESXiホストの台数が多くなれば、分散スイッチに分がありますね。

◆分散スイッチはいつ使うの?
分散スイッチはいつ使うのがよいのでしょう。分散スイッチで提供される、「物理NIC負荷に基づいたルート」と「ネットワーク I/O コントロール」を例に説明します。

<物理NIC負荷に基づいたルート>
分散スイッチのみで提供しているロードバランスの方法(物理NICの選択方法)が、「物理NIC負荷に基づいたルート」です。
物理NIC負荷に基づいたルートは、ポートID と複数物理NICのアップリンク(物理NIC)数を取得し、仮想マシンのアップリンクの負荷を計算します。30 秒ごとにアップリンクを監視し、その負荷が使用量の75 パーセントを超えると、I/O の使用率が最も高い仮想マシンのポート ID を別のアップリンクへ移動します。名前の通り、負荷状況に応じて最適な物理NICを選択する方法です。
デフォルトのポートIDベースはポートによって物理NICが選択されるシンプルな方法ですから、アップリンクの負荷までは見ていません。
仮想マシンの台数が多い仮想デスクトップ環境の場合は、「物理NIC負荷に基づいたルート」を選択することをお勧めします。Horizon Bundleのライセンスでは、vSphere Desktop(vSphere Enterprise Plusと同等の機能) が含まれます。このライセンスであれば、分散スイッチを使用できますね!

<ネットワーク I/O コントロール>
CPUやメモリーのリソースコントロールと同様に、ネットワークリソースのコントロールができる機能です。設定値には、「シェア」「予約」「制限」があります。

7

最近注目されているHCI基盤を例に説明します。10Gbpsの物理NIC2枚構成の場合、図3のようなトラフィックごとの仮想スイッチを準備することができません。物理NICは仮想スイッチ間で共有できませんから、1つの仮想スイッチに複数のトラフィック(役割)を構成することになります。
ここで、パフォーマンスが気になりますね。分散スイッチであれば、トラフィックごとにネットワークリソースのコントロールが可能です。
デフォルトのネットワークリソースの割り当ては、すべて無制限です。帯域幅が飽和した場合に、ネットワーク I/O コントロールの「シェア値」を使用することで、帯域幅の割り当てをコントロールできます。管理者としては、より多くの仮想マシントラフィックに、より多くのiSCSIトラフィックに十分な帯域を割り当てたい、優先順位を付けたいと考えますよね。そのような場合に備え、ネットワークリソースのコントロールをご検討いただければと思います。

下図は、vSphere Web Clientのネットワークリソース割り当ての画面ショットです。


8

実際の設計/導入の場面では、下図のように1Gbps物理NICを接続した標準スイッチに管理ネットワークを、10Gbps物理NICを接続した分散スイッチにそれ以外のトラフィックを構成されることが多いと思います。下図は設計例の1つです。
この場合も複数のトラフィックを構成している分散スイッチは、ネットワーク I/O コントロールでのリソースコントロールをお勧めします!
1Gbpsと10Gbpsの混在環境では、「構成の上限(※)」にご注意ください。vSphere 6.5では、1Gbpsは4、10Gbpsは16です。

(※)vSphereの各バージョン毎に準備されているConfiguration maximum ガイドを参照下さい。
vSphere6.5のConfiguration maximum ガイドはこちら

9

◆まとめ
今回はあらためて仮想スイッチをとりあげました。分散スイッチは、Version 4.0から「vSphere Enterprise Plus」ライセンスで提供されています。上位ライセンスのため、標準スイッチと比べて、頻繁に導入する機会はなかったのではないかと思います。
しかし、この数年注目されつつある「VMware NSX」では、分散スイッチが前提となります。また、物理NICも10Gbpsが一般的になってきましたから、ネットワーク I/O コントロールの提案もしやすくなっている状況ではないでしょうか。
提案時のエンドユーザー様はコスト重視の傾向がありますが、導入後のトレーニングでは、「先に話してくれれば。。。」とよく言われました(笑)
費用がかかるからこそ、その効果を知っていただくために、事前の勉強会も必要なのでは?と特に感じています。その際にはこちらのBlogをテキストに勉強会を企画いただけたら嬉しく思います。

8

nakagawa

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

1回目:仮想スイッチのお作法#1 (仮想スイッチの歴史とポートIDベースロードバランス)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、あらためて「仮想スイッチ」について取りあげます!!
私は、2009年から2015年までVMware認定インストラクターとして、「VMware vSphere : Install, Configure, Manage (5日間)」等の公認コースを実施してきました。
インストラクターとして得た、「ここがポイントですよ!」を共有しながら、標準スイッチと分散スイッチの同じところ/異なるところをご紹介していきます。
第1回目は、仮想スイッチの歴史とロードバランスのポートIDベースについてご紹介します。

◆仮想スイッチの歴史
Version3.5の知識のままvSphereを管理運用されているエンドユーザー様にお会いすることがあります。たとえば、vSphere HAや仮想スイッチです。仮想スイッチの1つである標準スイッチは3.5から変更点はありませんから支障がないのかもしれません。
しかし「ESXiホストの管理台数が増える」「ハードウェアの進化を活用する」となると、新しい知識(機能)が必要になります。そしてベストプラクティスも変更されていきます。
私は、エンドユーザー様にアップデートされた機能に興味をもっていただきたい場合、歴史(機能の変遷)の話をします。ご存知の時点から順に歴史の話をすると、興味をもっていただける傾向があります。では、歴史のお話を!
仮想スイッチの歴史は、公認コースのテキストを使用します。
Versionが上がれば機能が増えます。機能が増えればコースのスライド内容が変わるのは当然と思うかもしれません。しかし比較してみると、機能だけではなく、「思い(ベストプラクティス)」も伝わってくる気がします。順次見ていきましょう。

◆Version 3.5
古くからVMware製品に携わっている方には、懐かしい「サービスコンソールポート」です。3.xまでは管理ネットワークの接続タイプが必要でした。この図では、1つの「標準スイッチ」に複数の接続タイプが構成されています。1Gbps物理NIC3つの構成では、パフォーマンスに支障が出そうですね。
接続タイプ:3種類のネットワーク接続

1

◆Version 4.0
4.0になって、用途によって仮想スイッチを分ける例が紹介されています。この時は、用途別に仮想スイッチを分けるのは一般的でしたね。課題はESXホストの物理NICの数でした。冗長化を考慮するなら、最低2倍の物理NICが必要です。

2

◆Version 4.1
4.1になると、冗長化を意識した、複数の物理NICが搭載された図になっています。1Gbps物理NICが主流の時のベストプラクティスが見えてきますね。上の構成図は、10Gbps物理NICを使用した分散スイッチに適していますね!

3

◆Version 5.5
スライドの構成は、4.1以降変更はありません。しかし、各役割のVMkernelポートが1つという構成は最近ありませんね。vMotionであれば帯域確保や、iSCSIであればパスを増やす必要があります。その場合、複数のVMkernelポートを構成します。

4

◆なぜVMkernelポートは複数必要?
なぜVMkernleポートが複数必要なのかを知る前に、NICチーミングの「ロードバランス」を復習します。ロードバランスは物理NICの選択方法です。デフォルト値はポートIDベースです。ここでは仮想マシンポートグループを使用して、ポートIDベース確認します。物理NICは、仮想NICが割り当てられた仮想スイッチのポートによって選択されます。たとえば、下図は、VM①の仮想NICはポート0に割り当てられています。ポート0に接続されたVM①の通信は物理NICのvmnic0を使用します。同様にVM②はvmnic1を、VM③はvmnic2を使用します。すべての物理NICが選択されたため、残りのVM④は再びvmnic0を使用して通信をします。この説明はあくまでもイメージです。ポートIDベースは名前の通り、仮想NICが割り当てられたポートをベースに物理NICを選択し、ロードバランスをします。シンプルな物理NICの選択方法ですね。デフォルト値であることは納得です!

5

次に、VMkernelポートはどうでしょうか?
下図は、vMotionの構成例です。この仮想スイッチには、vMotion用のVMkernelポート(vmk0)が1つ構成され、物理NICが2つ(vmnic0/vmnic1)割り当てられています。VMkernelポートはESXiホストが通信をするために必要なポートですから、IPを付与するだけなら、1つでも支障はなさそうです。ただし、デフォルトのロードバランス設定はポートIDベースですから、フェイルオーバーが起きなければvmnic1は使用されません。ポートIDベースは、仮想NICが割り当てられた仮想スイッチのポートによって物理NICが選ばれるから。。。でしたね。この構成で冗長性は満たしていますが、2つの物理NICを十分に活用しているとは言えません。

6

ではどのように構成するのがベストでしょうか。参考までに次のKBをご確認ください。

-vSphere における複数 NIC の vMotion-
https://kb.vmware.com/kb/2014840

VMkernelはデフォルトのポートIDベースを使用します。複数の物理NICを活用するには、活用できるように構成をする必要があります。下図のように物理NICが2つあれば、VMkernelも2つ作成し、それぞれにActive-Standbyの設定をします。この構成をすることによって、2つの物理NICを活用し、帯域を拡張することができます。パフォーマンスを上げられますね。

7

VMkernelポートは、vMotion以外の用途として、「管理ネットワーク」「iSCSI/NFS」「FT」がありますね。管理ネットワークは、vSphere HAハートビートに影響がありますから、私は念には念を入れてロードバランスの値として、「明示的なフェイルオーバー」の設定を行っています。iSCSIでは、ポートバインドの設定が必要な場合もあります。参考までに次のポートバインドのBlogをご確認ください。

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/04/05/equallogic-vsphere-portbind

◆まとめ
ポートIDベースの物理NICの選択方法を知ると、特にVMkernelポートではNICチーミングが必要な構成であることをご理解いただけたと思います。ESXiホストが少ない場合は、複数の標準スイッチにポリシーを構成するのも煩雑ではないかもしれません。しかし、VDI環境など多くのESXiホストがある環境では、ポリシーを一元管理できる分散スイッチが注目されてきますね。
次回は、分散スイッチを活用するシチュエーションについてご紹介します。

8

nakagawa

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

5回目:vRealize Log Insightとの連携

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携
#6…V4HでHorizon RDSホストの監視

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回はvRealize Operations ManagerとvRealize Log Insightを連携した活用法をご紹介します。

仮想化健康診断では、「ワークロード」と「ストレス」の値を参考に、分析してくださいとお話しています。「ワークロード」は現在の状態を、「ストレス」は過去6週間の平均値を表わしています。
下図の「ストレス」の結果から、木曜の16時から18時、19時から20時の間で負荷が高いことがわかります。たとえば、バックアップなど定時に高負荷な状態が起きる場合は、この画面から原因を推察することができます。しかし突発的な負荷が起きた場合は、原因を調査する必要があります。その際、Log Insightで収集されたイベントから何が起きたかを調査すれば、より早く原因を特定することができます。vROpsとLog Insightを連携することで、よりパワーアップできますね。
stress

このBlogでは、ネットワークの負荷を高めた状態を準備し、原因を特定するまでのプロセスを、連携の活用法としてご紹介します。
ネットワークの負荷を高める方法は、仮想マシン「Win7-01(192.168.250.202)」から、仮想マシン「Win7-02(192.168.250.200)」へPingコマンドを実行します。
Pingコマンドは、「-t:パケットの送受信を無限に繰り返す」と「-l:パケットのデータサイズ(バイト単位)を指定する」の2つのオプションを追加しています。今回は負荷を高めるため「-l 1000」を指定しました。-lのデフォルト値は32バイトです。
実行してしばらく経つと、「推奨」タブに、Win7-01でCPU使用量が高いためストレスが発生しているとアラートが表示されました。
alert

◆vROpsでの分析◆
ここから順に原因を特定していきます!
「Win7-01」の「分析」タブで詳細な状況を確認します。通常とは異なる状態であることを表わす「アノマリ」が高い値を示しています。
anomaly
どのリソースが高い値を引き起こしているかを、画面下部の詳細情報から確認します。
これらの情報から、「ネットワークリソース」に原因があることがわかります。
Detail
「詳細」タブの「仮想マシンのネットワークI/O診断」からは、14:40以降に受信/送信パケット数が上がっていることもわかります。
Detail2
ここで、あらためてネットワークのパフォーマンスについて確認します。

◆仮想ネットワークのパフォーマンス◆
仮想ネットワークは、「スループット」や「パケットドロップ」のメトリックを使用してパフォーマンスを監視します。特に「パケットドロップ」が発生しているかを確認することはパフォーマンス劣化の原因を特定する有効な方法です。
パケットドロップは、受信と送信でパフォーマンス劣化の原因が異なります。そのため対応方法もそれぞれ異なります。

<ドロップ送信パケット>
送信パケットは、ネットワークキャパシティが足りない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

<ドロップ受信パケット>
受信パケットは、準備できていない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

「準備できる」というのは、受信する仮想マシンで、仮想CPUに物理CPUが割り当てられた状態です。物理CPUが割り当てられなければ、受信処理を行うことができません。
仮想マシンのCPU使用率は、受信パケットのドロップ数にも影響を与えます。

◆Log Insightでイベントの検索◆
下図は、「IPアドレス」と「dropped」をキーワードに、仮想マシン「Win7-01」のLogを検索した結果です。木曜(12/8)の17時前後にドロップされているイベントがあります。vROpsの「ストレス」で確認した曜日と時間が一致しています。ドロップによるパフォーマンスが劣化していることは確定しました。
LI
参考までに、受信側の仮想マシン「Win7-02」の状況も確認してみます。
こちらの仮想マシンも、「アノマリ」で高い値を示しています。送信側の仮想マシン「Win7-01」と異なるのは、「CPU|準備完了」の値も上がっています。仮想CPUに物理CPUに割り当てられず、受信処理が行われていないことがわかります。
ネットワークのパフォーマンスが劣化している場合は、原因特定にCPUの状況も確認する必要がありますね。
Detail3

◆まとめ◆
Log Insightと連携することで、詳細な日時で何が起きたのかを確認することができます。
vROpsの「詳細」タブでは日時までは確認できますが、具体的に何が起きているかまでは調査するのは厳しいですね。
仮想化健康診断で、具体的な日時で何が起きているのでしょうかと聞かれます。連携すると、このご質問にも対応できますね。ぜひご活用いただきたいと思います。
計9回(パート1 x4回パート2 x5回)にわたり、vROpsの活用法をご紹介してきました。「このBlogで勉強しています」と声をかけていただくこともあり、嬉しいフィードバックでした。
今後も、様々な製品の活用法をご紹介していけたらと思います!

nakagawa
ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!
voa

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

4回目:レポートの活用方法

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携
#6…V4HでHorizon RDSホストの監視

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回はレポートの活用方法をご紹介します。レポートを活用するためには、カスタマイズが必要です!!

◆よくあるご質問◆

「レポートの出力期間を変更したい」と質問を受けることがあります。その場合はレポートの元となる「ビュー」の日付範囲を変更します。
レポートは、1つ以上の「ビュー」または「ダッシュボード」、もしくは両方から構成されます。データの表示は「ビュー」または「ダッシュボード」を使用し、レイアウト(配置)や出力形式(PDF/CSV)をレポートの作成ウィザードで指定します。

◆カスタムレポートの作成①◆

既存レポートの出力期間(過去の期間)をデフォルトの30日から特定の2ヶ月間に変更します。
<データタイプの確認>
ここでは、「ホストのCPUデマンドおよび使用量(%)トレンドビューレポート」をカスタムの対象にします。どのビューを元にレポートが構成されているかを確認します。レポートを選択し、「テンプレートの編集」アイコンをクリックします。

edit-report-template

「2.ビューとダッシュボード」の「データタイプ」が表示されます。このレポートは、「ホストのCPUデマンドおよび使用量(%)トレンドビュー」というビューで構成されていることがわかります。

edit-report-template2

<ビュー/レポートの編集>
レポートのデータ表示期間を変更するには、レポートのデータタイプで指定されたビューの日付範囲を変更します。その後、変更したビューに差し替えます。この場合、ビューもレポートもコピーを作成し、変更することをお勧めします。

■ビューの編集
edit-view

■レポートの編集
edit-report
edit-report2

◆レポートの出力◆
レポートのテンプレートを実行し、レポートを出力(ダウンロード)します。
download-report

下図は、日付範囲を変更したレポートをPDFで出力した結果です。「特定の日付範囲」で指定した8月~9月の過去データが表示されています。

display-report

◆カスタムレポートの作成②◆
新規レポートを作成します。前回のBlogで作成したカスタムビューを元にレポートを作成します。
下図は、前回のBlogで作成したカスタムビューです。
custom-view

<レポートの新規作成>
create-report
create-report2

◆まとめ
2つのカスタムレポートの作成方法をご紹介しました。ぜひ活用してみてください!
全体を通したお話となりますが、vROpsに慣れるまでは標準の機能(ダッシュボード/ビュー/レポート)を使用してみてください。vROpsを知る段階で、カスタム機能までを習得しようとすると、「やることがいっぱい」「カスタム機能は難しい」と思ってしまうようです。
まずは、「vROpsで何ができるの?」を知ることから始めてください。その後、カスタム機能を習得するのが理想的です。カスタム機能については、ぜひこちらのBlogをご活用いただけたらと思います。

次回は、vRealize Log Insightとの連携をご紹介します。

nakagawaソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方 が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!
voa

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

3回目:ビューの活用方法②

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携
#6…V4HでHorizon RDSホストの監視

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回お伝えしましたとおり、今回はカスタムビューの活用方法をご紹介します。

最初に、エディションごとの機能を確認します。

◆エディション◆
カスタム機能を使用するには、「Advanced」エディション以降が必要です。前回ご紹介した標準ビューの機能は、「Standard」エディションから使用できます。

lic

◆カスタムビュー◆

下図のビューは、「CPU」「メモリ」「データストア」「ネットワーク」の4つのメインリソースのワークロードを調査するために新規作成しました。グラフが少々ひしめき合っていますが、複数リソースの相関関係の確認を前提に構成しました。

main-resource-workload

たとえば、ネットワークI/Oの遅延の原因を調べていたら、CPUの処理性能が原因だったということがあります。複数のリソースを並べたカスタムビューを活用すれば、このような相関関係を確認する場合に最適です!
先のカスタムビューを例に、「CPU」と「ネットワークI/O」の相関関係を調べたい場合は、「メモリ」と「データストアI/O」の凡例(ラベル名)を2回クリックします。そうすることで、調査対象のグラフのみ表示されます。もう一度ラベル名をクリックすれば、グラフは再表示されます。1つのカスタムビューで、表示を切り替えることにより、活用度がぐ~んと上がりますね。

ここからは、カスタムビューの作成手順を確認します。

◆カスタムビューの作成①◆

ナビゲーションパネルの「コンテンツ」ボタンをクリックします。左メニューから「ビュー」をクリックし、ビューの管理画面を表示します。「ビューの作成」ボタンをクリックします。

create-view

先のカスタムビューを例に、新規作成します。5つのステップで完成です!


1
2
3
4-1
4-2
4-3
4-4
4-55

◆標準ビューを利用したカスタムビューの作成◆

次は、標準ビューをコピーし、ビューを作成する方法を確認します。この方法は、表示されるデータのみを変更したい場合に適しています。
先にコピー元となるビューを確認します。下図は、「仮想マシンのワークロードデマンドサマリリスト」ビューです。仮想マシンが過去1週間に使用したリソース状況を確認することができます。仮想マシンでワークロードが高い場合、どのリソースが高いワークロードを引き起こしているかを特定することができます。
各リソースは、「5分」間隔でロールアップされ、過去「1週間(7日間)」の「平均値」が表示されます。これらはデフォルトの値です。「ロールアップ間隔」と「日付範囲(期間)」は、この画面のアイコン(赤枠)から都度変更できます。

rollup

◆カスタムビューの作成②◆

デフォルトの平均値を「最新値」に変更するカスタムビューを作成します。最新値を表示したいというご要望はよくあります。
ビューの管理画面で、変更したいビューを選択し、「ビューのクローン作成」アイコンをクリックします。

view-clone

ここでは、「名前」とデータの「変換」の値を変更するだけです!

custom-view-1

他に、何が変更できるのかを確認します。
「ロールアップ間隔」と「日付範囲」は、ビュー画面以外にウィザード内でも変更できます。


custom-view-2
custom-view-3custom-view-4

◆まとめ◆

すべてのビューをながめてみました。ビューでは、さまざまな視点からデータを得られます。そのデータをぜひ活用いただきたいです。
加えてビューは、ダッシュボードやレポートを構成するウィジェットとしても使用できます。ダッシュボードのビュー活用法はこちらのBlogで紹介しています。レポートのビュー活用法は次回のBlogでご紹介します。
実は、「vROpsをパワーアップしよう!」Blogを投稿する前は、カスタムが苦手でした。しかし、Blogを執筆する機会を得たり、ワークショップでエンドユーザー様からのご要望にお応えしたりするうちにすっかりはまってしまいました(笑)。

このBlogから、みなさんの仮想基盤がパワーアップされましたら、うれしい限りです!!

nakagawa

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!

voa

vSANのデザインとサイジング - メモリオーバーヘッドに関する考慮点

今週はEMEAで開催されるテックサミットに参加するためベルリンに来ています。このイベントはEMEAのフィールドの皆さんのためのイベントです。私は、vSANのデザインとサイジングを含むいくつかのセッションを担当しました。そのセッションの一部では、トピックとしてvSAN環境でのメモリ消費について取り上げました。過去には、こちらのブログでも触れました通り、ディスクグループ構成によるホストのメモリ要件についてのみお話しをしてきました。例えば、vSANの最大構成時(ホスト毎に最大5つのディスクグループ、各ディスクグループには最大7台のディスクを割り当て可能)には、ホストのメモリを最低でも32GB消費します。しかし、これはvSANのみが消費するのではなく、ワークロードを実行するために消費されるのかもしれません。その値は構成の上限としてお考えください。上の過去のブログで触れたように、もしホストが32GB以下のメモリしか搭載していない場合は、ホスト上で作成されるディスクグループの数を減らす必要があります。
私の知っている限り、何がvSANクラスタ上のメモリ消費の一因となるのかについて、情報として共有されていませんでした。このブログで、その部分について説明をしていきたいと思います。

[Update] KB2113954でも、vSAN環境でのメモリ消費について触れられています。

vSAN環境のメモリ消費を理解するために、以下の方程式が使われます。

equation

BaseConsumption:ESXiホスト毎で、vSANによって消費される固定のメモリ量。この値は現在は3GBです。このメモリは、vSANのディレクトリ情報、ホスト毎のメタデータ、メモリキャッシュを格納するために使われます。vSANクラスタが16ノードを超える場合は、BaseConsumptionの値は300MB増えて、3.3GBとなります。

NumDiskGroups:ホスト毎のディスクグループ数。1から5の範囲で設定可能です。

・DiskGroupBaseConsumption:ホストの個々のディスクグループによって消費される固定のメモリ量。この値は現在500MBです。このメモリは、主にディスクグループ毎の操作の際に使われます。

・SSDMemOverheadPerGB:SSDの各GB毎に割り当てられた固定のメモリ量。この値は現在はハイブリッド環境では2MB、オールフラッシュ環境では7MBとなっています。このメモリの大部分は、ライトバッファやリードキャッシュ用途として使われるSSD内のブロックのトラックを保持するために使われます。

・SSDSize:SSDのサイズ(GB)

注意:これらの値はvSAN 6.0,6.1,6.2を前提としています(KB2113954参照)。将来バージョンで変更される可能性があります。

それではいくつかのシナリオに沿ってメモリ消費について理解を深めていきましょう。

シナリオ1
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GB。

例1
ホスト毎に1つのディスクグループ、ハイブリッド構成

example1

例2
ホスト毎に3つのディスクグループ、ハイブリッド構成

example2

例3
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example3

例4
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example4

シナリオ2
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以上、SSDのサイズは600GB。
vSANクラスタが16台を超える場合は、BaseConsumptionは300MB増えてトータル3.3GB。

例5
ホスト毎に1つのディスクグループ、ハイブリッド構成

example5

例6
ホスト毎に3つのディスクグループ、ハイブリッド構成

example6

例7
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example7

例8
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example8

シナリオ3
各ホストで32GB以下のメモリを搭載。32GBよりも少ないため、メモリの消費量は公式(SystemMemory/32)に従って直線的に減少します。SystemMemory(GB)とは、システムに搭載されるメモリの搭載量です。よって、システム搭載メモリが16GBの場合、メモリ消費量は公式から”1/2”となります。システム搭載メモリが8GBの場合、”1/4”まで減少します。

各ホストの搭載メモリが16GB、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GBという前提で考えましょう。

例9
ホスト毎に1つのディスクグループ、ハイブリッド構成

example9

例10
ホスト毎に3つのディスクグループ、ハイブリッド構成

example10

例11
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example11

例12
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example12

vSAN構成におけるメモリ消費量について、いくつかの例をもとにまとめてきました。このようにして、vSANのメモリオーバーヘッドを算出することができます。特に考慮すべき点は、以下の通りです。

・ホストのメモリ搭載量が32GB以下の場合には、vSANはメモリ消費を抑制します
・16ノードを超えるvSANクラスタ環境では、追加でメモリを消費します
・オールフラッシュ構成では、ハイブリッド構成と比べて追加でメモリを消費します

VMware NSX for vSphereへの移行

3回目:VMware NSX for vShield Endpointへの移行検証サマリー

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。このBlogでは簡単な手順を共有します。詳細な手順をお知りになりたい方は、この後ご紹介するURLから入手ください。

◆構成図◆
今回の手順は、下図の構成で環境を構築しています。赤点線枠のコンポーネントをアップグレードします。vSphere 6.0環境下で、NSX for vShield Endpointへ移行します。
今後、vSphere 5.5 U1 + View 5.3 + Deep Security 9.5環境下からのアップグレード手順もご紹介する予定です。
env

◆アップグレード手順◆
次の11ステップを進めます。
1
2
3
4
5
6
7
8
9
10
11

◆詳細手順◆
<アップグレード手順>
詳細手順を入手されたい方は、こちらにアクセスください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/20161206_NSXforvShield_Upgrade_Guide.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

<新規手順>
「NSX for vShield EndpointおよびDeep Securityの新規構築」手順も準備しました。
こちらから入手ください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/Tips_NSX6.2.4_DS9.6SP1_PoC_20161121.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

◆まとめ◆

今回のBlogでは、vSphere 6.0環境でのアップグレード手順を共有いたしました。vSphere 6.0環境をご使用のエンドユーザー様は、こちらの手順を参考にアップグレードの計画を進めていただけましたらと思います。
最後に、仮想スイッチについて補足します。NSX for vShield Endpointは、標準スイッチ(vSS)での動作をサポートしています。今回の環境は標準スイッチを構成しています。他の3つの有償エディション(Standard/Advanced/Enterprise)では、分散スイッチ(vDS)のみのサポートになります。標準スイッチはサポートされません。仮想デスクトップ環境は、より多くのESXiホストで構築されています。複数のESXiホストで構成されたクラスタ環境において、分散スイッチのメリットを享受できます。こちらのBlogで、あらためて分散スイッチの活用方法についてご紹介したいと考えています。現在標準スイッチで仮想デスクトップ環境を構築されていらっしゃる場合は、分散スイッチのメリットをご認識いただけましたら幸いです。

nakagawa

VMware NSX for vSphereへの移行

2回目:Deep Securityを実装するためのNSX

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、vCloud Networking and Security (vCNS)の販売が終了したことをお知らせしました。早急にVMware NSX for vSphereへの移行を検討しなければいけませんね。
今回は、トレンドマイクロ社のDeep Securityにフォーカスし、Deep Securityを実装するためのNSXエディションについてご紹介します。

NSXの各エディションとDeep Securityが提供する6機能の使用可否を整理します。
matrix

上の表から、主な使用目的は次の2つに分けられると思います。

①不正プログラム対策(ウイルス対策)
②侵入防御、ホスト型ホストファイアウォール

目的に合わせて、どのNSXエディションを選択するべきかを順に確認します。

①ウイルス対策のみの場合 (赤枠)ウイルス対策のみを使用したい場合は、無償ライセンスのNSX for vShield Endpointを含めた 4つのVMware NSXを選択することが可能です。

anti-virus

②侵入防御やファイアウォールの場合 (緑枠)侵入防御やファイアウォールを使用したい場合は、「AdvancedまたはEnterprise」を選択するか、「NSX for vShield EndpointまたはStandard」を選択するかの2パターンがあります。それぞれ準備するコンポーネントが異なります。

◆Advance / Enterprise◆
NSXのAdvancedまたはEnterpriseを選択する場合、Deep Security Virtual Appliance(DSVA)のみで、侵入防御やファイアウォールの機能を使用することができます。
adv-ent

◆NSX for vShield Endpoint / Standard◆
NSX for vShield EndpointまたはStandardを選択する場合、Deep Security Virtual Appliance(DSVA)で提供される機能はウイルス対策のみです。そのため、各仮想マシンにDeep Security Agent (DSA)をインストールし、侵入防御やファイアウォールを使用します。この方法がコンバインモードです。
combined-mode
コンバインモードの詳細はこちらをご確認ください。
http://esupport.trendmicro.com/solution/ja-JP/1112549.aspx?print=true

◆まとめ◆
侵入防御やファイアウォールを使用したい場合、どのNSXエディションを選択するかがポイントですね。Advanced / Enterpriseを選択するなら、導入が容易に思えます。一方でライセンスコストとの費用対効果を考えることも必要です。Advanced / Enterpriseで提供される機能が自社の運用管理の効率の向上が見込めるのであれば、この機会に検討されるのもよいですね。

無償の「NSX for vShield Endpoint」を選択するなら、Deep Security Agent(DSA)を各VMに導入する必要があります。

現在、私個人が注目しているのは、運用面からの「ネットワークの仮想化」という選択です。

ここ数年、vRealize Operations Managerを介して、ユーザーの仮想基盤の運用管理のお悩みをうかがう機会が増えました。最近は、ストレージの運用の容易さから、Hyper-Converged Infrastructure (HCI)が台頭してきていますね。次はネットワークの仮想化の出番なのではないかと感じています。

今後のVMware Blogでは、運用面から見た「ネットワークの仮想化」の記事を投稿できたらと考えています。

次回は、VMware NSX for vShield Endpointへの移行検証サマリーを投稿します。

nakagawa

VMware NSX for vSphereへの移行

1回目:vCloud Networking and Security (vCNS)の販売終了

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
vCloud Networking and Security (vCNS)の販売が終了されていることをご存知ですか?
すでに一般サポートも2016 年 9 月 19 日に終了を迎えています。テクニカルガイダンスは2017年3月まで提供されます。
セキュリティベンダーが提供する仮想アプライアンスを使用して仮想基盤を保護されているユーザー様、または提案を予定しているパートナー様は、ご注意ください。
vCNSの販売および一般サポートの終了にともない、こちらのBlogでは3回にわたり、VMware NSX for vSphereへ移行のための情報を共有いたします。連携する仮想アプライアンスは、トレンドマイクロ社のDeep Securityを対象とします。

現在vCNS(旧vShield Manager) をご使用のユーザー様は、vShield Endpointを管理するために、今後はNSX Managerを使用することになります。
また、vShield  Managerを含むvShield Endpoint関連のコンポーネントは、すでにVMware社サイトからのダウンロードを終了しています。そのため、新規構築の際も、NSX for vSphereを使用することになります。
いずれも、NSX for vSphere 6.2.4 以降をダウンロードし、環境を構築する必要があります。
トレンドマイクロ社は、vCNS 5.5.x環境下のDeep Securityに関するサポートを継続します。ただしベストエフォート対応のサポートとなります。

終了については、次のKBをご確認ください。
<KB: 2145636 >
VMware vCloud Networking and Security 5.5.x の販売終了および一般サポートの終了

https://kb.vmware.com/kb/2145636

◆VMware NSX for vSphere 6.xのライセンスエディション◆

NSX for vSphereは、次の4つのエディションが提供されています。

  • NSX for vShield Endpoint
  • NSX Standard
  • NSX Advance
  • NSX Enterprise

「NSX for vShield Endpoint」は、VMware NSXバージョン6.2.4から追加された新しいライセンスです。

4つのエディションは、同じNSXモジュールを使用します。ライセンスキーを入力せずにインストールするとNSX for vShield Endpointとして機能します。残りの3つのエディションは各ライセンスをご購入されると利用できます。

◆vShield EndpointとNSXの構成の違い◆
vShield EndpointからNSXへ移行すると、どのようなコンポーネントが必要となるでしょうか。提案する際に何が必要かを知っておくことは大事なポイントとなりますね!

vshield-to-nsx

 

<変更のポイント>

  1. 管理マネージャーが、「vShield Manager」から「NSX Manager」に変わります。NSX Managerは、vShield Managerと同様に1システムに1つ準備します。
  2. 新たに、仮想アプライアンス「Guest Introspection」を、各ESXiホストに配置します。Guest Introspection がvShield Endpoint の全機能を提供します。

変更・追加対象の、「vShield Manager」と「Guest Introspection」は、「NSX for vShield Endpoint」を含む「VMware NSX for vSphere」すべてのエディションで提供されます。

◆各NSXエディションとDeep Securityの機能◆
ウイルス対策のみの場合は、NSX for vShield Endpoint (無償)で使用可能です。

matrix

◆まとめ◆

vCNSの販売の終了にともない、仮想基盤のセキュリティ強化に努めるユーザーや提案するパートナーに影響をもたらしていると思います。
仮想基盤の管理者にとっては悩ましいことですね。一般サポートも終了していますから、今後のことを考慮し、ぜひNSX for vSphereへのアップグレード準備を開始いただけたらと思います。
こちらのBlogの3回目では、無償版の「NSX for vShield Endpointへの移行」のサマリーをお伝えします。移行の詳細手順書を12月以降に提供する予定です。こちらは「VMware Japan」Facebookでお知らせします。
その前に新規インストール用の簡易手順書を共有します。こちらへアクセスください。

http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/NSX-NV-05-NSX_for_vShield_EndPoint_20161021a.pdf?elqTrackId=9bc23ac857cc422897d92420f93dc17b&elqaid=979&elqat=2

 

nakagawa