A10 Networks Thunder 實戰課程

👋 歡迎來到架構師殿堂

今天我們要來談談如何讓你的服務跨越地理限制，實現真正的「全球化」與「不死之身」。GSLB 是大型企業與雲端架構中不可或缺的一環，它超越了單一資料中心的限制，是實現異地備援 (Disaster Recovery) 的核心技術。

1 核心概念 (Concept)

一句話定義

GSLB (Global Server Load Balancing) 是一種基於 DNS 的智慧型流量調度技術，能根據使用者的位置與伺服器健康狀態，將流量導向「最適合」的資料中心。

生活化比喻

想像 GSLB 是全球連鎖飯店的「總機管家」。

當你要訂房 (發出請求) 時，你不需要知道哪間分店有空房。你只需要打給總機，管家會根據：

你的位置 (Geo-location)：你人在台北，就優先幫你訂台北分店。
忙碌程度 (Load)：台北客滿了，建議你去桃園分店。
營業狀態 (Health Check)：高雄分店整修中 (Down)，絕不會幫你轉接過去。

2 運作原理 (Mechanism)

1. DNS Proxy 角色

GSLB 的核心在於它介入了 DNS 解析過程。A10 Thunder 可以配置為 DNS Proxy 或 Authoritative DNS (授權 DNS)。

攔截查詢： 當 Client 查詢 www.bank.com 時，A10 GSLB 會收到這個 DNS Query。
智慧決策： 不同於傳統 DNS 只會輪詢 (Round-robin) 回傳固定 IP，GSLB 會即時檢查後端 VIP 狀態。
修改回應： GSLB 將「最佳」的 Service IP 包裝在 DNS Response 中回傳給 Client。

Zone (區域)

這就是 Domain Name (例如 example.com)。GSLB 需要知道它負責管理哪個網域的解析。

Service IP (服務 IP)

對應到各個資料中心內部的 SLB VIP。這是 GSLB 最終要回傳給使用者的 IP 地址。

Policy Metric (策略指標)

決策依據：
1. Geo-location: 根據 Client IP 地理位置。
2. RTT: 測量封包往返時間，選最快的。
3. Weighted: 權重分配。

3 架構視覺化 (Visuals)

圖一：多資料中心 GSLB 部署拓撲

flowchart TD %% 定義樣式 Class classDef client fill:#FF6600,stroke:#333,stroke-width:2px,color:#fff classDef dns fill:#F3F4F6,stroke:#666,stroke-width:1px,stroke-dasharray: 5 5,color:#333 classDef a10 fill:#002F6C,stroke:#333,stroke-width:2px,color:#fff classDef slb fill:#1e40af,stroke:#333,stroke-width:1px,color:#fff classDef app fill:#fff,stroke:#333,stroke-width:1px,color:#333 %% 網際網路區塊 subgraph Internet ["網際網路 (Internet)"] direction TB Client((Client)):::client LDNS[Local DNS Server]:::dns end %% 台北資料中心 subgraph DC_A ["Data Center A (Taipei)"] direction TB GSLB_A[A10 GSLB Controller A
DNS Proxy]:::a10 SLB_A[A10 SLB
VIP: 1.1.1.1]:::slb App_A[App Servers]:::app end %% 高雄資料中心 subgraph DC_B ["Data Center B (Kaohsiung)"] direction TB GSLB_B[A10 GSLB Controller B]:::a10 SLB_B[A10 SLB
VIP: 2.2.2.2]:::slb App_B[App Servers]:::app end %% 連線關係 - DNS 流程 (虛線或細線) Client -->|1. DNS Query| LDNS LDNS -->|2. Fwd Query| GSLB_A GSLB_A -->|3. Reply VIP: 1.1.1.1| LDNS LDNS -->|4. Return IP| Client %% GSLB 同步 GSLB_A <==>|Sync State| GSLB_B %% 健康檢查 (虛線) GSLB_A -.->|Health Check| SLB_A GSLB_B -.->|Health Check| SLB_B %% 實際流量 (粗線) Client ===>|5. HTTP Request| SLB_A SLB_A --> App_A %% 避免線條重疊的隱藏連結 (Layout Hint) SLB_A ~~~ SLB_B

圖二：GSLB 決策流程 (Sequence Diagram)

sequenceDiagram participant User as User participant LDNS as Local DNS participant GSLB as A10 GSLB (Controller) participant DC1 as DC1 (Taipei) participant DC2 as DC2 (Kaohsiung) User->>LDNS: DNS Query (www.myapp.com) LDNS->>GSLB: Forward Query Note over GSLB: Step 1: Check Health GSLB->>DC1: Health Check? DC1-->>GSLB: Status: Alive GSLB->>DC2: Health Check? DC2-->>GSLB: Status: Alive Note over GSLB: Step 2: Check Policy (Geo/RTT) GSLB->>GSLB: Evaluate: User IP is in Taipei GSLB->>GSLB: Decision: Select DC1 VIP GSLB-->>LDNS: DNS Response (VIP: 100.1.1.1) LDNS-->>User: DNS Response (VIP: 100.1.1.1) User->>DC1: Application Traffic Flow

4 實務應用場景 (Use Case)

案例：銀行跨中心災難復原 (Multi-DC DR)

情境： 某大型銀行擁有「台北主中心」與「高雄備援中心」。

需求：

平時：北部用戶連台北，南部用戶連高雄 (Active-Active, 就近服務)。
災難時：若台北中心斷線，所有北部用戶自動導向高雄，無需人工切換 DNS。

優點

無縫切換 (Zero Downtime)：使用者無感知，不需要等待 DNS TTL 漫長的過期時間。
資源利用率最大化：備援中心平時也能分擔流量，而非閒置浪費。
體驗優化：Geo-location 確保連線速度最快。

挑戰/注意事項

資料同步 (Data Sync)：GSLB 只管導流，應用層資料庫必須即時同步，否則用戶會看到舊資料。
複雜度：需要維護 DNS 設定與 GSLB Controller 之間的通訊 (Port 4149 等)。