VMware SD-WAN by Velocloudのまとめ

はじめに

この記事は、自社事例がVMwareさんの事例になったことによる記念の投稿です。
VMware SD-WANを導入を検討されている方々に、少しでも情報提供ができればと考えています。

この記事は基本文字ばっかです。（いつもやんって言われそうだけど・・・）

この記事は、エンジニアさん向けのナレッジ提供を目的としています。
内容は、細心の注意をはらって作成しておりますが、誤っている場合もございます。
ご了承ください。

なぜSD-WANが必要になったか？

一言でいえば、データセンタ以外のリソース（SaaS）を業務で使うことが増えたからです。
日本の多くの企業は、Closed（IP-VPNとかMPLSなどの閉域網）のネットワークで構成し、データセンタに
リソースを集約し、Proxy＋Firewallでインターネットに安全にアクセスさせていました。
10年以上前だと、メールサーバも自社保有が多かったので、インターネットはブラウズのみです。

それが、ここ10年でSaaSありきの業務スタイルに急速に変わってしまいました。
加えてコロナ禍でオフィスに出社せずに業務を動かす必要が出たわけです。
閉じられた環境のPCに外部からアクセスせるため、SplashtopやTeamViewerなどの画面転送型の
アプリケーションも急速に普及しました。そしてコミュニケーションのためのTeamsとかZoomなど
会議トラフィックも急激に増えました。画面転送のトラフィックはPC数台ではたいしたことありませんが、
数千台となると、話が変わってきます。

一般的な家庭用の回線に比べると、データセンタで利用されるインターネットの回線は信頼性も高いですが
価格も高く、簡単に束ねることもできません。1Gbpsの上は10Gbpsまで様々な帯域が提供されますが、機器側は
10Gで受ける必要があるため、値段も非常に高額となります。また1箇所最適化して改善される世界でも
なかったりします。
（回線増やして、Proxy増やして、LoacBalancer拡張して、WAN回線増やして・・・と堂々巡りします）

SD-WANは逆の発想です。データセンタに集約してトラフィックを出さずにそれぞれのオフィスやブランチから
から直接SaaSにアクセスさせましょうと。実際の導入はそんなに簡単な話ではありませんが、SD-WANを導入すること
によって実現できるのは間違いありません。

エンジニアにどんなスキルが必要か？

あったほうが良いスキルセット書いておきます。

• SD-WANもクラウドと接続するところはBGPが必須です。なので簡単なBGPは分かったほうがよいです。
  AS-PathやMED値、Filterのかけ方などのスキルはあったほうがいいかも。
• 既存のネットワークを手を入れる前提です。物理のネットワークスキルセットは必要です。L3SW、L2SW、LACP、RSTP
  MSTPとか。または既存のネットワークがちゃんとわかっているエンジニアさんがいえば大丈夫。
• SD-WAN自体はManagedに近いですがFirewallの機能もあるので。簡単なBOX型のFirewallとか作れるぐらいのほうが良いです。
• 英語のドキュメントを読む力・・・。
  あったほうが幸せだと思います。VMwareさんのサイトなにげに英語ページにのみ情報がある時があります・・・。
• インターネットアクセスに必要なDNS回りやポートの情報とか持っていたほうがよいです。
  SD-WANは何気にDNSの設計が難しいです。（実は苦労ポイントでした）非機能要件の検討が多いので気を付けましょう。

SD-WANは何ができるか？

簡単にまとめます。

1. オーケストレータ（Orchestrator)で全体の管理ができる。
   まず、CLIで機器に入ることはありません。（できません）
   管理コンソールはクラウド上で動くSaaSであり、そこにログインして設定する形になります。
2. 簡単に設定ができる。（ゼロタッチプロビジョニング）
   現地に設定する機器はEdgeと呼ばれる大きめの弁当箱の機器です。DC用はラックマウントです。
   初期設定は、インターネットに接続してActivation Keyと登録するOrchestratorのURLを入れるだけです。
   数分で利用可能となります。設定する人は、オーケストレータで設定を作っておけばOK。
   エントリーモデルは、WIFIを内蔵しているのでスマホで設定ができます。
3. マウスでプチプチ設定するだけでSaaSの開け閉めが可能。
   操作はすべてOrchestrator上で行います。ファームのバージョンアップも含めてです。
   個別設定と共通設定（プロファイル）という概念があり、全社的な設定などはプロファイルでコントロールします。
   SSHでCLIにログインして、遠隔で設定入れて、ミスって文鎮化なんてこともありません（笑）
4. Internet-VPNでクラウドとも接続が可能。
   クラウドと接続するのはInternet-VPNです。VeloCloudの場合はEdgeから接続する方法とGatewayから接続する方法と2種類あります。
   Edgeから接続する場合は固定IPも必要。クラウドとフルメッシュになるため大量の拠点から接続する場合はGatewayが便利です。
5. SWGやSASEへ発展が可能。
   Edgeはルータベースの機器です。高度なフィルタリングやSSLのヘッダ書換などはSASEやSWGで実施する必要があります。
   実際にはSWGというかSASEもつなげているので、もう少し複雑な構成だったりします。

