Home > Blogs > Japan Cloud Infrastructure Blog

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part2: VCFのメリット

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2    VCFはどんなお客様向けの製品?

#3   自動セットアップの方法とは?

#4   VCFはHPE Synergy との連携に優れている

 

こんにちは。日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)です。

 

連載第2回は、VCF(VMware Cloud Foundation)はどのようなお客様向けの製品なのかをご説明します。

 

今回お伝えしたことは、大きく3つです!

 

  1. VMware開発者の理想形が手に入る
  2. SIerさんも嬉しい
  3. 運用中も理想形のまま維持される

 

◆ 1. VMware開発者の理想形が手に入る ◆

 

連載第1回では、VCFはハイブリッドクラウドを実現するための製品であることやVMware CloudTM on AWS も実はVCFをベースとした共通技術(アーキテクチャー)で動いていることをお伝えしました。

共通技術で稼動するシステムがプライベートクラウド上とパブリッククラウド上にあれば、もうおわかりですよね。

――――そうです。

それぞれがシームレスに連携可能になります。わかりやすい例を1つ挙げると、VCF環境にインターネット接続が整っていれば、プライベートクラウドとパブリッククラウドの仮想マシンが相互vMotionすることが可能になります。

では、もしVCFを導入していないVMware仮想化環境でプライベートクラウドとパブリッククラウドをシームレスに連携させるとどうなるでしょうか??

 

下記のようなコンポーネントを一から ”1つ1つ” 構築をしていくことになります。

これらを構築するとなると、様々なソフトウェアを設計し、セットアップし、設定項目も判断しなければなりません。各々は連動もするでしょうから、相互の動作テストも必要です。何十時間、場合によっては何百時間も必要な設計と構築作業―――。うんざりしてしまいますよね。

 

第1回でもお伝えしたとおり、VCFには専用のセットアップツールが付属します。

これで構築を行うとどうなるのでしょう??

 

なんと、 開発元が想定した“理想形”が復元される んです!!

 

先ほどのソフトウェア(コンポーネント)は担当者の設計・判断は必要なく、開発元であるVMware社の最も理想とする形にセットアップされます。せっかく予算化して調達したのですから、良いもの・理想的なもの・高品質なものを手に入れたいのは担当者にとって当たり前のこと。開発元の想定した“理想形”であれば不安もないですし、安心です。

◆ 2. SIer さんも嬉しい ◆

日本のIT現場では“SIerさん”も無くてはならない存在です。

ツールを用いたセットアップはお客様だけはなく、SIer様にもメリットがあります。

 

1つは誰でも構築できること。担当者は実行ボタンをクリックはしますが、実際にセットアップするのはツールの中にいる“ロボット”です。ヒトに判断を委ねることもほとんどありませんので、引っ張りだこの“スーパーエンジニア”でなくとも品質を一律に保ってセットアップできます。そして早い

VCFのセットアップツールは高品質なうえに驚異的な早さでセットアップしてくれます。私が検証したときはナント セットアップ時間 1時間54分 で完了しました。

自動セットアップ完了時の画面 「Bringing Up the SDDC」

vSANやNSX・vRealizeといったVMware SDDCインフラを構築したことがある方であればこれが驚異的な早さであることはお分かりいただけるはず。忙しい設計担当者(アーキテクト)の工数も大きく削減可能です。

◆ 3. 運用中も理想形のまま維持される ◆

では、設計・構築の話はここまでにして、ここからはお客様が最も気になる「運用フェーズ」の話をしたいと思います。

いきなりですが、従来のVMware環境と、理想的な形でセットアップされたVCF環境は運用にどれくらいの違いがあるか説明していきます。

 

◇従来のVMware環境◇

運用を開始し、半年、1年、2年と経過していくと、メインコンポーネントであるVMware vSphere(ESXi)やNSX、管理コンポーネントであるvCenter Server・vRealizeといった各ソフトウェアに新しいバージョンが次々とリリースされていきます。機能強化だけではなく、脆弱性に関するパッチも含まれるため、セキュリティ対策のためにも定期的なアップデートが求められます。

 

これとは逆に“バージョン塩漬け”を好まれるお客様もいらっしゃいますが、VMware製品には製品ごとにサポート期間が設けられており、「サポート切れ」予告が次々に襲ってきます。このようなシステムでは計画停止もタイミングもなかなかありませんし、後手後手でバージョンアップしていくと、各コンポーネント間の互換性チェックが疎かになったり、知らぬ間に相互連携機能が正しく動かなくなってしまう―――。

 

その結果どうなるでしょうか??

 

導入当初どれだけ完璧な状態に構築されても、実際に運用が始まり、日が経つにつれてメーカーの理想形からどんどんかけ離れていきます。

