Andromeda: GCP Software-Defined Networking Stack

Vì sao quan trọng trong production

Andromeda là nền tảng của hầu hết networking trong GCP. Mỗi packet gửi từ VM của bạn, mỗi connection tới service khác, mỗi quyết định của load balancer đều được Andromeda xử lý. Hiểu cách nó hoạt động cho phép bạn:

Dự báo hành vi network thay vì thử sai
Debug vấn đề network khi lỗi không nằm ở application code
Tối ưu network performance thay vì để system chạy mặc định
Thiết kế security architecture nhờ hiểu rõ pipeline xử lý packet

Một kỹ sư platform hoặc cloud architect không cần implement Andromeda, nhưng PHẢI biết cách nó xử lý traffic. Mọi quyết định bạn đưa ra, như firewall rules, routing, NAT, đều phụ thuộc vào model này.

Model nội bộ: Cách Andromeda xử lý packet

Vấn đề: Tại sao Google cần SDN?

Trước khi có Andromeda (trước khoảng 2012), Google phải cấu hình thủ công từng network device (switch, router) để implement network policy. Khi có hàng triệu VM, network policy thay đổi liên tục: VM được tạo hoặc xóa, firewall rules được cập nhật, routes thay đổi. Cấu hình thủ công không thể scale.

Giải pháp là Software-Defined Networking: tách control plane (logic policy) khỏi data plane (packet forwarding). Google viết một "network operating system" tên Andromeda, chạy bên trên physical hardware, để quản lý toàn bộ network bằng API và automation.

Tổng quan kiến trúc

Andromeda có hai component chính:

┌─────────────────────────────────────────────┐
│         CONTROL PLANE (Trung tâm)           │
│  - Quản lý policy (Firewall, Routes)       │
│  - Service Discovery và Load Balancing     │
│  - Monitoring và Telemetry                 │
└────────────┬────────────────────────────────┘
             │
        gRPC / Protocol Buffers
             │ 
┌────────────▼────────────────────────────────┐
│   DATA PLANE (Tại từng node)                │
│  - Packet Forwarding                        │
│  - Connection Tracking                      │
│  - NAT/IP Translation                       │
│  - Thực thi Firewall                        │
└─────────────────────────────────────────────┘

Mô hình này cho phép:

Centralized policy: Một nơi định nghĩa "traffic từ A tới B được phép", rồi control plane push policy xuống tất cả node
Local enforcement: Mỗi node (VM) tự enforce policy, không phụ thuộc vào central system, giúp high availability
Stateful connection tracking: Mỗi node theo dõi connection, cho phép asymmetric routing; outgoing traffic có thể exit ở điểm khác incoming traffic

Cách Data Plane thực thi

Khi packet tới VM của bạn, Andromeda data plane xử lý theo thứ tự:

1. INGRESS FIREWALL RULES
   - Match Layer 4 (protocol, port)
   - Stateful: Nếu đã có outbound trước → allow inbound response
   - Default: DENY (implied deny rule)

2. ROUTING DECISION
   - Subnet routes (local)
   - Custom routes (static)
   - Dynamic routes (Cloud Router via BGP)

3. NAT (nếu được config)
   - Source NAT (SNAT) cho outgoing
   - Destination NAT (DNAT) cho load balancer

4. FORWARDING
   - Chuyển packet đến egress interface (physical NIC)
   - Tunnel encapsulation (nếu cross-datacenter)

5. EGRESS FIREWALL RULES
   - Match Layer 4
   - Implicit allow (khác ingress)

Chi tiết quan trọng: Firewall rules áp dụng TẠI INSTANCE (node), không phải ở network edge. Điều này có nghĩa:

Khi 2 VM trong cùng subnet giao tiếp qua internal IP, firewall vẫn được enforce. Không có chuyện bypass firewall vì cùng subnet
Monitoring được centralize bằng connection logs từ mọi node
Mỗi VM có stateful firewall đầy đủ, không cần dedicated firewall appliance

VPC Implementation trong Andromeda

VPC network trong Andromeda là logical overlay trên physical network:

