Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Yasunori Ohara

作成者別アーカイブ: Yasunori Ohara

vROps 6.7は初心者に優しい!#5

5回目:vSAN運用管理者にはvROpsは欠かせないツール

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。
5回目は「vSAN運用管理者にはvROpsは欠かせないツール」です。

vSAN監視のために、vROpsとの連携が強化されていますね。6.7からは「vCenter Server の vRealize Operations Managerプラグイン」が提供されています。
先日弊社教育サービスに、パートナー様から、「エンドユーザー様からのご依頼により、vROpsの知識を身につけたい」とお問い合わせがありました。
「vSANの運用監視のためにvROpsの活用方法をお知りになりたいのでしょうか」とお尋ねしたところ、「vSAN前提で、vROpsの設計から学習したい」というご要望でした。
vSANの運用監視をされるのはエンドユーザー様ですから、vSANの導入が増えるにしたがい、vROps連携の依頼も増えるのかもしれませんね。
vROps 7.0からはVMware Cloud on AWSと連携することも可能です。連携する対象が増え、この数年vROpsの啓もう活動をしてきた私には楽しい状況です(笑)。

vCenter ServerでもvSANの基本的なパフォーマンスメトリックを監視することはできます。vSANのパフォーマンスメトリックは他のメトリックとは異なり、vCenter Serverに保存されず、 vSANデータストアに存在するオブジェクトとして格納されます。データを表示できる時間は1時間から24時間、保持日数は90日間です。vROpsのデータ履歴の保持期間はデフォルト6か月です。

KB:How to configure Data Retention in vRealize Operations Manager 6.x and later (2147600)

加えて、vROpsはvCenter Serverにはないメトリックの提供、収集したデータのカスタマイズ表示が可能です。

先に、「vCenter Server の vRealize Operations Managerプラグイン」からご紹介します。

◆vCenter Server の vRealize Operations Managerプラグイン◆

vSphere Clientから、「VMware vROps Client Plugin」を確認できます。

ホームまたはメニューから、「vRealize Operations」を選択します。

プラグインを使用する場合は、この画面から「インストール」または「既存インスタンスの構成」を選択し、進めます。完了後、表示されるまで多少のタイムラグがあります。vSANはvCenter Serverより数分遅れて表示されます。

<vCenter ServerのvRealize Operations Manager プラグインのドキュメント>
詳細は次のドキュメントを参照ください。
https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vrops/GUID-57D6EFBD-3FD2-4EDC-A754-594F7AFE546E.html

 

画面右側の「クリック リンク(赤枠)」メニューから、vSANの画面に切り替えます。また「vRealize Operations(緑枠)」リンクをクリックすると、新規タブにvROpsのログイン画面が表示されます。

< vSANの概要 >

すべてのvSANクラスタを対象に、「最低限このメトリックのみ確認しておけばよいでしょう」というデータが表示されています。アラートの「詳細表示 (赤枠) 」をクリックすると、このプラグイン内のアラートリストの画面に遷移します。

< vSANのクラスタ ビュー >

「クラスタの変更 (赤枠)」から、各vSANクラスタのデータへ切り替え、1つのクラスタのメトリックを確認することができます。
1点気になるのが、「最終更新日(緑枠)」の時刻はJST (Japan Standard Time) ですが、各メトリックの時刻はUTC (Universal Time, Coordinated) で表示されているようです。黒いポップアップはグラフの一番右にマウスを合わせ表示しています。
下図では、最終更新日は12:40 PM、ポップアップの時刻は3:26です。9時間ほどの差があります。この時刻はHost Clientで確認するUTCの時刻とほぼ一致しています。
「vSANの概要」も合わせ、ここは注意点かもしれません。

< vSANの アラート >

vSANクラスタ内のアラートを表示します。

ここからは、vRealize Operationsです。

◆vRealize OperationsのvSANダッシュボード◆

vROps 6.7では事前に提供されるvSANに関するダッシュボードが4つあります。
ここでは、「vSAN運用概要」と「vSANへの移行」の2つのダッシュボードを取り上げます。

< vSAN運用概要 >

vSANのプラグインはvSANに特化したデータ表示ですが、vROpsは一画面でコンピュータリソースのデータも表示されます。CPUやメモリリソースも同時に確認できます。
ディスクデータの赤色の点線枠は現在の値です。現在値と履歴トレンド (傾向) がわかるのは便利です。
ディスクに関する値はTB (テラバイト) で表示されています (青色の点線枠) 。大容量のサイズを構成していない場合は、単位はGB (ギガバイト) の方が把握しやすいかもしれませんね。