気がついたら、サポートされない組み合わせになっていた・・・なんてことも良く聞く話です。

 

参考:「VMware Product Interoperability Matrices」
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

 

 

◇VCF環境◇

では、VCFを導入している環境ではどうでしょうか。

もちろん、従来環境と同様に、VCF環境でも半年、1年、2年が経過していくと、コンポーネントごとに次々と新しいバージョンがリリースされていきます。

 

しかし!

VCF環境にはバージョン管理の“救世主”として「VMware SDDC Manager」がいます。

 

覚えていますか?? Part1 でご紹介した「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

VCF環境はメーカーの理想形で完璧に構築されるだけでなく、お客様の運用が始まっても、SDDC Managerが理想の状態を維持してくれます。各コンポーネントにパッチがリリースされたりバージョンアップしても、「互換性を考えながら」「最適な手順で」「管理者の手を煩わせずに」最新の状態にアップデートしてくれます。従来と一線を画すこの管理手法は「自動ライフサイクル管理」と呼ばれています。

 

 

 

自動ライフサイクル管理により、理想の状態が保たれますので、運用管理者は不安なく、いつも安心して日々の運用を続けていくことができるというわけです。

 

これまでのようにバージョンアップを検討するたびに「これとこれの組み合わせは大丈夫だったかな・・・」と毎回考えないでよいと思うと、大きな重荷から解放されますよね!!

 

 

今回は、VCFを導入することにより、お客様のメリットをご紹介しました。

 

VCFはVMware開発者の理想形で構築され、それを維持し続けることができる。みんな幸せ!

 

この一言を是非、記憶に留めていただければと思います。

次回は今回取り上げたセットアップツールを解説していきます、是非ご期待ください!

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

Microsoft SQL や Exchange サーバーを VMware vSAN で稼働させるリファレンスアーキテクチャのご紹介・vSphere / vSAN オンラインセミナー実施のお知らせ(2019年04月)

VMware パートナーチームの内野です。

皆さまは、システムを構築する時に、例えば、Microsoft SQL サーバー専用の環境・Exchange サーバー専用の環境の様に各システムを個別に構築しておりませんでしょうか。

もちろん、SQL サーバーの負荷が高くなってしまった時に Exchange サーバー側への影響が発生してしまうのではないか。等のご心配も多くあるのではないかと思っております。

VMware vSAN は、Oracle、SAP、MS SQL サーバー、Exchange 等の様々なビジネスクリティカルなアプリケーションを混在させて稼働させることにより、クラスタの統合が行えることができるスケーラビリティを備えています。

クラスタの統合を行う事により、運用管理負荷の減少・柔軟性の向上・ハードウェアリソースの有効活用により、結果としてトータルコストの削減に役立ちます。

今回、ご紹介する “Mixed Workloads on VMware vSAN All-Flash” では、混在するワークロードがある様な環境において、インフラ管理者が VMware vSAN をどの様に構成するべきかの助けになる構成ガイドとベストプラクティスが記載されております。

 

 

また、こちらのデザインガイドの中には、よくお問い合わせを頂くパフォーマンスに関するテスト結果や Disk Group やキャッシュディスクが破損 (Fail) した場合のパフォーマンス結果の記載もございますので、ご興味がある方はぜひ、ご一読下さい。

■ 例 : 単一の vSAN データストアグループ上で SQL Server Always On Availability Groups と Exchagne Server Database availability groups を同時に稼働させた際のパフォーマンスデータ

■ 例 : Disk Group 障害時 (18:40 前後) の SQL サーバーの動作に関するテスト結果

 

本ガイドの中には、バックアップに関する影響等に関しても記載がされております。詳しくは、是非、”Mixed Workloads on VMware vSAN All-Flash” からご興味のある内容をご確認頂ければと思います。なお、本ブログは、下記 URL ブログの内容を翻訳・抜粋・補足を追記させて頂いたものとなります。不明点に関しては、下記ブログも合わせてご確認下さい。

Mixed Workloads on VMware vSAN for Microsoft SQL Server and Exchange

 

なお、上記でもご紹介している VMware vSAN に関して、2019 年 4 月にオンラインセミナーを実施させて頂くこととなりました。

(注意 : 上記、Microsoft SQL や Exchange サーバーを稼働させる際のリファレンスアーキテクチャーの話はオンラインセミナーでは含まれておりませんのでご注意下さい)

今回は、下記の 2 つのオンラインセミナーを実施させて頂きます。

4/19 日の “vFORUM 2019 プレイバック!基礎からわかる HCI 入門” では、HCI 導入の背景や VMware vSAN の概要・特徴等を解りやすくご紹介させて頂きます。vFORUM 2019 のブレイクアウトセッションでも非常にご好評を頂いたセッションンになっております。

