我對Web應用程序的cross-colo故障切換策略感興趣，例如，如果主站點無法將用戶無縫地連接到另一個colo的故障切換站點。Cross-colo故障切換設計，DNS級別故障切換？
事情的應用程序端看起來主要是在colos和服務之間建立主 - 從數據庫的基礎上進行設計的，旨在恢復並能夠在中途獲取。我試圖找出將流量從主站點轉移到故障轉移站點的策略。 DNS故障轉移，即使是低TTL，似乎也帶有fair bit of latency。
假設主colo中的服務器無法訪問，您建議如何快速移動colos之間的流量？
如果您有關於cross-colo故障轉移的其他有趣的經驗/智慧話語，我很樂意聽到這些。
DNS機制是麻煩的，即使你把低TTL值的區域文件。
原因是許多應用程序（例如MSIE）維護自己的緩存忽略TTL。其他軟件將執行一次gethostbyname()或同等調用並存儲結果，直到程序重新啓動。
更糟糕的是，許多ISP的遞歸DNS服務器已知忽略低於其自己偏好最小值的TTL並施加自己的更高TTL。
最終如果網站要從兩個數據中心運行而不是更改其IP地址，那麼您需要查看通過全局BGP4路由通告安排「多宿主」。
使用多宿主時，您需要至少獲得/ 24個「提供程序獨立」（又名「PI」）IP地址空間的網絡塊，然後讓它只從備份站點向全局路由表發佈，網站下線。
如果可以的話，多播 - http://en.wikipedia.org/wiki/Multicast或任 - 基於http://en.wikipedia.org/wiki/Anycast
至於DNS，我喜歡引用，"Why DNS Based Global Server Load Balancing Doesn't Work"。對於其他事情 - 使用BGP。爲了使用BGP進行負載均衡，設計網絡仍然不是一件容易的事，我自己也不是這方面的專家。它也比維基百科可以告訴你更復雜，但也有在網絡上一對夫婦有趣的文章，詳細介紹瞭如何可以做到：
總是有更多，如果你搜索BGP和負載平衡。網絡上還有一些白皮書，描述了Akamai如何進行全球負載平衡（我相信它也是BGP），這對閱讀和了解總是很有趣的。
除了您可以使用軟件和硬件實現的顯而易見的概念之外，您可能還需要檢查ISP /提供程序/ colo是否可以設置。
此外，沒有冒犯您的colo選擇（誰是供應商？），但大多數地方應該設置爲處理停機時間等，他們不應該要求你採取行動。當然，洪水或外星人總是可以罷工，但在這種情況下，我想還有更重要的問題。 :-)
多播是沒有用的 - 互聯網的其餘部分將無視它 – Alnitak 2008-12-30 20:49:30
多播將取決於colos的對等。 Anycast可以在整個互聯網上運行。你可能錯過了我的帖子的那一部分，但是我在完成之前意外地保存了帖子...... :-) – 2008-12-30 20:50:42
確實 - 那不是那裏。然而，任播通常用於無狀態的UDP服務，並且與TCP不兼容（請參閱維基百科文章中的注意事項）。 – Alnitak 2008-12-30 20:55:36