Cloud Express:SaaS、クラウド環境をSD-WANで快適に

ViptelaのSD-WANソリューションは単にSD-WANを提供するだけにとどまりません。Viptelaが目指しているのは「クラウド/SaaSに最適化されたWANを提供する」ことです。「リージョナル/ローカルExit」もクラウド/SaaSに最適化されたネットワークを作るための一つの有効な方法であることは前回ご紹介しました。今回ご紹介する “Cloud Express” という機能は、単純なリージョナル/ローカルExitよりもさらにインテリジェントにSaaS/クラウドに最適化されたネットワークを提供することのできる機能で、Viptelaソリューションが持つ非常にユニークな機能の一つです。

課題はSaaS、クラウドへのラストマイル

「ユースケース:アプリケーション対応ルーティング」の回で説明した通り、vEdge間で張られているIPsecトンネルの中にBFDのパケットを流して、各トンネルの品質(遅延、ジッター、パケットロス率)を常に監視しています。フルメッシュなネットワークであればすべてのvEdgeの間でこれらを測定して各トンネルの品質を把握していますので、vEdgeのネットワーク内に関してはどのvEdge(例えばローカル、リージョナル、DC、など)Exitするのが最適であるのかを判断することができます。しかし、出口のvEdgeからSaaSサービスまでのネットワークの品質は分かりませんので、本当にどの出口からExitするのがいいのか判断をすることはできません。一般的にはローカルからExitする方が良好なパフォーマンスが得られる場合が多いと考えられますが、場合によってはDCから抜けた方が良い場合もあるかもしれないわけです。

Cloud ExpressでSaaS、クラウドをより快適に!

Cloud Expressはエンド〜エンドでSaaSアプリケーションの品質を監視します。具体的には、出口となるvEdgeからSaaSアプリケーションまでの遅延などをHTTP pingなどにより監視をして、vEdge内のネットワークの遅延と合計します。これによりSaaSアプリケーションにとって本当にどのExitポイントが最適なのかを判断し、それに基づいたポリシーを自動的に適用することにより、SaaSアプリケーションに最適なネットワークパフォーマンスを提供します。Cloud Expressは、まずはOffice 365、SharPoint、Salesforce.com、Dropbox、Box、WebExなど代表的なSaaSアプリケーションに対応します。

CloudXpress
Cloud ExpressはSaaS、クラウドアプリケーションに最適なパスを提供

Cloud Expressは2016年12月末リリース予定の16.3というソフトウェアリリースから利用可能になります。まだリリース前なので、具体的な画面などはソフトウェアがリリースされてから再度ご紹介をしようと思います。

Viptela SD-WANのオンプレ展開

Viptelaのコントローラコンポーネント(vBond, vSmart, vManage)は通常Viptelaが運用管理しているクラウド(これは現状AWS上にあります)にデプロイして利用するのが一般的です。コントローラのインフラストラクチャの運用管理をViptelaに任せることができるので、サービスを素早く立ち上げることができます。しかし、何かしらの理由でこれらのコントローラコンポーネントを自社設備(オンプレ)に立てたい、または、サービスプロバイダーなどが自前のパブリッククラウド上にデプロイして使いたい、という場合もあるかと思います。Viptelaのソリューションはオンプレ環境でもまったく問題なく利用をすることができます。

コントローラコンポーネントを動作させるハイパーバイザとしては、現在VMware ESXi及びKVMがサポートされており、それぞれOVA形式、QCOW2形式のイメージがが提供されています。2016年末にはこれらに加え、Hyper-V用のサポートが加わる予定です。

これらのコントローラコンポーネントはvEdgeからIP的な到達性さえあれば、パブリッククラウド、プライベートクラウド、オンプレ、どこにデプロイしても構いません。コントローラをオンプレにデプロイした際でも、Viptelaソリューションの持つすべての機能を利用することができます。このようにオンプレ環境にコントローラを置くことができますので、インターネット接続のない環境(完全クローズドなネットワーク環境)でもViptela SD-WANソリューションを使うことができます。

オンプレ環境でコントローラを立てる際には、vBond、vSmart、vManageで以下のようなスペックを満たす仮想マシン環境を用意する必要があります。

  • vBond
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 8 GB 1 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 2 4 GB 8 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 2 4 GB 8 GB 5 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 4 8 GB 8 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vSmart
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 16 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 4 8 GB 16 GB 5 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 4 16 GB 16 GB 7 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 8 16 GB 16 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vManage
サイト数 vCPUs RAM OS用ボリューム DB用ボリューム 帯域 vNICS
1-250 16 32 GB 16 GB 500 GB, 1500 IOPS 25 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
251-1000 32 64 GB 16 GB 1TB, 3072 IOPS 100 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
1001- 32 64 GB 16 GB 1TB, 3072 IOPS GB 150 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)