4/24 の “【リアルタイム実況!!】 1 時間で vSAN 初期構築はどこまできる!?” では、オンラインセミナー中に VMware のインターネット上のハンズオン環境を使って、実際に VMware vSAN の構築作業を行い、その様子をオンラインセミナー経由で中継させて頂きますので、実際の構築作業を行いたい方向けの内容となっております。

 

vFORUM 2018 プレイバック! 基礎からわかる HCI 入門

vSphere / vSAN オンラインセミナー 2019#2

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 19 日(金) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 奥村 奈緒美

■ セミナー目次 :
=============

12:00-12:50

1. HCI が定番になりつつある背景
2. vSAN 技術概要
3. やっぱり vSAN がベストな理由
4. HCI 導入にあたる不安要素を取り除こう!
5. まとめ

12:50-13:00

QA

 

【リアルタイム実況!!】1 時間で vSAN 初期構築はどこまでできる!?

vSphere / vSAN オンラインセミナー 2019#3

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 24 日(水) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 内野 賢二

■ セミナー目次 :
=============

12:00-12:50

1. 検証環境への接続/vCenter への接続
2. 検証環境の確認 / VMware vSAN の有効化
3. ノードの追加・ディスクの追加作業
4. 仮想マシンストレージポリシーの設定作業
5. 仮想マシンの作成およびディスクレイアウトの確認

12:50-13:00

QA

 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的にオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容等がございましたら、是非、オンラインセミナーご参加時に直接、コメントを頂ければ幸いです。

VMware 内野

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part1:「VMware Cloud Foundation (VCF) 」 をご存知ですか?

 

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2 VCFはどんなお客様向けの製品?

#3 自動セットアップの方法とは?

#4 VCFはHPE Synergy との連携に優れている

 

はじめまして。日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)と申します。

昨今、パブリッククラウドやプライベートクラウドの登場を背景に、「従来型のシステムを将来に向けてどのように変化させていけばよいのか」といった相談が増えてきました。こういった性質の異なるサービスのメリットをうまく組み合わせた「ハイブリッドクラウド」というワードもメディアで取り扱われるようになり、都市部では有志によるハイブリッドクラウド勉強会なども開催されるようになってきています。

 

そんなハイブリッドクラウドを実現する1つの手段として、「VMware Cloud Foundation ™」製品があります。“VCF”(ヴイ・シー・エフ)と略されるこの製品はvExpertでもある私のイチオシであり、今後もVMwareのオンプレミス製品をお使いの方はもちろん、「VMware CloudTM on AWS」といった話題のクラウドサービスをご検討の方も理解しておかなければならない“必須科目”です。

 

HPEはVCFにおいて日本のみならずグローバルにて協業を進めており、以下のような記事も発表しております。

今回は、HPE Synergy上でVCFを検証した結果も含め、4回に分けてVCFのご紹介を行っていきます。

ご参考記事:

HPE、VMware Cloud Foundation認定のハイブリッドIT基盤を発表(ASCII.jp)

https://ascii.jp/elem/000/001/666/1666586/

 

対談 システムの自律化がクラウドの未来を切り開く(日経XTECH)

https://special.nikkeibp.co.jp/atclh/NXT/18/hpe1005/

 

◆ VMware Cloud Foundation (VCF)とは?◆

 

早速ですが、VCFを一言でいうと「ハイブリッドクラウドを実現するための製品」です。

 

VMware Cloud Foundationの“ファンデーション”は化粧品のそれと同じで「土台」や「基盤」といった意味があります。つまり、VCFはVMware Cloudのベースとなっていることがわかります。意外に知られていませんが、実は先ほど挙げたVMware Cloud on AWS もVCFをベースに動いています。

 

“クラウド”という言葉が付いていますが、VCFはなんとオンプレミス環境でも利用することができます。つまり、VCFはオンプレミスでもパブリッククラウドでも利用することができる、共通技術(アーキテクチャー)なのです!!

 

―――オンプレミスでもパブリックでも?あれ、このフレーズ最近よく耳にしますよね?

はい。「ハイブリッドクラウド」です。

 

 

◆ VCFの構成要素 ◆

 

冒頭ではVCFのことを「製品」と書きました。ただ「共通技術(アーキテクチャー)」とも表現しています。しかもVMware Cloud on AWSもVCFで動いている!?

――― 一体どういうことでしょう。

 

まず、VMware Cloud on AWSについてですが、これはAWSのべアメタルサーバーにVCFソフトウェア(製品)をインストールしてユーザーに提供するフルマネージド型のクラウドサービスです。

 

理解を深めるために、より身近な製品(コンポーネント)まで掘り下げてみましょう。VCFにはよく耳にする次の製品が組み込まれています。

 

 

