混合連線與多雲網路

專線不是混合網路的全部

企業說「我們要一條地端到 Google Cloud 的專線」時，架構師還不能開始下單。你至少還要問：

• 平常和尖峰各有多少流量？是雙向對稱，還是大量上傳？
• 延遲、抖動和封包遺失的目標是什麼？
• 哪些資料必須加密傳輸？
• 可以中斷多久？故障時要降級、切 VPN，還是停止寫入？
• 地端有幾個機房、幾家電信商、幾台邊界路由器？
• Google Cloud 有幾個區域，還要不要連其他雲端？

Cloud Interconnect、HA VPN 和 Cloud Router 是元件；把容量、路由和故障切換接起來，才是一個完整方案。

先選連線媒介，再設計備援

HA VPN

HA VPN 使用 IPsec，透過網際網路或 Cloud Interconnect 承載加密流量。它適合快速建立連線、流量還不大，或需要做加密備援的情境。

HA VPN gateway 有兩個介面。要符合 99.99% availability SLA 的 Google 端拓撲，至少要在兩個介面都建立 tunnel，並依對端 gateway 的介面配置正確連接。對端設備、電信線路和地端路由器是否同樣冗餘，仍要另外確認。只有兩條 tunnel，但最後都經過同一台設備和同一條線路，端到端仍可能只有一個故障點。

Classic VPN 還可能存在於舊環境，也支援部分靜態路由情境；新設計通常從 HA VPN 與 BGP 評估。不要只看到「VPN」就假設它符合 HA 拓撲，可依 HA VPN topologies 逐項核對。

Dedicated Interconnect

Dedicated Interconnect 讓客戶在支援的 colocation facility 直接連到 Google。適合能進駐或取得該設施線路、而且需要高容量與可預測網路路徑的組織。除了 Google 端 port，還要規劃 cross-connect、地端設備、VLAN attachment、Cloud Router 和備援位置。

不要用「流量超過某個數字就一定選 Dedicated」做決策。實際選擇還取決於設施可達性、交付期、電信合約、成長速度和所需 SLA topology。

Partner Interconnect

Partner Interconnect 透過支援的 service provider 連線，當公司無法直接到 Google colocation facility，或需要較彈性的 attachment capacity 時很實用。Google 的 SLA 範圍只涵蓋 Google VPC 到 provider network 的部分；provider 到客戶機房的服務品質與 SLA 要向供應商另外確認。

跨雲連線

若主要需求是另一個雲端到 Google Cloud 的直接私有連線，可以評估 Cross-Cloud Interconnect 或支援的 Partner Cross-Cloud Interconnect。它們不會自動解決所有多雲問題：

• 兩邊 CIDR 仍要避免重疊。
• DNS namespace、路由宣告與安全政策要協調。
• 兩家雲的區域和故障範圍不一定一一對應。
• 應用資料一致性與 failover 流程不是網路產品會替你完成的。

如果只是少量管理流量，HA VPN 可能已足夠；若需要大量穩定的跨雲資料交換，才進一步評估跨雲互連。完整類型可查 Cloud Interconnect overview。

flowchart TB
  Q["先量化容量、latency、<br/>交付期、加密、<br/>SLA 與責任邊界"] --> D{"主要連線情境？"}
  D -->|"快速建立／<br/>較小流量／<br/>需要 IPsec 備援"| V["HA VPN"]
  D -->|"可進 Google<br/>colocation<br/>且需要高容量"| I["Dedicated<br/>Interconnect"]
  D -->|"無法直接進<br/>colocation<br/>或要 provider 彈性"| P["Partner<br/>Interconnect"]
  D -->|"另一個 Cloud 到<br/>Google Cloud<br/>的大量私有流量"| C["Cross-Cloud<br/>Interconnect<br/>候選"]
  V --> H["再畫 peer gateway、<br/>tunnels、routers<br/>與 carrier 故障範圍"]
  I --> H
  P --> H
  C --> H
  H --> T["驗證端到端容量、<br/>加密範圍、路由收斂<br/>與實際 SLA"]

Interconnect 預設不代表端到端加密

Cloud Interconnect 的流量不走公共網際網路，但預設不等於已經做 IPsec 加密。若安全或法規要求在連線上加密，可依支援情況評估：

• HA VPN over Cloud Interconnect：在 VLAN attachment 上承載 IPsec tunnel。
• MACsec：保護支援的 Interconnect circuit 上，客戶路由器與 Google edge router 之間的鏈路。

兩者保護的範圍、支援條件和效能影響不同。設計文件要清楚寫「保護哪一段」，不能只在圖上放一個鎖頭。

Cloud Router：把學到的路由和宣告的路由分開看

Cloud Router 是受管理的 BGP control plane，不是流量一定會經過的一台虛擬路由器。除錯時先分成兩個方向：

