Viptelaユーザー事例:First America

First Americaは米国カリフォルニア州に本社をおき、100年以上の歴史をもつ金融業界の会社です。日本では馴染みが薄いですが、中古住宅の個人売買などがさかんな米国では、売買時に売主が本当にその物件に権利を有していることを調査し保証するTitle Insuranceが使われることが一般的です。First Americaはこの分野の米国最大手で、今では様々なサービスを世界30カ国以上で展開しています。

WANの課題

First AmericaWANは2002年に設計されてから最近まで、データセンターや大規模拠点ではMPLSを2回線、小規模拠点ではMPLSを1回線利用するというシンプルなものでした。しかしながら、コンテンツリッチなアプリケーションやマルチメディアトラフィック、さらには、SaaS利用の拡大により、慢性的な帯域幅の枯渇が大きな問題となってきました。くわえて、顧客の期待する業務の迅速性がますなか、MPLSを1回線しか契約していない拠点で、ネットワークや電話のダウンタイムも問題になってきました。このような課題を、従来のアーキテクチャのまま解消しようと考えた場合にかかるコストは、受け入れがたいものでした。

Viptela SD-WANの検討

そこで、First Americaは、2013年から次世代WANのアーキテクチャを決める作業を開始しました。その中で、新しい技術であるSD-WANも主要な選択肢として検討され、詳細な検証をふまえて、最終的にViptelaのSD-WANソリューションが採用されました。

検討の際にFirst Ameicaが特に重視したSD-WAN機能は以下でした。

  • MPLS回線とインターネット回線をアクティブアクティブで使用し、障害時には相互にフェイルオーバーできること
  • 回線の種類を問わず必要な機能が全て利用できること
  • 音声はフルメッシュ、それ以外のトラフィックはハブアンドスポークのトポロジーを構築できること
  • アプリケーションや組織の単位でWANを論理的に分割できること
  • ネットワーク遅延やダウンタイムを可視化し、それによってトラフィックのパス制御ができること
  • ゼロタッチプロビジョニングや、リモートでのソフトウェアバージョンアップが想定の環境で適切に使えること

また、First Americaは、SD-WAN機能だけでなく、ネットワーク機器として既存の環境にシームレスに導入できるかどうかについても詳細に検討を行いました。Viptelaはルータ機器としても下記のような必要な要件を満たすことができました。

  • MPLS回線とのeBGP接続が従来通りできること
  • データセンター内の既存ルーターとのiBGP接続が従来通りできること
  • 音声を中心とするQoSとポリシー制御が適切に動作すること
  • 従来使用していたCisco ISRで利用している機能 (NAT, QoS, ACLなど) を移行できること

SD-WAN導入効果

First Americaは、ViptelaのSD-WANソリューションを導入することで、コストを抑えながら帯域幅と可用性の問題を解消し、企業内のユーザエクスペリエンスを大きく向上することができたと言います。また、WAN全体の回線やアプリケーション使用状況の可視化や、テンプレートによる機器設定の一元管理も、ネットワーク管理の観点で非常に大きなメリットがありました。

Viptela vAnalyticsでキャリアごとのネットワーク遅延などを確認

First Americaの導入事例については、Viptela社のサイト(英語)でもご覧いただけます。

日本でのViptela SD-WAN本番環境導入事例

日々SD-WANのご紹介をしている中で、最も多くいただくご質問のひとつが本番環境での導入実績です。2017年7月時点で、米国のFortune 500のうちの40社に導入されるなど、ViptelaのSD-WANソリューションは海外企業の本番導入実績が豊富にあります。また、日本の企業様でも2017年に入ってから本番商用環境での導入が急速に伸びています。

まだ数は多くありませんが、ViptelaのSD-WANソリューションの導入についてWeb上で確認できる情報をご紹介したいと思います。

まずは、ITproに掲載されている、日本の大手製造業企業様がViptelaのSD-WANソリューションを100拠点で国内展開されたという記事です。現時点で、国内企業でのSD-WANの最大規模の導入事例だと考えています。