GCP Datacenter vật lý
├── Node A (Compute Host)
│   └── VM1 (10.1.0.10/VPC-A)
│   └── VM2 (10.1.0.11/VPC-B)
│
├── Node B (Compute Host)  
│   └── VM3 (10.1.0.12/VPC-A)
│
└── Network Switch Fabric
    └── Forward dựa trên physical MAC/IP

Andromeda tách logical network khỏi physical network:

Physical network thấy packet với physical MAC address và physical IP address trong GCP backbone
VM thấy packet với VPC IP address và VPC MAC address do Andromeda tạo

Cách này thực hiện:

1. VM1 gửi packet: src=10.1.0.10, dst=10.1.0.12
2. Andromeda data plane chặn packet
3. Lookup routing table: 10.1.0.12 nằm trên Node B
4. Encapsulate: thêm GCP backbone header (physical MAC/IP)
5. Forward qua physical network
6. Node B nhận, decapsulate, rồi chuyển tới VM3

Kết quả: VM không biết nó đang chạy trên shared physical network. Mỗi VPC là logical network được cô lập hoàn toàn, kể cả khi các VM chạy trên cùng physical host.

Pattern kiến trúc production

Pattern 1: Single-Region VPC (thường dùng cho stateful app)

┌─────────────────────────────────────────────┐
│      Region us-central1 (Iowa)              │
│                                             │
│  ┌──────────────────────────────────────┐  │
│  │ VPC Network (10.0.0.0/8)             │  │
│  │                                      │  │
│  │  ┌────────────────┐                 │  │
│  │  │ Subnet 1       │ (10.1.0.0/24)   │  │
│  │  │ Zone us-c1-a   │                 │  │
│  │  │ - VM-1         │ (10.1.0.2)      │  │
│  │  │ - VM-2         │ (10.1.0.3)      │  │
│  │  └────────────────┘                 │  │
│  │                                      │  │
│  │  ┌────────────────┐                 │  │
│  │  │ Subnet 2       │ (10.2.0.0/24)   │  │
│  │  │ Zone us-c1-b   │                 │  │
│  │  │ - VM-3         │ (10.2.0.2)      │  │
│  │  └────────────────┘                 │  │
│  │                                      │  │
│  │ Firewall Rules:                      │  │
│  │  - allow: tcp:80,443 from 0.0.0.0/0 │  │
│  │  - allow: tcp:3306 from 10.1.0.0/24 │  │
│  │  - deny: all (implicit)              │  │
│  │                                      │  │
│  │ Routes:                              │  │
│  │  - 10.0.0.0/8 → local (subnet rts)  │  │
│  │  - 0.0.0.0/0  → internet gateway    │  │
│  └──────────────────────────────────────┘  │
│                                             │
└─────────────────────────────────────────────┘

Cách Andromeda enforce phần này:

Subnet routes (10.1.0.0/24, 10.2.0.0/24) được program vào data plane của mỗi node
Firewall rules được compile thành iptables rules hoặc eBPF trong Dataplane V2
Mỗi node tự enforce rules. Nếu control plane chết, traffic vẫn forward theo cached rules
VM mới → control plane gửi configuration → data plane bắt đầu enforce

Pattern 2: Multi-VPC với VPC Peering

┌──────────────────┐        ┌──────────────────┐
│   VPC Network A  │        │   VPC Network B  │
│  10.1.0.0/16     │        │  10.2.0.0/16     │
│                  │        │                  │
│  ┌────────────┐  │        │  ┌────────────┐  │
│  │ VM-A1      │  │        │  │ VM-B1      │  │
│  │ 10.1.1.0   │  │        │  │ 10.2.1.0   │  │
│  └────────────┘  │        │  └────────────┘  │
│                  │        │                  │
│  Firewall Rules: │        │  Firewall Rules: │
│  allow: 10.2/16 │        │  allow: 10.1/16 │
└──────────┬───────┘        └────────┬─────────┘
           │                        │
           └────────VPC Peering─────┘
              (subnet routes exchanged)

Cách Andromeda implement peering:

Control plane: "VPC-A và VPC-B đã peered" → tính routes
Data plane push tới mọi node:
- Node trong VPC-A: 10.2.0.0/16 → peering next-hop → tới VPC-B
- Node trong VPC-B: 10.1.0.0/16 → peering next-hop → tới VPC-A
Firewall rules: Mỗi VPC tự kiểm soát ingress/egress
Điểm chính: Không có transit traffic. A→B→C không được phép, kể cả khi B peered với cả A và C

Pattern 3: Shared VPC cho enterprise multi-project

┌──────────────────────────────────────┐
│      Organization                     │
├──────────────────────────────────────┤
│  HOST PROJECT                         │
│  └─ VPC Network (10.0.0.0/8)         │
│     └─ Subnet (10.1.0.0/24)          │
│        ├─ Firewall Rules              │
│        └─ Routes                      │
└──────────────────────────────────────┘
        │
    VPC Peering (logical, shared)
        │
┌───────┴──────────┬────────────────────┐
│                  │                    │
▼                  ▼                    ▼
SERVICE-PROJECT-1  SERVICE-PROJECT-2  SERVICE-PROJECT-3
└─ Có thể tạo VM trong Shared VPC
   └─ Phải có IAM role: serviceAccount@svc.id.goog
   └─ Firewall rules từ host project được áp dụng

Vai trò của Andromeda:

Host project định nghĩa firewall/routes như central policy
Service project đặt VM vào shared subnets
Data plane enforcement diễn ra thống nhất trên các project
Billing được track theo từng project cho data transfer, nhưng routing được shared

Kịch bản thực tế và trade-off

Kịch bản 1: E-commerce platform toàn cầu, multi-tenant

├─ Lớp frontend (Global)
│  └─ Anycast IP (via Global Load Balancer)
│  └─ Route user→region gần nhất (dùng anycast + BGP)
│
├─ Region: us-east1
│  └─ VPC-us-east
│  └─ App servers (internal IP)
│  └─ Firewall: allow from GLB only
│
├─ Region: eu-west1
│  └─ VPC-eu-west
│  └─ App servers (internal IP)
│  └─ Firewall: allow from GLB only
│
└─ Lớp database (regional, có replicated)
   └─ Cloud SQL (managed, not in VPC)
   └─ Private IP endpoint (uses Private Google Access)

Quyết định của Andromeda:

GLB terminate SSL tại PoP gần nhất
Traffic giữa app-server ở lại trong region, không tạo cross-region latency
Database connection dùng Private Google Access (199.36.153.4/30 magic network)
Firewall rules: whitelist IP health check của GLB từ các region cụ thể

Kịch bản 2: Microservices với kiểm soát egress chặt

namespace: payment
├─ Pod: payment-processor (internal IP: 10.10.0.50)
│  └─ Outbound được phép: chỉ tới Stripe API (egress rule: stripe.com:443)
│  └─ Bị chặn: internet, service khác
│
└─ Pod: payment-audit (internal IP: 10.10.0.51)
   └─ Outbound được phép: chỉ tới Cloud Logging, BigQuery
   └─ Bị chặn: mọi thứ khác

Andromeda Data Plane:

Mỗi pod network interface có stateful firewall
Connection tracking: egress cho phép response, ingress chặn traffic không được yêu cầu
Egress rule cho "stripe.com:443" → DNS resolve ra IP → firewall match
Chặn ngay traffic bất ngờ tại pod network interface

Kịch bản 3: Hybrid Network (On-Prem + Cloud)

┌─────────────┐  Cloud Interconnect   ┌──────────────┐
│On-Prem DC   │━━━━━━━━━━━━━━━━━━━━━━━│ GCP VPC      │
│172.16.0/12  │    (Dedicated VLAN)   │10.0.0.0/8    │
└─────────────┘                       └──────────────┘
      │                                     │
      └─ On-Prem: 172.16.0.0/12             │
      └─ GCP: 10.0.0.0/8                   │
      └─ Cloud Router: BGP advertisement   │
      └─ Firewall: allow both CIDR blocks  │

Vai trò của Andromeda:

