基於網路位址轉換(NAT)的多伺服器負載平衡實作

前言

隨著網際網路的快速增長，多媒體網路伺服器面臨的並發存取量劇增。單一伺服器的處理能力與 I/O 效能逐漸成為服務瓶頸，必須採用多伺服器叢集與負載平衡技術來分擔流量。本文探討負載平衡技術演進，並基於 FreeBSD 的網路位址轉換（NAT）機制，實作一個軟體型負載平衡閘道，動態依據後端伺服器的 CPU 與 I/O 狀態分配請求，解決高併發下的效能問題。

負載平衡技術演進與比較

DNS 輪詢

最早期的做法是在 DNS 中為同一主機名對應多個 IP 位址，客戶端查詢時會取得不同位址，從而達到分流目的。優點是簡單易行，但無法感知伺服器異質性與即時負載狀態，容易造成負載不均。

反向 Proxy

反向 Proxy 可將請求轉發給內部 Web 伺服器群，並套用最佳化策略（如最少連線、回應時間）。然而隨著並發連線增長，Proxy 本身成為新瓶頸，且難以支援複雜應用協定。

硬體 Layer 4 交換器

廠商將 NAT 負載平衡整合至交換器，支援隨機、連線數、回應時間等演算法。但硬體實作靈活度低，難以支援優化策略與非標準協定。

軟體型 NAT 閘道

為彌補硬體不靈活，本文採用 FreeBSD 的 divert socket 與 ipfw 防火牆，開發自訂 NAT 守護行程 natd，實作支援動態負載演算法的軟體閘道。此架構易於擴充協定支援，並能整合更精細的負載度量模型。

動態負載平衡策略

傳統策略忽略請求類型差異與伺服器異質性。本文將請求分為兩類：

• 靜態文件請求：如圖片、文字，主要消耗網路 I/O 與磁碟 I/O，CPU 佔用低。
• 動態文件請求：如資料庫查詢、多媒體轉碼，大量消耗 CPU 與磁碟 I/O。

定義伺服器負載公式：

L = Ns + a × Nd + b × max(0, L_actual - Ll)

• Ns：靜態服務行程數
• Nd：動態服務行程數
• a：動態請求權重（10~100）
• Ll：硬體正常負載上限
• b：超載懲罰權重，與 Ll 成反比，避免弱效能主機在全叢集超載時仍分得最多任務

中心控制器定期從各後端伺服器的守護行程收集負載指標，將新連線導向負載最低的伺服器，達到真正的動態均衡。

FreeBSD 實作架構

核心元件

1. 後端伺服器守護行程：定期採樣 CPU、行程數、I/O 狀態，計算負載值並回報閘道。
2. 負載平衡閘道：運行於 FreeBSD，利用 ipfw 將封包導向 divert socket，由用戶空間 natd 依負載表重寫目的 IP 並重新注入核心路由。

優勢

• 純軟體實作，易於修改演算法、支援非標準協定。
• 可整合細緻負載模型（CPU、磁碟、網路分別監控）。
• 成本低，利用商用硬體即可部署。

實驗與效能分析

測試環境：三台 FreeBSD 伺服器以快速乙太網路互連。針對 HTTP 協定設計三類測試：

結果摘要

• 動態請求：隨伺服器數增加，吞吐量近線性成長，三台伺服器 CPU 利用率均達 95% 以上，負載分配理想。
• 小型靜態檔：三台伺服器 CPU 利用率僅 40% 左右，閘道 natd 進程佔用 76% CPU，成為瓶頸。
• 大型靜態檔：頻寬鎖定在 ~10 MB/s，natd 以鏈結串列維護連線狀態，演算法效率限制了網路效能。

瓶頸分析

所有封包必須經過閘道的 natd 處理，高併發、大流量時，用戶空間封包複製與鏈結串列查找成為系統瓶頸。後續優化方向：

1. 改用雜湊表或樹狀結構維護連線狀態，降低查找複雜度。
2. 將關鍵路徑移入核心模組，減少用戶/核心空間切換開銷。
3. 針對不同資源（CPU、磁碟、網路）分別監控，依請求特性導向最適合的伺服器。

結語

基於 NAT 的軟體負載平衡閘道有效解決後端 CPU 與磁碟 I/O 壓力，但閘道本身的網路 I/O 處理能力成為系統上限。透過演算法優化與硬體升級可進一步提升頻寬上限。未來工作將著重於多維度資源監控與核心級封包處理，構建更高效、彈性的負載平衡基礎設施。

參考文獻

1. E. Kata 等，《A scalable HTTP server: the ncsa prototype》，1994。
2. R. S. Engelschall，《Load Balancing Your Web Site》，1998。
3. Cisco，《LocalDirector Documents》，1997。
4. H. Zhu 等，《Adaptive load sharing for clustered digital library servers》，1998。
5. FreeBSD Core Team，《natd and divert manual pages》，1995。