Jupiter Fabric: Spine-Leaf Topology và Bandwidth Oversubscription

Vì sao quan trọng trong production

Andromeda là lớp logical networking, nhưng nó chạy trên hạ tầng physical network. Hạ tầng đó chính là Jupiter Fabric. Hiểu Jupiter giúp bạn:

Dự báo bottleneck hiệu suất: Biết một VM có thể đạt throughput tối đa bao nhiêu
Thiết kế multi-zone deployment: Hiểu rõ latency và throughput giữa các zone
Xử lý tail latency: Khi performance giảm mà lỗi không nằm ở application code
Tối ưu sử dụng băng thông: Biết khi nào nên gom VM trong một zone, khi nào nên phân tán qua nhiều zone

Jupiter Fabric quyết định physical packet path, còn Andromeda quyết định logical routing path. Kết hợp cả hai, bạn mới có cái nhìn đầy đủ về hành vi mạng.

Model nội bộ: Kiến trúc Spine-Leaf trong datacenter

Mạng ba tầng truyền thống (On-Prem / Đã lỗi thời)

┌─────────────────────────┐
│    Core Layer           │
│  (High-End Switches)    │
│   Capacity 10-100Gbps   │
└────────────┬────────────┘
             │
    ┌────────┴────────┐
    │                 │
┌───▼──┐         ┌───▼──┐
│Agg1  │         │Agg2  │
│Aggr  │         │Aggr  │
└───┬──┘         └───┬──┘
    │                │
  ┌─┴────┐      ┌────┴─┐
  │      │      │      │
┌─▼─┐  ┌─▼─┐  ┌─▼─┐  ┌─▼─┐
│LS1│  │LS2│  │LS3│  │LS4│  (Leaf Switches)
└─┬─┘  └─┬─┘  └─┬─┘  └─┬─┘
  │      │      │      │
[Servers]      [Servers]

Vấn đề:
- Oversubscription: Aggregation → Core thành bottleneck
- Mỗi server có 1Gbps, nhưng core chỉ có tổng 10Gbps (tỷ lệ 1:10)
- Cross-pod traffic bị nghẽn vì core bị giới hạn

Jupiter: Kiến trúc Spine-Leaf hiện đại

┌─────────────────────────────────────────────────────┐
│              SPINE LAYER (top-of-rack)              │
│  Spine1    Spine2    Spine3    Spine4    Spine5     │
│  200Gbps   200Gbps   200Gbps   200Gbps   200Gbps    │
│   ▲         ▲         ▲         ▲         ▲         │
└───┼─────────┼─────────┼─────────┼─────────┼─────────┘
    │         │         │         │         │
    │  (25Gbps per link)                   │
    │         │         │         │         │
┌───┼─────────┼─────────┼─────────┼─────────┼─────────┐
│   │         │         │         │         │         │
│ Leaf1    Leaf2      Leaf3     Leaf4     Leaf5      │
│  48×25G   48×25G     48×25G    48×25G    48×25G     │
│   │         │         │         │         │         │
│ ┌─┴─────┐ ┌─┴─────┐ ┌─┴─────┐ ┌─┴─────┐ ┌─┴─────┐ │
│ │ 48 Svrs  │ 48 Svrs  │ 48 Svrs  │ 48 Svrs  │ 48 Svrs│ │
│ │ (50Gbps) │ (50Gbps) │ (50Gbps) │ (50Gbps) │(50Gbps)│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────────────────────────────────────────┘

Đặc điểm chính:
- Non-blocking fabric: Server nào cũng có thể tới server khác ở mức 25Gbps đầy đủ
- Nhiều đường bằng nhau: Spine-Leaf-Spine cung cấp ECMP (Equal Cost Multi-Path)
- Oversubscription TRONG leaf (48×50G → 240Gbps down, 5×25G = 125Gbps up) = khoảng 2:1
- Oversubscription là hợp lý vì phần lớn traffic ngắn hạn, không phải mọi server đều saturated cùng lúc