◆ キーとなるのは 「VMware SDDC Manager」 ◆

あれ、1個聞き慣れない製品が混じっていますね・・・「VMware SDDC Manager」。これは何者でしょう?

 

「VMware SDDC」も呼ばれる、vSANやNSX・vRealizeまで導入したソフトウェアデファインドなVMwareインフラ。これを実際に構築・運用することを考えてみてください。HCI(Hyper Converged Infrastructure)であるvSANを使っていますし、一見外部ストレージ要らずでシンプルなアーキテクチャーに感じますが、実際のところはどうでしょう?

よくよく考えてみると、面倒を見なければいけないものがものとても多い。大まかに図にしただけでもこれだけのものがあります。

 

 

これら1個1個の四角アイコンは、ハードウェアもソフトウェアもそれぞれ“バージョン”を持っています。バージョンがあるということは「バージョン管理」をしていかなければならない―――。

 

このバージョン管理を手動で行っていくのは、日常的にかなりの手間と時間が掛かります。芋づる式のバージョン互換性を紐解きながらバージョンアップしなければいけませんし、トラブルなく進めるには事前検証・調査も必要です。それなりの規模になればトラブル無しは当たり前。いかにダウンタイムを最小限に留められるかを求められる運用管理者も多いのではないでしょうか。もし、事前の調査不足や検証不足などでバージョンアップが途中で失敗したらそこでトラブルシューティングをしなければならず、更に時間を要してしまいます。損ばかりの悩ましい問題です。

※バージョンは一例です

 

vSphereはもちろん、vSAN, NSX, vRealizeをきちんと導入してソフトウェアデファインドなSDDCインフラを目指したいけど、運用が大変―――。

 

これを解決するのが「VMware SDDC Manager」です。

 

VMware SDDC Manager はVCFアーキテクチャー環境専用の運用管理ツール。VCFを構成するvSphere, vSAN, NSX, vRealizeといった各コンポーネント(ソフトウェア)の「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

「ライフサイクル管理??」

 

このメリットは今後本連載を通じて一つずつご紹介していきたいと思いますが、少しだけスクリーンショットをお見せします。

 

まずは導入(セットアップ)フェーズ。

既にここから自動化です。vCenter Serverのインストールはもちろん、仮想スイッチやクラスタ構成・vSANのセットアップ・設定もすべて自動。しかも、VMware社の開発エンジニアの考える「うちの製品をこう設計・構築して欲しい」という姿―――。つまり“メーカーの理想形”(*) の環境にセットアップされます。

 

*「VMware Validated Design」と呼ばれています

 

自動セットアップ画面 「Bringing Up the SDDC」

自動セットアップが終わると、VCF専用の管理画面「VMware SDDC Manager」にアクセス可能になり、ここで一連のライフサイクル管理を行っていきます。

 

VMware SDDC Manager:Dashboard

 

今回はVCFの概要についてご紹介しました。

次回は、VCFがどのようなお客様にとってメリットがあるのかをご紹介いたします。

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。

技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

vSphere 6.7 / vSAN 紹介ウェビナー開催のお知らせ

VMware パートナーチームの内野です。

3/13 (水) のお昼の時間に、下記のオンラインセミナーを開催させて頂きます。インターネットに接続出来ていれば、日本全国はもちろん、海外からでも参加できる非常にお手軽なオンラインセミナーです。

去年の vFORUM でも非常に人気のセッションだった vSphere 6.7 の最新機能紹介とやはり、お客様やパートナー様からのお問い合わせが非常に多い VMware の HCI : vSAN に関するご紹介をさせて頂きますので、是非、多くの皆様にご参加頂ければと思っております。

 

vSphere & vSAN オンラインセミナー

~ 仮想化システムの運用負荷軽減に効く!! vSphere & vSAN 最新機能と活用法をご紹介


 

本オンラインセミナーでは、vSphere や vSphere に一番最適な HCI である vSAN に関して製品のご紹介から利用用途・導入事例等様々な情報をお届けさせて頂きます。

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 03 月 13 日(水) 12:00-13:00

費用: 無償

申し込み : こちらよりお申込み下さい

■ セミナー目次 :
=============

12:00-12:25
—————–
vSphere 6.7 What’s New – 進化した vSphere 6.7 の最新機能をご紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
今回のリリースの特徴には、管理の大幅な簡素化と効率化、組み込み型の包括的なセキュリティ、より多くのワークロードへの対応強化、ハイブリッド クラウド関連機能の強化があります。本セッションでは、それらを実現する為に実装された VMware vSphere 6.7 の新機能と拡張された機能について解説します。

