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

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

摘自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

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

 

An Axiom

對於GSLB，惟一可以實現高可用的方法就是在DNS解析結果中包含多個A記錄。

高可用實現有超多的替代的解決方案，可是沒有一個可以真正奏效（見下文「替代方案」 ），除了修改全部可能訪問該站點PC的註冊表，在解析結果中回覆多個A記錄是惟一的方法。

 

爲何多重A記錄會抵消GSLB的負載均衡算法？

就像前文提到的，DNS服務器可以在解析結果中返回多重A記錄。GSLB設備一樣也能夠返回多重A記錄。即便互聯網站點已經擁有DNS服務器（或購買了DNS解析服務），互聯網站點的擁有者仍會採購GSLB設備，一般每臺高達$30000，爲的是得到那些比普通DNS服務器能提供的更多的特性。 

問題來了：

 

這些特性中，沒有一個特性能夠同多重A記錄配合使用 。

 

簡單的站點Active/Standby算法不行、靜態的站點偏好算法不行、基於IANA的站點偏好算法不行、DNS persistence 算法不行，RTT或步長檢測算法不行，基於Geotargeting的重定向也不行…沒有任何一個特性能夠！下圖就來展現爲何： 

 

基於GSLB的DNS解析前面已經闡述過了（爲了簡便，像健康檢查、RTT測量等步驟這節就省略掉了）。 

1）咱們假設GSLB設備設置站點A爲首選站點，IP地址1.1.1.1 ,它在解析響應中按照以下順序返回解析結果： 

 - 1.1.1.1 

 - 2.2.2.2 

2）客戶端的Local DNS 收到解析結果後，將結果緩存。此時Local DNS將結果返回給客戶端，順序多是： 

 - 1.1.1.1 

 - 2.2.2.2 

 或者： 

 - 2.2.2.2 

 - 1.1.1.1

 

目前，幾乎全部的商用GSLB設備都會返回有順序的多重A記錄，一般被稱爲「順序列表」。設想預約的結果順序會一成不變穿越互聯網傳遞給DNS請求者，不幸的是，這個設想是錯誤的。

 

實踐證實：DNS解析結果的地址順序會被客戶端的Local DNS 篡改！

 

Local DNS服務器篡改解析結果中的地址順序是爲了平衡去不一樣站點的流量，這是大多數提供商DNS服務器的默認動做。曾經有想法是將DNS響應結果的TTL設置爲0，來避免Local DNS篡改順序。可是很是不幸，解析結果的順序仍會被篡改，徹底不受GSLB或權威名字解析服務器的控制，這種狀況下，肯定性的控制客戶端優先訪問某一站點是不可能的。

 

網站Cookies:猜怎麼着？依然不能奏效！

大多數多地部署的 網站都要求會話的持續 。換句話說，如何一個客戶端鏈接到了站點A，那麼必需要保證在整個會話期間，客戶端一直鏈接在站點A。即使是站點已經很好的同步以適應某種級別的會話持續，而後實時同步是不可能作到的。

 

瀏覽器DNS緩存是解決會話持續的一線但願。客戶端解析了www.trapster.net 以後，獲得結果是站點A---IP 1.1.1.1，客戶端會持續鏈接到站點A直到瀏覽器緩存過時。前面提到過，IE的過時時間是30分鐘，Netscape是15分鐘。很明顯，單獨使用這個方法不能知足超過30分鐘（或15分鐘）的會話的持續性，由於超時後瀏覽器會從新解析域名，這時客戶端可能會鏈接到錯誤的站點。同時，不論30分鐘或15分鐘，都是固定的時間段，不是客戶端中止使用的等待時間。例如，一個用戶訪問了www.trapster.net，而後接了29分鐘電話，掛斷了電話後，繼續瀏覽www.trapster.net 開始訂購某些商品，瀏覽器會在一分鐘後從新解析，極可能將用戶引導到錯誤的站點。

 

