Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2018年5月

月別アーカイブ: 2018年5月

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

こんにちは。株式会社ネットワールドのバックアップ製品担当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/

 

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

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

 

トレンドマイクロ 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の対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

皆さん、はじめまして。株式会社ネットワールドでバックアップ製品のSEをしております臼井と申します。VMware vSANを導入するお客様の増加に伴い、多くのバックアップ製品を扱っている弊社にもvSAN環境のバックアップについて、お問い合わせいただく機会が増えてきました。そこで、VMware様のJapan Cloud Infrastructure Blogの場をお借りして、仮想環境のバックアップで多くの実績があるVeeam Backup & Replication(以下、VBR)を使用してのvSAN環境のバックアップについて掲載させていただくことになりました。
前後編の2回に分けて、vSAN環境でVBRを使うメリットや特徴をご紹介させていただきたいと思いますので、宜しくお願い致します。

Veeam(ヴィーム)って?

個人的には、Veeamという名前も仮想環境のバックアップとして日本で浸透してきたかなと勝手に思っているのですが、ご存じない方のために改めてご紹介させていただきます。
メーカーの正式名称はVeeam Softwareで、データ保護や監視ツールのソフトウェアを主に開発している会社です。本社はスイスのバールにあり、設立は2006年ですが、ここ数年で急速に顧客数や売り上げを伸ばしている注目のベンダーです。

 

 

Veeam Backup & Replicationとは?

VBRという製品を簡潔に言えば、VMware vSphere Storage APIs – Data Protection (通称、VADP)と連携して、仮想マシンを丸ごとバックアップする製品です。VMware様の製品で言うと、vSphere Data Protectionと同種の製品になります。vSphere Data ProtectionはvSphere 6.5での提供が最後になりましたので、今後のバックアップの選択肢の1つとしてVBRをご検討いただければ幸いです。

 

 

 

 

 

 

 

 

 

 

VBRの歴史は古く、2008年にVADPの前身のVMware Consolidated Backup対応のバックアップ製品としてバージョン1.0がリリースされました。その後、VADP対応や数々の機能追加や機能拡張を重ねて、現在は昨年末にリリースされたバージョン9.5 Update 3が最新バージョンとなっております。

 

 

 

他のバックアップソフトとVBRは何が違うのかというと、以下の3つの特徴が挙げられます。

 

✔アプリケーション対応

✔柔軟なリカバリ

ストレージ連携

 

それぞれの特徴を見ていきましょう。

特徴その1<アプリケーション対応>

VBRはVADPによるVMwareスナップショットと連携して仮想マシンをバックアップしますが、その際に、Active Directory, Exchange, SharePoint, MS SQL Server, Oracleについてはデータの整合性を保持してバックアップすることが可能です。

 

 

仮想マシンの静止スナップショットにより、VMware Toolsに含まれるVSS(Volume Shadow copy Service)を利用することで、ファイルシステムの整合性や一部のVSS対応アプリケーションの整合性を保持したバックアップできる製品もありますが、 VBRでは独自のVSSを提供しており、アプリケーションに合わせて、完全VSSバックアップの実施やバックアップ成功後のトランザクションログの切り捨て、カスタムスクリプトの実行などを行うことができ、より信頼性の高いバックアップを行うことが可能です。また、Oracleについては、Windowsだけでなく、Linux上のOracleにも対応しております。

特徴その2<柔軟なリカバリ>

VBRは仮想マシン単位でバックアップを行いますが、リストアは仮想マシン全体だけでなく、フォルダ・ファイル単位、仮想ディスク単位、アプリケーション単位など、シチュエーションに応じて様々なリストア方式を選択できます。

フォルダ・ファイルのリストアについては、17種類もの多数のファイルシステムに対応しております。アプリケーションについては、Active Directory のユーザーアカウントやExchangeのメールメッセージ、SharePointのドキュメントやSQL Server/Oracleはデータベースなど、粒度の細かいリストアをエージェントレスで実行することが可能です。

 


リストア操作も専用のリストアツールとして、Veeam Explorerが提供されており、直感的な操作が可能です。

 

 

特徴その3<ストレージ連携>

Veeam Softwareはアライアンスパートナーが多く、様々なベンダーのストレージと連携できることも大きな特徴です。プライマリストレージとして、Dell EMC, NetApp, HPE, IBM, Pure Storage等のハードウェアストレージのスナップショットと連携しての安定したバックアップやDell EMC Data Domain(Boost), HPE StoreOnce(Catalyst)といった重複排除ストレージと連携してバックアップすることもできます。

まず、ハードウェアストレージスナップショットとの連携ですが、仮想マシンのスナップショットのみを使用してVADPによるバックアップを行うと、スナップショット作成後の仮想マシンに対しての変更はスナップショットファイル(通称:デルタファイル)に変更ログが書き込まれ、バックアップが完了するまで保持し続けます。バックアップが長時間に及ぶケースや仮想マシンへの変更が多い環境ではスナップショットファイルの容量が肥大化し、データストアの空き容量不足やシステムのパフォーマンス低下などが起きる可能性があります。スナップショット削除時においてもスナップショットの統合処理に時間がかかるケースや仮想マシンが応答を停止する可能性があります。

 

 

 

スナップショットの仕組みや問題点については、下記のKBでも紹介されておりますので、参考にしていただければと思います。

-ESXi / ESX における仮想マシン スナップショットについて (1033239)

https://kb.vmware.com/kb/1033239

-vSphere 環境でスナップショットを使用するベスト プラクティス (1038295)

https://kb.vmware.com/kb/1038295

-仮想マシンのスナップショットを統合するのに必要な時間の推定 (2096780)

https://kb.vmware.com/kb/2096780

-スナップショットの削除で仮想マシンが長時間停止する可能性 (2079323)

https://kb.vmware.com/kb/2079323

このような問題を回避するには、ストレージスナップショットとの連携が有効です。ストレージスナップショットと連携することで、仮想マシンのスナップショット作成後にストレージスナップショットを作成し、仮想マシンスナップショットはすぐに削除されます。そのため、仮想マシンのスナップショットがある時間が最小限になり、前述の問題が起きる可能性も低くしてなります。仮想マシンスナップショットだけの場合とストレージスナップショットを組み合わせた場合をバックアップ時間の流れを比較すると下の図のようになります。

 

 