ダッシュボードの「ウィジェットの編集 (鉛筆のアイコン) 」をクリックし、編集画面から表示する単位を変更することができます。カスタマイズにはAdvanced以上のエディションが必要です。

この環境のディスクサイズは少量のため、単位をGBに変更したことで管理しやすくなりました。事前に提供されるダッシュボードもカスタマイズするとより使いやすくなりますね。

< vSANへの移行 >

非vSAN (従来の) データストアまたはvSANデータストア内の仮想マシンのストレージメトリックを監視することができます。以前のバージョンの「vSANデプロイの最適化」ダッシュボードと比べてシンプルになりました。仮想マシンのディスクパフォーマンスを考慮しつつ、非vSANデータストアとvSANデータストアとの間で仮想マシンの移行の検討をすることができます。

◆ご紹介ドキュメント◆

このBlogを執筆するにあたり、参考にした英語のドキュメントを共有します。

◆まとめ◆

vROpsのバージョンが上がると、vSANとの連携が強化されますね。
vSANの運用管理は、Web Clinet、vSphere Client、Host Clientからもできますが、仮想基盤全体のメトリックの集約と分析にはvROpsの出番です。パフォーマンスはコンピュータリソースの視点も必要です。vROpsを使用して、コンピュータリソースが必要なのか、ディスク容量が必要なのかを把握できます。さらにvRealize Log Insightも準備すれば、重要なログインベントメッセージの検索が容易になります。トラブルシューティング時は安心ですね。先にご紹介したvSANのドキュメント内にLog Insightのデモがあります。ぜひご確認ください。
こちらでご紹介した内容が、みなさんのお役に立てたなら幸いです。

vROps 6.7は初心者に優しい!#4

4回目:6.7バージョンはメトリックの活用がポイント

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。
4回目は「6.7バージョンはメトリックの活用がポイント」です。
vROpsを使用したコンサルティングサービスの場で、「メトリック」をご紹介すると、物理基盤を監視していた方々に概ね好評でした。
収集データが時系列でシンプルに表示されると安心されるのでしょうか。メトリックのご紹介後、「このソフトウェア欲しい、いくら?」と笑顔で尋ねられたことがあります(笑)

本題に入る前に、2018年9月20日、vROps 7.0がLaunchされましたね。6.7が4月12日でしたから、半年余りで次のバージョンが出ました。

次は7.0の主な新機能です。AWS連携の機能が目を引きますね!

  • What if 分析の新機能 (キャパシティ(ホスト)追加が復活/クラウドへの移行プランニングが可能)
  • 新しいカスタムダッシュボード作成画面 (ドラッグ&ドロップで簡易性の強化)
  • AWS 3.0の管理パックの機能追加 (EC2以外のサービスも対象/デフォルトでダッシュボードの提供)

新機能については、あらためてご紹介できたらと思います。まずは6.7で基本を押さえて!

<vRealize Operations Manager 7.0 リリースノート>

https://docs.vmware.com/jp/vRealize-Operations-Manager/7.0/rn/vRealize-Operations-Manager-70.html

◆メトリックの画面◆

メトリックは、6.6バージョンから各オブジェクトのメインメニューに、「すべてのメトリック」と表示されるようになりました。下図は、#2でご紹介したアラートから遷移したメトリックの画面です。

警告のあるメトリックは、メトリック名の◆が黄色で表示されます。

◆メトリックの利点

関連するメトリックを並べて比較分析できるところがよい点です。

「仮想マシンのトラブルシューティング」ダッシュボードを例にしますが、仮想マシンのパフォーマンスを監視するために必要な4つのリソースのメトリックが並べて表示されています。

一目で何がボトルネックとなっているのかを確認することができます。

メトリックはデータが時系列で表示されますから、日時を参照しながら分析できますね。

たとえばワークロードの高い値だけを注目しても、正しい判断はできません。いつ高くなったかを確認するのもポイントです。vROpsを使用したアセスメントサービスの場で、高いワークロードの原因は仮想マシンのバックアップが要因ということがありました。時間帯も分析の必須要素ですね!

 

 

ここからはちょっとしたTipsをご紹介します。

 

◆メトリックの活用①◆

下図では、仮想マシンのCPUに関するメトリックとホストのCPU使用率のメトリックを表示しています。#1でお伝えしたように、ホストのCPU使用率と仮想マシンの使用率は比例していないことがわかります。関連する複数の要素(メトリック)を並べて表示することで、どこに(ESXiホストまたは仮想マシン)問題があるのかを特定できます。

