全局負載均衡（GSLB）的實現方案

What is GSLB

Global Server Load Balancing

中文:全局負載均衡

SLB(Server load balancing)是對集羣內物理主機的負載均衡，而GSLB是對物理集羣的負載均衡。
這裏的負載均衡可能不只是簡單的流量均勻分配,而是會根據策略的不同實現不同場景的應用交付。

GSLB是依賴於用戶和實際部署環境的互聯網資源分發技術，不同的目的對應着一系列不同的技術實現。

Why GSLB

總結爲:

• 高可用性
• 更快的響應時間
• 多版本分發

具體：

1. Disater recovery,發生故障時提供一個備用的位置來獲取資源或者能提供可簡易調整流量的裝置，或兩者都能提供。

2. Load sharing,基於多個地理位置的流量分發，可以做到：

   a.儘量節省帶寬
   b.限制給定位置的能力
   c.限制暴露斷電,地理災害等問題

3. Performance,將資源置於離用戶更近的地方，增強用戶體驗。

4. 多版本,根據本地政策提供不同版本的資源，或者根據自定義的規則提供爲特殊用戶提供特殊版本，如灰度交付等。

How implements GSLB

主流的技術實現

DNS

GSLB會替代最終的DNS的服務器從而實現自己的解析策略，返回給用戶最合適的IP(列表)。

一個普通的DNS請求：

1 2 3 4 5

① 用戶提交域名 ② 客戶端解析域名 ③ DNS服務器解析出IP ④ 客戶端請求IP ⑤ 返回結束

加入了GSLB的請求：

1 2 3 4 5 6

① 提交域名 ② 客戶端解析域名 ③ NS解析到GSLB- ④ GSLB解析並返回IP ⑤ 客戶端請求IP ⑥ 返回結束

特點：

• 這個技術對原業務的侵入性最小，被商業ADC廣泛實現，如A10，F5等。

• 但是可以得到的信息很有限，IP的定位只能靠Local DNS，因爲得不到源IP.

HTTP redirection

使用HTTP重定向將內容轉發到不同位置.

a. 請求的域名均解析爲GSLB機器的IP.
b. GSLB根據源IP等信息解析出新的IP並使用HTTP重定向技術將用戶請求重定向到目標主機.

請求過程：

1 2 3 4 5 6 7

① 提交域名 ② 客戶端解析域名 ③ DNS解析域名爲GSLB ④ 客戶端提交請求給GSLB服務器 ⑤ GSLB解析出目標IP併發起HTTP轉發 ⑥ 客戶讀轉發請求到目標IP ⑦ 返回結束

特點：

• 這個方案只適用於HTTP.

• 這個方案的實現可以是L7負載均衡工具如Nginx、HTTPD等

IP Route

更改IP首部實現使用跳轉.並利用IP tunneling技術實現只對請求負載均衡(響應直接返回).

a. 請求的域名均解析爲GSLB機器的IP.
b. 負載均衡設備可以解析出目標地址,然後封裝IP包發給目標地址.
c. 目標服務器收到請求包並處理,解析出被封裝的IP包可以得到客戶端地址,把響應直接返回.

請求過程:

1 2 3 4 5 6

① 提交域名 ② 客戶端解析域名 ③ DNS解析域名爲GSLB- ④ 客戶端提交請求給GSLB服務器 ⑤ GSLB發送請求到目標服務器 ⑥ 目標服務器直接返回請求給客戶端結束

特點

• 這個方案能解決不能獲得源IP和HTTP Only的問題，也不會成爲性能瓶頸.但由於是IP層的LB，因此得到的信息很有限，也就是做分發的策略會很有限.*

• 實現方式主要就是LVS的VS/TUN模式.如果自己編寫會更靈活，但難度較大.*

統一調度服務層

客戶端SDK+調度服務完成GSLB設備的功能。