次に、重複排除ストレージとの連携です。VBR自身にも重複排除機能はありますが、重複排除ストレージと組み合わせることでバックアップデータ全体の重複排除され、より高い重複排除率を実現することが可能です。

また、vSphere Data ProtectionとData Domainを組み合わせた場合と同様、DD Boostを利用することにより、VBRサーバ上で重複排除処理を行い、Data Domain上に存在していないブロックのみを転送することでネットワークに流れるデータ量を削減でき、更に論理的な仮想合成フルバックアップ作成により、バックアップのパフォーマンスを高速化することも可能です。

vSphere Data ProtectionはData Domainのみの対応でしたが、VBRでは DD Boostと同様、Open Storage Technology (OST)を使う、HPE StoreOnceのCatalystとの連携も可能です。

 

 

ここに書き切れないほど、VBRならではの機能や特徴はまだまだ沢山ありますが、厳選してVBRの特徴を紹介させていただきました。後半は、いよいよvSAN環境でのVBRについてご紹介させていただきますので、お楽しみに。

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

執筆者:

株式会社ネットワールド

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

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

臼井 守(Usui Mamoru)

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

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

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

 

 

新卒 SE 社員が贈る NSX のキソ︕第 6 回〜 NSX Data Center が提供するファイアウォール機能とは ~

こんにちは!「新卒 SE 社員が贈る NSX のキソ!」、第 6 回を担当する、VMware 新卒第4 期生の黒沢勇です。前回は、異なるセグメント間の通信に欠かせない「NSX Data Center のルーティング機能」についてご紹介させて頂きました。第 5 回までの内容で図 1 のような VXLAN、分散論理ルータ、Edge ルータを組み合わせた柔軟なネットワークを構築することが可能となりました(図 1)。

図 1 第 5 回で完成したサンプル構成図

さて、前回まで NSX Data Center を使うと、いかにネットワークを柔軟に構築できることをお話してきました。ですがここで気になることは、「セキュリティはどうなっているの?」というところです。従来はセグメントの境界に対して物理ファイアウォールを設置し、セグメント内に対してはアクセスリストを使用したセキュリティを用いていることが一般的でした。しかし、物理機器のみで構成されたセキュリティにはいくつかの課題が出てきています。今回は、NSX Data Center がどのように仮想環境でファイアウォール機能を提供し、課題を解決するのかをお話します!まずは、NSX Data Center のファイアウォールの概要についてお話していきましょう。

 

1. NSX Data Center が提供する2種類のファイアウォールの機能
第 5 回で NSX Data Center が提供するルーティング機能は 2 種類あるというご説明をさせていただきましたが、実はファイアウォールについても NSX Data Center は2種類の機能を提供しています。

 

1.1 NSX Edge Service Gatawayのファイアウォール機能
1 つ目は、NSX Edge Service Gateway(以下 NSX Edge)が提供するネットワーク機能の 1 つである仮想ファイアウォールです(図 2)。

図 2 NSX Edge ファイアウォール

 

第 5 回で NSX Edge で North-South 方向のルーティングを行えることをご説明しましたが、NSX Edge にはルーティング以外の機能を持たせることもできます。ファイアウォール機能も NSX Edge  機能の一部であり、従来の境界ファイアウォールと同様にセグメントの境界に設置することで、トラフィックの制御を行うことができます。ファイアウォール機能を持った仮想マシンとして機能を提供するため、素早い払い出しや、物理コストをかけずにすむなど、物理ネットワーク機器にはなかったメリットを得ることができます。

 

1.2 分散ファイアウォール
2 つ目は分散ファイアウォールと呼ばれる機能です。ハイパーバイザー カーネル モジュールに組み込まれており、仮想マシン1 つ 1 つに対して個別にファイアウォールルールやアクセスコントロールなどのセキュリティポリシーを適用することができます(図 3)。さらに、分散ファイアウォールのルール情報はホスト間で共有されているので、vMotion や DRS で仮想マシンが移動しても設定が引き継がれるという特徴を持っています。

図 3 分散ファイアウォール

 

どちらのファイアウォールも、これまで物理ファイアウォールで処理していたトラフィック制御をハイパーバイザや仮想マシンへ分散することが可能となります。その結果、トラフィックを最適化したり、セキュリティをより強固にしたり、柔軟な設定を行うことができるようになります。

 

2. 従来の物理ファイアウォールの課題を NSX Data Center が解決!
さて、NSX Data Center のファイアウォールが 2 種類あることはおわかりいただけたと思いますが、この 2 つのファイアウォールがどのように従来の課題を解決するのでしょうか?3 つの課題から考えてみましょう。

 

2.1 標的型攻撃の被害が広範囲に広がる
今回は図のような、事業部ごとに Web3 層構成のシステムが存在するケースを考えてみましょう(図 4)。

図 4 サンプルシステム図

 

今回の例ではシステムがフラットな L2 セグメントを持っており、社外との通信に対して境界ファイアウォールで制御を行っています。しかし、内部通信を行うときにはファイアウォールを通過しないため、社内のセキュリティレベルが同じ状態になっています。でも、よく考えてみると同じ L2 セグメントにあるからといってセキュリティレベルが一緒とは限りませんよね?財務部のサーバと、個人情報が詰まっている人事部のサーバは明らかにセキュリティレベルが異なります。
ここで、財務部のサーバがもしインターネット上からウィルスやマルウェアなどの標的型攻撃を仕掛けられてしまった場合を考えてみましょう。(図 5)

図 5 財務部のサーバが感染

 

標的型攻撃は感染をすると同じセグメントのマシンへ被害を広げようとします。そのため、感染したサーバが他のサーバへと通信できる状態だと、サーバ 1 つが感染しただけで、被害は同じセグメント全体に及んでしまいます(図 6)。

図 6 同じセグメントに感染が拡大

 

さらに、同じセグメントからの通信はファイアウォールを通らないため、アラートすら上がらないことも多いです。気づかない内に攻撃されて、気づいた時には機密情報や個人情報が盗まれていた…なんてことも起こり得ます(図 7)。

図 7感染したサーバから情報が漏えい

 