DNS緩存時間超時問題是衆所周知的，所以基本上全部的SLB(服務器負載均衡)都會去解決這一問題。使用一種被稱爲「站點 cookie」的方法，一般只爲HTTP協議部署（也有一些廠商爲流媒體協議實現了該方法）。 

1. 客戶端解析www.trapster.net的結果——站點A、IP地址1.1.1.1。客戶端鏈接到站點A，開始商務事務。在鏈接到站點A的同時，站點A的SLB設備植入了HTTP cookie，該cookie 指明瞭客戶端須要持續鏈接哪一個站點（甚至是具體的服務器）。 
2. 通過一段時間，客戶端瀏覽器的DNS緩存過時後，客戶端會從新解析，此次的解析結果是站點B、IP 地址2.2.2.2，該地址將會在客戶端瀏覽器中緩存30分鐘（或15分鐘），客戶端如今向站點B創建鏈接，當客戶端鏈接到站點B，其發送的站點cookie 代表客戶端的當前會話須要鏈接站點A。 
3. 站點B的SLB設備讀取這個cookie後，發送了一個條HTTP重定向。HTTP重定向中的FQDN部分不能是www.trapster.net，由於該域名對應的解析結果2.2.2.2，仍然緩存在客戶端的瀏覽器中。同時，也不能使用地址1.1.1.1重定向，由於若是不使用DNS域名作重定向，服務器軟件和SSL認證一般不能正常的工做。由於這個緣由，一般使用一個站點獨立的FQDN。在這個例子中，HTTP重定向的域名多是www-a.trapster.net（或 site-a.www.trapster.net）。 
4. 客戶端如今用www-a.trapster.net 從新鏈接原來的站點繼續商務事務。 

以下圖展現： 

 

通過一段時間，尤爲是站點經歷了很長的會話時間（好比股票交易或財經站點），很大比例的用戶會經過站點獨立的FQDN鏈接到網站。即便通過短暫的會話時間，有些用戶也會使用到站點獨立的FQDN www-a.trapster.net。

 

由於有用戶已經使用了www-a.trapster.net，爲了高可靠性考慮，不只僅須要爲www.trapster.net使用多重A記錄，並且還要爲www-a.trapster.net使用多重A記錄。若是IP 1.1.1.1 和 IP 2.2.2.2 都包含在www-a.trapster.net 的解析結果中，如前文所述，客戶端可能會鏈接站點A，也多是站點B!

 

站點cookie 不能很好的與多重A記錄一塊兒工做，同GSLB不能很好的與多重A記錄一塊兒工做的緣由同樣！

 

GSLB站點健康檢查有用嗎？

咱們已經證實了 多重A記錄是有必要 的，可是剩下的問題是 「他們能勝任基於B/S架構的站點嗎？」 。

當收到包含多重A記錄的解析結果後，基於瀏覽器的客戶端使用它們本身的「健康檢測」方法，這就是爲何多重A記錄會設計在DNS協議中。也許有這樣的情形，要求GSLB在解析結果中不返回已經檢測到失效站點的A記錄，可是也有不少情形要求返回失效站點的A記錄，即便明確檢測該站點失效。這一節就展現這樣一個情形，許多種類的故障是很短暫的，換句話說，一樣的問題可能會在不一樣站點間次序的或同時的出現。例如： 

1. 電力故障也許會影響一個區域的數據中心，而且當電纜網絡調整期間，也許會影響其餘地區的數據中心。 
2. 拒絕服務器攻擊(DoS)一般攻擊指定的IP地址。一次DoS攻擊也許會先攻擊IP地址1.1.1.1，而後再攻擊IP地址2.2.2.2。 
3. 電腦病毒也許會先影響數據中心A，也許會花半小時來人工的殺除病毒，在這期間，該病毒也許會在數據中心B爆發。 
4. ISP內部網絡出現問題，一個路由器問題會同時影響一個國家不一樣區域的網絡。