Tại sao chọn Spine-Leaf (thay vì 3-Tier)

Vấn đề với 3-tier: Bottleneck nằm ở tầng aggregation/core

Server → Leaf: 50Gbps (full bisection)
Leaf → Aggregation: 10Gbps (oversubscribed 5:1)
Cross-pod traffic mất 5x

Giải pháp với Spine-Leaf: Băng thông bằng nhau ở tất cả các tầng

Server → Leaf: 25Gbps
Leaf → Spine → Leaf: 25Gbps (qua ECMP, được load-balance)
Any-to-any: cùng băng thông bất kể destination

Trade-off về chi phí:

3-tier: Ít spine switch hơn, nhưng core đắt vì high-end
Spine-Leaf: Nhiều spine switch hơn, nhưng dùng commodity switch ở mọi tầng, rẻ hơn theo mỗi port

Ở quy mô của Google, Spine-Leaf rẻ hơn + hiệu suất tốt hơn.

Chi tiết Jupiter Fabric

Kết nối trên mỗi server

Server (Compute Host)
├─ 2x 100Gbps NIC (redundancy)
│  ├─ NIC1: kết nối tới Leaf1 (25Gbps)
│  ├─ NIC2: kết nối tới Leaf2 (25Gbps)
│  └─ Cả hai cùng subnet (LAG / bonding)
│
└─ Sustained throughput: 50Gbps (25Gbps mỗi leaf, aggregate)

Vì sao cần 2 NIC?

Redundancy: Nếu Leaf1 lỗi, traffic vẫn đi qua Leaf2
Capacity: Gộp lại đạt 50Gbps throughput cho mỗi server
Network diversity: Traffic không dồn vào một leaf

Định tuyến bên trong Fabric (Spine-Leaf Forwarding)

Khi server gửi packet:

1. Packet tới Leaf switch
   - ECMP: Có nhiều đường equal-cost tới destination
   - Load balancing: Hash trên (src_IP, dst_IP, src_port, dst_port)
   - Chọn một trong N spine switch

2. Spine switch nhận packet
   - Kiểm tra dest MAC → xác định destination leaf
   - Forward tới destination leaf qua next hop

3. Destination leaf nhận packet
   - Kiểm tra dest MAC → xác định server port đích
   - Forward tới server

Ví dụ:
src=10.1.0.2, dst=10.1.0.3
Hash(10.1.0.2, 10.1.0.3, port1, port2) = Spine2
Route: Leaf1 → Spine2 → Leaf1 (có thể cùng leaf!)

Hệ quả của Bandwidth Oversubscription

Jupiter có oversubscription 2:1 ở cấp leaf:

Capacity của Leaf Switch:
├─ Downlink (tới server): 48 × 50Gbps = 2400Gbps
├─ Uplink (tới spine): 5 × 100Gbps = 500Gbps
└─ Tỷ lệ: 2400:500 = 4.8:1 ??? (trông còn tệ hơn 2:1...)

Thực tế có sắc thái hơn:
├─ Nếu cả 48 server gửi local traffic trong leaf → tối đa 2400Gbps
├─ Nếu traffic đi giữa các leaf → bị giới hạn bởi uplink shared 500Gbps
├─ Thực tế: khoảng 48 server không saturated đồng thời
└─ Thiết kế giả định trung bình 25% utilization → 600Gbps sustained mỗi leaf

Hệ quả cho production:

✅ Một VM: Có thể đạt 25-50Gbps nếu isolated
✅ Nhiều VM trên cùng leaf, local traffic: Mỗi VM nhận một phần, nhưng tổng bandwidth bị giới hạn
⚠️ Mọi VM cùng gửi cross-leaf: Congestion, packet drop, tail latency
Cách giảm rủi ro: Traffic scheduling, bandwidth reservation, burst allowance

Physical và Logical Topology

