2016年2月21日日曜日

Embedded Host Client 5.0登場! ついに日本語対応も!

以前より紹介をしておりました、ESXiをWebで管理する「Embedded Host Client」ですが、5.0が2016/2/7に発表されました!

TechPreviewというところは未だ脱していませんが、Versionも5.0となりそろそろバグもとれてきたかなという感じです。(このままいくと、vSphereのメインバージョンを超えてしまいそうな気がします。バージョンアップの際に常にメインバージョンで上がっていくのは少々気になりますね)

さて、今までご紹介した、サクサク快適なスピードはそのままに、Embedded Host Client 5.0から、待望の日本語に対応しました。(4.0のころも言語選択の画面はありましたが、日本語を選んでも言語パックがないとメッセージが出ていました)

↓ログイン画面も日本語に


 ↓インターフェースもきちんと日本語化されています。


↓右クリックメニューもきちんと日本語化されています。


↓仮想マシン作成ウィザードももちろん日本語化済み

日本語化のクオリティも高く、いままで英語表記だから避けていた方も、是非活用できる一品ではないかと思います。

ちなみに、デフォルト言語の英語しか表示されない場合、ログイン後以下の方法で日本語設定が可能です。

↓ 日本語表記の設定方法




ダウンロードはこちらからどうぞ
https://labs.vmware.com/flings/esxi-embedded-host-client

インストールは、ESXiにSSHでログイン後

esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxui/esxui-3530804.vib
でインストール完了です。
(ESXiがインターネットに接続できない場合は、事前にvibをダウンロードしておきましょう)

管理画面にアクセする場合は、
http://ESXiのIPアドレス/ui/
で、アクセス可能です。
ユーザー名/パスワードは、ESXiにログインするID/パスワードを入力します。









2016年2月20日土曜日

vExpert 2016 Award 受賞しました!

本ブログを開設してもうすぐ1年となりますが、その一足早く、VMware社より毎年発表される、vExpert Awardにて、vExpert 2016 Awardを受賞することができました!




ちなみにvExpertとは、
年間を通じて VMware の製品やテクノロジーの普及やサポートに大きく貢献した個人に与えられる称号
です。

VMware製品を中心に、新しい情報とトラブルシューティングやドキュメントに記載されていない事項を中心に情報を掲載してきましたが、それを貢献として認めていただいたのだと思います。

個人的には、憧れのアワードでしたのでまさか自分が受賞できたことは、大変うれしいことです。また、本ブログを読んでいただいた皆様に感謝申し上げます。

今後も、VMware製品は今年はその他のサードパーティー製品も含めてご紹介をすることができればと思っております。





2016年2月7日日曜日

NSX for vSphereのVXLANの通信をWiresharkで見てみる

さて、VXLANの通信は、UDPでカプセル化される。カプセル化とカプセルを解く作業は、VTEPといわれる、ESXiごとに展開されるカーネルモジュールで行われるというお話をしました。

では、以下のような環境で、実際に仮想マシン同士の通信を見てみましょう。

この環境下で、VM1からVM2にPINGを投げてみましょう。
尚、VM1とVM2は、VNIが異なっており、DLRを別途用意し、ルーティングが正常に行われる環境下です。また、レプリケーションモードはユニキャストで設定されています。

実際にDataPlainである、VXLAN通信が流れる物理スイッチにミラーポートを設定して、Wiresharkを利用して、パケットをのぞいてみましょう。
(図で言うと紫色のラインの部分で流れる通信を見ることになります)


実際の仮想マシンのIPは、「172.16.1.11」と「172.16.0.12」であるにもかかわらず、Wiresharkでみると、通信は「10.0.0.1」と「10.0.0.2」となっています。

図を見るとわかるとおり「10.0.0.X」は、ESXiに搭載されたVTEPが保有しているIPアドレスとなります。そのため、この通信はUDPでカプセル化されたVXLANの通信であることがわかります。

