My Awesome Project

Appearance

Hybrid Connectivity Routing — Thiết kế kết nối on-prem đạt SLA và failover tự động ​

Why this matters in production ​

Kết nối on-prem ↔ GCP là nơi routing gặp phần cứng và SLA hợp đồng. Đây cũng là nơi sai lầm tốn kém nhất: một thiết kế "trông có vẻ dư thừa" nhưng thực ra có SPOF ẩn sẽ đạt 99.9% trên giấy nhưng rớt toàn bộ kết nối khi một thiết bị đơn chết. Khác với các phần trước (thuần control plane), ở đây topology vật lý quyết định SLA, còn BGP chỉ là cơ chế chuyển hướng trên topology đó.

Mục tiêu file này: cho bạn mental model đúng về vì sao một topology đạt 99.99% còn topology khác chỉ 99.9%, và cơ chế nào (đã học ở file 04–05) thực sự thực hiện failover trên hạ tầng vật lý. Hiểu điều này là khác biệt giữa "tôi cấu hình hai tunnel nên chắc HA rồi" và "tôi biết chính xác cái gì chết thì cái gì tiếp quản, trong bao lâu".

Internal model — hai họ kết nối và vai trò Cloud Router ​

GCP có hai họ kết nối hybrid, khác nhau về bản chất vật lý nhưng giống nhau ở tầng routing (đều dùng Cloud Router + BGP):

                       VPC (prod) ──── Cloud Router (regional, control plane)
                            │                    │ BGP sessions
        ┌───────────────────┴───────────┐        │
        ▼                               ▼        ▼
   HA VPN gateway                 VLAN attachments (Interconnect)
   (2 interface, IPsec            (gắn vào Dedicated/Partner
    qua internet/backbone)         Interconnect, private fiber)
        │                               │
   tunnel x2+                      circuit vật lý
        │                               │
   on-prem VPN device(s)          on-prem router(s) tại colo
  • HA VPN: IPsec tunnel qua internet (hoặc qua backbone). Gateway có hai interface ở hai địa chỉ riêng → nền tảng cho dư thừa. SLA 99.99% khi cấu hình đúng topology.
  • Cloud Interconnect (Dedicated/Partner): kết nối fiber riêng giữa on-prem và edge của Google qua VLAN attachment. Băng thông lớn hơn, độ trễ thấp hơn, không qua internet công cộng.

Điểm hợp nhất quan trọng: ở tầng routing, cả hai đều "treo" các BGP session trên Cloud Router. Mọi cơ chế file 04–05 (timers, BFD, MED, ECMP, dynamic routing mode) áp dụng y hệt. Sự khác biệt SLA không nằm ở BGP mà ở cấu trúc dư thừa của lớp vật lý bên dưới BGP.

HA VPN: SLA đến từ topology, không từ "có hai tunnel" ​

HA VPN gateway có hai interface (interface 0, interface 1), mỗi cái một external IP. SLA 99.99% của HA VPN chỉ có hiệu lực khi bạn dựng tunnel theo topology dư thừa đúng. Theo tài liệu HA VPN, để đạt 99.99% cần:

  • Tunnel từ cả hai interface của HA VPN gateway,
  • Tới hai peer device on-prem (hoặc một device hỗ trợ hai đường độc lập),
  • Mỗi đường có BGP session riêng trên Cloud Router.

Mental model về vì sao: SLA là xác suất ít nhất một đường còn sống. Nếu cả hai tunnel đổ vào một thiết bị on-prem, thiết bị đó là SPOF → xác suất rớt bị chặn dưới bởi độ tin cậy của một thiết bị → không thể đạt 99.99% bất kể bạn có bao nhiêu tunnel. "Hai tunnel vào một router" là dư thừa giả — đây là sai lầm thiết kế phổ biến nhất.

   SAI (dư thừa giả, ~99.9% bị chặn bởi 1 device):
     HA VPN if0 ─tunnel─┐
     HA VPN if1 ─tunnel─┴──► [ 1 on-prem router ]   ← SPOF

   ĐÚNG (99.99%):
     HA VPN if0 ─tunnel──► [ on-prem router A ]
     HA VPN if1 ─tunnel──► [ on-prem router B ]

Cloud Interconnect: edge availability domain là đơn vị dư thừa ​

