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

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 インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

また、最近はDeep Securityでセキュリティイベントを検出した際に、NSX分散ファイアウォールと連携して該当の仮想デスクトップのネットワーク通信の制御(実質的な隔離)を行うことも可能です。
ウイルスを検出した際に、PCのLANケーブルを抜くようなオペレーションを自動的に実行してくれるというわけですね。(ウイルスの隔離に失敗した場合にだけ隔離するといった細かい制御も可能です。)

自動隔離まで行わない場合でも分散ファイアウォールで仮想デスクトップ環境を使うことの大きなメリットがあります。
それはランサムウェアや標的型サイバー攻撃に対する被害の拡散の防止です。分散ファイアウォールでは仮想デスクトップ同士の通信をブロックするポリシーを1行で書くことができますので、これによって同一セグメントにありながら、ランサムウェアや標的型サイバー攻撃の足がかりとなるマルウェアを実行してしまった場合でも他の端末に対して情報を取得したり、感染を行う“横”の通信(Lateral Movement)をブロックすることができます。これによって被害の拡大を最小限に食い止めることが可能となりますし、その状況を可視化することもできます。

 

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

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

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

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

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

 

まとめ

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.


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

$
0
0

エージェントレス型とエージェントレス型の使い分けのポイント

 

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

前回までエージェントレス型セキュリティ対策を提供するDSVAでウイルス対策、侵入防御をどのような仕組みで提供しているかを解説してきました。
Deep Securityにはエージェントによるセキュリティ保護も可能ですが、うまく使い分けて頂くことでよりセキュアなインフラ環境を構築することが可能です。
今回はこれからDeep Securityの導入を検討している、またはこれから実装する!といった皆様に向けて、エージェントレス型のDeep Security Virtual Appliance(DSVA)とエージェント型Deep Security Agent(DSA)の使い分け、組み合わせのポイントを解説していきたいと思います。

 

DSVA/DSAで提供できる機能の違い

まずは、DSVAとDSAで提供できる機能について見てみましょう。

※GI:VMware NSX にてGuest Introspectionが有効である必要がある機能
※NI:VMware NSX にてNetwork Introspectionが有効である必要がある機能
※OSのバージョン、ディストリビューション毎の対応状況の詳細については、Supported features by platformをご確認ください。

詳細部分で機能、OS毎に対応できる内容に差異がありますが、大枠は上記で確認を頂けると思いますが、特に以下の点は見落としがちな内容ですので、留意してください。

  • DSVAによる推奨設定の検索は、Guest Introspectionが有効である必要がありますので、Linux OSの仮想マシンで侵入防御機能を利用する場合には利用できません。推奨設定の検索を利用する場合にはDSAが必要となります。
  • Webレピュテーションはネットワーク系のプロセスで処理を行うため、DSVA環境ではNetwork Introspectionを有効にする必要があります。
    (Deep Security Virtual Appliance ウイルス対策では不正プログラム対策とWebレピュテーションが利用できますが、Network Introspectionが利用できるVMware NSXライセンスが必要になります。)

 

DSVAとDSAを組み合わせて利用もできる

DSVAはVMware vSphere/VMware NSXと連携をしてセキュリティ機能を提供していますが、DSVAで保護しているESXiホスト上にDSAが導入された仮想マシンを稼動させることも可能です。
Windows系仮想マシンとLinux系仮想マシンでは動作仕様が異なります。

  1. Linux OSの場合
    DSVAによる保護は行われず、DSAがすべてのセキュリティ機能を提供します。(DSVAが稼動するESXiホスト上で、DSAがすべてのセキュリティ機能を提供)

  1. Windows OSの場合
    DSVAとDSAで予め決められたルール(アフィニティルール)に従って、保護機能を分担してセキュリティ機能を提供します。これをコンバインモードといいます。コンバインモードについては次回詳しく解説します。

上記のようにDSVAとDSAが混在した環境でも利用することができるため、サーバ環境で複数の機能を利用したい場合でも柔軟に設計することが可能です。

 

まとめ ~ DSVAとDSAを使い分ける上でのポイント
DSVAとDSAの機能の違いとESXiホスト上での基本的な動作仕様を踏まえて、導入されるケースとして多い組み合わせをいくつかご紹介しておきます。

  • 仮想デスクトップ環境でWindows OSを展開してウイルス対策を行いたい場合にDSVAを利用する。(Webレピュテーションを利用する場合にはVMware NSXでNetwork Introspectionを有効化する必要あり)
  • LinuxサーバとWindowsサーバが混在する、またはWindowsサーバが大多数を占める環境において、Windowsサーバは機能に応じてDSVA、LinuxサーバはDSAにて保護する。
  • セキュリティログ監視、アプリケーションコントロールが利用したいユーザでサーバ環境を全面的にDSAで保護する。実際にはシステム環境に応じてさまざまなケースがあると思いますが、DSVA/DSAそれぞれでできることを理解頂きながら、うまく使い分けて頂ければと思います。

 

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

 

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

Veeam Backup & ReplicationのvSANバックアップ(後編)

$
0
0

こんにちは。株式会社ネットワールドのバックアップ製品担当SEの臼井です。前編では初回ということで、Veeam Backup & Replication(VBR)の概要について、ご紹介させていただきした。後編となる今回はvSAN環境でのVBRについてご紹介してきます。

Veeam Backup & ReplicationのvSANバックアップ(前編)

vSAN対応バックアップソフト

バックアップ製品によって、多少の違いはあるものの、最近ではほとんどバックアップ製品がvSAN対応を謳っていますが、VBRは独自にvSAN上でテストしているだけでなく、VMware様のvSAN認定を受けています。

VMware様のvSAN認定を受けているバックアップソフトは、下記のvSANのCompatibility Guideから確認することができます。

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanps

このブログを書いている時点(2018年5月)では、Data Protectionのタイプで検索すると下記のバックアップ製品がリストされました。VBRも掲載されており、認定済みですので、安心してvSAN環境でご利用いただけます。

 

 

VBRvSANサポート

vSANは2014年3月11日にリリースされたvSphere 5.5 Update1において、vSAN1.0(vSAN 5.5)として最初にリリースされましたが、VBRはその3か月後の2014年6月にリリースしたVBR 7.0 Patch4でいち早くvSANのサポートを開始しました。そして、vSANのバージョンアップに合わせて、VBRも対応し、昨年末にリリースされたVBR 9.5 Update 3では vSAN 6.6.1まで対応しております。

