Home > Blogs > Japan Cloud Infrastructure Blog

VMware Cloud on AWS 環境も Trend Micro Deep Security で守ることができるんです!

トレンドマイクロ VMware テクニカルアライアンス担当 栃沢です。

2018年11月に VMware Cloud on AWS が東京リージョンでリリースをされました。
VMware Cloud on AWS のリリースにより、従来オンプレミス環境で vSphere を採用していたユーザはよりパブリッククラウドとの連携を生かした運用を実現する道が開けてきたと思います。
パブリッククラウドの活用にあたってもセキュリティ要素の検討は必ず必要となり、従来のセキュリティ対策との兼ね合いも気になるところでしょう。

トレンドマイクロはすでに VMware Cloud on AWS のユーザとして、当社のサーバセキュリティ製品である Deep Security での連携などをすでに進めています。
今回は VMware Cloud on AWS 環境に対して Deep Security がどのような連携が可能になっているかをご紹介します。
今回ご紹介するこのブログの内容は、トレンドマイクロの VMware マイクロサイトにも転載されています。

 

マルチクラウド環境に対する Deep Security の位置づけ

Deep Security は統合サーバセキュリティ製品として多くのお客様にご利用をいただいていますが、物理、仮想化環境だけではなくパブリッククラウド、コンテナサービス、サーバレスも含めたマルチクラウド環境への対応を日々目指して開発を継続しています。

 

そして、Deep Security はシングルコンソールでオンプレミス環境とクラウド環境を一元管理できる仕組みを提供しています。
これによりインフラ環境を問わずにセキュリティレベルを統一していくことが容易となると同時に仮想マシン、インスタンスの新規デプロイ、移行にもシームレスに対応することが可能です。

 

VMware Cloud on AWS 環境における Deep Security の連携

VMware Cloud on AWS 環境においても Deep Security を連携することが可能になっています。Deep Security Manager(以下DSM)が vCenter Server と連携する仕組みを利用することによってオンプレミスの vCenter ServerVMware Cloud on AWS の vCenter サービスと連携をしてインスタンス情報をリアルタイムに同期します。また、現時点(2018年12月時点)では、VMware Cloud on AWS 上で利用できる保護モジュールは Deep Security Agent(以下DSA)のみとなります。

 

実際にどのような手順で連携をすればよいかを順を追って解説します。

VMware Cloud on AWS vCenter への接続準備

  1. VMware Cloud on AWS コンソール画面から展開する SDDC を選択して、“OPEN VCENTER” をクリック
  2. vCenter へのアクセスを許可するための Management Gateway に対するインターネット経由での Firewall アクセスルール、または、オンプレミス環境からの VPN アクセス(vCenter への HTTPS(TCP443)を許可)が設定されていれば連携可能
    DSMとvCenter の連携についてもこのポートを利用します。(DSM から vCenter へ HTTPS セッションを利用してリアルタイムに情報連携)○Firewall ルール例

VMware Cloud on AWS vCenter と DSM の連携設定

  1. DSM にアクセスして、[コンピュータ]画面から ”VMware vCenterの追加” を選択
    オンプレミスの vCenter Server との接続設定と同様の設定を行います。
  2. vCenter の Administrator 権限を持つアカウントでアクセス設定
    vCenter とのアクセス情報を入力して “次へ” に進むと vCenter へのテストアクセスが実行されます。アクセスができない場合にはエラーとなり、次の設定画面に進めません。
    NSX Manager の設定画面はスキップして “次へ” に進みます。
  3. vCenter からデータセンター配下のホスト、仮想マシン情報が取得されていることを確認して “完了” をクリック
  4. オンプレミスの vCenter とともに VMware Cloud on AWS のリソース情報が一元管理できていることを確認。

 

 

このように Deep Security を利用することによって、オンプレミスも VMware Cloud on AWS の双方の仮想マシンを統合管理し、同一のセキュリティポリシーを適用することが可能になります。
(そのほかにも AWS マネジメントコンソール、Azure ポータルと連携することも可能です。)
マルチクラウド環境への移行が進むにつれて、仮想マシンがどういった環境にあるかに問わず、統一したセキュリティを担保するためには、セキュリティツールがインフラ環境にリアルタイムに連携できることが大前提となります。
そしてリアルタイムに連携できることで、仮想マシンの増減に対しても Deep Security 側で登録を行わなくてもシームレスにセキュリティの適用が可能となり、セキュリティの適用を忘れてしまう、ということも避けられます。
ぜひ、皆さんの環境でもオンプレミスの vCenter、VMware Cloud on AWS の vCenter と Deep Security を連携してみてください。きっと有効性を体感していただけると思います。

 

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~電力消費量計算編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

◆はじめに

はじめまして! 田中電機工業株式会社 中野 (左) と 村上 (右) です。

田中電機工業は広島でシステム・ネットワーク構築、アプリケーション開発をはじめ、コンサルティングから設計、構築、運用、保守まで、システム全般のサポートを行っております。

http://www.tanaka-elec.co.jp

 

前回のシュナイダーエレクトリック 出口さんの続きとして、VMware vSANとシュナイダー UPSを自社の本番環境に導入した実績を基に、「構成と製品選定のコツ」、「バッテリー稼働時の耐久時間」「シャットダウン時の動き」をご紹介していきます。

 

1.構成と製品選定のコツ

2018年10月現在で、我々の会社では3ノードの vSAN 上で約50台のVMが稼働しています。

 