根據前面的例子，站點A使用IP地址1.1.1.1，站點B使用IP地址2.2.2.2，若是一臺SLB或GSLB設備（或者是綁定的某個健康檢測腳本），發現站點A失效了，應該在解析結果中只返回單一的A記錄2.2.2.2嗎？若是站點B使用IP地址2.2.2.2隨後也發生了故障，可是站點A在半小時的窗口中，從故障恢復，這種狀況下最好仍是一直返回兩個站點的A記錄，即便健康檢測進程檢測到了失敗。記住，返回多重記錄不多是拔苗助長的，由於客戶端會自動地鏈接A記錄列表中健康的站點，不須要人工干預。

 

替代方法

還有一種不太嚴重的故障會發生。一個站點的全部服務器故障，然而站點的電力、互聯網鏈接和SLB設備都工做正常。此類問題有許多商業上可用的解決方案，包括backup redirection, triangulation，proxying，或NATing。爲了完整性這裏會討論一下這些解決方案，可是這節會說明，這些解決方案雖然能夠解決不太嚴重的服務器故障，可是並不能解決更重要的站點故障問題。

 

Triangulation

Triangulation 是一種鏈接恢復方法，對全部的IP 協議都適用。 

1. 客戶端已經鏈接到站點A，正常的瀏覽網站。 
2. 站點A的全部服務器故障（可是在這個例子中，SLB、互聯網鏈接、交換機、路由器、電力等設備都正常）。運行在站點A的SLB上的軟件檢測到了服務器故障，固然全部的存在的TCP鏈接都會丟失，可是客戶端會嘗試重連。在站點A的SLB與站點B事先有預創建的TCP隧道，站點A的SLB將客戶端的新鏈接請求經過TCP隧道轉發給站點B。 
3. 站點B的SLB設備選擇一個新服務器爲該客戶端提供服務，而且使用冒名的地址1.1.1.1將數據包直接返回給客戶端。

Backup redirection

Backup redirection 只對應用層支持重定向的協議有效（好比 HTTP、HTTPS、一些流媒體協議等）。 

1. 客戶端向站點A發起請求，請求的URL是FQDN www.trapster.net，已經解析爲IP地址1.1.1.1。 
2. 站點A的SLB發現全部的服務器都故障了，因而發出一個HTTP重定向引導用戶去鏈接站點B。這裏的重定向必須使用一個不一樣的FQDN，能夠是www-b.trapster.net。若是HTTP重定向使用www.trapster.net，客戶端的會使用已經緩存的地址（1.1.1.1）從新連回站點A。而且HTTP重定向可能不可使用IP地址，由於大多數的服務器、SSL認證等，須要客戶端經過FQDN訪問站點，而不能是IP地址。 
3. 客戶端如今訪問站點B。

IP proxy 和 NAT

IP proxy（和NAT）對全部的IP協議都有效，這裏不詳細介紹他們了。這兩個方法，在發現站點A的全部服務器故障後，會將客戶端的鏈接負載均衡到站點B的VIP(2.2.2.2)上，就像將客戶端鏈接負載均衡到本地服務器同樣。

 

Triangulation、backup redirection、IP proxy和NAT的問題

這些方法確實會對站點故障快速恢復有所幫助，但只能是在 互聯網鏈接、網絡設備、電力和本地SLB設備都工做正常的狀況下起做用 ，換句話說， 僅當服務器故障時有效 。若是 這些方法同多重A記錄一同使用，這些方法的可否起做用是值得懷疑的 。若是單獨使用這些方法，而不使用多重A記錄，等因而「丟了西瓜揀芝麻」。若是不將站點的災難性故障考慮在內，那也沒有什麼強有力的論據去使用GSLB。看來最好是徹底忘掉GSLB，丟棄那些花費和複雜性，將全部的服務器彙集在一個數據中心，而不是兩個，使用冗餘的電力、網絡鏈接、網絡設備、和SLB設備。

 