現在はvSphere 6.7がリリースされておりますので、vSANの最新は6.7になりますが、VBRは次のアップデートでvSphere 6.7をサポートする予定になっておりますので、vSAN 6.7もすぐにサポートされることでしょう。

Veeam Backup & Replication support for VMware vSphere

https://www.veeam.com/kb2443

 

vSAN環境でのVBR

VBRのvSAN対応の特徴の1つとして、ストレージ ポリシーベース管理 (SPBM) への対応があります。vSANを使用する場合、パフォーマンスや可用性などの仮想マシンのストレージ要件(冗長化)を仮想マシンストレージポリシーという形で定義します。

 

 

バックアップソフトによっては、デフォルトの仮想マシンストレージポリシー(Virtual SAN Default Storage Policy)以外を割り当てていても、リストアするとデフォルトの仮想マシンストレージポリシーが割り当てられてしまい、リストア後に仮想マシンストレージポリシーの再適用が必要になることがあります。

それに対して、VBRは仮想マシンストレージポリシーを認識し、仮想マシンストレージポリシーの情報を含めてバックアップしているため、仮想マシンストレージポリシーの再適用は不要です。また、バックアップ時と異なる仮想マシンストレージポリシーを割り当ててリストアするといったことも可能です。

 

VxRailでの検証

実際に弊社環境で仮想マシンストレージポリシーがリストアされるのか検証してみました。vSAN環境としてDell EMC社のVxRail を使用し、非vSANのESXiホスト上に展開したData Domain Virtual EditionへDD Boostを使用してバックアップする構成です。

 

 

新規でRAID1-(Mirroring)の仮想マシンストレージポリシーを作成し、バックアップ対象の仮想マシンに割り当ててから、バックアップを取得しました。

 

 

仮想マシンのリストアウィザードのリストア先のデータストアの指定する箇所を見てみると、割り当てていた仮想マシンストレージポリシー(Mirror Policy)が表示されています。

 

 

検証では新しい別の仮想マシンとしてリストアしましたが、元通りに仮想マシンストレージポリシーが適用された状態でリストアされており、VBRが仮想マシンストレージポリシーに対応していることが確認できました。

 

 

vSANバックアップのベストプラクティス

vSAN上でVADPを使用して仮想マシンをバックアップする際、転送モードとしては、SANモードは使用できず、NBD(SSL)モードかHotAddモードのどちらかを使用する必要があります。

 

 

 

 

 

今回のVxRail上での検証では、VBRサーバを仮想マシンで用意しましたが、VBRは転送モードを選択することが可能です。追加でNBDモードとHotAddでバックアップ・リストアの時間がどれほど違うのか検証してみました。

 

 

 

バックアップ結果が下の表になります。47GBの少量のデータの場合、HotAddモードとNBDモードでバックアップ時間に大きな違いはありませんが、プロセスレートでは、HotAddモードはNBDモードの2倍以上のスループットが出ています。1.1TBのデータをバックアップした場合には、バックアップ時間としてもNBDモードはHotAddモードの2.5倍以上の時間がかかりました。

 

 

下の表はリストア時の結果ですが、リストア処理ではData Domain上の重複排除されたデータを元の状態に戻してリストアされる(データストアに書き込まれる)ため、バックアップよりプロセスレートは落ちます。47.6GBのリストアにおいては、NBDモードとHotAddモードは誤差の範囲で差はありませんが、1.1TBのリストアでは差が表れており、HotAddモードの方が早い結果となっています。

 

 

以上の結果から、vSAN環境では物理のバックアップサーバを構成して、NBDモードでバックアップするより、仮想でバックアップサーバを構成してHotAddモードでバックアップした方がより高速にバックアップ・リストアすることができると考えられます。

更に、Data DomainのDD BoostやStoreOnceの Catalystを利用すれば、VBRサーバ上で重複排除処理をしてからバックアップストレージにデータを転送することで、データ転送量を減らし、より高速なバックアップが期待できます。

まとめ

vSAN環境のバックアップの視点でVBRをご紹介させていただきましたが、如何でしたでしょうか?もっと詳しくvSANのバックアップやVBRについて知りたいという方は、お気軽に弊社までご相談いただければ幸いです。弊社ではVBR以外にも多くのバックアップソフトを扱っておりますので、お客様の環境や要件に合わせて最適なバックアップソリューションをご提案させていただきます。

 

執筆者:

株式会社ネットワールド

SI技術本部 ストレージ基盤技術部

ストレージソリューション2課

臼井 守(Usui Mamoru)

■ネットワールド Veeam製品情報

https://www.networld.co.jp/product/veeam/

■ネットワールドらぼ (ネットワールド ブログ)
https://blogs.networld.co.jp/

 

The post Veeam Backup & ReplicationのvSANバックアップ(後編) appeared first on Japan Cloud Infrastructure Blog.

新卒 SE 社員が贈る NSX のキソ︕第 7 回〜NSX Edgeが提供する各種ネットワーク機能〜

$
0
0

こんにちは!「新卒社員が贈る NSX のキソ!」第 7 回を担当する VMware 新卒第 4 期生の村田太郎です。
6 回では、NSX Data Center for vSphere の特徴的な機能である、分散ファイアウォールについてご紹介いたしました。この回では、NSX Data Center が提供する各種ネットワーク機能についてご紹介いたします。

NSX Data Center を導入した vSphere 環境では、NSX Edge を用いることで、ファイアウォール、ロードバランサ、DHCP、NAT などの各種ネットワーク機能を統合的に実現することができます。

今までの仮想環境では、仮想マシンの展開スピードにネットワークの構築が追い付けないという問題がありましたが、今回ご紹介する NSX Data Center の機能を用いることで、仮想マシンの展開スピードに合わせたネットワークの展開が可能になります。サーバ仮想化は、NSX Data Center によるネットワークの仮想化と合わせて使用することで、その真価を発揮すると言えます。

NSX Edge は、5 回でもご紹介した通り、仮想アプライアンスとして簡単に展開することができますので、必要なときにほぼリアルタイムでネットワークサービスを展開することができ、スケールアウトも簡単に実施することが可能です。