ゼロタッチプロビジョニング

多数の拠点をもつ企業にとって、WANルータの管理は負荷の高いオペレーションです。特に、海外展開などにより物理的に離れた拠点が増えると、WANルータの管理にかかる運用コストも高くなります。ViptelaSD-WANソリューションでは、「vManageによるオーバーレイネットワークの管理」の回でご紹介した一元的な運用管理に加え、vEdgeの初期展開の負荷を大幅に軽減するゼロタッチプロビジョニング機能が提供されています。

ゼロタッチプロビジョニングによる展開

ゼロタッチプロビジョニングとは、工場出荷時状態のvEdgeをそのまま拠点に展開できる仕組みです。展開前もしくは展開時に、vEdgeに対して設定投入などの作業を一切する必要がないことから「ゼロタッチ」と呼ばれています。

ゼロタッチプロビジョニングの仕組み自体は非常にシンプルです。工場出荷時のvEdgeでは、物理インターフェースでDHCPクライアントが有効になっており、起動後にztp.viptela.comというサイトにアクセスするよう設定されています。このため、vEdgeDHCPサーバからIPアドレスを受け取り、DNSサーバでztp.viptela.comを名前解決することができれば、vEdgeztp.viptela.comにアクセスを試みます。

ztp.viptela.comは、ZTP(Zero Touch Provisioning)サーバと呼ばれるViptelaが運用するコンポーネントです。このサーバは、接続してきたvEdgeをセキュアに認証したうえで、所有者であるユーザ企業を特定し、適切なコントローラにリダイレクトさせます。vEdgeが所有するユーザ企業のコントローラに接続すると、コントローラはvEdgeを認証し、vManageのテンプレート機能を使用して必要な設定を適用します。この一連のプロセスは完全に自動化されています。

詐称による企業ネットワークへの不正侵入を防ぐため、ゼロタッチプロビジョニングにおいてvEdgeの認証を適切に行うことは極めて重要です。個々のvEdgeにはTPM(Trusted Platform Module)チップが内蔵されており、シリアル番号を含む証明書が記録されています。ZTPサーバやコントローラとの認証にはこのシリアル番号が使われます。物理的には読み取れないように処理された特殊なチップであるTPMチップを使うことで、vEdgeは詐称などのリスクを排除して適切に認証できるようになっています。ゼロタッチプロビジョニングはSD-WANを標榜する製品の中でよく見られる機能ですが、実際の動作仕様はそれぞれ異なり、実際には現場で個々のデバイスの認証を行う必要があるソリューションもあり注意が必要です。

機器故障によるリプレイス

万一vEdgeが機器故障を起こし、ハードウェア交換が必要となった場合、管理者は新しいvEdgeのシリアル番号に対して、それまで使っていたvEdgeの設定テンプレートとパラメーターを割り当てることができます。その後、新しいvEdgeを起動すると、ゼロタッチプロビジョニングによっての旧vEdgeの設定が自動投入されます。これにより、ハードウェア交換のプロセスは非常にシンプルなものとなります。

コールドスタンバイのvEdgeにはライセンスが必要ありません。vEdgeハードウェア自体は非常に安価に提供されていますので、予備のvEdgeを置いておくと、ハードウェア障害時にも、現場で即座に予備機に電源コードとLANケーブルを差し替えることでサイトの復旧が可能になります。WANルータがシンクライアントのように、簡単に扱うことができるようになるわけです。

PPPoE等の非DHCP環境でのプロビジョニング

前述の通り、ゼロタッチプロビジョニングが動作するためには、vEdgeはDHCPでIPアドレスを取得し、DNSサーバでztp.viptela.comを名前解決できる必要があります。日本で非常によくつかわれているPPPoEなどの非DHCP環境において、vEdgeを直接網につなぐためには、ゼロタッチプロビジョニングを使うことができません。

この場合、あらかじめインターネット接続のために必要な最低限の設定をvEdgeに追加することで、その後の処理はゼロタッチプロビジョニングと同様に自動化することが可能です。vEdgeの工場出荷時設定では、管理目的で192.168.1.1/24が割り当てられた物理ポートがあるほか、コンソール接続でもPPPoEの設定情報を投入できます。完全なゼロタッチではなく「ワンタッチ」となりますが、拠点での実際の作業は電源コードとLANケーブルをつなぐだけという点に違いはありません。

このように、ViptelaのSD-WANソリューションでは、ゼロタッチプロビジョニングによりvEdgeの初期展開およびハードウェア交換にともなう企業の負荷を大幅に軽減しています。

vManageによるオーバーレイネットワークの管理

