摘要
GSLB 是 Global Server Load Balance 的縮寫，即全局負載均衡。本文首先介紹了什麼是負載均衡 SLB ，以及為什麼要使用 SLB 。接著引出全局負載均衡 GSLB 的概念和作用。為此介紹了其基於 DNS 進行解析和分配負載的實現，包括 DNS 的原理簡介、應用部署中的基本概念、分配負載的決策條件等內容。以外，本文還簡單介紹了通過 HTTP 和 IP 實現 GSLB 的方式，並對三者的優缺點進行了簡單對比。最後是本文的參考文獻。
關鍵詞: GSLB , DNS, CDN
目錄
- 1. 負載均衡 SLB
- 1.1 SLB的簡介與作用
- 1.2 SLB關鍵技術
- 2. 全局負載均衡 GSLB
- 2.1 GSLB的簡介與作用
- 2.2 DNS原理簡介
- 2.3 基於DNS的GSLB
- 2.4 GSLB的其他實現方式
- 3. 參考文獻
一、負載均衡 SLB
1.1 負載均衡及其作用
負載均衡(Server Load Balance, SLB)，其含義是將負載(工作任務)平衡分散到多個服務器上。CDN是典型的負載均衡集群系統。
圖1.1是負載均衡的示意圖。從圖中可以看出，負載均衡設備可以在用戶請求到達服務器之前將其截獲，然後將其分發到合適的後端服務器。
也就是說，客戶端發出的請求，首先會到負載均衡設備的IP地址上。因為該IP地址並不負責處理實際的業務，所以通常將該地址稱為【虛擬IP】(Virtual IP, VIP)。
後端真正的業務服務器被稱為【真實服務器】(Real Server, RS)，其IP地址被稱為【真實IP】(Real IP, RIP)，負責處理業務。
舉個例子，VIP 就像是前臺招待，會告訴你辦什麼事該去哪個房間。而RIP是內部實際辦業務的房間號。
利用負載均衡，很大程度上可以避免單個服務器過載或者閒置，前者會引起服務能力下降，後者則沒有充分利用資源。因此，為了達到更好的系統處理能力，需要進行以下兩個步驟：
1.在集群前端部署負載均衡設備
2.根據預先配置的均衡策略，在集群中智能分發用戶請求
1.2負載均衡關鍵技術
要做到負載均衡，需要的問題包括但不限於以下幾個方面
請求的分發
會話保持
服務健康監測
故障隔離
自動恢復
1.2.1 請求分發算法
請求分發算法，可以分為【靜態算法】和【動態算法】兩大類。
靜態算法
靜態算法是指按照預先設置好的策略進行分發，而不考慮服務器當前的實際負載狀況。
這類算法包括輪詢、加權輪詢、基於源IP或目的IP的hash算法等等，優點是簡單快捷。
動態算法
動態算法指的是能夠根據當前服務器狀況進行分發，包括最小連接，加權最小連接等。
1.2.2 會話保持
出於一些業務的特殊要求，有時候需要進行會話保持，以保證一段時間內，某一個用戶與系統的交互（會話），只交給同一臺服務器處理。
例如，大多數電商應用需要用戶認證，而一次交易需要與服務器多次交互才能完成。這幾次交互必須由同一臺服務器處理，而不能被分散到不同服務器上。
會話保持有以下幾種方法：
源IP地址的持續性保持
cookie 持續性保持
基於HTTP報文頭的持續性保持
1.2.3 服務器健康檢測
為了保證服務質量，需要定時進行健康檢測。我們可以利用ICMP、TCP、HTTP、FTP等協議進行檢測，即主要是在傳輸層和應用層進行檢測。
應用層的檢測顆粒更細，但對系統的要求也比較高，因為需要針對應用層的不同的協議做不同的識別分發機制。應用層檢測用的比較多的就是HTTP協議，比如先和集群中的設備建立連接，然後發出請求，如果收到正確應答，則說明HTTP處理正常。
傳輸層的檢測，主要在於能否建立TCP連接，迴響是否正常，等等。
二、 全局負載均衡GSLB
2.1 GSLB的簡介與作用
GSLB, Global Server Load Balance, 即全局負載均衡。
由於現實中存在各種不穩定因素，比如某個服務器集群所在的數據中心斷電，洪水或者地震造成數據中心癱瘓等等。在一個數據中心內，無論採用怎樣的技術，總可能存在一些不可抗因素，導致其癱瘓。所以通常會把服務器分散部署到多個數據中心，以最大程度減小災害對服務質量產生影響的概率和程度。
另外，CDN系統總是希望用距離用戶最近的設備為其提供服務，這也需要在不同地域部署多個節點。
GSLB系統就是針對這個問題的。它負責多個CDN節點之間相互協作，將各節點和設備的負載保持在一個有利於提供優質服務的水平。GSLB的負載均衡結果可能直接將用戶分配到RS，也可能將用戶交付到下一層次的負載均衡系統。
經過多年發展，已有多種調度機制可實現CDN的全局負載均衡。其中最常用的是基於DNS的GSLB。
2.2 DNS簡介
2.2.1 DNS工作流程
DNS是一個應用層協議，但它通常被其他的應用層協議使用，以便將主機名(host)解析為IP地址。DNS的工作流程如圖2.1
在第4步中,本地DNS服務器(Local DNS, LDNS)在得到瀏覽器解析的域名請求後，會採用迭代或遞歸查詢的方式，向DNS 系統中其他遠程域名服務器提出查詢請求，如圖 2.2 所示。
如果LDNS中沒有關於這個域名的緩存，則首先會去根域名服務器請求解析.root，收到其返回的.com域的域名服務器列表。LDNS在該列表中選出一個域名服務器，對其發出域名解析請求。
被請求的.com域的域名會查找CDNbook.com的權威域名服務器的IP，並將其返回給LDNS。
由於這個權威域名服務器是CDNbook.com這個域名授權的，所以LDNS對權威域名服務器請求後就能得到www.CDNbook.com的IP地址，並將其返回給客戶端。
另一方面，如果在LDNS上有的緩存記錄，就可以直接把這個結果返回給客戶 端，節省了中間的遞歸查找步驟時間和資源開銷。
2.2.2 DNS記錄的類型
DNS服務器是根據資源記錄來對DNS請求進行應答的。其中，最常見的是Internet類的記錄(Class IN)。Internet類的記錄主要有以下幾種類型(Type):
A記錄
A記錄即地址Address記錄，對應的value是域名的IP地址。
NS記錄
域名服務器Name Server記錄，保存了下一級域名信息的服務器地址。該記錄只能設置為域名,不能設置為IP地址。
CNAME記錄
規範名稱記錄Canonical Name for an alias，也稱為別名記錄，其value是另一個域名。也就是說，將原域名key映射到了另一個域名value。
舉個栗子。百度的域名是www.baidu.com，它的cname是www.a.shifen.com。
那麼，我們已經有了一個域名了，為什麼還要設置cname呢？假設有www.vzhiliao.com和mail.vzhiliao.com，其cname都指向host domain.cloudomic.com。
然後某一天，我們的服務器地址(A記錄對應的IP地址)可能要變了。由於www和mail都會被引導到domain.cloudomic.com，所以這時我們只需修改domain.cloudomic.com的A記錄，而不必把www和mail的A記錄都改一遍。
因此cname增加了靈活性，在子域多的時候更為明顯，相當於進行了批量管理。
RR記錄
資源記錄Resource Record。一個主機名可以對應多個IP地址，在一個DNS應答報文中可能含有多條RR信息。
下面我們使用nslookup來對上述的幾個定義進行具體說明。
$ nslookup www.baidu.com # 返回如下響應 Non-authoritative answer: www.baidu.com canonical name = www.a.shifen.com. Name: www.a.shifen.com Address: 112.80.248.74 Name: www.a.shifen.com Address: 112.80.248.73
首先，www.baidu.com沒有A記錄，但是通過cname被引導到了www.a.shifen.com.。
其次，www.a.shifen.com有2條A記錄，也就是一個主機對應了2個IP。實際上，如果在不同地區進行DNS請求，則最後得到的這2條A記錄也不同。
C:\Users\huangjiatao>nslookup www.baidu.com 服務器: one.one.one.one Address: 1.1.1.1 非權威應答: 名稱: www.wshifen.com Address: 103.235.46.39 Aliases: www.baidu.com www.a.shifen.com
現在我採用香港VPS進行請求的結果是103.235.46.39。這麼做是為了將不同地區的用戶分配其最近的服務節點，以便快速訪問。後面的內容將會解釋這一點。
//未完待續
三、參考文獻
- 雷葆華. CDN技術詳解[M]. 電子工業出版社, 2014.
- CDN簡介
- DNS原理入門
- Content Delivery Network - wikipedia