また、Infoのところを見るとわかるように、宛先は「8472」になっています。これも、NSX for vSphereが、IANAに登録される前のドラフト時代のポートである8472をVXLANの通信として利用することがわかります。

ここでわかることは、VXLANの通信は、物理ネットワークの層から見ると全部カプセル化されていますので、デバッグが難しいと言うことです。仮想マシンが何の通信をしているかはこれだけではわかりません。

ただし、前のお話の通りVXLANは、IPSECのような暗号化はしておらず、単純にL2フレームを包んでUDPパケットに変換をしているだけです。では、VXLANのヘッダーを外せば元のパケットの中身が見られるのではと想像できます。

このヘッダーを外す機能は、Wiresharkに機能として搭載されています。
その機能をご紹介します。

1.まずは、Wiresharkの「分析」メニューから「...としてデコード」を選択します。


2.「+」マークをクリックします。


3.行が追加されますので、以下の通りに設定をします。
  • フィールドに「UDP Port」
  • 値に「8472」
  • 現在に「VXLAN」
 を選択し、OKをクリックします。


4.するとVXLANヘッダーが外され、仮想マシン間の通信パケットが表示されます。
(図で言うと、緑の矢印で書かれた仮想マシン間の通信になります。)
この場合、「172.16.1.11」と「172.16.0.12」の仮想マシン間でICMPで、PINGのリクエストと応答が行われていることがわかります。



手順は簡単ですし、これでNSX for vSphereを利用した際の、VXLANトラブルシュート行う場合に非常に便利な手法ですので、押さえておくとよいかと思います。






Horizon View 6.2.2 リリース

2016年になり、Horizonシリーズもメインバージョンが上がるのかなと思っていましたが、先にHorizon View 6.2.2がリリースされました。
今回のリリースは機能追加ではなく、バグフィックスがメインのようです。

早速リリースノートを見てみましょう。

このリリースの Horizon 6 の新機能
VMware Horizon View 6.2.2 はメンテナンス リリースです。 前のリリースのいくつかの既知の問題が解決されています。

と記載がありますとおり、まずはメンテナンスリリースであることが記載されています。


解決された問題

  • ユーザーがセキュリティ サーバを介して接続している場合、ユーザーの PCoIP セッションの応答時間が低速になる場合があります。
  • リモート アプリケーションに対するプリンタのマッピングが断続的に失敗します。

さてこの2点ですが、結構クリティカルな問題です。
2つめの、RDSHの公開アプリケーション時にプリンターマッピングがなされないという症状は、私も経験をしたことがあります。(同じホストとクライアントでも、RDSH公開デスクトップだったらプリンターマッピングが成功する)

小さなバグフィックスのようにも見えますが、RDSHを利用時には結構はまりどころな問題です。特にプリンターマッピングやセッション応答までに時間がかかるとなると、ネットワークまわりなどもかなり疑うことになりますので、導入時にはバージョンの確認を先にすることをお勧めします。

(参考)
VMware Horizon 6 バージョン 6.2.2 リリース ノート



NSX for vSphereを見てみよう(7) VXLANを学ぼう(その2)

さて、VXLANの項もクライマックスです。
VXLANをデバッグする上でも知っておかなけえればならないのが、この各種テーブルの問題です。

L2のフレームをL3でカプセル化するとなると、VXLANで包まれた後の通信用MACアドレスと、元のL2フレーム時のMACアドレスなどいろいろな必要情報が出てきます。
特に物理ネットワークがL3レイヤーでまたいだセグメントの場合、どのノードに通信したい本来のマシンがあるかなどがわからないはずです。

では、まずはテーブルの種類を見ていきましょう。

VTEPテーブル
どのVNI(VXLAN Network Identifier)とVTEPテーブルを対応させるもの

MACテーブル
VNI、VTEP、仮想マシンのMACアドレスを対応させたテーブル

ARPテーブル
仮想マシンのIPアドレスとMACアドレスを対応させたテーブル