なぜVeloCloudが優れているか？

SD-WANと呼ばれるソリューションは、基本的に同じような事ができますが、
Cloud Gateway(VCG)と呼ばれるクラウド上で稼働するGatewayが利用できるからです。
そしてEdgeからCloud Gatewayの間の回線をDMPOと呼ばれるプロトコルで複数束ねることで大量のトラフィックを安価な回線を使って束ねて利用することが可能となります。

たとえばですが・・・。

• すごく高信頼で低遅延だけど高額なそれほど帯域のない回線（主に会議トラフィック用）
• 上より少し共用型で遅延も多少あるけど、ベストエフォートの帯域のある回線（普通のSaaS用）
• 家庭用＋αの非常に安価なベストエフォートの帯域のある回線（Windows Update用）
  Cloud Gateway経由は3つのすべての回線を組み合わせて束ねて利用します。トラフィック毎に自動的に最適に利用されます。
  ユーザが個別に設定をいれることで回線用途を分離することも可能です。（括弧で書いているのが一例です）
  
  音声はもっとも品質を重視するため、IPv6側を通してGateway経由で抜けさせることで効率化させます。
  

インターネットの回線は常に安価で高品質なサービスがリリースされていくため、その時期や提供エリアに併せて
回線を組み合わせることが可能です。積極的に見直すことができることが最大限のメリットだと思います。

Cloud Gatewayがある場合のCloudへの接続イメージ

回線を2本活用できるため、赤と青の線でCloud Gatewayに接続し、そこからCloud（CSP）に接続できているイメージが着くかと思います。
ちなみに、VeloCloudに固定IPは不要です。（EdgeのWAN IPで接続元を縛るなら必要です）

なお、Velocloudの用語では、NVS（Non VeloCloud Site）と呼ばれます。
ここではCSP（Cloud Service Provider）としていますが、VeloCloud視点ではNVSという表現になります。

Cloud Gatewayを利用せずにEdgeからCloud接続のイメージ

Edgeに接続された1本目の回線からCSPに接続しているため、Edgeから全拠点接続しているイメージが分かると思います。
IPSecの接続は、Hub&SpokeかFullMeshとなりますが、CSPの場合はFullMeshが一般的です。（通信効率が悪くなるので）
数拠点であれば、問題ありませんが、数百拠点で実装するのは現実的な構成とは言えないかと思います。
（構築が大変だしCSP側のVPNの本数だけコストが増える）

Cloud Gateway利用時の注意点

1. Cloud Gatewayにはエリア概念がある
   これは、IPSecの区間をなるべく短くするというVeloCloudのサービス思想のようです。
   接続するGatewayは、接続先（CSP）のエンドポイントのIPアドレスで選定されます。
   たとえば、東日本のAWSであれば、東日本のGatewayが自動的に選択されますが・・。AWSの場合は接続先のアドレス（カスタマゲートウェイ）を先に入力しなければ、エンドポイントが選定されません。つまりVelo側もAWS側もアドレスが分からない状態からスタートする形となります。こちらの対策ですが、AWSのアドレスレンジで東京と強制的に認識させることでゲートウェイを選択して対応することで解決が可能です。または、AWSのアドレスレンジで強制的に東京リージョンなどを固定する方法も有効です。
   https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
   ちなみに、VCGは冗長構成を取るためにBGPが必須となります。Staticでも組めないことはないですが、
   Gatewayのメンテナンス（バージョンアップ）やトラブルによる停止などは考慮しなければなりません。
   

2. Non Velocloud Site間は通信がサポートされません。
   NVSとVelocloud GatewayはあくまでEdgeと接続するために存在します。
   そのため、NVS同士がVelocloud Gatewayを挟んで通信することは非サポートとなります。
   
   この場合、CSP-CとCSP-Aは通信がサポートされません。なぜサポートされないという表記にしているかというと、
   西日本側のVCGのバックアップが東日本が選定された場合は実は通信ができてしまうからです。
   内部の構造は非公開ですが、おそらくエリア内のVCGは経路交換がされていると推察されます。
   CSP-AとCSP-CがAWS同士などの場合は、VPC Peerなどでカバーすれば問題はありませんが、CSP-AとCSP-Cが別のクラウドの場合は注意が必要となります。

入れた後のオチ

• ネットワークは蛇口をひねった水みたいなものなので、ユーザーからはあんまり感謝されません（涙）
• 減ったトラフィック分だけほかのトラフィックが増えます。マーフィーの法則みたなもの

まとめ

事例の記事にも書いてある通り、1年以上1万人ちかくのユーザが利用していますが大きなトラブルもなく稼働しています。
業務に必要なSaaSをローカルブレイクアウトできるようになったことで、ユーザのエクスペリエンスはよくなったのではないかと思います。
なかなかここまでネットワークに手を入れるのは、簡単な話ではありませんが、SaaS活用によってネットワークで困っているエンジニアさんのヒントになれば幸いです。

最後までご覧いただきありがとうございました。