12:25-12:50
—————–
vSAN 概要紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
サーバにコンピューティング機能とストレージ機能を統合したシンプルな構成の仮想化基盤として、ハイパーコンバージドインフラ(HCI)の普及が急速に進みつつあります。仮想化システムの運用管理の負荷にお困りのお客様や、仮想化システムの更新を検討中のお客様に最適な VMware の HCI : vSAN に関して、概要および利用方法をご紹介させて頂きます。

12:50-13:00
—————–
Q&A


 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的に vSphere や vSAN 等のオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容や VMware のオンラインセミナーで発表してみたい等のご意見がございましたら、お気軽にご意見を頂ければ幸いです。

 

VMware 内野

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

Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

 

私の役割の 1つとして、お客様毎の VMware 仮想環境とお客様の要望に対して、Deep Security をどのように導入するのが最適かをご提案させていただく、というものがあります。

その中で 2018年にいくつかのお客様からご相談をいただいたのが、Cross-vCenter NSX 環境における Deep Security の導入についてでした。

データセンターが複数にまたがっている場合には、vCenter Server の Block もデータセンター毎に配置されることが多く、Cross-vCenter NSX を利用して仮想マシンの一元管理と障害時のスムーズなデータセンター間移行を実現したいというニーズが増えてきているようです。また、同一データセンター内でも管理上 vCenter Server を分けているケース(開発環境と本番環境の分割管理)もあり、運用フェーズに応じて仮想マシンを移行していきたいというケースもあるようです。

 

そこで今回は Cross-vCenter NSX 環境において Deep Security を導入する場合のユースケースをご紹介したいと思います。

 

Cross-vCenter NSX 環境について改めて整理してみる

まず、Cross-vCenter NSX 環境について改めて整理をしてみましょう。

  • 同一の Platform Services Controller(PSC)配下に各データセンターの vCenter Server が配置され、各 vCenter Server が同一 SSO ドメインに属していること。
    vSphere 6.7 の場合は、Embedded PSC もサポートされていますが、Deep Security との連携とは直接関係がないため、言及は割愛しています。)
  • 各 vCenter Server で拡張リンクモード設定が行われていること。
    拡張リンクモードにより複数の vCenter Server Block のインベントリ情報を一元管理することができるようになります。
  • Cross-vCenter NSX 設定により NSX サービスも vCenter Sever を跨いだクラスタで一元管理できること。
    Cross-vCenter NSX 設定時に vCenter Server に紐づく NSX Manager のどちらをプライマリロールとするかを選択する必要があります。
    ※ ネットワークの拡張においては、各 vCenter Server Block のクラスタ間のオーバレイネットワークが同一セグメントで拡張されるようにする必要があります。
    ※ 物理的にデータセンターが分かれている場合は、ユニバーサル分散論理スイッチを展開して L2 ネットワークを拡張する必要があります。同一データセンターで各 vCenter Server 配下のクラスタ上に展開されている分散スイッチ上のネットワークアドレス体系が同一の場合(同一のネットワークスイッチ群に接続されている)場合には、ユニバーサル論理スイッチの展開は不要となるでしょう。

 

Cross-vCenter NSX 環境における Deep Security 構成のベストプラクティス

ここからはサンプルのデータセンター構成(2つのデータセンターにそれぞれ vCenter Server、NSX Manager が構築されている Cross-vCenter NSX 環境)で Deep Security を導入する際のベストプラクティスを解説していきたいと思います。
Cross-vCenter NSX 環境で Deep Security を導入する場合には、プライマリとして動作するデータセンター(以下の図ではデータセンター A)に Deep Security Manager(DSM)を配置することを推奨します。

Cross-vCenter NSX 環境に限らず、Deep Security と VMware NSX との連携にあたっては DSM、vCenter Server、NSX Manager の連携が非常に重要となります。
以下のような三角形のようなイメージでのコネクションにより、インベントリ情報の共有、ポリシー連携などが実現されます。
(ポリシー連携の詳細については、第6回ブログをご参照ください。)Cross-vCenter NSX 環境で DSM を連携する際には、データセンター A の vCenter Server / NSX Manager、データセンター B の vCenter Server / NSX Manager それぞれと接続設定をする必要があります。(拡張リンクモードで接続されているとしても、DSM はあくまで vCenter Server Block がそれぞれ独立して存在するものとして連携します。)
連携設定後、DSM の管理コンソールからは vCenter Server Block が両サイト分表示されることになります。

サンプル構成のように、DSM を片方のサイトに設置して、両サイトの vCenter Server 配下の仮想マシンを統合的に保護することによって、データセンター A からデータセンター B へ vCente Server 跨ぎで Enhanced vMotion した場合でも自動的に Deep Security のセキュリティ保護を継続することができます。
実際には、Enhanced vMotion した際には移行先の vCenter Server 上では新たな仮想マシンが生成されたように見えるため、その仮想マシンに新たなUUID が付与されたと認識して、NSX セキュリティポリシーが自動的に適用されて、合わせて Deep Security ポリシーも有効化される動作となります。
(Deep SecurityのポリシーとNSXセキュリティポリシーの関係については、第6回ブログをご参照ください。)