◆メトリックの活用②◆

次の例も複数のメトリックを並べて表示し、ネットワークパフォーマンスの原因を分析します。

仮想CPUに物理CPUが割り当てられていない場合、仮想NICはパケットの受信処理を行うことができません。処理を行うことができず、受信パケットがドロップすることがあります。

ネットワークの受信ドロップパケット数を監視する場合は、同時にESXiホストや仮想マシンのCPU競合値も表示すれば、どこに原因があるのかを特定しやすくなります。

受信パケットをドロップしているESXiホストがあれば、仮想マシンのCPU競合値も調べ、どの仮想マシンが影響を受けているかを確認できます。仮想ネットワークアダプタがVMXNET3の場合は、リングバッファを大きく設定できるため、受信パケットのドロップを回避することができます。

◆メトリックの活用③◆

いくつか並べたメトリックを同時にズームしたい場合、「すべてのグラフのズーム(赤色枠)」をクリックします。1つのメトリックでズーム操作(ある日時をドラッグ)をすると、他のメトリックも同時にズームされ、日時を揃えることができます。この機能を知らない時、同じ日時でズームされるよう、各メトリックのドラッグ操作に苦戦してました。同じ日時に表示調整するのはテクニックを要します(笑)

元に戻したい場合は、右にある「ズームのリセット(緑色点線枠)」をクリックします。

◆メトリックの構成◆

「VMのトラブルシューティング」ダッシュボードを例に、メトリックの内容(XML構文)を確認します。「6.仮想マシンにデマンドの急増または異常があります」は、メトリック「Dash-VM-Troubleshooting-Utilization」から構成されています。

メトリック「Dash-VM-Troubleshooting-Utilization」のXML構文は、「管理」-「メトリック構成」で確認できます。CPUデマンドにしきい値(緑色点線)が設定されていますが、このダッシュボードでは使用されていないようです。

◆メトリックに関するドキュメント◆

各メトリックの説明は、次のドキュメントをご確認ください。

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/com.vmware.vcom.metrics.doc/GUID-C272EDE0-49E0-44D6-B47F-C32723AC9246.html

 

◆まとめ◆

メトリックは目新しいものではないのですが、アラートと連携されていたり、関連するメトリックと並べて比較分析できるのは便利ですね。

どのメトリックを選択するかで、表示されるデータに意味を持たせることができます。メトリックの組み合わせによって原因の特定を早めることもできますから、エンジニアの力量が発揮されますね。vROpsを操作する機会があれば、どんなメトリックがあるかを眺めてみてください。

次回はvSANと連携したvROpsを紹介します。最近弊社にvROpsコースについてVMwareパートナー様からお問い合わせがあります。vSANを検討されるエンドユーザー様からの依頼でvROpsのニーズがあるそうです。次回の内容もぜひ参考にしてください。

vROps 6.7は初心者に優しい!#3

3回目:仮想マシンのリストはカスタムビューで

 

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

 

日本ヒューレット・パッカード株式会社の中川明美です。

3回目は「仮想マシンのリストはカスタムビューで」です。

vROps 6.7のビューでは、「仮想マシンの診断リスト」が提供されていません。私は仮想マシンの診断リストを使用して、各仮想マシンのデマンドや競合を比較分析していたため、かなりの痛手です(笑)

提供されないなら、「ビューをカスタム作成しよう、みなさんにもカスタムビューの作成方法を共有しよう」と今回テーマに取り上げました。

 

カスタムビューを作成するには、Advanced / Enterpriseエディションが必要です。

リリースノートに、次の記述があります。

「vRealize Operations Standardエディションでは、ビュー、ダッシュボード、スーパー メトリック、およびレポートを作成または編集する機能は使用できません。」

vROpsを活用するには、Advanced以上のエディションが必要ということですね。

<vRealize Operations Manager 6.7 リリースノート>

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/rn/vRealize-Operations-Manager-67.html

仮想マシンの診断リストを作成する前に、「ホストのCPU診断リスト」の内容を確認します。「ホストの診断リスト」は6.7でも引き続き提供されています。

 

◆ホストのCPU診断リスト◆

メインメニュー「ダッシュボード」で「ビュー」を選択します。「ホストのCPU診断リスト」を選択し、「ビューの編集」アイコンをクリックします。

ビューの数が多いため、この画面では右上のフィルタ (赤点線枠) を使用しています。

 

下図は、「ビューの編集」画面です。