では、どのように NSX Data Center のファイアウォールがこの課題を解決するのかをお話させていただきます。実は、L2 セグメントが同じシステムであったとしても、通信が必要ないという場合は多々あります。しかし、従来の境界ファイアウォールはセグメント内の通信には手が出せないため、通信を許す状態になっていました。
ここに分散ファイアウォールを設定することにより、L2 セグメント内の通信を厳しく制限をかけることができます。このファイアウォール設定により、感染したサーバは他のマシンと通信が行えないので感染を広げることができなくなります(図 8)。

図 8 分散ファイアウォールで標的型攻撃の感染を抑制

 

境界型ファイアウォールを設置するだけではセグメント内の通信ができる状態なので被害が拡大してしまいますが、分散ファイアウォールを使えば他のマシンとの通信を遮断することができるので、感染が拡大しなくて済むのです!
ご存知とは思いますが、境界型のファイアウォールは突破される可能性が 0 ではありません。分散ファイアウォールを設定することによって被害を最小限にとどめられるのは、とても安心ですよね。

 

2.2 ヘアピン通信を分散ファイアウォールで解決
セキュリティレベルを高めるために、常にファイアウォールを通過する形で、通信を行うようにしているお客様もいらっしゃると思います。この場合、ネットワークのトラフィックパターンが複雑になり、余計な経路を通るヘアピン通信が発生してしまいます。1 回 1 回物理ファイアウォールを通ると、物理機器に負担がかかるうえに、遅延も大きくなってしまいます。
ここに分散ファイアウォールを導入するとどうなるのか考えてみましょう。ハイパーバイザー内部にファイアウォール機能を持っているので、いちいち物理ファイアウォールを通過する必要がなくなります。これで、仮想マシン間のヘアピン通信が発生しなくなるので、物理機器への負担を小さくすることができます。そのためシンプルなトラフィックパターンとなるので、物理機器のダウンサイジングや運用コストの低下も期待できます(図 9)。

図 9 ヘアピン通信と分散ファイアウォール

 

2.3 どっちを取る!? vMotion の自由度とセキュリティ
これまでのネットワーク環境はセキュリティ機能が物理機器頼りになっているため、vMotion の自由度と、セキュリティのどちらかを犠牲にしているような形が多々見られます。ご存知と思いますが、仮想マシンを vMotion で移動する際には移動先と移動元が同じセグメントでないと、移動先で正常に通信ができなくなってしまいます。つまり、仮想マシンの移動先を多くするためには広い L2  ネットワークが必要になります(図 10)。

図 10 フラットな L2 ネットワークを使った従来管理

 

従来の管理方法で L2 ネットワークを広く取ってしまうと、多くの仮想マシンを同じセキュリティポリシーで管理することになってしまいます。本来は別々のセキュリティポリシーを適用すべきですが、仮想マシンが移動できる代わりにセキュリティを犠牲にしていることになります。
一方、セグメントを細かく切り、仮想マシンのセキュリティポリシーを厳しく適用する運用方針もあります。しかし、セグメントを細かくすると今度は仮想マシンの vMotion 先が少なくなってしまいます。また、このように自由度の低い構成は集約率の低下を招いてしまうことも多々あります。せっかく仮想マシンを使っているのに vMotion ができない…なんていうのはもったいないですよね(図 11)。

図 11 細かくセグメントを分けた従来管理

 

では、NSX Data Center を導入するとどうなるのかを見てみましょう。分散ファイアウォールを導入すれば仮想マシン毎にセキュリティポリシーを適用できるようになるので、フラットな L2 ネットワークを作りつつ、セキュリティレベルを維持することができます。加えて、ホスト間で分散ファイアウォールの情報を共有しているため、仮想マシンが移動できるようにしても、移動先でセキュリティレベルを維持することができます。

図 12 分散ファイアウォールの活用で自由度とセキュリティポリシーを両立

 

NSX Data Center を使えばセキュアな環境も維持しつつ、仮想マシンのメリットも最大限に引き出すことが可能となるんですね。

これまでは NSX Data Center のファイアウォール機能について、どのようなメリットが出るのかについてご説明させて頂きました。ところでみなさんはファイアウォールの設定というと、IP アドレスや MAC アドレスをコマンドで入力しながら 1 つ 1 つ設定を行っていくイメージがあると思います。今まで当たり前のことでしたが、もっとわかりやすく設定が行えたらいいな…と思ったことはありませんか?

実は NSX Data Center のファイアウォールは設定も従来のファイアウォールよりも柔軟に行えるんです。

3. 機能だけじゃない!簡単で柔軟な NSX Data Center のファイアウォール設定
では、実際に NSX Data Center のファイアウォールを設定する画面を見てみましょう(図 13)

図 13 NSX Data Center のファイアウォール設定画面

 

設定項目は以下の 5 項目となります。全て GUI 上から設定を行えるため、従来の IP、MAC アドレスを対象とした従来の CUI で行う設定よりも可視性に優れており、簡単にセキュリティポリシーを適用できるようになります。

・ソース
サービスの送信元を IP、MAC アドレスに加え vCenter オブジェクトから設定可能
・ターゲット
サービスの送信元を IP、MACアドレスに加え vCenter オブジェクトから設定可能
・サービス
物理ファイアウォールでセッティングできるサービスの大半を選択可能
・操作
サービスを許可/ブロック/却下するかを選択可能
・適用先
ルールの適用先を分散 FW もしくは Edge FW から選択可能

ここで注目していただきたいのは、ソースとターゲットを IP アドレスや MAC アドレスだけでなく、仮想マシンやポートグループ、クラスタ、ホスト、データセンタ、論理スイッチ、vApp、vNIC といった vCenter オブジェクトでも設定可能な点です。
従来のファイアウォールは文字が羅列されているだけので見にくいだけでなく、セキュリティポリシーの適用先が IP、MAC アドレスのみに縛られていました。vCenter オブジェクトで設定を行えるようになると、ソースとターゲット設定を直感的にできるため、従来のファイアウォールと柔軟に設定が可能となります。
ここで、さらに NSX Data Center のファイアウォールの柔軟性に足を踏み入れてみましょう。その秘密はセキュリティグループという概念にあります。

 