システムの運用を進めるにつれてネットワークのパフォーマンスが足りなくなってきた、といった場合、物理機器の買い替えはなかなか難しく、購入しても実際に届くまでには時間がかかりますが、NSX Data Center を利用している環境では NSX Edge の設定を変更するだけですぐに対応することができます。

役割 提供する機能
ルーティング 静的、動的(OSPF、BGP)ルーティング機能
ファイアウォール IP や Port に加え vCenter インスタンスベースで設定できるFW機能
NAT/NAPT 送信先、送信元の NAT 機能
DHCP DHCP サーバ機能、DHCP リレー機能
ロードバランサ TCP/UDP、HTTP、HTTPS サーバ負荷分散機能
IPsec VPN IPsec によるサイト間の VPN 機能
SSL VPN リモートからの SSL VPN アクセス機能
L2 VPN L2 延伸機能

 

それでは、簡単に NSX Data Center の提供する機能についてご紹介いたします。

 

1. ファイアウォール
第 6 回でご紹介した分散ファイアウォールに加え、NSX Edge による境界型ファイアウォールも提供可能です。NSX Edge は、主に North-South トラフィックフローに対するファイアウォール機能を提供します。

NSX Edge のファイアウォールでも、6 回の 2 節でご紹介した分散ファイアウォールと同様に、IP アドレスによる指定だけでなく、vCenter のオブジェクト単位でルールを作成することができます。

vCenter のオブジェクト単位で設定が可能であるということは、例えば「仮想マシン A から仮想マシン B への通信を禁止」というような設定ができるということです。仮想マシンの IP アドレスが変わったり、 vMotion などによって利用する物理ポートが変わったりしてもファイアウォールルールが仮想マシンに追従できるというメリットがあります。

図 1 Edge FW の設定画面

 

2. NAT/NAPT
NAT/NAPT(Network Address Translation/Network Address and Port Translation)は、IP アドレスを変換する機能です。IP アドレスを節約したい場合や、外部に社内 IP アドレスを公開したくない場合、システム統合時のテナント間での IP 重複を回避する場合などに用いられます。

NSX Edge では、NSX Edge を経由する通信に対して、SNAT(送信元 NAT)と DNAT(送信先NAT)を提供することができます。SNAT は送信元の IP アドレスを変換する機能、DNAT は送信先の IP アドレスを変換する機能です。

 

図 2 Edge NAT の設定画面

図 3 SNAT の動作

図 4 DNAT の動作

 

3. ロードバランサ
NSX Edge ロードバランサでは、アプリケーション要求、サービス要求をプール内の複数のバックエンドサーバ間に分散することができます。ロードバランサを使用する際には、ユーザがアクセスする際に使用する VIP アドレス(仮想 IP アドレス)と、実際にサービスを提供するサーバのプールを用意します。
例:VIP アドレス – 192.168.1.1 ポート 80、サーバプール – 10.10.10.1 から 10.10.10.3

NSX Edge ロードバランサでは以下のようなプロトコル、機能が提供されます。

NSX Edge ロードバランサの機能 内容
サポートされるプロトコル TCP/UDP

HTTP

HTTPS (SSL パススルー)

HTTPS (SSL オフロード)

ロードバランシングの方法 ラウンドロビン

送信元IP のハッシュ

最小接続数

URI/HTTP ヘッダ/URL

 

NSX Edge ロードバランサのデザインとしては、ワンアームロードバランサとインラインロードバランサの 2 種類が存在します。

図 5 ワンアームロードバランサ

ワンアーム構成では、NSX Edge はロードバランス対象の仮想マシンと同じセグメントに存在し、その名の通り、ネットワークと 1 つのリンクでつながるデザインとなります。

アクセスの流れは以下のようになります。
① 外部クライアントからロードバランサによって外部に公開されている VIP アドレスにパケットを送信する。
② ロードバランサはクライアントから受け取ったパケットに対しアドレス変換を行い、送信元 IP アドレスをロードバランサのアドレスへ、送信先 IP アドレスを VIP からサーバプール内の 1 台のサーバの IP アドレスに変換します(SNAT/DNAT)。
どのサーバが選択されるかは設定されたアルゴリズムによって異なります。
③ パケットを受け取ったサーバは、クライアントへのパケットをロードバランサに送信。
④ ロードバランサは再度 SNAT/DNAT を行い、送信元を VIP、送信先を外部クライアントとしてパケットを送信します。

ワンアーム型のロードバランサは、展開と構成がシンプルで、既存の NSX Edge に手を加えずに済む、ロードバランサの障害時の影響範囲が少ないなどのメリットがあります。

図 6 インラインロードバランサ

インライン構成では、NSX Edge をサーバプールのセグメントと外部セグメントとの境界に配置し、2 つのリンクでそれぞれに接続するデザインとなります。

インラインロードバランサ利用時のアクセスの流れは以下のようになります。
① 外部クライアントは、ロードバランサによって外部に公開された VIP アドレスにパケットを送信します。
② ロードバランサは DNAT により外部クライアントから受け取ったパケットの宛先を VIP から設定されたアルゴリズムに従いサーバプールに展開されているサーバの内の 1 台の IP アドレスに変換します。
③ サーバは、元のクライアントの IP アドレスを宛先 IP アドレスとして、ロードバランサにパケットを送信します。これは、上記の構成では NSX Edge ロードバランサがインラインで展開されており、サーバのデフォルトゲートウェイであるためです。
④ ロードバランサはサーバから受け取ったパケットに対して SNAT を実行し、送信元を自身の VIP に変換したうえで外部クライアントに送信します。

ワンアーム型との違いは、インライン型の場合はサーバにクライアントのアドレスが透過的であるということが挙げられます。また、インライン構成では内部セグメントと外部セグメントの中間にロードバランサが配置されるので、内部セグメントを外部から隠ぺいすることができるというメリットもあります。

インライン構成時には、サーバプール内のサーバで NSX Edge ゲートウェイがデフォルトゲートウェイとして指定されている必要があります。

 

4. IPsec VPN/SSL VPN/L2 VPN
NSX Data Center では、IPsec VPN、SSL VPN、L2 VPN の 3 種類の VPN をサポートしています。それぞれ、拠点間の VPN 接続、クライアントのリモート接続、データセンター間の接続に利用されます。

