Quantcast
Channel: VMware Japan Blog
Viewing all 861 articles
Browse latest View live

ちょっとした技術的な TIPs のご紹介 (2017.08)

$
0
0

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は、Cloud Infrastructure Blogに次の 3点について投稿したいと思います。

1. vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順について
2. Nexus 1000v から vDS への移行について
3. vSphere 6.5 の EOGS (End Of General Support) の延長について

では、それぞれについて記載していきます。

 

1. vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順について

vSphere の上で動作する弊社製品 (Horizon、NSX など) が混在する環境において、vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順の説明をしている KB (Knowledge Base) があります。この KB で更新する製品の順番を確認できますので、参考にしてみてください。

vSphere 6.5 へ更新する場合:
・Update sequence for vSphere 6.5 and its compatible VMware products (2147289)
・vSphere 6.5 およびその互換性のある VMware 製品の更新手順 (2148021)

vSphere 6.0 へ更新する場合:
・Update sequence for vSphere 6.0 and its compatible VMware products (2109760)
・vSphere 6.0 およびその互換性のある VMware 製品の更新手順 (2113872)

注:英語版に更新が入っても、ローカライズ版には反映されなかったり、更新が遅れたりする場合が多々ありますので、日本語版 (もローカライズ版の1つになります) は参考情報という扱いでご参照頂けると幸いです。

 

2. Nexus 1000v から vDS への移行について

その昔、弊社がサードパーティ仮想スイッチ (Nexus 1000v) を OEM 販売していたのですが、OEM の終了に伴い、以下の KB (FQA:Frequently Asked Questions 形式) が公開されています。

・Discontinuation of 3rd party vSwitch program (2149722)
・サード パーティ vSwitch プログラムの終了 (2150173)

—– KB 2149722 (英語) から抜粋 —–
Will VMware support the migration of Nexus 1000V to VDS?
Yes, customers can use a free migration tool developed by VMware. They can reach out to Global Support and Services (GSS), or engage the VMware professional services organization (PSO). Migration documentation and the migration tool is available for download.
——————————————

—– KB 2150173 (日本語) から抜粋 —–
vSwitch の移行を支援するため、VMware では、Nexus 1000v から Distributed Switch に移行するための無償の移行ツールを提供しています。さらに、VMware Professional Services Organization が、サード パーティ vSwitch から Distributed Switch に移行するサービスをお客様に提供することができます
——————————————

上記、抜粋の中で太字 (ボールド) にしている 「free migration tool」 や 「無償の移行ツール」 は次の手順で入手できますので、実際に移行を行う場合や、検討されている場合は、是非、ダウンロードして活用してみてください (もしくは、ツールを使わないまでも、同梱されている Migration Guide (PDF ドキュメント) は参考になると思います)。

英語のダウンロード・サイトへアクセス。

②検索ボックスに “nexus 1000v vds” と入力して検索。

③検索結果ページの (恐らく) 1つ目にリストされている “VMware vSphere > Drivers & Tools > Migration tool – Nexus 1000v to VDS” をクリック。

④表示されたページで Download ボタンをクリックします。

⑤MyVMwareにログイン後にダウンロードが開始されます。

⑥ダウンロードした 「MigrationTool_Nexus1000v_to_VMWare_VDS.zip」 を展開すると以下のファイルがあります。

補足情報:
2017年7月27日にリリースされた ESXi 6.5 Update 1 のリリースノートで、サードパーティ製の仮想スイッチ・プログラムと、サードパーティ製の仮想スイッチで使用されていた VMware vSphere API が vSphere 6.5 Update 1 の次のリリースで廃止される予定との発表がされています (VMware ESXi 6.5 Update 1 リリース ノートの内で詳細は KB2149722 参照との記載がされています)。

 

3. vSphere 6.5 の EOGS (End Of General Support) の延長について

一部の方は既にご存知かも知れませんが、2017年7月27日に vSphere 6.5 Update 1 がリリースされたタイミングで、vSphere 6.5の EOGS が延長され、vSphere 6.0.x と vSphere 6.5.x で、EOGS の日付が次の様に変更となりましたので、ご留意ください。

・ vSphere 6.0.x の EOGS は 2020年3月12日 (以前の vSphere 6.x の EOGS と同じ日付)
・ vSphere 6.5.x の EOGS は 2021年11月15日 (vSphere 6.5.x の EOGS として延長された日付)

詳細は、VMware Lifecycle Product Matrix  を参照下さい (ちなみに、このリスト内で参照頂く製品名は、ESXi 6.0 や ESXi 6.5 の行です)。

補足情報:
サポートを購入頂いているお客様には、General Support 期間中、メンテナンス アップデートとアップグレード、不具合、セキュリティの修正、および、技術的な支援が提供されますが、EOGS (End Of General Support) とは、その General Support  期間の終了を指しています。詳細はこちらをご参照ください。

 

今回、お伝えした内容も、日々の活動の中で、広くお伝えした方がいいかなと思う点をピックアップしてブログにさせて頂きました。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

 

The post ちょっとした技術的な TIPs のご紹介 (2017.08) appeared first on Japan Cloud Infrastructure Blog.


ちょっとした技術的な TIPs のご紹介 (2017.09)

$
0
0

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は、Cloud Infrastructure Blogに次の 2点について投稿したいと思います。

1. vRealize Operations Manager のサイジングについて
2. vSAN Ready Node について

では、それぞれについて記載していきます。

 

1. vRealize Operations Manager のサイジングについて

みなさん、vRealize Operations Manager (vRealize Operations for Horizonを含む) のサイジングのガイドラインとして、以下の KB (Knowledge Base) を公開しているのはご存知でしょうか?

vRealize Operations Manager Sizing Guidelines (2093783)
vRealize Operations Manager のサイズ変更のガイドライン (2124497)

注:KBの英語版に更新が入っても、ローカライズ版には反映されなかったり、更新が遅れたりする場合が多々ありますので、日本語版 (もローカライズ版の1つになります) は参考情報という扱いでご参照頂きたく存じます。

vRealize Operations Manager (vR Ops) は、仮想環境のリソース使用状況のデータを収集し、独自のアルゴリズムで分析した結果から、リソースの使用状況が健全かどうかを可視化したり、未来のリソース使用状況を予測したり、動的閾値を用いて必要に応じてアラートをあげるといった事などを可能にする製品ですが、仮想環境の規模に応じて収集すべき対象のデータが多くなったり、収集したデータの保持期間 (デフォルトでは180日) に応じて蓄積するデータが多くなったりと、それらデータを格納する為にはそれなりのディスク容量が必要となってきます。また、収集した大量のデータを分析するには、CPU や メモリ といったリソースも必要です。

と言う事で、実際にデプロイすべき vR Ops の仮想アプライアンスはどれくらいのスペック (CPU、メモリ、ディスク) を保持していればいいのか、という点をガイドしているのが上記の KB になります。実際は、上記の KB 内で、 vR Ops のバージョンに対応した KB のリンクを公開しており、その KB 内で、各バージョンでのサイジングのガイドライン、および、エクセルのサイジング・ツールを添付しています。

例えば、KB 2093783 の中で、vR Ops 6.4 の場合は、KB 2147780 を参照となっています。KB 2147780 にアクセスすると、vR Ops を展開する際の仮想アプライアンスのサイズ (Small / Medium / Large など) や、それに伴う展開された際の仮想アプライアンスのスペック、および、注意事項 (Note) の記載と、エクセルのサイジング・ツールが添付されています (KB 2147780 には 2147780_vRealizeOperationsManagerSizingFor6.4_v2.xlsx が添付されています)。

添付のエクセルには、幾つかのシートがありますが、簡易サイジングであれば、Sizing Guide (Basic) シートをお使い頂き、より詳細なサイジングの場合は、使用する Management Pack 等に応じて必要な他のシート (xxxxx Input という名称のシート) のインプット (水色) のセル部分に数値を入力して、Advanced – Results シート (このシート内にもインプットのセルはありますのでご注意ください) を結果として参照します。

是非、これらの KB を vR Ops のサイジングに役立てて頂ければと思います。

 

2. vSAN Ready Node について

さて、vSAN を語る上で、必ずと言っていい程出てくる言葉があります。それは vSAN Ready Node という言葉なのですが、みなさん、この vSAN Ready Node とは何の事かご存知でしょうか?

vSAN ReadyNode は、VMware Hyper-Converged Infrastructure ソフトウェア用に事前設定され、テストされ、認定された全ての主要なサーバーベンダーから入手可能な x86 サーバーで、各 ReadyNode は、必要な CPU、メモリ、ネットワーク、I/O コントローラ、ストレージ (SSD、HDD、または、フラッシュデバイス)で vSAN 用に最適に構成されています。また、構成プロファイルとして、サーバ ワークロード向けと、VDI ワークロード向けのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

vSAN Ready Node の確認や、構成プロファイルの確認はそれぞれ以下で可能です。

VMware Compatibility Guide – vSAN Ready Node
vSAN ハードウェア クイック リファレンス ガイド

では、この vSAN Ready Node で定められたハードウェア・コンポーネントをカスタマイズする事は弊社のサポート的に許されているのでしょうか?

2014年3月11日に vSphere 5.5 Update 1 のリリースに伴い、vSAN 1.0 (当時は Virtual SAN という名称でした) が正式にリリースされましたが、当時は vSAN Ready Node をカスタマイズする事は想定しておらず、vSAN Ready Node として構成されたハードウェア・コンポーネントを使用する事がサポートの前提でした。ところが、この点が今年の春 (具体的には以下のブログが公開された2017年3月14日) から緩和され、以下のブログ (英語) で公開されている範囲でのカスタマイズが認められるようになりました。

What You Can (and Cannot) Change in a vSAN ReadyNode

詳細については上記のブログを参照頂きたいのですが、参考情報と言う事で、以下に上記ブログ内にも記載されている vSAN Ready Node から変更可能なパーツについて、一部補足情報を加えて掲載しておきます。

参照リンクのみこちらにもピックアップしておきます:
https://blogs.vmware.com/virtualblocks/2017/01/18/designing-vsan-disk-groups-cache-ratio-revisited
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan
https://kb.vmware.com/kb/2145210

この点 (vSAN Ready Node) について、弊社の製品担当 SE もブログで触れていますので、以下のブログもチェックしてみてください。以下のブログでは、私が今回テーマとして挙げた vSAN Ready Node 以外の vSAN ネタについて掲載されていますので、それらも是非、参考にして頂けると幸いです。

ReadyNode – もう始める準備はできています。

 

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

 

The post ちょっとした技術的な TIPs のご紹介 (2017.09) appeared first on Japan Cloud Infrastructure Blog.

ここが変わった! VMware vSphere 6.5 Part4

$
0
0

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

今回は、vSphere 6.5で使用可能な3つの管理ツールについてご紹介します。

vSphere 6.5から、「VMware Host Client (HTML5 バージョン)」と「vSphere Client (HTML5 バージョン)」が新たに提供され、「vSphere Web Client (Flex/Flash バージョン)」はパフォーマンスと操作性が改良されています。

WindowsアプリケーションのvSphere Clientは、vSphere 6.5から使用不可となりました。

https://blogs.vmware.com/vsphere/2016/05/goodbye-vsphere-client-for-windows-c-hello-html5.html

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆3つの管理ツール◆

vSphere 6.5で使用可能な3つの管理ツールの違いを確認します。

vSphere 6.5からは、ESXiホストを管理するために「VMware Host Client (HTML5バージョン)」を、vSphere基盤を管理するために「vSphere Web Client (Flex/Flash バージョン)」および「vSphere Client (HTML5 バージョン)」を使用します。

 

◆VMware Host Client (HTML5バージョン)◆

VMware Host ClientはvSphere Web Clientと類似したユーザーインターフェイスです。慣れた画面構成で、初めて使う方でも操作に迷うことはほとんどないと思われます。

また、1台のESXiホストを管理するツールのため、vCenter Serverで提供される機能は表示されません。特別な設定も必要とせず、サポートされるWebブラウザを準備するのみです。

次のアドレスを使用して、Host Clientへ接続します。

https://ESXiホストのFQDNまたはIPアドレス/ui

 

Host Clientは、vSphere 6.0 Update 2 以降から使用可能です。vSphere 6.0を運用管理されているユーザーの方もぜひ試用してみてください。

私個人としては、HTMLベースのHost Clientは、ダウンロード等の事前準備が必要ないこと、vSphereバージョンごとの導入が必要ないことをメリットと感じます。

 

 

◆vSphere Client (HTML5バージョン)◆

vSphere Clientは、HTMLベースのため、Adobe Flash Playerのインストール(Adobe Flexの有効)は必要ありません。Host Client同様、対応のWebブラウザがあれば使用可能です。

次のアドレスを使用して、vSphere Client (HTML5)へ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ui

 

vSphere Client (HTML5)は未サポートの機能もあります。vSphere 6.5 Update 1から標準的な機能が追加されています。

<vSphere 6.5 Update 1の未サポート/サポート機能>

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-client-65-html5-functionality-support.html

 

先日vRealize Operations Managerのトレーニングテキストを作成するために、テスト環境を構築しました。その環境では、Adobe Flash Playerのインストールができなかったため、vSphere Client (HTML5) の使用を試みました。標準的な機能を使用するのであれば十分ですね。全機能の移行が待たれます。

 

 

◆vSphere Web Client (Flex/Flash バージョン)◆

vSphere 6.5から、vSphere Web Clientがすべての機能やプラグインを提供する管理ツールとなります。

Web Clientは、Adobe Flash Player 16以降のインストール、およびサポートされるWebブラウザを準備する必要があります。

次のアドレスを使用して、vSphere Clientへ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ vsphere–client

 

vSphere 6.5のWeb Clientの改善点をいくつか挙げます。

 

1.ユーザーインターフェイス

vSphere 6.5では、「はじめに」「監視」「構成」のタブで構成されています。以前の「管理」から「構成」へタブが変更されています。vCenter Serverのwebclient.propertiesを編集し、「管理」タブへ戻すことも可能です。

Web Client 6.5では、WindowsアプリケーションのvSphere Clientに近いメニュー構成に変更されています。以前と比べ階層が1つ減り、操作性が改良されています。

 

<Web Client 6.0>

<Web Client 6.5> ※下図は、vSphere 6.5 Update 1の画面ショットです

2.クライアント統合プラグイン

vSphere 6.0以前のバージョンでは、次の機能を実行するために、クライアント統合プラグインが必要でした。6.5では不要です。小さな改良ですが、嬉しい改良点ですね。

  • OVFファイルのインポート/エクスポート
  • データストア内のファイルのアプロード/ダウンロード

 

3.拡張認証プラグイン

拡張認証プラグインは、vSphere 6.0以前のクライアント統合プラグインの後継機能です。

拡張認証プラグインは、統合 Windows 認証と Windows ベースのスマート カード機能を提供します。この2つの機能のみが、以前のクライアント統合プラグインから引き継がれます。

以前のクライアント統合プラグインとvSphere 6.5の拡張プラグインの間で競合は発生しません。

 

4.その他のプラグイン

VMware Site Recovery Manager (SRM) プラグインはバージョン 5.8からWeb Clientへ完全に移行します。

参考までに、VMware Update Manager (VUM) プラグインは、vSphere 6.0 Update 1からWeb Clientで使用可能です。

 

 

◆vSphere Client (HTML5)の情報◆

vSphere Client (HTML5) と vSphere Web Client 6.5 の FAQ

<英語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147929

<日本語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2148759

 

vSphere Client (HTML5)で使用可能な機能の最新情報はこちらでご確認ください。

https://labs.vmware.com/flings/vsphere-html5-web-client#changelog

 

 

◆まとめ◆

VMware Infrastructure 3.5からのユーザーである私には、使い慣れたツールであるWindows アプリケーションのvSphere Clientが廃止されるのは少々寂しい気持ちになります。しかし快適な使用環境へ移行しているのですから、喜ばしいことです。

vSphere 5.1からの新機能はWeb Clientから提供され、vSphere 6.5でvSphere ClientからWeb Clientへ完全に移行されました。また先に述べたように、Web Client 6.5ではメニュー構成も改良されています。覚えたメニューの配置が変わるのは、慣れるまで時間を要しますが、よりよい変更のためですからね!

次回はvSphere HAです。vSphere HAはvSphere 5.0で大きくアーキテクチャーを変更し、その後も小さな改良が見られます。私個人はバージョンが上がるたびにVMware社がvSphere HAの改善を追求していると感じます。vSphere HAは運用において重要な機能ですからね。次回も参考にしていただければ幸いです。

 