ここで、「なぜ、DSM を vCenter Server と同様に両サイトに置かないのか?」という疑問が出てくることでしょう。
その理由は、DSM がその管理配下に入る Deep Security Agent(DSA)、Deep Security Virtual Appliance(DSVA)をどのように管理するかということに関係してきます。

Deep Security では DSA、DSVA の保護に問わず、仮想マシン毎に割り振るべきポリシーを管理しており、その仕組みに ”フィンガープリント” を利用しています。
DSA または DSVA の保護対象になる仮想マシンは、DSM の管理配下で有効化処理をされた時点で仮想マシン毎に固有のフィンガープリントを発行され、一意に管理されます。(コンバインモードで保護されている仮想マシンは、DSA と DSVA 双方のフィンガープリントを保持します。コンバインモードについての詳細は、第9回ブログをご参照ください。)フィンガープリントを保持することにより、対象の仮想マシンは必ず一意の DSM に紐づくことが保証され、vMotion などにより他の環境に移動した際にも、勝手に他の DSM の管理下に入ってしまうことを防ぐためにセキュリティ的なプロテクトをかけることができます。(フィンガープリントは、仮想マシンに対する無効化処理を行い、なおかつ、DSA の場合にはエージェントが保持しているフィンガープリントを手動でリセットしない限り削除されません。)

上記のように、Deep Security は VMware vSphere / VMware NSX の仕組みとは別に独自の仕組みによって、DSM と保護対象である仮想マシンをセキュリティ保護する DSA / DSVA との間で各仮想マシンを一意に管理しているため、Cross-vCenter NSX 環境で DSM を利用する場合には、DSM はどちらかのサイトにだけ配置して、各 vCenter Server、NSX Manager と連携をすることが運用面からも最適と考えられます。

 

vCenter Server Block に対応して DSM を配置した場合の留意点

もし、DSM をデータセンター B にも配置して、vCenter Server Block と対になる形で構成したい場合には、前述の通り、Deep Security は VMware vSphere / VMware NSX の仕組みとは別にフィンガープリントにより DSM と DSA が一意に紐づいていることから、Enhanced vMotion を実行する仮想マシンに DSA がインストールされている場合、移行先の vCenter Server 配下のクラスタで有効化されたとしても、DSA のフィンガープリントが移行元の DSM となっているため、正常に保護を行うことができなくなります。正常に有効化をするためには、Enhanced vMotion 実行後に DSA のリセット処理を行う必要があります。この処理は、仮想マシン上から手動にて実行する必要があります。

また、いくつかの機能については、DSM 側で情報を保持して機能を提供しているため、以下の制約が発生します。

  • 各サイトにおいて、それぞれ同一の DSM 上のポリシー、vCenter Server / NSX Manager の NSX セキュリティポリシー / セキュリティグループを設定しておく必要がある。
  • 推奨設定の検索の結果、変更監視のベースラインが移行元 DSM から移行先 DSM へ引き継がれない。(推奨設定の検索、ベースラインの新たに構築を実施する必要がある。)

 

Cross-vCenter NSX 環境で Deep Security 連携する場合の制約事項

ベストプラクティスに則った構成であっても、いくつかの制約事項があります。

  • 移行元の vCenter Server 配下で DSA が有効化されていなかった仮想マシンが、Enhanced vMotion した場合には、移行先の vCenter Server で起動したタイミングで、DSA の有効化が自動的に行われます。(NSX セキュリティポリシーによって、新しい UUID を付与された仮想マシンが起動したと認識して、Deep Security ポリシーを含めたサービス適用を行うため。)
  • DSVA で変更監視を行っている場合、変更監視のベースラインマッチングを行うエージェントデータベースを移行できないため、ベースラインを新たに構築する必要がある。

 

少し複雑な内容だったかもしれませんが、ご理解いただけましたでしょうか?
基本的には、以下の点を抑えて設計をいただければ、正しい設計をいただけるのではないかと思います。

  • DSM は vCenter Server / NSX Manager とそれぞれの Block 毎に連携設定を行う。
  • DSM と DSA / DSVA は仮想マシン毎にフィンガープリントによって一意に紐づいている。
  • 構成に応じた制約事項、留意事項があることをあらかじめ理解しておく。

 

