為什麼基於DNS的全域負載平衡（GSLB）不起作用？

標籤：

Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work

Pete Tenereillo
3/11/04
Copyright Tenereillo, Inc. 2004

序言

弗雷德：喬，我要去趕一班飛機，從好萊塢到洛杉磯國際機場需要多長時間？
喬：恩。。。這取決於你走哪條路。
弗雷德：恩。。。我覺得我應該走高速公路，對吧？
喬：好吧，這是一個技術性問題，我能回答它。如果以60km/h的速度，走高速需要20分鐘。
弗雷德：好的，謝啦。
（費雷德登機前一小時去了羅迪歐大道購物，然後在去洛杉磯國際機場的路上堵了兩個小時，錯過了航班。）
弗雷德：(在電話裡)喬，交通太糟糕了，我錯過了我的航班！，你說過路程只需要20分鐘！
喬：噢，你沒有問在交通擁堵的情況下需要多長時間啊。
弗雷德：每天這個時間段交通都很糟糕嗎？
喬：你在開玩笑嗎？交通一直很糟糕，這可是洛杉磯！

一個問題的答案在給定的條件下可能是正確的，但是如果答案忽略已知的細節，那就失去了討論的意義。也許作為技術人員我們很希望每一個問題都有解決方案，因此有時候我們忽略了最顯而易見的東西。也許有太多細節需要考慮會讓我們犯糊塗。抑或有些細節過一會我們就忘記關注它了。

摘錄

基於DNS的全域負載平衡（GSLB）解決方案是為了提供互連網DNS服務以及標準DNS服務之外的其他功能與特性。本文闡述了大多數互連網服務，比HTTP,HTTPS,FTP,流媒體，和其他基於B/S架構的應用程式或協議，使用GSLB特性時會產生的問題。此時我本應該加上“如果GSLB能夠同時增強B/S架構互連網服務的高可用性”，但是我沒有，因為人們總是預期GSLB解決方案可以很好的部署高可用。這是“顯而易見”的。

THE Punch line

在DNS 響應中返回多個A記錄，是GSLB高可用部署的最佳實務1，但是返回多個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 Proxy緩衝程式和郵件伺服器，都內建“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記錄。例如瀏覽器、Proxy 伺服器、郵件伺服器等應用程式都可以使用該特性。

展示了他是如何工作的：

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記錄。

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要求者3，不幸的是，這個設想是錯誤的。

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

Local DNS伺服器篡改解析結果中的地址順序是為了平衡去不同網站的流量，這是大多數供應商DNS伺服器的預設動作4。曾經有想法是將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緩衝到期後，用戶端會重新解析，這次的解析結果是Site 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記錄。5

BGP主機路由注入

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

0）（用戶端發起DNS解析，www.trapster.net 的解析結果中只有一個IP地址——1.1.1.1。）
1）網站A和網站B的SLB裝置（或路由器）都向互連網宣告了地址1.1.1.1。互連網路由器將1.1.1.1的路由資訊通過BGP傳播，同時交換度量值，最終將路由資訊傳播給距離用戶端最近的互連網路由器，該路由器選擇度量值最小的路徑，將1.1.1.1的路由加入路由表。
2）用戶端此時串連拓撲上最近的網站。

此時發生了伺服器（全部）故障，或互連網串連故障、電力故障、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伺服器會在兩個網站間輪詢負載。見：

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

為了更好的說明，我隨便選擇一個術語“地區”，來描述這個GSLB拓撲結構。
上文提到的網站A和網站B被劃分為“歐洲GSLB地區”，網站C和網站D劃在“美國地區”。這個方法，只有在網站的網站分布在全球，且劃分為不同的地區，每個地區至少包含兩個資料中心互為備份，這種情況下，才能被全域負載平衡。如果www.trapster.net的資料中心分布在倫敦、紐約、東京，那麼“最佳選擇+輪詢”的模式就不會奏效了。某一用戶端在倫敦，GSLB需要返回倫敦網站的A記錄（地理位置最近的網站），同時它必須至少返回另一個網站的IP（紐約或東京，兩個網站與倫敦的距離都不近）。用戶端會串連倫敦的網站或者串連其他的網站。很明顯，這明顯違背了GSLB網站選擇演算法的初衷。同時，一些網站選擇演算法（例如步長計算）不能在“最佳選擇+輪詢”模式下工作（留給讀者來思考），DNS persistence 演算法也不能同“最佳選擇+輪詢”協同。即使這個複雜的實現可以為超大的全球網站服務，對於本文討論的案例來說該方法並不是一個通用的解決方案。

Copyright Tenereillo, Inc. 2004

原文地址：http://www.tenereillo.com/GSLBPageOfShame.htm

1. This paper discusses Internet behavior in the sense of the larger Internet. Certainly custom solutions can be created. For
   example, there is the possibility of distribution of special software to run on client computers. Such solutions are almost
   never practical for Internet sites, and are therefore not discussed here. Also, exceptions can be found in noncustom
   solutions, such as browsers or DNS servers that are configured to behave differently than described here. Again, those are
   very rare. Finally, there are applications that are not required to serve browser based clients. This paper does not apply to
   those applications. ?
2. The timeliness of the connection attempt to the second site is application dependent, but essentially all browser based
   applications will try the second IP address after a few unanswered TCP SYN packets. ?
3. Some solutions also attempt to achieve site weighting by returning duplicates. For example, to get 75% of traffic on site
   one they would return the ordered list {1.1.1.1, 1.1.1.1, 1.1.1.1, 2.2.2.2}. This feature does not work reliably, as most DNS
   servers note the duplicates and round robin the list as {1.1.1.1, 2.2.2.2}. ?
4. The order that A records are returned by the most commonly deployed DNS server, BIND, is as follows. The first record
   is chosen at random. The remaining records are returned in a cyclic order. For example, if the ordered list is {1.1.1.1, 2.2.2.2,
   3.3.3.3} the first response might be {2.2.2.2, 3.3.3.3, 1.1.1.1}, the next response to a subsequent client request, from a client
   that shares that name server, would be {3.3.3.3, 1.1.1.1, 2.2.2.2}. Other DNS resolvers and servers reorder the list differently,
   for example the Windows XP DNS cache will reorder a response such that any subnetadjacent
   IP address is returned first.
   This paper does not attempt to provide a canonical list of such issues. It will suffice to say that, for a number of reasons, the
   order in an ordered list of A records cannot be expected to be preserved. ?
5. Sites that do not support browser based clients, but do support applications that do not work well with multiple A
   records (indeed some custom robot type client applications do not), have no other recourse but to use one of these recover
   methods. ?
6. The “Watering it down” section was part of the original paper. I removed it because I thought it complicated the issue.
   Reviewers suggested that I put it back in. Done. 5/26/04. ?

為什麼基於DNS的全域負載平衡（GSLB）不起作用？