4. セキュリティグループで俊敏性を向上!!
先の節で仮想マシンや、ホストごと、ポートごとにセキュリティポリシーを設定できることをお話しました。しかし、仮想マシンは何度も作成されます。GUI になったとはいえ、仮想マシンを作成するたびに、ファイアウォールのルールを変更するのは少々手間です。できることであれば、もう少しグルーピングをし、なおかつ追加、削除される仮想マシンに対して動的にセキュリティポリシーを適用していきたいものです。
NSX Data Center では動的にグループメンバーを追加、削除してくれるセキュリティグループというオブジェクトをてソース・ターゲットとして選択できます。
セキュリティグループは、”仮想マシンに Tech の名前を含むもの”といった形でグルーピングをすることができ、あとから仮想マシンを追加しても動的にグループへ対象の仮想マシンを追加してくれます。

図 14 セキュリティグループを使えば後からポリシーを適用可能

 

例えば、技術部の Web サーバを追加する例を考えてみましょう。仮想マシン名に“Tech という文字が含まれば、技術グループ”、“Web という文字が含まれれば Web サーバグループ”というように事前にセキュリティグループを定義しておきます。すると、追加した Tech-Web という仮想マシンの分散ファイアウォールには、技術グループと Web サーバグループの 2 つのセキュリティグループのルールが適用されます。
これで、仮想環境に新しく仮想マシンを追加したときに、毎回毎回煩わしいファイアウォールの設定を追加していく必要もなくなります。セキュリティグループを活用すれば柔軟かつ俊敏に設定を適用できるようになります。NSX Data Center でネットワークを仮想化することで、ネットワークを最適化するだけでなく、ファイアウォール機能を強化したり、柔軟に設定できるようになるメリットも得られることができることがお分かりいただけたでしょうか?

 

5. まとめ
最後に改めて、NSX Data Center の持つファイアウォール機能の特徴とメリットをそれぞれ整理しておきましょう。
NSX Data Center のファイアウォールで従来の物理ファイアウォールの課題を解決!
・標的型攻撃に対しては分散ファイアウォールで感染拡大を抑制
・仮想マシンの可搬性を最大限にして運用
・ヘアピン通信を抑制して物理機器をダウンサイジング
設定は GUI 上で簡単に行える上、設定項目が豊富!
・物理ファイアウォールと違い、GUI 上で簡単に設定
・ターゲットとソースを vCenter オブジェクトを使って柔軟に設定可能
・セキュリティグループを使えば動的にセキュリティポリシーを適用可能

 

6. おわりに
今回は NSX Data Center のファイアウォールについてお話させて頂きました。次回は NSX Edge について詳しく触れます!実は NSX Edge にはルーティング機能や、今回お話したファイアウォール機能以外にも様々な機能があるんです!!
次回、さらなる NSX Data Center の魅力に触れていきましょう!お楽しみに!

 

コラム ~ 3rd party連携について ~
NSX Data Center は 3rd party 製品との連携も可能となっております。Symantiecs 社、Palo Alto Network 社、Fortinet 社、Juniper 社製品など様々なベンダー製品との連携が可能ですが、今回はトレンドマイクロ社の Deep Security との連携がどのように行われるのか、見てみましょう。昨今流行している標的型攻撃に対して、Deep Security と連携することによって、標的型攻撃の被害にあった被害にあった仮想マシンを物理的に隔離することが可能となります。さらに、Deep Security を活用することで仮想マシンの浄化まで行うことができる上に、仮想マシンの再接続を行うことも可能です。
これにより、NSX Data Center 単体での運用以上に安全な仮想環境を運用することが可能となります。
トレンドマイクロ社との連携についてはこちらの記事をご参照下さい。
VMware NSX と Trend Micro Deep Security で実現する仮想化セキュリティの最適化

新卒 SE 社員が贈る NSX のキソ!第 5 回~仮想化されたネットワークのルーティング~

こんにちは!「新卒 SE 社員が贈る NSX のキソ!」第 5 回を担当する VMware 新卒第 4 期生の笠井伶花と申します。
前回の第 4 回では、論理スイッチをテーマに仮想環境のネットワークを VXLAN で払い出すことで物理環境に手を加えず、サーバ側で自由に仮想ネットワークを払い出すことができるというお話をしてきました。
構成図で見ると、図 1 のところまで完成している状態ですね。

 

図 1 第 4 回で完成した構成図

しかし、ここまでのお話で VXLAN によるセグメントをまたいだ通信はどうするんだろう?という疑問を持ったかたもいらっしゃるのではないでしょうか。そこで、第 5 回では、異なるセグメントネットワーク間の通信に欠かせない「NSX Data Center のルーティング機能」についてご紹介いたします。

VXLAN によるセグメントをまたいだ通信をする場合、もちろんルーティングが必要になります。しかし、VXLAN で払い出した仮想ネットワークのセグメント間のルーティングを従来通り物理のルータで行うとしたらどうなるでしょうか? 第 4 回でもお話がありましたが、結局はトラフィックが 1 度仮想化されたネットワークの外に出てしまいます。また物理ルータへの設定が都度必要になってしまうのです。折角サーバ側で自由にネットワークを払い出すことが出来るようになったのに、ルーティングで結局物理ネットワーク側での設定変更が必要になっては意味がありません。
しかし、NSX Data Center ではルーティング機能に関しても仮想の世界の中だけで行う機能を備えているんです!

 

1. NSX Data Center のルーティング機能

NSX Data Center には実は 2 種類のルーティング機能があります。1 つは NSX Edge の機能の 1 つである仮想ルータによるルーティング、もう 1 つは、ハイパーバイザのカーネルに組み込まれた分散論理ルータによるルーティングです。
しかしこの 2 種類のルーティングは一体何が違っているのか、ややこしいですよね。そこで、ここからは NSX Edge のルータ、分散論理ルータについてそれぞれ特徴を見ながら、2 つのルータの違いとメリットについて理解していきましょう。

 

2. NSX Edge Service Gateway とは ~NSX Edge を使うメリット~

第 2 回の主要コンポーネントの紹介の部分で簡単に説明しましたが、NSX Edge はネットワーク機能を提供する仮想アプライアンスです(図 2)。従来、物理ネットワーク機器で提供されていた各種ネットワーク機能を仮想マシンで提供しているというと分かりやすいかもしれません。NSX Edge はルータ、NAT、ファイアウォール、ロードバランサー、VPN、DHCP といった機能を提供することができます。

