Network Connectivity Center

Seiji Ariga
Feb 4 · 14 min read

Google Cloud に Network Connectivity Center という新しいサービスが出ました(プレビュー)。

このサービスを使うと Google Cloud のバックボーンを使ってユーザーの拠点間を接続することが簡単にできるようになります。

今まで、国内含めグローバルに拠点がある場合は通信サービスを利用して各拠点を接続するのが一般的でした。しかし、クラウドサービスが多くの国、拠点で利用できるようになり、かつ、クラウドにおける仮想ネットワーク(VPC - Virtual Private Cloud)がグローバルに通信をできることから、そもそもクラウドのバックボーンをユーザーの拠点間の通信に使いたいというご要望が増えてきました。

ネットワークサービスの利用からクラウドバックボーンの利用へ

そのようなご要望に応えるサービスが、Network Connectivity Center になります。

ユーザー拠点(オンプレミス環境)をクラウドへ接続するサービスとして Cloud VPN (サイト間 IPsec VPN サービス)や Cloud Interconnect (専用線接続)が提供されていますが、これらのサービスでユーザーの拠点をクラウドへ接続した上で、Network Connectivity Center によって各拠点間の経路交換をおこなうことで、クラウドのバックボーンを通した拠点間通信を実現できます。

本サービスはプレビューということもあり 2021 年 2 月 3 日時点での対応拠点はオーストラリア、インド、英国、米国の 4 拠点ですが、他の拠点も順次対応予定となっています。

(なお、この場合の「拠点」の考え方ですが、Cloud VPN や Cloud Interconnect で接続する先のリージョンがどの拠点(国)にあるかで判断します。たとえばアイルランドからロンドンリージョンに VPN で接続している場合は、英国拠点接続相当になります。)

Network Connectivity Center の詳細

ハブ&スポーク モデル

Network Connectivity Center は図のように「ハブ&スポーク モデル」によって構成されます。「ハブ」(Hub)に対して各接続サービスが「スポーク」(Spoke)として接続され、各スポーク間が通信できるようになる、というモデルです。

なお、一般的なネットワークモデルとしてのハブ&スポークのように、ハブを実際のパケットが経由するということはありません。ハブはあくまでスポーク間の論理的な情報交換のために使われ、実際のパケットはスポーク間で直接やりとりされます。

グローバルなリソースであり、複数のスポークをまとめる役割を担っています。ハブと VPC は 1:1 の関係で、あるハブにすでに VPC からのスポークがつながっている場合、同じ VPC から異なるハブへ接続したり、異なる VPC からハブへスポークを作ったりすることはできません。

ハブと VPC の関係

NG の例を作ろうとすると "Hub xxx already contains Spokes from the VPC network xxx; two Hubs cannot contain Spokes from the same VPC network" "all Spokes must belong to the same VPC network" のようなエラーメッセージが表示されます。

スポークはハブに追加するかたちで作成することができ、Cloud VPN の VPN トンネル (HA VPN のトンネルのみ)、Cloud Interconnect の VLAN アタッチメント、ルーターアプライアンスなどを一つもしくは複数接続することができます。冗長構成をとっている場合(HA VPN のトンネルのペアや、Zone 間で冗長となっている VLAN アタッチメントなど)は、一つのスポークに接続するようにしてください。

設定例

では、実際に設定をしてみます。設定のターゲットは以下のような環境です。ユーザー拠点に見立てた VPC を 3 つ用意し、2つは Cloud VPN で、一つは Cloud Interconnect で接続し、それぞれの VPC (拠点)が相互に通信できることを目指します。

なお、Network Connectivity Center の設定自体は簡単なんですが、複数の拠点が VPN や専用線でつながってる環境を作るのは少し手間です。

初めにユーザー拠点相当となる VPC (とサブネットに必要最小限のファイアウォール)を 3 つ、ムンバイ(インド)、バージニア(米国)、ロンドン(英国)にそれぞれ作ります。