這就是說，即便在災難狀況下的高可用是對GSLB最基本的需求，GSLB也只能在特定狀況下知足，所以：

對於高可用的需求，Triangulation、backup redirection、IP proxy和NAT，這些方法都不能知足，或者說不須要。基於瀏覽器的客戶端仍須要使用多重A記錄。

 

BGP主機路由注入

還有一個解決方案，一般被叫作BGP主機路由注入（HRI），同時，至少有兩家廠商也叫作「Global IP」。他並非簡單與GSLB配合的備選方案，而是一種用來替換基於DNS的GSLB的解決方案。下面是其原理的概述： 

  

1. 客戶端發起DNS解析，www.trapster.net 的解析結果中只有一個IP地址——1.1.1.1。
2. 站點A和站點B的SLB設備（或路由器）都向互聯網宣告了地址1.1.1.1。互聯網路由器將1.1.1.1的路由信息經過BGP傳播，同時交換度量值，最終將路由信息傳播給距離客戶端最近的互聯網路由器，該路由器選擇度量值最小的路徑，將1.1.1.1的路由加入路由表。 
3. 客戶端此時鏈接拓撲上最近的站點。

此時發生了服務器（所有）故障，或互聯網鏈接故障、電力故障、SLB設備故障、網絡設備故障等災難性故障：

1. 站點A的SLB設備發現了服務器故障，中止經過BGP向互聯網宣告IP地址1.1.1.1(或 SLB、互連網鏈接被破壞，這種狀況下宣告顯然會中止)。 
2. 路由在互連網設備間收斂，前往站點A的路由條目最終會被刪除。 
3. 客戶端從新創建鏈接，仍鏈接IP 1.1.1.1,但此次鏈接的是站點B。

雖然在理論層次上，這個方案實現的功能像是GSLB求之不得的，可是它不多真正部署實現，下面闡述了爲何： 

• 互聯網的路由至關複雜，在不一樣地區宣告同一個IP地址的實踐，工做的並不可靠。在客戶端的會話期間，若是發生路由變更，數據包會在站點A和站點B之間斷斷續續的傳輸，此時，即便兩個站點均可以正常工做，客戶端依然不能正常訪問。 
• 路由收斂的時間會至關的長。當站點發生故障後，客戶端的瀏覽器會超時，會跳轉訪問失敗的頁面。若是用戶手動的持續嘗試訪問，最終鏈接會恢復，可是故障恢復時間超過5分鐘也是有可能的，這麼長時間的故障對於商業站點來講是不能接受的。
•  BGP宣告的單個IP地址（主機地址）一般會被互聯網路由器忽略。一個可能的解決方式是宣告整個網絡地址段，然而僅僅爲了GSLB這麼作，等同於浪費昂貴的公網IP地址資源(由於僅僅一個地址，或一小部分地址會被實際使用到)。 
• 爲了安全考慮，路由器上會配置源地址過濾（有時叫作「bogon」過濾），源地址過濾會防止從不一樣的地域宣告同一IP地址。這個問題一般能夠經過與ISP協商解決。儘管如此，即便與ISP協商去掉了源地址過濾，一般還會有人疏忽的從新加上去，這一般會形成站點失去互聯網鏈接，須要故障報修處理等。

BGP HRI在站點分佈在較小地域範圍的網絡中算是個健全的解決方案，也許能夠用於一些互聯網應用，可是部署至關的少見，由於它在實踐中的表現遠遠不如理論分析的好。

 

結論

實現B/S架構的GSLB高可用，惟一的方法就是在解析響應中返回多重A記錄，可是返回多重A記錄，會破壞目前任何站點選擇算法的做用。 由於這些特性，好比基本的active-standby算法、DNS persistence算法、基於RTT或步長或BGP跳數的站點選擇算法、基於IP地址geotargeting或基於IANA的站點選擇都不能奏效。

 