リンク – ITpro『本邦初の大規模SD-WANユーザーがついに登場?』

続いて、東京大学 情報基盤センター様です。弊社パートナーの日商エレクトロニクスさんがユーザ事例として詳細を公開されていらっしゃいます。

リンク – 東京大学情報基盤センター様ケーススタディ

Interop Tokyo 2017の基調講演では、同センターの関谷勇司先生にご登壇いただき、学内でのViptelaの導入事例を具体的にご紹介いただきました。

弊社の進藤が国内外の本番導入事例をまとめたスライドも下記からご覧いただけます。上記2件以外の国内企業様の事例も記載しています。

リンク – Slideshare『Viptela 導入事例』

国内での本番環境での導入は、当初、製造業のお客様が比較的多い印象でしたが、最近では商社や金融機関での導入も増えつつあります。今後、様々な事例をご紹介できるようになっていくのではと期待しています。

Azure MarketplaceにViptela vEdge Cloud Routerが掲載されました

20177月に、vEdgeルータの仮想アプライアンス版であるvEdge Cloudが、Azure Marketplaceに掲載されました。これにより、Azure、AWSESXiHyper-VKVMでvEdge Cloudをお使いいただけることになりました。

AzureでのvEdge Cloudの展開はたったの数ステップです。初期設定を完了するだけで、AzureAWS、オンプレのデータセンター、国内外の拠点をフルメッシュでセキュアに相互接続し、SD-WANの機能が使えるようになります。

AzureにてViptela vEdgeを検索し展開

なお、先日、Cloud onRampというクラウド対応機能を発表しました。これは今までCloud Expressと呼ばれていたSaaS向け機能と、近日中にリリース予定のIaaS向け新機能をまとめて呼称したものです。6月に開催されたInterop Tokyo 2017でのプレゼンテーションで、後者のCloud onRamp for IaaSのモックアップをご紹介しましたが、非常に大きな反響をいただきました。実際に機能がリリースされれば、こちらのblogでもご紹介したいと思います。

DHCPが使えない環境でのゼロタッチプロビジョニング

16.3までのゼロタッチプロビジョニングの前提条件

Viptelaが提供するゼロタッチプロビジョニングは、電源ケーブルとLANケーブルを挿すだけで作業が完了する、完了なゼロタッチプロビジョニングです。現場でラップトップを内蔵Wifiに接続してeメールでのアクティベーション作業を実施したり、機器それぞれに異なるUSBメモリを事前配布したりといったミスにつながりかねない作業を必要としません。

しかしながら、従来のゼロタッチプロビジョニングは、DHCPもしくはLTEのデフォルトプロファイルに依存して動作していました。つまり、DHCPIPアドレスとDNSサーバが取得できるか、LTE対応のvEdge-100mデフォルトプロファイル(現在日本では、OCN Mobile Oneのlte-d.ocn.ne.jpのAPNに接続するmobileid@ocnアカウント)に対応するSIMを挿している場合にのみゼロタッチプロビジョニングが可能でした。

17.1で新たに静的IPでの閉域網への接続などもサポート

2017年4月にリリースされた17.1.0では、ゼロタッチプロビジョニングに大きな機能追加がありました。これにより、DHCPではIPアドレスやDNSサーバが取得できない環境でも、環境に合わせてネットワークの接続性を確保し、ゼロタッチプロビジョニングを行うようになります。特に、MPLSなどの閉域網につながり、本来はIPアドレスとBGPを静的に設定する必要がある環境でも、ゼロタッチプロビジョニングによる自動設定が可能となります。

具体的な動作の説明は割愛させていただきますが、ご興味をお持ちいただいた方は、是非ask@sd-wan.jpまでお問い合わせください。

なお、17.1においても、PPPoEを必要とする回線のみの環境では完全なゼロタッチプロビジョニングは実現できません。しかしながら、閉域網との回線二重化が行われている拠点や、LTEも利用する拠点では、それらの回線を使ってゼロタッチプロビジョニングすることで、PPPoEの設定もvEdgeにプッシュされます。このため、日本においてもゼロタッチプロビジョニングを使った展開がかなり現実的になったのではないかと期待しています。