仮想アプライアンスの NSX Edge を使うと、例えば、従来では物理ネットワーク機器での運用が必要だったネットワーク機能と比較して、「仮想マシンだからこそ」の簡単かつ素早いネットワーク機能の展開、展開が簡単だからこその短期間でのスケールアウトの実現、そして、物理ネットワーク機器のダウンサイジングによるコスト縮小、といったメリットが得られます。また、NSX Edge の管理・運用についてもバラバラの管理コンソールではなく、vSphere Web Client で一元的に管理可能なことも管理者側から見て魅力的な部分です。

 

図 2 NSX Edge によるルータを含む構成図

 

2.1 NSX Edge Service Gateway のルータ ~North-South 方向のルーティング~

NSX Edge は物理ネットワーク機器が仮想アプライアンスになったイメージと言いましたが、物理ネットワーク機器のルータを使った場合と NSX Edge のルータを使った場合のトラフィックの流れと比べると図 3 のようになります。物理ネットワーク機器の代わりに NSX Edge のルータがルーティング処理していますね。また、ネットワーク仮想化環境で通信が完結する場合は、L3 スイッチまでトラフィックがあがらずに Edge で処理することができます。
このように NSX Edge ルータは、特に仮想ネットワークと外部ネットワーク間の通信、すなわち North-South 方向の通信のルーティングを処理するときに適しています。

 

図 3 物理ルータと NSX Edge ルータのルーティング経路の比較

 

では、データセンター内の通信、いわゆる East-West 方向のルーティングでは NSX Edgeルータを使わないのでしょうか?実は East-West 方向のルーティングに関しては、もっとトラフィックを減らせる最適な方法を NSX Data Center は持っているんです。

それが次に説明する「分散論理ルータ」です。

 

3. 分散論理ルータ(Distributed Logical Router/DLR)

さて、NSX Data Center が持つもう 1 つのルーティング機能、「分散論理ルータ」。この機能は NSX Data Center だからこそ、という特徴を持っています。この回の最初にお話した通り、従来の物理ルータによるルーティングは、同じホスト上にあるセグメントが異なる仮想マシン同士が通信しようとすると、1 度必ずホストからパケットが出て物理ルータで処理されてから、再度同じホスト上にある送信先仮想マシンにパケットが届きます。

なんだか遠回りしていると思いませんか?

このルーティングでは、同じホスト上に仮想マシンがあるにも関わらず 1 度通信がホストからネットワークに出てしまうため、その分ヘアピン通信(同じホスト上にある仮想マシン間の通信がホストから 1 度出て、また元のホストに戻るような通信)が発生してしまいネットワーク機器が処理するパケットの量が増大してしまいます。また、仮想ネットワークの追加・変更時には、物理ネットワーク機器への設定変更が必要になってしまいます。

実はこれらの問題を「分散論理ルータ」で一気に解決できてしまうんです!

 

3.1 分散論理ルータによるメリット ~East-West 方向トラフィックの最適化~

まず、ヘアピン通信の問題から見ていきましょう。
実はデータセンター内における通信のうち約 7 割はマシン-マシン間での通信であるとも言われています。つまり、仮想サーバで構成されたデータセンターでは、仮想マシン同士の通信によるトラフィックの量が大きいのです。この East-West 方向のトラフィックの最適化を分散論理ルータはどう実現しているのでしょうか?

実は分散論理ルータの正体はハイパーバイザー カーネル モジュールに組み込まれたルーティング機能です。もう少し噛み砕いて言うと、同じ設定のルーティングテーブルを持ったルータが複数の ESXi ホストのカーネル モジュールに実装されるイメージです。分散論理ルータでは、送信元の仮想マシンからパケットが投げられると、そのホスト内の分散論理ルータでルーティング処理され、そのまま送信先の仮想マシンにパケットが届けられます。

分散論理ルータでは、ダイナミックルーティングで構成する場合、ルーティング情報を集中して制御している「分散論理ルータコントロール仮想マシン」がルーティング情報を NSX Controller クラスタに集約し、NSX Controller から各ホストに情報をプッシュすることでルーティングの構成が各分散論理ルータに共有されます(図 4)。

 

図 4 分散論理ルータのルーティング情報の共有の仕方

 

ちなみに、スタティックルートで構成する場合は、新たにルートを学習することはないため、分散論理ルータコントロール仮想マシンは必要なく、静的に設定された分散論理ルータの構成が Controller クラスタから各 ESXi ホストにプッシュされます。

このように、各ホストのカーネル モジュールに構成された分散論理ルータがルーティングの情報を持っているため、ホスト内の分散論理ルータでルーティング処理ができるのです!

分散論理ルータを使った場合のトラフィックの流れは、図 5 のようになっています。まず、ルーティング処理は送信元の仮想マシンがのっているホスト内の分散論理ルータで処理されるため、1 度、物理ルータ、もしくは Edge を使用している場合は Edge に行く必要がなくなります。

もう少し詳しく説明しますと、図 5 の赤い線が示すように、送信先の仮想マシンがローカルのホスト上に存在する場合、ネットワーク側にパケットが転送されることなく、ローカルのホスト内でルーティングが完結するんです!
また、図 5 の橙色の線を見てもらうと分かるように、送信先の仮想マシンが別のホストに存在する場合は、分散論理ルータでルーティング処理が行われた後に VXLAN で該当の仮想マシンが起動しているホストまでパケットが転送されます。どちらの場合も仮想マシン間でルーティングを行うにあたり、物理ルータや Edge にパケットを転送する必要がありません!
このようにして East-West 方向におけるルーティングのトラフィックの最適化を可能にしているのです。

 

図 5 分散論理ルータによるルーティングの経路

 

そして皆様、本ブログ第 4 回の VXLAN の話を思い出してください!
VXLAN を使えば、物理ネットワーク機器への VLAN 設定変更は必要ない、というお話がありましたね。つまり分散論理ルータでルーティング処理された後は VXLAN による通信で転送される、すなわち L2 の通信ということですから、このときの物理ネットワークはただのパケットの通り道になっているんです。