VTEPテーブルは、VXLAN独特のものですね。VNIといわれるVLAN-IDのようなもので、どのVNIがどのVTEPがESXiで構成されているかを持っています。

MACテーブル(L2スイッチは保有)とARPテーブル(L3スイッチや仮想マシンなどIPアドレスを認識するものが保有)は、通常と同じ考えですが、かならずVNIやVTEPとの関連性が出てきます。

では、このテーブルは各VTEP上にキャッシュされる仕組みになっていますが、このテーブル情報はどうやって各ESXiホストにあるVTEP同士で共有するのでしょうか?

これが、NSX Controllerの役割でもあります。
このテーブル情報の共有方法として、3つの種類をNSX for vSphereは保有しています。

<VTEPテーブルのレプリケーション方法>
  1. ユニキャストモード
  2. マルチキャストモード
  3. ハイブリッドモード
ユニキャストモードは、NSX Controllerで各テーブルが管理され、各情報をユニキャストで配信する仕組みです。

マルチキャストモードは、テーブル情報を常にマルチキャストで同期します。マルチキャストの場合、都度同期が走るため、NSX Controllerは、各種テーブル管理に介在しません。

ハイブリッドモードは、同じクラスター(vCenter Serverで構成したクラスター)の範囲間はマルチキャストで、違うクラスターをまたいだテーブル共有は、ユニキャストで行います。
違うクラスターとの通信の場合、受信をするESXiのVTEPは、1つが代表になり、代表が受信をした後、マルチキャストで同じクラスター内にテーブルが共有されます。
ちなみに、ハイブリッドモードで利用する際には、VTEP(L2フレームを変換したり戻したりする機能)のことを、MTEPと呼びます。

VXLANの仕様はもともと、マルチキャストでのテーブル共有しかありませんでした。(RFCもマルチキャストでの定義となっています)
ただ、L3 over L2であるにもかかわらず、L3越しのマルチキャストとなるとIGMPの設定など、いろいろと面倒な設定が物理層に必要になってきます。これはネットワーク仮想化を行う上で物理層に手を加える手間が出るのは不便であることと、そもそもIGMPに未対応なスイッチの場合、利用できないという観点から、ユニキャストモードとマルチキャストモードが新たにできた背景があるようです。


各種テーブルを作る動きは、VMwareのBlogに大変わかりやすく記載されていますので、是非こちらを参考にしてください。


第2回:論理スイッチ(VXLAN) –Layer2 の世界
https://blogs.vmware.com/jp-cim/2015/04/nwv02.html




2016年2月6日土曜日

NSX for vSphereを見てみよう(6) VXLANを学ぼう(その1)

さて、ここまで来たら少しプロトコルの話をしたいと思います。
VXLANの仕様について見ていきましょう。

VXLANは、VLANの4096枯渇問題を解決するものだとお伝えをしました。
となると、イメージするのはQinQのような、VLANを更に上位で拡張するような仕組みにイメージするかもしれませんが、これは違います。

その鍵は、「VXLANを使うとL3 over L2でL2延伸が可能」という点にあります。
VXLANには、
  • VLANの4096枯渇問題を解決
  • VXLANを使うとL3 over L2でL2延伸が可能
この2つを同時に解決するのがVXLANです。

つまりL2のフレームをL3パケットに包んで通信をするというのがVXLANの仕様です。


以下は、VXLANのパケット構造です
これを見るとわかるのですが、元のL2フレームをそのままカプセル化して、VXLANの必要ヘッダーを追加した上で、UDPパケットに変換されていることがわかります。IPSECのように暗号化などはされずそのまま包んでいるだけです。

だいたい見当が付いてきたと思います。
L2のフレームをUDPパケットに変換するのが、VXLANの仕様で有り、このVNIに16bitの保有が有り、VLANのように4Bitではないところが特徴です。

そう考えると、じゃあ、L2フレームでVLANIDが付与したパケットを流せば、4096×1677のネットワークが構成できるじゃないかと思いますが、それは基本しないようにというRFCの指針が記載されています。