PPPoEを必要とする回線のみの環境では、事前にPPPoE用の最低限の設定を投入する事で、それ以降のプロセスはゼロタッチプロビジョニングを使用することができます。正式名称ではありませんが、ワンタッチプロビジョニングなどと呼んでいます。

今日のWANが抱える問題点

一般的に異なる地点間を結ぶネットワークはWide Area Network(WAN)と呼ばれます。例えば企業の拠点間や学校のキャンパス間を結ぶネットワークはWANということになります。当初WANは専用線やフレームリレーで構築されるのが一般的でしたが、それらは徐々にMPLS VPNや広域イーサーネットサービスなどに置き換えれらていきました。

従来のWANが抱える課題

当初はさほど大きな問題はなかったWANですが、ネットワークがビジネス上不可欠なツールとなり、拠点数が数千〜数万になることも珍しくなくなってくると、拠点開設にかかる時間がビジネスが求める俊敏性に応えられなくなってきました。また、世の中のグローバル化に伴い、拠点は国内だけはなく海外にも展開されるようになり、回線費用や回線品質などが問題になってきました。広帯域を必要とするアプリケーション(ビデオなど)を使うニーズも増えてきましたが、狭帯域な従来のWANでそれを実行するのは非現実的でした。

クラウドとSaaSがネットワークを変える?

そこに追い打ちをかけたがのが近年のパブリッククラウドやSaaSの台頭です。これらのサービスは全てインターネット上にあるわけですが、WANからインターネットへ抜ける道は通常データセンタなど一箇所に限られることが多いため、パブリッククラウドやSaaS向きのトラフィックでデータセンタのインターネット回線が輻輳してしまったり、プロキシーの性能が足らずアプリケーションが思ったように動作しない、などといった問題が顕在化してきました。Office 365の使用は爆発的に伸びています。今後もこのようなクラウドベースのアプリケーションがどんどんと出てくると考えられます。

SD-WANはクラウド時代のWAN

これらの課題を解決するために生まれてきたのがSD-WAN(Softwre Defined WAN)という技術です。回線コストの削減と広帯域化を図るために、従来のMPLS回線に加えインターネットを活用します。ただし、信頼性保証のないインターネットだけでは今日のビジネス要件に応えることはできないので、複数ある回線の品質をモニターしながらSLAを満たす回線のみを使えるような機能が提供されています。また、ゼロタッチプロビジョニングと呼ばれる機能を持ち、簡単に拠点のネットワークを立ち上げることができます。特定のアプリケーションのトラフィックだけ拠点から直接インターネットに抜けるようにして、高価なMPLS回線の使用を抑え、クラウドやSaaSアプリケーションに最適化されたネットワークを提供することができるので、まさに「クラウド時代のWAN」ということができるでしょう。

本Blogでは、SD-WAN分野リーディングカンパニーで、SD-WANの市場を牽引してきたViptelaのソリューションに関する情報を提供していきたいと思います。

Viptelaユーザー事例:ACADIA Healthcare

ACADIA Healthcare(以下ACADIA)は行動問題医療を専門とする医療機関で、2016年にFortuneで「最も早いスピードで成長している企業100」にも選出されています。米国、英国、プエルトリコなどに600近い施設と約17,000の病床を持ち、この分野では最大級の医療機関です。

彼らが直面していた問題は、従来使っていたWAN回線はかなり信頼性が低く(特に地方拠点)たびたびダウンタイムが発生していたことでした。サーバがオンプレミス側にあるうちはWANに障害があっても業務に大きな支障は発生しませんでしたが、近年業務アプリケーションがクラウド化さるようになってくるに伴い、WANの障害によって業務に大きな支障が生じるようになってきました。特に音声アプリケーションがクラウド化され、WANの障害で電話による受付業務が止まってしまい、ビジネスの機会損失になってしまうのが大きな悩みでした。