👉 vSAN を構成しているハードウェアはこちら

👉 vSAN と UPS の構成図

vSAN と UPS の物理接続構成はこの様になっています。

もし導入構成で迷われている方がいましたら、ぜひ参考にしてください!!

 

では具体的にUPS製品の選び方を見ていきましょう!

 

シュナイダー社が提供している UPS 製品のラインナップは以下の様に豊富に提供されていますが、HCI 環境で使う場合には赤字でマークしてある製品を検討いただくことが多くなるかと思います。 (2018年1月現在のラインナップ)

 

お気づきの方もいるかも知れませんが、製品名に書かれている「2200」「3000」という数字は UPS の保持電力量になります。

vSAN 環境で UPS を使う場合は複数のノードの扱うことになりますので、上の表でマークしたような、ある程度の電源容量がある型番が選ばれることが多くなりそうですね。

 

 

2.電源容量とUPS稼働時間の計算方法

では、いよいよ UPS を選んでいくにあたって 皆様が気にされていると思われる電源容量と稼働時間の算出方法を見ていきたいと思います。

稼働時間を算出するには、以下のポイントを確認いただければ簡単に算出していくことが可能です。

  • UPS の電源容量

    👉こちらは先程お見せしたリストのように、UPS型番をみれば電源容量は一目瞭然ですね (^^♪

  • 接続するサーバーの合計消費電力

    👉 弊社で導入したvSAN基盤は Lenovo 社のサーバーを使っていますので、こちらのサイトから詳細に電力を算出しました。
    http://dcsc.lenovo.com/


最大電力消費量は3ノードで1983.6 W。

運用中の負荷が70%  程度の使用率と考えた場合の消費量は以下になります。

「皮相電力」 ・・・ 2009.7 VA × 70% = 1406.79 VA
「消費電力」 ・・・ 1983.6 W × 70% = 1388.52 W

 

2台冗長構成で実装しており、3台の電源消費量を2台で分散して処理しますので、UPS 1台あたりの消費量は以下のとおりです。

「皮相電力」 ・・・  1406.79 VA ÷ 2 = 703.395 VA
「消費電力」 ・・・  1388.52 W ÷ 2 = 694.26 W

使っている UPS 型番と機器の消費電力が算出できたら、シュナイダー社の以下ドキュメントに記載されている各 UPS 毎のバックアップ時間表を確認することで、簡単に計算をすることができます。
http://catalog.clubapc.jp/pdf/ups/small-ups_1510.pdf

※P23 を参照。以下に抜粋

今回の使用している UPS は一番右の SMT3000RMJ2 です。

先程算出した皮相電力と消費電力が当てはまる部分を赤枠で囲ってみました。

ということで、今回の構成ではバッテリー稼働時に20分間は問題なく稼働できるということが確認できました。

 

 

3.UPS稼働時のシャットダウン動作と電源復旧時の起動方法

最後に望まないことではありますが、もし実際に電源障害が発生してしまい、UPSで vSAN を安全にシャットダウンしなければならない状況が発生した場合に、「どのような流れでシャットダウンが行われているか?」と「電源復旧時のシステム起動方法」を実際に運用した際の勘所を交えてお伝えします。

 

[シャットダウンフローはこちら]

 

[電源を復旧させる場合のフロー]

・vSAN ノードと vCenter Server が異なるホスト上にある場合

今回はこちらの流れになります。

1.UPSの通電を開始
2.vCenter Server の起動
3.ESXiホストの起動
4.ESXi ホストのメンテナンスモードを終了
5.各仮想マシンを起動

※2番でESXiホストよりも先にvCenter Server を起動していますが、Virtual Appliance 版のvCenter ServerをvSANノード上に配置している場合は、次にご紹介するフローで起動可能です。

 

・vSANノード上にvCenter Serverが配置してある場合

1.UPSの通電を開始
2.ESXi ホストの起動
3.ESXi ホストのメンテナンスモードを終了
4.vCenter Server の起動
5.各仮想マシンを起動

vSANの機能はESXiホストが実装している機能なので、vCenter Serverが起動していなくても
vSANデータストアは使用できるのです  ε-(´∀`*)ホッ

 

最後に実装と運用する際の勘所をサマリにまとめました。

・vSAN をメンテナンスモードに移行していく際に、一度に全てのホストがメンテナンスモードには移行するのではなく、1台ずつ順番にメンテナンスモードに移行します。

・PowerChute Network Shutdownでコマンド実行を行う場合、サービスを起動するユーザで実行します。うまくいかない場合は、管理者権限のあるユーザに変更する必要があります。

・ホストをメンテナンスモードに移行させるためにSSH接続を使用しますが、初回にセキュリティ警告が表示されますので、unknown_hostsリストに該当のESXiホストサーバを追加する必要があります。

実装するスクリプトや、詳細な情報については以下のURLが参考になりましたのでご覧ください。

 

https://www.schneider-electric.co.jp/ja/faqs/FA329212/

 

 

4.さいごに

 

いかがでしたでしょうか?

HCI を導入する際に vSAN を採用すれば、今まで vSphere で蓄えた知識を基に、簡単にUPSを導入できることがイメージしていただけたのではないかと思います。

弊社では検証環境用に 2 ノード vSAN も導入しています。
社内で身につけた 2 ノード vSAN 構築、運用、3rd パーティ製品連携の勘所なども、いずれご紹介したいと思いますのでご期待ください!!

PS : 広島へお越しの際は、お土産に平安堂梅坪にも寄ってみてください。
特にバターケーキが村上のオススメです。

 

平安堂梅坪

※株式会社平安堂梅坪は、田中電機工業の子会社になりました。

仮想基盤のパフォーマンスは使用率だけでは図れない

1回目:仮想基盤のパフォーマンスは使用率だけでは図れない

– Back Number –

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

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

VMware vRealize Operations Manager 6.7が2018年4月にリリースされましたね。

6.7を操作した感想は、「仮想基盤の運用管理に必要なメトリック (カウンタ) にフォーカスしている!」です。フォーカスされていると、覚えるべき項目が少なくなり、初めて仮想基盤の運用に携わる方は助かりますね。

6.7バージョンの一番の変更点は、「分析」タブがなくなったことです。分析タブがなくなったのは残念ですが、初心者に優しいダッシュボードが準備されています。

#1:仮想基盤のパフォーマンスは使用率だけでは図れない

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

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

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

ここ数年vROpsに関わるお仕事で、現在も物理マシンと同様の手法で仮想マシンを監視されていらっしゃる方をお見受けします。よくあるのは「使用率」のみを監視する方法です。

仮想基盤は、「キャパシティ」と「パフォーマンス」の2つの視点で監視する必要があります。「使用率」に加え、仮想基盤特有のメトリックと合わせて監視するのがポイントです。

数バージョン前からVMware vRealize Operations Manager (以降はvROps) のワークロードには、CPUは「デマンド」、メモリは「消費 (実際に使用された物理メモリ量) 」を分析結果に表示しています。これらのメトリックを調査するのは仮想マシンのパフォーマンスを最適化する前提となります。標準で提供されるVMのトラブルシューティングダッシュボードでは、使用率と仮想基盤に特化するメトリックが並べて表示されています。

 

仮想基盤において、なぜ使用率のみでは正しい判断ができないのでしょうか。コンピュータリソースのCPUとメモリを例に検証します。

 

◆ワークロード◆

下図は、vROps 6.6まで提供されていた、「分析」タブの「ワークロード」画面です。

この画面はデータセンターを選択しています。ESXiホスト2台分で、CPUのキャパシティは16.76GHz、メモリは32GBです。

<CPU>

ESXiホストの使用率は23.2%です。物理マシンの使用率を監視するならば、問題なしと判断されます。しかしこの画面から2台の仮想マシンのワークロードが高い状態であることがわかります。この画面だけでは根本原因はわかりませんが、ホストの「デマンド」が「使用量」より高い状態であることが1つのヒントになります。

参考までに、この画面でオーバーヘッドが高いのは、CPUの省電力機能が原因です。

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

 

<メモリ>

ESXiホストの使用率は82.48%です。物理マシンの使用率を監視するならば、高い使用率から問題ありと判断されるのではないでしょうか。しかし仮想マシンのワークロードは高くありません。この結果から、仮想マシンからのデマンド(要求)により、物理マシンの多くの物理メモリが消費されていることがわかります。

ESXiホストの使用率は90%を超えないように監視するのがポイントです。

仮想マシンからの要求により割り当てられた物理メモリの回収の発生タイミングは、次のBlogにまとめられています。

https://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html

ESXiホストに96GBの物理メモリが搭載されていた場合、バルーニングが発生するタイミングは残りメモリが10244.26MBになった時です。このスライディングスケールというアーキテクチャを知ると、90%を超えないように監視するというのも納得できますね。

そして物理マシンの高いメモリ使用率が単純に仮想マシンのパフォーマンスに影響を与えるわけではないこともわかると思います。

 

CPUの高いワークロードの原因を特定しましょう。

◆仮想マシンのCPU診断リスト◆

下図は、vROps 6.6まで提供されていた、「仮想マシンのCPU診断リスト」ビューの画面です。

高いワークロードの原因は、高い競合値です。仮想CPUに物理CPUが割り当てられず、待ちが発生すると、高い競合値となります。

さらにこのBlogのテーマである使用率を確認します。VM-2を例にします。

VM-2のCPUキャパシティは約2.8MHzです。使用量を確認すると、約1.4MHzですから、使用率は50%です。低い使用量は物理CPUが割り当てられないためと考えられます。

 

上記から、物理マシンや仮想マシンの使用率のみでは、仮想基盤のパフォーマンスを分析するための判断材料が不足していることはおわかりになるかと思います。

次にデマンドの値も確認しましょう。競合値が特に高い、2つの仮想マシンでは、「キャパシティ」よりも「デマンド」の方が高い値が表示されています。これも物理CPUが割り当てられないために、リソース要求 (デマンド) が高くなっているためです。

 

 

◆「VMのトラブルシューティング」ダッシュボード◆

vROps 6.7では、「VMのトラブルシューティング」ダッシュボードが標準で提供されています。

このダッシュボードの内容から、「慣れるまではこのダッシュボートを活用すれば問題ないよ」というメッセージを感じます。私が個人的にお勧めする初心者に優しいダッシュボートです。

左側のリストから仮想マシンを選択すると、仮想マシンの構成情報、アラート、ワークロード、稼働ホスト、格納先データストア、VMware Toolsのバージョンを一覧表示できます。

ダッシュボードをスクロールすると、左側に各リソースの使用量 (CPUはデマンド/メモリはワークロード/ディスクはIOPS総数/ネットワークは使用率)、右側にパフォーマンスに影響を与えるメトリックが表示されています。そのメトリックには、CPUとメモリは競合、ディスクは遅延、ネットワークはドロップパケット数が選択されています。

 

複数の画面を遷移せずとも、このダッシュボードから、パフォーマンスに影響を与える原因と対応方法のおおよその検討をつけることができます。

CPUを例にします。CPUのデマンドが高くかつ競合が高いのであれば、パフォーマンスに問題があると判断し、他のESXiホストへの移行を検討します。CPUのデマンドが高くかつ競合が低いのであれば、キャパシティに問題があると判断し、その仮想マシンの仮想CPUの追加を検討します。

 

◆「運用概要」ダッシュボード◆

「運用概要」ダッシュボードで表示される上位15でも、「使用率」ではなく、「CPU競合」「メモリ競合」「ディスク遅延」が選択されています。このダッシュボードも標準で提供されています。

なぜ使用率 (使用量) が選択されていないのかはもうおわかりですよね!

競合の詳細な原因や、ディスク遅延およびネットワークのドロップの発生原因は、「ビュー」または「メトリック」を使用して分析します。こちらについては、以降の回でご紹介します。

 

 

◆まとめ◆

仮想基盤のパフォーマンスに影響を与えるメトリックには仮想基盤特有のメトリックがあるにも関わらず、物理基盤と同様の方法で監視されている方がいらっしゃるのが気になっていました。それをご存じないために、物理基盤と同様の方法で監視されるのではないかと推測します。vROpsで仮想基盤に特化したメトリックが表示されていても、活用するには少々ハードルが高いというお話も私の耳には入っていました。

「VMのトラブルシューティング」ダッシュボードを見た時に、「そうそう、このメトリックが必要なの!」とうれしく思いました。仮想基盤の運用に慣れていない方も、VMのトラブルシューティングダッシュボードを活用すれば、一時切り分けが可能です。

vROps 6.7から、初心者が活用することを意識した構成になっていると個人的に感じています。知識習熟度レベルによって、使い分けられたら費用対効果もあります。

次回は、アラート対象のオブジェクトの原因を探る方法をご紹介します。

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(10) 

エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

トレンドマイクロ VMwareテクニカルアライアンス担当 栃沢です。

Windows 10環境への移行が進む中でWindows 10 Creators Updateへの対応についてご質問を頂くことが多くなってきております。
仮想デスクトップ環境では、Creators Updateがリリースされた場合にVMware vSphereVMware NSXVMware Horizon、VMware Toolsを確認する必要があります。そして、エージェントレス型セキュリティ対策ではさらにDeep Security Virtual Appliance(DSVA)との互換性を意識していく必要があります。今回は各ソリューションが互換性の面でどのような関係性があり、どのようなポイントを確認していけばよいか、順を追って解説したいと思います。

 

仮想マシンOSがVMware仮想環境で利用できるか確認するポイント

仮想マシンにはポップアップツールであるNotifierを除いてセキュリティ機能を提供するDeep Securityのコンポーネントは導入されません。DSVAによるエージェントレス型セキュリティを提供するためには、仮想マシン側にVMware Tools のVMCIドライバに含まれるNSXファイル自己検証ドライバ(vsepflt)を導入しておく必要があり、NSXファイル自己検証ドライバがフックする情報を基に不正プログラム対策などの機能を提供しています。
詳細は第5回ブログをご覧ください。

VMwareの仮想環境上でどのWindows OSが利用できるかを確認するためには、VMware Tools とOSの互換性をチェックする必要があります。
確認のポイントは以下の2つです。

1) 仮想マシンに導入するOSがVMware Toolsに対応しているかを確認する
 VMware Compatibility Guide にて確認することができます。

2) VMware Toolsが利用を予定している vSphere / NSX に対応しているかを確認する
 VMware Product Interoperability Matrices にて確認することができます。

ここでのポイントは、該当するWindows OSがサポートするVMware Toolsを確認し、VMware Toolsが利用可能なvSphereNSXの組み合わせを把握する、という点です。この組み合わせ(=互換性)が満たされていないとVMwareのサポートを受けられなくなる可能性がありますので、必ずチェックをしましょう。

 

エージェントレス型セキュリティ提供可否を確認するためのDSVA互換性チェック

導入する仮想環境のバージョンが確認できたら、その環境でDSVAが利用可能かを確認します。
DSVAの互換性は、vSphere及びNSXのバージョンに依存します。VMware Toolsとは直接の互換性を持っていません。また、仮想デスクトップ環境において利用されるHorizonとも依存関係はないので意識する必要はありません(もう少し踏み込むとvCenter Server、NSX ManagerがDeep Security Managerと連携できれば、仮想デスクトップ展開ソフトウェアは意識しない)。
以下のサイトにてDSVAがvSphere及びNSXのどのバージョンと互換性があることをDeep Securityのバージョン毎に確認することができます。

Deep Security and VMware compatibility matrix

 

DSVA利用時のWindows 10 Creators Update の対応について

ここまでの解説を見てお分かりいただけたかと思いますが、DSVA環境における利用可能なOSは直接的にはVMware Toolsのバージョンに依存します。VMware Toolsについては、仮想マシンのOS種別単位で対応が定義されており、Windows 10のCreators Update(RS3、RS4など)のサービスオプションごとの互換性を意識する必要はありません。 対応OSについては、VMware Toolsのリリースノートを参照してください。

 

[参考情報]VMware HorizonのWindows10のサポート

DSVAとの互換性とは直接関係ありませんが、Horizonによる仮想デスクトップ環境の導入の際にはOSがどのようにサポートしているかを確認する必要があり、よくご質問をいただきますので、その情報もここでご案内しておきたいと思います。

以下のKBにはHorizonのWindows 10のサポートバージョンが記載されていますが、あくまでHorizonの互換性であり、VMware Toolsの対応バージョンは考慮されていませんので上記の互換性の確認を行って対応OSの確認をする必要があります。
https://kb.vmware.com/s/article/2149393

また、Horizon環境のサポートポリシーとして、Windows10サービスオプションが「対象(Targeted)」となっているバージョンについてはTech Preview Supportということで上記KBでもサポートされないステータスとして管理されています。
Microsoftが公開しているWindowsのリリース情報も適宜確認するようにしましょう。
https://www.microsoft.com/ja-jp/itpro/windows-10/release-information

 

まとめ

仮想マシンのOSの利用できる環境を確認する方法についてご理解いただけたでしょうか?
簡単な互換性の関係をまとめると以下のようになります。

Windows 10を例にここではお話してきましたが、レガシーOS(Windows Server 2003など)の対応も同様に確認することができます。
ただし、VMware、トレンドマイクロそれぞれでレガシーサポートの対応について定義しておりますので、必ずサポートの可否、対応条件および制限事項について事前に確認するようにしましょう。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

    1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
    2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは?
    3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
    4. VMware NSXとDeep Securityのユースケースと実現できることとは?
    5. エージェントレス型ウイルス対策のアーキテクチャ(1)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェントレス型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

仮想スイッチのお作法~Network I/O Control#6~

6回目:仮想スイッチのお作法#6    (Network I/O Control#6)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

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

6回目は、分散スイッチが提供する「vSphere Network I/O Control バージョン3」についてご紹介します。「Network I/O Control」は、複数の種類のトラフィックが共通のリソースを使用する場合に、競合する問題を解決します。

サーバーの最新モデルによっては、10Gbpsの物理NICを16個まで搭載することができるようになりました。16個もあれば、10Gbpsの物理NICを必要なトラフィックで占有できそうですね。参考までに、vSphere 6.5の10Gbps物理NICの最大構成数は、Intel製は16個、QLogic製またはEmulex製は8個です。

数年前までは10Gbps物理NICは2個が大半で、物理NICを共有する複数の種類のトラフィックをどのようにコントロールするかは設計者の腕の見せ所だったのではないかと思います。

また、Network I/O Controlバージョン2をお使いの方で、物理NICのコントロールはNetwork I/O Controlを、仮想NICのコントロール (制限) はトラフィックシェーピングを使用されていた方もいらっしゃったのではないかと思います。

バージョン3では物理NICおよび仮想NICのリソースコントロール機能を提供しています。ぜひこの機会に、Network I/O Control バージョン3の使いどころを知っていただけたら幸いです。

 

 

◆vSphere Network I/O Control バージョン2とバージョン3

vSphere 6.0から提供されたNetwork I/O Control バージョン3では、vSphere 5.5までのバージョン2にいくつかの機能を追加しています。バージョン2と3の違いを確認します。

 

<バージョン2>

バージョン2では、たとえば仮想マシンのネットワークトラフィックで、物理NICを対象に異なるコントロールを行いたい場合、ユーザー定義のネットワークリソースプールを使用します。

新規ネットワークリソースプールで、「制限」「シェア値」「CoS優先順位タグ」を指定します。作成したネットワークリソースプールを分散ポートグループに割り当てます。

 

 

 

 

 

 

 

 

 

 

 

 

<バージョン3>

バージョン3では、仮想マシンのネットワークトラフィックで、物理NICを対象にコントロールを行いたい場合は「仮想マシンシステムトラフィック」を、仮想NICを対象にする場合は「ネットワークリソースプール」または「仮想マシンの設定」を使用します。

ネットワークリソースプールを作成する前に、仮想マシンシステムトラフィックでバンド幅の予約設定が必要です。

 

◆システムトラフィックのバンド幅割り当て

システムトラフィックには、事前に定義された9つのトラフィックタイプがあります。

物理NICを対象に、「シェア」「予約」「制限」の設定値を使用して、各システムトラフィックにバンド幅を割り当てます。バージョン3から、設定値に「予約」が追加されました。

設定値 説明
シェア 同じ物理NICを使用するシステムトラフィックタイプの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。

たとえば、FTとiSCSIに100、それ以外には50のシェア値が設定され、対象の物理NICはFT/iSCSI/vMotion用に使用されているとします。

ある時点でFTとiSCSIの2つのトラフィックが物理NICの帯域を超えたら、各トラフィックは物理アダプタのバンド幅の50%を使用します。

ある時点で3つのトラフィックが物理NICの帯域を超えたら、FTとiSCSIに物理アダプタのバンド幅の40%、vMotionに物理アダプタのバンド幅の20%が使用されます。

予約 1個の物理NIC上で確保が必要な最小バンド幅 (Mbps) です。

すべてのシステムトラフィックタイプで予約される合計バンド幅は、物理NICのバンド幅の75%を超えることはできません。

制限 1個の物理アダプタでシステムトラフィックタイプが使用できる最大バンド幅 (MbpsまたはGbit/s) です。

 

下図は、vMotionトラフィックの設定の編集画面です。この分散スイッチには1Gbpsの物理NICが割り当てられています。

 

 

 

 

 

 

 

 

 

 

<10Gbps物理NIC上のシステムトラフィックのバンド幅予約例>

たとえば、次の予約設定によって、1つの物理NICを対象に、仮想マシン用の0.5Gbpsのバンド幅を確保できたことになります。

 

◆仮想マシントラフィックのバンド幅割り当て

仮想マシンを対象に異なるコントロールを行いたい場合には、「ネットワークリソースプール」を使用する方法と、仮想マシンの設定の編集で設定する方法の2つがあります。

設定値 説明
シェア 仮想マシントラフィックをネットワークに転送する物理NICのキャパシティに応じ、この仮想マシンの仮想NICを通過するトラフィックの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。
予約 仮想マシンの仮想NICが物理NIC上で受け取る必要がある、最小バンド幅(MbpsまたはGbit/s) です。

ネットワークリソースプールは予約 (Mbps) のみの設定です。

制限 同じESXiホストまたは別のESXiホストに配置されている他の仮想マシンへのトラフィックに使用できる、仮想マシンの仮想NIC上の最大バンド幅(MbpsまたはGbit/s) です。

 

 

<ネットワークリソースプール>

ネットワークリソースプールのバンド幅割り当ては、そのプールに関連付けられている分散ポートグループ間で共有されます。仮想マシンには、その仮想マシンが接続されている分散ポートグループを介して、ネットワークリソースプールからバンド幅が割り当てられます。

デフォルトでは、分散スイッチ上の分散ポートグループは、割り当てが構成されていない「デフォルト」と呼ばれるネットワークリソースプールに割り当てられています。

 

下図を例にすると、分散ポートグループAに接続される仮想マシンに割り当てられるバンド幅の合計が最小2Gbps確保 (保証) されます。

先に述べたように、ネットワークリソースプールを使用するには、仮想マシンシステムトラフィックで予約の設定をします。

下図は、仮想マシンシステムトラフィックの設定の編集画面です。物理NICのバンド幅の75%を超えない値を設定します。

 

下図は、新規ネットワークリソースプールの画面です。ここで予約値 (最小バンド幅) を設定します。最大割り当て値は、仮想マシントラフィックで設定した予約値×アップリンク (物理NIC) の数です。このアップリンク数は分散スイッチで設定した値です。

 

 

下図は、分散ポートグループの設定の編集画面です。ここで作成したネットワークリソースプールを割り当てます。

<仮想マシン>

各仮想マシンのバンド幅割り当ては、仮想マシンの設定の編集で行います。

「制限」と「予約」は、仮想NICが接続されている分散ポートグループのトラフィックシェーピングポリシーにも依存します。たとえば、トラフィックシェーピングポリシーで平均バンド幅を100Mbpsに設定したなら、仮想マシンの仮想NICの予約値によって仮想マシンが200Mbpsを要求したとしても、実際のバンド幅は100Mbpsになります。

下図は、仮想マシンの設定の編集画面です。ネットワークアダプタを分散ポートグループへ変更し、「シェア」「予約」「制限」を設定します。

 

◆仮想マシンバンド幅のアドミッションコントロール

仮想マシンに十分なバンド幅を確実に割り当てられるようにするため、バンド幅予約とチーミングポリシーにしたがい、ESXiホストおよびクラスタレベルでアドミッションコントロールを実装します。

仮想マシンをパワーオンすると、分散スイッチのNetwork I/O Control機能が、ESXiホストで次の条件が満たされることを確認します。

  • ESXiホスト上の物理NICが、チーミングポリシーと予約に従って、仮想NICに最小限のバンド幅を提供できる
  • 仮想NIC用の予約が、ネットワークリソースプール内の空き割り当て量より小さい

 

<vSphere DRSのバンド幅のアドミッションコントロール>

DRSクラスタ内の仮想マシンをパワーオンすると、vSphere DRSはアクティブなチーミングポリシーに従って、その仮想マシン用に予約されたバンド幅が確保されるキャパシティを持つESXiホストに、その仮想マシンを配置します。下図は極端な例です。

<vSphere HAのバンド幅のアドミッションコントロール>

HAクラスタ内のESXiホストでエラーが発生するかホストが隔離されると、vSphere HAはバンド幅予約とチーミングポリシーに基づき、HAクラスタ内の別のESXiホスト上で仮想マシンをパワーオンします。

 

 

◆まとめ

仮想マシン上のアプリケーションによっては、ネットワークリソースが競合した場合により多くのリソースを割り当てたい、最小限のバンド幅を割り当てたい等のご要望はあると思います。

Network I/O Control バージョン3であれば、これらの要望を仮想NICレベルで満たすことができます。CPUやメモリと同様のコントロール方法ですから、取り組みやすいと思います。予約は仮想マシンがパワーオンできない要因になりますから、その点は注意が必要です。

今回で分散スイッチの投稿は終了です。今後はNSXのご紹介を予定しています。ネットワークは詳しくないと思われているサーバー管理者の方がNSXを検討するなら、を前提に進めたいと考えています。引き続きよろしくお願いします。

仮想スイッチのお作法~分散スイッチの管理②#5~

5回目:仮想スイッチのお作法#5  (分散スイッチの管理②#5)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

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

5回目は、分散スイッチの障害からのリカバリ方法、vCenter ServerとESXiホスト間のネットワーク接続に問題が生じた場合の対処方法をおもにご紹介します。

◆分散スイッチのネットワーク構成のバックアップとリストア

分散スイッチのネットワーク構成のバックアップとリストアは、次の目的で使用します。

  • vCenter Serverデータベースの破損または誤った設定からの復旧
  • アップグレードでエラーが発生した場合に以前の設定へロールバック
  • 分散スイッチのコピーを作成するためのテンプレート

次の操作により、上記目的を達成します。

  • 非同期でディスク上へ分散スイッチ/分散ポートグループ/アップリンクポートグループ設定のバックアップ (エクスポート)
  • バックアップから分散スイッチ/分散ポートグループ/アップリンクポートグループを復旧 (リストア)
  • 変更後に以前の分散ポートグループ/アップリンクポートグループ設定にロールバック (リストア)
  • バックアップから新しい分散スイッチの作成 (インポート)

◆ネットワーク構成のバックアップ

<分散スイッチのバックアップ>

「設定のエクスポート」メニューで、分散スイッチ/分散ポートグループ/アップリンクポートグループの設定をバックアップします。

ここでは、分散スイッチのバックアップを行います。

「分散スイッチを右クリック → 設定 → 設定のエクスポート」を選択します。

次にエクスポート対象を選択します。

バックアップデータを保存して、終了です。

以前、vCenter Serverデータベースの障害により、複数のVLANを構成した分散スイッチにエラーが発生しました。再作成を前に、導入エンジニアが嘆いていたのを思い出します。

新規作成や構成変更のタイミングで、バックアップを取得しておくことは心の安定を得られますね。様々な設定を構成した分散スイッチのエラーを解消できず、最初から作成するのは心が折れます!

◆ネットワーク構成のリストア

設定ミスを想定し、次の内容に変更しています。

リストアは、分散スイッチ単位/分散ポートグループ単位/アップリンクポートグループ単位で行うことができます。

 

<分散スイッチのリストア>

分散スイッチ単位でリストアする場合は、「分散スイッチを右クリック → 設定 → 設定のリストア」を選択します。次にバックアップファイルとリストア対象を選択します。

<分散ポートグループのリストア>

分散スイッチのバックアップデータから、分散ポートグループのみをリストアすることもできます。リストアしたい分散ポートグループを右クリックし、「設定のリストア」を選択します。

次に、バックアップデータから戻すのか(「設定を次のファイルからリストア」)、正常に動作していた以前の設定にロールバックするのか(「以前の設定にリストア」)を選択します。

バックアップ時の設定に戻されているかは、「設定」 → 「ポリシー」で確認します。下の画面では、先のリストア操作で変更前の状態に戻っています。

 

◆分散スイッチのインポート

バックアップした構成ファイルのインポートから、「新しい分散スイッチの作成」「削除された分散スイッチの再作成」「アップグレードに失敗した分散スイッチの復元」を行うことができます。

また既存の分散スイッチに、エクスポートした分散ポートグループのインポートすることもできます。

ここでは分散スイッチのインポートを行います。データセンターを右クリック、「Distributed Switch」 → 「Distributed Switchのインポート」を選択します。

次に、バックアップファイルを選択します。再作成や復元をする場合は、「元のDistributed Switchとポートグループ識別子を保存します」オプションを選択します。

◆管理ネットワークのロールバックとリカバリ

管理ネットワークの構成ミスのためにvCenter Serverへの接続を失った場合、分散スイッチでは管理ネットワークのロールバックとリカバリを行うことができます。

<ロールバック>

ロールバックはデフォルトで有効の設定になっています。接続を失ったことを検知後、30秒 (デフォルトのタイムアウト値) でロールバックします。タイムアウト値の変更方法はKB2096691を参照ください。

分散スイッチのロールバックは、分散スイッチ/分散ポートグループ/分散ポートに不適切な変更が行われると自動で起動します。

ロールバックを無効にするには、vCenter Serverの詳細設定で「config.vpxd.network.rollback」を「false」にします。

<リストア>

ロールバックを無効にした場合や物理ネットワークの変更によって管理ネットワークに問題を生じた場合、ダイレクトコンソール ユーザーインターフェイス (DCUI) を使用して、管理ネットワークの復旧を行います。

DCUIには次の3つのリストア設定があります。

  • Restore Network Settings
  • Restore Standard Switch
  • Restore vDS

「Restore Standard Switch」「Restore vDS」は、分散スイッチで管理ネットワークが構成されている場合に選択可能になります。管理ネットワークが構成されていない場合はグレーアウト表示になります。

「Restore Network Settings」を選択し、次の画面で<F11>を選択すると、工場出荷時の状態に戻ります。

管理ネットワークの構成エラーから復旧する場合は「Restore vDS」を選択します。次の画面で、ポートバインドの方法を選択します。

分散スイッチを標準スイッチに復元する場合は「Restore Standard Switch」を選択します。

「Restore Standard Switch」を選択すると、IPアドレスを割り当てることができる新しいVMkernelポートと標準仮想スイッチがESXiホスト上に作成されます。分散スイッチのアップリンクは、新しい標準仮想スイッチに移動されます。

<KBのご紹介>

◆分散スイッチのアップグレード

アップグレード対象の分散スイッチを右クリックし、「アップグレード」 → 「Distributed Switchのアップグレード」を選択します。

アップグレードメニューには、他に「Network I/O Controlのアップグレード」「LACPサポートの強化」があります。

< Network I/O Controlのアップグレード>

Network I/O Controlをバージョン3へアップグレードすると、システムトラフィックおよび個々の仮想マシン (仮想NIC) へバンド幅割り当てることができます。#6で紹介します。

<LACPサポートの強化>

バージョン5.1の分散スイッチからバージョン5.5/6.0にアップグレードした分散スイッチで、拡張LACPサポートに変換すると、複数のLAGを作成することができます。

アップグレード前に分散スイッチで基本LACPサポートが有効になっていた場合、拡張LACPサポートへは手動で拡張します。

次の画面で、アップグレードするバージョンを指定します。

 

アップグレード前には、分散スイッチの設定のエクスポートをおすすめします!

 

◆まとめ

今回ご紹介した、「ネットワーク構成のバックアップとリストア」や「管理ネットワークのロールバックとリカバリ」は、バージョン5.1から提供されている機能です。分散スイッチはvSphere 4.0から提供されていますから、こなれた仮想スイッチではありますね。

10Gbpsの物理NICの使用が一般的となり、管理するESXiホストが増設され、分散スイッチを活用する機会が増えてきたのではないかと個人的には思います。

管理ネットワークを分散スイッチで構成するなら、設計も変わってきますよね。分散スイッチで管理ネットワークを構成し、接続が失われた時に慌てた方もいらっしゃると思います。実際に正常に復元するの?と問われたこともあります。事前の復元検証は必須かと思いますが、分散スイッチが提供する復旧機能をぜひ活用いただけたらと思います。

次回は、Network I/O Control バージョン3をご紹介します。

 

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

4回目:仮想スイッチのお作法#4    (分散スイッチの管理①#4)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

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

4回目は、分散スイッチの特長であるポートの管理機能および分散スイッチで提供されるアラームや権限付与についてご紹介します。

◆ポートバインド

「ポートバインド」設定によって、仮想マシンの仮想NICを分散スイッチのポートに割り当てるタイミングと方法を指定します。ポートバインドは分散ポートグループで設定します。

下図は、仮想マシンの分散ポートグループの編集画面です。

ポートバインドには、次の3つのオプションがあります。

  • 静的バインド (デフォルト設定)
  • 動的バインド (ESXi 5.0から廃止)
  • 短期-バインドなし

「静的バインド」と「短期-バインドなし」の違いをまとめます。

<KBのご紹介>Choosing a port binding type in ESX/ESXi (1022312)

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

<参考>標準スイッチのポート数

ESXi 5.5以降の標準スイッチのポート数は、分散スイッチのポート割り当ての弾性と同様に8個ずつポートが追加されます。標準スイッチではポートバインドはされません。

標準スイッチは、ESXiホストでサポートされているポートの最大数まで拡張できます。vSphere 6.5の標準スイッチ1台あたりの最大作成ポート数は4,088です。

◆ポート単位の管理

分散スイッチでは、ポート単位でポリシーを設定することができます。

下図は分散ポートグループの編集画面です。「詳細」ページで、各ポリシーのオーバーライドを「許可」に設定します。この設定により、分散ポートグループのポリシーをポートのポリシーで上書きすることができます。

下図はアップリンクチーミングでオーバーライドの許可をした後のポート0の編集画面です。

許可していない項目はオーバーライドを選択することができません。

◆アップリンクポートの管理

分散スイッチでは、アップリンクポートグループやアップリンクポート単位でポリシーを設定することもできます。

下図はアップリンクポートグループのオーバーライドを設定する画面です。この画面でベンダー設定を「許可」にすると、「VLAN」「NetFlow」「トラフィックのフィルタリングとマーキング」に対して、一度にオーバーライドの許可を行うことができます。

◆監視機能

監視機能には、「NetFlow」「ポート状態の監視」「アラーム」があります。

<NetFlow>

NetFlowを有効にすると、分散ポートグループのポートまたは分散ポートを通過するIPパケットを監視することができます。

分散スイッチでNetFlowの構成をする場合は、分散スイッチの設定で、「NetFlow」を選択し、「編集」をクリックします。

編集画面で、コレクタのIPとポート番号を指定します。コレクタから分散スイッチを識別できるように、スイッチIPアドレスに分散スイッチ用のIPアドレスを指定します。

<ポート状態の監視>

「ポート状態の監視を開始」アイコンをクリックすると、ランタイム統計情報を表示することができます。

<アラーム>

分散スイッチでは、「分散スイッチ」「アップリンクポートグループ」「分散スイッチポートグループ」で、新しいアラームを定義することができます。標準スイッチでは定義することはできません。

下図は分散スイッチの新しいアラームの定義を設定する画面です。

<参考>

パケットのキャプチャ用のコマンド「pktcap-uw」をご紹介します。

下図はVMkernelアダプタの「vmk0」をキャプチャした画面です。他に物理アダプタ、vmxnet3仮想マシンアダプタ、ドロップされたパケットのキャプチャを行うこともできます。

3パケットの内容を保存し、Wiresharkなどのツールで表示することもできます。

◆まとめ

4回目は、分散スイッチの分散ポートにフォーカスし、どのような機能があるのかをご紹介しました。物理スイッチの運用管理をされている方には、ポートを番号で管理するのは当然と思われるかもしれませんが、仮想スイッチも分散スイッチなら可能です。

今回ご紹介した機能は、私がインストラクターをしていた時に、「仮想スイッチで〇〇の機能はありますか」とご質問いただいた機能でもあります。

標準スイッチをお使いの方は、運用の効率性もふまえ、分散スイッチの使用をぜひご検討いただけたらと思います。