この構造で、QinQのようなVLANをカプセル化するものではなく、このカプセル化する際のVLAN-IDのような役割をはたすVNI(VXLAN Network Informatio)が、1677万程度の付与できるというのがポイントになります。

では、ここでVXLANにおけるポイントをさらに押さえていきましょう。

<Point>
  1. UDPで利用するポートは8472(RFCで定義される4789ではない)
  2. VXLAN通信を行う通信機器は、MTUが1600以上(JumboFrame)対応の機器が必要
  3. VXLANパケットは、フラグメントできません。(DFビットが立っています)

まず1つめですが、NSX for vSphereは、RFC準拠のポート4789ではなく、まだドラフト時代に利用していた、8472/UDPを利用しています。

続いて2つめですが、VXLANは、普段のL2フレームをそのままカプセル化するというお話をしました。 通常、L2のフレームは1518byteですので、これに約40byteが付加されます。
そのため、VXLANを転送するネットワーク物理層が、1500Byteまでしか転送できないとなると、既存L2フレームにVXLANヘッダーが乗ったパケットはそのままでは送信できません。

ここで3つめです。サイズの大きなパケットの場合、フラグメントという形でパケットを分割する仕組みが有りますがVXLANパケットは、DFビットが立っているためフラグメントつまり分割は許可されていません。
仮に分割ができた場合の話しですが、VXLANパケットが任意の場所で分割されると、元のL2フレームが意図されない形で分割され、UDPでカプセル化されたます。UDPは、TCPのように完全性がないため、VXLANパケットの複合化をするときに、正しく複合できない可能性が出てくるためです。

ここで、わかったこととして、L2のフレームをL3に変換してくれるものが必要になると言うことですね。この変換する仕組みをVTEPといいます。VTEPで変換されUDPになったパケットは、NSX for vSphereで設定した、ESXiのVMKernelポートを利用して、外に出て行くことになります。


VXLANの構造は、わかりましたね。
次は、カプセル化した際におけるMACテーブルやARPテーブルについて考えてみましょう。





NSX for vSphereを見てみよう(5) NSXの主要コンポーネントを紹介(データープレーン)

さて、では最後になりましたデータープレーンについてご紹介をします。
データープレーンとは、実際のネットワーク仮想化を行うエンジン部分となります。

このデータープレーンですがまず、2つの切り分けがあります。
  1. ESXiカーネルモジュールで提供されるサービス
  2. 仮想アプライアンスで提供されるサービス
の2つとなります。
1.は、カーネル側で処理をされますが、2.は、仮想アプライアンスで展開されますので、基本どこかのESXiホストで稼働する形となります。機能的にもvCloud Network and Security時代のvShield Edgeで展開されるEdge Gatewayの後継となります。

ではまず、カーネルモジュール側のコンポーネントをご紹介しましょう

◆カーネルモジュールでの提供

1.論理スイッチ(Logical Switch)
これは、VXLANを展開した際、VXLANにもVLANと同じようにIDが存在します。VLAN-IDのVXLAN版が、VNI(VXLAN Network Index) と思っていただければよいです。この1つのVNIに対して、1つの論理スイッチができる形となります。VLANに対応していないスイッチをそれぞれ配置するように、VLANの場合のvSwitchの用にポートグループで、VLANを分ける構成ではなく、VXLANの場合は、VNIごとに論理スイッチができるのが構成ポイントです。

2.分散論理ルーター(Distributed Logical Router)
通称「DLR」と呼びます。分散ルーターとも呼ばれます。これは、論理スイッチや分散スイッチ(vDS)のポートグループなどいわゆるL2スイッチの機能に対して、ルーティングの機能を提供します。これが、L2スイッチをL3スイッチに変換させ、EAST-WEST通信のヘアピンをなくす重要なコンポーネントとなります。ダイナミックルーティングにも対応します。

