Cloud Interconnect に関するよくある質問

このドキュメントでは、Cloud Interconnect の機能とアーキテクチャに関するよくある質問について説明します。質問と回答は、以下の主要セクションにまとめています。

Cloud Interconnect を経由するトラフィック

このセクションでは、Cloud Interconnect を経由するトラフィックの種類、帯域幅、暗号化に関する質問に回答します。

Cloud Interconnect 経由で伝送されるのはどのような種類のパケットですか?

Cloud Interconnect の回線では、ペイロードに IPv4 パケットが含まれる 802.1q イーサネット フレームが伝送されます。これらのフレームは、VLAN タグ付きイーサネット フレームとも呼ばれます。

802.1q ヘッダーの 12 ビット VLAN ID(VID)フィールドの値は、相互接続のアタッチメント(VLAN)の作成時に Google Cloud によって割り当てられる VLAN ID の値と同じです。詳細については、次のドキュメントをご覧ください。

Cloud Interconnect 経由のトラフィックを暗号化するにはどうすればよいですか?

Cloud Interconnect を使用してアクセスされるサービスによっては、特別な処理をしなくてもトラフィックがすでに暗号化されている場合があります。たとえば、Cloud Interconnect 経由で到達可能な Google Cloud API のいずれかにアクセスする場合、そのトラフィックは、すでに、公共のインターネット経由でその API にアクセスする場合と同じように、TLS によって暗号化されています。

お客様が作成するサービスで TLS ソリューションを使用することもできます。たとえば、Compute Engine インスタンス上で提供するサービスや、HTTPS プロトコルをサポートする Google Kubernetes Engine ポッド上で提供するサービスなどで TLS ソリューションを使用できます。

IP レイヤで暗号化が必要な場合は、Virtual Private Cloud ネットワーク内に 1 つ以上の自己管理型の(Google Cloud のものではない)VPN ゲートウェイを作成し、各ゲートウェイにプライベート IP アドレスを割り当てます。たとえば、Compute Engine インスタンスで StrongSwan VPN を実行します。この場合は、オンプレミスから Cloud Interconnect を通過してそれらの VPN ゲートウェイで終端する IPsec トンネルを確立できます。

詳細については、転送データの暗号化に関するドキュメントをご覧ください。

Dedicated Interconnect 経由の 100G 接続を作成できますか?

はい、必要に応じて Google との接続をスケーリングできます。

Cloud Interconnect 接続は、イーサネット ポート チャネルリンク(LAG)グループとしてデプロイされた 1 つ以上の回線で構成されます。接続内の回線は 10 Gbps または 100 Gbps のいずれかです。両方を使用することはできません。

接続には、次の最大容量のいずれかを選択できます。

  • 8 x 10 Gbps 回線(合計 80 Gbps)
  • 2 x 100 Gbps 回線(合計 200 Gbps)

Dedicated Interconnect または Partner Interconnect では、相互接続のアタッチメント(VLAN)に対して、50 Mbps~50 Gbps の容量をサポートします。

Cloud Router の BGP ルーティング機能を利用すると、複数の接続を注文して、それらをアクティブ - アクティブ方式で使用できます。

容量、割り当て、制限の詳細については、Cloud Interconnect の価格設定のページ割り当てのページをご覧ください。

Cloud Interconnect 経由で IPv6 を使用してインスタンスにアクセスできますか?

VPC には、IPv6 トラフィックをインスタンスで終端させるネイティブの機能はありません。

BGP ピアリング IP アドレスを指定できますか?

  • Partner Interconnect の場合はできません。ピアリング IP アドレスは Google によって選択されます。
  • Dedicated Interconnect の場合は、相互接続のアタッチメント(VLAN)を作成するとき、Google によって選択される IP アドレス範囲(CIDR ブロック)を指定できます。この CIDR ブロックは、リンクローカル IP アドレス範囲 169.254.0.0/16 内にある必要があります。

オンプレミスから Cloud Interconnect を介して Google API にアクセスできますか?また、どのようなサービスや API を使用できますか?

Google API にアクセスするには、次の 2 つの方法があります。