図 7 VPN の設定画面

図 8 IPsec VPN

図 9 SSL-VPN

図 10 L2 VPN

 

5. NSX Edge の高可用性
少しここまでの流れと話が変わりますが、NSX Edge には個別の機能として高可用性機能(HA)が存在します。NSX Edge で HA を有効化するには、設定画面で有効化ボタンをクリックするだけです。有効化すると、HA 用の NSX Edge が追加され、片方がアクティブ、もう片方はスタンバイ状態になります。

図 11 NSX Edge HA の設定画面

物理機器でロードバランサなどの機能を実現して可用性を担保するためには、同一の製品を 2 台購入し、配線し、HA の設定も複雑で、可用性を上げるはずがトラブルの原因になることもありました。これが NSX Edge の場合は設定画面から有効を選ぶだけで完了します。これもソフトウェアだからこそなせる業です。

 

6. おわりに
今回は、NSX Edge が提供する主要なネットワーク機能についてお話してきました。
NSX Edge を用いると、さまざまなネットワーク機能を簡単に展開することができるようになります。

この回の冒頭でも申し上げましたが、仮想環境は NSX Data Center を用いることでその真価を発揮します。NSX Data Center のメリットは、何と言っても今までご紹介した機能をすべてソフトウェアとして提供できることにあります。

今まで仮想サーバの展開が数クリックで終了していたとしても、サービスを開始するまでには物理環境上でさまざまな作業が必要でした。物理機器の選定をし、ラッキングして、配線して、バージョンアップや管理系の初期設定をして、、、これらの物理作業は NSX Data Center を使うことですべて不要になります。ほんの数クリックで新規ネットワークセグメントを作成したり、ロードバランサ、ファイアウォールの設定を行うことも可能です。物理配線を変えることなくネットワーク構成の変更も行えますし、トラフィック量が増えた場合に物理機器を購入することなく性能を向上させることも可能です。ネットワークが不要になった場合は簡単にネットワークの削除、リソースの開放ができます。

これらは物理ネットワーク環境では考えられなかった運用方法で、NSX Data Center だからこそ実現できることです。

 

さて、今まで 1 データセンターでの NSX Data Center の利用に関する説明をしてきました。NSX Data Center は複数のデータセンターにまたがる展開も可能であり、そういった環境でこそ活きる機能も持っています。

次の回では、複数データセンターにまたがった NSX Data Center に関してご紹介いたします。ご期待ください。

 

コラム ~ ハンズオンラボ(HOL)~
みなさんはVMware のハンズオンラボというものをご存知でしょうか?ハンズオンラボとは、簡単に言うとVMware の製品のお試し環境のことで、VMware の提供するさまざまな製品を実際に触ってみることができます。
このコラムでは、ハンズオンラボの使い方を簡単に説明いたします。

まず、ウェブブラウザで次のリンクにアクセスします。
https://www.vmware.com/jp/try-vmware/try-hands-on-labs.html
すると図 12 のような画面になるので、「VMware NSX:入門」の [ラボを開始する] をクリックします。

図 12 VMware HOL

図 13 VMware NSX ハンズオンラボ

既に My VMware のアカウントをお持ちの方はそのアカウントのメールアドレスとパスワードを用いてログインします。お持ちでない方は [アカウントの作成] からアカウントを作成したのち、ログインします。ログインが完了したら [開始] をクリックしてハンズオンラボを開始します。

図 14 HOL コンソール画面

右上の [LANGUAGE] をクリックし、日本語を選択するとハンズオン環境の日本語化ができます(図 15)。既に日本語環境になっている場合はそのままで OK です。

図 15 日本語への言語変更

図 16 Chrome の言語設定

このラボ環境内で用いるブラウザ(Google Chrome)の設定もデフォルトでは英語になっていますが、Google Chrome の右上のアイコンから Japanese を選択すると言語を日本語にすることができます(図 16)。2 重に設定がありややこしいですが、ハンズオンラボの環境と、ハンズオンラボで利用する仮想端末内のブラウザの設定です。

図 17 HOL の vSphere Web Client 画面

これでハンズオン環境への接続は完了です。あとは、右側のハンズオンガイドに従って機能を試してみるのもよし、自分で自由に触ってみるのもよしです。今まで説明してきたさまざまな機能、メリットをぜひ体感してみてください。

ハンズオンラボについてはこちらもぜひ御覧ください!
ハンズオンラボの始め方など、動画付きで詳しくご紹介しています。

The post 新卒 SE 社員が贈る NSX のキソ︕第 7 回〜NSX Edgeが提供する各種ネットワーク機能〜 appeared first on Japan Cloud Infrastructure Blog.

新卒 SE 社員が贈る NSX のキソ!第 8 回~Cross-vCenter NSX で実現するマルチサイト環境~

$
0
0

おひさしぶりです。第 1 回からご無沙汰しておりました大田です。
この回は最終回になります。「新卒 SE 社員が贈る NSX のキソ!」最終回のテーマはこちら!「Cross-vCenter NSX」
うわ、なに Cross て!ていうかもう NSX Data Centerでなにができるかわかったんだけどまだあるの?サンプル構成完成したじゃん!
そうです、まだあるのです。皆様はまだ NSX Data Center の最強奥義を知らないのです。最終奥義を習得しないと、この NSX Data Centerアドベンチャーは全クリできません!それはもったいない!あれ、何の話でしたっけ。とにかく、最後に Cross-vCenter NSX を理解して、気持ちよく終わりましょう。

1. 一般的な企業の事情
世の中には色々な事情がありますが、企業にも当然色々な事情があります。

事情① 災害が起きた時も事業を継続するための対策考えなきゃ!
事情② 海外にも事業を展開してガンガン成長するぞ!
事情③ 買収だ!合併だ!てんやわんや!
事情④ 古いデータセンターから新しいデータセンターに移行しなきゃ(汗)
事情⑤ あっちとこっちに 2 個データセンター持ってるけど、あっち余裕そうだからちょっと使わせてほしいなー。。

