經過負載均衡器+域名實現容災切換-（8）基於DNS解析的GSLB在BS架構中應用實踐（轉）（1）

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

摘自https://blog.csdn.net/windyf2013/article/details/79727348

原文：Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work  http://www.tenereillo.com/GSLBPageOfShame.htm

          Why DNS Based GSLB Doesn't Work, Part II   http://www.tenereillo.com/GSLBPageOfShameII.htm

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

 

摘錄

基於DNS的全局負載均衡（GSLB）解決方案是爲了提供互聯網DNS服務、以及標準DNS服務以外的其餘功能與特性。

本文闡述了大多數互聯網服務，比HTTP、HTTPS、FTP、流媒體、和其餘基於B/S架構的應用程序或協議，使用GSLB特性時會產生的問題。

此時我本應該加上「若是GSLB可以同時加強B/S架構互聯網服務的高可用性」，可是我沒有，由於人們老是預期GSLB解決方案能夠很好的部署高可用，這是「顯而易見」的。

本文從大互聯網的意義出發，探討了互聯網的行爲，固然也能夠建立自定義的解決方案。例如，有可能在客戶端計算機上運行特殊軟件，這樣的解決方案几乎是對於互聯網網站來講，歷來不是實用的，所以不在這裏討論。

 

THE Punch line

在DNS響應中返回多個A記錄，是GSLB高可用部署的最佳實踐。可是返回多個A記錄會從某種程度上影響GSLB的負載均衡特性（好比流量控制或站點選擇算法）。所以全局負載均衡（或多站點流量控制）的實際價值是值得懷疑的（見爲何基於DNS的全局負載均衡（GSLB）不起做用？ II）。人們必須在高可用和負載均衡之間作出妥協。下文會作出技術性的解釋。

 

GSLB的根本目標

多站點部署互聯網網站加強高可用性是沒法爭辯的，若是災難性事件致使一個站點不可用，其餘站點必須可以接替處理用戶的請求，這樣事務方可持續。下面給出一個例子，服務器站點分別部署在洛杉磯和紐約： 

 

互聯網鏈接失效，斷電事故、SLB設備故障、Dos攻擊或者災難性事件都會形成整個站點中止服務，GSLB設備必須檢測到故障而且將請求路由到其他的站點，以保證客戶端請求獲得響應，事務能夠繼續。

 

DNS 解析

出於完整性考慮，這節回顧一下使用GSLB的DNS解析過程。若是您是GSLB的專家能夠跳過這一部分。下圖展現了客戶端解析全域名（FQDN）www.trapster.net的 的步驟 

站點A在洛杉磯，使用虛IP 1.1.1.1。站點B在紐約城，使用虛IP 2.2.2.2。GSLB設備做爲www.trapster.net的權威名字服務器。當DNS請求到達GSLB時，GLSB負責決定返回1.1.1.1或 2.2.2.2。

1. 邊緣解析者（運行在客戶端PC上的軟件程序）向本地DNS發起解析請求，在這個例子中，「本地DNS」指的是客戶端在佐治亞州亞特蘭大的互聯網提供商（ISP）的DNS服務器。客戶端要麼收到DNS的解析結果，要麼收到錯誤消息。這種查詢叫作「遞歸」查詢。注：邊緣解析者不支持在互聯網上「挖掘」查詢出結果，「遞歸」這是DNS服務器的工做。 
2. 客戶端的本地DNS服務器爲客戶端代理「迭代」查詢，向根域名服務器查詢，並最終查詢到www.trapster.net 的權威名字服務器。在本例中GSLB作爲權威的名字服務器。 
3. GSLB同每一個站點的軟件或設備之間運行某種通訊程序，收集各個站點的信息，好比，站點的健康狀態、會話鏈接數、響應時間等。 
4. 每一個站點的軟件或設備運行某種動態特性的度量程序，好比測量該站點到客戶端local DNS服務器的往返時間（RTT）、地理間隔、BGP跳數等。 
5. GSLB使用從步驟3和4 收集到的信息，向客戶端的local DNS服務器返回計算最優的結果，這個結果是1.1.1.1 或 2.2.2.2 二者之一，若是DNS保活時間（TTL）不爲0，這個結果會緩存到客戶端本地 DNS服務器上，以便其餘共享該本地DNS服務器的客戶端能夠直接使用這個結果（不在重複步驟2-4）。

DNS 解析結束後，客戶端會向相對最優的站點創建TCP鏈接。

 

瀏覽器DNS緩存

 

IE瀏覽器、Netscape 瀏覽器、其餘瀏覽器、甚至Web 代理緩存程序和郵件服務器，都內建「DNS 緩存」。

DNS 緩存是一個小型數據庫，能夠將DNS解析結果存儲一段時間。一般狀況下，DNS結果的存儲時間由回答這條結果的權威DNS服務器指定，這段時間被稱做保活時間（TTL）。

不幸的是，瀏覽器的緩存不可以得到DNS服務器返回的TTL，這是由於DNS請求是由經過調用操做系統的gethostbyname()函數(或其餘提供相似功能的函數)完成的，該函數調用僅返回請求域名對應的一個或多個IP地址（該系統調用不容許請求應用程序獲取TTL）。爲了解決這個問題，瀏覽器的開發者引入了一個可配置的TTL值。在IE瀏覽器中，該值默認是30分鐘，能夠經過Windos 的註冊表修改。在Netscape中，這個值默認是15分鐘，能夠經過修改prefs.js文件中的一行來配置該值。

 

