📚 课程目录第4章 Partner Interconnect 集成

4. Partner Interconnect 集成

Partner Interconnect 是 Google Cloud 混合互联家族中“由第三方运营商承载最后一公里”的方案。它不要求企业自建专线直连 Google 的边缘接入点（PoP），而是通过 Google 认证的合作伙伴（如 Equinix、Lumen、Orange、Vodafone、中国电信国际等）提供的网络服务，把本地数据中心或办公站点接入 Google Cloud VPC。理解它的关键，是把它看成一条“由合作伙伴负责接入段、由 Google 负责云端段”的分段链路，而不是一条端到端由 Google 交付的专线。

一、Partner Interconnect 的定位与两种接入形态

与 Dedicated Interconnect 相比，Partner Interconnect 的核心差异在于：Dedicated 要求企业自己的机房或托管机柜与 Google PoP 在同一 colocation 设施内，且带宽通常从 10 Gbps 起；Partner 则允许企业位于任意位置，只要该位置能接入某个合作伙伴的网络，就能以 50 Mbps 到 50 Gbps 的粒度建立连接。这使它特别适合分支机构、非一线城市机房、带宽需求中等或希望快速开通的场景。

Partner Interconnect 有两种接入形态：二层连接（Layer 2）和三层连接（Layer 3）。二层连接中，合作伙伴只提供 VLAN 透传，BGP 会话由企业自己与 Google 建立，企业需要自行管理 Cloud Router 和 BGP ASN；三层连接中，合作伙伴负责建立并管理到 Google 的 BGP 会话，企业只需把本地路由通过合作伙伴通告，配置更简单，但可控性和路由可见性略低。选择哪种形态，取决于企业是否希望保留对 BGP 的完全控制。

二、服务等级协议（SLA）要看什么

Partner Interconnect 的 SLA 是分段的，这一点必须提前向业务方说明。Google 对 Partner Interconnect 的云端段提供可用性承诺：单条 Attachment 通常为 99.9%，配置了冗余（两条 Attachment 位于不同边缘可用域）后可提升到 99.99%。但“最后一公里”的可用性由合作伙伴的合同决定，Google 不为其背书。因此，评估整体 SLA 时，应把 Google 段与合作伙伴段的可用性按串联系统估算：若两段各为 99.9%，理论端到端约为 99.8%。

除可用性外，还要关注合作伙伴合同中的时延承诺、抖动、丢包率、故障响应时限（MTTR）以及是否提供 24×7 中文支持。对于承载语音、视频或数据库同步的业务，时延和抖动往往比可用性更敏感。建议在采购前要求合作伙伴给出从企业站点到目标 Google 区域的实际时延参考值，而不是只看“接入 Google”这一层。

三、配置步骤：从下单到 BGP 建立

下面以二层连接为例，梳理一条可复现的配置路径。示例参数均为教学假设，实际值需按项目填写。

在合作伙伴侧下单。向合作伙伴提交接入点位置、目标 Google 区域、带宽（如 1 Gbps）、连接形态（L2）以及 VLAN 需求。合作伙伴会返回一个配对密钥（Pairing Key），格式类似 7d9f-2a4c-8b31，用于在 Google 侧认领连接。
在 Google Cloud 创建 Partner Interconnect Attachment。进入“混合连接 → Interconnect → 创建 Partner Interconnect”，选择边缘可用域（如 iad-zone1-1），填入配对密钥，设置带宽和 VLAN ID（如 1200）。
创建 Cloud Router 并配置 BGP。Cloud Router 的 ASN 建议使用私有 ASN，如 16550 是 Google 侧固定 ASN，企业侧可用 65001。在 Attachment 上启用 BGP 会话，设置对端 ASN 和链路本地地址（如 169.254.10.1/30 与 169.254.10.2/30）。
在 CE 路由器上配置 VLAN 子接口与 BGP。示例配置片段如下：

interface GigabitEthernet0/1.1200
  encapsulation dot1Q 1200
  ip address 169.254.10.2 255.255.255.252
!
router bgp 65001
  neighbor 169.254.10.1 remote-as 16550
  address-family ipv4 unicast
    neighbor 169.254.10.1 activate
    network 10.10.0.0 mask 255.255.0.0

配置完成后，在 Google Cloud 控制台的 Attachment 详情页查看 BGP 会话状态，应显示为 UP，并能在 Cloud Router 的路由表中看到从 CE 学到的 10.10.0.0/16 路由。此时从 VPC 内的一台 VM 执行 ping 10.10.1.10（假设为本地某台主机），若返回正常且 traceroute 显示经过 Attachment 的链路本地地址，即可判定二层连通与路由交换均已生效。

四、成本优化：把带宽和流量花在刀刃上

Partner Interconnect 的成本由两部分组成：Google 侧的 Attachment 小时费和出向流量费，以及合作伙伴侧的端口/带宽月费。优化空间主要在三处。

第一，按实际峰值选带宽，而不是按端口上限。Attachment 带宽可以按 50 Mbps 步进调整，若业务峰值长期低于 500 Mbps，就不必购买 1 Gbps。可以先按较低带宽开通，观察 Cloud Monitoring 中的 interconnect/attachment/sent_bytes_count 指标，再按需扩容。

第二，利用出向流量费差异做路径选择。Google 对 Partner Interconnect 的出向流量定价通常低于公网出向，但高于同区域内部流量。对于跨区域备份、批量数据回传等大流量场景，应尽量让流量走 Interconnect 而非公网出口，同时避免不必要的跨区域转发。

第三，冗余不等于双倍成本。高可用要求两条 Attachment 位于不同边缘可用域，但两条链路可以共享合作伙伴的接入端口，且 Google 侧只对实际使用的 Attachment 计费。若业务允许，可采用“主用 1 Gbps + 备用 200 Mbps”的非对称冗余，在满足 99.99% 目标的同时降低合作伙伴侧月费。

建议在开通前用一张简单的成本对比表，把“公网 VPN + 出向流量”“Partner Interconnect 1 Gbps”“Partner Interconnect 500 Mbps”三种方案按 12 个月估算，重点比较固定月费与流量费的交叉点。通常当月均出向流量超过数 TB 时，Interconnect 的固定成本会被流量节省抵消。

Partner Interconnect 的配对密钥有有效期，且一个密钥只能认领一次。若在 Google 侧创建 Attachment 后长时间未完成合作伙伴侧配置，密钥可能失效，需要重新向合作伙伴申请。此外，VLAN ID 在合作伙伴网络与 Google 侧必须一致，否则 Attachment 会停留在 DOWN 状态。

总体而言，Partner Interconnect 的价值在于用合作伙伴的覆盖能力换取开通速度和地理灵活性，代价是 SLA 分段和成本结构更复杂。工程上应把“配对密钥—Attachment—Cloud Router—CE BGP”这条链路的每一步都留下可核对的参数记录，并在上线后持续观察 BGP 会话状态与流量指标，才能在可用性和成本之间取得平衡。