a. 客戶端使用原地址請求服務時，SDK會交付一個解析過的地址給客戶端.(或對網絡請求模塊做Proxy)
b. SDK會通過一定的策略從調度服務中獲取解析地址(一個或多個).
c. SDK和調度服務會某種形式保持聯繫(HTTP or TCP).
d. 出於性能考慮，SDK本身有Cache功能同時有時效限制(TTL)。

調用試請求過程:

① 客戶端請求
② 調用SDK
③ SDK沒有命中緩存
 ④ SDK請求調度服務
 ⑤ 調度服務返回新地址
 ⑥ 客戶端用新地址發起請求

代理式請求過程:

① 客戶端發起請求
② 網絡請求Proxy攔截請求
③ Proxy沒有命中緩存
④ Proxy請求調度服務
⑤ 調度服務返回新地址
⑥ Proxy請求新地址

特點

• 讓客戶端(SDK)具備了負載均衡知識,而因此讓服務端可以獲得任何想要知道的信息，從而可以做更全面的解析策略，但侵入性是最大的。

常見策略實現

1. 地理區域。地理&IP表。
2. IP權重，爲每個IP分配權重，權重決定流量比例。
3. 往返時間RTT，分active RTT(請求時ping)和passive RTT(採集tcp的syn->act的時間)。
4. 業務自定義條件,如根據語言,UserID等.

方案的對比

方案1：

工具：使用現有的商用解決方案：F5，A10 Thunder.
優點：
  能靈活配置GSLB,滿足就近選擇，位置備份等基本GSLB需求。
  除了GSLB以外，還能帶來對性能和安全的全解決方案，如防DDos，硬件加速SSL加解密等等。
  當我們的業務羣越來越龐大時，這些需求會越來越迫切。

缺點：
  貴。

方案2

工具：編寫HTTP轉發服務或使用Nginx,HTTPD
優點：自由實現，HTTP層可獲取的信息更多因此LB策略更靈活.
缺點：只能是HTTP的轉發，另外可能會成爲性能瓶頸.

方案3

工具：使用LVS的VS/TUN模式
優點：free
缺點: 能實現的LB策略只能是LVS所支持的那些，如果想自己定義似乎不可能。

方案4

工具：編寫統一調度服務
優點：有HTTP轉發的所有優點，而且不需要流量經過，因此性能要比HTTP轉發高很多。
缺點：
  1. 需要客戶端的參與。（基本排除了瀏覽器和升級困難）。稍顯複雜的緩存策略。
  2. 這個服務會成爲一個`移動接入層`，將會具備相當規模。(成本)。

總結

選擇方案首先選擇能完全滿足自己業務需求的方案.然後在從中選擇功能&性能/價格比最高的.

以上四個方案，也可以分爲L7層和其他.對於需要更多業務信息參與的負載均衡，則必須從7層協議入手.

方案2和方案4都可以解析7層協議的內容，其中方案4則能更靈活的實現通用的負載均衡,條件是必須有客戶端的支持.因此如果能解決客戶端的問題則方案4是比較好的方案，否則只能選擇方案2了.

另外也不一定選擇一種方案，能有效結合這些方案會使負載均衡能力更強大.

比如方案4無法干預瀏覽器的請求,這個時候就需要使用其他方案來彌補(方案1,2,3皆可).

同時還要區分動態資源和靜態資源的請求，以上方案主要使針對動態資源的負載均衡,對於靜態資源,CDN提供了更好的解決方案.

---

參考資料：

Citrix的NetScaler說明書： http://support.citrix.com/servlet/KbServlet/download/22506-102-671576/gslb-primer_FINAL_1019.pdf

GSLB和CND: http://blog.csdn.net/u010340143/article/details/9062213

智能DNS: http://www.cnblogs.com/peon/archive/2007/12/30/1021219.html

負載均衡: http://blog.arganzheng.me/posts/load-balance.html

LVS: http://www.linuxvirtualserver.org/zh/lvs1.html