DNS解析請求的頻率主要取決於不一樣的瀏覽器。舊版的瀏覽器請求時間間隔是固定的，對應每一個站點，IE瀏覽器每30分鐘執行一次請求，Netscape是15分鐘，無論用戶/客戶端這個時間段內鏈接多少次該站點。點擊刷新，甚至其餘組合操做都不會改變這一行爲。惟一可以刷新瀏覽器DNS緩存的辦法就是退出而且重啓瀏覽器（或者重啓計算機）。在大多數情形下，「重啓瀏覽器」意味着關閉全部正在瀏覽的頁面，不光是出現鏈接問題的這個頁面——當頁面發生鏈接問題時，這件事（重啓瀏覽器），用戶不必定會自行去作。Microsoft 很早之前修復了這一問題。可是在最近的統計中（2007-8），仍有至關一部分的瀏覽器受該問題影響。更多關於DNS緩存與瀏覽器的問題請參見http://www.tenereillo.com/BrowserDNSCache.htm

 

瀏覽器緩存帶來的問題

瀏覽器緩存會給GSLB帶來至關大的影響。若是一個站點由於災難性的事故不能提供服務，全部當前鏈接到該站點的客戶端都會遭遇鏈接故障直到瀏覽器中的DNS緩存過時，或者用戶重啓瀏覽器或計算機。同時，任何指定緩存了失效站點IP的DNS服務器做爲Local DNS服務器的客戶端，也會遭遇鏈接故障。這顯然是不能接受的。

 

下圖能夠幫助展現這個至關嚴重的問題。以一個金融行業站點（提供證券、股票交易，網上銀行等）爲例，使用active/backup負載方案，該方案是最簡單，而且最普遍使用的GSLB配置，見下圖： 

虛構一個站點 www.ReallyBigWellTrustedFinancialSite.com，使用位於洛杉磯的站點A（1.1.1.1）做爲主要站點，站點B（2.2.2.2）做爲備用站點。

1. 爲了實現該方案。 www.ReallyBigWellTrustedFinancialSite.com 的DNS解析響應中需回覆惟一的結果，或者說「A 記錄」——IP 地址1.1.1.1。一個GSLB設備部署在互聯網上，使用最優秀的高級站點健康監控技術。 
2. 數千用戶鏈接在站點A，順利的進行交易事務，全部用戶將IP地址1.1.1.1緩存在其瀏覽器中。

如今災難發生了，以下圖所示： 

1. GSLB優秀的高級站點健康監控技術當即檢測到了故障。 
2. GSLB注意到站點B仍然健康，開始返回IP地址2.2.2.2，以便將新請求路由到站點B。 
3. 全部在線的用戶仍然將站點A的IP地址1.1.1.1，緩存在其瀏覽器中。GSLB沒有任何辦法通知這些用戶，由於這些用戶在瀏覽器緩存過時以前，不會發起新的DNS請求。

對於全部在線用戶，站點故障實際上持續了半個小時，徹底超出基於高級站點健康監測技術的GSLB設備的控制。

 

然而這還不是最壞的，狀況還會更糟，以下圖：

1. 一些新客戶端的瀏覽器緩存和local DNS服務器緩存中沒有解析結果1.1.1.1。這些用戶會請求www.ReallyBigWellTrustedFinancialSite.com 。 
2. 這些客戶端的local DNS會代理其發起迭代地址解析（至少會爲第一個請求代理解析），最終請求到GSLB，GSLB 會響應健康站點的結果——IP 2.2.2.2 ,一切都很正常。 
3. 然而一些客戶端的local DNS服務器緩存中已經有解析結果1.1.1.1，或者是由於這條結果中由GSLB設置的TTL沒過時，要麼是local DNS服務器器忽略了太低或爲零的TTL值（事實上，有些DNS服務器確實這麼作）。由於解析結果仍在緩存中，local DNS服務器不會向GSLB發起迭代請求，而且沒法感知到站點A——1.1.1.1 已經失效，所以這些新加入客戶端也會經歷半個小時的故障，徹底不受GSLB的控制。

解決瀏覽器緩存問題的方法

對於瀏覽器緩存問題有一個存在已久的解決方案，就是 權威DNS服務器（或GSLB）在解析響應中返回多個DNS結果（」A 記錄」）。

在解析響應中返回多個A記錄並非什麼訣竅。也不是負載均衡設備廠商的持有的特性。DNS協議在設計之初就支持在解析響應中返回多個A記錄。例如瀏覽器、代理服務器、郵件服務器等應用程序均可以使用該特性。

 

下圖展現了他是如何工做的： 

1. 客戶端請求解析FQDN www.trapster.net。 
2. 迭代查詢以後（未顯示），客戶端的Local DNS服務器返回兩個A記錄——1.1.1.1 和 2.2.2.2 （按照這個次序）。 
3. 客戶端向站點1的IP 1.1.1.1 創建請求。 

1. 當客戶端訪問站點A順利的進行商務活動時，一個災難性的事件致使站點失效。客戶端與站點A失去鏈接。 
2. 由於第二條A記錄2.2.2.2也包含在原始的解析結果中，客戶端會平滑的鏈接到站點B2。注意：這取決於商業應用程序的架構，一些鏈接狀態，好比登陸狀態、購物車、財務事項等，也許會由於災難而丟失，然而客戶端仍能夠在站點B繼續進行商務活動。

解析結果中回覆多個A記錄並不須要GSLB設備，不過大多數GSLB設備支持這一功能。全部重要的DNS服務器都支持回覆多個A記錄，基本上全部基於B/S的商業站點爲了應對瀏覽器緩存問題，都會在解析結果中返回多個A記錄。