vManageはViptelaのSD-WANソリューションを構成するコンポーネントの1つで、オーバーレイネットワークの動作状況や各コンポーネントの設定情報を管理しています。管理者はvManageのGUIもしくはRESTful APIを使用して、オーバーレイネットワークの運用と管理を行います。今日は、スクリーンショットを使いながら、vManageの主要な機能をご紹介したいと思います。

ダッシュボード画面

vManageのGUIのトップページであるDashboard画面によって、管理者はオーバーレイネットワークのリアルタイムの状況を簡単に把握できます。Dashboard画面には、vSmartやvEdgeなどの各コンポーネントの状態や、コントロールプレーン(DTLS/TLSトンネル)の接続状況、データプレーン(IPsecトンネル)の接続状況と品質などが一覧で表示され、問題がある場合にはすぐに把握できるようになっています。

vManage Dashboard

Dashboard画面の各ブロックをクリックすることで、詳細を表示することもできます。例えば、ダッシュボードの左下にある青い棒グラフのブロックをクリックすると、オーバーレイネットワークを流れるトラフィックをDPI (Deep Packet Inspection)で可視化したグラフが拡大表示されます。グラフのそれぞれの棒をクリックすると、当該アプリケーションのトラフィックを多く送出している送信元IPアドレスを確認することができます。

vManage DPI
vManageを使ってネットワーク上を流れるアプリケーションを可視化

Dashboard画面の右下のブロックには、IPsecトンネルの回線品質の情報を表示されています。クリックすると下のスクリーンショットのように、各トンネルの遅延、パケットロス率、ジッターの情報が表示され、オーバーレイネットワークの中で最も品質が悪いトンネルを簡単に確認できます。

vManage AAR
vManageを使ってIPsecトンネルを遅延の大きい順に一覧表示

ジオグラフィー画面

MonitorセクションのGeography画面は、世界地図上に企業のViptelaコンポーネントの設置場所をマッピングして表示します。地図を拡大して、詳細な場所を表示することもできます。

vManage Geography
vManageのGeography画面

ネットワーク画面

MonitorのNetwork画面では、vEdgeやvSmartなどの各コンポーネントの詳細な状態を確認できます。インターフェースの情報、コントロールプレーンやデータプレーンのコネクションの状態、トラフィックの詳細を確認できるほか、直接コンポーネントにログインしてCLIで確認できる情報のほぼ全てがこの画面から確認できるようになっています。

vManage Network Control
vManageを使ってvEdgeのコントロールプレーンの状態を確認

さらに、ネットワークの疎通性や障害ポイントを簡単に確認できるように、GUIでのトラブルシューティング機能も提供されています。

vManage Troubleshooting
vManageが提供するトラブルシューティング機能

テンプレート画面

ConfigurationのTemplate画面では、vEdgeやvSmartなどの各コンポーネントの設定をテンプレートとして一元管理できます。CLIベースで設定を定義するCLI Templateと、GUIベースで設定を定義するFeature Templateという2種類の定義方法が準備されており、規模や好みに応じて使い分けることができます。テンプレートによる設定管理については、今後あらためて詳しくご紹介したいと思います。

vManage Template
GUIを使った設定の作成画面

今日ご紹介した機能のほかに、vManageはポリシーの管理や、各コンポーネントのソフトウェアのアップグレード、イベントやアラームなど、管理者にとって必要な機能を多数提供しています。また、それらの機能にはGUIだけでなく、Restful APIでアクセスすることもできます。

SD-WANのスケーラビリティ

ViptelaのSD-WANはIPsecによるオーバーレイネットワークです。今回はこのオーバーレイネットワークのスケーラビリティについて少し考えてみたいと思います。

オーバーレイネットワークの進化の方向性

オーバーレイ技術の歴史を振り返ると、その技術の進化の方向性としては、私は3つほどあるのではないかと思っています。

オーバーレイネットワークの進化の方向性
オーバーレイネットワークの進化の方向性

一つはカプセル化技術の進化です。古くはGREから、そしてその後もさまざまなカプセル化技術(IP in IP、MPLS、L2TP、VXLANなど)が生まれてきました。オーバーレイの二つ目の進化の軸はシグナリングです。こちらも過去さまざまな方式が生まれましたが、歴史的に振り返ってみると、勝者はBGP(あるいはその拡張)ということになるのではないかと思います。MPLS/BGP VPNの成功や最近のEVPNなどがそれを証明しているように思います。3つ目の進化の軸はスケーラビリティです。今回はここに注目してみたいと思います。

なぜフルメッシュが困難なのか?