The post ここが変わった! VMware vSphere 6.5 Part4 appeared first on Japan Cloud Infrastructure Blog.

ここが変わった! VMware vSphere 6.5 Part5

$
0
0

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

今回は、vSphere 6.5でアップデートされたvSphere HAの次の3つの機能についてご紹介します。

  • Proactive HAの構成
  • ホスト障害への応答
  • 仮想マシンで許容するパフォーマンス低下

 

vSphere HAはvSphere基盤の可用性を提供する重要な機能です。運用に関わるエンドユーザー様を対象にトレーニングを実施してきた私には、追加された3つの機能はエンドユーザー様の声を反映したアップデートではないかという印象を受けます。

Enterprise Plusで提供されるDRSやサーバーのPluginが前提となる機能もありますから、ご提案時にはこれらの機能もふまえ、ご紹介いただけたらと思います。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆Proactive HAの構成◆

ホストを構成するハードウェアの障害により健全性が低下した時、どのように仮想マシンを保護するかを構成する機能がProactive HAです。

詳細には、ハードウェア障害の情報をProactive HAプロバイダからvCenter Serverが受け取り、vCenter ServerはProactive HAの構成内容をDRSへ知らせ、仮想マシンを移行します。

たとえばファンに障害が発生し健全性が低下した場合、仮想マシンの移行によって可用性が提供されます。Proactive HAプロバイダは、サーバーベンダーから提供されます。

 

<Proactive HAの有効化>

Proactive HAはvSphere HAの編集画面で、「Proactive HAをオンにする」を選択します。仮想マシンの移行(vMotion)により仮想マシンを保護するため、DRSの有効が前提となります。

<Proactive HAの構成>

構成には、「自動化レベル」と「修正」の2つがあります。「自動化レベル」では仮想マシンの移行方法を、「修正」では健全性が低下したホストの使用可否を指定します。

<自動化レベル>

「手動」と「自動化」があります。

  • 手動:DRSと同様に仮想マシンの移行先が推奨されます。
  • 自動化:仮想マシンは健全なホストに移行され、健全性が低下したホストは検疫モードまたはメンテナンス モードにしたがい使用の可否が決まります。 

<修正>

「検疫モード」「混合モード」「メンテナスモード」があります。

  • 検疫モード:一部のハードウェア(メモリ/ネットワーク/ストレージ等)の障害にともない、性能が低下したホストを使用しません。ただし、仮想マシンのパフォーマンスに影響がない範囲においてです。
  • 混合モード:検疫モードの状態に加え、重大な障害が発生したホストは使用しません。
  • メンテナンスモード:一部のハードウェアに障害が発生したホストは使用しません。

<Proactive HAプロバイダ>

ホストの健全性をチェックするには、サーバーベンダーが提供するProactive HAプロバイダが必要です。Proactive HAプロバイダに対応する vSphere Web Client プラグインをインストールすると、Proactive HAプロバイダが表示されます。プロバイダを選択後、Proactive HAプロバイダは有効になります。

※Proactive HAプロバイダ

HPEサーバーは、「OneView for VMware vCenter」を導入します。Proactive HAに対応するOneViewは2017年11月提供予定です。

Dellサーバーは、「OpenManage Integration for VMware vCenter」を導入します。

Proactive HAプロバイダの詳細については、各サーバーベンダーへお問い合わせください。

 

◆ホスト障害への対応◆

vSphere 6.5では、vSphere HAによる再起動のオーケストレーション(Orchestration)を設定することができます。再起動の優先順位と仮想マシン間の依存関係を構成することによって、より詳細な再起動の順序を指定することができます。

下図はクラスタの設定画面です。

仮想マシンは、次の条件を満たすと他のホストへの配置や再起動の準備が整います。

  • 他のホストに仮想マシンのリソースが予約されている
  • 仮想マシンはパワーオンしている
  • VMware Toolsのハートビートが検出される
  • VMware Toolsアプリケーションのハートビートが検出される

 

各仮想マシンの設定は、「設定」の「仮想マシンのオーバーライド」を使用します。設定対象の仮想マシンを追加します。

<仮想マシン再起動の優先順位>

優先順位は5つのレベルがあります。優先順位が高い仮想マシンを再起動後、次に優先順位が高い仮想マシンを再起動します。

ただし、次の場合は異なります。

  • エージェント仮想マシンは最初に起動する
  • vSphere FTのセカンダリ仮想マシンは、他の仮想マシンより優先される

<優先度が次に高い仮想マシンを次の場合に起動/遅延時間の追加>

依存関係は、再起動の優先順位と特定の条件に一致した場合の遅延時間で指定します。

「割り当てられたリソース」「パワーオン」「検出されたゲストのハートビート」「検出されたアプリケーションのハートビート」のいずれかの条件を満たした後、指定された遅延時間を待って、次に優先順位の高い仮想マシンを再起動します。

 

<または次におけるタイムアウトの発生後>

指定した条件が満たされない場合はタイムアウトになります。指定したタイムアウト値までに条件が満たされなければ、vSphere HAは次に優先順位の高い仮想マシンの再起動へ進みます。

 

<仮想マシングループ間アフィニティルールを利用した依存関係の構成>

依存関係を構成するには、仮想マシングループ間のルールを利用することもできます。

特定の順序で再起動しなければ正常に復旧しない複数層のアプリケーションには有効です。一般的な例として、DB>>App>>Webの3階層システムがあります。

たとえば、障害があったホスト上にDB仮想マシンとWeb仮想マシンが稼働し、障害のないホスト上でApp仮想マシンが稼働していたとします。vSphere HAはDBとWebの仮想マシンはフェイルオーバーしますが、Appの仮想マシンは再起動しません。このような状況を回避する方法として、仮想マシングループ間のルールを利用します。

ただし、このルールには、DBが再起動しなければAppは再起動しないという課題があります。その場合は、手動でDBの仮想マシンを起動します。

vSphere HAはホスト障害に対する可用性を提供する機能のため、このような課題は発生します。今後のさらなる改善が期待されます。

 

◆仮想マシンで許容するパフォーマンス低下◆

本題に入る前に、アドミッション コントロールの選択方法がわかりやすくなりましたね。

許容するホスト障害の台数を指定し、その後はフェイルオーバー時のリソース予約をするか否か、するのであれば3つのうちのどの方法で予約するのかという流れになっています。

さらに、クラスタのリソース使用率がフェイルオーバー キャパシティの割合を超えた場合、警告を表示する機能が追加されました。この機能は、クラスタリソースの使用状況を取得するために、DRSを有効にする必要があります。

 

下図のvSphere HAクラスタはESXiホスト2台で構成し、「クラスタで許容するホスト障害」を1台に設定しています。

フェイルオーバー リソースの自動計算により、CPU50%/メモリ50%がフェイルオーバーキャパシティとして予約されています。

「仮想マシンで許容するパフォーマンス低下」でしきい値を「0」%に設定すると、クラスタのリソース使用率がフェイルオーバーキャパシティを超えた時、クラスタの「サマリ」タブに下図の警告が表示されます。この警告によって、リソース不足によって仮想マシンが再起動されない状況を回避することができそうですね。

◆まとめ◆

vSphere HA 6.5で追加された機能は、「ESXiホストの障害時にあわてなくても大丈夫。追加機能を活用して可用性を高めましょう。」と言われたような気がしました。「備えあれば患いなし」という言葉が浮かびます!

「Proactive HA」および「仮想マシンで許容するパフォーマンス低下」はDRS機能を前提とするため、Enterprise Plusのライセンスが必要です。vSphere 6.5へUpgradeを検討されていらっしゃるエンドユーザー様は、運用の効率性も見据えてご検討いただければと思います。

次回は、vSphere DRSでアップデートされた機能をご紹介します。個人的にはvRealize Operations Managerと連携する「Predictive DRS」にとても興味があります。

予算が許されるなら、「vSphere with Operations Management (vSOM)」を検討したいですね!

 

The post ここが変わった! VMware vSphere 6.5 Part5 appeared first on Japan Cloud Infrastructure Blog.

Test

ここが変わった! VMware vSphere 6.5 Part 6

$
0
0

 

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

今回は、vSphere 6.5でアップデートされたvSphere DRSの次の機能をご紹介します。

  • Predictive DRSの有効化
  • その他のオプション
    • 仮想マシンの分散
    • ロードバランシングのためのメモリメトリック
    • CPUオーバーコミットメント

vRealize Operationsと連携し、予測メトリックに基づいてリソースをバランシングするPredictive DRSは、vRealize Operationsのさらなる活用がけん引できそうですね。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆Predictive DRS◆

Predictive DRSは、vSphere DRSとvRealize Operations (以降vROps) を連携し、仮想マシンの配置とリソースのバランスを決定する機能です。

vROpsは、履歴データに基づき、近い将来の仮想マシンの予測ワークロードを分析します。vROpsではトレンドとして表示されます。

vSphere DRSは、現在の使用値 (リアルタイムメトリック)に加え、予測ワークロード値(予測メトリック)にも対応し、仮想マシンからリソースが要求される前に、仮想マシンの配置を決定することができます。

 

Proactive DRSは、vSphere 6.5 + vROps 6.4以降の環境で使用できます。

下図の画面から、Predictive DRSを有効化します。

Proactive DRSはタイムリーな移行のために1時間前 (デフォルト) の値を使用します。

 

状況によって、移行を判断するメトリックが異なります。

<現在の使用率が予測使用率を上回る場合>

現在の使用率が優先され、この値を使用して推奨が生成されます。

 

<予測使用率が現在の使用率を上回る場合>

予測使用率の値が仮想マシンの現在のデマンドとして使用されます。このデマンド値を基に、仮想マシンからリソースが要求される前にリソースが利用できる状況にします。要求前に対応するため、パフォーマンスへの影響を軽減します。

 

◆その他のオプション◆

vSphere 6.5では次の3つのAdvanced Optionsが追加されています。

<仮想マシンの分散:TryBalanceVmsPerHost>

ESXiホスト間で仮想マシンの数を均等に分散します。

DRSにより1台のESXiホスト上に多くの仮想マシンが配置される場合があります。その状況でvSphere HAが動作した場合、分散された仮想マシンと比べ、多くの仮想マシンの再起動が必要になります。このような状況を回避する際に、仮想マシンの分散は有効です。

このオプションを設定すると、各ESXiホストにはロードバランシングmaxVMsの制限が与えられます。この制限は、ロードバランシングにのみ適用されます。

 

<ロードバランシングのためのメモリメトリック>

ESXiホスト上のメモリ負荷を計算する時、「有効なメモリ」ではなく「消費されたメモリ」メトリックを使用します。

オーバーコミットされている環境では有効なメモリが適しています。有効なメモリは、アイドルメモリの25%が加算され、負荷を計算します。

オーバーコミットされていない環境では、このオプションを選択し、消費されたメモリを使用してバランシングすることもできます。

 

※仮想マシンのメモリメトリック

「有効なメモリ」はゲストOSが使用している物理メモリ量、「消費されたメモリ」は仮想マシンによって使用されるゲスト物理メモリ量 (共有メモリのうち該当の仮想マシン分を含む) を表します。

<CPUオーバーコミットメント: MaxVcpusPerClusterPct>

クラスタ内で仮想CPUと物理CPUの比率を設定し、オーバーコミットを制御します。オプションで定義された値に達すると、追加の仮想マシンをパワーオンことはできません。

オーバーコミットメント率(最小0/最大500)は、次を参考にしてください。

  • 0-99% 1vCPU未満:1pCPU (コア) ※オーバーコミットしない
  • 100% 1vCPU:1pCPU (コア)
  • 500% 5vCPU:1pCPU (コア)

このオプションはクラスタが対象です。ESXiホストを対象とする場合は「MaxVcpusPerCore」で指定します。

 

 

追加機能ではありませんが、改良点をご紹介します。

◆DRS移行のしきい値

6.5では、移行のしきい値に従来のCPUとメモリに加え、物理NICの使用率が加わりました。

CPUとメモリの統計値から移行の可否を判断することに変わりはありません。初期配置および負荷分散のために移行先のESXiホストが選択されると、次にDRSはその移行先が最適かを判断するために、ネットワーク使用率をチェックします。

移行先のESXiホストに接続される物理NICの使用率が80% (デフォルト値) を超えていれば、最適な配置ではないと判断し、別のESXiホストを使用します。

ネットワーク使用率のしきい値は、「NetworkAwareDrsSaturationThresholdPercent」で変更します。

 

 

◆vSphere DRSに関する情報◆

vSphere 6.5のDRSについての詳細な情報は、こちらを参照ください。

こちらのBlogでは取り上げなかった、パフォーマンス向上のための改良点についても述べられています。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/drs-vsphere65-perf.pdf

 

アップデートされたDRSについては終了です。

 

 

ここからは、クラスタからESXiホストを削除する方法をご紹介します。

「メンテナンスモードにしなければクラスタからESXiホストを削除できないのですかと尋ねられることがあります。こちらで紹介する方法は、仮想マシンをシャットダウンできない場合にお試しください。可能なら、メンテナンスモードに移行後、クラスタから削除ください。

 

◆クラスタからESXiホストの削除◆

メンテナンスモードに移行せず、ホストをインベントリから除去すると、次のメッセージが表示されます。

ESXiホストをvCenter Serverから切断すると、メンテナンスモードに移行せず、ESXiホストをインベントリから除去することができます。

ESXiホストを右クリック→接続→切断と操作します。

次のメッセージの内容を確認の上、操作を進めてください。

切断後、インベントリの除去を行うと、次のメッセージが表示され、ESXiホストをクラスタから削除することができます。

ドラッグアンドドロップで、データセンター配下に置くこともできます。

◆まとめ◆

「ここが変わった! VMware vSphere 6.5」のすべての回が終了しました。

vSphereもバージョンが上がるたびに様々改善されていますね。今回取り上げた機能を使用すると、運用管理面が強化されるように思います。特にHAやDRSは、ホスト障害およびパフォーマンス低下に備えて、予防しましょうというメッセージを感じます。

今後は、HAとDRSの併用を前提に、構築設計していく必要があるのかもしれませんね。

また、「VMware Cloud on AWS」が発表され、Hybrid Cloud環境がけん引されそうですね。vRealize製品も注目を集めそうです。機会がありましたら、vRealize製品のBlogも投稿できたらと思います。

 

The post ここが変わった! VMware vSphere 6.5 Part 6 appeared first on Japan Cloud Infrastructure Blog.

エンタープライズ クラスのKubernetes導入を実現するPivotal Container Service(PKS)

$
0
0