Cloud Router ở phía GCP nhận routes qua BGP từ on-prem
Routes: "172.16.0.0/12 qua Cloud Interconnect attachment"
Data plane: routes match 172.16.0.0/12 được gửi tới tunnel interface
Physical network (Jupiter) xử lý encapsulation/tunneling
Firewall enforce rules cho hybrid traffic giống intra-VPC

Lỗi thường gặp và anti-pattern

Lỗi 1: Nghĩ cùng subnet là tự allow

❌ Suy nghĩ sai:

"VMs in same subnet are automatically reachable - firewall rules don't matter"

✅ Hiểu đúng:

Firewall rules LUÔN áp dụng, kể cả trong cùng subnet
Mặc định: implied deny cho ingress, tức secure by default
Phải allow rõ từng chiều traffic
Andromeda enforce ở packet level, bất kể subnet

Tác động: Dev deploy application, thử curl vm-b từ vm-a, rồi bị fail. "Cùng subnet thì phải chạy!" Không đúng; cần firewall rule.

Phòng tránh: Luôn review firewall rules, kể cả khi giao tiếp cùng subnet. Dùng gcloud compute firewall-rules list để verify.

Lỗi 2: Không hiểu Stateful Connection Tracking

❌ Suy nghĩ sai:

"I need separate egress firewall rules for inbound responses"

✅ Hiểu đúng:

Firewall là stateful. Nếu allow egress TCP:443, response TCP:443 tự động được allow quay lại
Connection state được track trong kernel (connection tracking table)
ESTABLISHED/RELATED connections bypass firewall rules

Tác động: Firewall rules phình ra không cần thiết, dễ hiểu sai performance

Phòng tránh: Hiểu connection states (NEW, ESTABLISHED, RELATED). Trong GCP firewall console, xem "Session affinity" và connection matching.

Lỗi 3: Quên Egress Internet Gateway

❌ Suy nghĩ sai:

"VM has external IP, can reach internet automatically"

✅ Hiểu đúng:

Chỉ có external IP là chưa đủ
Cần egress firewall rule và default route (0.0.0.0/0 → internet gateway)
Default VPC có sẵn các phần này; custom VPC có thể không có

Tác động: VM có external IP nhưng không ra internet được. Debug rất mất thời gian.

Phòng tránh: Khi tạo custom VPC, hãy tạo rõ internet gateway route. Kiểm tra bằng gcloud compute routes list.

Lỗi 4: Hiểu sai VPC Isolation

❌ Suy nghĩ sai:

"VPC-A and VPC-B are completely isolated - no data leakage possible"

✅ Hiểu đúng:

VPC-to-VPC isolation phụ thuộc vào cấu hình peering/sharing
Firewall rules cung cấp defense-in-depth
Shared VPC cấp quyền cross-project access theo thiết kế

Tác động: Lỗi thiết kế security. Dev bật Shared VPC mà không hiểu hệ quả.

Phòng tránh: Hiểu IAM boundary và VPC boundary. Shared VPC nên tách rõ network admin role.

Hướng dẫn triển khai GCP-native

Tạo VPC với Andromeda Control

bash

# Tạo custom VPC (Andromeda quản lý)
gcloud compute networks create my-vpc \
  --subnet-mode=custom \
  --bgp-routing-mode=regional

# Tạo subnet (Andromeda allocate trong data plane)
gcloud compute networks subnets create my-subnet \
  --network=my-vpc \
  --region=us-central1 \
  --range=10.1.0.0/24 \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec

# Firewall rule (Andromeda compile thành data plane rules)
gcloud compute firewall-rules create allow-http \
  --network=my-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=http-server \
  --allow=tcp:80,tcp:443

# Tạo VM (Andromeda gán VPC IP, cấu hình firewall)
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --network-interface=network=my-vpc,subnet=my-subnet \
  --tags=http-server

Andromeda làm gì phía sau:

Control plane nhận "create subnet" → tính CIDR allocation
Push tới mọi node trong region: "10.1.0.0/24 là local tại us-central1-a"
Control plane nhận "create firewall rule" → compile thành iptables/eBPF rules
Push tới target nodes: "VM có tag http-server allow 0.0.0.0/0:tcp:80"
VM start → được gán 10.1.0.2 → Andromeda data plane cấu hình veth pair → VM gửi được traffic