オプション 1 は、VPC ネットワーク内の 1 つ以上のサブネットで限定公開の Google アクセスを有効にして、それらのサブネットに 1 つ以上のリバース プロキシ インスタンスをデプロイする方法です。これらのリバース プロキシには VPC のプライベート IP のみが構成されているため、オンプレミスからそれらに到達するには、Cloud Interconnect リンクを経由する必要があります。このソリューションを採用すると、ほとんどのクラウド API、デベロッパー API、ほとんどの Google Cloud サービスへのアクセスが許可されます。

限定公開の Google アクセスでサポートされる GCP サービスのリストなどの詳細については、限定公開の Google アクセスの構成をご覧ください。

オプション 2 は、オンプレミス ホストで限定公開の Google アクセスを利用するという方法です。この場合は、オンプレミス ホストからのリクエストを restricted.googleapis.com に送信する必要があります。この URL は常に IP 範囲 199.36.153.4/30 に解決されます。この範囲は制限付き VIP 範囲とも呼ばれます。

この制限付き VIP 範囲をアドバタイズするために、Cloud Router 上にカスタムルートを追加します。これにより、(宛先である)制限付き VIP へのトラフィックは、オンプレミスから Cloud Interconnect 経由で API エンドポイントにルーティングされます。このソリューションでは、制限付き VIP をサポートする Google API と Google サービスにのみ到達できます。

構成の詳細とサポートされるサービスに関する最新情報については、オンプレミス ホスト用の限定公開の Google アクセスの構成をご覧ください。

Cloud Interconnect をプライベート チャネルとして使用して、すべての G Suite サービスにブラウザからアクセスできますか?

2018 年 12 月の時点では、Cloud Interconnect を経由して G Suite アプリケーションにアクセスすることはできません。

一定の時間が経過すると BGP セッションが継続的にフラップするのはなぜですか?

オンプレミスの BGP IP 範囲のサブネット マスクが正しいかどうか確認してください。たとえば、169.254.10.0/29 と構成すべきところを、169.254.10.0/30 と構成しているかもしれません。

L3 Partner Interconnect 接続を介して MED 値を送信し学習できますか?

レイヤ 3 パートナーが BGP を処理する Partner Interconnect 接続を使用している場合、Cloud Router はオンプレミス ルーターから MED 値を学習することや、MED 値をそのルーターに送信することができません。これは、MED 値が自律システムを通過できないためです。つまり、このタイプの接続では、Cloud Router によってオンプレミス ルーターにアドバタイズされるルートと、オンプレミス ルーターによって VPC ネットワークにアドバタイズされるルートの優先度を設定できません。

Cloud Interconnect のアーキテクチャ

このセクションでは、Cloud Interconnect のアーキテクチャを設計または使用する際のよくある質問に回答します。

Cloud Interconnect を使用して公共のインターネットに接続できますか?

2018 年 12 月の時点では、インターネット ルートは Cloud Interconnect 経由でアドバタイズされません。

コロケーション施設のロケーション ページに記載されていない POP ロケーションにいる場合、Google Cloud に接続するにはどうすればよいですか?

2 つの方法があります。いずれかを行った後、Dedicated Interconnect の通常の発注とプロビジョニングの処理を進めることができます。

  • 通信事業者に回線を注文し、お客様の POP(point-of-presence)ロケーションから Google のいずれかの Cloud Interconnect コロケーション施設に接続できます。通常は、契約しているコロケーション施設プロバイダに問い合わせ、「オンネット」プロバイダのリストを入手することをおすすめします。オンネット プロバイダとは、お客様の建物の中にすでにインフラストラクチャを構築しているプロバイダのことです。オンネット プロバイダを使うほうが別のプロバイダを使うよりも低コストかつ迅速です。別のプロバイダを使う場合、そのプロバイダは既存の POP ロケーションに到達するためのインフラストラクチャを構築しなければならないからです。
  • もう 1 つは、Partner Interconnect を使用し、お客様の拠点に到達するための「ラストワンマイル回線」を提供できる通信事業者をパートナーにするという方法です。通常、コロケーション プロバイダはこのタイプのサービスを提供できません。コロケーション プロバイダのロケーションは固定されており、お客様がすでにそのロケーションに存在している必要があるためです。

Partner Interconnect を使用する場合、相互接続のアタッチメント(VLAN)を作成したプロジェクトで相互接続は表示されますか?

Partner Interconnect サービスを使用すると、相互接続オブジェクトはパートナー プロジェクト内に作成され、お客様のプロジェクトには表示されません。相互接続のアタッチメント(VLAN)については、Cloud Interconnect の場合と同様に、プロジェクト内に表示されます。