一般的に大規模なフルメッシュのオーバーレイネットワークを構築するのは大変困難です。大きく分けると2つ理由あります。一つは設定(プロビジョニング)の困難さです。初期設定時に多くの工数がかかるものもちろんですが、むしろ大変なのはサイトを追加する時です。フルメッシュを維持するためには、対向の全てのノードにも再設定をしなければいけません。初期構築時は仮に頑張れても、運用に入った後に全てのノードの再設定をしなければいけないのは大きな苦痛を伴います。もう一つの困難さはステート維持です。使用するオーバーレイ技術が何かしらのステートを持つ場合、nノードからなるフルメッシュなネットワークでは、全体としてn^2のオーダー(O(n^2))のステートを維持管理していかなければいけません。IPsecの鍵もこのようなステートの一種です。IPsecのフルメッシュネットワークが難しいのは上記の二つの理由に依るところが大きいと言えます。

サイト追加時のプロビジョニングの苦痛を解決する策としては、過去にも提案がありました。例えばRFC6224です。提案者の名前から通称「Kompella方式」とも呼ばれる方法です。

Kompella方式
Kompella方式

この方式のポイントは「オーバー・プロビジョニング」をする、という点にあります。この方式では、例えばFrame RelayのネットワークであればDLCIをあらかじめ余計に割り当てておき、サイトが追加になった際にローカルの設定変更だけで残りのリモートサイトには変更が必要ないように工夫されています。

また、CoSine CommunicationsのIPSXは仮想ルータをIPsecで結んでオーバレイネットワーク(VPN)を作ることができました。

CoSine IPSX
CoSine IPSX

CoSineのInVisonというNMSには自由にハブ&スポークやフルメッシュのIPsecを構成する機能がありましたので、ある意味プロビジョニング上の問題は解決することができていたとも言えます。2000年当時、1仮想ルータで1000のIPsecトンネルを終端することができた(ハブ&スポーク)を構成することができた)のはかなり頑張っていたのではないかと思いますが、では1000個の仮想ルータでフルメッシュのIPsecトンネルを作れたかというと、それは全くもって不可能な話でした。

IPsecをスケールさせるのが難しい理由

IPsecをスケールさせるのが難しいのには二つの理由があります。IPsecの鍵交換プロトコルであるIKEで使われる処理(Diffie Hellmanの鍵交換)が非常に重たい処理であるという点。Diffie Hellmanの鍵交換がどれくらい重いのか、少し考えて見ましょう。

https://www.cryptopp.com/benchmarks.html を見ると様々な暗号化アルゴリズムのベンチマーク結果が出ています。この中からAES-CBC-256bitとDiffie Hellmanの鍵交換の結果を以下に掲載します。

Diffie Hellman鍵交換とAESによる暗号化処理の比較
Diffie Hellman鍵交換とAESによる暗号化処理の比較

AESなどの暗号化アルゴリズムの性能はスループット(MiB/s)で測るのに対し、Diffie Hellmanの鍵交換は1オペレーションの実行時間(msec/operation)で測りますので単純に比較はできませんが、仮に1500バイトのデータをAES-CBC-256bitで暗号化するのを1オペレーションとみなしてそれにかかる時間を計算して見ると上記のようになります。Diffie Hellmanの鍵交換はAES-CBC-256bitに比べると二桁ほど重い処理であることがわかります。このようにDiffie Hellmanの鍵交換処理は非常に重たい処理なのです。

IPsecのフルメッシュネットワークが難しいもう一つの理由が、IKEによって作られる鍵が “pair-wise” である、という点です。鍵がpair-wiseであるというのは、相手が異なれば異なる鍵を使う、すなわちペアごとに異なる鍵が存在するということです。nノードのフルメッシュのネットワークの場合にはO(n^2)の個の鍵が存在することになります。暗号鍵があるということは、必ず鍵の更新(Rekey)をしなければいけないということを意味します。どんな暗号化システムでも、同じ鍵を使い続けていけば暗号強度は必ず低下してくるからです。上記のように重たい処理であるDiffie Hellmanの鍵交換を全体としてO(n^2)回やらなければいけないのでとても大変です。O(n^2)問題を甘く見てはいけません。例えば1,000ノードのフルメッシュを構成するとおよそ500,000のペアが存在することになります。仮にIKEのPhase 1のRekey時間を24時間としましょう。24時間はたった86,400秒しかありません。この間に500,000回の鍵交換をしなければいけないわけですから、毎秒5〜6回のペースで鍵交換をし続けなければいけないことになります。3,000ノードのフルメッシュなら毎秒50回以上になります。

このように非常に重たい処理のIKEですが、IPsecにとって本当に必須のものなのでしょうか? 実際、多くの場合IPsecを使う際にはIKEが使われます。しかし、IPsecにとってIKEが唯一無二の鍵交換プロトコルというわけではありません。実は、IPsecにはKINKやPhoturisといった別の鍵交換プロトコルもあります。極端な話、手動で鍵を設定することもできるわけです(もちろん鍵の更新をしなければセキュアとは言い難いですが・・)。つまりIPsecにとってIKEは必須ではないのです。