。。。と、このような事情から、企業はすでにマルチサイトでデータセンターを複数もっていたり、あるいはマルチサイトでデータセンターがほしくなったりするわけです。そして、すでに持っている場合にも、これからほしいという場合にも、いずれにせよせっかく複数あるのだからたとえ災害対策用だけにあるサイトだとしても Active-Standby ではなく Active-Active で上手いこと日ごろからサイトを意識せずに仮想マシン(以下 VM)を稼働させてどちらのサイトも有効活用できないかなと思うところではないでしょうか。

図 1 複数拠点のデータセンターの扱い

ということで、従来の別々のデータセンターをそのまま利用しようとしたら、どのような問題が生じるかといいますと、

・サイトをまたいだ vMotion には IP アドレスの変更が必要→システム停止
・IP アドレスの変更に伴い物理ネットワーク構成やロードバランスの設定変更が生じることも
・セキュリティポリシーは手動で同期したり、vMotion 時に設定変更の必要が生じたりする

といった具合に、サイト内の仮想マシン移行なら難なくできるどころかもはやこっちがvMotion しているつもりがなくても勝手に物理サーバの負荷を見て vCenter がよしなに vMotion してくれているくらいなのに、ネットワークをまたいでサイト間でワークロードを移行しようとした途端に影響範囲が物理構成やセキュリティ設定まで非常に大きい話になってしまい、一言で言うと「こんなのやだ!」といった状況でした。

図 2 データセンター間のワークロード移行

2. 従来のマルチサイトソリューション
では、今まで「こんなのやだ!」で終わりにしていたのかといいますと、そうではありません。データセンター内では簡単に移行でも負荷分散でも何でもできるんだからということで、複数サイトをまたいでも、まるで 1 つのデータセンターかのように扱えるように工夫しよう!ということで、L2 ネットワークを延伸しデータセンター間で 1 つのネットワーク環境を作るための様々なソリューションが生まれました。そんな今までの文明の利器を軽くご紹介したいと思います。突然専門用語が出てきたりしますが、「実に興味深い」程度でスルーしていただいて大丈夫です。

① キャリアの広域 Ethernet サービス+STP

図 3 キャリアの L2 サービスを借りるの巻

通信キャリアが提供する L2 サービス(広域 Ethernet)を使用するというのはどうでしょう。うんうん、L2 サービスね、、、ん?なんか赤字の Block Port っていうのが気になりますね。今この図、なんで黄緑の線が 2 本あるのかというと、1 本だと物理的な障害が起きた時に一発アウト!…っていうのを防ぐためです。こうやって物理障害対策で冗長構成を取ると、L2 のEthernet フレームはその仕組み上延々とループしてしまうことがあり、それを防ぐためにはこのようにBlock Port を作らなくてはならないのです。この技術を STP (スパニングツリープロトコル)といいますが、ざっくり言うとこちら管理がすごく大変です。これが 3 拠点とかになっちゃったら、もっと大変です、つまり拡張性に欠けています。しかもそもそも、Block Port の存在自体、Mottainai!そして設定ミスか何かでもしサイトをまたいだ広範囲でループを起こしたら、つまりブロードキャストストームを起こしたら、、、全シャットダウンで大惨事、なんてこともありえるのです。L2 サービス自体には様々なメリットもあるかと思いますが、大切なデータセンター間を STP で直接 L2 接続っていうのは、あまり現実的ではないでしょう。

② キャリアサービス or ダークファイバの上で専用のハードウェアによるオーバーレイの実装

図 4 専用ハードウェアによるオーバーレイ

こちらもまずはキャリアのネットワークを借りるか、ダークファイバというただの線を借りてネットワークを構築し、その上にオーバーレイネットワークを、秘密道具、「専用ハードウェア」によって構築する(例:MPLS/VPLS or EVPN ・ OTV)という方法です。つまりやりたいことはハードウェアがやってくれますが、ハードウェアを購入する手続きとか、サポートの期間とか、なんだか腰が重いですね。。。やっていることといえば、片方のサイトで作られた Ethernet フレームにさらにヘッダをかぶせてなにかのプロトコルでなんやかんやで宛先のサイトにお届けして、ついたところでしれっとヘッダを外し、宛先のサイトからしたら、これまで IP ヘッダやら MPLS のラベルやらつけられていたことなどつゆ知らずのんきに Ethernet フレームを受け取り、はい、L2 延伸のできあがり~、、と、第 4 回でもお伝えしたトンネリングの技術です。

このように 2 つの手法をご紹介させていただきましたが、何か思いませんでしたか?この 2 つ、どちらも物理ネットワークの世界でなにかしら頑張っているんですね。①だと L2 ネットワークの上で頑張って STP を設定する、②だと専用のハードウェアに物理ネットワークのトンネリングを頑張ってもらう。。。でももっとシンプルに、それぞれのデータセンター内で設定をいじっただけでそのデータセンター同士が L2 でつながっちゃった、みたいな、お手軽なこと、ソフトウェアで頑張れないの?って思いませんか?だって NSX Data Centerでネットワークは仮想化されて仮想環境内にソフトウェアで定義されてるんですし、物理ネットワークを延伸するんじゃなくて、それぞれのデータセンターで仮想化されたネットワークをデータセンター同士でソフトウェア的につながっていると認識してくれればよくない?と。はい、お察しの通り、それを実現できるのが Cross-vCenter NSX の機能となりますので、前置きが長くなりましたが本題に入りたいと思います。

3. Cross-vCenter NSX 概要
Cross-vCenter NSX とはズバリ、「複数サイトをまたいで 1 つの仮想ネットワーク環境を構築することを実現する NSX Data Centerの機能」です。言葉では伝わりにくいので、図にします。

図 5 物理ネットワーク延伸

今まで L2 延伸をしようとしたら、物理ネットワークを延伸しようとするので、物理ネットワークの領域でがちゃがちゃと工夫をする必要がありました。

図 6 仮想ネットワーク延伸

NSX Data Centerでは、ネットワークは物理ではなく仮想環境で定義されていますので、物理的に頑張る必要はありません。サイト 1 に存在する仮想的なネットワークセグメントが、サイト 2 にも仮想的に存在すればいいのです。このようなことは、ネットワークが仮想化されなければ不可能であり、逆に言えば、ネットワークが仮想化された環境においては当然ともいえる仕組みではないでしょうか。

と、ここまで物理ネットワークの延伸と仮想ネットワークの延伸の比較という観点でご説明してきましたが、前回まで説明していた NSX Data Centerのネットワーク世界の観点で図にすると、次のようになります。
まず、NSX Data Centerを各サイトに導入しているものの、Cross-vCenter NSX の機能は使用しないといった場合、このような図になります。