ACADIAは、このような問題にはSD-WANが有効であると考え、SD-WANの検討を始めました。3ヶ月ほどSD-WAN製品選定を行い、最終的にはViptelaを選択しました。Viptelaを選択した理由は、最もネットワーク機能がしっかりしており「ネットワーク屋が作ったネットワーク製品」と感じられた、というのも大きかったようです。

まずは10拠点ほどでPOCを行い、その結果も良好だったのでその後展開を進め、2016年秋の時点で50箇所ほどデプロイを完了、最終的には100拠点ほどにViptelaを展開する予定だそうです。従来はMPLS回線を使っていましたが、そこにブロードバンド回線とLTEを加え、非常に可用性の高いネットワークにすると共に、Application Aware Routing機能を使って、医療用アプリケーションに対してSLAを保証するようにしているのも特徴的な使い方と言えるでしょう。

将来的にはセグメンテーションの機能を活用したり、より積極的にクラウド化を進めて行くことを考えているとのことです。

ACADIAの方が2016年秋のONUGでプレゼンテーションをしていますので、興味がある方はこちらのビデオをご覧ください。

Interop Tokyo 2017でお待ちしています!

INTEROP6月7日(水)から幕張で開催されるInterop Tokyo 2017にて、弊社のパートナー様にViptelaソリューションを展示いただきます。ヴィプテラ・ジャパンの社員も、各社様のブースでお待ちしています。

  • NTTPCコミュニケーションズ様 (SDIショーケース)
  • 日商エレクトロニクス様
  • マクニカネットワークス様
  • 丸紅OKIネットソリューションズ様 (SDIショーケース)
  • ユニアデックス様
    (五十音順)

また、Interop Conferenceの下記セッションに弊社社員が登壇します。是非ご参加ください!

vManageテンプレート機能による設定管理

vManageが提供する機能の1つに「テンプレート機能」があります。ViptelaのSD-WANソリューションではvEdgeやコントローラー(vManage/vSmart/vBond)に直接ログインして設定を行うこともできますが、vManageのテンプレート機能で全てのデバイスの設定を一元管理することもできます。各デバイスの固有の値(ホスト名、IPアドレスなど)をパラメーター化(変数化)できるため、複数のデバイスの設定を共通のテンプレートで管理できます。これにより、設定ミスや設定漏れを排除し、短時間で新しいデバイスを展開できます。

テンプレートの作り方

テンプレートは2つの方法で作成することができます。CLI TemplateとFeature Templateです。CLI Templateは、各デバイスに直接ログインした場合に使われるCLIでの設定をテンプレート化したものです。

CLI Templateとパラメータ化
CLI Templateの作成画面とパラメータ化

テンプレートの中に{{variable}}のように{{と}}で囲んで任意の文字列を記述すると、その部分は機器ごとに固有の値が入る変数として扱われます。

CLI TemplateはCLIそのものですのですし、シンプルな内容であれば慣れた方には全体をざっと見渡しやすいという特徴があります。このため、すでにCLIで設定を行い運用を始めたあとでテンプレート化を行う場合や、非常にシンプルな環境で運用管理を行う場合に適しています。

もう1つの作り方であるFeature Templateは、vManageのGUIを使って作るテンプレートです。

Feature Templateの設定画面
Feature Templateの作成画面

Feature TemplateではGUIに沿って必要な設定を選択していくだけで全体の設定を作り上げることができます。また、CLI Templateと同様に、機器固有の値についてはパラメータ化(変数化)が可能です。さらに、Feature Templateは設定の内容ごとにブロック化され、複数のテンプレートから利用できるようになっていてます。構成の異なる複数のテンプレートを用意する場合でも、共通の内容の設定箇所は1つのFeature Templateを使い回すことで管理性を高めることができます。このため、多数のテンプレートの管理が必要となる環境ではFeature Templateがお勧めです。

テンプレートの適用とvManage Mode

作成したテンプレートを各デバイスに適用する手順は主に下記の3ステップです。

  1. テンプレートにデバイスを割り当てる
  2. パラメーター化(変数化)されている固有の値を入力する
  3. 最終的な設定内容を確認する