3.分散ファイアーウォール(Distributed Firewall)
これは、マイクロセグメンテーションにおける重要なコンポーネントです。具体的には、分散スイッチ(vDS)のdvFilterといわれる機能を利用しており、仮想マシンのvNICごとに展開され、通信の制御ができます。仮想マシン単位でファイアーウォールが展開されるため、L2ネットワーク環境下でも細かい通信制御ができるようになります。

4.分散ロードバランサー(Tech Preview)
こちらは、まだ正式なリリース機能ではありませんが、NSX for vSphere 6.2から、分散ロードバランサーの機能が提供されるようになりました。こちらは、EAST-WEST間の通信におけるロードバランシングを行う機能です。ただ、カーネルベースでの処理のため、パフォーマンスに主眼を置いており、ヘルスチェックなどの機能は現行ありません。仮想マシンで冗長構成が組まれている場合で、WEBサーバーとAPサーバーのAPIコール通信などを分散したい場合に利用可能です。


◆バーチャルアプライアプライアンスでの提供

まず、バーチャルアプライアンスで提供される各種機能は、Edge Security Gateway(ESG)で提供されます。そのため、ESGといわれたら、このデータープレーンのバーチャルアプライアンスのことを思い出してください。

1.ファイアーウォール
こちらは、カーネルベースではなくVAとして提供されますので、L3での利用が前提となるケースで利用します、またNATなどは、カーネルモジュールの分散ファイアーウォールでは提供されませんので、今までのネットワークアプライアンスと同様な動作が可能です。

2.ルーティング
こちらも、DLRと異なり、より細かい設定が可能になることと、分散スイッチのポートグループや論理スイッチだけではなく、標準スイッチからのルーティングも可能となります。(DLRは、分散スイッチと論理スイッチでのルーティングしかできません)
物理層にあるネットワーク機器との接続の際によく利用されます。もちろんダイナミックルーティングにも対応しています。ここは、以前のvCNS時代のEdge Gatewayよりも機能アップしています。

3.VPN
こちらは、カーネルモジュールには提供されていない機能です。
 IPSECとSSL-VPNの2つが提供されています。

<SSL-VPN>
SSL-VPNは、最大で1000ユーザーの同時接続に対応し、Windows / Mac / Linuxの接続クライアントが提供されます。
このアーキテクチャーは、NeoAccel社のSSL-VPN Plusを利用しています。(NeoAccel社はVMwareに買収されました)
また、L2によるサイト間VPN機能もこのSSL-VPNを使って行うことが可能です。


<IPSEC-VPN>
IPSEC-VPNは、L3によるサイト間接続をする際に利用します。最大で、6000トンネルに対応しています。

4.ロードバランサー
こちらは、vCNS時代のEdge Gatewayから一番機能アップしたところではないかと思います。
最大1024VIP(仮想IP)に対応し、ワンアームとインライン(ツーアーム)モードに対応しています。
このEdge Security Gatewayのロードバランサーは、 SSL証明書を食べさせることもでき、SSLアクセラレーターとして利用することも可能となります。ヘルスチェックももちろん可能ですので、いわゆる100万円程度で販売されるローエンド市場のロードバランサー以上のことができるイメージでいてもらえればよいかと思います。カーネルモジュールの分散ロードバランサーに比べて、多機能であり、商用サービスレベルに耐えられるバランサーです。

データープレーンになると、細かい動きが見えてきますので、できることがよりよくわかってきたかと思います。




NSX for vSphereを見てみよう(4) NSXの主要コンポーネントを紹介(制御プレーン)

ではでは、次に制御プレーンを見てみましょう。

 制御は、NSX Controllerで行われます。
NSX Controllerは、NSX Managerで登録したvCenter ServerのvSphere Web Clientから、展開をします。

NSX Controllerは、VXLANにおけるVTEPテーブルといった各種テーブルの管理や分散論理ルーター(DLR)といわれるESXiのカーネルモジュールで動作するルーターなどの一部情報を持っています。

さて、このコントローラーは、「Paxos」というアルゴリズムを採用しており、冗長化と負荷の分散を御個なります。そのため、NSX Controllerは3台の展開が必須となっています。
※検証環境の場合は1台でも動作しますが、サポート対象外となります。