著者:製品ライン シニア マネージャ ナラヤン・マンダレーカ(Narayan Mandaleeka)/製品管理担当副社長 ポール・ダル(Paul Dul

米国時間2017年12月7日に公開されたブログ記事の抄訳です。

https://blog.cloud.vmware.com/s/content/a1y6A000000aG0KQAU/deploy-enterprisegrade-kubernetes-with-vmware-pivotal-container-service-pks

 

VMwareとPivotalは、エンタープライズ クラスのKubernetesソリューションを求める顧客向けに、12月中旬にPivotal Container Service(PKS)の提供を開始します。PKSはKubernetesの活用を望む企業やサービス プロバイダ向けの製品で、Kubernetesクラスタの導入や運用を大幅に簡素化します。PKSはVMware vSphere®で稼動するデータセンタやGoogle Cloud Platform(GCP)に導入可能で、最近ではCloud Native Computing Foundationが主催するKubernetes Software Conformance Certificationプログラムの認証を取得しました。

PKSの主な特長は以下の通りです。

  • 最新のオープンソース版Kubernetesに対応:PKSの初版リリースではKubernetes 1.8をベースにしており、開発者は独自の拡張設定を行わずにKubernetes APIにフル アクセス可能
  • 高度なコンテナ向けネットワークとセキュリティ:マイクロセグメンテーション、負荷分散、セキュリティ ポリシーなどの機能を備えたNSX-Tにより、Pod単位のコンテナ向けネットワークを実現
  • 安全性に優れたコンテナ レジストリ:脆弱性スキャンに加え、イメージへの署名や監査といった機能によりコンテナ ワークロードを保護
  • 迅速なプロビジョニング:開発者が迅速かつオンデマンドでKubernetesクラスタを作成可能
  • 高可用性:PKSが高可用性を備えており、インフラからアプリケーションまでのKubernetesクラスタを監視/管理することで高可用性を実現
  • GCPサービスを利用可能:GCPサービス ブローカーとの連携により、開発者はGCPサービスに簡単にアクセス可能
  • パーシステント ストレージ:ステートレス/ステートフルなアプリケーションの両方をKubernetesクラスタに導入可能

図 1: Pivotal Container Service

 

ネイティブなKubernetes APIを使用したマルチクラウド環境向けに開発されたPKSは、Google Kubernetes Engine(GKE)との互換性を維持しながら主要なKubernetesリリースをベースに開発されているため、開発者は最新かつ安定性に優れたKubernetesリリースを利用可能です。PKSは導入初日から運用開始までの課題をCloud Foundry Container Runtime(CFCR)を活用することで解決できます。このCFCRは、以前はKubernetesの運用支援ツールBOSH(またはKubo)として知られていたものです。BOSHにより、PKSは自動化やオーケストレーションの機能を活用してKubernetesクラスタの導入を簡素化できるだけでなく、高可用性と本番環境での導入に向けて、基盤となるインフラのヘルスチェックと自己修復などの機能を提供します。

 

BOSHを活用してKubernetesクラスタに必要なネットワーク設定全体を自動化することで、パフォーマンスの問題や、さらにはセキュリティ ホールの発生など、マニュアル設定により発生するエラーのリスクを排除できます。

 

NSX-Tを使用したネットワーク

PKSにはVMware NSX-Tが含まれており、Kubernetesクラスタのための高度なコンテナ ネットワークやセキュリティの機能を備えています。NSX-Tは、レイヤ2からレイヤ7までの、コンテナ/Pod単位のネットワークに必要とされる完全なネットワーク サービス群を提供します。これにより、企業は開発サイクルを中断することなく、マイクロセグメンテーションやオンデマンドのネットワーク仮想化によって素早くネットワークを導入できます。

 

またPKSにより、IT部門はCNCF認証のフルスタックのKubernetesコンテナ サービスを提供可能になります。このサービスにはネットワークやストレージのサービス、安全性に優れたコンテナ レジストリ、そしてサービス ブローカー機能などが含まれます。さらに、VMware vSAN™、VMware vRealize® Operations™、Wavefront® by VMwareをはじめとするVMwareのインフラ製品や管理製品とのカスタム統合も可能です。

PKSはライセンス付与、本番環境対応、VMware NSX-Tとの緊密な連携も可能です。

Pod単位のネットワーク、サービスへのアクセス、複数のレプリカの負荷分散など、NSX-TはKubernetesに必要なあらゆるネットワーク機能を提供します。Kubernetesの基本的なネットワーク機能に加えて、NSX-Tの多層ルーティング モデルを使用することで、ネットワーク セキュリティ ポリシーやテナント レベルでのアイソレーションなどの高度なネットワーク機能を実現します。

NSX-TをPKSと統合する際の重要な設計コンセプトの1つが、Kubernetesの各ネームスペースに固有の論理スイッチを割り当てることです。これによってKubernetesクラスタの各ネームスペースのトラフィックをセグメント化できるようになります。開発チームは、共有クラスタ内で専用Kubernetesネームスペースを使用して、他のチームからワークロードを確保できます。

図 2: NSX-Tはネットワークのアイソレーションと負荷分散機能を備えたPodネットワークを提供

安全なコンテナ レジストリ — Harbor

Harbor は、コンテナ イメージを格納/配布するオープン ソースのエンタープライズ クラスのレジストリ サーバです。本番環境の認証とロール(役割)ベースのアクセスにより、プッシュおよびプル イメージを提供します。また、統合的な脆弱性スキャン、イメージ信頼サービス、イメージ レプリケーション サービスなどの主要なレジストリ サービスも提供します。

 

Harborを利用することで、アプリケーション導入のためのコンテナ イメージを安全にKubernetesクラスタにダウンロードできます。HarborのレジストリはCI/CDパイプラインで本番環境レベルのイメージ リポジトリを可能にします。顧客は、アプリケーション リリースの自動化プロセスの一環として、コンテナ イメージを安全にHarborに取り込めます。これらのイメージに対し、アプリケーションのワークロード導入プロセスの一環としてHarborが脆弱性スキャンを実行し、署名承認を行った後にKubernetesクラスタに取り込むことが許可されます。

 

その結果、開発チームはアプリケーションをプラットフォームに迅速に導入し、IT部門は企業のセキュリティ要件を確実に満たすようにコンテナ イメージをコントロールできます。

図 3: Harborは、PKSが管理するKubernetesクラスタにイメージを導入するために使用される

Harborの統合コンテナ レジストリの使用を推奨しますが、PKSはそれ以外のコンテナ レジストリも使用可能です。

パーシステント ストレージとvSphere Cloud Providerプラグイン

PKSなら、Kubernetesクラスタをステートレス/ステートフルのどちらのアプリケーションでも展開可能です。Project Hatchwayを通じて、KubernetesではVMware vSphere Storage for Kubernetesプラグインをサポートしているため、PKSはVMware vSphereストレージ上でKubernetesストレージ プリミティブに対応しています。ストレージ プリミティブには、ボリューム、パーシステント ボリューム、パーシステント ボリューム クレーム、ストレージ クラス、ステートフル セットが含まれます。また、ストレージ プラグインはエンタープライズ クラスのストレージ機能も備えています。例えば、VMware vSANを使用することで、Kubernetesクラスタで実行しているアプリケーションに対して、ストレージのポリシー ベースの管理を拡張できます。

 

GCPサービス ブローカー

PKSには、GCPサービスにすぐにアクセス可能なサービス ブローカーが含まれています。サービス ブローカーを活用することで、運用者は選択したGCPサービスを公開し、開発チームがkubectl CLIまたはAPIで「サービス インスタンス」を作成および管理することで、GCPサービスをプロビジョニングして使用できるようになります。GCPサービス ブローカーは、Google Cloud Storage、Google BigQuery、Google StackdriverなどのGCPサブスクリプション サービスにも対応しています。これらのサービスは、オンプレミスまたはGCP内で実行しているアプリケーションで使用することも可能です。

 

PKSのサポート

PKSのユーザは本番環境レベルのサポートを受けることができます。PivotalとVMwareは、世界レベルのグローバル サポート サービスの提供を通じて、最も要求の厳しい本番環境のニーズに応えます。

注:PKSの利用にはVMware vSphere 6.5が必要です。

 

Pivotal Container ServicePKS)に関する詳細情報(英語)

Pivotal Container Serviceに関する詳細は、以下をご覧ください。

https://cloud.vmware.com/pivotal-container-service

 

NSX-T 2.1リリースに関する詳細は、以下をご覧ご確認ください。

http://blogs.vmware.com/networkvirtualization/2017/11/nsx-t-2-1.html/

 

Pivotal Cloud Foundry 2.0に関する詳細は、以下をご覧ご確認ください。

https://content.pivotal.io/announcements/pivotal-unveils-expansion-of-pivotal-cloud-foundry-and-announces-serverless-computing-product

The post エンタープライズ クラスのKubernetes導入を実現するPivotal Container Service(PKS) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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

 

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

 

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

 

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

 

◆はじめに

 

はじめして! シュナイダー エレクトリック APC UPS 管理製品担当 出口 (右) & 冨田 (左) です。

最近 IT業界全体で注目度の高い ハイパーコンバージドインフラ ( 略して HCI ) の代表的な製品 VMware vSAN と弊社 UPS 管理製品 PowerChute がシャットダウン連携できるようになりました。

 

vSAN を導入することで運用負荷やコストを下げられるというメリットを感じて導入を検討される方も多いとは思いますが、やはり 電源障害や停電対応にも対応した UPS がないと不安で導入できないという方もいらっしゃると思います。

 

ご安心ください!!既に連携ができます!! 

 

今回のブログでは、どのような構成がサポートされて、どのような仕組みで VMware vSAN & シュナイダー ( APC ) UPS 連携ができるのかをご紹介いたします!!

 

1.UPS と vSAN のシャットダウン連携のサポート構成

APC UPS では 以下に挙げる構成パターンで vSAN との連携が可能です。

 

[パターン1]

物理 Windows サーバー にPowerChute Network Shutdown ( 略 PCNS )と、Windows 版 vCenter Server をインストールするパターン

この構成は、Windows 版 vCenter Server に PCNS や他の管理系ソフトウェア(バックアップ、監視など)を同居させる場合にピッタリの構成パターンとなっています。

 

[パターン2]

vSAN クラスタ上に vCenter Server Virtual Appliance ( 略 VCSA ) をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に構成するシンプルなパターンで、Dell EMC 社 の VxRail に代表される vSAN を基盤とした HCI アプライアンスを導入される方にピッタリの構成パターンとなっています。

 

[パターン3]

vSAN クラスタとは異なる ESXi サーバー上に VCSA をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に配置しないで構成します。vCenter Server のような管理系のサーバーを vSAN クラスタとは異なる環境で構成したい方や、複数のシステムをやクラスタを vCenter Serverで統合管理されている方にピッタリの構成パターンとなっています。

 

これだけのパターンが網羅されていればどんな環境でも安心して vSAN を導入できますね (^^♪

2.vSAN 連携させるために必要なもの

各パターンごとにおける 必要なコンポーネントと機器サンプルは以下の通りです。
詳細な電源容量の計算などは次回のブログでご紹介します!!

[構成パターン1および2で必要なコンポーネント]

Smart-UPS 1500 RM 2U LCD (SMT1500RMJ2U)   ・・・・・・・・・・・・ 1

Network Management Card (AP9630J)    ・・・・・・・・・・・・・・・・ 1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J)   ・・・・・  4

 

[構成パターン3で必要なコンポーネント]

Smart-UPS X 3000 Rack/Tower LCD (SMX3000RMJ2U) ・・・・・・・・・  1

Network Management Card (AP9630J) ・・・・・・・・・・・・・・・・  1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J) ・・・・・  5

 

3.vSAN 連携時のシャットダウンシーケンス

シャットダウン時の流れは以下の様になります。

 

4.参考リンク

すでに vSAN を導入されている方も、これから導入を考えている方もぜひ、電源管理は シュナイダー UPS にお任せください!!

次回のブログでは「電源容量と耐久時間」や「製品の選び方のポイント」についてご紹介いたします。

では次回を乞うご期待ください!!

 

[vSAN & シュナイダー UPS 連携のKB (シュナイダー社リンクへ飛びます)]

PowerChute Network Shutdown の vSAN対応について

アプリケーションノート:PowerChute Network Shutdown for VMware

The post シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! appeared first on Japan Cloud Infrastructure Blog.


ちょっとした技術的な TIPs のご紹介 (2017.12)

$
0
0

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いております SE の北村です。
今回は、Cloud Infrastructure Blog に次の 3点について投稿したいと思います。

 

1. NSX Recommended Configuration Maximums (NSX 推奨構成の上限)
2. 3種類の新しい VMware NSX の本を発表!
3. VM Encryption と vSAN Encryption がサポートする KMS (Key Management Server) について

では、それぞれについて記載していきます。

 

1. NSX Recommended Configuration Maximums (NSX 推奨構成の上限)

vSphere では以前から公開されている “構成の上限 (Configuration Maximums)” ですが (こちら。PDF版はこちら)、NSX 6.3.3 から NSX Recommended Configuration Maximums という事で、PDF版が公開されました (こちら )。

以下に「1 Introduction」の内容を意訳してみました。ご参考まで。

1 イントロダクション
このドキュメントでは、NSX for vSphere の推奨構成の上限 (最大値) を示しています。 この文書を使用して製品の設計、導入、操作する場合は、次の点を考慮してください。

  • 仮想および物理機器を選択して構成する場合は、このマニュアルで説明するように、NSX for vSphere でサポートされている上限以下に留めることを強くお勧めします。
  • 次のセクションで示される制限は、テスト済みの推奨限度を表し、VMware が完全にサポートしています。
  • このガイドに記載されている制限は、NSX for vSphere に適用されます。 この制限は、ハードウェアの依存関係などの他の要因の影響を受ける可能性があります。 サポートされるハードウェアの詳細については、適切な NSX for vSphere のインストールおよび管理ガイドを参照してください。 ご使用の環境でサポートされている構成を超えないように、個々のソリューションの制限を調べてください。
  • 全ての構成設定を最大化しても、望んでいる結果を期待する事は出来ないかもしれません。
  • 推奨構成の上限は、NSX for vSphere の規模の理論上の可能性を表すものではありません。

 

2. 3種類の新しい VMware NSX の本を発表!

お伝えそびれていた情報になりますが、今年の VMworld U.S. 2017 に合わせて、次の 3種類 (4つ) の NSX 本 (英語の本です) を発表してまして、こちらのサイトから PDF 版を入手できます。ご興味がある方は、是非、ダウンロードしてください。

 

3. VM Encryption と vSAN Encryption がサポートする KMS (Key Management Server) について

vSphere 6.5 では、仮想マシンや仮想ディスクの暗号化機能 (詳細はこちら) が提供されていますし、vSAN 6.6 でも vSAN データストア内の全てを暗号化する機能 (詳細はこちら) が提供されています。

今回は、個々の機能説明はしませんので、詳細はそれぞれリンクされているドキュメントを参照してください。

今回お伝えしたいのは、それら新しい機能として提供されている暗号化ですが、VM Encryption も vSAN Encryption、いずれの機能も外部 KMS が必要です。では、これらの機能がサポートしている KMS をご存知でしょうか? 実は上記でリンクしたドキュメント内にはサポートする KMS についての詳細は記載されていません。それらは、HCLで公開されていて、以下からアクセスできます。

1) HCL <https://www.vmware.com/go/hcl> にアクセス

2) 検索カテゴリのプルダウンメニューから “Key Management Server (KMS)” を選択

3) VM Encryption、vSAN Encryption (vSAN Data at Rest Encryption) でサポートされている KMS 製品を確認

 

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

 

 

The post ちょっとした技術的な TIPs のご紹介 (2017.12) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

こんにちは。VMware でパートナー様を担当させて頂いております SE の北村です。

昨年の2月から前回まで、「ちょっとした技術的な TIPs のご紹介」 という事で、Cloud Infrastructure Blog や End User Computing Blog にブログを投稿させて頂きましたが、今回からは今までと少し趣向を替えながら、みなさまのお役に立てる情報をお伝えしていきたいと思いますのでよろしくお願いします。

 

現在 (2018年2月8日)、Horizon は 7.4 というバージョンが提供されていますが、約 1年前の 2017年3月16日にリリースされた Horizon 7.1 から提供している JMP (Just-in-time Management Platform:「ジャンプ」 と読みます) という機能ご存知でしょうか?

参考情報:プレス リリース
ヴイエムウェア、新たなアプリケーションとデスクトップ仮想化製品により、デジタル ワークスペースの変革を加速

 

JMP テクノロジーは、Horizon 7 Enterprise Edition の機能を使い、パーソナライズされたデスクトップとアプリケーションを、柔軟、かつ、高速に提供する仕組みになりますが、その JMP は次のVMware テクノロジーで構成されています。

VMware Instant Clone:迅速なデスクトップおよび RDSH プロビジョニング
Instant Clone 機能は、vSphere vmFork テクノロジー (vSpehre には 6.0 Update 1 から実装) を活用して、実行中の親仮想マシンの静止、高速メモリ内クローニング、コピーオンライト (Copy-On-Write:書き換え時にコピーする方式) を使用して、仮想マシン (仮想デスクトップ、または、RDSH サーバ) を迅速に展開します。

VMware App Volume:リアルタイムでのアプリケーションの配信
App Volumes は、アプリケーションをオペレーティング システム (OS) から切り離し、仮想マシンに配信することで、アプリケーションのプロビジョニング工数を大幅に削減し、App Volumes Manager による一元的な管理を実現します。

VMware User Environment Manager:ユーザー、プロファイル、ポリシーの管理
Horizon のスマートポリシー機能を実現するために必須のコンポーネントでもあり、仮想/物理環境、および、クラウド ベースの Windows デスクトップ環境全体にパーソナライゼーションと動的なポリシー設定を提供します。

これらのテクノロジーを活用する事で、パーソナライズされたデスクトップやアプリケーションを高速に展開する仕組みとして期待されています。

 

ここで、セキュリティについて考えたいと思いますが、Horizon の仮想デスクトップのセキュリティ向上を考えた場合、VMware NSX for vSphere と、セキュリティ ソフトウェア ベンダー様のアンチウィルス ソフトウェア製品との連携ソリューションであるマイクロセグメンテーションがあります。