図 7 Cross-vCenter NSX 以前

それと比較して、Cross-vCenter NSX を導入した環境は、このような構成となります。

図 8 Cross-vCenter NSX 以後

前回までは、1 つの vCenter 配下に、NSX Manager と NSX Controller がそれぞれ存在し、ルーティングや FW ルールの情報については 1 つの vCenter 配下で完結しておりました。
Cross-vCenter NSX では、1 つのサイトの NSX Manager がプライマリロールを持ち、ルーティングや FW ルールの情報をほかのサイトのセカンダリ NSX Manager と同期し、1 つの NSX Controller クラスタが複数サイトにまたがって一貫したルーティング情報や FW ルールの情報をすべてのホストにプッシュするといった形になり、サイト 間で情報の一貫性を保ちます。これらの設定は、全て今まで通り、vSphere Web Client のコンソールから設定をポチポチするだけで実現でき、物理ネットワークの設定や構成は全く触る必要がありません!(サイト間で物理的にルーティングが可能であることは前提となりますが。)この「L2 延伸をソフトウェア的な設定だけでお手軽に実現できる!」ということ自体が、従来の物理的な L2 延伸の費用や大がかりな作業を削減するという意味で Cross-vCenter NSX のすごいメリットとなります。

4. Cross-vCenter NSX の使いどころ
ということで、L2 延伸それ自体について、従来との比較をさせていただきましたが、Cross-vCenter NSX を導入する気になりましたか?。。。。。。実際に Cross-vCenter NSX を導入して、どんなことを実現できるのかがわからないと、わざわざ Cross-vCenter NSX なんてしませんよね。ということで、ここからは Cross-vCenter NSX がどんな場面で力を発揮するのか、しっかりお伝えしたいと思います。

その 1:災害用サイトリソースの有効活用
たとえば、東京にデータセンターを持っていて、東京でなにか災害があったときのために、東京ではないどこかにもデータセンターをもっているとしましょう。

図 9 災害用のマルチサイト構成

従来でしたら、普段のデータセンターと災害時用データセンターはネットワーク的に完全に違うセグメントにおり、災害が起きた時だけアクセス先をバシっと切り替える形になりますが、普段は災害時用のサイトは完全に災害に備えて静かにスタンバっているということになります。これ、もったいなくないですか?こう、うまいこと工夫して、災害時の事業継続性も確保しつつ、2 つのデータセンターのリソースをもっと活用できないですかね?うーん、、、、あ、こんなのはどうでしょう。

図 10 システムごとにアクティブとなるサイトを分散

このように、システムごとにアクティブになるサイトをばらけさせる方法がとれると思います。これなら、どちらかのサイトが障害にあったときに、生きている方のサイトで元々稼働していた VM は引き続きそちらで稼働し、障害にあった VM のみリカバリさせればいいですね。でも、これ、どこに Cross-vCenter NSX を活用する必要があるんでしょう?
1 つ目に、障害時のサイト切替にあたって、VM の IP アドレスを変更する必要がないというところがポイントになります。今まででしたら、別サイトでリカバリする際に、別サイトは違うセグメントになるので、切替用の IP アドレスを事前に設定する必要がありましたが、これからは単純にサイトが変わるだけでネットワーク的な変更は無し、ということになり、よりリカバリ作業が単純な話になります。
2 つ目に、今までだと FW ルールがサイト間で共有されず、サイト障害に備えてどちらのサイトにも同じ FW ルールを設定する必要がありました。こちら、口だけで言うと簡単そうですが、L2 延伸無しの場合 VM が移行先で IP アドレスを変更しているので、単純に FW ルールをコピーすればいいという話ではないのです。そのような状態で図 10 のような構成をしようとしたら、どうでしょう?えーと、システム A は災害用サイトではこんな IP アドレスで、セキュリティポリシーは、、、といった設定を、2 つのサイトでシステムごとにごちゃごちゃ計画・実施しなくてはならないんですね。そもそも、災害対策なんて、実際に災害が起きた時にしか必要ないしコストでしかないのに、こんなに苦労したくないというのが企業の本音ですよね。

その 2:マルチサイトでかしこく経路選択
以前にもご紹介した、NSX Data Centerの賢いルーティング経路選択について、サイトをまたいだ場合にはどうなるのか、ご紹介します。

図 11 マルチサイトのネットワーク

図 11 は、マルチサイトにおけるネットワークを少々詳しく表しております。ユニバーサル分散論理ルータは、今までご紹介した分散論理ルータと同じ役割をもち、この図に 1 つ書いてある NSX Controller Cluster が、別サイトのホストにも同じルーティング情報を一生懸命お届けしております。

図 12 別サイトに移行したい VM

注:DGW=Default Gate Way, UDLR=Universal Distributed logical router(ユニバーサル分散論理ルーター)

さて、ここで落ち着きのない VM 君が現れたようです。どうやら今いるサイトでリソースが足りてなくて、もう 1 つのサイトに移動したいようです。この VM のネットワーク設定において、デフォルトゲートウェイはいつでもどこでも分散論理ルータになります。そう、たとえサイトを移動しても、この VM がおしゃべりしたいエンドポイントとセグメントをまたいだ通信をするには、VM が送信したパケット君は、分散論理ルータ、つまり VM がそのとき乗っているホストにこう聞くのです。「ネクストホップはー?」

仮にこの VM がインターネット上のエンドポイントと通信したいとしましょう。インターネットにいくには、パケット君は一度仮想環境から脱出しなくてはなりません。仮想環境と物理環境の窓口は Edge ルータになります。ここで問題です、インターネットに出るためには、もし VM 君が別サイトに移行しても、同じ Edge ルータを通る必要があるでしょうか??

図 13 移行した VM の物理ネットワークへの出口