1. Learned routes：對端透過 BGP 告訴 Google Cloud 哪些 prefix 可達。
2. Advertised routes：Cloud Router 告訴對端哪些 Google Cloud 或自訂 prefix 可達。

VPC 的 dynamic routing mode 會影響動態路由的套用範圍，也會影響預設 subnet advertisement 的區域範圍：

• Regional mode 讓學到的 dynamic routes 只套用在連線所在區域，預設也只宣告該區域的 subnet ranges。
• Global mode 讓學到的 dynamic routes 可套用到 VPC 的所有區域，預設 subnet advertisement 也可涵蓋所有區域，並考慮跨區域成本。

但「宣告哪些 prefix」還能在 Cloud Router 或個別 BGP session 改成 custom advertisement。也就是說，global mode 不等於無條件把所有路由都送出去，regional mode 也不妨礙你明確宣告自訂 prefix。排錯時應同時看 VPC routing mode、effective advertisements、peer advertisements、route priority 和 quotas。

flowchart TB
  subgraph CLOUD["Google Cloud control plane"]
    V["VPC subnet／<br/>custom prefixes"] --> A{"Default 或 Custom<br/>advertisements"}
    B["Cloud Router<br/>BGP control plane"] --> L["Learned routes"]
    L --> M{"VPC dynamic<br/>routing mode"}
    M -->|"Regional"| R["只套用於<br/>連線區域"]
    M -->|"Global"| G["可套用到<br/>VPC 各區域"]
    A --> B
  end
  B -->|"Advertised routes"| P["On-prem／<br/>Other cloud<br/>BGP peer"]
  P -->|"Peer<br/>advertisements"| B
  W["實際 workload<br/>packets"] -.->|"走 Google network<br/>與 attachment<br/>不是穿過<br/>Cloud Router VM"| P2["Hybrid<br/>data path"]

DNS 要設計查詢方向

混合環境最常見的情況是：雲端服務要解析地端名稱，地端系統也要解析 Google Cloud private zone。先把查詢方向拆開：

• Cloud 到地端：可用 forwarding zone，把指定 suffix 的查詢送到地端 DNS。
• 地端到 Cloud DNS：可使用 inbound forwarding，讓地端 resolver 把查詢送到 Cloud DNS inbound forwarder addresses。
• 跨 VPC 共用 private zone：可依管理邊界評估 DNS peering、authorized networks 或集中 DNS 架構。

DNS forwarding path 也需要路由和防火牆。正式切換前，除了測 dig，還要驗證多個 resolver 故障、TTL、negative caching、split-horizon 記錄和 DNSSEC 是否符合需求。

flowchart LR
  C["Cloud workload"] --> F["Cloud DNS forwarding zone<br/>指定 on-prem suffix"]
  F --> O["Outbound forwarding path"]
  O --> R["On-prem DNS resolvers"]
  U["On-prem workload"] --> R2["On-prem resolver<br/>指定 cloud private suffix"]
  R2 --> I["Cloud DNS inbound<br/>forwarder addresses"]
  I --> Z["Cloud DNS private zone"]
  P["Routes＋Firewall＋DNS policy"] -.-> O
  P -.-> I
  T["TTL／negative cache／split horizon<br/>與 resolver failover tests"] -.-> R
  T -.-> Z

Network Connectivity Center：管理多個 spoke

Network Connectivity Center（NCC）用 hub-and-spoke 模型集中管理連線。現在支援的 spoke 不只地端站點，還包括：

• VPC spokes 與 producer VPC spokes。
• 由 HA VPN tunnel、Interconnect VLAN attachment、router appliance 等組成的 hybrid spokes。
• Cross-Cloud Interconnect 等跨雲連線資源。
• NCC Gateway spokes 等其他支援類型。

NCC 可以簡化多 VPC 與 hybrid connectivity 的集中管理，但不是「掛上 hub 就全部傳遞」。Subnet routes、dynamic routes、static routes、IPv4／IPv6、site-to-site data transfer、import／export filter 都有各自的支援條件。拓撲和 route table 仍要按 NCC overview 驗證。

如果只有兩個獨立 VPC 需要互通，peering 可能已足夠；VPC 和站點數量增加、需要集中路由與分段時，NCC 的價值才會明顯。

高可用要從端到端畫故障範圍

拿一條 Interconnect，再加一組 VPN，不等於已經有獨立備援。請在架構圖標出：

• Google Cloud region、edge availability domain 與 VLAN attachment。
• Colocation facility、service provider 和 last-mile circuit。
• 地端機房、邊界路由器、電力與電信商。
• Cloud Router／BGP session、prefix 與 route priority。
• DNS resolver 和應用實際依賴的服務。