Với Dedicated Interconnect, đơn vị dư thừa vật lý là edge availability domain (EAD) — về cơ bản là các "metro availability zone" của điểm kết nối Google. Để đạt SLA cao, VLAN attachment phải nằm ở các EAD khác nhau (và lý tưởng là các metro khác nhau), mỗi attachment có Cloud Router + BGP session riêng:

  • 99.9% SLA: cấu hình tối thiểu dư thừa trong một metro (nhiều attachment, các EAD khác nhau).
  • 99.99% SLA: dư thừa qua hai metro + hai vùng on-prem, để một sự cố metro không hạ toàn bộ.

Một lần nữa, BGP không tạo ra SLA; phân bố vật lý qua EAD/metro tạo ra SLA. Cloud Router và BGP chỉ khai thác sự dư thừa đó bằng cách chuyển route khi một attachment chết.

Failover thực sự diễn ra thế nào: ghép các mảnh ​

Đây là nơi mọi thứ từ file 02–05 hợp lại thành một câu chuyện failover hoàn chỉnh. Giả sử thiết kế HA VPN đúng (hai đường tới A và B), cùng advertise prefix on-prem 192.168.0.0/16:

Trạng thái bình thường:
  Đường A: MED thấp  → dynamic route priority cao  (active)
  Đường B: MED cao   → dynamic route priority thấp (standby, ĐÃ program sẵn)
  → Andromeda forward 192.168.x qua đường A (route resolution: priority thấp thắng)

Cáp/đường A đứt:
  t0   BFD trên đường A phát hiện mất gói (sub-giây)
  t0+  BGP rút dynamic route của đường A khỏi VPC route collection
  t1   Route resolution (file 02) giờ chọn đường B (route standby đã sẵn sàng)
  t1   Andromeda reprogram → forward 192.168.x qua đường B
  Tổng: dưới một giây NẾU có BFD; tới 60–180s nếu chỉ dựa hold timer

Ba điều kiện để failover nhanh và đúng, mỗi điều kiện là một mảnh đã học:

  1. Route standby phải được program SẴN (cùng prefix, MED cao hơn) → Andromeda chỉ cần đổi lựa chọn, không cần học route mới. Đây là lý do advertise cùng prefix qua cả hai đường (file 05).
  2. Phát hiện lỗi phải nhanh → BFD (file 04), nếu không hold timer kéo failover lên hàng phút.
  3. Route resolution phải chọn đúng standby → hiểu preference category/priority (file 02); đừng để một static route che mất dynamic route standby.

Bài học tổng hợp: "Failover tự động" của hybrid không phải một tính năng bật/tắt — nó là sự cộng hưởng của topology vật lý dư thừa (lớp dưới) + route standby program sẵn (file 05) + phát hiện lỗi nhanh bằng BFD (file 04) + route resolution chọn đúng (file 02). Thiếu bất kỳ mảnh nào, "HA" chỉ là ảo tưởng.

ECMP qua nhiều tunnel: tăng throughput tổng, không tăng một flow ​

Nếu thay vì active/standby, bạn muốn dùng cả hai đường đồng thời, hãy advertise cùng prefix với cùng MED → hai dynamic route cùng priority → ECMP (file 02). Như đã nói ở file 02, ECMP là hash theo flow:

  • Tổng throughput ≈ tổng băng thông các tunnel (qua nhiều flow).
  • Một flow vẫn bị giới hạn ở một tunnel (và trần ~3 Gbps/tunnel của HA VPN).

Để vượt trần một flow, bạn cần Interconnect băng thông cao hơn, không phải thêm tunnel VPN. Đây là lý do thiết kế throughput phải xuất phát từ phân bố flow thực tế của ứng dụng, không phải con số tổng.

Constraints, trade-offs & failure modes ​

Dư thừa giả: SPOF ẩn sau "hai tunnel" ​

Failure mode số một: topology nhìn dư thừa nhưng hội tụ về một thiết bị/một metro/một EAD. SLA thực bị chặn bởi thành phần đơn lẻ đó. Phòng tránh: vẽ topology tới tận thiết bị vật lý và hỏi "cái gì chết thì mất mấy đường" cho từng thành phần (gateway interface, tunnel, on-prem device, EAD, metro, fiber path). Nếu một thành phần chết làm mất cả hai đường, đó là SPOF.

VPN qua internet ⇒ BFD phải khoan dung hơn ​