答えは NO です。ユニバーサル分散論理ルータは、どのホスト上でも冷静にルーティングします。インターネットに出たいなら、普通にその VM がいるホストから 1 番いきやすく、インターネット上のエンドポイントにパケット君が最短で到着できる Edge にルーティングするのです。これ自体はルーティングという観点でいうとごくごく普通の話ですが、従来こんな風に分散してルーティングする機能なんてありましたっけ?この機能があるから、移行しても変わらず VM 君のデフォルトゲートウェイはホスト上に散らばっている分散論理ルータの IP アドレスのままでいいのです。しかし物理環境へのゲートウェイという意味だと、VM の設定は変えずに、勝手に最適なゲートウェイが選択されるという意味で、まるで VM のゲートウェイ設定が自動で適切に変更されているようですね。この機能、あたりまえのようで、あたりまえではないのです!

5. さらなるポイント:ハイブリッド環境の将来像
最近ハイブリッドクラウド環境に移行している企業は多くあると思います。移行作業、大変じゃないですか?FW ルールなど色々な設定をパブリッククラウド側で用意して、移行して、IP アドレスとかデフォルトゲートウェイとか設定しなおして、、、って、VM たちがめっちゃダルがっていますね既に。オンプレミスとパブリッククラウドをまたいで NSX Data Center で 1 つの仮想ネットワークを構築すれば、VM にとってパブリッククラウドへの移行はホスト間の vMotion となんら変わらなくなります。ユーザーからしても当然 VM 自体にネットワーク的にも FW ルール的にもなんの変化もないのですからハイブリッド環境であるからといって気にしなければならないことがなくなります。このようなことは、クラウドプロバイダーの IaaS を利用してオンプレミスと IaaS 間で NSX Data Centerを構築すれば実現可能です!これを活用すれば、移行作業の計画に長い間骨を折るのではなく、Cross-vCenter NSX の構築さえすれば移行自体は通常の vMotion と変わらないスタンスで実行することができますね。
また、パブリッククラウドを活用し、インフラ管理から解放されるということ以外のもう一つの重要なメリットとして、必要なときに必要な分だけ使って、従量課金ができるというポイントがありますので、これについて考えてみましょう。ある一定の時期だけめちゃくちゃ利用負荷が増える Web サーバーがあったとします。例えばキャンペーン中だけアクセスが 10 倍になるとか。こんなとき、その 10 倍のアクセスに備えて自社のデータセンターに 10 倍のアクセスが必要になったときに必要なリソースを常にスタンバらせておきたいですか?普段全然使わないのに。うーん、、嫌ですね。絶対嫌だ!じゃあ、パブリッククラウドをその時だけ使えばよくないですか?
でも、簡単にはいかないですよね。だって、リソースが足りなくなりそうになったらパブリッククラウドに移行するっていったって、IP アドレス体系変えなきゃだし、Web サーバだけ増やしたいのに IP アドレス体系変えたら App サーバに通信できるようにルーティング設定しなきゃ。FW ルールだって事前にパブリッククラウド側にも準備しておかなきゃ。。。
こんなとき、もしオンプレミス環境と従量課金のパブリッククラウド環境を、先ほどご紹介したサイト間 L2 延伸と同様につなぐことができたら、こうなります。

図 14 VM にとってオンプレミスかパブリックか全く関係ない様子

いやいや、こんなこと、ほんとにできるの?と、この雑すぎる図解を見る限りでは到底真に受けられないかと思いますが、実際にすでにこのようなことが我々のテクノロジーで実現が可能になってきております。Cross-vCenter NSX でマルチサイト間で実現していることと同様に、パブリッククラウドと複数サイトのオンプレミスを含めて統合的なネットワークやセキュリティポリシーで管理運用できる将来もすぐそこに実現できる段階にきつつあります!弊社の Vision としては、このようにサーバやストレージ、ネットワークといった物理インフラ環境に左右されない柔軟な世界を創りたく、さらに将来的にはパブリッククラウドすらも自由に選択できるような、人間様のご都合に難なく適応してくれるインフラ環境を作るべく絶賛奮闘中です!乞うご期待!

6.おわりに
さあ、遂に最終回もまとめに入ってしまいましたが、この回はお伝えしたことが多かったので内容を整理したいと思います。

まず初めに、企業が複数データセンターを持つにいたる事情を色々と上げさせていただきました。
次に、複数データセンターをひとまとめに扱うために、従来物理ネットワークの範疇でお金や手間をかけて頑張らなくてはならなかったということをお伝えしました。
そして、Cross-vCenter NSX では複数データセンターをソフトウェア的に 1 つのデータセンターのように扱うことが可能になるということをご紹介し、それ自体が従来の手間と比較してメリットになるということと、L2 延伸、FW ルールの共有によってワークロード移行の手間が軽減され災害対策の工数の簡素化やリソースの有効活用、そして経路選択の最適化といった具体的なメリットもご紹介させていただきました。実のところ、ユースケースとしてお伝えできることはまだまだたくさんありますが、今回はぐっとこらえて、皆様の探求欲、クリエイティビティを刺激したところで締めさせていただきたいと思います。最後の最後になりましたが、この冊子では、NSX という名の下の NSX Data Center for vSphere について解説してきました。実は NSX SD-WAN、NSX Cloud、NSX Hybrid Connect、など続々と仮想ネットワークを支える NSX ファミリーが弊社のラインナップに加わっております。こちらの最新情報もぜひチェックしていただき、VMware NSX による仮想ネットワークの最先端を一緒に突っ走りましょう!それでは、またいつか!

-VMware SE 大田愛里香

The post 新卒 SE 社員が贈る NSX のキソ!第 8 回~Cross-vCenter NSX で実現するマルチサイト環境~ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

コンバインモードの正しい理解と知っておきたいこと

 

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

前回、DSVADSAの使い分けについて解説をしましたが、Deep Security Virtual ApplianceDSVA)で保護しているESXiホスト上にDeep Security Agent(DSA)がインストールされたWindows仮想マシンが配置された場合、Deep Securityでは“コンバインモード”というモードで動作します。
コンバインモードについては、誤解しやすい点もあるので、今回はその正しい理解と抑えておいていただきたい点をまとめてお伝えしたいと思います。

 

コンバインモードの有効化と状態

前回のブログにも書きましたが、コンバインモードが有効化されるのはWindows仮想マシンのみとなります。
コンバインモードを有効にするために必要な設定は特段ありません。対象の仮想マシンが DSVA で保護可能な状態になっており、かつDSA がインストールされていると自動的にコンバインモードによる保護が有効になります。そして、コンバインモードが有効になるのはWindows OSのみです。(前回も解説しましたが、設定が特に必要ないという点では、DSAをインストールしたLinux OSをDSVAが稼動しているESXiホスト上で動作させる際にDSAでの保護が自動的に継続されることと共通しています。詳細は前回ブログをご確認ください。)