Verify cấu hình Andromeda

bash

# Kiểm tra thuộc tính VPC network
gcloud compute networks describe my-vpc

# Liệt kê firewall rules (control plane state)
gcloud compute firewall-rules list --filter="network=my-vpc"

# Kiểm tra network interface của VM (data plane state)
gcloud compute instances describe my-vm --zone=us-central1-a \
  --format='value(networkInterfaces[0])'

# Monitor VPC Flow Logs (capture từ data plane)
gcloud logging read "resource.type=gce_instance AND jsonPayload.src_addr=10.1.0.0/24" \
  --limit=10

# Trace packet path bằng Network Connectivity Tests
gcloud compute networks vpc-peering routes list --vpc-network=my-vpc

Tài liệu tham khảo

Andromeda: Google Cloud's Software-Defined Networking (USENIX NSDI '18) — Paper học thuật gốc mô tả kiến trúc Andromeda
GCP VPC Networks Documentation — VPC được Andromeda implement như thế nào
Creating and Managing VPC Networks — Hướng dẫn thực tế cho cấu hình Andromeda
Firewall Rules Documentation — Cách Andromeda enforce policy
VPC Flow Logs — Monitor activity của Andromeda data plane

Tiếp theo: Jupiter Fabric: Spine-Leaf Topology và Oversubscription — Hiểu infrastructure vật lý mà Andromeda chạy bên trên

Andromeda: GCP Software-Defined Networking Stack ​

Vì sao quan trọng trong production ​

Model nội bộ: Cách Andromeda xử lý packet ​

Vấn đề: Tại sao Google cần SDN? ​

Tổng quan kiến trúc ​

Cách Data Plane thực thi ​

VPC Implementation trong Andromeda ​

Pattern kiến trúc production ​

Pattern 1: Single-Region VPC (thường dùng cho stateful app) ​

Pattern 2: Multi-VPC với VPC Peering ​

Pattern 3: Shared VPC cho enterprise multi-project ​

Kịch bản thực tế và trade-off ​

Kịch bản 1: E-commerce platform toàn cầu, multi-tenant ​

Kịch bản 2: Microservices với kiểm soát egress chặt ​

Kịch bản 3: Hybrid Network (On-Prem + Cloud) ​

Lỗi thường gặp và anti-pattern ​

Lỗi 1: Nghĩ cùng subnet là tự allow ​

Lỗi 2: Không hiểu Stateful Connection Tracking ​

Lỗi 3: Quên Egress Internet Gateway ​

Lỗi 4: Hiểu sai VPC Isolation ​

Hướng dẫn triển khai GCP-native ​

Tạo VPC với Andromeda Control ​

Verify cấu hình Andromeda ​

Tài liệu tham khảo ​

Andromeda: GCP Software-Defined Networking Stack

Vì sao quan trọng trong production

Model nội bộ: Cách Andromeda xử lý packet

Vấn đề: Tại sao Google cần SDN?

Tổng quan kiến trúc

Cách Data Plane thực thi

VPC Implementation trong Andromeda

Pattern kiến trúc production

Pattern 1: Single-Region VPC (thường dùng cho stateful app)

Pattern 2: Multi-VPC với VPC Peering

Pattern 3: Shared VPC cho enterprise multi-project

Kịch bản thực tế và trade-off

Kịch bản 1: E-commerce platform toàn cầu, multi-tenant

Kịch bản 2: Microservices với kiểm soát egress chặt

Kịch bản 3: Hybrid Network (On-Prem + Cloud)

Lỗi thường gặp và anti-pattern

Lỗi 1: Nghĩ cùng subnet là tự allow

Lỗi 2: Không hiểu Stateful Connection Tracking

Lỗi 3: Quên Egress Internet Gateway

Lỗi 4: Hiểu sai VPC Isolation

Hướng dẫn triển khai GCP-native

Tạo VPC với Andromeda Control

Verify cấu hình Andromeda

Tài liệu tham khảo