Cloud Router Architecture — Tại sao Cloud Router không nằm trên đường đi packet

Why this matters in production

Khi một kỹ sư lần đầu thấy "Cloud Router", bản năng on-prem mách bảo họ rằng đây là một con router ảo: traffic đi qua nó, nó có throughput giới hạn, nếu nó nghẽn thì mạng nghẽn, nếu nó chết thì mạng chết. Mọi câu trong câu trên đều sai. Và vì chúng sai, các quyết định dựa trên chúng cũng sai:

• Đội vận hành panic khi thấy Cloud Router "restart" trong maintenance, tưởng traffic on-prem vừa rớt — trong khi datapath chưa hề bị động.
• Kỹ sư cố "scale up Cloud Router để tăng throughput VPN" — một việc vô nghĩa vì Cloud Router không forward byte nào.
• Thiết kế HA bị đặt sai chỗ: người ta lo dư thừa Cloud Router trong khi điểm yếu thật nằm ở BGP session và tunnel.

Hiểu đúng Cloud Router là một dịch vụ control-plane được quản lý — cụ thể là một BGP speaker phân tán, có tính sẵn sàng cao, chỉ làm nhiệm vụ học và công bố route rồi program chúng vào VPC — sẽ định vị lại toàn bộ các mối lo trên về đúng chỗ. Đây là điều file này xây dựng.

Internal model — Cloud Router làm gì và không làm gì

Tuyên bố nền tảng: control plane only

Theo tài liệu Cloud Router, phát biểu chính xác là: "Cloud Router không cung cấp khả năng routing hay forwarding packet. Andromeda xử lý toàn bộ packet routing và forwarding, còn Cloud Router quản lý các BGP session tương ứng."

Hãy đọc câu này thật kỹ vì nó đảo ngược mental model on-prem. Phân rã trách nhiệm:

        CLOUD ROUTER (control plane)            ANDROMEDA (data plane)
        ──────────────────────────              ──────────────────────
   • Mở & duy trì BGP session với peer     • Forward MỌI packet ở wire speed
   • Nhận BGP UPDATE → học prefix          • Encapsulate/decapsulate
   • Công bố (advertise) prefix của VPC    • Thực thi forwarding state đã
     ra peer                                  được program
   • Chạy thuật toán chọn BGP path         • KHÔNG hỏi Cloud Router cho
   • PROGRAM route đã chọn vào VPC            từng packet
     (đẩy vào control-plane collection)
   • KHÔNG chạm vào packet của user

Cloud Router giống một route server / BGP controller hơn là một router theo nghĩa truyền thống. Nó nói BGP với thế giới bên ngoài, dịch kết quả thành các Route resource của VPC, và để Andromeda — datapath thực sự — lo việc bê từng packet. Một byte traffic của bạn không bao giờ đi qua Cloud Router.

Hệ quả #1: Cloud Router không có "throughput"

Vì không byte traffic nào đi qua nó, Cloud Router không có khái niệm bandwidth/throughput của riêng nó. Throughput của kết nối hybrid được quyết định bởi:

• Băng thông của tunnel/attachment: ví dụ HA VPN tunnel có trần ~3 Gbps mỗi tunnel; VLAN attachment của Dedicated/Partner Interconnect có capacity theo cấu hình (50 Mbps → 50 Gbps).
• Băng thông egress của VM và của fabric.

"Tăng throughput VPN" nghĩa là thêm tunnel/attachment và để ECMP chia tải (xem file 06) — không phải động vào Cloud Router. Đặt câu hỏi "Cloud Router của tôi chịu được bao nhiêu Gbps" là đặt sai câu hỏi; con số đúng cần hỏi là số BGP peer, số route prefix, và số BGP session mà nó quản lý — đó mới là các đại lượng control-plane mà Cloud Router thực sự bị giới hạn.

Hệ quả #2: Cloud Router fail không lập tức làm rớt traffic

Đây là điểm vận hành quan trọng nhất. Vì datapath (Andromeda) thực thi forwarding state đã được program từ trước, nếu control plane (Cloud Router) tạm thời gián đoạn:

• Forwarding state đã program vẫn còn đó và Andromeda vẫn forward theo nó.
• Traffic đang chạy không rớt chỉ vì Cloud Router mất một nhịp — miễn là graceful restart được bật để giữ route trong cửa sổ restart.

Theo best practices, Google khuyến nghị bật graceful restart trên thiết bị BGP on-prem: "với graceful restart, traffic giữa các mạng không bị gián đoạn khi Cloud Router hoặc thiết bị BGP on-prem gặp lỗi, miễn là BGP session được tái lập trong khoảng graceful restart". Cơ chế: khi BGP control plane khởi động lại, peer giữ nguyên các route đã học (đánh dấu stale) thay vì rút ngay, cho datapath tiếp tục forward trong lúc session được dựng lại. Nếu thiết bị peer không hỗ trợ/ bật graceful restart, Google khuyến nghị cấu hình hai thiết bị BGP on-prem, mỗi cái một tunnel để dự phòng — nghĩa là điểm dư thừa đúng nằm ở session/tunnel, không phải ở chỗ "thêm Cloud Router".