Logical (Andromeda thấy):
└─ VPC A: 10.1.0.0/24
   ├─ Subnet: 10.1.0.0/24
   └─ Mọi VM kết nối logical dạng flat

Physical (Jupiter thấy):
└─ Datacenter topology
   ├─ Leaf switches (rack-level)
   ├─ Spine switches (fabric-level)
   └─ Server trong rack
       ├─ Server1 (10.1.0.2) @ Rack5, kết nối tới Leaf5
       └─ Server2 (10.1.0.3) @ Rack7, kết nối tới Leaf7

Packet từ Server1 tới Server2:
- Andromeda: Route 10.1.0.2 → 10.1.0.3 (logical, local subnet)
- Jupiter: Forward Leaf5 → Spine → Leaf7 (physical path)
- Kết quả: Packet đi theo physical path, nhưng VM không biết chi tiết leaf/spine

Pattern kiến trúc production

Pattern 1: Workload throughput cao (batch processing)

Yêu cầu: Di chuyển dataset 100GB trong 1 phút
┌──────────────────────┐
│ GCS Bucket (multi-region)
└────────┬─────────────┘
         │ 25Gbps per source
         │
┌────────▼──────────────────────────┐
│ Compute VMs (4 instances)         │
├─ VM1: 10.1.0.10 @ Leaf1 (25Gbps)  │
├─ VM2: 10.1.0.11 @ Leaf2 (25Gbps)  │
├─ VM3: 10.1.0.12 @ Leaf1 (25Gbps)  │  (Ghi chú: VM phân tán qua nhiều leaf)
└─ VM4: 10.1.0.13 @ Leaf3 (25Gbps)  │

Phân tích throughput:

Lý tưởng: 4 × 25Gbps = tổng 100Gbps
Thực tế: IO contention, giới hạn spine → sustained khoảng 80Gbps
100GB ÷ 80Gbps = 1.25 giây (đạt yêu cầu!)

Tác động của Jupiter: VM được phân tán qua nhiều leaf để tránh bottleneck oversubscription ở cấp leaf.

Pattern 2: Database Replication (throughput thấp, nhạy latency)

┌───────────────────────┐
│ Primary DB (Zone A)   │
│ IP: 10.1.0.100        │
│ @ Leaf1               │
├───────────────────────┤
│ Replication Channel   │
│ Throughput: 10Mbps    │
│ Latency SLA: <5ms     │
└───────────┬───────────┘
            │
            │ (Leaf1 → Spine2 → Leaf2: ~50μs physical latency)
            │
┌───────────▼───────────┐
│ Replica DB (Zone B)   │
│ IP: 10.2.0.100        │
│ @ Leaf2               │
└───────────────────────┘

Tác động của Jupiter: Throughput thấp thì ổn, nhưng latency rất quan trọng.

Spine được thiết kế cho latency <50μs
ECMP routing cung cấp latency thấp ổn định, không có queue dài
Replication không gây fabric congestion vì data volume nhỏ

Pattern 3: Kiến trúc Multi-Zone Failover

Primary (Zone A):
├─ Application @ Leaf1
├─ Database @ Leaf3
└─ Replication link: 10Mbps

Standby (Zone B):
├─ Application @ Leaf2
├─ Database @ Leaf4
└─ Sẵn sàng tiếp quản

Failover: Primary data center down
├─ Standby Application: DNS updated → kết nối tới Standby Database
├─ Jupiter fabric: Route traffic nội bộ từ Zone B tới Zone B
├─ Latency: <5ms (intra-zone via spines)
├─ Throughput: Có đủ 25Gbps
└─ Recovery: Không có cross-zone congestion

Lợi ích của Jupiter: Mỗi zone được cô lập ở cấp fabric, nên failover không ảnh hưởng zone khác.

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

Lỗi 1: Nghĩ mọi server có throughput bằng nhau tới mọi server khác

❌ Suy nghĩ sai:

"All VMs in same zone have equal 25Gbps to all other VMs"