Cloud Interconnect を使用して冗長アーキテクチャを作成するにはどうすればよいですか?

希望する SLA に応じて、Dedicated Interconnect、Partner Interconnect の両方について、特定のアーキテクチャを実装する必要があります。

本番環境対応アーキテクチャ用の 99.99% SLA のトポロジと、ミッション クリティカルではないアプリケーション用の 99.9% SLA のトポロジについては、/network-connectivity/docs/interconnect/docs/tutorials をご覧ください。

これらの SLA レベルは、Cloud Interconnect の可用性(オンプレミス ロケーションと VPC ネットワークの間でルーティングされる接続の可用性)を示しています。たとえば、Cloud Interconnect を介して到達可能な Compute Engine インスタンスにサービスを作成する場合、このサービスの可用性は、Cloud Interconnect サービスと Compute Engine サービスの両方の可用性の組み合わせによって左右されます。

  • Dedicated Interconnect の場合、単一の相互接続(LACP バンドル)に稼働時間のない SLA があります。
  • Partner Interconnect の場合、単一の相互接続のアタッチメント(VLAN)に稼働時間のない SLA があります。

単一の相互接続 / バンドルの障害に関する問題は、「P3: 中程度の影響 – サービスの使用が部分的に損なわれている」より低いサポートケースの優先度で処理されます。そのため、迅速な解決やさらなる根本原因の分析は期待できません。

定期または臨時メンテナンスが原因で、単一のリンクやバンドルが数時間または数日などの長期間にわたってもドレインされる可能性があります。

オンプレミスのレガシー アプリケーションと内部ロードバランサのバックエンドの間で、Cloud Interconnect 経由のトラフィックを転送できますか?

このシナリオでは、2 つの階層で構成されるアプリケーションをデプロイ済みです。Google Cloud にまだ移行されていないオンプレミス階層(レガシー階層)と、Google Cloud の内部ロードバランサ(ILB)のバックエンドでもある VPC インスタンス上で実行されているクラウド階層です。

Cloud Router とオンプレミス ルーターの間に必要なルートを実装すれば、Cloud Interconnect を使用してこれら 2 つのアプリケーション階層の間でトラフィックを転送できます。このアプリケーションのトラフィックを処理するために Cloud Interconnect で使用する Cloud Router は、ILB バックエンドを含むサブネットと同じリージョンに配置する必要があります。ILB はリージョンのルーティングのみをサポートしているからです。また、VPC のグローバル ルーティングで、ILB バックエンドが存在するリージョンの外部にあるトンネルを使用する場合、ILB アクセスが失われることもその理由です。詳細については、VPN または Interconnect の使用をご覧ください。

オンプレミス トラフィックが別のリージョンから VPC ネットワークに入る場合は、もう一方のリージョンでそれぞれのバックエンドを持つ ILB をデプロイするか、トラフィックをリバース プロキシにルーティングしてそこから ILB VIP に到達させます。

Google Cloud のプロジェクトや組織間で、1 つ以上の Cloud Interconnect のインスタンスを移動できますか?

プロジェクトを新しい Google Cloud 組織に移行する必要がある場合は、サポートケースを作成していただくと、Cloud サポートで移行を迅速に処理できます。

Dedicated Interconnect および相互接続のアタッチメント(VLAN)は、プロジェクトが同じである限り、組織の変更による影響を受けません。

プロジェクトを変更するにあたって、Cloud Interconnect のアクティベーションを実行していて LOA を所有しているが、まだアクティベーションを完了していない場合は、現在のアクティベーションをキャンセルして目的のプロジェクトに新しいインスタンスを作成します。Google が新しい LOA を発行し、お客様はそれを相互接続プロバイダに提供できます。

ただし、アクティブな Cloud Interconnect をプロジェクト間で移動することはできません。アクティブな Cloud Interconnect はプロジェクトの子オブジェクトであり、プロジェクト間でオブジェクトを自動的に移行する機能がないためです。もし可能であれば、新しい Cloud Interconnect のリクエストを最初から行ってください。

同じ Google Cloud 組織内の複数のプロジェクトで、同じ Cloud Interconnect を使用して複数の VPC ネットワークに接続するにはどうすればよいですか?