今まで、Horizon の Composer を使用して展開された仮想デスクトップのセキュリティの向上には、マイクロセグメンテーションを利用していたと思います。この形態は今後も引き続き利用されていくと思いますが、更に、JMP テクノロジーの構成要素の 1つである Instant Clone を使用した、柔軟、かつ、高速に展開された仮想デスクトップや RDSH サーバのセキュリティ向上にもマイクロセグメンテーションを利用していく事が考えられます。

 

そこで、次回 (来週を予定) からトレンドマイクロ株式会社の栃沢様に、【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】 というタイトルで数回にわたりブログを掲載頂きます。

最初となる次回は、「Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策」 というテーマでブログを掲載頂きますので、お楽しみに!

 

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

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

以上です。

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(0) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。今回からVMware様のJapan Cloud Infrastructure Blogの場をお借りして、VMware vSphere、NSX、Horizonを利用した環境でのTrend Micro Deep Securityの活用方法や連携について掲載をさせていただくことになりました。いかにセキュリティを担保していくのか?そのテクノロジーにはどういったものがあるのか?という点を中心にお伝えしていければと思います。

初回となる今回は、最近よく質問をいただくご質問にお答えしたいと思います。
「VMware vSphere/NSX+VMware Horizonの環境でインスタントクローン方式による仮想デスクトップの展開を行った場合、Deep Securityのエージェントレス型セキュリティ対策は使えないの?
Deep Securityはインスタントクローン方式では使えない?といったことをお聞きになっていた方もいらっしゃると思います。実際にインスタントクローン環境でDeep Securityを利用するという場合には制約事項があります!といったお話をしていました・・・

ところが!Deep Securityの新しいバージョンをご利用いただくとインスタントクローン方式で展開した仮想デスクトップ環境でもDeep Securityによるエージェントレス型セキュリティ対策がご利用いただけるようになりました。
みなさんにとってご理解しづらかった点を含めて、今回は紐解いていきたいと思います。

 

Deep Securityがエージェントレスでセキュリティ保護できる仕組み

まず、Deep Securityがエージェントレスで仮想デスクトップ(仮想マシン)を保護できるプロセスをおさらいしておきましょう。このプロセス、連携の仕組みを理解頂くことで全体像をご理解いただくことができると思います。

Deep Securityでエージェントレス型セキュリティ対策(ここでは不正プログラム対策を利用することを前提で記載していきます)を利用するためには以下の環境が必要となります。

  • VMware ESXi/vCenter
  • VMware NSX (NSX Manager / Guest Introspection)
  • Deep Security Manager(DSM)
  • Trend Micro Deep Security Virtual Appliance(DSVA)
  • VMware Tools(保護対象仮想マシンに導入)

そして、構成上重要になってくるのが、管理マネージャ群の連携です。vCenterとNSX Managerは1:1でコネクションを張ります。そして、DSVAを管理するDeep Security Manager(DSM)もvCenter、NSX Managerそれぞれとリアルタイムに同期を行うためのコネクションを張っています。

 

このvCenter – NSX Manager – DSMの連携によって、仮想マシンがどのESXiホスト上にいるのか、NSXのどういったセキュリティポリシーを適用するのかをといった情報をやりとりが可能となっています。仮想デスクトップ環境では、仮想デスクトップが生成されてからDeep Securityによってセキュリティ保護が完了するまでに以下のようなプロセスが発生します。

 

Horizon Connection Serverが仮想マシンの生成をトリガー

vCenterがそのリクエストに応じてマスターイメージから仮想デスクトップ(子仮想マシン)を生成

DSMがvCenterから新たに生成された仮想デスクトップの情報(仮想マシンの属性情報、配置されたESXiホストの情報など)を元にセキュリティポリシーを適用

 

ここで押さえておいていただきたいポイントは、Deep SecurityはあくまでvCenterから情報を取得しており、Horizon Connection Serverとは直接連携していない、という点です。言い換えると、Deep SecurityはvSphere/NSXとの連携が前提となっているため、Horizonの展開方式には依存せず、対応は可能な仕様になっているということです。(PowerShellやHorizon以外での仮想デスクトップの展開でもDSVAの利用が可能)。

 

インスタントクローンを利用する上で抑えておくべきポイント

今までDeep Securityをインスタントクローン方式の環境では導入を推奨できなかったのは、Deep Securityが「インスタントクローンに対応していなかった」のではなく、「インスタントクローンで生成される仮想マシンのスピードに追いつくことができなかった」というのが正確な表現になると思います。

インスタントクローン方式で同時に生成される台数がそれほど多くなければ問題はありませんでしたが、検証によって数百台単位で仮想デスクトップが「高速に」生成されることになった場合にDeep Securityのセキュリティの有効化処理が追いつかないケースが確認されたため、推奨しないというメッセージを出しておりました。(実際の環境では、Horizon Connection ServerからvCenterに対して同時に仮想マシンを生成できる上限がデフォルトでは制限されておりますので、100台単位で有効化処理が走ることは少ないと思いますが。)
このような背景がありましたが、今回、Deep Securityの新しいビルドで有効化処理がより効率的に処理ができることを確認できました。また、それに加えてチューニングやサイジングの見直しを頂くことで対応することも可能ですので、その方法を以下にご案内します。

 

【利用頂くことを推奨するDeep Securityのバージョン】

  • インスタントクローン方式を採用する環境では、Deep Security 10.0 Update5以降をご利用ください。

【サイジング・チューニングのポイント】

  • DSMに対するvCPUの割り当てを追加する(ジョブはCPU処理能力に依存)
    • DSMサーバに対するvCPUの追加
    • DSMサーバの増設(Multi DSM構成)
  • CPU処理能力を向上させるためのパフォーマンスプロファイルの変更
    • ジョブ処理を行える上限設定を明示的に引き上げるプロファイルをご用意しています。
      パフォーマンスプロファイルについては以下をご参照ください。
      https://help.deepsecurity.trendmicro.com/ja-jp/Reference/ref-performance.html?Highlight=パフォーマンスプロファイル
      CPU処理能力を向上させるためのパフォーマンスプロファイルは以下のFAQからダウンロードが可能です。
      http://esupport.trendmicro.com/solution/ja-JP/1119051.aspx
      ※パフォーマンスプロファイルについては、ソフトウェアの健全な動作担保のため、パフォーマンスプロファイル内のパラメータをお客様にて変更いただくことはお控えください。

 

まとめ

Deep Security 10.0 Update5以降をご利用いただくことによって、VMware vSphere/NSX+VMware Horizonの環境でインスタントクローン方式による仮想デスクトップの展開を行った場合にDeep Securityのエージェントレス型セキュリティ対策が安定してご利用いただけるようになりました。もちろん、引き続きフルクローン、リンククローン環境でのご利用も可能ですので、ぜひご活用ください。

 

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

 

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

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(1) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

VMware NSX+Deep Secuirty 連携によるエージェントレスセキュリティとは?

 

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。前回は最近よくお問い合わせを頂いていたVMware vSphere/NSX+VMware Horizonの環境でインスタントクローン方式による仮想デスクトップの展開を行った場合にDeep Securityがどのように対応ができるのか?ということを解説しました。
ただ、そもそもDeep SecurityとVMwareソリューションってどのように連携するの?それってどんなことがうれしいの?実際にどういった仕組みで連携しているの?といった点をご存じない方も多くいらっしゃると思います。また実際に設計、構築、運用をされるパートナー様、ご利用いただいているユーザ様にも改めてその魅力や仕組みを知って頂きたいと思っています。
そこで、今後何回かに分けて、そのメリットや仕組みについてお伝えをしてきたいと思います。

今回はまずDeep Securityにより解決できる課題とその特徴、VMware NSXと連携によるメリットを概観していきたいと思います。

 

システム管理者が抱えるインフラ管理におけるセキュリティ課題

仮想化技術の向上により、今や企業、公共団体など幅広い業種においては、サーバ仮想化はいまや当たり前のものとなっています。クラウドサービスの急激な浸透の背景にも仮想化技術を生かしたインフラが大きく貢献をしています。当然のことながら私たちも含めたエンジニアにとっても仮想化技術はもはや「基礎技術」といっても過言ではなくなっており、今はストレージ、ネットワークの仮想化やコンテナなどの採用が進みつつあります。そのような中で現在のインフラ管理を担当するシステム管理者が抱えている課題としては以下のようなものが挙げられると思います。

  • サーバの集約率をあげた場合にアプリケーション、ユーザの業務パフォーマンスに影響を与える可能性がある(ウイルス検索の負荷など)
  • 最新のセキュリティアップデート、パターンファイルの適用確認作業といった管理が煩雑
  • サーバリソースの有効活用は可能となったが、それに伴うネットワークリソースの最適化、セキュリティポリシーの追随ができていない(それぞれの運用を個別に行う必要がある)
  • パブリッククラウドを含めたマルチクラウドを意識した統一したセキュリティ運用の仕組みが考慮されていない(オンプレミス環境とクラウド環境を分けて考える)

こういった課題は単にセキュリティをどのように担保するかということに留まらず、インフラ全体の運用を見据えて解決をしていく必要があります。

 

Deep Securityが採用される理由

Deep Securityは、OSにセキュリティソフトウェアとして導入するDeep Security Agent(DSA)とVMware vSphere/NSXと連携するDSVAの2つの防御コンポーネントを利用してサーバ保護から仮想デスクトップ保護までを一元的に提供することが可能なソリューションです。Deep Securityは上記のようなインフラシステムにおける課題を解決できるセキュリティパッケージとして幅広いお客様にて利用をいただいており、採用されている理由としては以下のようなことが挙げられます。

  • エージェント型、エージェントレス型の防御コンポーネントを利用することにより、システム環境に応じて仮想マシンのリソースに影響を最小限にとどめつつ、仮想サーバのセキュリティを担保できる
  • システムに応じた適切なセキュリティポリシーの適用と、最新のセキュリティアップデート、パターンファイルの適用を仮想マシン単位で統合管理ができる
  • さまざまなインフラ環境と連携することによりサーバ、ネットワーク環境の変化に自動的に追随してセキュリティ対策を継続できる
  • オンプレミス、クラウドに限らず、マルチクラウド環境で統一したセキュリティ運用が実現可能

昨今のITシステムにおいて「セキュリティ」を考えない、ということはもはや難しい状況となっている中で、さまざまなセキュリティ課題に対してDeep Securityを有効活用いただくことで解決の道筋をつけていただいています。

また、特徴的なのはVMware vSphere環境においてDeep Securityを利用する場合は、VMware NSXとの連携により仮想マシンにエージェント型ソフトウェアを導入する必要のないエージェントレス型によるセキュリティ実装も選択可能なことです。ここ数年、仮想デスクトップ(VDI)を採用される企業、公共団体なども増加してきており、特にこの領域ではDeep Security Virtual Appliance(DSVA)によるエージェントレスセキュリティが多く採用されています。

では、Deep SecurityとVMware vSphere/NSXの連携によるメリットはどのようなところにあるのでしょうか?

 

Deep SecurityとVMware vSphere/NSX連携のメリット

Deep SecurityとVMware vSphere/NSXの連携のメリットは大きく3つ上げられます。

  1. 仮想マシンにエージェントを導入することなく、セキュリティ対策が提供できる(エージェントレス型セキュリティ)
  2. VMware NSXセキュリティポリシーとDeep Securityポリシーの連携(インフラシステムと連動したセキュリティ運用の統一)
  3. Deep SecurityイベントをトリガーとしたNSX分散ファイアウォールによる仮想マシンの自動隔離(セキュリティインシデント発生時の一次対処の自動化)

それぞれのメリットを簡単に見ていきましょう。

 

1) エージェントレス型セキュリティ

エージェンレスでのセキュリティ実装を行う場合には、各ESXiホストに対して1台のセキュリティ専用アプライアンスとしてDeep Security Virtual Appliance(DSVA)を配置します。
DSVAは、VMware vSphere/NSX及び仮想マシン側に導入するVMware Toolsと連携をします。(詳細については次回以降解説していきます。)

エージェントレス型セキュリティ対策を導入することによって、以下のような効果を期待することができます。

  1. 仮想デスクトップ環境の統一的なセキュリティの確保(DSVAにて仮想マシン毎のセキュリティポリシーを管理)
  2. セキュリティチェックの簡素化と運用負荷の軽減(最新のセキュリティアップデート、パターンファイルはDSVAにのみ配信)
  3. セキュリティ機能の負荷をDSVA(=セキュリティ専用アプライアンス)に集約させることによる仮想デスクトップの集約率向上とそれに伴うコスト削減
  4. セキュリティ機能を仮想デスクトップから切り離すことによるユーザ利便性の向上とアプリケーションへの影響の提言(セキュリティ機能を意識せずに業務を実施可能)

特に昨今の仮想デスクトップ環境では、仮想マシンの展開にフルクローン、リンククローン、そしてインスタントクローン方式などニーズに応じてさまざまな方式が採用されるようになりました。動的に仮想マシンが生成されるケースも多いため、パターンファイルやルールを保持するソフトウェアエージェントを導入する必要のないDSVAによるエージェントレス型セキュリティ対策は、マスターイメージの維持、運用などの負担を減らすことができ、セキュリティ面のみならず日々の運用の観点からもメリットのあるソリューションとなっています。

 

2) インフラシステムと連動したセキュリティ運用の統一

Deep Securityを管理するDeep Security Manager(DSM)は、vSphere環境を管理するvCenter、NSXサービスを管理するNSX Managerと連携をすることができます。DSMはESXiホスト、仮想マシンの情報をリアルタイムで同期するとともに、vCenter Server/NSX Managerに対してDeep Securityが保持しているポリシー情報を提供しており、仮想マシンの生成、削除、DRS/vMotionによるホスト間の移動などの仮想インフラ側の変化に対しても予め設定されたDeep Securityのポリシーをシームレスに適用していくことが可能となっています。仮想マシンの状態に応じてセキュリティポリシーを自動的に適用できることにより、インフラ運用とセキュリティ運用の統合を実現できます。

 

3) セキュリティインシデント発生時の一次対処の自動化

DSMにてある仮想マシンでセキュリティイベントが検出された際にNSXセキュリティタグを付与するオプションを設定しておくことにより、Deep Securityのイベントをトリガーとして該当する仮想マシンの属性(所属するセキュリティグループ)であるセキュリティタグによって変更することによって、適用されるファイアウォールポリシーを変更することが可能となります。(詳細の動作仕様については次回以降解説していきます。)

 

Deep SecurityとVMware vSphere/NSX連携を利用するには

DSVAによるエージェントレスでのセキュリティ機能を利用する場合には、VMware NSXのコンポーネントと連携をする必要があることはすでにお話をしました。NSXのライセンスによってDSVAで提供することができるセキュリティ機能が異なりますので、押さえておいていただければと思います。

上記の表は、縦軸にNSXライセンス、横軸にDeep Securityの機能を記載しています。
※コンバインモードについては別途このブログの中でも触れる機会を設ける予定です。概要についてはFAQをご参照ください。

ここで抑えておいていただきたいポイントをいくつか挙げておきます。

  • NSX for vShield Endpointは、NSXライセンスをアクティベートすることなくNSX Managerをデプロイする形態となるため、NSXライセンスがなくてもDSVAによる不正プログラム対策だけであれば提供可能(ポリシー連携などの機能は使えないが、Deep Securityのイベントベースタスクを利用することで代替可能)
  • DAVAによるWebレピューテション、侵入防御、ファイアウォールを利用したい場合は、NSX Advanced 以上のライセンスが必要
  • vCloud Network and Security(vCNS/vShield Endpoint)を利用しているお客様もこちらに移行することが可能
  • DSVAによるエージェントレス型セキュリティ対策は、VMware vSphere /NSX環境であれば、どのような仮想デスクトップの展開方式でも利用可能

 

まとめ

VMware vSphere/NSX とDeep Securityを組み合わせることによって、仮想インフラのメリットを損なわずセキュリティを担保していくことが可能となり、運用性を高めていくことが可能であることをご理解いただけたのではないかと思います。また、エージェントレス型セキュリティの採用により、セキュリティ機能によるユーザ作業、アプリケーションのパフォーマンス影響を避けることができることも可能となります。