固有の値(変数/Variable)の入力はvManageのGUI画面からも可能ですが、デバイスが複数の場合にはCSVファイルでまとめてインポートもでき、便利です。

デバイス固有の変数を入力 (CSVファイルで代替可能)
vManageでデバイス固有の値を入力 (CSVファイルで代替可能)

CLI TemplateとFeature Templateのいずれの作り方で作成したテンプレートも、各デバイスに適用を行う際に自動的にCLIに変換されます。適用前に現在の設定との差分を確認することもできます。

Config Diff
テンプレートの適用の際の設定と差分の確認

各デバイスはvManageから適用された設定を自分自身で保持しますので、再起動時にvManageと接続できない場合に設定が失われるというようなことはありません。

テンプレートを使ってvManageから設定を適用されたデバイスはvManage Modeに設定されます。vManage Modeにあるデバイスには、直接ログインしても設定を変更することができません。vManageで設定を確実に一元管理できるようになっています。各デバイスで設定変更を行いたい場合には、vManageにてデバイスをテンプレートから切り離します。このモードをCLI Modeと呼びます。

ゼロタッチプロビジョニングとテンプレート

ゼロタッチプロビジョニングはViptelaのSD-WANソリューションの大きなメリットです。工場出荷時設定のvEdgeにゼロタッチで設定を適用するためには、あらかじめそのvEdgeをテンプレートに割り当て、固有の値(変数)を指定しておきます。vManageに未登録のvEdgeの識別には、シリアル番号が使用されます。シリアル番号はサポートポータルで確認できるほか、vEdgeの入っている外箱にも記載されています。これにより、ゼロタッチプロビジョニングで展開されたvEdgeに、適切な設定が適用され、vManage Modeで安全に運用できます。

SD-WANでマルチキャスト

ViptelaのSD-WANに特徴的な機能の一つにマルチキャストのサポートがあります。アンダーレイネットワーク側にマルチキャストのサポートは必要ありません。オーバーレイネットワーク側でマルチキャストネットワークを作ることができます。以下、Viptelaのマルチキャスト機能について見てみましょう。

スケーラブルなマルチキャスト

ViptelaのSD-WANはPIM-SMをサポートしています。マルチキャストの送信者側、受信者側共に特別な要件はなく、普通にマルチキャストをする場合となんら変わりません。一方、オーバーレイ側では少々工夫がされています。

Multicast Support by Viptela
オーバーレイでマルチキャストをサポート

サービス(LAN)側から来るIGMPまたはPIMのjoinは、OMPプロトコルを使ってvSmartコントローラに送られるようになっています。

また、パケットのレプリケーションは上流のルータ(マルチキャストのソースを持つvEdge)が行うのではなく、「レプリケータ」と呼ばれる別のvEdgeルータが行うようになっています。通常、データセンタ側に置かれるvEdgeをレプリケータに設定します(性能や帯域に余裕があることが多いため)。このようにレプリケータを設けることで、拠点側のvEdgeの処理負荷軽減や帯域の削減が可能になります。レプリケータは複数設定することができ、マルチキャストのグループアドレス、ソースのvEdgeなどによって分散するようになっており、その際に各はレプリケータの負荷も考慮してレプリケータへの振り分けが行われるようになっています。このようにレプリケータを設けることで、単純にソースのvEdgeでレプリケーションするよりもスケールするマルチキャストネットワークを構築することができます。

セキュアなマルチキャストオーバーレイ

マルチキャストのトラフィックもユニキャストの時と同様に全てIPsecで暗号化されて送られます。「SD-WANのスケーラビリティ」で述べたように、vEdgeは自分宛に送るパケットを暗号化する際に使って欲しい暗号化鍵を自分で生成し、vSmartでそれを配布するようになっています。しかし、マルチキャストでこれをやろうとすると、レプリケータは送信先のvEdgeの数だけIPsecの暗号化処理をしなければなりません。暗号化処理はハードウェアで行われるとはいうものの、下流にvEdgeが100台あったら100回別々の鍵で暗号化をしなければいけませんのでかなり大変です。そこで、マルチキャストトラフィックを暗号化する際は、送信先のvEdgeが生成した鍵ではなく、送信元が生成した鍵を使うようになっています。このようにすればレプリケータは下流のvEdgeの数だけ別々に暗号化する必要は無くなります。レプリケータからパケットを受け取ったvEdgeは送信元のvEdgeが生成した鍵を使って復号化を行えば良いわけです。