NSX Controllerの展開においては、共有ディスクは必須ではありません。ESXiもDASへの配置が可能です。また、NSX for vSphereを利用する際にはvDSが必須と言われていますが、NSX Controllerは、標準スイッチにも展開が可能です。そのため管理ノードは標準スイッチで公正といった環境でもOKです。


ちなみに、NSX Controllerは、VXLANやDLRなどネットワーク仮想化を利用する際に必須のコンポーネントとなりますが、分散ファイアーウォールの機能(マイクロセグメンテーション)単体で利用する際には、NSX Controllerは利用されませんので、その場合は無理して展開をする必要はありません。




NSX for vSphereを見てみよう(3) NSXの主要コンポーネントを紹介(管理プレーン)

では、NSX for vSphereを構成するコンポーネントを見ていきたいと思います。

NSXを説明する上で、よく見かけるこの図をベースに見ていきたいと思います。


では1つずつ見ていきましょう

◆管理プレーン

NSX for vSphereを購入するとNSX Managerの仮想アプライアンスが提供されます。
すべてはここから始まります。
まずは、既存のvSphereにこの仮想アプライアンスを展開します。
展開後、vCenter Serverと紐付ける設定を行います。
NSX Managerは、NSXで構成された仮想ネットワークの設定管理情報を保有しますが、通常の設定オペレーションではNSX Managerは利用しません。通常の設定は、NSX Managerが提供する、vSphere Web Clientのプラグインである「Network and Security」のアイコンから操作を行います。

NSX Managerの画面

細かい設定は、vSphere Web Clientから行います。



では、次回はコントローラーを見ていきたいと思います。



NSX for vSphereを見てみよう(2) NSXは何ができるのか?

さて、NSXの生い立ちはわかりました。
で、何ができるのかというのが、という話をしたいと思います。

NSX for vSphereは、vCloud Network and Security(vCNS)の流れを踏んでいるとお伝えしました。実際、vCNSでできた機能は、すべて機能アップした上で、ほとんどの機能が利用できます。

vCNSというか、vShield時代は管理方法や機能バランスが悪いく、正直あまり導入されているケースは少なかったかと思います。
データーセンター事業者で、vShield Edgeを利用されていたり、DeepSecurityとの連携でvShiled Ednpointを利用していたりと部分部分での利用だったかと思いますが、NSX for vSphereになって、統合的な展開と管理ができるようになり、より実用性になったと思います。

NSX for vSphereを使うメリットを紹介しましょう


1.VXLANの利用で、ネットワークの仮想化とマルチテナントを実現
これは、従来からのVXLANのメリットであるVLAN枯渇問題の対応がまずあげられます。
これ自体は、vCNS時代から提供されていました。
NSX for vSphereでは、VXLANのセグメントを「論理スイッチ(Logical Switch)」という表現を行い、この論理スイッチをどんどん追加したり、消したりできます。
NSX for vSphereで管理できるVXLANの数は、1万程度です
VXLANの特徴はまた改めてお話をしたいと思いますが、物理ネットワークにVLANのTRUNK設定やVLANインターフェースの作成など面倒くさいことをせずに、L2のネットワークを自由に作成できることがメリットになります。
物理ネットワークに影響を与えずに、ネットワークをどんどん拡張できることから、マルチテナントにおけるクラウド環境における"自動化"も、仮想マシンの自動展開の時代から、ネットワークを含めた環境が自動展開が可能となります。
自動化には、REST APIを利用するほかに、vRealize Automationを利用することが可能です。
これで、仮想マシンの自動販売機から、インフラ基盤の自動販売機の構築が可能となります。



