はじめに
こんにちは！ BBSakura で基盤となるネットワークを開発している酒井です。
このブログ記事では、前回の 「拠点間接続」ユースケースの記事 に引き続いて、 OCX のもう 1 つの代表的なユースケースである「拠点からクラウドサービスへの接続」を通して OCX リソースについて解説します。
「拠点からクラウドサービスへの接続」ユースケースではお客さまのオンプレミス環境とパブリッククラウドを OCX のネットワークを介して接続します。このパブリッククラウドへの接続に必要な OCX リソースである Cloud Connection を詳しく解説していきます。
この記事の想定読者ですが、下記の技術について理解していることを前提としています。
- パブリッククラウド
また、この記事では下記の内容で話を進めていきます。
前回のおさらい
- 前回の記事で解説した、もっとも基本となる OCX リソースについておさらいします。
パブリッククラウドへの接続
- 本ユースケースが必要になる状況とその方法について簡単に説明します。
- OCX を用いた接続の概要について説明します。
Cloud Connection
- OCX リソース Cloud Connection について概要と使い方について説明します。
冗長構成
- 本ユースケースでお客さまに設計いただく OCX ネットワークの冗長構成について説明します。
1. 前回のおさらい
前回の 「拠点間接続」ユースケースの記事 では、「拠点間接続」ユースケースを通して Virtual Circuit ・ Physical Port ・ Virtual Circuit Interface の OCX リソースについて解説しました。もし OCX を知ろうとされていて前回の記事をまだ読んでいない方は、先に前回の記事を読んでいただければと思います。
おさらいとして、前回解説したリソースについて簡単に説明します。
Virtual Circuit (VC)1 つの L2 ネットワーク(ブロードキャストドメイン)に対応します。 OCX では VC へのアタッチ操作がその VC に対応した L2 ネットワークへの接続を意味し、さまざまな OCX リソースを VC へアタッチ可能です。Physical Port (PP)OCX への接続口であり、お客さま側ネットワーク機器が接続する OCX の物理インタフェースになります。Virtual Circuit Interface (VCI)1 つの PP に紐づき、その PP に VLAN を設定します。また、 VC にアタッチ可能なリソースです。
これらの VC ・ PP ・ VCI を組み合わせることにより、下の図のように複数の OCX 拠点を結ぶ L2 ネットワークを自由に作成できることを前回の記事で説明しました。
今回のユースケース「拠点からクラウドサービスへの接続」においても、これらのリソースは使用することになりますので、ここまでの内容をしっかり理解しておくことが重要です。
2. パブリッククラウドへの接続
パブリッククラウドへの通信方法
まず、「拠点からクラウドサービスへの接続」ユースケースがどのような時に必要となるのか説明します。併せて、その実現方法についても説明します。
企業や自宅のオンプレミス環境からパブリッククラウドへの通信はインターネットを経由して行なうことが一般的です。しかし、インターネットは通信帯域や通信経路の保証がないこと、加えて、さまざまな攻撃に晒されるリスクがあることから、一部のシステムの要件にはインターネットとの通信が禁止されている場合があることはご存じかと思います。 こういったインターネット通信禁止の要件をクリアするパブリッククラウドへの通信方法として「専用ネットワークを経由する方法」を多くのパブリッククラウド事業者が提供しています。 この方法では、オンプレミス環境から専用ネットワークのみを経由することで、低遅延・広帯域・安全にパブリッククラウドとの通信が可能になります。
「専用ネットワークを経由する方法」では、パブリッククラウド事業者のネットワーク機器にお客さま側ネットワーク機器を物理的に接続する必要があります1。このパブリッククラウド事業者ネットワーク機器とお客さま側ネットワーク機器間の接続方法をもとに「専用ネットワークを経由する方法」をさらに細かく下記の 2 種類の方法に分けることができます。
- 「専用接続」
- 「パートナー接続」
「専用接続」では、パブリッククラウド事業者のネットワーク機器への接続をすべてお客さまにて調達する必要があります。具体的には、パブリッククラウド事業者ネットワーク機器が設置されているデータセンターまでの回線や当該データセンター内の構内配線などを一から用意する必要があります。調達した接続についてはお客さまが専有できますが、コストやリードタイムの観点では負担が大きくなりがちです。
その一方で、 「パートナー接続」ではパブリッククラウド事業者の認定接続パートナーがパブリッククラウド事業者ネットワーク機器への接続部分を肩代わりしてくれます。 先行してパブリッククラウド事業者ネットワーク機器とパートナーのネットワーク間で接続を行なっているため、お客さまはパートナーのネットワークに接続するだけで OK です。
「専用接続」「パートナー接続」でそれぞれの場合のお客さまにて調達が必要になる区間を上の図で表しました。なお、図ではパブリッククラウド事業者のネットワーク機器が設置されているデータセンターとは別の場所にお客さま側ネットワーク機器が設置されていることを想定しています。
OCX を用いたパブリッククラウドへの接続
OCX は前述の「パートナー接続」を提供しています。 OCX の「パートナー接続」のメリットとしては以下のようなものがあります。
- マルチクラウドに対応
- OCX では複数のパブリッククラウド事業者とのパートナー接続をサポートしています。現在サポートしている事業者は こちら に記載されております。
- OCX 拠点への 1 つの物理接続(1 つの Physical Port)から複数のパブリッククラウドへ同時に接続が可能です。
- 短いリードタイム
- お客さまに用意いただく物理的なものは OCX 拠点(Phyisical Port)への接続のみとなります。
- 一度 OCX 拠点へ接続いただいた後は、お客さまにて OCX マネジメントポータルを直接操作いただくことで、リアルタイムにパブリッククラウドへの接続を作成できます。
- 安価で明確な料金
- 「専用接続」で必要となるパブリッククラウド事業者ネットワーク機器までの高価な専用回線に比べて、 OCX は安価な価格設定になっています。
- OCX の料金はリソースごとに初期費用と月額から構成される簡潔明瞭な価格設定となっています。
各パブリッククラウドへの「パートナー接続」に対応する OCX リソースがこの後に説明する Cloud Connection となります。
3. Cloud Connection
Cloud Connection (CC) はパブリッククラウドへの 1 つの接続に対応する OCX リソースです。例えば、 AWS への接続を 2 つ用意する場合は 2 つの CC を作成する必要があります。
CC を使用したもっともミニマムな「拠点からクラウドサービスへの接続」ユースケースの構成を図示します。
この図では VCI と CC が 1 つの VC にアタッチされています。そのため、図の左にあるお客さま側ネットワーク機器(通常はルータとなります)と右にあるパブリッククラウド事業者のネットワーク機器(パブリッククラウドゲートウェイ)までが L2 ネットワークで接続されていることになります。このお客さま側ネットワーク機器とパブリッククラウドゲートウェイ間で BGP を用いてお互いのネットワーク経路を交換することで、お客さまオンプレミスネットワークと「パブリッククラウド上のネットワーク」の間で通信が可能となります。
なお、ここの「パブリッククラウド上のネットワーク」が指すネットワークは 2 つあります。 1 つ目はお客さまがそのパブリッククラウド上で作成したプライベートネットワークです。 2 つ目はパブリッククラウドがインターネットに公開している SaaS などのパブリックサービスに到達するためのネットワークです。 1 つ目のネットワークについてはすべてのパブリッククラウドで「専用ネットワークを経由する方法」で提供されていますが、 2 つ目のネットワークについては提供されていない場合があります。詳細は各パブリッククラウドの公式ドキュメントを確認してください。
接続に BGP を用いるのはパブリッククラウド側のサービス要件となります。そのため、 OCX に限らず他パートナーによる「パートナー接続」や「専用接続」でも基本的に同様であるため、接続に用いるお客さま側ネットワーク機器が BGP をサポートしている必要があります。もし、 お客さま側ネットワーク機器が BGP をサポートしていない場合は、 OCX では OCX-Router(v1) という BGP をサポートしたオンデマンドのルータを提供していますのでご利用をご検討いただければと思います。
CC の作成手順は、接続先となるパブリッククラウドによって微妙に異なります。各パブリッククラウドに対応した詳しい手順は OCX ドキュメントサイト で説明されていますのでご参照ください。
CC の作成(「パートナー接続」の作成)から実際に通信が可能となるまでの大まかな手順は、どのパブリッククラウドでも基本的に下記の手順となります。
パブリッククラウドで「パートナー接続」を作成
- 手順[2]の操作で必要となるパラメータが提供されます。
- この手順が不要なパブリッククラウドもあります。
OCX マネジメントポータルで CC を作成
- 対象となるパブリッククラウドに合わせて必要なパラメータを入力します。
パブリッククラウドで追加操作
- パブリッククラウド側で必要な追加の操作を行ないます。
作成した CC を VC にアタッチ
- VC にアタッチすることでその VC に対応する L2 ネットワークへ CC (≒パブリッククラウドゲートウェイへのネットワーク)を接続します。
- 当該 VC にはオンプレミスのお客さま側ネットワーク機器へと続く VCI がすでにアタッチされていることとします。
BGP の設定
- お客さま側ネットワーク機器で BGP を設定し、パブリッククラウドゲートウェイとネットワーク経路の交換を行ないます。
ここまでの内容で、「拠点からクラウドサービスへの接続」ユースケースでは VC ・ PP ・ VCI に加えて CC を用いて構成することがわかったかと思います。
4. 冗長構成
最後に、少し進んだ内容になりますが「拠点からクラウドサービスへの接続」ユースケースでの冗長構成について説明します。
このユースケースでは、障害が発生したとしてもオンプレミス環境とパブリッククラウド間の通信が途絶えないようにすることが重要です。そのためにも、 SPOF (Single Point Of Failure)が存在しないように OCX ネットワークを構成する必要があります。以降では、例となる図を用いて段階的に SPOF を取り除いていきながら解説します。なお、今回の例ではオンプレミス環境から 1 つのパブリッククラウドへ OCX を介して接続しているものとします。
まずは下の図のように、もっともミニマムな構成からスタートです。
上の図の CC に注目します。 CC は OCX とパブリッククラウドとの接続部分となるため、当該 CC 箇所の OCX 側ネットワーク機器の物理インタフェースとパブリッククラウドゲートウェイの物理インタフェースの障害による影響を受けます。そのため、 CC を 2 つ用意して冗長化します。 OCX では CC を冗長化できるように OCX とパブリッククラウドの接続ポイントである NNI (Network-Network Interface)を各パブリッククラウドごとに 2 つ以上提供しています。 NNI が異なるということは、 OCX とパブリッククラウド間が違う箇所で接続されているということを意味します。 CC の作成時に NNI を選択できますので、 CC を冗長化する場合は NNI を重複させずに CC を 2 つ作成していただければと思います。
CC を冗長化した構成が下の図となります。
上の図では PP に注目します。 PP はお客さま側ネットワーク機器が接続する OCX への接続口となるため、お客さまネットワーク機器の物理インタフェースと OCX 側ネットワーク機器の物理インタフェースの障害による影響を受けます。この影響を回避するために、 PP を 2 つ用意して冗長化します。
この際、単に PP を 2 つ用意するだけではなく、より一歩踏み込んで、ネットワーク機器筐体の障害への対策を取ることを推奨します。この対策により、当該 PP を収容している OCX 側・お客さま側ネットワーク機器の突発的な再起動や電源断による筐体全体に影響がある障害も回避が可能です。具体的には、 PP の 「ポートの冗長」 オプションを有効化することで、 OCX 側ネットワーク機器筐体障害の対策を行なえます。この「ポートの冗長」オプションを有効化することで、 PP 作成時に同じ OCX 接続拠点の既存 PP を指定でき、その指定した既存 PP を収容している OSW 側ネットワーク機器筐体とは別の機器筐体に PP を作成できます。これにより、機器筐体をまたいで冗長化された PP のペアを構成できます。また、この PP の冗長ペアに接続するお客さま側ネットワーク機器も冗長化することで、お客さま側ネットワーク機器筐体の障害にも耐えうる設計となります。
ネットワーク機器筐体の障害対策を含めて、 PP を冗長化した構成が下の図となります。
さて、最後に 1 つの OCX 拠点がまるごとダウンすることを考えます。あまり考えたくはないですが、広域災害や電源に関わる事故によってデータセンター全体に影響のある障害が存在します。上の図のように 1 つの OCX 拠点にしか接続していない場合に、当該データセンターでそういったデータセンター全体に影響のある障害が発生すると、その障害が復旧するまで影響を受け続けることになってしまいます。この影響を回避するには、下の図のように異なる OCX 拠点へ接続し、拠点冗長をとる必要があります。
上の図が、オンプレミス環境から 1 つのパブリッククラウドへ OCX を介して接続する場合の SPOF が無い構成と言ってよいでしょう。これ以上にシステム全体として障害に強い構成とするには、「OCX 以外のオンプレミスとパブリッククラウド間の通信手段も用意しておく」「パブリッククラウドの障害に備えてマルチクラウドで構成する」といったことが考えられます。リスクとコストを天秤にかけて、お客さまにとってベストな構成を検討いただければと思います。
おわりに
今回の記事では、「拠点からクラウドサービスへの接続」ユースケースを通して、 Cloud Connection のリソースについて解説しました。また、 Cloud Connection を用いた構成での冗長構成についても説明しました。前回の記事とあわせて、これで OCX のもっとも基本となるユースケースについて理解いただけたかと思います。
紹介したもの以外にも、まだまだ OCX には他の機能サービスやそのサービスを構成するリソースが存在し、今後も追加されていく予定です。それらの解説も別の機会にできればと考えています。
OCX のご利用に興味をもたれたり、 OCX を使用した構成の設計についてご質問やご相談ごとがあれば、お気軽に弊社までお問い合わせください！
- より正確にはパブリッククラウド事業者が発行した LOA のパッチパネルポートまで接続する必要があります。そのためには、 LOA をデータセンターに提出してクロスコネクトを調達する必要があります。↩