若主線與備線共享同一個 last mile，挖斷一條光纖就可能同時中斷。若備援路由平常從未被使用，切換時也可能才發現 prefix 沒宣告、MTU 不合或防火牆沒放行。

切換演練要觀察什麼？

1. 主路徑中斷後，BGP 多久撤回路由？
2. 備援路由多久生效？是否發生不對稱路由？
3. 既有連線會重建，還是應用會長時間卡住？
4. DNS 和健康檢查多久反映新路徑？
5. 備援容量能否承受尖峰，而不只是平常流量？
6. 復原主線時，流量切回是否穩定？

RTO 應該由實際演練得到，而不是從產品 SLA 推算。

flowchart TB
  B["記錄正常路徑、latency、<br/>prefix 與容量 baseline"] --> F["注入單一故障<br/>Circuit／Router／Site／Region"]
  F --> W["觀察 BGP withdrawal<br/>與備援路由生效時間"]
  W --> A["驗證 App reconnect、<br/>DNS、不對稱路由<br/>與備援容量"]
  A --> R["復原主線並觀察<br/>穩定切回"]
  R --> E["以實測收斂 RTO，<br/>修正 runbook 與拓撲"]
  E --> B

情境練習：兩個機房連兩個區域

假設公司在台北和新竹各有機房，Google Cloud 工作負載分布在台灣與另一個亞洲區域。正確的討論順序可以是：

1. 盤點正常、批次和災難切換流量，決定 Interconnect 類型與容量。
2. 依可靠性目標，把連線分散到適當的 edge availability domains、設備和電信路徑。
3. 依資料分類決定是否加上 HA VPN over Interconnect，而不是假設專線已加密。
4. 選擇 VPC dynamic routing mode，並明確列出每個 BGP session 要宣告和接收的 prefix。
5. 規劃地端與 Cloud DNS 的雙向解析，以及 resolver 故障時的行為。
6. 若 VPC、機房和其他雲的連線持續增加，再評估 NCC hub、spoke groups 與 filters。
7. 在上線前做斷線、設備故障、路由誤宣告和容量壓力測試。

這樣做的好處是，任何一個元件被問「為什麼需要」，都有需求和驗證方式可以回答。

15 分鐘演練判讀：備援線路通了，服務就恢復了嗎？

以下是虛構演練資料，容量與秒數只適用於本題，不是產品效能或 SLA 保證。主路徑中斷後，備援路徑的實測可用吞吐為 4 Gbps。流量數字均已換算為相同方向、同一瓶頸鏈路的需求，不必再換算雙向流量或協定開銷。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

營運規範要求降級時至少保留 30% 容量餘裕，也就是總需求不得超過可用吞吐的 70%。業務恢復目標為故障後 120 秒內。本次演練把「恢復」定義為核心 API 連續 30 秒達到約定成功率與延遲，完成觀察窗時才停止 RTO 計時。

演練紀錄如下，所有時間都從故障注入的 t = 0 起算：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

請寫出一份四項判讀，不必建立任何雲端資源：

1. 即使暫停批次，正常尖峰流量能否全部切到備援？差多少 Gbps？
2. 全部切到降級需求後，是否符合 30% 餘裕？還剩多少可分配容量？
3. 本次實測 RTO 是多少？是否達到目標？為什麼不能用 35 秒作答？
4. 提出一項縮短恢復時間的假設，以及一項確認主備獨立性的檢查。兩者都要寫出驗證方式。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• HA VPN 建了兩條 tunnel，就算高可用了嗎？還要確認哪些事？（回〈HA VPN〉）
• Cloud Interconnect 的流量不走公共網際網路，為什麼還不能當成已經加密？（回〈Interconnect 預設不代表端到端加密〉）
• Cloud Router 的 learned routes 和 advertised routes 各是哪個方向？VPC 的 dynamic routing mode 又會影響什麼？（回〈Cloud Router〉）

本課重點

• HA VPN 提供加密；是否符合高可用 SLA 取決於 tunnel 與 peer topology。
• Dedicated、Partner 和跨雲互連的選擇，要看設施、容量、交付、成本和責任邊界。
• Cloud Interconnect 流量不走公共網際網路，但預設不等於端到端加密。
• Cloud Router 要分開檢查 learned routes、advertised routes 和 route applicability。
• Dynamic routing mode 和 custom advertisements 是兩個相關但不同的控制面。
• NCC 能集中管理多種 VPC 與 hybrid spokes，但 route exchange 仍有限制。
• SLA 不能取代端到端故障分析與切換演練。

延伸閱讀

• Choosing a Network Connectivity product
• Cloud VPN overview
• Cloud Router advertised routes
• Network Connectivity Center overview

下一步

下一課會回到運算與儲存配置，練習怎麼替 GKE、Cloud Run 和 VM 設定擴縮、資源與儲存，而不是把預設值直接搬進生產環境。