次回以降、VMware vSphere/NSX+Deep Security連携ソリューションがどのような仕組みで実現をしているのか、それをどういった形で利用できるのかなどを紹介していきたいと思います。

 

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

 

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

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
  2. VMwareNSX+Deep Secuirty連携によるエージェントレスセキュリティとは?

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(2) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成

 

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。前回はDeep SecurityをVMware NSXと連携した際のメリットについてご紹介をしましたが、3回目となる今回は、VMware NSXとDeep Securityの連携によるエージェントレスセキュリティを実現するために必要なコンポーネントとその基本構成について解説していきたいと思います。ネットワーク、サーバの設計、構築を担当されているエンジニアの皆様には見慣れない用語も出てくるかもしれませんが、VMware vSphere とNSXの関係、そしてDeep Securityとの連携のポイントを把握する上で、アーキテクチャを正しく理解することは重要となりますので、しっかり抑えていただきたいと思います。

 

VMware コンポーネント

まず、システムの基盤となるVMware vSphere のコンポーネントです。

  • ESXi(ハイパーバイザ)
    ESXi は ハイパーバイザ型仮想化ソフトウェアのことであり、ホスト OS の代わりにハードウェア上で直接動作し、ESXi 上でゲスト OS を複数台動作させることが可能です。(もはや解説は必要ないですね。)
  • vCenter Server
    vSphere 環境において、各ESXiホスト、仮想マシンの管理、機能の有効化・リソース監視などの統合管理を実現します。管理者は vCenter からホスト や仮想マシンの状態をリアルタイムに確認し、仮想マシンのデプロイやスマップショットの取得、バックアップ等も実行することができます。
    Deep Securityはインベントリ情報などの多くの情報をvCenter Serverとのリアルタイム同期によって取得をしていますので、必ずvCenter Serverとの接続性が確保されていることが重要です。

次にエージェントレスによるセキュリティ対策を提供するために必要なVMware NSXのコンポーネントをご紹介します。

  • NSX Manager
    NSX Manager はすべての NSX コンポーネントの管理を実施する管理サーバとして動作します。vCenter Server とは別の仮想アプライアンスとして動作しますが、NSXが提供するサービスは vCenter Server から NSX Manager を経由して管理されます。
  • Guest Introspection
    Deep Securityなどサードパーティ製品がセキュリティサービスなどを提供する際に必要な仮想アプライアンスとして保護対象となるESXiホストに配信されます。不正プログラム対策、ファイル変更監視などのセキュリティ機能をエージェントレスで提供する上で必要となる仮想マシン毎のNSXセキュリティポリシーの管理を行います。
  • Guest Introspection Driver(NSXファイル自己検証ドライバ)
    エージェントレスで仮想マシンに対する不正プログラム対策、ファイル変更監視などを行う際には、保護対象の仮想マシンにこのドライバをインストールする必要があります。仮想マシン上のNSXファイル自己検証ドライバにより検出されたファイルへのアクセス情報は、ESXiホスト経由でDeep Securityなどのサードパーティのセキュリティアプライアンスへ連携されます。(VMware Tools内のVMCIドライバとして提供されています。)
  • Network Introspection
    Deep Securityなどサードパーティ製品がネットワークセキュリティ機能を提供する際に有効化する必要がある機能です。Network Introspectionサービスのポリシー設定、有効化することにより、対象となる仮想マシンへの通信をサードパーティ製品へリダイレクトすることが可能となります。Deep Securityにてファイアウォール、侵入防御、Webレピュテーションを利用する際に有効化します。
  • 分散スイッチ(vSphere Distributed Switch)
    複数のESXiホストをまたがって構成する仮想スイッチで、仮想マシンを複数のホスト間で移行する場合でも、仮想マシンに対して一貫したネットワーク構成を提供することができます。ネットワークポリシーはvCenter Serverで一元管理され、NSX環境においては分散スイッチを利用することが原則となります。
    ※NSX for vShield Endpointを利用する場合は、標準スイッチ(vSphere Standard Switch)を利用することも可能です。

 

Trend Micro Deep Security コンポーネント

続いて仮想マシンに対して実際のセキュリティ機能を提供するDeep Securityのコンポーネントをご紹介します。

  • Deep Security Manager(DSM)
    DSMは、WebベースでDeep Securityの防御コンポーネント(Deep Security AgentおよびDeep Security Virtual Appliance)を統合管理するサーバです。設定、ログの多くはデータベースに格納する仕様となっており、セキュリティ管理者が実行するセキュリティポリシーの作成や管理、ログの集約などに必要な機能を提供します。なお、データベースについては構成によって、DSMと同じOS上に構築する場合と、DSM用のデータベースを別OS上で構築する場合があります。
  • Deep Security Agent(DSA)
    DSAは、仮想マシンのOS上に直接インストールされ動作することで、Deep Securityで提供されるほぼすべてのセキュリティ保護機能を一括で提供できます。DSAの各機能はモジュール化されており、スクリプトインストールを行うことにより必要なセキュリティモジュールのみをインストールすることで仮想マシンのリソース消費を必要最低限にすることも可能です。また、DSAをリレー化することによってDeep Security Relayとして機能させることができます。
  • Deep Security Relay(DSR)
    Deep Securityは新たな脅威に対応するため、Deep Securityソフトウェアやウイルスパターンファイル、侵入防御シグネチャなどが日々アップデートされています。DSRは、インターネット上のトレンドマイクロのダウンロードサイトからセキュリティアップデート、新しいソフトウェアビルドのダウンロードを行うとともにDSAおよびDSVAへの配信も担います。そのため、DSRはDeep Securityシステム全体で最低1台は必要となります。(DSRはDSA中のひとつのサービスとして有効化することで機能します。)
  • Deep Security Virtual Appliance(DSVA)
    DSVAは、vSphere環境で実行されるセキュリティコンポーネントです。Agentが直接仮想マシンのOS上にインストールされるのに対して、DSVAはVMware NSX と連携し、VMware ESXiホスト上で実行される仮想アプライアンスとして動作し、同一ホスト上の仮想マシンを保護します。仮想マシンのOS上にセキュリティソフトウェアをインストールすること無く、エージェントレスによるDeep Securityのセキュリティ機能を提供することができます。
  • Notifier[オプション]
    DSVAで保護されている仮想マシンでセキュリティイベントが発生した場合、その仮想マシンにログインしているユーザはその状況を知るすべがありません(エージェントレスのため)。Notifierをインストールしていると不正プログラムなどを検出・隔離したとき、または不正なWebページにアクセスしたときなどにユーザにポップアップ通知が表示されます。NotifierはDSVAで保護されている仮想マシン(Windows)内で動作し、必要なディスク容量は1MB未満、メモリサイズは1MB未満です。導入は必須ではありませんが、主にVDI環境で利用している場合には利用を推奨しております。
  • Smart Protection Server(SPS)[オプション]
    SPSは、Webレピュテーションおよびファイルレピュテーションのデータベースをローカルに保持するための仮想アプライアンスです。SPSは社内ネットワークに構築され、トレンドマイクロがクラウド提供しているSmart Protection Network(SPN)と連携します。DSAやDSVAはSPSを参照してWebレピュテーションおよびファイルレピュテーションの機能を提供します。

 

VMware NSX & Trend Micro Deep Security 基本構成

コンポーネントがずらーっ!と並んでしまって分かりにくくなってしまったかもしれませんが、ここでVMware NSXとDeep Securityを連携させるためにどのようなシステム構成を組む必要があるかをご紹介しておきましょう。

図の左側のvCenter Server、NSX Manager、Deep Security Managerが管理コンポートネント群となり、Guest Introspection、Deep Security Virtual Applianceがセキュリティサービスを提供するコンポーネント群として各ESXiホストに配信される構成となっています。
コンポーネント間の関係性において重要な点をいくつか挙げておきたいと思います。

また、システム全体の設計においては以下の点も事前にチェックをしておいてください。

  • Deep Securityコンポーネント間の通信ポート
  • Deep SecurityとVMwareコンポーネント間の使用通信ポート
    DSMからvCenter Server、NSX Managerに対してはTCP443でアクセスできることが必要となります。また、NSX環境では各ESXiホストへのGuest Introspection、DSVAの配信はvCenter Serverが管理をします。
    また、配信の際にはESXiホスト上に内部コネクション用の仮想スイッチ(vmservice-vswitch)が自動的に生成されます。この仮想スイッチのポートグループ、IPアドレス、ポート番号は手動で変更する必要はありません。

<vmwervice-vswitchイメージ図>

<DSとVMware NSX関連コンポーネントの通信フロー>

  • 名前解決
    Deep Securityを利用する環境においては、コンポーネント間の通信において名前解決が可能な設計を行う必要があります。
  • ハートビート
    DSMとDSVA/DSAの間ではステータス管理のため、10分毎(デフォルト:最短1分に変更可能)にハートビート通信を行っています。DSM⇔DSVA間のハートビートは双方向通信(デフォルト)が必須となりますので、ハートビートの通信方向の変更を行わないようにしてください。
  • 時刻同期
    Deep Securityの環境構築においては、システム間の連携が重要となること、イベントログの正確な取得のためにシステム全体をNTPによる時刻同期を計ることが重要です。また、Deep Security ManagerのOSのシステム時間は、データベースコンピュータの時間と同期している必要があります。コンピュータの時間がデータベースの時間と30秒以上前後すると、Manager管理コンソールの [アラートステータス] ウィジェットにこのアラートが表示されます。NTPの設定においては、タイムゾーンが一致するように同一のNTPソースを指定するようにしてください。

 

まとめ

システムを設計、構築、運用していく上で、各コンポーネントの役割や基本的な構成を理解頂くことは重要な点となります。一見複雑に見えるかもしれませんが、今回ご紹介したポイントを抑えて頂ければ安定したシステムを構築することができると思います。
当社のサポートサイトにはDSVAを構築する際のチェックシートも公開をしていますので、こちらもご参考にしてください。

今後、さらに連携の仕組みを深掘りしていきたいと思います。

 

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

 

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

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
  2. VMwareNSX+Deep Secuirty連携によるエージェントレスセキュリティとは?
  3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(3) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

VMware NSXとDeep Securityのユースケースと実現できることとは?

 

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。このたび、VMware vExpert 2018 に選出をいただきました。今後もVMwareソリューションの優位性やトレンドマイクロのソリューションを組み合わせたメリットや技術情報を皆さんにお伝えをしてければと思っております。

 

前回はVMware NSX環境でDeep Security Virtual Appliance(DSVA)によるエージェントレス型セキュリティを実装するために必要なコンポーネントと基本構成について解説しました。
VMware NSX環境でDeep Securityを利用いただくケースとしては、大きく分けると2つのシチュエーションがあります。

  1. 仮想デスクトップ(VDI)環境
  2. サーバマイクロセグメンテーション(いわゆるサーバ環境の保護)

今回はそれぞれのケースでどのように利用されているかをご紹介したいと思います。

 

ユースケース1:仮想デスクトップ(VDI)環境

仮想デスクトップ環境におけるDeep Securityによるエージェントレス型セキュリティ対策は、VMware NSXが登場する前にVMwareがサードパーティ連携を提供していたVMware vShield Endpointというコンポーネントとの連携も含めると2011年あたりからご提供しています。
いまや仮想デスクトップ環境のセキュリティといえば、“Deep Security”というくらいまで認知を頂けるようになるほど業種を問わず多くのお客様にてご利用頂いており、数万台規模でご導入いただいている企業、団体様もございます。
採用いただいているポイントとしては、第2回でも少し記載をしていますが、改めてあげて整理をしてみたいと思います。

(1)仮想デスクトップ(仮想マシン)毎にセキュリティソフトウェアを導入する必要がない

エージェントレス型セキュリティに移行するとESXiホスト毎にセキュリティ専用アプライアンス(DSVA)が配信されることとなり、仮想デスクトップ側にセキュリティソフトウェアを導入する必要はなくなります。また、仮想デスクトップユーザは、朝の時間帯で発生するパターンファイルのアップデートやお昼の時間帯などの定期的なウイルス検索によって仮想デスクトップのパフォーマンスが悪くなってしまうような事象が解消され、セキュリティソフトウェアの稼動を意識することなく業務に従事できるようになり、利便性の向上にも寄与することができます。

(2)セキュリティ対策に共有リソースを使用するため、消費リソースを削減できる

仮想デスクトップ環境では、サーバ環境に比べると1台のESXiホストに対する仮想マシンの集約率が高くなる傾向があります。100台近い仮想デスクトップが集約された環境でそれぞれにウイルス対策ソフトウェアを導入すればホストベースで見ると100台分のアプリケーションリソースを消費していることになります。
各仮想デスクトップのセキュリティ機能をDSVAにオフロードすることにより、集約率の高い環境であればあるほど、ホストからみたリソースの消費は効率化されます。効率化されたリソースの分だけさらに集約率を向上させることにより、ハードウェアコストの削減につなげることも可能です。
※集約率とセキュリティ対策に必要なDSVAなどのセキュリティ専用アプライアンスのサイジングとのバランスは考慮する必要があります。

(3)vSphere環境でのユースケースを考慮した実装となっている

vSphere環境では多くの場合、DRS/vMotionを利用して仮想マシンの最適なリソース配置を行っています。仮想デスクトップが他のホストにvMotionしてもvCenterのインベントリ情報をDeep Securityがリアルタイムに監視することにより、自動的に他のホスト上でもセキュリティ対策を継続します。また、Horizon のリンククローンやインスタントクローンなどの展開方式に関わらず対応できるような設計となっています。
インスタントクローンへの対応については、第1回の記事をご覧ください。

Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

ユースケース2:サーバマイクロセグメンテーション

Deep Securityはもともとサーバセキュリティ製品としてリリースをされ、物理環境、クラウド環境、そして仮想化環境問わずさまざまな環境でご利用いただいています。
加えて、サーバセキュリティに必要な多くの機能を提供が可能で、環境に関わらず同一のコンソールから一元管理できることも大きなメリットとなっています。

各監督官庁がリリースするセキュリティガイドラインや国際的なセキュリティ統一基準(PCI-DSSなど)などに準拠するために利用いただいているケースも多くあります。

Deep SecurityとVMware NSXを利用いただくことにより、各ESXiホストに配置される分散ファイアウォールでの仮想マシン単位での適切なアクセス制御とDeep Securityの各セキュリティ機能によるサーバ要塞化を実現することができます。

また、vCenter Server / NSX Managerが連携していることによりポリシーの適用漏れがないかを簡単に確認することもでき、セキュリティ強化にとどまらず、セキュリティ実装の証明、適用している内容の可視化、そして運用の効率化という側面からも優位性が高いソリューションとなっています。

 

さらにVMware NSXとDeep Securityが連携していると、Deep Security Virtual Applianceでセキュリティイベントを検出した際に、NSX分散ファイアウォールと連携して該当の仮想デスクトップのネットワーク通信の制御(実質的な隔離)を行うことも可能です。
ウイルスを検出した際に、PCのLANケーブルを抜くようなオペレーションを自動的に実行してくれるというわけですね。(ウイルスの隔離に失敗した場合にだけ隔離するといった細かい制御も可能です。)
自動隔離まで行わない場合でも分散ファイアウォールを仮想化環境で使うことには大きなメリットがあります。
それはランサムウェアや標的型サイバー攻撃に対する被害の拡散の防止です。分散ファイアウォールでは仮想デスクトップ同士の通信をブロックするポリシーを1行で書くことができますので、これによって同一セグメントにありながら、ランサムウェアや標的型サイバー攻撃の足がかりとなるマルウェアを実行してしまった場合でも他の端末に対して情報を取得したり、感染を行う“横”の通信(Lateral Movement)をブロックすることができます。サーバセグメントにおいても不必要な通信に対するアクセス制御を行うことよって被害の拡大を最小限に食い止めることが可能となりますし、その状況を可視化することもできます。

 

 

まとめ

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のユースケースと実現できることとは?

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(4) appeared first on Japan Cloud Infrastructure Blog.

仮想スイッチのお作法 Part 3

$
0
0

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

「仮想スイッチのお作法」は、以前所属する会社名で執筆していたものです。

最近こちらのブログのフィードバックをいただくことがあり、サブタイトルにあります「分散スイッチへの道」を継続投稿することにいたしました。

マーケット的には、「VMware NSX」が注目されていますね。NSXは分散スイッチを拡張した機能を持ちます。標準スイッチから分散スイッチ、分散スイッチからNSXへと、順次ステップアップしていくのはNSXを理解する一つの方法ではないかと思います。それは、私自身がNSXの認定コースを受講した際に、「分散スイッチがわかっているとNSXを理解しやすい」と感じたからです。