ビューのポイントは「データ」です。「データ」で表示したいメトリックを指定します。

 

表示される値は、「平均ですか」「最大値ですか」と算出方法を聞かれます。その場合は、編集画面で確認します。※ Standardエディションは編集画面を表示できません。

「変換」で算出方法のタイプを選択できます。また「詳細設定を表示」 (赤色点線枠) をクリックすると、「ロールアップ間隔」を選択できます。

「競合(%)」は、「CPU競合 (%) 」メトリックの5分間の最大値を表示していることがわかります。

 

「メトリック相関」は、指定した「相関メトリック」の変換タイプが最小値または最大値である時に、値を表示します。この画面では、競合 (CPU競合) に「最大値」が選択されているため(青色枠)、「デマンド」や「使用量」などのデータも表示されるよう設定されています。

 

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

仮想マシンの「仮想CPUの数」と「CPUのパフォーマンスに関するメトリック」、仮想マシンが配置されている「ESXiホストの名前」が表示されるビューを作成してみましょう。

「ホストのCPU診断リスト」のメトリックを参考に、仮想マシン用のCPU診断リスを作成します。

ビューの画面で、「ビューの作成」アイコンをクリックします。5つのStepを進めます。

 

「1. 名前と説明」ではビューの名前を、「2. プレゼンテーション」ではデータの見せ方(リストやトレンドなど)を指定します。下図ではプレゼンテーションで「リスト」を選択しています。

 

「3. サブジェクト」では、データ対象のオブジェクトを選択します。

ここでは、「vCenter Server アダプタ」内の「仮想マシン」を選択します。

 

「4. データ」では、表示するプロパティやメトリックを選択します。

対象を「プロパティ」に変更し、「サマリ-親ホスト」「構成-ハードウェア-仮想CPU数」を右側のウィンドウにドラッグします。

 

対象を「メトリック」に変更し、パフォーマンスに関するメトリックを追加します。「デマンド」「使用率」は、単位を「自動」から「GHz」に変更しています。

 

「5. 可視性」では、作成したビューを、「ダッシュボード」「レポート」「詳細タブ」で使用するのかしないのかを指定します。

 

◆詳細タブで確認◆

作成したビューは、環境の詳細タブで確認します。

変更したい場合は、「ビューの編集」アイコンをクリックします。確認しながら変更できるため、作成後はこの画面で作業するのが便利です。

私も確認後、検索を容易にするためビューの名前変更、プロパティの「仮想CPU数」からメトリックの「プロビジョニングvCPU数 (vCPU) 」へ変更、「キャパシティ合計」を追加しました。

ビューのクローン、エクスポート、インポートもこの画面から行うことができます。

 

ビューの編集画面の「時間設定」で、データ表示期間を変更することができます。デフォルトは直近7日間です。この画面で変更せず、詳細タブのビュー画面でカレンダーのアイコン (上図の緑色枠) で都度変更することもできます。

 

ビュー作成時の詳細な説明は、こちらのドキュメントをご確認ください。

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/com.vmware.vcom.config.doc/GUID-BC800026-25B4-4EDD-AE6F-E4A82BDE88C0.html

 

◆まとめ◆

vROps 6.7になり、仮想マシンの診断リストを見つけられなかった時は、困ったなぁと思いましたが、必要なメトリックを考えながらの作成は楽しかったです。

vROpsの操作を始めた数年前は、カスタム作成はハードルが高いのではと思っていたのですが、やってみると簡単でした。提供されているビューを参考にしてもよいですしね。

ビューは、ダッシュボードやレポートの元になるオブジェクトでもありますから、vROpsを超活用するためには必要な知識です。ぜひトライしてみてください!

 

 

 

 

vROps 6.7は初心者に優しい!#2

2回目:アラートからブレイクダウン

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。
2回目は「アラートからブレイクダウン」です。vROpsを使用してアセスメントをする時、私はアラートの確認から始めます。アラートの確認は現在の問題を把握するために最適なアプローチだからです。一般的にも問題が起きているオブジェクトを特定する場合、最初に行うステップはアラートの確認ですもんね。

アラートの説明の前に、ユーザーガイドのご紹介を!
VMware社が提供するドキュメント「vRealize Operations Manager ユーザー ガイド」では、次の3つのシチュエーションにしたがい、問題解決までのアプローチを提示しています。
• 問題が発生したユーザーから問い合わせがあった場合
• 受信箱にアラートが到着した場合
• オブジェクトの状態を監視しているときに問題を発見

