原文:Google’s Transition from Single Datacenter, to Failover, to a Native Multihomed Architecture
運行單數據中心的系統很有難度,那么設想一下切換到雙數據中心吧,假設你需要對多個位于不同地理位置的數據中心提供支持。谷歌有一篇發人深思的優秀論文,其中對這一過程有所描述——“大規模高可用性:打造谷歌的廣告數據基礎設施”。
文中的主要觀點是:在將單個數據中心切換到多個數據中心時,典型的故障轉移架構在實踐中效果并不太好。能夠起到作用,使用較少資源就能提供高可用性和一致性的方法,是原生的多宿主/多重連接架構(natively multihomed architecture):
我們目前的方式是構建原生多宿主架構。 在這樣的系統中,多個數據中心會持續運作,并根據情況自發平衡不同數據中心的負載,同時還能以完全透明化的方式解決任意規模的數據中心停機。此外,按計劃執行的數據中心停機與維護事件也是完全透明化的,這樣就會將對運營系統造成的影響降到最低。在過去,要想完成停機與維護事件,需要付出大量人力將運營系統從一個數據中心遷移到另一個。
“多宿主”這種說法也許會令人費解,因為多宿主這個詞一般指的是一臺電腦連接著多個網絡。不過按照谷歌的規模,用這種說法描述連接著多個數據中心也是非常自然的。
谷歌構建了多個多宿主系統,以確保在出現數據中心級別的停機時,還能保持高可用性(99.99%到99.999%)與一致性,下面這些文章對這些系統進行了詳細描述:F1 / Spanner:關系數據庫;Photon:對多個連續數據流進行join的部署;Mesa:數據倉儲。這些論文分別討論了各系統所采用的方式,以及在構建多宿主系統時遇到的諸多挑戰:全局狀態同步、怎么設置檢查點,以及可重復的輸入與只執行一次的輸出等。
為了 保持可用性與一致性,系統受到了很大約束。這就凸顯了谷歌持續在簡化這些復雜系統,提高其易用性上付出的努力:
多宿主系統的簡單性對用戶是極有價值的,沒有多宿主系統的話,無論故障轉移、系統恢復還是一致性問題,都是應用需要解決的問題。而借助多宿主系統,基礎設施會處理這些麻煩的問題,應用開發者只要專注于自身應用即可,可用性和一致性有系統來保障。
在這篇論文中最大的驚喜就是:實際中,多宿主系統比故障轉移系統所耗費的資源還要少:
部署在3個數據中心之上的多宿主系統,總同步性能為穩定狀態的20%,總資源占用為170%,遠遠小于故障轉移系統所需的300%。
故障轉移系統有什么問題?
基于故障轉移系統的方式并未真正實現高可用性,而且由于需要部署備用資源,會帶來成本浪費。
以前我們在使用故障轉移系統時,有很多不好的體驗。由于非計劃性停機很少見,故障轉移系統多是后期才添加的功能,無法自動化執行,也沒有經過很好的測試。很多時候,團隊需要花費數日才能從停機中恢復,一個組件一個組件的上線,用自定義MapReduces之類的臨時工具執行狀態恢復,并在系統處理停機時的積壓工作時,逐步執行優調。這些情況不僅讓系統無法再進行擴展,還讓團隊由于所運行的關鍵任務系統太過復雜而承受了極大壓力。
多宿主系統的工作原理是什么?
相比之下,多宿主系統在設計之初就將運行多個數據中心作為核心設計屬性,因此無需另外添加故障轉移系統。多宿主系統一直保持多個數據中心運行。每個數據中心都在持續處理工作,同時各數據中心之間的負載會自動進行平衡。一旦某個數據中心的處理速度減緩,系統就會自動將一部分工作調整到速度較快的數據中心上去。一旦某個數據中心出現故障完全不可用,所有工作都會自動分發到其他數據中心上去。
只有持續的動態負載平衡,不再有故障轉移的過程。多宿主系統通過實時同步的全局共享狀態來協調數據中心之間的工作。所有關鍵的系統狀態都有備份,以確保隨時能從另一個數據中心的某個點重新開始工作,同時確保恰一次語義(exactly once semantics)。在出現數據中心級別的故障時,多宿主系統是唯一能夠提供高可用性和完整一致性的系統。
在典型流系統中,事件處理基于用戶交互來解決;同時,全世界范圍內的多臺數據中心會為用戶提供流量服務和日志存儲服務。日志收集服務會在全球范圍內收集這些日志,并將其復制到兩臺或多臺特定的日志數據中心上。每個日志數據中心都會保存完整的日志記錄,并確保復制到某個數據中心中的所有事件都會(逐漸)復制到其他日志數據中心上。流處理系統運行在一個或多個日志數據中心之上,并處理所有事件。流處理系統所輸出的內容通常會存儲在全球范圍內的一些復制系統中,這樣從任何地方都能可靠地對輸出執行消費。
在多宿主系統中,所有數據中心都會持續運行并處理事件,典型狀況下會部署三臺數據中心。在穩定狀態下,這三臺數據中心每個都能處理33%的流量。如果某臺數據中心出現故障而停機,剩下的兩臺數據中心會分別承擔50%的流量處理工作。