IKEはセキュアなチャネルがないところにセキュアなチャネルを開設するプロトコルです。従ってすでにセキュアなチャネルがあれば、必ずしもIKEを使う必要はないという点に注意してください。「Viptelaのアーキテクチャー」の回で、コントローラとvEdgeの間のコントロールチャネルはTLSもしくはDTLSが使われているというご説明をしました。すでにそこにセキュアなチャネルがあるわけですから、それを使えば良いのです!

Viptelaによるスケーラブルなオーバーレイネットワーク

ViptelaのコントローラであるvSmartはBGPをベースに拡張をされたOMP (Overlay Management Protocol)というプロトコルを使って経路の配布を行っており、OMPはTLS/DTLSによるセキュアなチャネルの上で動いています。vSmartはBGPのルートリフレクタと同様の役割を果たしていて、経路情報をすべてのvEdgeに配布するようになっています。実はこのOMPは、経路だけではなくIPsecで使う鍵の配布も行えるように拡張をされているのです。このためOMPでの鍵交換は非常にシンプルなものになっています。

統合されたルーティングとセキュリティ
統合されたルーティングとセキュリティ

vEdgeは自分宛に送るパケットの暗号化に使う鍵を自らランダムに生成し、それをvSmartに送ります。すると、vSmartは他のすべてのvEdgeにその鍵を配布してくれます。これだけで鍵を更新することができるわけです。

各vEdgeがやらなければいけないのはランダムな鍵を自ら生成するだけです。これは非常に軽い処理ですので、例えば極端に短い時間(例えば30秒)で鍵更新をするということも可能です。IPsec/IKEのフルメッシュネットワークで30秒で鍵更新をするのはほぼ不可能だと思いますが、Viptelaではそれが可能です。Viptelaのアーキテクチャでは鍵の更新は経路のアップデートとほぼ同程度の処理です。BGPの環境で30秒に一度程度の経路アップデートをさばくのはさほど大変なことではないのはみなさん肌でご理解いただいていると思います。ViptelaのIPecの鍵更新は経路の更新と本質的に同じ処理ですので、BGPと同様のスケーラビリティをIPsecについても実現できる、と考えていただければいいかと思います。

また、鍵はvEdge毎に1つしかないことも注目すべき点です。したがって鍵はpair-wiseにはならず、IKEの時のような鍵の個数をO(n^2)からO(n)に大幅に減らすことができるのでスケーラビリティを確保することができます。

今日の多くのSD-WANソリューションは、IPsecによるオーバーレイネットワークを使ったものが多いです。SD-WANソリューションには通常何かしらのコントローラがありますので、プロビジョニングに関する問題は多くの場合解決されていると考えて良いと思います。しかし、維持しなければいけないステートの問題、特にIPsecの鍵交換のスケーラビリティに関して未解決のものが多いです。ViptelaのSD-WANソリューションのオーバーレイネットワークは、IKEを使わず鍵もpair-wiseに作らないので、他のIPsec/IKEベースのオーバーレイネットワークに比べると遥かにスケールする仕組みになっています。

Viptelaのオーバーレイネットワーク
Viptelaのオーバーレイネットワーク

実際に、ViptelaのSD-WANを使っているお客様の中には3,000拠点のIPsecフルメッシュなネットワークを実現されているされているお客様がおられます。そのお客様の利用事例についてはまた日を改めてご紹介をしたいと思います。

ユースケース:vEdge Cloud仮想アプライアンス

vEdgeルータ 製品ファミリー」の回でご紹介したように、vEdgeには仮想アプライアンス版があり、vEdge Cloudと呼ばれています。現在、Amazon Web Service、VMware ESXi、KVMの3つのプラットフォームに対応するvEdge Cloudが提供されており、今月(2016年12月)中に、Microsoft Azureに対応する仮想アプライアンスもリリースされる予定です。今日はこのvEdge Cloudを利用したユースケースをご紹介します。

vEdge Cloudのユースケース #1- 企業WANをパブリッククラウドに延長

企業とAWSのVPC(Virtual Private Cloud)との接続には、キャリアが提供するDirect Connectを利用するか、インターネット経由で接続しVPNを使うのが一般的です。vEdge CloudをVPCに展開することで、企業はDirect Connectとインターネットを2つのWAN回線として同時にアクティブに使い、VPNを企業のDCや各拠点とセキュアにフルメッシュで接続できます。

vEdge_Cloud_with_AWS

vEdge Cloudでは、ハードウェアで提供されているvEdgeと同じ機能を使うことができます。各拠点からVPCに対して最適なパスで接続できるだけでなく、VPC上のアプリケーションにあわせてDicrect Connectとインターネットを使い分けたり、セグメンテーション機能を使うこともできます。つまり、VPCは企業のWAN環境にシームレスに接続された、企業ネットワークの一部として使われることになります。