ここまでくるとお気づきでしょう。
分散論理ルータを使うと、仮想マシン間のルーティングを行うための物理ルータは必要ありません!そして、ルーティング処理の追加・変更時においても物理ネットワーク機器への設定変更も必要ありません!
従来の物理ルータによるルーティングの問題が仮想ネットワークのルータにより解決されたのがお分かり頂けたでしょうか?

 

4. まとめ

最後に改めて NSX Data Center の持つ 2 種類のルーティング機能の特徴とメリットをそれぞれ整理しましょう。

NSX Edge のルータと分散論理ルータは適しているトラフィックの方向が違います!
分散論理ルータは East-West 方向のルーティングのトラフィックを最適化します。NSX Edge のルータの使いどころは、外部(物理)ネットワーク-仮想ネットワーク間の通信をルーティングすること、すなわち North-South 方向の通信のルーティングです。

 

図 6 論理図で見る NSX Data Center の 2 種類のルーティング

 

② VXLAN による L2 通信と同様、仮想ネットワーク内におけるルーティングまわりの設定追加・変更を物理ネットワークから切り離して実施できるため、ネットワーク運用の工程削減の実現が可能になります!

③ 2 種類のルーティングのデザインを活用し、ネットワーク処理の最適化を行うことで、物理ネットワーク機器のダウンサイジングが可能になります!

 

5. おわりに

ここまででスイッチ、ルータといったネットワークの基本が NSX Data Center の機能で仮想化の世界で閉じて実現しましたね(図 7)。

図 7 NSX Data Center のルーティング機能を実装した構成図

 

でもこれではまだセキュアなネットワーク環境にはなっていません。VXLAN で払い出した仮想ネットワークのセグメント間でも通信をさせたくない・・そんな状況ももちろん出てきますよね。

そこで次回の「新卒社員が贈る NSX のキソ!」では、セキュアなネットワークを実現する NSX Data Center のファイアウォール機能についてご紹介します!お楽しみに!

- VMware SE 笠井伶花

新卒 SE 社員が贈る NSX のキソ︕第 4 回〜論理スイッチがもたらす NSX Data Center の オーバーレイネットワーク〜

読者の皆様こんにちは!2017 年 4 月に VMware に入社しました、新卒第 4 期生の馬場浩太と申します。
「新卒社員が贈る NSX のキソ!」も第 4 回となりました。ブログの第 1 回では、ネットワークを仮想化することで、ネットワーク機能を様々な物理環境の制約から解放し、運用負荷を軽減する、と説明しました。第 4 回は、 NSX Data Center の「ネットワークの仮想化」の本質である、論理スイッチをテーマに(図 1)、この仕組みを技術的に理解し、NSX スゴイ!使ってみたい!提案したい!と感じていただくことを目的としています。

図 1 論理スイッチ作成前のネットワーク図(仮想マシン同士は通信できていない)

さて、ネットワーク仮想化をすることで、その運用負荷が大幅に削減される?本当でしょうか?外資ベンダーはいつも都合のいいことばかり言いますので、疑ってかかることは重要です。ネットワークを仮想化する前の、仮想マシンを新規ネットワーク上に構築するオペレーションについて具体的に確認してみましょう。

【サーバ側】
・標準仮想スイッチ (vSS:vSphere Standard Switch)の場合、通信に関連するすべての ESXi ホストに対して、追加する VLAN のポートグループを作成し、仮想マシンを追加したポートグループに所属させる
・分散仮想スイッチ(vDS:vSphere Distributed Switch)の場合、追加する VLAN のポートグループを 1 つだけ作成し、仮想マシンを追加したポートグループに所属させる

【物理ネットワーク側】
・通信に関連するすべての物理スイッチに対して、VLAN を作成する
・通信に関連するすべてのトランクポートに対して、Allowed VLAN を設定する
・PVST+ など、VLAN 単位でスパニングツリーを構成している場合、追加する VLAN に応じてスパニングツリーの設定をする

【その他】
・ネットワーク担当者に連絡して動いてもらう

図 2 ネットワーク仮想化前に新規ネットワークを追加する場合のオペレーションの一例

なぜこのようなオペレーションが必要なのでしょうか?それは、物理ネットワーク機器が仮想マシンを認識しているからです。
「新卒 SE 社員が贈る vSphere のキソ!」第 2 回では、「仮想マシンに入っている OSはあたかも物理サーバ上で動作していると思い込んでいる」と紹介しました。当然、物理ネットワーク機器も、仮想マシンを 1 つの物理サーバ/物理マシンと思い込んでいます。彼らにとって、物理か仮想かは関係がないのです(図 3)。

図 3 物理ネットワーク機器の認識する通信は物理サーバではなく仮想マシン

具体的には、異なる ESXi ホスト上の仮想マシン同士が通信をする時、物理ネットワーク機器を通るパケットは、仮想マシンの MAC アドレス/IP アドレスを送信元/送信先とします(ESXi ホストを送信元/送信先とはしません!)。つまり、仮想の世界の通信にも関わらず、物理の世界にも影響を及ぼしているのです。
仮想マシンが増えれば増えるほど、物理ネットワーク機器が認識する仮想マシンの数も増えてしまいます。そして、それらが接続されるネットワークの数が増えれば増えるほど、物理ネットワーク機器へのオペレーションはますます複雑になり、新規ネットワークを追加するときにでさえ、物理機器への面倒な作業が不可欠となり、ネットワーク担当者に動いてもらう必要があるのです。

 

仮想の世界の通信は、仮想の世界で完結してしまいませんか?

 

このような、NSX Data Center のネットワークの仮想化を実現するのが論理スイッチです。VXLAN という技術を使うことで、vDS 上にある仮想マシンを、論理スイッチという仮想ネットワーク上に接続させることができます。NSX Data Center では、クラスタの集合であるトランスポートゾーンと呼ばれる単位で、論理スイッチを有効化します。
先ほど、どの仮想マシンがどの仮想マシンに通信したかを、物理ネットワーク機器が認識してしまう、と説明しました。すなわち、MAC アドレステーブルなどの各種テーブルや ACL(アクセスコントロールリスト)などの情報は、通常は仮想マシンの MAC アドレス/IP アドレスで照合されるというわけです。
NSX Data Center を導入した場合、仮想マシン間の通信は各 ESXi ホストが持つ VTEP と呼ばれるインターフェース間の通信への置き換えられ、物理ネットワーク機器が認識する通信は、仮想マシンではなく VTEP となります。したがって、物理ネットワーク機器の持つ各種テーブルや ACL などの情報は、VTEP の MAC アドレス/IP アドレスで照合されるようになります(図 4)。

