跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
跳到課程內容
網路架構設計 混合連線與多雲網路
0%
8 / 25 進階 30 分鐘 00:00

混合連線與多雲網路

從容量、加密、路由、DNS 與故障範圍，設計可驗證的地端與多雲連線

2026年3月13日 Updated: 2026年7月17日

專線不是混合網路的全部

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

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

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

兩座機房、兩條異質連線、冗餘路由器與跨雲故障切換的端到端拓撲圖

圖解：混合網路的高可用必須跨越機房、電信路徑、路由器與雲端區域；當其中一條路徑失效，路由與 DNS 也要能把流量導向仍健康的端點。

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

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。

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。

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 是否符合需求。

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 推算。

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

假設公司在台北和新竹各有機房，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. 在上線前做斷線、設備故障、路由誤宣告和容量壓力測試。

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

本課檢查清單

  • 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 不能取代端到端故障分析與切換演練。

延伸閱讀

下一步

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

徽章解鎖！