vEdge Cloudのユースケース #2 – VNFとしてvCPEでSD-WANを使用

企業が拠点に必要とするネットワーク機能は、SD-WANだけとは限りません。しかしながら、非常に小規模な拠点にまで複数のネットワーク機器を導入すると、コストや機器を置くスペース、運用などが課題となります。このため、ファイアウォールやWAN最適化など、複数のネットワーク機能をVNF(Virtualized Network Function)として1つのx86サーバー上に展開し、拠点にまとめて展開するvCPE(Virtualized Customer Premises Equipment)を使うという選択肢があります。

vEdge_Cloud_as_VNF

vEdge CloudはVMware ESXiやKVM向けにも提供されており、これらのハイパーバイザーをベースとするvCPE上にVNFとして展開できます。VMware vCloud NFVやOpenStackから管理することも可能です。これにより、企業は最適なコストでSD-WANを含む複数のネットワーク機能を拠点に展開することができます。

ユースケース:セグメンテーション

企業の経済活動が多岐にわたる昨今では、機密性の高いデータの保護や、異なる要件を伴うアプリケーションの利用のために、企業内ネットワークであっても用途に応じてネットワークを適切に使い分けることが重要です。キャンパスの中であれば、VLANを使って1つのネットワークインフラを論理的に分離し、部門や用途に応じて簡単に使い分けることができます。しかしながら、WANに関してはVLANのように簡単な手段はありませんでした。

WANにおける従来のネットワーク分離

今日、企業がWANにおいてネットワークを分離して使用する最も現実的な方法は広域イーサネットを利用することです。広域イーサネットを利用することで、キャンパスの中で使用しているVLANをそのままWANを越えて延長できるためです。しかしながら、広域イーサネットは、日本国内であっても接続可能な場所が限られ、海外拠点なども含めた全社レベルでのネットワーク分離には対応できません。また、全社レベルでVLAN IDの割り当てが共通である必要があり、エンドツーエンドでネットワークを適切に分離するソリューションとしては限定的と言わざるをえません。

VRFやBGP/MPLS VPNといったレイヤ3のテクノロジーもあります。しかしながら、これらの技術を利用してネットワーク分離を行うには、キャリアがWANの網内のネットワーク機器に設定を追加する必要があり、要件に応じたネットワークを得るために、企業は追加の費用とリードタイムを要します。

SD-WANによる解決方法 – セグメンテーション機能

ViptelaのSD-WANソリューションによって、このような問題を簡単に解決することができます。「セグメンテーション機能」は、WANをまたいで全社レベルでのエンドツーエンドのネットワーク分離を実現するシンプルで強力なソリューションです。企業のネットワーク管理者は新たなセグメント(VPN)を定義し、各拠点のvEdgeのLAN側の物理インターフェースやVLANを割りあてます。これだけで、あたかも新たなWAN回線を契約したかのように、論理的に分離されたネットワークを使うことができます。

複数のセグメントを使う場合でも、vEdgeはそれぞれにトンネルをはるわけではありません。このため、vEdgeの負荷を気にすることなく、多数のセグメントを使用できます。(ライセンスによってセグメントの上限数が規定されています。)

セグメンテーション機能のユースケース

各セグメントはルーティングドメインとして独立しており、IPアドレスやサブネットの重複は問題になりません。ルーティングプロトコルを個別に動かすことも可能ですし、セグメントごとにフルメッシュやハブ&スポークといったトポロジーを変えることも可能です。このため、セグメンテーション機能は下記のような様々なユースケースに利用できます。

  • 世界各地の拠点ごとにWAN回線の数や組み合わせが異なっていても、全社レベルの標準ポリシーに基づいて、適切にデータやアプリケーションのネットワーク分離を行う(PCI-DSS対応など)
  • 多数のグループ会社や関連会社のWANを統合した上で、論理的にセキュアに分離して使用する
  • 買収した企業のネットワークと物理的には統合しながら、IPアドレス体系などが段階的に整理されるまでは、論理的に隔離されたネットワークとして扱う
  • 個々の機器のアクセスリストに依存することなく、社外の協力会社と直接ネットワークを接続し、必要なデータやアプリケーションを共有する
  • 共通のネットワークインフラ上に、論理的に分離された本番・開発・UATのネットワーク面を作成する

このように、ViptelaのSD-WANソリューションでは、従来は簡単に実現できなかったWANでのネットワーク分離を実現し、管理性を維持しながら企業の経済活動のセキュリティリスクを軽減することができます。

ユースケース:サービスチェイニング

より快適にSaaSやパブリッククラウドを使うためにはローカルExitが有効であるというのは「ユースケース:リージョナル / ローカルExit」の回で説明しました。ローカルExitの場合は拠点を直接インターネットにつなぐことになりますので、セキュリティが心配です。一つの解決策はzScalerのようなCASBを使うことですが、もう一つの方法はViptelaのSD-WANソリューションが持つ「サービスチェイニング機能」(サービスインサーション機能と呼ばれることもあります)を使うことです。

