多個數據中心和 HTTP 流量：DNS 循環是確保即時故障轉移的唯一方法？

指向同一個域的多個 A 記錄似乎幾乎專門用於實現 DNS 循環作為一種廉價的負載平衡技術。

針對 DNS RR 的常見警告是它不利於高可用性。當 1 個 IP 出現故障時，客戶端將繼續使用它幾分鐘。

通常建議使用負載均衡器作為更好的選擇。

兩種說法都不完全正確：

1. 當流量為 HTTP 時，大多數 HTML 瀏覽器能夠自動嘗試下一個 A 記錄，如果前一個記錄關閉，則無需新的 DNS 查找。閱讀**此處第 3.1章和此處**。
2. 當涉及多個數據中心時，DNS RR 是在它們之間分配流量的唯一選擇。

那麼，對於多個數據中心和 HTTP 流量，使用 DNS RR 是否是確保在一個數據中心出現故障時立即進行故障轉移的唯一方法？

謝謝，

華倫天奴

編輯：

• 當然，每個數據中心都有一個帶有熱備用的本地負載均衡器。
• 為即時故障轉移犧牲會話親和性是可以的。
• AFAIK DNS 建議數據中心而不是另一個數據中心的唯一方法是僅回復與該數據中心關聯的 IP（或 IP）。如果數據中心變得不可訪問，那麼所有這些 IP 也是不可訪問的。這意味著，即使智能 HTML 瀏覽器能夠立即嘗試另一個 A 記錄，所有嘗試都將失敗，直到本地記憶體條目過期並完成新的 DNS 查找，獲取新的工作 IP（我假設 DNS 自動建議一個失敗時的新數據中心）。因此，“智能 DNS”不能保證即時故障轉移。
• 相反，DNS 循環允許它。當一個數據中心發生故障時，智能 HTML 瀏覽器（大多數）會立即嘗試將其他記憶體的 A 記錄跳轉到另一個（工作）數據中心。因此，DNS 循環不能確保會話親和性或最低 RTT，但似乎是當客戶端是“智能”HTML 瀏覽器時確保即時故障轉移的唯一方法。

編輯2：

• 有些人建議將 TCP Anycast 作為最終解決方案。在**本文**（第 6 章）中解釋了 Anycast 故障轉移與 BGP 收斂有關。為此，Anycast 可以使用 15 分鐘到 20 秒來完成。在拓撲為此優化的網路上可能需要 20 秒。可能只有 CDN 運營商可以授予如此快速的故障轉移。

編輯 3：*

• 我做了一些 DNS 查找和跟踪路由（也許一些專家可以仔細檢查）並且：

  • 唯一使用 TCP Anycast 的 CDN 似乎是 CacheFly，其他運營商如 CDN 網路和 BitGravity 使用 CacheFly。似乎它們的邊緣不能用作反向代理。因此，它們不能用於授予即時故障轉移。
  • Akamai 和 LimeLight 似乎使用地理感知 DNS。但！他們返回多個 A 記錄。從 traceroutes 看來，返回的 IP 位於同一個數據中心。因此，當一個數據中心出現故障時，他們如何提供 100% 的 SLA 讓我感到困惑。

當我使用術語“DNS 循環”時，我通常指的是 OP 所描述的“廉價負載平衡技術”。

但這並不是 DNS 可用於全球高可用性的唯一方式。大多數時候，具有不同（技術）背景的人很難進行良好的溝通。

**最好的負載平衡技術（如果錢不是問題）**通常被認為是：

1. 一個由“智能”DNS 伺服器組成的 Anycast 全球網路，
2. 以及一組遍布全球的數據中心，
3. 其中每個 DNS 節點都實現了水平分割 DNS，
4. 並且以某種方式對“智能”DNS節點可用的可用性和流量進行監控，
5. 以便使用者 DNS 請求通過 IP Anycast 流向最近的 DNS 伺服器，
6. 並且此DNS 伺服器通過“智能”水平分割 DNS 為該最終使用者提供最近/最佳數據中心****的低 TTL A 記錄/一組 A 記錄。

對 DNS 使用任播通常很好，因為 DNS 響應是無狀態的並且幾乎非常短。因此，如果 BGP 路由發生變化，則極不可能中斷 DNS 查詢。

Anycast 不太適合較長且有狀態的 HTTP 會話，因此該系統使用水平分割 DNS。客戶端和伺服器之間的 HTTP 會話保持在一個數據中心；它通常不能在不中斷會話的情況下故障轉移到另一個數據中心。

正如我在“A 記錄集”中指出的那樣，我稱之為“DNS 循環”可以與上面的設置一起使用。它通常用於將流量負載分散到每個數據中心中的多個高可用性負載平衡器上（這樣您可以獲得更好的冗餘，使用更小/更便宜的負載平衡器，而不是壓倒單個主機伺服器的 Unix 網路緩衝區等）。

那麼，對於多個數據中心和 HTTP 流量，使用 DNS RR 是否是確保高可用性的唯一方法？

不，這不是真的，如果通過“DNS 循環”我們只是指為一個域分發多個 A 記錄，則不是這樣。但是，巧妙地使用 DNS 確實是任何全球高可用性系統的關鍵組件。以上說明了一種常見的（通常是最好的）方法。

編輯： Google 論文“Moving Beyond End-to-End Path Information to Optimize CDN Performance”在我看來是全球負載分配方面的最先進技術，可實現最佳最終使用者性能。

**編輯 2：**我閱讀了 OP 連結到的文章“為什麼基於 DNS .. GSLB .. 不起作用”，這是一個很好的概述——我建議看一下。從頂部閱讀它。

在“瀏覽器記憶體問題的解決方案”一節中，它提倡使用指向多個數據中心的多個 A 記錄的 DNS 響應作為瞬時故障轉移的唯一可能解決方案。

在底部附近的“澆水”部分中，它很明顯地擴展了，如果它們指向多個大陸的數據中心，發送多個 A 記錄是不酷的，因為客戶端將隨機連接，因此經常得到一個“慢” DC在另一個大陸。因此，要使其真正運作良好，每個大陸都需要多個數據中心。

這是與我的步驟 1-6 不同的解決方案。我無法對此提供完美的答案，我認為需要來自 Akamai 或 Google等公司的 DNS 專家，因為其中大部分歸結為實用知識今天部署的 DNS 記憶體和瀏覽器的局限性。AFAIK，我的步驟 1-6 是 Akamai 對他們的 DNS 所做的（任何人都可以確認這一點嗎？）。

我的感覺——來自於在移動瀏覽器門戶（手機）上擔任 PM 的經歷——是那裡的瀏覽器的多樣性和完全崩潰的程度令人難以置信。我個人不會相信要求最終使用者終端“做正確的事”的 HA 解決方案；因此，我認為在不中斷會話的情況下進行全域瞬時故障轉移在今天是不可行的。

我認為我上面的步驟 1-6 是商品技術可用的最佳步驟。此解決方案沒有瞬時故障轉移。

我希望 Akamai、Google 等的 DNS 專家之一來證明我錯了。:-)

引用自：https://serverfault.com/questions/69870