✅ Hiểu đúng:

Một VM: Có thể đạt khoảng 25Gbps egress tới một destination
2 VM trên CÙNG leaf gửi cross-leaf: Mỗi VM bị giới hạn khoảng 12.5Gbps vì shared uplink
2 VM trên leaf KHÁC nhau: Mỗi VM có thể gần đạt 25Gbps vì uplink tách biệt
Many-to-many: Aggregate spine bandwidth trở thành bottleneck

Tác động: Tưởng application scale tuyến tính, nhưng networking bị giới hạn khi concurrency cao.

Phòng tránh: Benchmark throughput thực tế trong zone. Dùng iperf3 giữa các VM và đo qua topology.

Lỗi 2: Kỳ vọng zero packet loss khi utilization cao

❌ Suy nghĩ sai:

"Google infrastructure never drops packets, so can rely on 99.9% utilization"

✅ Hiểu đúng:

Spine switch: Non-blocking, hiếm khi drop packet
Leaf switch: Oversubscribed, có thể drop khi tải cực cao
TCP backoff: Packet mất gây retransmit và giảm performance
Target: <0.01% packet loss trên mọi region pair theo Google SLA

Tác động: Sustained leaf utilization trên 90% gây packet drop và retransmit thấy rõ.

Phòng tránh: Giữ sustained utilization dưới 70%, chỉ burst tạm thời. Monitor switch fabric metrics.

Lỗi 3: Không cân nhắc physical rack placement

❌ Suy nghĩ sai:

"VMs are placed automatically, no need to think about rack topology"

✅ Hiểu đúng:

Andromeda: Logical VPC placement
Jupiter: Physical rack/leaf placement, thường bạn không kiểm soát được
Nhưng zone/rack vẫn ảnh hưởng performance
VM trong cùng rack/leaf: Latency thấp nhất, nhưng shared fabric
VM ở rack khác nhau: Latency cao hơn chút, nhưng isolation tốt hơn

Tác động: Application performance khó đoán nếu 2 VM quan trọng cùng nằm trên một leaf → bottleneck.

Phòng tránh: Dùng Pod Affinity/Anti-Affinity cho GKE. Dùng placement policies để topology dễ dự đoán hơn.

Lỗi 4: Bỏ qua oversubscription khi hoạch định capacity

❌ Suy nghĩ sai:

"1000 servers × 25Gbps = 25Tbps total capacity"

✅ Hiểu đúng:

Raw capacity: 25Tbps nếu mọi server gửi đồng thời
Sustained thực tế: khoảng 5Tbps khi tính oversubscription 2:1
Burst: Tối đa 10Tbps trong thời gian ngắn
Thực tế: Plan cho average utilization khoảng 40%

Tác động: Tốn tiền compute quá mức vì bottleneck nằm ở network.

Phòng tránh: Đưa network throughput vào capacity planning. Monitor egress bottleneck metrics.

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

Hiểu Zone Placement

bash

# Liệt kê mọi zone trong một region
gcloud compute zones list --filter="region:us-central1"

# Tạo VM và kiểm tra leaf/rack gián tiếp qua zone
gcloud compute instances create vm1 --zone=us-central1-a
gcloud compute instances create vm2 --zone=us-central1-b

# VM ở zone khác thường nằm trên leaf khác → fabric path khác

# Verify zone assignment:
gcloud compute instances describe vm1 --zone=us-central1-a \
  --format='value(zone)'

Monitor Fabric Congestion

bash

# VPC Flow Logs capture telemetry cấp packet từ Andromeda
gcloud compute instances create test-vm \
  --zone=us-central1-a \
  --network-interface=enable-display-device=true

# Bật flow logs trên subnet
gcloud compute networks subnets update my-subnet \
  --enable-flow-logs \
  --region=us-central1

# Query flow latency cao, dấu hiệu congestion
gcloud logging read "resource.type=gce_instance AND jsonPayload.bytes_sent>1000000" \
  --format=json | grep -i latency

