Kiến Trúc VPC Global-Regional — Andromeda SDN và Mô Hình Mạng Ảo của GCP
Tại sao VPC của GCP khác về bản chất
Khi chuyển từ AWS hoặc Azure sang GCP, sai lầm phổ biến nhất của các engineer là áp dụng mental model cũ vào VPC. Trên AWS, VPC là tài nguyên regional — bạn tạo một VPC cho us-east-1, một VPC khác cho eu-west-1. Trên GCP, một VPC tồn tại ở cấp global và subnet mới là tài nguyên regional. Điều này không đơn thuần là sự khác biệt về API — nó phản ánh kiến trúc SDN (Software-Defined Networking) hoàn toàn khác biệt phía dưới.
Hiểu được lý do thiết kế này — tại sao Google chọn global VPC thay vì regional VPC — là chìa khóa để thiết kế hệ thống đúng và tránh những lỗi không thể gỡ lỗi được.
Internal Model: Andromeda và Jupiter
GCP triển khai VPC bằng Andromeda, stack SDN độc quyền của Google. Andromeda không phải là một thiết bị vật lý trung tâm — nó là một lớp phần mềm chạy phân tán trên mỗi máy chủ vật lý trong data center của Google.
Mỗi VM khi khởi động được cấp một virtual network interface (vNIC) ảo được quản lý bởi Andromeda agent trên hypervisor của máy host. Khi VM gửi một gói tin, Andromeda agent trên host intercept gói tin đó và quyết định:
- Gói tin này thuộc VPC nào? Subnet nào?
- Route nào phù hợp nhất cho destination?
- Firewall rules có cho phép gói tin này không?
- Gói tin được forward đến đâu (next hop)?
Điểm quan trọng: Toàn bộ quá trình này diễn ra tại hypervisor, không phải tại một thiết bị routing trung tâm. Đây là kiến trúc distributed forwarding — mỗi host chạy một phần của "router" VPC.
Andromeda hoạt động trên nền tảng mạng vật lý Jupiter — fabric mạng spine-leaf được Google thiết kế riêng. Jupiter cung cấp băng thông cao và độ trễ thấp giữa các máy chủ trong cùng data center, còn Andromeda cung cấp lớp trừu tượng mạng ảo phía trên.
┌─────────────────────────────────────────────────────────────────────┐
│ VM (Guest OS) │
│ eth0: 10.0.1.5 (IP được cấp bởi DHCP của GCP) │
├─────────────────────────────────────────────────────────────────────┤
│ Andromeda Agent (Hypervisor) │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Lookup route table → Forward đến next-hop │ │
│ │ Kiểm tra firewall rules (stateful) │ │
│ │ Anti-spoofing check (IP nguồn phải khớp với VM IP) │ │
│ │ Encapsulate gói tin → gửi qua Jupiter fabric │ │
│ └──────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ Jupiter Fabric (Mạng vật lý spine-leaf) │
│ Gói tin được truyền đến host đích (có thể cùng hoặc khác region) │
└─────────────────────────────────────────────────────────────────────┘Control Plane và Data Plane
Andromeda tách biệt rõ ràng control plane và data plane:
Control Plane (GCP API): Khi bạn tạo một route mới hay thay đổi firewall rule, GCP control plane nhận lệnh, validate, lưu vào hệ thống lưu trữ trung tâm, và sau đó lan truyền (propagate) cấu hình mới này tới tất cả các Andromeda agent đang chạy trong VPC đó.
Data Plane (Andromeda agent): Mỗi agent lưu một bản sao local của route table và firewall rules. Packet forwarding được thực hiện hoàn toàn tại local — không cần round-trip về control plane cho mỗi gói tin.
Đây là lý do tại sao GCP có thể đạt được độ trễ sub-55 microsecond cho cùng zone, và tại sao firewall rule thay đổi không có hiệu lực ngay lập tức trên toàn thế giới — control plane phải propagate thay đổi đến hàng nghìn Andromeda agent trước khi data plane cập nhật.
VPC là Global Resource: Cơ chế và Hệ quả
GCP lưu trữ cấu hình VPC (routing table, firewall rules, subnet definitions) trong một distributed storage system toàn cầu. Không có khái niệm "VPC region" — cùng một VPC object tồn tại và có thể được đọc từ bất kỳ GCP region nào.
Khi bạn tạo một VPC:
gcloud compute networks create prod-vpc --subnet-mode=customGCP tạo ra một network object với:
- Một ID duy nhất toàn cầu
- Một route table trống (chưa có subnet routes)
- Hai implied firewall rules (deny-all ingress + allow-all egress)
- Không có subnet nào (với custom mode)
Object này được replicate across GCP's control plane infrastructure. Không có region nào "sở hữu" VPC này.
Tại sao Google chọn Global VPC?
Lý do kỹ thuật cốt lõi: Jupiter fabric của Google kết nối các data center trong cùng region với băng thông cực cao và độ trễ cực thấp. Đối với intra-region traffic, Andromeda có thể forward packets trực tiếp qua Jupiter mà không cần routing qua nhiều hops.
Mô hình global VPC cho phép:
- Một bộ routing table duy nhất kiểm soát traffic trong toàn bộ VPC, không cần sync giữa nhiều regional routing tables
- Một firewall policy áp dụng nhất quán trên toàn cầu
- Cross-region routing tự động — VM ở us-west1 có thể giao tiếp với VM ở europe-west1 trong cùng VPC mà không cần peering hay gateway
Đây là khác biệt căn bản so với AWS: trên AWS, để VM ở us-east-1 giao tiếp với VM ở eu-west-1, bạn phải thiết lập VPC Peering hoặc Transit Gateway. Trên GCP, chúng đã trong cùng VPC.
Subnet là Regional Resource: Internal Model
Mỗi subnet được gắn với một region cụ thể và có primary CIDR range không được trùng với bất kỳ subnet nào khác trong cùng VPC.
Khi bạn tạo subnet:
gcloud compute networks subnets create prod-us-west1 \
--network=prod-vpc \
--region=us-west1 \
--range=10.0.0.0/20GCP tạo ra:
- Một subnet route (
10.0.0.0/20 → local) được tự động thêm vào VPC routing table - Một DHCP service regional cho subnet này
- Reservation cho 4 địa chỉ đặc biệt trong CIDR: network address, default gateway, second-to-last address (dành riêng cho Google), broadcast address
Quan trọng: Một subnet gắn với region, nhưng VM trong bất kỳ zone nào của region đó có thể sử dụng subnet. us-west1 có 3 zones (us-west1-a, b, c) — tất cả đều share cùng subnet 10.0.0.0/20.
Region: us-west1
├── us-west1-a: VM có thể dùng 10.0.0.0/20 ✓
├── us-west1-b: VM có thể dùng 10.0.0.0/20 ✓
└── us-west1-c: VM có thể dùng 10.0.0.0/20 ✓
→ Subnet KHÔNG = AZ. Subnet = Region.Đây là điểm mà nhiều AWS engineer nhầm lẫn. Trên AWS, subnet gắn với một Availability Zone cụ thể. Trên GCP, subnet gắn với region và span tất cả zones trong region đó.
Tại sao GCP chọn Regional Subnet thay vì Zone-level Subnet?
Nếu subnet là zone-level (như AWS), để triển khai HA trong 3 zones, bạn phải tạo 3 subnets riêng biệt và quản lý 3 CIDR ranges. Với regional subnet, một subnet phục vụ cả 3 zones — đơn giản hóa đáng kể việc thiết kế high availability.
Tuy nhiên, trade-off là bạn không thể cô lập CIDR theo zone. Nếu cần zone-level isolation, phải dùng nhiều subnets trong cùng region.
Lập Kế Hoạch CIDR: Hệ Quả của Global Uniqueness
Vì tất cả subnet trong một VPC phải có CIDR không trùng nhau — và VPC là global — bạn phải lập kế hoạch CIDR toàn cầu ngay từ đầu.
Tại sao không thể tái sử dụng CIDR?
Andromeda agent cần một route table nhất quán. Nếu hai subnets trong cùng VPC có cùng CIDR 10.0.0.0/20, Andromeda không thể xác định gói tin đến 10.0.1.5 thuộc subnet nào — đây là ambiguity không thể giải quyết được ở data plane.
# VÍ DỤ SAI - không thể tạo trong GCP:
Subnet us-west1: 10.0.0.0/20
Subnet europe-west1: 10.0.0.0/20 ← CONFLICT! GCP sẽ từ chối
# VÍ DỤ ĐÚNG - global CIDR planning:
Subnet us-west1: 10.0.0.0/20
Subnet us-central1: 10.0.16.0/20
Subnet europe-west1: 10.1.0.0/20
Subnet asia-northeast1: 10.2.0.0/20Đây là trade-off quan trọng so với AWS: trên AWS, bạn có thể dùng 10.0.0.0/16 cho VPC ở us-east-1 và cũng dùng 10.0.0.0/16 cho VPC ở eu-west-1 vì chúng là 2 VPCs riêng biệt (regional isolation). Trên GCP, một VPC là global nên CIDR phải unique trong VPC đó.
Template Lập Kế Hoạch CIDR cho Production
Một cách tiếp cận có hệ thống cho tổ chức với đa region và đa environment:
Tổng không gian: 10.0.0.0/8 (16 triệu IPs)
Phân bổ theo Environment:
Production: 10.0.0.0/10 (4M IPs: 10.0.0.0 - 10.63.255.255)
Staging: 10.64.0.0/10 (4M IPs: 10.64.0.0 - 10.127.255.255)
Development: 10.128.0.0/10 (4M IPs: 10.128.0.0 - 10.191.255.255)
Reserved: 10.192.0.0/10 (4M IPs: cho tương lai)
Trong Production (10.0.0.0/10), phân bổ theo Region:
us-west1: 10.0.0.0/14 (262K IPs)
us-central1: 10.4.0.0/14
us-east1: 10.8.0.0/14
europe-west1: 10.16.0.0/14
europe-north1: 10.20.0.0/14
asia-northeast1: 10.32.0.0/14
asia-southeast1: 10.36.0.0/14
[reserved for new regions]
Trong mỗi Region (ví dụ us-west1 = 10.0.0.0/14), phân bổ theo Tier:
Primary nodes: 10.0.0.0/16 (65K IPs cho VMs)
GKE pods: 10.1.0.0/16 (65K IPs - secondary range)
GKE services: 10.2.0.0/20 (4K service CIDRs)
Reserved/future: 10.3.0.0/16Điều quan trọng là phải dành trước không gian cho:
- GKE secondary ranges (pods và services cần riêng)
- Regions mới mà GCP sẽ mở trong tương lai
- Môi trường mới hoặc workloads mới
- Failover VPC (nếu dùng DR strategy với secondary VPC)
Route Table: Global, Phân tán, Không Có Thiết Bị Vật Lý
Route table của GCP VPC là một abstraction logic — không có router vật lý nào lưu trữ nó. Thay vào đó:
- GCP control plane lưu route table như một distributed database
- Andromeda agents trên từng host nhận bản copy của routing information
- Khi VM gửi gói tin, Andromeda agent trên host của VM thực hiện route lookup locally
Mô hình phân tán của Route Table:
GCP Control Plane (Global):
Route: 10.0.0.0/20 → local (subnet us-west1)
Route: 10.1.0.0/20 → local (subnet europe-west1)
Route: 0.0.0.0/0 → default-internet-gateway
↓ Propagate xuống từng host
Host A (us-west1-a):
Local copy of route table: [tất cả routes trên]
→ VM trên host A gửi gói tin đến 10.1.0.5
→ Andromeda trên host A lookup: route 10.1.0.0/20 → local
→ Andromeda encapsulate và gửi qua Google backbone đến host của VM đích
Host B (europe-west1-b):
Local copy of route table: [tất cả routes trên]
→ Andromeda nhận gói tin, decapsulate, deliver đến VM đíchTài liệu GCP xác nhận: "There is no physical device that's assigned to the network." Đây là pure software routing, được implement bởi Andromeda trên mỗi hypervisor.
Firewall Enforcement Point
Tương tự route, firewall không phải là một appliance. Firewall rules được enforce tại network interface level của từng VM, bởi Andromeda agent.
Điều này có hệ quả quan trọng:
- Firewall được enforce ngay tại source VM (cho egress) và tại destination VM (cho ingress)
- Traffic giữa 2 VMs trong cùng subnet vẫn đi qua firewall enforcement
- Không có "bypass" firewall bằng cách traffic không đi qua thiết bị trung tâm
VM A gửi gói tin đến VM B (cùng VPC, khác region):
VM A (us-west1)
↓
[Andromeda trên Host A]
Kiểm tra egress firewall rules của VM A
Nếu bị deny → drop gói tin ngay tại đây
Nếu allow → encapsulate, gửi qua Google backbone
↓
[Google Private Backbone Network]
↓
[Andromeda trên Host B]
Kiểm tra ingress firewall rules của VM B
Nếu bị deny → drop gói tin
Nếu allow → deliver đến VM B
↓
VM B (europe-west1)Eventual Consistency: Vùng Nguy Hiểm Ẩn
Khi bạn thay đổi route hay firewall rule, GCP control plane cập nhật distributed database và bắt đầu propagate thay đổi đến tất cả Andromeda agents trong VPC. Quá trình này là eventual consistent — không phải atomic và không phải instant.
Theo tài liệu GCP, "Policies are eventually consistent; hierarchy changes may take minutes to propagate."
Kịch Bản Nguy Hiểm: Race Condition trong Security Changes
Thời gian 0: Admin xóa firewall rule block-external-access
(cho phép ingress từ 0.0.0.0/0 đến service X)
Thời gian +100ms: Andromeda agents ở us-west1 cập nhật
→ VMs ở us-west1 đã bị expose
Thời gian +200ms: Andromeda agents ở us-central1 cập nhật
→ VMs ở us-central1 đã bị expose
Thời gian +500ms: Andromeda agents ở europe-west1 cập nhật
...
Kết quả: Trong khoảng 100-500ms (hoặc lâu hơn cho VPCs lớn),
trạng thái firewall KHÔNG ĐỒNG NHẤT giữa các region.
Scanners bên ngoài có thể thấy service ở us-west1 nhưng
không thấy ở europe-west1 trong cùng thời điểm.Điều này không phải lỗi — đây là đặc điểm của hệ thống distributed. Eventual consistency là sự đánh đổi cần thiết để đạt được hiệu năng và scale.
Hệ Quả Cho Operations
- Sau khi thay đổi firewall rule hoặc route, đừng test ngay lập tức — đợi ít nhất vài giây để propagation hoàn thành
- Trong change management process, coi thay đổi network config là có window "partial state" — monitor cả trước và sau
- Hierarchical firewall policy propagation chậm hơn VPC-level rules — có thể mất vài phút khi liên quan đến org hoặc folder level
GCP vs AWS vs Azure: Mental Model Mapping
Hiểu sự khác biệt kiến trúc giúp tránh antipatterns khi migrate:
| Khía cạnh | GCP | AWS | Azure |
|---|---|---|---|
| Phạm vi VPC/VNet | Global (một VPC cho tất cả regions) | Regional (VPC per region) | Regional (VNet per region) |
| Phạm vi Subnet | Regional (span tất cả zones trong region) | Zonal (một AZ) | Regional hoặc Zonal |
| Route table | Một table per VPC, áp dụng toàn cầu | Route table per subnet | Route table per subnet |
| Firewall | Cấp VPC, distributed enforcement per-VM | Security Group per ENI, NACL per subnet | NSG per NIC hoặc per subnet |
| Cross-region connectivity | Automatic trong cùng VPC | Cần VPC Peering hoặc Transit Gateway | Cần VNet Peering |
| CIDR constraint | Unique trong VPC (global) | Unique trong VPC (regional) | Unique trong VNet (regional) |
| Firewall enforcement point | Tại VM (Andromeda) | Tại VM (hypervisor) | Tại VM (hypervisor) |
Migration Pattern quan trọng: Một hệ thống AWS có nhiều VPCs per region có thể map sang GCP theo 2 cách:
- Một VPC với nhiều subnets (nếu không cần isolation mạnh)
- Nhiều VPCs với VPC Peering hoặc Shared VPC (nếu cần isolation theo team/environment)
Đừng map AWS VPC sang GCP VPC 1:1 — đây là nguồn gốc của rất nhiều over-engineering.
Constraints và Technical Limits
Số lượng VPCs
Mỗi project có thể có tối đa 15 VPCs (soft limit, có thể tăng). Tuy nhiên, GCP khuyến khích dùng ít VPCs hơn và dùng subnets, firewall rules để phân tách — thay vì tạo nhiều VPCs.
Lý do kỹ thuật: nhiều VPCs tạo ra complexity cho routing, peering, DNS, và troubleshooting. Mô hình tốt hơn là hierarchical là Shared VPC.
Số lượng Subnets
Mỗi VPC có thể có tối đa 4,000 subnets (kiểm tra quota thực tế vì có thể thay đổi). Đây là giới hạn rất lớn, rất khó đạt được trong thực tế.
IP Addresses Per Subnet
Mỗi IPv4 subnet tiêu tốn 4 địa chỉ reserved:
- Network address (first IP)
- Default gateway (second IP)
- Penultimate IP (Google reserved)
- Broadcast address (last IP)
Với /24 (256 IPs), bạn có 252 usable. Với /29 (8 IPs), chỉ còn 4 usable — đây là minimum subnet size mà GCP hỗ trợ.
MTU
GCP hỗ trợ MTU configurable từ 1300 đến 8896 bytes per VPC. Default là 1460 bytes (lịch sử từ thời GRE encapsulation overhead). Hiện tại với Andromeda, bạn có thể tăng lên 1500 hoặc cao hơn tùy workload.
Lưu ý: MTU phải nhất quán giữa tất cả VMs trong VPC. Thay đổi MTU sau khi deploy có thể gây packet fragmentation.
Failure Modes và Scale Considerations
Khi Nào VPC Trở Thành Bottleneck?
VPC bản thân không có "throughput limit" theo nghĩa truyền thống — vì đây là distributed SDN, không có single device nào làm bottleneck. Tuy nhiên, các điểm có giới hạn thực tế:
Connection tracking table: Mỗi vCPU hỗ trợ 130,000 kết nối đồng thời (1,040,000 với 8+ vCPUs). High-connection-rate workloads (gaming servers, proxies) có thể hit giới hạn này.
Route table size: Số lượng routes lớn (từ BGP peers) có thể slow down propagation và ảnh hưởng đến route lookup performance.
Firewall rule evaluation: Số lượng rules lớn làm tăng latency của mỗi packet evaluation. Best practice là giữ số rules ở mức reasonable và sử dụng hierarchical policies để tổ chức.
NAT gateway: Nếu dùng Cloud NAT cho egress, đây là điểm có throughput limit — NAT gateway có giới hạn số lượng NAT ports và connections.
Blast Radius của Global Resources
Vì route table và firewall rules là global, một thay đổi sai ảnh hưởng toàn bộ VPC trên tất cả regions:
Tình huống: Admin vô tình thêm route 0.0.0.0/0 → tunnel-vm
(next-hop là một VM đã bị tắt)
Hệ quả:
- TẤT CẢ default route traffic trong VPC bị drop
- VMs ở mọi region không thể kết nối ra internet
- Gián đoạn toàn bộ hệ thống
Trong AWS: Chỉ ảnh hưởng route table của subnet đó (regional scope)
Trong GCP: Ảnh hưởng toàn bộ VPC (global scope)Mitigations:
- Dùng IAM để hạn chế ai có thể modify routes và firewall rules
- Dùng hierarchical firewall policies với approval workflow cho org-level changes
- Tạo monitoring alert khi route table thay đổi
- Luôn test thay đổi ở staging VPC trước
Kiến Trúc Tham Chiếu: Multi-Region Production VPC
VPC: prod-vpc (GLOBAL)
Mode: Custom
MTU: 1460 (hoặc 1500 nếu không có legacy workloads)
Route Table (Global):
10.0.0.0/8 → [subnet routes, auto-generated]
0.0.0.0/0 → default-internet-gateway
Firewall (Global):
Priority 1000: allow ingress tcp:443 from 0.0.0.0/0 → tag:public-lb
Priority 1100: allow ingress tcp:8080 from tag:public-lb → tag:api-server
Priority 1200: allow ingress tcp:5432 from tag:api-server → tag:db
Priority 65534: deny ingress (implied)
Priority 65534: allow egress (implied)
Subnets (Regional):
us-west1 (10.0.0.0/14):
prod-nodes-us-west1: 10.0.0.0/16 [primary - VM IPs]
secondary: pods: 10.1.0.0/16 [GKE pod CIDR]
secondary: services: 10.2.0.0/20 [GKE service CIDR]
europe-west1 (10.16.0.0/14):
prod-nodes-eu-west1: 10.16.0.0/16
secondary: pods: 10.17.0.0/16
secondary: services: 10.18.0.0/20
asia-northeast1 (10.32.0.0/14):
prod-nodes-asia-ne1: 10.32.0.0/16
secondary: pods: 10.33.0.0/16
secondary: services: 10.34.0.0/20References
- GCP VPC Overview — Tổng quan kiến trúc VPC chính thức
- Andromeda: Performance Isolation and Sharing across Virtual Networks — Bài báo nghiên cứu về Andromeda SDN (USENIX NSDI 2018)
- GCP Route Documentation — Chi tiết về routing trong VPC
- VPC Firewall Rules Overview — Cơ chế firewall enforcement
- GCP Quotas and Limits — Giới hạn kỹ thuật của VPC