◆vRealize Operations Manager ユーザー ガイド◆
https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/vrealize-operations-manager-67-user-guide.pdf
下図は、ユーザーガイドの目次です。先にご紹介した3つのシナリオにアラートの項目が続きます。ガイドの構成も、アラートから始め、次にパフォーマンスやキャパシティの状態を確認する手順になっています。私もこのプロセスでアセスメントを行っています。
こちらのユーザーガイドはとても参考になるのですが、文字だけの73ページのボリュームは文章を読みなれていない人には、ハードルが高いかもしれませんね。。。

 

では、vROpsのアラートの活用方法をご紹介します。

 

◆vSphere基盤全体の現状把握◆

vSphere基盤全体の現状を把握するために、vROpsのメインメニューのアラートを選択します。この画面で「すべてのアラート」を確認します。

下の画面ショットでは、2つの仮想マシンで同じ内容のアラートが表示されています。

この段階では、仮想マシンに何らかの問題が発生していることを認識します。

 

◆対象オブジェクトの現状把握◆

対象オブジェクトのアラートの詳細を確認するために、リンク文字列(青色表示)をクリックすると、下の画面が表示されます。

この画面から、4つの情報を得ることができます。

赤枠:アラートの原因

上の画面ショットでは電源管理の設定がなされていないことが原因として挙げられ、それによってパフォーマンスに影響を与えているのではと推測します。

電源管理のアラートはvROps 6.6から表示されるようになりました。それより前のバージョンでは、非常に高いCPU Ready値またはオーバーヘッドから電源管理が原因なのでは?と分析していました。

 

青枠:現状を解消するための推奨アクション

「推奨」には、現状を解消するための具体的な操作方法が表示されます。

他の推奨がある場合は、「>その他の推奨事項」の「>」をクリックすると、表示されます。

上の画面ショットでは、BIOSとESXiホストで電源管理の設定方法を紹介しています。

BIOSの設定は、各サーバーベンダーに問い合わせることをお勧めします。この画面では、「OS Controlled」がありますが、ベンダーによってメニュー名は異なります。

BIOS設定の詳細については、VMware社の以下Knowledge Baseも参考になるかと思いますので是非ご参照下さい。
Virtual machine application runs slower than expected in ESXi

 

緑枠:詳細情報の表示

いつからパフォーマンスに影響がある状況になったのか、どのメトリックの値が原因なのかを知りたい場合に、次の3つのリンクをクリックします。「ログの表示」は、vRealize Log insightと連携すると表示されます。このBlogでは、「追加メトリックの表示」と「イベントの表示」を取り上げます。

  • 追加メトリックの表示
  • ログの表示
  • イベントの表示

 

追加メトリックの表示

「追加メトリックの表示」をクリックすると、対象オブジェクトのメットリック画面に遷移します。

パフォーマンス低下の原因となるメトリックの左側の◆が黄色で表示されます。

次に、メトリックをダブルクリックすると、右側のウィンドウにグラフが表示されます。このグラフから値の変遷を確認することができます。

メトリックの詳細については、4回目で説明します。

イベントの表示

アラートで表示されているイベントが、いつ警告(またはアラート)レベルに至ったかを時系列で確認することができます。下図にあるように、赤い▲にマウスカーソルを合わせるとイベントの詳細が表示されます。この画面ショットでは、グレーの▲時点でCPUに高負荷がかかり、10分以内に警告レベルに至っていることがわかります。

 

黒枠:シンプトン

シンプトンは「事象」と訳されます。vSphere仮想基盤で発生した、クリティカル (またはその兆候) な事象を確認することができます。

下の画面ショットで表示されているシンプトンは、「電源管理テクノロジーがOS Controlledに設定されていません」という事象です。このシンプトンには、「CPU競合」のメトリックとそのメトリックに指定された条件 (しきい値) が設定されています。競合値が30%以上の場合、クリティカルレベルのアラートが発生されます。

アラートは、問題の発生を知らせ
るだけでなく、「シンプトン」と「推奨アクション」を関連付けて構成 (作成) することもできます。

 

メインメニューのアラートはすべてのオブジェクトを対象とします。任意のオブジェクトの詳細な状況を確認する場合は、各オブジェクトを選択します。各オブジェクトのアラート機能をご紹介します。

 

◆任意オブジェクトのサマリ◆

環境メニューから、任意のオブジェクトを選択し、「サマリ」を確認します。

サマリでは、「健全性」「リスク」「効率」のステータスとアラートが表示されます。バッジ (赤い点線枠) で表示を切り替えます。