拠点ファイアウォールの問題点

WAN回線がMPLSによるクローズド・ネットワークだけで構成されていた場合は拠点側にファイアウォールを置かない場合もあるかと思いますが、インターネットで接続されている場合はファイアウォールを置いていることが多いと思います。拠点数が少ないうちはそれでも良いでしょうが、拠点数が数百、あるいは数千、という規模になってくると、全ての拠点にファイアウォールを設置するのは機器コスト的にも現実的ではありませんし(CAPEX的側面)、それだけの数のファイアウォールにきちんとしたポリシー設定をして維持管理をしていくのも並大抵のことではありません(OPEX的側面)。

そのような場合に有効なのがViptelaの持つサービスチェイニング機能です。

Viptelaのサービスチェイニング機能

例えばある拠点からユーザがデータセンター側のサーバにアクセスをする際には必ずファイアウォールを経由させたいとします。

Viptelaのサービスチェイニング機能
Viptelaのサービスチェイニング機能

従来は拠点側に置いたファイアウォールにアクセスポリシーを設定していたと思いますが、Viptelaのサービスチェイニング機能を使うと特定トラフィックの経路を変更して、別のvEdgeに送り、そこでさまざまなサービス(ファイアウォール、アンチウィルス、ロードバランサ、など)を経由させることができます。トラフィックの特定にはACLやDPIによるアプリケーション識別が使えます。同等のセキュリティモデルを保ちながら、従来拠点側にあったファイアウォールをリージョナルなデータセンターに集約することができるわけです。ViptelaのSD-WANソリューションを使っているお客様の中には、この機能を使って何千台もあった拠点側ファイアウォールをデータセンター側の数十台のファイアウォールに集約し、大きなコスト削減を実現されているお客様がいます。

このサービスチェイニング機能はViptelaの持つ柔軟なポリシー制御機能によって実現されています。サービスチェイニングの具体的な仕組みや設定例はまた日を改めてお話したいと思います。

ユースケース:リージョナル / ローカルExit

近年、Office365に代表されるようなSaaSサービスが急速に企業に受け入れられ始めています。また、Amazon AWSやMicrosoft Azureなどのパブリッククラウドの利用も一般的になってきました。

これらSaaSやパブリッククラウドは基本的にはインターネットを通じて利用するわけですが、場合によっては快適に利用することができないことがあります。自宅で使うとサクサク動くOffice 365が、オフィスに行くとモッサリした動作になり快適に使えない、というのは最近よく聞く話なのではないかと思います。これは企業ネットワークがSaaSやクラウドに最適化されていないために起こる現象です。

今までのインターネット接続の形態

今日、多くの企業ネットワークはインターネットへの出口(Exit)は本社やデータセンターなど、1箇所にしかありません。各拠点は全て1箇所に集約され、そこからインターネットに抜けて行く形になっています。極端なケースでは、海外の拠点のトラフィックも一度日本に集約してからインターネットに抜けて行く場合もあります。セキュリティ的な管理のしやすさからこのような設計をされることが多いですが、全てのトラフィックが1箇所に集約されるため、そこに設置されているファイアウォールやプロキシーがボトルネックになったり、インターネット回線が輻輳してしまうという問題が起こりがちです。

SD-WANによる解決方法 – リージョナルExit

SD-WAN技術を使うとこのような問題を簡単に解決することができます。

Reginal Internet Exit
リージョナルなインターネットExit

Viptelaはアプリケーションを特定して、特定のアプリケーションだけを別の箇所に送ることができます。通常トラフィックはデータセンターに送りますが、例えば、Office 365のトラフィックであると認識したらデータセンターに送らずに、より地理的に近い(リージョナルな)ところからインターネットに出て行くようにポリシーを設定することが可能です(このようなインターネットへの抜けたかをリージョナルExit、またはリージョナルBreakoutなどと言います)。例えば東日本の拠点は東京のデータセンターから、西日本の拠点は大阪のデータセンターからインターネットに抜けるようにするわけです。このようなポリシーはvSmartコントローラからの一括で設定されるので、拠点が多数あっても設定はとても簡単です。

SD-WANによる解決方法 –ローカルExitとCASBとの連携

