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

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

-VMware SE 大田愛里香

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

エージェントレス型ウイルス対策のアーキテクチャ(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)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェント型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

エージェントレス型ウイルス対策のアーキテクチャ(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)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェント型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

3回目:仮想スイッチのお作法#3 (vSphere 6. 5の分散スイッチの機能とアーキテクチャ)

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

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

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

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

マーケット的には、「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への興味を高めていただけたら嬉しく思います。