あらためて分散スイッチを知りたい方、将来的にネットワークも仮想化しようとプランされていらっしゃる方の一助になれば幸いです。

3回目以降は、次の内容で進めます。

#3… vSphere 6.5の分散スイッチの機能とアーキテクチャ

#4…分散スイッチの管理①

#5…分散スイッチの管理②

#6…Network I/O Control

 

◆vSphere 6.5で提供される分散スイッチの機能

下表は分散スイッチが提供する機能の一部です。

一般的なレイヤー2物理スイッチと同様に、IPアドレスまたはMACアドレスでトラフィックのフィルタリング、CoSタグまたはDSCPタグでトラフィックにマーキングすることもできます。

◆分散スイッチ提供のライセンス

分散スイッチは、次の製品のエディションで提供されます。

vSphere Standardエディション環境であっても、VMware NSX for vSphereを購入すれば分散スイッチを使用することができます。

(参考) VMware NSX for vSphereのエディション

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

◆分散スイッチのアーキテクチャ

下図は、分散スイッチのアーキテクチャです。

<アップリンクポートグループ>

分散スイッチを理解するには、「アップリンクポートグループ」から。#2で「dvUplink Ports」と表現したコンポーネントです。

アップリンクポートグループは論理的な物理NICのポートです。分散スイッチを作成する際、1つ以上のアップリンクポート数を指定します。NICチーミング (フェイルオーバーおよびロードバランシング) を設定するなら、2つ以上のアップリンクポート数を指定する必要があります。

上図では3つのアップリンクポートを構成しています。「Uplink1」にはESXiホスト1のvmnic0とESXiホスト2のvmnic0を、「Uplink2」にはESXiホスト1のvmnic1とESXiホスト2のvmnic1を、「Uplink3」にはESXiホスト1のvmnic2とESXiホスト2のvmnic2を割り当てている想定です。

Uplink#が論理的な物理NICのポートであり、標準スイッチでたとえるなら、選択可能な3つの物理NICがあるのと同様です。

下図は分散ポートグループのNICチーミングの設定画面です。標準スイッチでは「有効なアダプタ」と表示されますが、分散ポートグループでは「アクティブアップリンク」と表示されます。

 

<管理プレーンとデータプレーン>

vSphere の仮想スイッチは、「データプレーン」と「管理(制御)プレーン」の2つのセクションで構成されます。標準スイッチは仮想スイッチ内に「データプレーン」と「管理(制御)プレーン」が含まれますが、分散スイッチは「データプレーン」と「管理(制御)プレーン」が分離されます。

分散スイッチの「管理プレーン」は、vCenter Serverにあり、データセンターレベルでネットワーク構成を一元管理します。「データプレーン」は、分散スイッチに関連付けられる各ホストで管理します。分散スイッチのデータプレーンセクションをホストプロキシスイッチ (または隠された仮想スイッチ) と呼びます。

vCenter Server (管理プレーン) で作成するネットワーク構成は、すべてのホストプロキシスイッチ (データプレーン) に自動的にプッシュダウンされます。そのため、vCenter Serverが停止したとしても、I/Oは停止しません。vCenter Serverの障害がネットワークトラフィックに影響されることはありません。ただしvCenter Serverが開始されるまで、新たなネットワーク構成を行うことはできません。

<参考>

参考までにNSXのコンポーネントをご紹介します。

この図では、NSXのコンポーネントを4つの役割および目的で分類しています。

NSXには論理ネットワークの管理のためにデータプレーンと分離する、「NSX Controller」や「NSX論理ルータコントロール仮想マシン」の制御プレーンがあります。

データプレーンには、分散スイッチを拡張したNSX vSwitch (L3スイッチ) があります。ESXiホストにVIBパッケージをインストールし、L2スイッチの分散スイッチをL3スイッチのNSX vSwitchに拡張します。

※NSXと分散スイッチ

ドキュメントに、「分散スイッチの計画と準備を行ってから、NSXをインストールすることがベストプラクティス」とあります。NSXへの移行を検討されている方は、次のドキュメントを参照ください。

https://docs.vmware.com/jp/VMware-NSX-for-vSphere/6.4/com.vmware.nsx.install.doc/GUID-9B22794A-AC90-418D-BAA7-199D9559CF29.html

◆分散スイッチのデータフロー

下図を例に、分散スイッチのデータフローを確認します。

たとえば、仮想マシンネットワークの分散ポートグループには4台の仮想マシン用の仮想NICのポートが割り当てられ (4個の分散ポートを使用)、VMkernelネットワークの分散ポート グループにはESXiホスト2台のvMotion用の仮想NICのポートが割り当てられた(2個の分散ポートを使用)とします。

また、仮想マシン用ネットワークは、Uplink1とUplink2を使用し、ロードバランシング設定にします。vMotion用ネットワークはUplink3を使用します。各ESXiホストのネットワーク接続を提供するために、vmnic0をUplink1へ、vmnic1をUplink2へ、vmnic2をUplink3へマッピングします。

分散スイッチは次の処理を行います。

  • 分散ポートグループの作成順に、仮想マシンおよびVMkernelにポートを割り当て、0 ~ 5のIDを使用して、ポート番号を割り当てる
  • ESXiホスト1とESXiホスト2を分散スイッチに関連付ける
  • ESXiホストの作成順に、ESXiホストの各物理NICにポート (アップリンクポート) を割り当て、上記の続きとなる6から始まるIDを使用して、ポート番号を割り当てる
  • Uplink1とUplink2は仮想マシンネットワークのポートグループのトラフィックを処理し、Uplink3はVMkernelネットワークのポートグループのトラフィックを処理する

◆ホストプロキシスイッチのパケットフロー

ESXiホスト側では、仮想マシンおよびVMkernelからのパケットを特定のポートから物理ネットワークへ送信します。

ホストプロキシスイッチは次の処理を行います。

  • ESXiホスト1上の仮想マシン1から送信されるパケットは、仮想マシンネットワークの分散ポートグループのポート0へ送信
  • 分散スイッチのUplink1とUplink2は、仮想ネットワークのポートグループのトラフィックを処理するために、パケットをホストプロキシスイッチのアップリンクポート6またはアップリンクポート7へ送信
  • パケットがアップリンクポート6を通過する場合はvmnic0へ、パケットがアップリンクポート7を通過する場合はvmnic1へ送信

 

◆まとめ

今回は、分散スイッチのアーキテクチャについてご紹介しました。

分散スイッチでは、「管理」と「データ」のセクションが明示的に分離されているため、ネットワークポリシーの構成や設定をvCenter Server側で一元管理します。一方、データの管理は各ESXiホストが行います。ホストプロキシスイッチにフォーカスすると、標準スイッチと同様ですね。

 

分散スイッチの各ポートがホストプロキシスイッチ (隠された仮想スイッチ) のポートにマッピングされていることを知ると、vCenter Serverが停止しても、プッシュダウンされたポリシーによって、I/Oに影響がないことを理解いただけたのではないかと思います。

分散スイッチと標準スイッチの異なる点の1つにポートID (番号) があげられます。標準スイッチではポートは割り当てられますが、IDは付与されません。仮想マシンの仮想NICを仮想スイッチポートに割り当てるタイミングと方法を設定するポートバインドについては次回取り上げます。

参考としてNSXのコンポーネントについてもご紹介しました。NSXは分散スイッチを拡張したものと理解すると、難しい製品なのでは?と思うハードルが下がりますね。このブログから分散スイッチを知り、さらにNSXへの興味を高めていただけたら嬉しく思います。

The post 仮想スイッチのお作法 Part 3 appeared first on Japan Cloud Infrastructure Blog.


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

$
0
0

エージェントレス型ウイルス対策のアーキテクチャ(1)

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。前回まではVMware NSXとDeep Securityを組み合わせたエージェントレス型セキュリティのメリットや基本的なコンポーネントなどについてご紹介してきました。では、実際にどのようや仕組みでエージェントレス型セキュリティが実現されているのか?という疑問もあるかと思います。今回からは数回にわたってエージェントレス型セキュリティのアーキテクチャ、その際に抑えておくべきポイントなどを技術的な側面から解説していきたいと思います。

まずは、仮想デスクトップ(VDI)環境では多くご利用を頂いているエージェントレス型ウイルス対策がどのような仕組みで実現されているかを解説していきたいと思います。

 

エージェントレス型セキュリティ実装時のウイルス検索処理の流れ

はじめにVMware NSXとDeep Securityの連携によるエージェントレス型(仮想マシンにセキュリティソフトウェアを導入しない)でウイルス対策がどのような流れで実行されているかを確認しておきましょう。

  1. 仮想マシンにインストールされたGuest Introspection Driverに含まれるvsepfilt.sysがファイルのアクセス(読み取り/書き込み)を検出
  2. vepfilt.sysがESXiホスト上のプロセスvShield-Endpoint-MUXへアクセス情報を送信(VMCI経由)
  3. vShield-Endpoint-MUXからDSVAのプロセスds_amへアクセス情報を送信(TCP/IPコネクション経由)
    DSVAのマルウェアスキャンエンジンのスキャンポリシー(スキャン条件、スキャンキャッシュの有無など)に従いマルウェアスキャンが必要かどうかをチェック
    マルウェアスキャンが必要と判断された場合、vsepfilt.sysに対してファイル取得リクエストをレスポンス
  4. vsepfilt.sysが該当のストレージ領域からファイルを取得
  5. 検索対象ファイルをvShield-Endpoint-MUX経由でDSVA(ds_am)へ送信
  6. マルウェアスキャンエンジンがウイルス検索を実行
  7. ウイルス検索イベント(検索結果・実施アクション)をvsepfilt.sysへ通知
  8. マルウェア判定されていた場合、vsepfilt.sysがイベントに基づき隔離、削除などのアクションを実施

エージェントレス型のウイルス検索処理おいてポイントとなるのは以下の点です。

  • ウイルス検索する対象ファイルの検出、アクション自体はVMware vSphere/NSX側のコンポーネントが担っている
  • ウイルス検索の実行、アクションの決定はDeep Security Virtual Applianceが行う

また、Deep Securityにおいてこの仕組みは不正プログラム対策のほかに変更監視機能でも利用されています。変更監視機能では仮想マシン上のファイル、ディレクトリの情報を取得してベースラインからの改ざんがなされていないかを確認することができますが、ファイル、ディレクトリ情報の取得にもこの仕組みを利用しているわけですね。

 

エージェントレスでもトリガーするためのドライバが必要

そしてこの流れを見ていただいたわかるとおり、エージェントレスではありますが、仮想マシンでのファイルアクセスを検出するためのドライバが必要であるということも重要な点です。
このドライバがなければ、ファイルアクセスを検出することもウイルス検索のための上記のプロセスをトリガーすることもできません。
このブログではGuest Introspection Driverと記載をしてきていますが、現行バージョンではNSXファイル自己検証ドライバと呼ばれています。VMware Toolsに含まれるVMCIドライバのひとつでこれを有効化しておく必要があります。
ちなみにNSXファイル自己検証ドライバの下にあるNSXネットワーク自己検証ドライバというものもあります。“ネットワーク”とあるので、Deep Securityのファイアウォール、侵入防御機能などを利用する場合に有効化する必要があるのではないかと思われると思いますが、こちらのドライバはDeep Securityのどの機能を利用する場合でも有効化の必要はありません。

また、エージェントレス型セキュリティの場合、ウイルス検索の結果マルウェアが検出された場合、それをWindowsにログインしているユーザに通知する仕組みがありません。突然ファイルが見えなくなってしまっては何が起こっているかわかりませんね。業務サーバであればそれでも運用が困ることは少ないと思いますが、仮想デスクトップ環境ではそうはいきません。
そのため、Deep SecurityにはDeep Security Notifierというポップアップツールを提供しています。NotifierはNSXファイル自己検証ドライバと連携してDeep Securityの検出状況をユーザに提供することができます。
NSXファイル自己検証ドライバ、Notifierともにパターンファイルなどの情報は保持していませんので、ログインごとに仮想マシンが生成されるような仮想デスクトップ環境であってもマスターイメージにこの2つのモジュールをあらかじめインストールしておくことによりスムーズな展開、運用が可能となります。

 

まとめ

ここまでエージェントレス型セキュリティにおけるウイルス検索の流れと仕組みを見てきました。
ただし、まだ押さえておかなくてはならない点があります。DSVAはvSphere/NSXの仕組みを通してウイルス検索を行うファイル情報を受け取っていますが、この仕組みを利用できるように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)

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(5) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

エージェントレス型ウイルス対策のアーキテクチャ(2)

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

前回はDSVAによるエージェントレス型セキュリティのウイルス検索の流れについて解説をしました。VMware NSX/vSphereと連携をしてDSVAがウイルス対策をはじめとしたセキュリティ機能を提供するためにはNSX側でも必要なサービス設定をしておく必要があります。
NSX側のサービス設定があるからこそ、仮想マシンが生成されたタイミングでDeep Securityのポリシーを自動適用することが可能となりますし、vMotion/DRSによる仮想マシンのホスト間の移動が発生した場合のポリシーのシームレスな移行も可能となっています。
今回は、NSXとDeep Securityが連携した環境で仮想マシンの制御がどのように行われているのか、という側面からアーキテクチャを見ていきたいと思います。これはエージェントレス型セキュリティの実装において一番抑えておいて頂きたい点の1つです。

 

NSX ManagerとGuest Introspectionの役割

まず、エージェントレス型セキュリティ対策で必要となるコンポーネントとしてNSX ManagerとGuest Introspectionが挙げられます。それぞれの役割については第3回でも触れましたが改めておさらいをしておきましょう。

  • NSX Manager
    NSX Manager はすべての NSX コンポーネントの管理を実施する管理サーバとして動作します。vCenter Server とは別の仮想アプライアンスとして動作しますが、NSXが提供するサービスは vCenter Server から NSX Manager を経由して管理されます
  • Guest Introspection
    Deep Securityなどサードパーティ製品がセキュリティサービスなどを提供する際に必要な仮想アプライアンスとして保護対象となるESXiホストに配信されます。不正プログラム対策、ファイル変更監視などのセキュリティ機能をエージェントレスで提供する上で必要となる仮想マシン毎のNSXセキュリティポリシーの管理を行います。

エージェントレス型セキュリティ対策では、NSXサービスを利用するために管理コンポーネントとしてNSX Managerをデプロイし、サードパーティ製品が連携するために必要となるGuest Introspectionという仮想アプライアンスを各ESXiホストに配信することが必要になります。
ここでポイントとなるのは、Guest Introspectionが「仮想マシン毎のNSXセキュリティポリシーの管理」を行うという点です。ESXiホスト単位で配信されるGuest Introspectionがどのように「仮想マシン毎のNSXセキュリティポリシーの管理」しているのでしょうか。

  1. NSX ManagerはvCenter Serverと連携をして常に仮想マシンの状態・稼動しているホストの情報を保持しています。また、NSXサービスを利用する上では必ずセキュリティグループ/セキュリティポリシーの設定が必要になります。これによって仮想マシン毎に適用するNSXサービスを指定します。
    • セキュリティグループ
      仮想マシンが所属するオブジェクトグループとして指定
    • セキュリティポリシー
      NSXで提供するサービスを定義して、セキュリティグループにバインド
  1. NSX Managerは仮想マシン毎に割り当てられたセキュリティグループ・ポリシーを元に稼動するESXiホスト上のGuest Introspectionに対してNSXサービスの提供を指示します。
  1. Guest Introspectionは、ESXiホスト上のvShield-Endpoint-MUXに対して仮想マシン毎に管理用のTCPコネクションを張ります。

以下にNSXサービスが各ESXiホストにどのように配信されているかを図示しています。(直接Deep Securityとの連携はありませんが、Horizon Connection Serverも記載をしています。)

 

DSVAの位置付けとNSXサービスとDeep Securityポリシーの連携