さらに拠点がインターネットの接続を持っているのであれば、リージョナルなデータセンターではなく、直接拠点からインターネットに抜けるようにすることも可能です(ローカルExitまたはBreakout)。リージョナルなデータセンターにはファイアウォールが設置されている場合が一般的かと思いますが、ローカルExitをする場合には全ての拠点にファイアウォールが設置されていない場合もあるかと思います。ファイアウォールのない拠点から直接インターネットに繋ぐのはセキュリティ的に心配だ、という懸念もるでしょう。そのような場合には、最近注目を集めるようになってきたCASB (Cloud Access Security Broker)サービスを利用すると方法が考えられます。ViptelaのvEdgeはCASBサービスとして広く利用されているzScalerと連携をすることができるようになっていますので、ローカルExitをするトラフィックをzScalerに廻してセキュリティを担保することが可能です。

Local Internet Exit
ローカルなインターネットExitとCASB

このように特定のアプリケーションのトラフィックをリージョナルなデータセンターからExitさせたり、拠点から直接Exitさせることにより、SaaSアプリケーションやパブリッククラウドをより快適に使うことができるようにできるのもSD-WANの大きなメリットの一つです

ユースケース:アプリケーション対応ルーティング

今日からViptelaSD-WANソリューションのユースケースについて具体的にご紹介していきます。

SD-WANを導入した企業、もしくは、導入を検討する企業の非常に多くは、WAN回線をよりコスト効率よく使いながら、企業内のエンドユーザのアプリケーションの使用感も改善したいと考えています。今日ご紹介するユースケースは、この期待を実現するSD-WANの使い方で、アプリケーション対応ルーティング(英語名:Application Aware Routing)と呼ばれています。

日本の多くの企業では、WAN回線としてIP-VPNや広域イーサネットなどのサービスを2回線契約し、一方をメイン、もう一方をバックアップとして使い分けているケースが一般的です。また、拠点からのインターネット向けのトラフィックはWAN回線を経由してデータセンターに集め、データセンターのプロキシサーバやファイアウォール等を通ってインターネットに出ていく構成がよくみられます。昨今、SaaSが普及し、各拠点からOffice365Salesforceなどへのアクセスが増加したことなどから、WAN回線の帯域幅の枯渇や輻輳が発生し、エンドユーザのアプリケーション使用感を損ねているケースも少なからずあるようです。

123日の記事にあるように、各拠点のvEdge間はIPsecトンネルでつながり、フルメッシュのオーバーレイネットワークが構成されます。vEdge間のオーバーレイは全て1ホップですので、デフォルトではECMPによってすべてのWAN回線がアクティブに使われます。2つのWAN回線をメインとバックアップで使い分けていた企業にとっては、アクティブ・アクティブでWAN回線を使うことで実際に使えるWAN回線の帯域幅が増えたことになります。しかしながら、単純なECMPではエンドユーザの使用感が改善するとは限りません。アプリケーションによって、必要となる回線品質が異なる上、WAN回線によって提供される性能も異なるためす。そこで、使われるのがアプリケーション対応ルーティングと呼ばれるポリシーです。

SD-WANによる解決方法 – アプリケーション対応ルーティング

アプリケーション対応ルーティングでは、ユーザは使用するアプリケーションに対して必要な性能要件を定義します。性能要件には、遅延、ジッター(遅延の揺らぎ)、パケットロス率の3つの指標が使われます。例えば、voiceのトラフィックは遅延が20ms、ジッターが10ms、パケットロス率1%を下まわる回線品質が必要というポリシーを定義すると、vEdge間でvoiceのトラフィックを転送する際に、指定された回線品質を満たすWAN回線のみが使用されます。複数のWAN回線が指定された回線品質を満たす場合、それらのWAN回線を同時に使うことも、優先的に使用するWAN回線を指定しておくこともできます。

アプリケーション対応ルーティングアプリケーション対応ルーティングで指定可能なアプリケーションは、vEdgeがもつDeep Packet Inspection (DPI)エンジンによって識別されるアプリケーションです。現在、vEdgeのDPIエンジンは約3000種類のアプリケーションやWebサイトを識別します。ユーザは、RTP (Realtime Transport Protocol) やLine、Skypeといった個別のアプリケーションを指定してポリシーを定義することも、Audio&VideoやInstant Messagingといった同種のアプリケーションをグループ化したアプリケーションファミリーを指定して定義することも可能です。企業で使用されるアプリケーションは多岐にわたるため、特別重要なもの以外はアプリケーションファミリーでポリシーを定義すると簡便です。

vEdgeは自分が保持する全てのIPsecトンネルに対して、デフォルトでは1秒ごとにBFD (Bidirectional Forwarding Detection) パケットを送出し、遅延、ジッター、パケットロス率を計測しつづけています。アプリケーション対応ルーティングは、WAN回線がアプリケーション要件を充たしているかどうかをこの値に基づいて判断します。

以上のように、ViptelaのSD-WANソリューションによって、企業は複数のWAN回線を全てアクティブに使うだけでなく、アプリケーションの要件に合わせて適切なWAN回線を割り当て、エンドユーザのアプリケーションの使用感を向上することができます。