次に、各ユーザー拠点からの接続を終端する VPC を作成します。その際、 --bgp-routing-mode=global を指定し、VPC 内で(各リージョンにある接続からの)経路がグローバルに伝播するようにします。

gcloud compute networks create

Cloud Console だとこんな設定です。

ちなみに目的の構成ではこの hub-vpc に VM 等はなくてもよいので、サブネットすら作成する必要はありません。

(余談ですが、Google Cloud では VPC の MTU が長らく 1460 バイトでしたが、2020 年 10 月から 1500 バイトに設定できるようになりました。次は 9000 バイトを…)

次に、このハブとなる VPC へ拠点となる VPC を Cloud VPN/Cloud Interconnect でつないでいきます。

各 VPC を作成したら、初めにハブとなる VPC hub-vpcと、インド、ロンドンの VPC を Cloud VPN で接続します。具体的な設定方法はドキュメント「Google Cloud ネットワーク間の HA VPN の作成」にありますのでここでは割愛します。(また、スクリーンショットの羅列で恐縮ですが以前書いたエントリ「Cloud VPN で VPC 同士をつなぐ方法」でもご紹介しています)

次は Cloud Interconnect を使った専用線接続です。Google Cloud のサービス単体では外部のネットワークとの接続も VPC 同士の接続もできないので、ここは Google Cloud のパートナーでもある Megaport さまのサービスを利用することにします。

また、せっかくなのでユーザー拠点となる VPC として外部のクラウドサービスを利用し、(パートナーさまによる Cloud Interconnect サービスの提供である) Partner Interconnect を使って簡単にマルチクラウド接続ができることをお見せしたいと思います。

…といいつつ、(英語ですが)すでにドキュメントがありますので、実際の設定内容はそちらをご覧ください。

Connecting multi-cloud VPCs with Megaport Cloud Router

それでは本題の Network Connectivity Center の設定に入ります。

ここまでの設定により、インド、バージニア、ロンドンにあるそれぞれの VPC が、ハブとして機能する VPC hub-vpc に Cloud VPN、Cloud Interconnect で接続され、各拠点 VPC と hub-vpc は相互に通信できるが、拠点 VPC 間は通信できない状態になっています。

これは、各拠点 VPC と hub-vpc はお互いの経路を交換しているが、hub-vpc が各拠点 VPC の経路を他の拠点 VPC へと再広報してくれていないからです。

設定前は直接接続された VPC 同士の経路交換だけ OK

ここを Network Connectivity Center で解消していきます。

まず初めに「ハブ」を作成します。

$ gcloud alpha network-connectivity hubs create connectivity-hubCreate request issued for: [connectivity-hub]Waiting for operation [projects/project-ongcp/locations/global/operations/operation-1612236151311-5ba51fb17caf8-28765d5a-e933047a] to complete...done.Created hub [connectivity-hub].

この時点では connectivity-hub という名前のハブを作成しただけで、VPC との関連もありません。(なお「ハブ」リソース自体はグローバルなリソースで、どこかのリージョンに作られるものではありません。)

次に、Cloud VPN のトンネルや Cloud Interconnect の VLAN アタッチメントを「スポーク」として今作成したハブ connectivity-hub に接続します。