図 4 物理ネットワーク機器の認識する通信は論理スイッチによりVTEP に

これによって何が変わるでしょうか?再び、仮想マシンを新規ネットワーク上に構築する場合を考えてみましょう。vSS や vDS の場合に必要なオペレーションが、論理スイッチの場合はどうなるでしょうか?

【サーバ側】
・vSS の場合、通信に関連するすべての ESXi ホストに対して、追加する VLAN のポートグループを作成し、仮想マシンを追加したポートグループに所属させる
・vDS の場合、追加する VLAN のポートグループを 1 つだけ作成し、仮想マシンを追加したポートグループに所属させる
→ ポートグループはもはや意識する必要がありません。作成した論理スイッチに、仮想マシンを接続するだけです。

【物理ネットワーク側】
・通信に関連するすべての物理スイッチに対して、VLAN を作成する
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。
・通信に関連するすべてのトランクポートに対して、Allowed VLAN を設定する
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。
・PVST+ など、VLAN 単位でスパニングツーを構成している場合、追加する VLAN に応じてスパニングツリーの設定をする
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。

【その他】
・ネットワーク担当者に連絡して動いてもらう
→ 必要ありません。vCenter Server から新規ネットワークを作成できるためです。VTEP には影響がありませんので、物理ネットワーク機器にも影響はありません。

図 5 ネットワーク仮想化で新規ネットワーク作成の手間は大幅に削減

どうでしょう?あれだけ手間がかかっていた新規ネットワーク構築作業が、物理スイッチへのログインを一切することなく、vSphere Web Client 内だけで完結しました。不思議ですよね?これが NSX Data Center によるネットワーク仮想化のスゴさです。NSX Data Center の論理スイッチの本質は、このような仮想マシン間の通信を隠蔽する、というところにあります。これにより、仮想の世界でいくら新しいネットワークを作成しても、物理ネットワーク機器側からは VTEP 間の通信と認識され、その判断ができません。したがって、物理ネットワーク機器に手を加えず、サーバ側で自由にネットワークを払い出すことができるようになり、ネットワークの運用負荷が大幅に削減されるのです。NSX Data Center が構築する仮想ネットワーク、すなわちオーバーレイの世界にとって、VTEP 間の通信、すなわち仮想ネットワークを支えるアンダーレイの世界はどうだっていいのです。
最後にまとめとして、もう一度、皆様にこの言葉を捧げたいと思います。

 

仮想の世界の通信は、仮想の世界で完結してしまいませんか?

 

おわりに
いかがだったでしょうか?今回は論理スイッチについて説明いたしました。論理スイッチを作成することで、仮想マシン間は物理ネットワークの制約を受けず、自由に仮想ネットワーク上で L2 接続ができるようになります(図 6)。

図 6 論理スイッチ作成後のネットワーク図(仮想マシン同士は L2 で接続)

しかしながら、これは NSX Data Center の魅力のほんの一部でございます。NSX Data Center にはまだまだ紹介していない機能、それによってもたらされる価値がたくさんございます。例えば、今回はNSX Data Centerの論理スイッチという L2 の部分だけをお話しましたが、次回はこの論理スイッチ間の「ルーティング機能」を提供する分散論理ルータ、Edge ルータをご紹介します。


コラム ~VXLANについて~

お気づきになられた読者も多いかとは思いますが、NSX Data Center の論理スイッチでは、ESXi ホスト単位でトンネリングを行っています。これについて補足します。
スイッチは L2 レベル、すなわち MAC アドレスを見てパケットを判断し、適切なポートから他の機器へパケットを伝達します。ルータは L3 レベル、すなわち IP アドレスを見て、パケットを判断し、適切なポートから他の機器へパケットを伝達します。
この時、スイッチやルータは、図 7 のように、パケットの先頭にある情報しか見ません。つまり、もし図 7 のようにパケットの先頭に本来のものとは異なる MAC アドレス/IP アドレスが付与された場合、スイッチやルータは一番先頭にある MAC アドレス/IP アドレスしか見ませんので、本来のパケットの送信元/送信先を捻じ曲げることができます。これがカプセル化です。
NSX Data Center では、VTEP の MAC アドレス/IP アドレスで、本来のパケットをカプセル化します。パケットがカプセル化されたことを物理ネットワーク機器は判断できず、VTEP の MAC アドレス/IP アドレスを見て、送信先仮想マシンが存在するサーバの VTEP にそのままフォワーディング/ルーティングしますが、パケットを受け取った VTEP はカプセル化されたことを判断できます。すなわち L3 以上の VXLAN ヘッダを見ますので、そこでカプセルが外され、送信先仮想マシンが存在する ESXi カーネル上で本来のパケットを処理するわけです。実は、VTEP はトンネルの入り口や出口なのです。

図 7 物理ネットワーク機器が認識するパケットのヘッダの違い

さて、もう少し論理スイッチと VXLAN を深堀りしてみましょう。トンネリングをすることで、サーバ間のネットワークが何であれ、 1 本の仮想の専用線、L2 ネットワークで接続することができます。まさに、サーバ間の複雑なネットワークを、トンネルで束ねて隠してているイメージですね。この、複雑なネットワークをトンネルで束ねて隠し、同じ L2 ネットワークでつなぐことを「L2 延伸」と呼びます。L2 延伸をすることで、vMotion が必要とする L2 サービスを、安定的な標準化技術である L3 ネットワーク上で構成することが可能となります。そしてこれは、本ブログの最終回でお話しするような、複数のデータセンター間の仮想ネットワーク環境の構築や、VMware のビジョンでもあるクロスクラウドを実現するために必要な技術です。
L2 ネットワークを単に広げるのは簡単です。しかしながら、ある程度の規模の L2 ネットワークを、どのように安定的に構成・管理するかはネットワークエンジニアの長年の課題でした。ブロードキャスト範囲の増加、それによる帯域圧迫、ループを防ぐための STP、新たなソリューションが出たとしてもベンダー独自技術の習熟コストがかかってしまうなど、L2 ネットワークを「安定的に」広げるのは、案外難しいのです。
論理スイッチは、これらの課題に対する 1 つの答えと言えます。NSX Controller がVTEP とそれに紐づく仮想マシンのテーブルを持っているため、必要のない ESXi ホストにはブロードキャストは届きません。論理スイッチ上ではループは生じませんし、VXLAN は VMware 独自の技術でもありません。VMware の NSX Data Center は、ハイパーバイザーである ESXi と VXLAN を効果的に組み合わせることで、ネットワーク運用負荷の削減と、L2 延伸によるネットワークインフラの抽象化を実現するのです。