好消息是，如今消費者能夠將本來花GSLB上的每單元$30000，用在購置更多的服務器和提高站點內部同步能力上!

 

Watering it down

冒着混淆前文理論的風險6，寫了下文：

 

至少在理論上，GSLB設備能夠以某種 「最佳選擇+輪詢」 的模式運轉，例如若是一個FQDN在歐洲有兩個站點，在美國有兩個站點，對於歐洲的客戶端，爲了更好的服務，GSLB只返回位於歐洲的兩個站點的A記錄給客戶端的Local DNS服務器。客戶端的Local DNS服務器會在兩個站點間輪詢負載。見下圖： 

1. 在這以前（沒有在圖上顯示），客戶端請求解析FQDN www.trapster.net，最終解析請求迭代到了www.trapster.net的權威服務器，也就是GSLB設備。GSLB執行站點選擇算法，爲客戶選擇法蘭克福和巴黎站點，排除洛杉磯和紐約。 
2. GSLB返回兩個站點的IP 1.1.1.1 和2.2.2.2。 
3. 解析結果中的A記錄順序會被客戶端Local DNS服務器打亂，可是在這個例子中，該行爲是可接受的，客戶端會鏈接法蘭克福或巴黎站點。

爲了更好的說明，我隨便選擇一個術語「區域」，來描述這個GSLB拓撲結構。 

上文提到的站點A和站點B被劃分爲「歐洲GSLB區域」，站點C和站點D劃在「美國區域」。這個方法，只有在網站的站點分佈在全球，且劃分爲不一樣的區域，每一個區域至少包含兩個數據中心互爲備份，這種狀況下，才能被全局負載均衡。若是www.trapster.net的數據中心分佈在倫敦、紐約、東京，那麼「最佳選擇+輪詢」的模式就不會奏效了。某一客戶端在倫敦，GSLB須要返回倫敦站點的A記錄（地理位置最近的站點），同時它必須至少返回另外一個站點的IP（紐約或東京，兩個站點與倫敦的距離都不近）。客戶端會鏈接倫敦的站點或者鏈接其餘的站點。很明顯，這明顯違背了GSLB站點選擇算法的初衷。同時，一些站點選擇算法（例如步長計算）不能在「最佳選擇+輪詢」模式下工做（留給讀者來思考），DNS persistence 算法也不能同「最佳選擇+輪詢」協同。即便這個複雜的實現能夠爲超大的全球站點服務，對於本文討論的案例來講該方法並非一個通用的解決方案。

 

 

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

 

對於基於瀏覽器的客戶端來講，若是與返回多個A記錄的慣常作法結合起來，基於全局服務器負載均衡 (GSLB)的DNS沒法正常生效。Part 2 在忽略多A記錄的高可用性因素狀況下，涵蓋了一些與基於GSLB的DNS的其餘問題。

  在GSLB的DNS工做原理Part 1已經描述，這裏再也不重複。

 

DNS解析時的就近路徑問題：

問題一：客戶端一般在地理上不接近器緩存DNS服務器。

基於GSLB的DNS解析過程當中，沒有任何一個GSLB設備可以肯定實際客戶端的IP地址和位置。由於和惟一和GSLB直接通訊的設備是客戶端的緩存DNS服務器。GSLB必須假定客戶端在地裏上接近其緩存DNS服務器，不幸的是，這個是很差的假定。

 

下圖展現了兩個客戶端及其各自的緩存DNS服務器的地裏關係：

• Author位於卡爾薩德，Author的客戶端一般被分配到位於20英里外的一個主DNS服務器（緩存DNS服務器），位於聖迪伊戈，在美國聖迪亞哥。
• Author的家庭成員也生活在卡爾斯巴德，但使用的一個Service的全部主機的緩存DNS服務器位於亞特蘭大，大約2000英里之外。