コンバインモードで動作していることは、Deep Security ManagerDSM)コンソール、DSAがインストールされたWindows OSのタスクトレイから確認することができます。

Deep Security Managerコンソール

■Deep Security Agentタスクトレイ

 

コンバインモードのアフィニティルール

コンバインモードでは、機能群ごとにDSA、DSVAどちらの防御コンポーネントで保護を実施するか(保護ソース)選択できるようになっています。
デフォルトでは以下のように動作するように設定されています。

  • 不正プログラム対策                 Appliance優先
  • Web レピュテーション/ファイアウォール/侵入防御   Agent優先
  • 変更監視                      Appliance優先

DSVAで対応していない機能であるセキュリティログ監視、アプリケーションコントロールは、DSAでの保護となるためコンバインモードのアフィニティルールの設定項目はありません。
また、コンバインモードはDeep Security 9.6から実装された機能ですが、アフィニティルールをデフォルトの設定から変更できるのはDeep Security 10.0以降になります。

機能群毎に選択できるコンポーネントの保護ソースの選択には以下の4つがあります。

  • Appliance 優先 : Appliance 有効化不可時に Agent にてセキュリティ機能を提供
  • Agent優先   : Agent 有効化不可時に Appliance にてセキュリティ機能を提供
  • Appliance のみ : Appliance 有効化不可時に Agent でのセキュリティ機能の移行を行わない
  • Agentのみ   : Agent 有効化不可時に Appliance でのセキュリティ機能の移行を行わない

このアフィニティルールの設定は、利用したい機能と仮想マシンに対するDeep Securityの機能利用による負荷を考慮して適宜変更することが可能です。

 

コンバインモードの保護ソースの変更のトリガー

Appliance優先、Agent優先を選択した場合、選択された保護ソース(DSVAまたはDSA)が無効化された場合に、もう一方の保護ソース(DSAまたはDSVA)に保護機能を移行するためのDSMからポリシーの配信が実行され、保護ソースが変更されます。各機能のステータスにエラーがあった場合などに保護ソースが変更されるようなフェイルオーバー(エラーに備えた冗長化)には対応していませんので、留意してください。

 

コンバインモード利用にあたって知っておくべきこと

コンバインモードの利用にあたって、知っておいて頂きたい点をいくつか挙げておきたいと思います。

  • Appliance優先、Agent優先を選択した場合、前述のとおりDSMからのポリシー配信が実行されます。Appliance優先でAgentに保護ソースが切り替わった場合、該当の機能モジュールがインストールされていない場合、機能モジュールのインストールが行われた後、ポリシーの配信が行われます。コンバインモードの保護ソース変更時にモジュールの自動インストールをさせたくない場合にはあらかじめ機能モジュールをインストールしておくか、Applianceのみを選択する必要があります。
  • コンバインモードでは、DSVA による保護を仮想マシン単位で無効化することはできません。
  • Deep Security Virtual ApplianceのCPU課金、かつ、侵入防御・ファイアウォール・Webレピュテーションを利用できるライセンスをご購入いただいている場合に限り、DSAで上記の機能を実装することが許諾されています。(vShield Endpoint環境でDSVAを利用していた場合に利用できた機能をDSAにて補完するための措置)ライセンスの詳細はこちらをご覧ください。

まとめ ~ DSVAとDSAを使い分ける上でのポイント

コンバインモードについてご理解をいただけたでしょうか?
少し複雑な部分もありますが、ポイントを抑えてコンバインモードもうまく活用を頂ければと思っております。
コンバインモードについてはこちらのFAQにも記載されておりますので、ご参照ください。

 

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

 

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

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

$
0
0

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

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

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

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

◆ポートバインド

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

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

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

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

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

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

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

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

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

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

◆ポート単位の管理

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

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

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

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

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

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

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

◆監視機能

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

<NetFlow>

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

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

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

<ポート状態の監視>

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

<アラーム>

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

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

<参考>

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

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

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

◆まとめ

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

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

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

The post 仮想スイッチのお作法~標準スイッチから分散スイッチへの道~ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

<ロールバック>

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

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

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

<リストア>

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

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

  • Restore Network Settings
  • Restore Standard Switch
  • Restore vDS

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

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

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

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

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

<KBのご紹介>

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

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

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

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

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

<LACPサポートの強化>

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

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

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

 

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

 

◆まとめ

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

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

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

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

 

The post 仮想スイッチのお作法~分散スイッチの管理②#5~ appeared first on Japan Cloud Infrastructure Blog.


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

$
0
0

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

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

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

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

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

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

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

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

 

 

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

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

 

<バージョン2>

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

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

 

 

 

 

 

 

 

 

 

 

 

 

<バージョン3>

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

 

 

 

 

 

 

 

 

 

 

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

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

 

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

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

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

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

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

 

 

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

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

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

 

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

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

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

 

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

 

 

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

<仮想マシン>

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

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

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

 

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

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

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

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

 

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

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

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

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

 

 

◆まとめ

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

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

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

The post 仮想スイッチのお作法~Network I/O Control#6~ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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

 

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

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

 

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

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

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

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

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

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

 

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

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

Deep Security and VMware compatibility matrix

 

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

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

 

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

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

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

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

 

まとめ

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

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

 

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

 

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

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

 

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

vROps 6.7は初心者に優しい!

$
0
0

1回目:vROps 6.7は初心者に優しい

– Back Number –

#1 … vROps 6.7は初心者に優しい

 

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

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

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

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

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

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

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

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

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

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

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

 

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

 

◆ワークロード◆

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

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

<CPU>

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

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

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

 

<メモリ>

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

 

 

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

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

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

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

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

 

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

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

 

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

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

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

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

 

 

◆まとめ◆

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

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

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

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

The post vROps 6.7は初心者に優しい! appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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

 

トレンドマイクロ 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 の構成ベストプラクティス

 

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

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

$
0
0

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

The post vROps 6.7は初心者に優しい!#5 appeared first on Japan Cloud Infrastructure Blog.

Viewing all 972 articles
Browse latest View live


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