エージェントレス型セキュリティ対策を提供するDeep Security Virtual Appliance(DSVA)は、上記のNSXサービスと連携をして各種セキュリティ機能を提供しています。
DSVAはGuest Introspectionと同様にESXiホスト毎に配信されます。また、ハイパーバイザ経由で各仮想マシンからのファイル情報、パケット情報の受け渡し及び各仮想マシンのNSXサービスステータスを受け取るため、Guest IntrospectionからvShield-Endpoint-MUXに張られるTCPコネクションに対応して、vShield-Endpoint-MUXからDSVAに対してもTCPコネクションが張られます(このコネクションも仮想マシン毎に張られます)。
これによって、DSVAがハイパーバイザ経由でエージェントレスのセキュリティサービスが提供するために必要なハイパーバイザ側のパスが確立されます。
このコネクションは非常に重要で、Guest Introspection → vSheild-Endpoint-MUX → DSVAのコネクションが確立できない場合には、DSVAに適切なDeep Securityポリシーが適用されていても、該当する仮想マシンへのNSXサービスが提供できない状況となるため、Deep Securityのセキュリティ機能は提供できません。

一方でDSVAを管理するDeep Security Manager(DSM)は、vCenter Server、NSX Managerと連携を行い、仮想マシンの状態・稼動しているホストの情報とともに適用されたNSXセキュリティサービスの情報をリアルタイムで同期しています。また、この管理サーバ間の連携によりNSX ManagerがDeep Securityのポリシー情報のエイリアス情報を保持することにより、NSXサービスと同様にどのDeep Securityポリシーを適用するべきかをDSMに指定することが可能となります。
(vCenter Server上の “Networking and Security” Security Policy Service ProfileとしてDeep Securityの“ポリシー”が選択可能となります。)

NSXセキュリティグループ、NSXセキュリティポリシーおよびDeep Securityポリシーの関係性は以下のようになります。

※このポリシー連携はNSX Advancedライセンス以上を利用している場合にのみ可能となり、NSX Standardライセンス以下の場合には、Deep Securityのイベントベースタスクを利用する必要があります。イベントベースタスクを利用する際には、NSX側ではSecurity Policy Service Profileにおいて“default(EBT)”を選択する必要があります。
イベントベースタスクについてはこちらをご参照ください。

Deep SecurityのポリシーとNSXサービスのセキュリティポリシーが連携することで、仮想マシン生成時にはNSX セキュリティポリシーに従ってDSMから稼動するESXiホスト上のDSVAに対して自動的にDeep Securityのポリシーが配信されます。また、vMotion/DRSにより仮想マシンがホスト間で移動した場合にもDSVA間のポリシーの移行を自動的に行うことができるようになっています。
NSXのサービスに加えてDeep Security “ポリシー”がどのように配信されているかを以下に図示しています。

 

まとめ

ここまで見てきたとおり、NSX+Deep Securityによるエージェントレス型セキュリティ対策は、“仮想マシン単位”でNSXサービスとDeep Securityポリシーの双方を連携させることで、vSphere環境上での変化にリアルタイムに対応しつつ、必要なセキュリティ機能を適用し続けることができるように実装されています。

今回は少し詳細な部分まで踏み込んで解説しましたが、vCenter Server/NSX Manager/DSMの管理サーバ群の連携、Guest Introspection-DSVAのコネクションの確立、この2点が重要なポイントです。それらがあって始めてDeep Securityポリシーを適用することが可能となります。ブラックボックスと思われがちなエージェントレス型セキュリティの仕組みも少し身近に感じていただけければうれしく思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネス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)

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(6) appeared first on Japan Cloud Infrastructure Blog.

新卒 SE 社員が贈る NSX のキソ!第 1 回~ネットワーク仮想化への第一歩~

$
0
0

はじめまして!
2017 年 4 月入社 VMware 新卒 4 期 SE の大田愛里香と申します。VMware ではこれまで社会人なり立てほやほやの新卒 SE 社員が一生懸命自社製品について勉強した努力の結晶として、新卒にしていきなり SE という職種を放り投げブロガーと化し、サーバ仮想化製品であるvSphereデスクトップ仮想化製品である Horizon について、それぞれ新卒の目線からご紹介してきました。今回はそのネットワーク仮想化編としまして、これから 8 回に分けて「新卒 SE 社員が贈る NSX のキソ!」と題して、NSX for vSphere の用語や機能、仕組み、メリットを新卒 SE 大田(Ota)、村田(Murata)、甫木(Hogi)、馬場(Baba)、笠井(Kasai)、黒沢(Kurosawa)の 6名でご紹介します。

記念すべき NSX ブログ第 1 回となりますが、まずこのブログで想定している読者、ネットワーク仮想化をとりまく背景、このブログの進み方についてご説明いたします。

 

1. このブログの対象
弊社のネットワーク仮想化製品である NSX は、前提としてサーバ仮想環境の上で機能します。サーバ仮想化については、弊社の記念すべき新卒第 1 期生(!)が新卒 1 年目の時に作成した(!!)、記念すべき初めての弊社新卒 SEブログ(!!!)、「新卒 SE 社員が贈る vSphere のキソ!」ですでにご紹介していますので、今回はサーバ仮想化については改めて詳細なご紹介はいたしません。もちろん、サーバ仮想化について、「FT とは Fault Tolerance の略であり常にレプリケーション VM を別の物理サーバにスタンバイさせることにより物理障害発生時のダウンタイm」というように全て完璧な理解をしている必要はありません。このブログでは積極的に図解をしていこうと思いますので、図をみれば仮想環境上のネットワークについては十分イメージしてもらえると思います。サーバ仮想化の知識について、あやしいなと思ったときに、vSphere 編をかいつまんで見返していただけると、理解が深まるのではないかと思います。

また、ネットワーク仮想化をするにあたって、今まで物理ネットワーク機器で実現していた機能を仮想化するということになりますので、ルーティング、スイッチング、VLAN、ロードバランシング、ファイアウォール、NAT、VPN といったこれまでの機能がネットワーク仮想化環境にも実現されます。これらの機能についてそれぞれどのようなものなのかといったことは、私たちそもそもネットワーク初心者だしネットワーク仮想化という大きなテーマを語るうえでボリュームの問題もあり、このブログでは基本的には改めての詳細なご紹介はできませんでした、ごめんなさい!ですが、それぞれの機能の概要だけ理解していれば内容としては読み進められるように、適宜図やスクリーンショットを交えてご紹介しています。

上記の前提はありますが、このブログでは広くネットワーク仮想化について興味があり、まずは「どんな機能があるか?」「どんなメリットがあるか?」というところを理解したい方を対象にしており、さらに深く知りたい方にも「どんな仕組みなのか?」といったところまで分かりやすく説明することを目的にしております。私たちは入社後わからないことがあまりにも多く、特にネットワーク仮想化については複雑でかなり苦戦しましたが、実際に学び、操作しているうちに、専門的な知識が乏しくても、「なるほど、こんなことができるのか!」とだんだんわかるようになりました。本ブログでは、私たちが初心者的な目線で NSX を理解した時の視点をそのまま、NSX の全体像をお伝えできたらと思います。

 

2. ネットワーク仮想化をとりまく背景
まずネットワーク仮想化の導入として、サーバ仮想化を導入してからインフラがどのように変わったのかを歴史の教科書ばりに真面目に復習してみたいと思います。

下記の通り、サーバ仮想化によって、物理リソースの集約、機器調達時間や作業工数、人的コストの削減といったメリットがありました。

図 1 サーバ仮想化によって得られた効果

図 1 サーバ仮想化によって得られた効果

 

しかし、企業のインフラを構成するものはサーバだけではありません。サーバ側の最適化により作業工数が削減されても、下記のようにネットワーク側では昔のままで機器調達や作業工数に時間を割かれることにより、インフラ全体としての提供スピードは結局変わらず、サーバ仮想化によるメリットを最大限に享受できない状態になってしまいます。

図 2 従来のネットワークにおける課題

 

そこで、今まで物理的に提供してきたネットワーク機能をソフトウェアで提供することで、サーバ仮想化の時に得られたメリットと同じように、ネットワーク機能を仮想マシンの作成と同様の手順でお手軽に提供したり、様々な物理環境の制約から解放したサービスを提供したり、そしてそれらの管理を一元化して運用負荷を軽減したりするために、弊社のネットワーク仮想化ソリューションである NSX が生まれました。

図 3 仮想環境ならネットワーク機器も気軽に構築

 

さらに、NSX は、従来のネットワーク機能を仮想環境に置き換えるのみならず、仮想環境に特化したファイアウォール 機能(第 6 回でご紹介予定)による最新のセキュリティソリューションや、ハイパーバイザーのカーネルで処理される各種分散ネットワーク機能、複数のデータセンター、およびハイブリッドクラウド環境(第 8 回でご紹介予定)に柔軟に対応するマルチサイトソリューション、など様々な新しい形のネットワークサービスとして活用いただけます。このように、これまでの物理的なハードウェアの制約に縛られていたネットワークとは異なった、NSX の仮想ネットワークであるがゆえに実現できることは非常に多くあり、本書でお伝えできることに限らず幅広い用途でメリットをご提供できますが、今回はそのエッセンスとなるものをできる限り分かりやすくひも解くことによって、読者の皆さん自身でも NSX の多岐にわたるユースケースを連想していただけたら何よりです。

...はい、ということで、背景となるところを真面目に説明させていただきました。退屈でしたか?そうですよね、「なんか、めっちゃざっくり当たり障りない概要説明!!!よくある結局なにもわかんないやーつ!」って感じだったと思います。ちょっと待ってください、このブログはネットワーク仮想化についてこのようなふんわりとした概要しか知らないという方が、ビビビッと、鮮明に理解していたけるように、一同頑張って書いております。ということでお待たせいたしました、今からこのブログの流れを説明させていただきます。

 

3. このブログのながれ
このブログでは、「結局のところ、NSX でどんな世界が作れるのか?」ということを皆さんにイメージしていただきたいという思想の元、NSX のサンプル構成をご用意しております。前述の通り、NSX で実現できる世界は実に多様になっており、コンポーネントの役割だけを淡々とお伝えしても、おそらくたいていの人が「んー、今どこの話してて、結局なんなの?あーなんか退屈だし、飽きた(笑)」と SNS を眺めはじめ、私たちは皆様に何も残すことができず終わってしまうかもしれません。そこで、読者の皆さんにも、あらかじめ「今からどんなものを作ろうとしているのか?」という視点を合わせていただき、その上で、実際に構築するときの手順と同じ流れで様々なコンポーネントをご説明いたします。これにより、各コンポーネントがどのような役割、機能を持ち、それがお互いに作用することによって何を実現できているのかということを実感していただければと思います。しかしこれだけでは、「で?!この機能何の意味があんの?!(笑)」とビジネス的にあっさり切り捨てられてしまうので、各機能を実現することによるメリットについても、皆さんに具体的にイメージしていただけるように一生懸命ご説明させていただきます。機能を理解した上で、「この機能があればこんなことがメリットになるのか!」と感じていただき、NSX という製品の意義を伝えられたらと思います。ついでに SNS で「VMware NSX サイコー!」などテンション高めに紹介していただけるとうれしいです。

それでは、次回よりさっそく、NSX を構成するイケてるメンツを紹介するぜ!ということで、NSXの登場人物(コンポーネント)と、今回のサンプル構成をご紹介いたします。各回ごとにサンプル構成の NSX 環境がどんどん完成していき、それに伴い NSX のイケてる機能がどんどん増えていきますので、どうぞ最後までお楽しみください!

-VMware SE 大田愛里香

The post 新卒 SE 社員が贈る NSX のキソ!第 1 回~ネットワーク仮想化への第一歩~ appeared first on Japan Cloud Infrastructure Blog.

新卒 SE 社員が贈る NSX のキソ︕第 2 回〜NSX for vSphere の基本構成(登場人物の整理)〜

$
0
0

こんにちは!「新卒社員が贈る NSX のキソ!」第 2 回を担当する VMware 新卒第 4 期生の村田太郎です。第 2 回では NSX for vSphere を構成する主要なコンポーネントと、ブログ全体で利用する NSX のサンプル構成についてご紹介いたします。

図 1 NSXを構成する主なコンポーネント

NSX for vSphere を構成する主なコンポーネントは図 1 のようになります。 vCenter Server と ESXi ホスト以外は全て NSX 導入時に新たに展開されるコンポーネントになります。

念のため簡単に説明すると、 ESXi ホストは仮想化の基盤であるハイパーバイザーのインストールされた物理ホストで、この上に仮想マシンが作成されていきます。vCenter Server は ESXi ホストの管理を行うためのコンポーネントで、複数ホストにまたがったネットワークの設定を行う際に必要となります。

vCenter Server によって提供される管理画面が vSphere Client (HTML5)と vSphere Web Client (Flash)ですね。現在はFlash 版と HTML5 版が利用可能になっていますが、今後 Flash 版はなくなり、HTML5 に統合されていく予定です。

図 2 vSphere Client (HTML5)

各コンポーネントはその役割によって、管理プレーン(Management Plane)、制御プレーン(Control Plane)、データプレーン(Data Plane)のいずれかに分類されます。プレーンという言葉は聞きなれないかもしれませんが、あるひとつの機能を実現するのにもいろいろなコンポーネントが関わっていて、それぞれの役割で分類されている、程度に思ってください。

1. NSX のプレーンについて
NSX では、各コンポーネントがプレーンごとにぞれぞれ独立して動作しているので、もし制御プレーンに障害が発生しアクセスができない状態になったとしても、データプレーンが動作していれば通信を継続的に正常に処理することができる、などのメリットがあります。

プレーンが分かれておらず、設定、制御、実際の通信を同じコンポーネントで実現していると、そのコンポーネントに障害が発生してしまったときの影響範囲が非常に広くなってしまいますが、役割を分けてコンポーネントが存在しているとそういったことは起こりづらくなります。

管理プレーンは NSX Manager によって構築される NSX の管理コンポーネント群であり、管理者への一元的な設定、管理を提供します。管理プレーンでは管理トラフィックを扱います。制御プレーンは NSX における論理スイッチや論理ルーティングなどの制御を行います。データプレーンでは制御プレーンによって与えられたルーティング情報などをもとに実際にパケットのスイッチングなどデータのやりとりを行います。

実際に管理者が操作するのは管理プレーンのコンポーネント、ネットワークの実データが流れるのがデータプレーン、管理者からの操作を受けてデータプレーンを制御するコンポーネントは制御プレーンといったイメージになります。

図 3 NSX のプレーン

2. 各コンポーネントについて
NSX Manager は、NSX 導入における管理コンポーネントであり、NSX 導入時に最初に仮想アプライアンス(仮想マシン)として展開されるコンポーネントです。NSX Manager は vCenter Server に登録され、1 対 1 でマッピングされます。NSX Managerの初期構成を終えたのちは、NSX に関連する設定は対応する vCenter Server 上で行うことが可能になります。

 

NSX Controller は、NSX の仮想ネットワークを制御するコンポーネントで、論理ネットワークの制御を行っています。こちらも NSX Manager 同様、実体は仮想マシンで、NSX Manager を展開したのちに vSphere Client から作成します。仮想マシン、ホスト、論理スイッチ、分散論理ルータに関する情報を保持しており、重要な役割を持っているので、可用性を担保するために 3 台でクラスタを組む必要があります。

NSX には仮想アプライアンスによって提供される機能と vSphere のカーネル上で提供される機能がありますが、 vSphere のカーネル上で提供される機能はハイパーバイザー カーネル モジュールによって実現されます。ハイパーバイザー カーネル モジュールは、もともと vSphere のカーネルで提供されている仮想スイッチである分散仮想スイッチ(vDS: vSphere Distributed Switch)を拡張する形で提供される NSX のコンポーネントです。論理スイッチ、分散論理ルータ(DLR: Distributed Logical Router)、分散ファイアウォール(DFW: Distributed FireWall)などの機能を提供します。
NSX の論理スイッチは VXLAN(Virtual eXtensible LAN)というカプセル化の技術を使って実現されています。VXLAN を用いると、L3 ネットワーク上に仮想的な L2 ネットワークを構築することができるようになります。ピンと来ないかもしれませんが、後の回で別途説明がありますので、少々お待ちください。

分散論理ルータ コントロール仮想マシンはその名の通り、分散論理ルータの制御を行います。制御プレーンに属するコンポーネントで、分散論理ルータと他のルータとルーティングプロトコルセッションの確立を行います。

 

NSX Edge ゲートウェイは、North-South 方向のルーティング、境界ファイアウォール、NAT、DHCP、VPN、ロードバランシングなどのネットワークサービスを提供します。