$ gcloud alpha network-connectivity spokes create mumbai-vpn-spoke --hub=connectivity-hub --vpn-tunnel=hub-mumbai-tunnel-1,hub-mumbai-tunnel-2 --region=asia-south1Create request issued for: [mumbai-vpn-spoke]Waiting for operation [projects/project-ongcp/locations/asia-south1/operations/operation-1612236271476-5ba5202415d2e-e148eac3-918698c5] to complete...done.Created spoke [mumbai-vpn-spoke].$ gcloud alpha network-connectivity spokes create london-vpn-spoke --hub=connectivity-hub --vpn-tunnel=hub-london-tunnel-1,hub-london-tunnel-2 --region=europe-west2Create request issued for: [london-vpn-spoke]Waiting for operation [projects/project-ongcp/locations/europe-west2/operations/operation-1612236340893-5ba52066497fb-e4c8966d-7249a4d0] to complete...done.Created spoke [london-vpn-spoke]$ gcloud alpha network-connectivity spokes create virginia-interconnect-spoke --hub=connectivity-hub --interconnect-attachment=hub-virginia-attachment-1 --region=us-east4Create request issued for: [virginia-interconnect-spoke]Waiting for operation [projects/project-ongcp/locations/us-east4/operations/operation-1612238585157-5ba528c295912-56fb15c7-511dd83f] to complete...done.Created spoke [virginia-interconnect-spoke].
  • ハブと違ってスポークは各リージョンに作成されます。
  • HA VPN の(冗長性を構成している) 2 つのトンネルは一つのスポークに集約して設定します → --vpn-tunnel=hub-mumbai-tunnel-1,hub-mumbai-tunnel-2

設定は以上です。シンプルですね。ここまで設定したら、ハブを経由して各拠点の経路がお互いに広告され、結果として、たとえば各拠点 VPC 内の VM から他の拠点 VPC 内の VM に到達できるようになります。

例としてムンバイの VPC (ユーザー拠点相当)で経路がどう見えるかを確認します。

まずはスポークの設定前です。hub-vpc と Cloud VPN でつながってはいますが、hub-vpc にサブネットが無いため何も経路が広告されてこず、結果として自分のサブネットルートしかありません。

次にスポークを設定した後の経路の見え方です。Network Connectivity Center の設定をしたことで、他拠点からの経路も受信できるようになりました。これで、このムンバイの拠点からロンドンやバージニアへも通信できるようになります。

作成したリソース(ハブとスポーク)を見てみるとこんな感じです。

たとえば、ハブ connectivity-hub には 3 つのスポークが。スポークの一つ mumbai-vpn-spoke には 2 つのトンネル hub-mumbai-tunnel-1,2 が紐付いてることが分かります。

(なお、VPC とハブは 1:1 の関係だと上の方で書きましたが、ハブに対して直接 VPC の設定をするのではなく、スポークに紐づくリソースが VPC に紐付いており、そのスポークをハブにつなげることで間接的にハブと VPC が関連付くこととなります。)

注意点

ここまでで Network Connectivity Center の利用イメージは持っていただけたかと思います。以下は利用上の注意点となります。

  • Network Connectivity Center を利用した拠点間接続では帯域は保証されません。(ただし、Google Cloud のバックボーンをご利用いただくため、通常は十分な帯域をご利用いただけるものと思います。)
  • 共有 VPC をご利用の場合、ハブはホストプロジェクトに作成いただく必要があります。
  • (他の拠点からの経路を Network Connectivity Center 経由で受け取るため) 各ユーザー拠点のルーターはそれぞれ異なる AS 番号を利用する必要があります。(同じ AS 番号を利用してしまうと、他拠点からの経路広告を自 AS からの経路を見なして拒否してしまいます。)
  • BGP の AS パス長、MED は経路の優先順位決定に利用されますが、BGP コミュニティは利用されません。

また、執筆時点ではプレビューでのご提供のため、何らかの不具合が発生する可能性があることはご承知おきください。

Google Cloud のバックボーンを拠点間接続に使いながら、合わせてオンプレミス環境とクラウド環境でのハイブリッドクラウド環境を構築するのに役に立てていただけると思っておりますので、ぜひお試しいただき、フィードバックをいただけますとありがたいです。

google-cloud-jp

Google Cloud Platform…

google-cloud-jp

Google Cloud Platform 製品などに関連するコミュニティが記載したテクニカル記事集。掲載された意見は著者のものであり、必ずしも Google のものを反映するものではありません。

Seiji Ariga

Written by

Customer Engineer, Network Specialist, Google Cloud (All views and opinions are my own.)

google-cloud-jp

Google Cloud Platform 製品などに関連するコミュニティが記載したテクニカル記事集。掲載された意見は著者のものであり、必ずしも Google のものを反映するものではありません。

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store