-VMware SE 馬場浩太

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

エージェントレス型による侵入防御/Webレピュテーションの実装

 

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

前回はエージェントレス型ウイルス対策を実現するために必要となるVMware NSXのサービス設定とDeep Securityとの連携について解説を行いました。
この連携を行うことで、ウイルス対策以外にも侵入防御(IDS/IPS)、Webレピュテーションなどの機能をエージェントレスで提供することも可能となります。
ウイルス対策は仮想マシン上でアクセス(読み取り/書き込み/コピーなど)をした「ファイル」に対して処理を行っています。一方、Deep Securityにおける侵入防御、Webレピュテーションは仮想マシンが送受信する「パケット」に含まれる情報に対して処理を行っており、ウイルス対策などの「ファイル」に対する処理とは異なる仕組みによってセキュリティ機能を提供しています。今回はそのアーキテクチャについて解説していきます。

 

NSX ManagerとGuest Introspectionの役割は変わらない

ウイルス対策に限らず、Deep Security Virtual Appliance(DSVA)を利用する場合には、NSXサービスが必要となりますので管理プレーンとしてのNSX Manager、制御プレーンとしてのGuest Introspectionが必要となります。(前回も記述)

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

 

ネットワークイントロスペクションサービス

実際に仮想マシンが送受信する通信を検査するためには、ハイパーバイザーからDSVAに対してパケットを転送(リダイレクト)をさせるが必要があります。そのためにはNSXセキュリティポリシーで必要なルールを設定する必要があります。パケットのリダイレクトにはネットワークイントロスペクションサービスを設定します。

ネットワークイントロスペクションサービスで「サービスのリダイレクト」を指定して、サービス名から「Trend Micro Deep Security」を選択することにより、NSXセキュリティポリシーが適用された仮想マシンに対する通信をDSVAに対して転送(リダイレクト)されるようになります。リダイレクトさせる通信は送信元・送信先・サービスで制限すること可能となるため、仮想マシンの送信方向、受信方向それぞれにネットワークイントロスペクションサービスのルールを設定することが必要です。

 

パケット処理の流れとDeep Securityでの処理

仮想マシンのVNICからのパケットはハイパーバイザー上の仮想スイッチ上のdvFilterによって、NSXセキュリティポリシーに設定したネットワークイントロスペクションのルールに則ってリダイレクトされます。
ネットワークイントロスペクションを理解する上で重要なコンポーネントがdvFilterです。

  • dvFilterはネットワークイントロスペクションが有効化されると機能します。
  • dvFilterにはスロット(Slot)が複数用意されており、リダイレクトするサービス毎にSlotが割り当てられます。Slotには入力パスと出力パスが設定されています。
  • Slot 0-3はVMware用に予約されており、分散ファイアウォールを有効にした場合にはSlot 2が割り当てられます。
    DSVAをはじめとする3rd Party製品はSlot 4-11までに割り当てられます。
  • 通信はSlot 0から若い番号から順次有効なSlotにリダイレクトされます。Slotに割り当てられたサービスを入れ替えることで適用されるサービスの順番を入れ変えることも可能です。

実際にどのようにパケットが処理されているのか、上の図を例に見ていきましょう。

  1. 仮想マシンからの通信をパケットはdvFilterが分散ファイアウォールへのSlot の入力パス経由でリダイレクトされます。
  2. 分散ファイアウォールは設定されたファイアウォールポリシーに従ってパケットの制御を行います。
  3. 分散ファイアウォールを通過したパケットは、Slotの出力パス経由でdvFilterに戻され、ネットワークイントロスペクションサービスの設定に基づき、次に割り当てられているDeep SecurityのSlotにリダイレクトされます。
  4. リダイレクト先となるDSVAはDeep Securityセキュリティポリシーに従って、ファイアウォール、侵入防御、Webレピュテーションなどの機能によりパケットを検査し、必要な処理を行います。
  5. DSVAでの検索も通過したパケットはSlotの出力パス経由で再びdvFilterに戻され、仮想スイッチから外部のネットワークへ送信されます。

上記では仮想マシンからの送信トラフィックを例に記載をしましたが、仮想マシンへの受信トラフィックも同様にSlotの若い番号のサービスから順次パケットはリダイレクトされていきます。

 

まとめ

VMware NSXのパケット処理の仕組みをセキュリティ機能の観点から解説をしました。
DSVAはネットワークイントロスペクションサービスがリダイレクトするパケットに対してDeep Securityの機能を提供するように設計されていることがご理解いただけたのではないでしょうか。
VMware NSX環境でDSVAを利用する場合には、ファイアウォール機能はNSX分散ファイアウォールで実装して、Deep Securityのファイアウォール機能はOFFにしておくことを推奨しております。ファイアウォールのようなパケットヘッダーの処理を高速に行う処理は、仮想アプライアンスとして提供されるDSVAでソフトウェア処理するよりも、ハイパーバイザーで処理される分散ファイアウォールのほうが高速に処理することを期待できます。
シンプルなアクセス制御は分散型で高速に処理できるNSXで行い、パケットの内部を検査するような侵入防御やWebレピュテーションを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)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェント型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

こんにちは! 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 甫木 佑美佳

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

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

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

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

念のため簡単に説明すると、 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 Data Center のプレーンについて
NSX Data Center では、各コンポーネントがプレーンごとにぞれぞれ独立して動作しているので、もし制御プレーンに障害が発生しアクセスができない状態になったとしても、データプレーンが動作していれば通信を継続的に正常に処理することができる、などのメリットがあります。

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

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

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

図 3 NSX のプレーン

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

 

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

 

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

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

 

 

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

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

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

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

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

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

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

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

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

 

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

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

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

コラム ~ 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)をご覧ください。