接続先の Cloud Interconnect とは異なるプロジェクトに存在する VLAN アタッチメントの指定は、Dedicated Interconnect と Partner Interconnect の両方でサポートされています。

Partner Interconnect の場合

異なるプロジェクトのものも含めて、相互接続のアタッチメント(VLAN)が複数存在する場合は、それらを同じサービス プロバイダからの Partner Interconnect 接続、または異なるサービス プロバイダからの Partner Interconnect 接続でペアリングできます。

Dedicated Interconnect の場合

プロジェクトが多数ある場合は、各プロジェクトに独自の相互接続のアタッチメント(VLAN)と独自の Cloud Router を与えつつ、指定されたプロジェクトで同じ物理的な Dedicated Interconnect を使用するようにすべてのアタッチメントを構成できます。

相互接続のアタッチメント(VLAN)は、802.1q ID を持つ VLAN であるだけでなく、プロジェクト内に存在する Cloud Interconnect の子オブジェクトでもあります。

このモデルでは、VPC ネットワークごとに独自のルーティング構成を持つことになります。ルーティング ポリシーを一元管理する場合は、共有 VPC モデル共有 VPC の考慮事項を確認したうえで、共有 VPC ホスト プロジェクトの VPC ネットワーク内で相互接続のアタッチメント(VLAN)を終端させます。ホスト プロジェクトには、1 つの Cloud Interconnect あたりの相互接続のアタッチメント(VLAN)の最大数に関する割り当てが存在します。詳細については、Cloud Interconnect の割り当てに関するページをご覧ください。

1 つの Cloud Interconnect を使用して複数のオンプレミス サイトを VPC ネットワークに接続できますか?

これは簡単に実現できます。たとえば、複数のサイトが MPLS VPN ネットワークの一部である場合(自己管理型、通信事業者による管理型のいずれであっても)、Inter-AS MPLS VPN Option A(RFC 4364 のパラグラフ 10 を参照)と同様の方法で、VPC ネットワークを追加サイトとして「論理的に追加」できます。

このソリューションは、パートナーの MPLS VPN サービス内に VPC ネットワークが含まれるようにする方法に関する回答で説明されています。Cloud Router の BGP 機能を活用すると、インターネット ルートのインポートに使用するのと同様のテクニックとアーキテクチャを使用して、既存の IP コア ファブリック内に VPC ルートを挿入することができます。

Cloud Interconnect と他のクラウド プロバイダの相互接続を物理的に「つなぎ合わせる」ことができますか?

Cloud Interconnect と機能面で同等のサービスを提供する別のクラウド プロバイダをすでに使用している場合、2 つの相互接続(Google Cloud が提供するものと他のクラウド プロバイダが提供するもの)を物理的に「つなぎ合わせる」方法に関して、クラウド プロバイダ間で合意されている構成はありません。ただし、VPC ネットワークのプライベート アドレス空間と、別のクラウド プロバイダのネットワークの間でのルーティングは可能です。

他のクラウド プロバイダのサービス ハンドオフのポイントが Cloud Interconnect と同じロケーションにある場合は、そのロケーションに独自のルーターをプロビジョニングして、2 つの相互接続サービスを終端させることができます。この場合、そのルーターは、VPC ネットワークと、他のクラウド プロバイダのネットワークの間をルーティングします。この構成を使用すると、遅延を最小限に抑えながら、2 つのクラウド ネットワークからオンプレミス ネットワークに直接ルーティングできます。

Partner Interconnect の一部の通信事業者は、これを仮想ルーターに基づくマネージド サービスとして提供できます。Google Cloud と他のクラウド プロバイダが異なるロケーションで相互接続サービスを終端させる場合は、2 つのロケーションを接続する回線を用意する必要があります。

Google エッジ近くのコロケーション施設に装置を設置せずに AWS と Google Cloud を接続するにはどうすればよいですか?

Megaport は、Google エッジの近くにハードウェアを配置することを望まない Google Cloud のお客様向けに、独自のクラウド ルーター ソリューションを提供しています。Google Cloud でこのプロダクトを設定する方法の詳細は、構成手順をご覧ください。

相互接続のアタッチメント(VLAN)

このセクションでは、相互接続のアタッチメント(VLAN)に関する質問に回答します。

相互接続のアタッチメント(VLAN)で使用する VLAN ID を選択する方法を教えてください。