右下のパフォーマンス (青い点線枠) ではパフォーマンスに関わる主要なメトリックが表示されます。下の画面ショットでは、電源管理の設定により、競合値が高く、100%を超えるデマンド値になっています。物理CPUが割り当てられず、CPUリソースの要求が高くなっていますね。

 

◆任意のオブジェクトのアラート◆

アラートのシンプトンでは、リスト形式でクリティカルな事象を時系列で確認できます。

下の画面ショットでは、パフォーマンスに影響があるシンプトンが表示されています。

 

◆まとめ◆

今回はアラートを取り上げました。このBlogを書くにあたり、アラート画面をじっくり確認した結果、この画面だけで1時間は話せるなという情報量です (笑) 。

vSphere仮想基盤の運用担当者になったばかりという方は、アラート画面の情報量だけで原因を特定するための工数を短縮できるのではないかと思います。アラートによっては推奨アクションも表示されますしね。

vROpsは情報量が多いのが、よいところでもあり、初心者のハードルを上げてしまうところでもあります。しかし、理解度 (習熟度) レベルに合わせて使用するダッシュボード (ユーザーインターフェース) を使い分けると活用の幅が広がります。コンサルティングの場で、ユーザーの方に安心いただくために、順番に覚えればいいのですよとお伝えしています。

次回は少々レベルを上げて、カスタムビューの作成方法をご紹介します。

VMware NSX for vSphereへの移行

4回目:VMware NSX for vShield Endpointへの移行検証サマリー (パート2)

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

こんにちは、ソフトバンク コマース&サービスの中川明美です。
12月に投稿しました3回目ではvSphere 6.0環境下での移行方法をご紹介しました。
今回は、vSphere 5.5環境下での「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。vSphere 5.5からの移行を計画されている方はぜひご参考にしてください!
このBlogでは簡易手順を共有します。詳細手順をお知りになりたい方は、ページ下部でご紹介するURLからご入手ください。

◆構成図◆
下図は、Upgrade前の構成図と、Upgrade後の構成図です。
Upgrade前はvSphere 5.5 U1環境下でvShield Endpoint(vCNS)を使用、Upgrade後はvSphere 6.0 U2環境下でNSX for vShield Endpointへ移行します。
<Upgrade前>

before

<Upgrade後>

after

◆アップグレード手順◆
次の16ステップを進めます。

1.DSVA(Deep Security Virtual Appliance)の無効化/停止/削除

1

2

3

2.各ESXiホストから Filter Driverを削除

4

3.vShield Managerの停止

5

4.Deep Security ManagerとvCNS / vCenterサーバーの連携解除

6

5. vCenterサーバー / ESXiホスト のアップグレード

7


8

6.Horizon Viewのアップグレード

9

7. Deep Security ManagerのDBスキーマのアップグレード

10

8. Deep Security Manager のアップグレード

11

9. NSX Managerのデプロイ

12

10.Deep Security ManagerとNSXの連携設定

13

11.Guest Introspectionのデプロイ ※詳細手順では、仮想標準スイッチ使用時の注意点を追記

14

12.DSVA(Deep Security Virtual Appliance)のデプロイ ※詳細手順では、既知の問題について追記

15

13.Security Policy / Security Groupの作成等

16

17

14.対象VMを順次有効化

18

15. 新規VMの自動有効化設定

19

16.vShield Managerを削除 手順3で停止した、「vShield Manager」仮想マシンを削除
※画面ショットは手順3の画面

20

◆アップグレードの詳細手順◆
詳細手順をダウンロードできます。
https://app.box.com/s/5n62ebuw8c30yg5vzwki22g4qblwdp17

◆トラブルシューティングガイド◆
Deep Security + NSXのトラブルシューティングガイドをダウンロードできます。http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/DSVA_9.5-6TroubleshootingTips_NSX.pdf?elqTrackId=9bc23ac857cc422897d92420f93dc17b&elqaid=979&elqat=2

◆まとめ◆
今回のBlogでは、vSphere 5.5環境でのアップグレード手順を共有いたしました。
今回のアップグレードは仮想基盤も含まれているため、事前にどのような手順で進めるのかを知ることは有益ですよね。詳細手順ではアップグレード中に認識できた注意点についても付記しています。こちらの手順をガイドに、工数の見積り、トラブルのない導入に活用いただけましたら幸いです。

nakagawa

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
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、仮想スイッチの歴史とロードバランスの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
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、あらためて「仮想スイッチ」について取りあげます!!
私は、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