您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費(fèi)注冊]

您的位置:電子發(fā)燒友網(wǎng)>源碼下載>數(shù)值算法/人工智能>

谷歌架構(gòu)的轉(zhuǎn)變分析

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

非常好我支持^.^

(0) 0%

不好我反對

(0) 0%

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關(guān)規(guī)定!

      ?