Mental model: Cloud Router là "bộ não" cập nhật bản đồ; Andromeda là "đôi chân" đi theo bản đồ. Bộ não chợp mắt một nhịp không làm đôi chân ngã, miễn bản đồ cũ còn dùng được (graceful restart) trong lúc bộ não tỉnh lại.

HA nội tại: Cloud Router không phải một process đơn

Cloud Router là một dịch vụ được quản lý, có tính sẵn sàng cao theo thiết kế — nó không phải một VM hay một process đơn lẻ mà bạn phải tự lo HA. Về mặt triển khai, mỗi Cloud Router được hiện thực bằng một cặp software task dư thừa trong vùng điều khiển của Google: nếu một task gặp sự cố, task kia tiếp quản BGP session mà không cần bạn can thiệp. Bạn không "scale" hay "patch" Cloud Router; Google vận hành nó như một control-plane service.

Điều này định hình lại tư duy HA: bạn không thiết kế dư thừa cho bản thân Cloud Router (Google đã làm). Bạn thiết kế dư thừa cho những thứ ngoài tầm quản lý của Google:

• BGP session: dùng nhiều session (nhiều interface/peer IP) để một session down không mất hết route.
• Tunnel/attachment vật lý: dùng HA VPN (2 interface) hoặc nhiều VLAN attachment ở các edge availability domain khác nhau.
• Thiết bị on-prem: nhiều router on-prem để tránh SPOF phía bạn.

Regional scope: vì sao quan trọng cho thiết kế

Cloud Router là regional resource. Một Cloud Router sống trong đúng một region và quản lý các BGP session gắn với tài nguyên hybrid (HA VPN gateway, VLAN attachment) của region đó. Hệ quả kết hợp với file 01:

• Route mà Cloud Router ở region X học được, theo mặc định (regional dynamic routing), chỉ được program vào VM trong region X.
• Để on-prem reachable từ nhiều region, bạn hoặc đặt một Cloud Router + kết nối hybrid ở mỗi region, hoặc bật global dynamic routing để route học ở một region được program ra mọi region (chi tiết ở file 05).

Sự "regional" này không mâu thuẫn với việc VPC global. Nó phản ánh đúng kiến trúc: kết nối vật lý (tunnel, interconnect) gắn với một region cụ thể (nơi có edge/PoP), nên BGP speaker quản lý kết nối đó cũng regional. Cái global là phạm vi program route (do dynamic routing mode quyết định), không phải bản thân Cloud Router.

Vòng đời "học → chọn → program" của một route động

Ghép Cloud Router vào mô hình control-plane của file 01:

On-prem router                Cloud Router (control plane)         VPC (control-plane collection)        Andromeda (datapath)
     │  BGP UPDATE                     │                                    │                                   │
     │  prefix 192.168.0.0/16  ──────► │                                    │                                   │
     │  AS_PATH, MED, communities      │ (1) nhận UPDATE                    │                                   │
     │                                 │ (2) chạy BGP best-path             │                                   │
     │                                 │     (chọn 1 path nếu nhiều)        │                                   │
     │                                 │ (3) dịch thành Route resource:     │                                   │
     │                                 │     dest=192.168.0.0/16            │                                   │
     │                                 │     priority = f(MED)             │                                   │
     │                                 │     type=dynamic                  │                                   │
     │                                 │ (4) PROGRAM ──────────────────────►│ (5) thêm vào route collection     │
     │                                 │                                    │ (6) tính forwarding state ───────►│ (7) program vào host
     │                                 │                                    │                                   │     → VM bắt đầu reach 192.168.x

Bước (2) — BGP best-path selection — đáng nhấn mạnh: khi nhiều peer cùng advertise một prefix, Cloud Router chọn một (hoặc nhiều, nếu đủ điều kiện multipath) theo thuộc tính BGP (AS_PATH length, MED...) trước khi program vào VPC. Việc chọn này xảy ra ở control plane Cloud Router, tách biệt với bước route resolution của VPC (file 02) áp lên forwarding của VM. Hai tầng selection khác nhau: Cloud Router chọn BGP path để biến thành VPC route; VPC route resolution chọn route nào thắng khi forward một packet.

Constraints, trade-offs & failure modes

Giới hạn là giới hạn control-plane, không phải throughput

Các giới hạn thực tế của Cloud Router đều mang bản chất control-plane:

• Số dynamic route prefix học/program: có quota (mặc định ở mức hàng nghìn mỗi Cloud Router/VPC, nâng được qua support). Vượt → ngừng học prefix mới → mất reachability một phần (xem file 01).
• Số BGP peer / BGP session mỗi Cloud Router: có trần.
• Tần suất cập nhật: BGP flapping (session up/down liên tục) tạo recompute + reprogram dồn dập, gây bất ổn — không phải vì "router quá tải byte" mà vì control plane phải hội tụ lại liên tục.

Khi capacity-planning, hãy đếm prefix, peer, session, đặt alerting trên metric số prefix (Google khuyến nghị cụ thể điều này), và summarize route ở on-prem để ở dưới quota prefix.

Graceful restart vs BFD: hai cơ chế giải hai bài toán khác nhau

Hai cơ chế hay bị nhầm:

• Graceful restart bảo vệ traffic khi control plane khởi động lại (giữ route stale, không rút vội). Nó tăng tính chịu lỗi của control plane.
• BFD (Bidirectional Forwarding Detection) phát hiện đứt liên kết datapath nhanh hơn nhiều so với BGP hold timer, để rút route nhanh khi đường thực sự chết.

Chúng đối nghịch về mục tiêu (một cái "đừng vội rút", một cái "rút thật nhanh") nhưng bổ sung nhau: graceful restart cho lỗi control-plane lành tính, BFD cho lỗi datapath thật. File 04 đi sâu cả hai.

Đặt HA sai chỗ là failure mode về tư duy

Failure mode phổ biến không phải kỹ thuật mà là kiến trúc: đội ngũ dồn công sức "làm HA cho Cloud Router" (Google đã lo) trong khi để hở SPOF thật ở tunnel đơn, thiết bị on-prem đơn, hoặc một BGP session duy nhất. Kết quả: tốn công vào chỗ không cần, hở chỗ cần.

Anti-pattern: coi Cloud Router như một datapath appliance

• Vì sao xảy ra: ánh xạ thẳng "router" trong tên gọi sang mental model router vật lý on-prem.
• Hệ quả ở scale: (1) capacity-planning sai (lo throughput của thứ không forward byte nào); (2) HA đặt sai chỗ; (3) phản ứng sự cố sai (panic khi control plane restart dù datapath ổn); (4) bỏ lỡ các giới hạn thật (prefix/peer/session quota) cho tới khi chạm trần và mất reachability một phần.
• Cách tư duy đúng: Cloud Router = BGP controller được quản lý, control-plane-only. Throughput là chuyện của tunnel/attachment + Andromeda. HA của bản thân nó do Google lo; HA của kết nối là việc của bạn (session, tunnel, thiết bị on-prem dư thừa). Giới hạn của nó là prefix/peer/session, không phải Gbps.

GCP-native implementation guidance

# Tạo Cloud Router (regional). ASN private 16-bit cho phía Google.
gcloud compute routers create cr-us-central1 \
  --network=prod-vpc --region=us-central1 \
  --asn=64512

# Trạng thái control-plane: BGP peer up/down, số prefix nhận/gửi
gcloud compute routers get-status cr-us-central1 --region=us-central1 \
  --format="table(result.bgpPeerStatus[].name,
                  result.bgpPeerStatus[].state,
                  result.bgpPeerStatus[].numLearnedRoutes)"

# Bật BFD + graceful restart phụ thuộc cấu hình BGP peer (xem file 04)

Lưu ý: get-status là cửa sổ nhìn vào control plane của Cloud Router (session state, learned/advertised prefix). Để xác minh datapath thực sự forward đúng, vẫn dùng Connectivity Tests — vì Cloud Router không phải datapath, "BGP UP" không tự động đảm bảo packet thông (firewall, route resolution vẫn có thể chặn).

Tóm tắt mental model

• Cloud Router là control-plane-only: học/công bố route và program chúng vào VPC; Andromeda mới forward packet. Không byte traffic nào qua Cloud Router.
• Vì vậy Cloud Router không có throughput; băng thông là chuyện của tunnel/attachment + fabric.
• Cloud Router gián đoạn không lập tức rớt traffic nhờ forwarding state đã program + graceful restart.
• Cloud Router HA nội tại (cặp software task do Google vận hành). Bạn lo dư thừa cho session/tunnel/thiết bị on-prem, không phải cho bản thân Cloud Router.
• Là regional resource; phạm vi program route ra ngoài region do dynamic routing mode quyết định.
• Giới hạn thật là prefix/peer/session (control-plane), không phải Gbps.

References

• Cloud Router Overview — control-plane-only, Andromeda forward, graceful restart, redundancy, MP-BGP, alerting quota prefix
• Cloud Router — BGP — best-path, MED, communities
• HA VPN topologies — dư thừa tunnel/session đúng chỗ
• Andromeda (USENIX NSDI '18) — datapath forward, tách control/data plane