分散論理ルータ コントロール仮想マシンと NSX Edge ゲートウェイもそれぞれ別々の仮想マシンとして作成されるコンポーネントです。分散論理ルータ自体は ESXi の「カーネル」で動作しますが、分散論理ルータを制御するのは分散論理ルータ コントロール「仮想マシン」であることに注意してください。この辺はよくこんがらがりますが、基本的に実データのやりとりは ESXi のカーネルで行われると思ってください。

NSX のコンポーネントの中でルーティングの機能を有するものは分散論理ルータと NSX Edge の 2 つがあります。なぜ同じ機能を複数のコンポーネントが持っているのか不思議に思われる方もいるかもしれませんが、分散論理ルータと NSX Edge ルータはルーティングを担当するトラフィックのタイプによって使い分けられます。

図 4 North-South/East-Westトラフィック

データセンターにおける通信は、データセンターの内外を行き来する North-South トラフィックと、データセンター内部の East-West トラフィックに分類されます。
分散論理ルータは East-West トラフィックのルーティングを、NSX Edge では North-South トラフィックのルーティングを主に行います。

3. サンプル構成図と今後の流れ
さて、NSX の主要なコンポーネントについての紹介を終えたところで、これらのコンポーネントがどのように展開されていくのかを、サンプル構成図を用いて次の回から順を追ってご紹介いたします。

このサンプル構成図は、論理ネットワーク構成図になっており、物理ネットワーク図ではないことに注意してください。ESXi ホストの絵が載っており、なんとなくその上に仮想マシンが配置されているように見えますが、気にしないでください。これは論理ネットワーク図なのでデバイスの物理的な配置には左右されません。この辺りの頭の切り替えが仮想ネットワークを理解する際のポイントになります。

図 5 サンプル構成図(NSX導入前)

図 6 サンプル構成図(NSX導入後)

 

図 5 が NSX 展開前、図 6 が NSX 展開後のサンプル構成図になります。

このサンプル構成(NSX 展開前)では、ESXi ホスト 4 台でクラスタを組んでおり、vCenter Server が 1 台の非常にシンプルな構成となっています。NSX 展開前の仮想マシンはどのネットワークにも接続していません。ネットワークは 4 つの VLAN に分かれており、それぞれ VTEP(後述)用、仮想マシンネットワーク用、管理ネットワーク用、vMotion 用となっています。今回はこのサンプル構成図を用いて NSX についてご紹介いたしますので vMotion 用の VLAN については特に関係ありませんが、通常 vSphere 環境を構築する際には管理ネットワーク、vMotion ネットワークなどでセグメントを分けるので、それにならった形の構成になっています。

それでは、NSX がどのように展開されていくのか見ていきましょう。

コラム ~ vSS と vDS ~
ハイパーバイザー カーネル モジュールのご紹介の際に、何気なく vDS の拡張ですと書いてしまいましたが、ここで簡単におさらいしておきたいと思います。

もともと、vSphere 上の仮想マシンが通信を行う際には、vSphere のカーネル内部に存在する仮想的なスイッチ、vSS(vSphere Standard Switch)を経由していました。vSS は各物理ホスト単位で設定を行う、ESXi に標準の機能になります。
各物理ホスト単位でスイッチの設定を行うとなると、ホスト数が多い場合、仮想スイッチの管理が手間になってきますし、設定ミスの可能性も上がってきますが、この問題を解決するものが、vDS(vSphere Distributed Switch)になります。

vDS では複数ホストの仮想スイッチを一元的に設定、管理することが出来るようになります。

VMware は、仮想ネットワークに取り組んできた長い歴史があり(スイッチの出荷ポート数で考えると、データセンタ―にある物理の ToR スイッチ以上のポート数を既に出荷済み!)、この vDS が仮想ネットワークの基礎となり、次世代のネットワーク仮想化プラットフォームとしての NSX に昇華されることになったのです!

vSS と vDS

vSS、vDS に関する詳しい説明は、「新卒 SE 社員が贈る vSphere のキソ」(https://blogs.vmware.com/jp-cim/2014/08/vsphere_kiso01.html)をご覧ください。

The post 新卒 SE 社員が贈る NSX のキソ︕第 2 回〜NSX for vSphere の基本構成(登場人物の整理)〜 appeared first on Japan Cloud Infrastructure Blog.

新卒 SE 社員が贈る NSX のキソ︕第 3 回〜NSX Manager・NSX Controller・ハイパーバイザー カーネル モジュールについて〜

$
0
0

こんにちは! VMware 新卒 4 期生 SE の甫木佑美佳です。第 3 回の「新卒 SE 社員が贈る NSX  のキソ!」では、私たちが NSX Data Center を勉強した時に少々理解にてこずり、でもここが分かると NSX Data Center のアーキテクチャへの理解が深まる気がする…そんなコンポーネントである NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールをご紹介していきます。

 

1. NSX Manager・NSX Controller・ハイパーバイザー カーネル モジュール

図 1 サンプル構成図 NSX Data Center 導入前

前回は、NSX Data Center を構成する主要なコンポーネントやサンプル構成についてお話してきました。NSX Edge や分散論理ルータコントロール仮想マシンは、ネットワークに触れたことのある方ならエッジ、ルータといった単語からなんとなく環境の境界にあるんだろう、ルーティングに関連するんだろうと想像できると思いますが、NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールはなかなかイメージがつきにくいですよね。Manager と Controller って似てそうだけどどう違うの?、モジュールって一体何?、今回はそういった疑問にお応えすべくこれらの 3 つのコンポーネントを解説していきます。

図 2 NSX Manager、NSX Controller クラスタ、ハイパーバイザー カーネル モジュール

図 2 が今回ご紹介するコンポーネントの全体像です。NSX Data Center は管理・制御・データプレーンによって構成されていることは前回お話ししました。それぞれのプレーンについて、一度ここでおさらいしましょう。管理プレーンでは NSX Data Center が提供する機能の設定・管理を実施します。実際のデータトラフィックが流れてスイッチングやルーティングが行われるのがデータプレーン、そしてスイッチングやルーティングに必要な計算を行いデータプレーンを制御するのが制御プレーンです。今回ご紹介するコンポーネントはそれぞれ、NSX Manager は管理プレーン、NSX Controller は制御プレーン、ハイパーバイザー カーネル モジュールはデータプレーンに属しています。

これだけの説明だとちょっと抽象的ですよね。それでは、より具体的なイメージを掴んでいただくために、従来の物理ルータ 1 台が提供する基本的な機能を NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールの 3 つのコンポーネントがそれぞれどのように提供するか、図 3 で示してみました。

図 3 物理ルータと NSX Data Center の比較(例)

図 3 の左にある従来の物理ルータでは、管理者がコマンドで作成した設定の反映や、ルーティング情報の制御、そして実際のデータトラフィックの処理といったサービスを 1 台の機器で集中的に提供していました。一方で図 3 の右側にある、今回ご紹介する 3 つのコンポーネントでは、管理者による設定の反映は NSX Manager が、ルーティング情報の制御は NSX Controller が、データトラフィックの処理はハイパーバイザー カーネル モジュールがそれぞれの機能を提供します。このように、従来物理機器 1 台で提供されていた機能が複数のNSX Data Center のコンポーネントに分散されます。

これらのコンポーネントへの認識が少し深まったところで、ここから NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールそれぞれの展開方法、役割、機能についてもっと詳しくお話ししていきます!

 

2. NSX Manager について

2.1 役割

NSX Manager は、管理プレーンに属しており NSX Data Center 環境全体の管理はこのコンポーネントで実施します。NSX Data Center を構築する際に最初に立てる必要があるコンポーネントで、これなしでは NSX Data Center によるネットワーク仮想化のサービスは提供されません。NSX Data Center を集中管理するという点から、vSphere における vCenter Server 的な存在だと考えてください。

2.2 展開方法

この NSX Manager、先ほど vSphere における vCenter Server のような存在とお伝えしましたが、デプロイは vCenter Server の管理コンソールである vSphere Web Client で実施します。vSphere Web Client 上で NSX Manager の ova ファイルをアップロードし、仮想アプライアンスとして展開します。デプロイされた NSX Manager は vCenter Server と 1:1 でマッピングされます。vSphere Web Client にプラグインが追加されることで、NSX Data Center が提供するサービスは vSphere Web Client を通じて展開および管理されます。

2.3 機能

NSX Manager が提供する機能は、主に 4 つあります。

① GUI の提供

図 4 vSphere Web Client 上のNSX Data Center 管理画面

NSX Data Center では NSX Manager が唯一の管理ポイントであり、NSX Data Center に関するすべての設定はNSX Manager で実施します。図 3 のスクリーンショットが実際の管理画面です。

② REST API の提供

NSX Data Center は、セキュリティ製品など様々なサードパーティ製品と連携することが可能です。他のソリューションとの連携には、NSX Manager が唯一のエントリポイントとなります。

③ コンポーネントのデプロイ

図 5 コンポーネントのデプロイ

今回ご紹介する NSX Controller、ハイパーバイザー カーネル モジュールや第 2 回の記事で登場した NSX Edge ゲートウェイ、分散論理ルータコントロール仮想マシンといった NSX Data Center を構成するコンポーネントは NSX Manager からデプロイします。

④ 構成情報の配布・保持

図 6 NSX Manager による構成情報の配布

NSX Manager が提供する GUI 上で設定を実施することはこの記事でお伝えしました。NSX Data Center のコンポーネントに対する設定は図 3 の画面から実施し、各コンポーネントに配布されます(図6)。

このように、NSX Manager は NSX Data Center のすべての構成情報を保持しているため、NSX Manager のバックアップを取ってしまえば NSX Controller、論理スイッチ、ファイアウォールルールなど、あらゆる NSX Data Center の設定のバックアップまで取ることになります!

 

3. NSX Controller について

3.1 役割

NSX Controller は制御プレーンに属しており、冒頭でお話ししたようにカーネル モジュールがデータトラフィックの処理を実施する論理ネットワークの制御を行います。また、NSX Manager と ESXi ホストのカーネル モジュールからそれぞれ情報を受け取って管理する役割を担います。

3.2 展開方法

NSX Controller は、他のコンポーネント同様 NSX Manager からデプロイされ、NSX Manager が提供する GUI から仮想アプライアンスとして展開されます。図 7 をご覧いただくと、NSX Controller が 01、02、03 と 3 台構築されていることがお分かりいただけると思います。なぜ 3 台も立てる必要があるのでしょうか?この理由については、後ほどご説明します。

図 7 NSX Controller ノード

3.3 NSX Controller の機能

NSX Controller が提供する機能は 2 つあります。

① NSX Data Center 環境の論理スイッチング・分散論理ルーティングに関する情報の制御

NSX Controller は、それぞれのホストのハイパーバイザー カーネル モジュールや分散論理ルータコントロール仮想マシンから送られてくる仮想マシンの情報を管理、制御します。このあたりの仕組みについては、第 5 回でもう少し詳しい説明をします。

② ESXi ホストに対して、論理スイッチング・分散論理ルーティングに関する情報の提供

図 8 NSX Controller による情報のプッシュ

上記 ① の機能で収集した論理スイッチング・分散論理ルーティングの情報を NSX Controller は環境内のホストに送信します。NSX Controller がこれらの情報をまとめてホストに提供することで、それぞれのホストはそのホスト上にない仮想マシンの情報も把握します。

3.4 NSX Controller が3 台必要な理由

ところで、このシリーズの冒頭から登場している NSX Controller ですが、サンプル構成図では「NSX Controller クラスタ」と表記され、アイコンが 3 つ並んでいることにはお気づきでしょうか?

NSX Controller の展開方法をご説明した際にも 3 台立てられていたことをご確認いただきましたが、実は NSX Controller は 3 台構成する必要があります。なぜ NSX Controller が 3 台必要なのか、端的にお伝えすると以下の 2 つがその理由です。

・負荷分散

・冗長性の確保

まずどのように負荷分散させているかというと、NSX Controller が論理スイッチング・分散論理ルーティングの情報を管理することは既にお話ししましたが、NSX Controller が 3 台あることで、そのワークロードを分散させることが可能となります。その際にNSX Controller クラスタでは、それぞれの情報に対してマスターのロールを持つノードが 1 台選ばれ、そのマスターが他のノードにワークロードの割り当てを実施します。

図 9 NSX Controller 間でのワークロードの分散

そして冗長性の確保については、もし 3 台の NSX Controller のうち 1 台のホストで障害が発生してサービス提供が出来なくなってしまった場合には、その 1 台が担っていたワークロードが他の 2 台の NSX Controller に再分散されます。このワークロードの再分散も、マスターによって実施されます。マスターを選出する際は、クラスタ内にある全ノードの過半数票が必要となります。これが、NSX Controller クラスタのノード数が奇数である 3 台必要な理由です。

また、ホスト障害への可用性を担保するため、それぞれの NSX Controller は異なるホスト上に立てる必要があります。このように、NSX Controller は障害が発生した場合でもサービスが継続して提供できるようなアーキテクチャになっています。

図 10 NSX Controller 間でのワークロードの再分散

ちなみに、仮に NSX Controller 全台に障害が発生するという事態が起きたとしたらどうなると思いますか?仮想マシンの通信が止まってしまう…なんて心配はありません!なぜなら、 ESXi ホストは NSX Controller から配布された情報を自身で保持していますし、データトラフィックはデータプレーンに属しており制御プレーンである NSX Controller を経由しないからです。

NSX Controller が 3 台立てられる理由、お分かりいただけたでしょうか。それでは続けて、ハイパーバイザー カーネル モジュールについてご紹介していきます。

 

4. ハイパーバイザー カーネル モジュールについて

4.1 役割

ハイパーバイザー カーネル モジュールとは、データプレーンに属しており、ESXi ホストにインストールされます。カーネルモジュールによって、NSX Data Center では論理スイッチ、分散論理ルータ、分散ファイアウォールを提供できるようになります。ESXi ホストのカーネル内には分散仮想スイッチ(vDS: vSphere Distributed Switch)と呼ばれる仮想スイッチが存在する、というのは前回の記事でご認識いただいていると思いますが、カーネルモジュールのインストールによってこの vDS の機能が拡張されます。つまり、カーネルモジュールをホストのカーネルにインストールすることは、vDS に更に論理スイッチ、分散論理ルータ、分散ファイアウォールの機能を持たせることと同義です。

4.2 展開方法

ハイパーバイザー カーネル モジュールは、NSX Manager によって各ホストのカーネルに対してインストールされます。インストールは、NSX Manager と紐づいている vCenter Server で管理されているクラスタ単位で実施されます。

図 11 ホストへの NSX Data Center コンポーネントインストール

4.3 機能

ハイパーバイザー カーネル モジュールが提供する機能は、主に2つあります。

① 論理スイッチング・分散論理ルーティングの処理

図 12 分散論理ルータによるルーティング

カーネル モジュールのインストールは、ホスト上に論理スイッチ、分散論理ルータの機能を追加することと同様だと先ほどお話ししました。例えば、同じホスト上に異なるセグメントの仮想マシンが存在する状況でお互い通信をする場合、カーネル モジュールがルーティングの処理をしてくれます。

② NSX Manager 上で設定された分散ファイアウォールルールの反映

図 13 分散ファイアウォールルールの適用

NSX Data Center では、vDS のポートグループや仮想マシンの vNIC など、様々なオブジェクトに対して分散ファイアウォールルールを設定できます。NSX Manager で作成した分散ファイアウォールルールは、各ホストのカーネルモジュールによって管理・処理されます。NSX Data Center ではこの分散ファイアウォールと、NSX Edge が提供する境界ファイアウォールという 2 つのファイアウォールが提供されます。これらのファイアウォールについては、第 6 回で詳しくご紹介していきます。

 

5. おわりに

図 14 サンプル構成図 NSX Manager、NSX Controller 追加後

今回は NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールについてご説明してきました。それぞれのコンポーネントが果たす役割や機能についてご理解いただけたでしょうか?この 3 つのコンポーネントが分かると、次回以降の記事で紹介される論理スイッチ、分散論理ルータ、分散ファイアウォールといった NSX Data Center が提供するネットワークサービスの仕組みをより理解しやすくなります。次回は NSX Data Center の L2 ネットワークサービスである論理スイッチをご紹介します。お楽しみに!

 

-VMware SE 甫木 佑美佳

The post 新卒 SE 社員が贈る NSX のキソ︕第 3 回〜NSX Manager・NSX Controller・ハイパーバイザー カーネル モジュールについて〜 appeared first on Japan Cloud Infrastructure Blog.

Viewing all 861 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>