Partner Interconnect で作成される相互接続のアタッチメントの場合、アタッチメントの作成プロセス時にパートナーが VLAN ID を選択しますが、ユーザーによる選択が可能な場合もあります。相互接続のアタッチメント用の VLAN ID を選択できるかどうかは、パートナーにご確認ください。

Dedicated Interconnect を使用して作成された相互接続のアタッチメントの場合は、--vlan フラグをオンにして gcloud compute interconnects attachments create コマンドを使用するか、Google Cloud Console の手順に従います。

次の例では、gcloud コマンドを使用して、VLAN ID を 5 に変更しています。

gcloud compute interconnects attachments dedicated create my-attachment \
  --router my-router \
  --interconnect my-interconnect \
  --vlan 5 \
  --region us-central1

完全な手順については、以下のいずれかのドキュメントをご覧ください。

Cloud Router を複数の相互接続のアタッチメントと併用できますか?

はい、この構成はサポートされています。

MPLS

このセクションでは、Cloud Interconnect と MPLS に関する質問に回答します。

Cloud Interconnect を使用して VPC ネットワーク内の MPLS LSP を終端させることができますか?

2018 年 12 月時点では、VPC には MPLS LSP を終端させるための Google Cloud のネイティブ機能はありません。

自己管理型 MPLS VPN サービスにおいて、VPC ネットワークを追加サイトとして含めることはできますか?

お客様が管理している MPLS VPN サービスがある場合は、自己管理型 VPN によって構成されている追加サイトとして VPC ネットワークを含めることができます。

このシナリオでは、プロバイダから MPLS VPN サービスを購入していないことが前提となります。つまり、お客様が所有している MPLS VPN 環境において、MPLS ネットワークの P ルーターおよび PE ルーターをお客様が管理、構成している必要があります。

自己管理型 MPLS VPN サービス内に追加サイトとして VPC ネットワークを含めるには、次の手順に従います。

  1. いずれかの MPLS VPN PE エッジデバイスを、Dedicated Interconnect のピアリング エッジデバイスに接続します。これには、Inter-AS MPLS VPN Option A(RFC 4364 のパラグラフ 10 を参照)によく似たモデルを使用します。つまり、必要な MPLS-VPN VPN(たとえば VRF_A)を PE エッジデバイス内で終端させ、VLAN から VRF へのマッピングを使用して Google Cloud の相互接続のアタッチメント(VLAN)をこの VPN に「参加」させることができます。実質的には、PE エッジデバイスで VLAN を VRF_A にマッピングすることになります。

  2. PE ルーターと Cloud Router の間に標準的な IPv4 BGP セッションを作成し、それらの間でルートが確実に交換されるようにします。Cloud Router によって送信されたルートは、VPN のルーティング テーブル(VRF_A 内)のみに設定され、PE エッジデバイスのグローバル ルーティング テーブルには設定されません。

    複数の独立した VPN を作成することで、重なり合う IP 範囲を管理できます。たとえば、VRF_A と VRF_B があり、それぞれに特定の VPC ネットワーク(たとえば VPC_A と VPC_B)内の Cloud Router への BGP セッションが存在するとします。この場合、お客様の PE エッジデバイスと Dedicated Interconnect のピアリング エッジデバイスの間に MPLS カプセル化は必要ありません。

Partner Interconnect のパートナーである通信事業者の MPLS VPN 内に、VPC ネットワークを追加サイトとして含めることはできますか?

Partner Interconnect の正式なパートナーである通信事業者から MPLS VPN サービスを購入した場合は、MPLS VPN 内に VPC ネットワークを追加サイトとして含めることができます。

この場合は、プロバイダが MPLS ネットワークの P ルーターと PE ルーターを管理、構成します。Partner Interconnect は Dedicated Interconnect とまったく同じ接続モデルを使用するため、通信事業者は Inter-AS MPLS VPN Option A(RFC 4364 のパラグラフ 10 を参照)と非常によく似たモデルを利用できます。

実質的には、通信事業者はレイヤ 3 Partner Interconnect サービスをお客様に提供し、相互接続のアタッチメント(VLAN)を通信事業者のエッジデバイス上の適切な MPLS VPN に「バインド」します。詳細については、Interconnect Partner の概要をご覧ください。これはレイヤ 3 サービスモデルであるため、Cloud Router と通信事業者のエッジデバイス内の VRF の間に BGP セッションが確立されます。