2.EAST - WESTの通信におけるヘアピーニングを削減
これだけ聞くと意味がわからないのですが、いわゆるL3スイッチの上り下り問題です。
同じESXiにVLAN10に属する仮想マシンとVLAN20に属する仮想マシンがいたとしましょう。
同じESXiの中ですのが、VLAN10の仮想マシンがVLAN20に通信をしようとすると、ESXiのvSwitchを経由しますが、このvSwitchは、標準スイッチ(VSS)、分散スイッチ(vDS)は、良くも悪くもL2スイッチですので、ルーティングができません。そのため、vSwitchから上位に接続されるL3スイッチでルーティングされることになります。そのため同じホストで繋がっているにもかかわらず、かならず外に出てルーティングされてまた戻ってくると言う通信のヘアピンが発生することになります。
これは、無駄ですね。ということで、ESXiのvSwitchをL3スイッチにしてしまうという考え方が、分散論理ルーター(DLR)になります。この分散論理ルーターは、ESXiカーネルモジュールとして提供され、各ESXiホストでパケットをルーティングしていわゆるヘアピン処理をなくすことが可能です。
これにより、上位のL3スイッチに莫大な投資をすることが不要となります。



3.分散ファイアーウォールによるマイクロセグメンテーション
いままでのFirewallは、ゲートウェイとして動作し、いわゆるネットワークの境界として動作をしていました。これはL3ネットワークにおける、セグメントを跨いだ場合において有効ですが、同じセグメントにある端末において細かい通信セキュリティを設定することはできません。
この場合は、Windows Firewallやiptables(firewalld)のようなOSベースの機能を利用するか、トランスペアレントの設定が施されたアプライアンスを展開するしか方法がありません。しかしいずれの方法も台数が増えると一括管理をする仕組みがないため、管理コストが膨大になります。
しかし、NSX for vSphereを利用すると、仮想マシンの手前にファイアーウォールが展開され、 L2ネットワークにおいても通信セキュリティの設定が可能となります。
この機能とサードパーティーのセキュリティ製品を組み合わせることで、たとえばマルウェア感染した仮想マシンだけを動的に一切の通信を不可にするといったダイナミックなL2ファイアーウォールによるマルウェアの拡散も可能となります。


4.Edge Security gatewayによる、VPNやADCの提供
プライベートクラウド基盤を企業や組織において構成した場合、サーバーリソースの仮想化による共同利用は可能となりました。
例えばある企業で、営業向けのCRMを導入することになったとしましょう。立てる仮想マシンは共通のプライベートクラウド基盤に構築しました。システムの冗長構成を組むために、WEBロードバランサーと、営業だけがアクセスできるSSL-VPNの構築が別途必要となりました。
こうなると、情報システム部で基盤のロードバランサーやVPN装置を貸すことはできないので、結果部門でロードバランサーアプライアンスやVPNアプライアンスの導入をすることとなりました。
こんな話し、結構あるあるな話しなのですが、実際これはせっかくのプライベート基盤であるにもかかわらず、部門負担のネットワーク装置が設置されるという、すべてをクラウド基盤から提供するというポリシーを守れない結果となります。(かといって、部門ごとに必要な台数のロードバランサーを都度情報システム部で購入するわけにも、必要なリソースが読めないのに大規模なロードバランサーをあらかじめ購入することも現実的ではありません)
こんな時、NSX for vSphereを導入すれば、仮想化基盤と同じようにロードバランサーやSSL-VPNなどのネットワークアプライアンス(仮想アプライアンス)を展開、提供することが可能です。


5.VXLANによるL2延伸
これは、言わずと知れずです。サイトをまたいでネットワークを構成した場合、どうしてもL3で違うセグメントになってしまいます。VXLANは、L2フレームをL3パケットに包んで通信をしますので、L3越しのネットワーク環境下で、同じL2ネットワークを利用することができます。
DRサイトを構築した際には、DRサイトで稼働したときにIPアドレスが変わることに対する対応は大変です。仮想マシンのIP変更はもちろん、DNSへの反映、内部で利用為ているDBなどのアプリケーションの接続をFQDNへの変更等々。こんな課題もVXLANを利用すればなくなります!



