經過負載均衡器+域名實現容災切換-（7）基於DNS解析的GSLB基本原理

==============================

DNS全局負載均衡（GSLB）基本原理

摘自： https://blog.csdn.net/hrl7752/article/details/80984240

==============================

原理

採用全局負載均衡（GSLB）的前提是在不一樣地區設立了多個數據中心，並非全部的互聯網服務都能作GSLB，前提是業務已經作了分佈式部署的規劃，不管用戶從哪一個IDC訪問都能獲得相同的結果，或者用戶基本不會出現跨區域流動訪問的狀況，只會訪問就近IDC，或者有一套入口調度機制，能將用戶調度到所屬的節點。

如今不少CDN也都提供動態內容的加速，只不過這個加速只是數據傳輸上的優化，能夠看作給你作了不少個轉發節點，最終業務處理壓力仍是源站承擔。若是不具有分佈式部署改造的條件，只是要解決遠距離客戶訪問慢問題，能夠考慮CDN。

目前不少DNS服務商都提供了智能DNS服務，智能DNS能夠經過多種負載均衡策略來將客戶端須要訪問的域名解析到不一樣的數據中心不一樣的線路上，好比經過各運營商分省IP地理信息數據來判斷用戶的就近性，並結合健康檢查策略（一般是發一個固定的http請求）來分配訪問量。

第三方智能DNS的不足在於經過公網健康檢查可能會受到運營商網絡擁塞的影響，目前國內域名服務商提供的服務目前還沒法感知線路繁忙程度和後端服務器真實負載狀況。除了使用智能DNS解析軟件或者雲服務，多數對可靠性和性能要求高的用戶都會使用硬件的全局負載均衡解決方案。全局負載均衡設備以經過更豐富的維度來判斷用戶就近性，造成就近性表，除了分地域IP數據庫外，還能夠經過TTL、用戶訪問延時、服務器負載狀況等來判斷。

下例的全局負載均衡解決方案中，域名服務商處將域名的NS記錄指向有智能DNS解析功能的GSLB設備，而後由GSLB設備來進行A記錄解析。若是在多地部署了GSLB設備，它們都應該添加到NS記錄中以保證高可用性，域名服務商處輪詢地返回GSLB地址或者一次性返回所有地址。GSLB設備會對本身所在的IDC後端服務器以及其餘IDC公網IP進行健康檢查，健康檢查結果會經過自有協議在不一樣IDC的GSLB設備之間同步，最終根據全局負載均衡策略來選擇最優的地址解析給用戶。

解析的步驟示意以下圖：

1. 用戶向本級配置的本地DNS服務器發出查詢請求，若是本地DNS服務器有該域名的緩存記錄，則返回給用戶，不然進行第2步；
2. 本地DNS服務器進行遞歸查詢，最終會查詢到域名註冊商處的受權DNS服務器，這裏可能有多個步驟，圖中只反映最後一步；
3. 受權DNS服務器返回一條NS記錄給本地DNS服務器。根據受權DNS服務器上的不一樣設置，這條NS記錄多是指向隨機一個GSLB設備的接口地址或者是全部GSLB設備的接口地址；
4. 本地DNS服務器向其中一個GSLB地址發出域名查詢請求，若是請求超時會向其它地址發出查詢；
5. GSLB設備選出最優解析結果，返回一條A記錄給本地DNS服務器。根據全局負載均衡策略設定的不一樣可能返回一個或多個VIP地址；
6. 本地服務器將查詢結果經過一條A記錄返回給用戶，並將緩存這條記錄。

經過DNS解析報文中的TTL（Time To Live）字段能夠控制客戶端緩存這條記錄的時間，在緩存時間內客戶端會使用舊的查詢結果，當緩存時間超時後纔可能從新發出查詢，TTL值過大會致使故障發生時切換時間過長，TTL值過小會形成查詢頻繁，對設備和網絡的壓力增大。

侷限性

請注意GSLB設備收到的DNS請求的源地址不是用戶的地址而是用戶所配置的本地DNS服務器地址，而GSLB的就近性探測是根據這個地址來判斷的，在我國大多數ADSL撥號上網用戶都能就近分配正確的數據中心，可是當用戶用戶經過4G移動網絡上網的狀況下，客戶會一直使用歸屬地的DNS服務器，或這手動設定本地DNS而設置的DNS距離用戶較遠的狀況，GSLB不能分配最佳的地址。這種狀況很常見，國內有不少人使用google的公有dns或者opendns。

這種狀況可使用重定向來解決，SLB設備正式收到用戶發來的請求時，會再次查找就近性表，當發現用戶的最佳訪問節點非本身時，經過http 302重定向來再次引導用戶流量。