執筆者:
トレンドマイクロ株式会社
エンタープライズSE本部
セールスエンジニアリング部 サーバセキュリティチーム
シニアソリューションアーキテクト / VMware vExpert
栃沢 直樹(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の対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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のデモがあります。ぜひご確認ください。
こちらでご紹介した内容が、みなさんのお役に立てたなら幸いです。

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

分散ファイアウォールと連携したマルウェア検出時の自動隔離

 

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

少し間が空いてしまいましたが、今回は Deep Security がマルウェアを検出した際に VMware NSX の分散ファイアウォールと連携して該当の VM を自動隔離する仕組みについてご紹介します。この連携はここ最近特に VMware Horizon の導入を検討されているお客様の多くでご利用をご要望されることが多いソリューションです。
ランサムウェアや標的型サイバー攻撃に対する対策の強化にあたり、インシデントが発生した段階でいち早く一次対処が可能となる点が採用のポイントになっています。

NSX 分散ファイアウォールによってユーザが利用する仮想デスクトップ環境のマイクロセグメンテーションを実装しておくだけでも、ランサムウェアや標的型サイバー攻撃の初期段階でよく見られる「横感染/拡散」を抑制することはできますが、さらに自動隔離を実装しておくことによって管理者の手を煩わせることなく感染した仮想デスクトップ(以下 VM)をネットワークから切り離すことが可能となります。また、あくまでこの「自動隔離」はハイパーバイザ上でのアクセス制御ポリシーによって行われますので、VM 側の vNIC には直接影響を与えないことも特徴です(ネットワークアドレスの変更や vNIC のステータスには変更はありません。)

以下にマルウェア検出時の自動隔離の仕組みと実装のポイントについて解説していきます。

 

Trend Micro Deep Security と NSX 分散ファイアウォールの連携イメージ

最初に Deep Security と分散ファイアウォールがどのように連携をするかのイメージを見ていきましょう。

  1. Deep Security Virtual Appliance(以下 DSVA)にて VM 上でのマルウェアを検出。DSVA からDeep Security Manager(以下 DSM)に不正プログラム対策イベントを検出
  2. DSM が不正プログラム対策イベントの検出をトリガーとして、NSX Manager に対して該当のVM への NSX セキュリティタグ情報を送信
  3. 該当の VM に対して NSX セキュリティタグが付与されることにより、予め設定されていた VM の NSX セキュリティグループが変更されることによって適用されるファイアウォールポリシーが変更されて、ネットワークアクセスが制限される

マルウェアを検出して NSX セキュリティタグを付与するまでは Deep Security の役割、実際の VM のアクセス制御を行うのは VMware NSX の役割となります。また、NSX セキュリティタグが付与された VM は vCenter 上からも確認することが可能です。

 

自動隔離を実現するために必要な設定

マルウェア検出時に設定しておくべきポイントは大きく以下の 3つがあります。

  • NSX セキュリティグループの作成
  • NSX 分散ファイアウォールの設定
  • Deep Security での NSX セキュリティタグ付与の設定

ここではすでに VMware NSX と Deep Security のエージェントレス型セキュリティ対策に必要な設定は完了している前提で上記の3つのポイントについて解説していきます。詳細の設定手順を確認したい方は、以下のインテグレーションガイドを参照してください。

VMware NSX & Trend Micro Deep Security インテグレーションガイド
<ダウンロード先>
Trend Micro Deep Security サポートウェブ
VMware テクニカルリソースセンター

 

【NSX セキュリティグループの作成】

エージェントレス型セキュリティ対策の実装が完了していれば、VM をグルーピングするためのセキュリティグループの設定はすでに行われているはずですが、以下の設定を加えておく必要があります。

  1. 通常運用時に所属しているセキュリティグループに対する NSX セキュリティタグが付与された VM を除外する設定の追加
  2. NSX セキュリティタグが付与された VM が所属するセキュリティグループの作成

NSX セキュリティグループの特性として、同一 VM が複数のセキュリティグループに参加することができてしまうため、1. 側で除外設定をしておかないと NSX セキュリティタグが付与された際に両方のグループに所属することになり、正しく隔離動作が行われなくなります。
また、2. の隔離用のセキュリティグループは正常時は VM が所属しないグループとなります。(設定の方法は上記に限らず設定はできると思いますので、環境に合わせて設定をしていただければと思います。)

 

【NSX 分散ファイアウォールの設定】

実際にマルウェアを検出した際に自動隔離するためには、先ほど設定をしたセキュリティグループを利用して隔離用のファィアウォールルールを作成する必要があります。
ここで、分散ファィアウォールにおけるセキュリティポリシー、グループの関係を整理しておきましょう。

分散ファイアウォールの設定は通常のネットワーク型ファィアウォールと同様で、送信元や送信先を IP アドレス(または IP アドレス)以外の仮想マシンやセキュリティグループなどをオブジェクトとして利用することでよりシンプルなルール設定が可能となっています。
実際には以下のようなファィアウォールルールを設定することになります。

この例ではルール ID #4/#5 に隔離用グループのアクセス制御ルールを記載しており、Incoming、Outgoing の通信を完全に遮断する形となっています。運用要件に応じて、隔離時にも通信が必要なトラフィックがある場合には適宜ルールをカスタマイズ、追加して対応することができます。特に VMware Horizon 環境の場合、Horizon Connection Server とのコネクションが切断されてしまうことで隔離した VM が削除されてしまうことがあり、そういった際には隔離グループと Horizon Connection Server との通信を許可するルールを設定しておくことも有効です。

また、自動隔離とは直接関係はしませんが、仮想デスクトップ環境において利用する場合、現在のクライアント PC に導入されるアプリケーションの多くは、サーバとの通信を行うのがほとんどで、クライアント間の Peer to Peer の通信が必要なことはありません。クライアント環境の脅威で特に留意が必要なランサムウェア感染時の横拡散や標的型サイバー攻撃の着弾を受けたクライアントからの攻撃者の探索活動に対しては、ルールID #3 のような仮想デスクトップ間の通信をブロックするルールを設定しておくことで被害の拡大を抑制することが可能となります。IP アドレスベースではなく、セキュリティグループをファイアウォールルールのオブジェクトとして指定できることで同一ネットワークにある仮想デスクトップ同士でも必要なセキュリティポリシーを柔軟に適用できるところは NSX 分散ファイアウォール活用の大きなメリットではないかと思います。

 

【Deep Security での NSX セキュリティタグ付与の設定】

あとは Deep Security 側で不正プログラム対策イベントが検出された際に NSX セキュリティタグを NSX Manager へ送信するために必要を設定しておく必要があります。
DSM のコンソールにアクセスをして、自動隔離を行いたい VM(正確には自動隔離を行いたい NSX セキュリティグループに割り当てた NSX セキュリティポリシー)に紐づく Deep Security ポリシーを選択します。

不正プログラム対策の[詳細]タブより、NSX セキュリティのタグ付けを有効化する設定を行います。
NSX セキュリティタグはすでに用意されている 3つのタグのうちどれを利用していただいても問題ありません。(high / medium / low のどれを選択しても挙動は一緒です。)
また、自動隔離された後に、フル検索を手動で実施した際に新たなウイルスを検出しなかった場合に NSX セキュリティタグを自動的に削除(隔離グループから通常のグループへの復帰)したい場合には、[この後の不正プログラム対策が不正プログラム検出イベントが生成されずに完了した場合、以前に適用された NSX セキュリティタグは削除されます。]にチェックボックスを入れてください。(もちろん、vCenter から該当 VM の NSX セキュリティタグを手動で外すことも可能です。)

また、DSM と DSVA との間ではデフォルト 10分に 1回のハートビートで相互の状態確認を行っています。不正プログラム対策イベントはハートビートのタイミングで DSVA から DSM へ通知されるため、このままだと感染検出時に即時に隔離を行うことができません。そのために、DSVA がホスト上の VM で不正プログラム対策イベントを検出した場合に、ハートビートのタイミングを問わず、即時に DSM にイベントを通知する設定を行う必要があります。
この設定は DSM のコンソールから設定はできないため、OS上でコマンド実行を行っていただく必要があります。(以下は Windows OS で DSM を構築した場合のコマンド例)

DSM のプロセスの再起動が発生します。
また、DSVA に設定を反映することが必要なため、この後に必ず DSVA に対するポリシーの再配信を行ってください。(設定反映のためのポリシー配信のため、各 VM に対するポリシー配信ではないことを注意)

上記の一連の設定を完了すれば、Deep Security の不正プログラム対策イベントを起点とした自動隔離を行うことができるようになります。

 

 

まとめ

いかがでしたでしょうか。
Deep Security と VMware NSX の連携は単純にエージェントレスでのセキュリティ対策を実現するだけではなく、インシデント発生時のオペレーションの自動化を図るためにも利用することができます。本編でも記載をしましたが、NSX 分散ファイアウォールをうまく利用することで通常時でもランサムウェアの拡散や標的型サイバーいかがでしたでしょうか攻撃着弾時の横感染のリスクを低減できますし、いざとなったときにさらに強固な隔離用ファイアウォールルールを自動適用することができます。
みなさんが当たり前に使っているファイアウォール、ウイルス対策ですが、Deep Security とVMware NSX の連携をうまく活用していただくことでセキュリティレベルの向上の運用性の向上の両立を図っていただけるのではないかと思います。
ぜひ、お試しください!

 

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネス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の対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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を超活用するためには必要な知識です。ぜひトライしてみてください!