HA VPN chạy IPsec qua internet công cộng có jitter/loss cao hơn fiber. BFD interval quá nhặt → false positive → flap. Cân chỉnh BFD theo chất lượng thật của đường: Interconnect (fiber ổn định) chịu được BFD nhặt; VPN-qua-internet cần multiplier/interval khoan dung hơn để tránh báo động giả. Đây là trade-off giữa tốc độ failover và độ ổn định.

MTU & fragmentation trên IPsec ​

IPsec thêm overhead header → MTU hiệu dụng của HA VPN nhỏ hơn (~1460 hoặc thấp hơn). Ứng dụng gửi packet lớn với DF set, hoặc on-prem MTU không khớp, gây PMTUD đen (packet bị rớt im lặng) → "kết nối lúc được lúc không, file lớn fail còn ping được". Đây là failure mode datapath, không phải BGP — nhưng hay bị đổ lỗi cho BGP. Khớp MTU end-to-end và bật MSS clamping ở on-prem.

Tromboning khi global mode + nhiều region ​

Như file 05, global dynamic routing có thể khiến traffic từ region X đi vòng ra on-prem qua Cloud Router region Y nếu inter-region cost/MED không được cân nhắc. Trên hạ tầng hybrid, tromboning không chỉ tăng latency mà còn tăng chi phí inter-region egress và dồn tải lên một kết nối vật lý. Thiết kế kết nối hybrid ở mỗi region (regional mode) thường sạch hơn cho topology lớn.

Anti-pattern: "hai tunnel là đủ HA" ​

  • Vì sao xảy ra: đếm số tunnel thay vì truy nguyên SPOF vật lý; tin rằng dư thừa ở tầng tunnel tự động cho SLA cao.
  • Hệ quả ở scale: SLA hợp đồng không đạt; một sự cố thiết bị on-prem đơn hoặc một EAD hạ toàn bộ kết nối dù "có hai tunnel"; sự cố chỉ lộ ra khi đã muộn.
  • Cách tư duy đúng: SLA = thuộc tính của topology vật lý dư thừa thật (hai interface → hai thiết bị → hai EAD/metro), không phải số tunnel. BGP/BFD chỉ khai thác dư thừa đó. Luôn map tới thiết bị vật lý và xác định "cái gì chết thì mất bao nhiêu đường".

GCP-native implementation guidance ​

bash
# HA VPN gateway (2 interface) — nền tảng dư thừa
gcloud compute vpn-gateways create ha-vpn-gw \
  --network=prod-vpc --region=us-central1

# Hai tunnel từ hai interface tới HAI peer on-prem khác nhau (A và B)
gcloud compute vpn-tunnels create tun-to-A \
  --peer-gcp-gateway=... --interface=0 --region=us-central1 \
  --vpn-gateway=ha-vpn-gw --ike-version=2 --shared-secret=... \
  --router=cr-us-central1
gcloud compute vpn-tunnels create tun-to-B \
  --interface=1 --region=us-central1 \
  --vpn-gateway=ha-vpn-gw --ike-version=2 --shared-secret=... \
  --router=cr-us-central1

# Trên Cloud Router: BGP peer cho mỗi tunnel, BFD bật, MED phân biệt active/standby
#   (peer A: advertised-route-priority thấp = active; peer B: cao = standby)
# Xem lại file 04 (BFD) và file 05 (MED/advertisement).

Sau khi dựng, xác minh failover thật: hạ một tunnel (gcloud compute vpn-tunnels delete ở môi trường test, hoặc rút BGP) và quan sát thời gian route chuyển + traffic phục hồi qua Connectivity Tests / monitoring. "Cấu hình xong" không bằng "đã chứng minh failover hoạt động".

Tóm tắt mental model ​

  • Hai họ kết nối (HA VPN, Cloud Interconnect) khác ở lớp vật lý nhưng giống ở tầng routing (đều Cloud Router + BGP).
  • SLA đến từ topology vật lý dư thừa thật (hai interface → hai thiết bị → hai EAD/metro), không từ số tunnel hay cấu hình BGP. "Hai tunnel vào một router" = dư thừa giả.
  • Failover tự động = cộng hưởng của: route standby program sẵn (cùng prefix, MED cao hơn) + BFD (phát hiện nhanh) + route resolution chọn đúng. Thiếu một mảnh ⇒ HA ảo.
  • ECMP qua tunnel (cùng MED) tăng throughput tổng qua nhiều flow, không tăng một flow đơn.
  • MTU/IPsec overhead là sát thủ datapath thầm lặng; tromboning là rủi ro của global mode trên hybrid.

References ​