さあ、NSX for vSphereの魅力はわかりましたのでしょうか?
ネットワークの仮想化は、魅力が満載ですし、サーバー仮想化による課題事項が解決できる製品だと思います。これが、SDDC(Software Defined Data Center)を実現する大きな役割を施す成否であることも是非認識をしていただければと思います。




NSX for vSphereを見てみよう(1) NSXとはなんぞや?

最近VMware NSXというキーワードをよく聞きます。
そもそもVMware NSXとは、なにものなのか?
何が凄いのかを改めて見てみたいと思います。

さて1回目は、NSXとはなにかを見ていきたいと思います。

NSXというキーワードを聞くとホンダを思い出す方もいるかと思いますが、HONDA NSXとの関連性はおよそ無いと思います。
(ただ、Project EnzoみたいなものVMwareで走っていますので、ひょっとしたらその走りで名前がついた?)

そもそもNSXとは、ネットワーク関連の製品であることはまず押さえておいていただきたいと思います。

NSXを語る上でまず、2つの事項をおさらいしておきたいと思います。


◆VMwareが取り組んだネットワーク仮想化

これは、言わずと知れたvCloud Network and Security(旧vShiledシリーズ)ですね。仮想化基盤にvShieldを入れてネットワークコンポーネントを仮想化環境で動作させるものです。


vShield Zones仮想マシン間のトラフィックに対するセキュリティ機能を搭載
(ESXiホストをまたいでの管理ができない)
vShield App仮想データセンターを単位としたファイアウォールとして機能する。
vShield Zonesの上位版のイメージ
vShield Edgeロードバランサー、ファイアウォール、SSL/IPSEC VPN、NAT、DHCPサービスなどを提供する仮想アプライアイアンス。vCloud AirのEdge Gatewayはこのアプライアンスのことである。
vShield Endpoint仮想データセンター上に配置される仮想マシンにウイルス対策機能を提供。
Deep Security、Sophos、カスペルスキーなどのサードパーティー製ウイルス対策ソフトと連携
vShield Manager vShieldファミリすべての管理を行う仮想アプライアンス
上記の機能は、このManagerより展開される。

さて、このvShield Managerでもう一つある機能が「VXLAN」です。
VXLANは、VMwareとCiscoが中心となって提案する、現在のVLANを拡張する技術である。2011年8月に、VMware、Cisco、Arista、Broadcom、Citrix、Red Hatの共著で、IEEEへ申請が行われ、現行はRFC7348として制定されています。

VXLANの細かい話しはまた改めてお話をしますが、データーセンター事業者において、VLAN4096の制限は、マルチテナントにおいて大きなハードルでした。これを4096×4096の1677万のセグメントが作成できるのがVXLANの特徴です。

さて、NSXを語るに当たってはもう一つ重要なコンポーネントがあります。


◆Niciraが取り組んだネットワークの仮想化

Niciraは2007年に、OpenFlowの開発者であるマーティン・カサド氏が設立したITベンダー会社です。 2011年にOpenFlowをベースとしたネットワーク仮想化を提供する「NVP(Network Visualization Platform)」の出荷を開始。
Niciraの思いは、KVMやXen、ESXiなど、各社違うハイパーバイザーで構築されたクラウド基盤を、ハイパーバイザーに関係なく、L2ネットワークでつないでしまうという壮大な構成です。
ネットワークの仮想化(SDN)の中心にあった会社で、2012年7月に米VMware社によって買収することが発表された。


NSXは、vCloud Network and SecurityとNicira NVPの融合によりできた製品ですが、その2つの系統は引き継がれ、2つの製品群
  • NSX for vSphere
  • NSX for MultiHypervisor
の2製品としてリリースされています。


最近では一般的に「NSX」というキーワードが出た場合、「VMware NSX for vSphere」を指すことが多いです。(2014年ぐらいまでは、for vSphereシリーズがなかったため、NSXというと現在のNSX for Multi Hypervisorを指していました。そのため文献を見るときは、年代を確認する必要があります)