ViptelaのSD-WANでは、上記のようなさまざま工夫によってスケールするマルチキャストネットワークを構築することができるようになっています。Viptelaユーザの中には、実際にこのマルチキャスト機能を使ってWAN上でビデオ配信を行なっているお客様がおられます。

vEdgeのQoS機能

どのようなSD-WANソリューションであっても、通常拠点側(エッジ)に設置する機器(CPE; Customer Premise Equipment)があります。Viptelaソリューションの場合はvEdgeがCPEになります。基本的にこれらのCPEは「ルータ」ですので、ルータとしての基本機能を備えている必要があります。ルーティングプロトコルサポートの重要性については「SD-WANへのスムースなマイグレーション」で述べましたが、QoS(Quality of Service)機能もSD-WANのCPEがサポートしていなければならない基本的機能要件の一つです。アプリケーションの重要度によってWANの回線を使い分ける、というのが最も典型的なSD-WANのユースケースだと思いますが、そもそも重要度の高いアプケーションのQoSを担保できなかったら回線を使い分けてもあまり意味がないでしょう。

一口に「QoSサポート」といっても非常に幅広いので、SD-WANソリューションを選択する際には具体的にどのようなQoS機能をサポートしているのかを注意深く見極める必要があります。vEdgeが持つQoS機能は以下のようなものがあります。

  • キューイング
  • シェーピング
  • ポリシング
  • リマーキング

キューイング

パケットの分類(Classification)はACL(src/dst IPアドレス or プレフィックス、src/dstポート番号、DSCP、パケット長、TCPフラグ、PLP (Packet Loss Priority) を使用できます。またDPIによるアプリケーション分類を使うこともできます。

vEdgeはEgressインターフェース毎に8個のキュー(Q0〜Q7)を持っています。このうちQ0はLLQ(Low Latency Queue)です。LLQは他のキューよりも高い優先度を持つものの、指定された以上の割合でスケジュールされることはありません。これにより単純なPQ(Priority Queueing)時に見られるような他のキューの飢餓状態(Starvation)が起こりません。したがって、音声などのトラフィックに向いています。残りのQ1〜Q7は通常のWRR(Weighted Round Robin)なキューです。

Queueing
キューイング処理

また、キューが輻輳した際の挙動についてはテールドロップをするかRED(Random Early Detection)をするかを指定できます。REDはキューへのたまり具合に応じて(たとえキューが満杯になっていなくても)パケットを確率的に落とす方法です。REDを使うことによりテールドロップ時に見られる「TCPのグローバル同期問題」を避けることができます。

シェーピング

シェーピングは単純にEgressのインターフェースに上限のレート(Kbps)を設定します。指定したレートを超えるパケットはキューイングされます。

ポリーシング

いわゆるシングルレート、2カラーなポリサーです。レート(bps)とバーストサイズ(bytes)を設定します。

ポリサーはIngress、Egressのインターフェースのどちらにでも設定することができます。また、ACLを使ってパケットに対して選択的にポリーシングをかけることもできます。

Policiing
ポリーシング処理

なお、指定したポリサーに違反するトラフィックに対するアクションとして “drop” もしくは “remark” を指定することができます。remarkを指定すると違反パケットはドロップはされませんが、PLPが “high” であるとマークされ、それを元にキューイングをしたりDSCPのリマーキングをすることができます。

リマーキング

ACLやDPIで特定されたトラフィックによって指定されるトラフィッククラスとPLP毎に、書き換えるDSCPの値を指定することができます。このリライトルールはインターフェースに対して適用されます。