Multi-Zone Load Distribution

bash

# Tạo instance group qua nhiều zone để phân tán qua nhiều leaf
gcloud compute instance-groups managed create ig-zone-a \
  --base-instance-name=vm \
  --template=my-template \
  --size=10 \
  --zone=us-central1-a

gcloud compute instance-groups managed create ig-zone-b \
  --base-instance-name=vm \
  --template=my-template \
  --size=10 \
  --zone=us-central1-b

# Load balancer phân phối traffic qua nhiều zone
# Kết quả: VM ở zone riêng = leaf riêng = isolation tốt hơn

Tài liệu tham khảo

Jupiter Rising: A Decade of Clos Topology and Centralized Control in Google's Datacenter Network (Google Tech Report, 2015) — Kiến trúc Jupiter chi tiết
Google Datacenter Networking Architecture — Tổng quan cấp cao
Network Performance Monitoring — Monitor Jupiter fabric congestion
VPC Flow Logs Documentation — Hiểu traffic pattern trên fabric

Tiếp theo: GCP Edge Network và Point of Presence (PoP) — Cách Internet traffic đi vào GCP fabric

Jupiter Fabric: Spine-Leaf Topology và Bandwidth Oversubscription ​

Vì sao quan trọng trong production ​

Model nội bộ: Kiến trúc Spine-Leaf trong datacenter ​

Mạng ba tầng truyền thống (On-Prem / Đã lỗi thời) ​

Jupiter: Kiến trúc Spine-Leaf hiện đại ​

Tại sao chọn Spine-Leaf (thay vì 3-Tier) ​

Chi tiết Jupiter Fabric ​

Kết nối trên mỗi server ​

Định tuyến bên trong Fabric (Spine-Leaf Forwarding) ​

Hệ quả của Bandwidth Oversubscription ​

Physical và Logical Topology ​

Pattern kiến trúc production ​

Pattern 1: Workload throughput cao (batch processing) ​

Pattern 2: Database Replication (throughput thấp, nhạy latency) ​

Pattern 3: Kiến trúc Multi-Zone Failover ​

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

Lỗi 1: Nghĩ mọi server có throughput bằng nhau tới mọi server khác ​

Lỗi 2: Kỳ vọng zero packet loss khi utilization cao ​

Lỗi 3: Không cân nhắc physical rack placement ​

Lỗi 4: Bỏ qua oversubscription khi hoạch định capacity ​

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

Hiểu Zone Placement ​

Monitor Fabric Congestion ​

Multi-Zone Load Distribution ​

Tài liệu tham khảo ​

Jupiter Fabric: Spine-Leaf Topology và Bandwidth Oversubscription

Vì sao quan trọng trong production

Model nội bộ: Kiến trúc Spine-Leaf trong datacenter

Mạng ba tầng truyền thống (On-Prem / Đã lỗi thời)

Jupiter: Kiến trúc Spine-Leaf hiện đại

Tại sao chọn Spine-Leaf (thay vì 3-Tier)

Chi tiết Jupiter Fabric

Kết nối trên mỗi server

Định tuyến bên trong Fabric (Spine-Leaf Forwarding)

Hệ quả của Bandwidth Oversubscription

Physical và Logical Topology

Pattern kiến trúc production

Pattern 1: Workload throughput cao (batch processing)

Pattern 2: Database Replication (throughput thấp, nhạy latency)

Pattern 3: Kiến trúc Multi-Zone Failover

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

Lỗi 1: Nghĩ mọi server có throughput bằng nhau tới mọi server khác

Lỗi 2: Kỳ vọng zero packet loss khi utilization cao

Lỗi 3: Không cân nhắc physical rack placement

Lỗi 4: Bỏ qua oversubscription khi hoạch định capacity

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

Hiểu Zone Placement

Monitor Fabric Congestion

Multi-Zone Load Distribution

Tài liệu tham khảo