運行單數(shù)據(jù)中心的系統(tǒng)很有難度，那么設(shè)想一下切換到雙數(shù)據(jù)中心吧，假設(shè)你需要對多個位于不同地理位置的數(shù)據(jù)中心提供支持。谷歌有一篇發(fā)人深思的優(yōu)秀論文，其中對這一過程有所描述——“大規(guī)模高可用性：打造谷歌的廣告數(shù)據(jù)基礎(chǔ)設(shè)施”。
　　文中的主要觀點是：在將單個數(shù)據(jù)中心切換到多個數(shù)據(jù)中心時，典型的故障轉(zhuǎn)移架構(gòu)在實踐中效果并不太好。能夠起到作用，使用較少資源就能提供高可用性和一致性的方法，是原生的多宿主/多重連接架構(gòu)（natively multihomed architecture）：
　　我們目前的方式是構(gòu)建原生多宿主架構(gòu)。 在這樣的系統(tǒng)中，多個數(shù)據(jù)中心會持續(xù)運作，并根據(jù)情況自發(fā)平衡不同數(shù)據(jù)中心的負(fù)載，同時還能以完全透明化的方式解決任意規(guī)模的數(shù)據(jù)中心停機(jī)。此外，按計劃執(zhí)行的數(shù)據(jù)中心停機(jī)與維護(hù)事件也是完全透明化的，這樣就會將對運營系統(tǒng)造成的影響降到最低。在過去，要想完成停機(jī)與維護(hù)事件，需要付出大量人力將運營系統(tǒng)從一個數(shù)據(jù)中心遷移到另一個。
　　“多宿主”這種說法也許會令人費解，因為多宿主這個詞一般指的是一臺電腦連接著多個網(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è)置檢查點，以及可重復(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)所耗費的資源還要少：
　　部署在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)高可用性，而且由于需要部署備用資源，會帶來成本浪費。
　　以前我們在使用故障轉(zhuǎn)移系統(tǒng)時，有很多不好的體驗。由于非計劃性停機(jī)很少見，故障轉(zhuǎn)移系統(tǒng)多是后期才添加的功能，無法自動化執(zhí)行，也沒有經(jīng)過很好的測試。很多時候，團(tuán)隊需要花費數(shù)日才能從停機(jī)中恢復(fù)，一個組件一個組件的上線，用自定義MapReduces之類的臨時工具執(zhí)行狀態(tài)恢復(fù)，并在系統(tǒng)處理停機(jī)時的積壓工作時，逐步執(zhí)行優(yōu)調(diào)。這些情況不僅讓系統(tǒng)無法再進(jìn)行擴(kuò)展，還讓團(tuán)隊由于所運行的關(guān)鍵任務(wù)系統(tǒng)太過復(fù)雜而承受了極大壓力。
　　多宿主系統(tǒng)的工作原理是什么？
　　相比之下，多宿主系統(tǒng)在設(shè)計之初就將運行多個數(shù)據(jù)中心作為核心設(shè)計屬性，因此無需另外添加故障轉(zhuǎn)移系統(tǒng)。多宿主系統(tǒng)一直保持多個數(shù)據(jù)中心運行。每個數(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ù)中心的某個點重新開始工作，同時確保恰一次語義（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)運行在一個或多個日志數(shù)據(jù)中心之上，并處理所有事件。流處理系統(tǒng)所輸出的內(nèi)容通常會存儲在全球范圍內(nèi)的一些復(fù)制系統(tǒng)中，這樣從任何地方都能可靠地對輸出執(zhí)行消費。
　　在多宿主系統(tǒng)中，所有數(shù)據(jù)中心都會持續(xù)運行并處理事件，典型狀況下會部署三臺數(shù)據(jù)中心。在穩(wěn)定狀態(tài)下，這三臺數(shù)據(jù)中心每個都能處理33%的流量。如果某臺數(shù)據(jù)中心出現(xiàn)故障而停機(jī)，剩下的兩臺數(shù)據(jù)中心會分別承擔(dān)50%的流量處理工作。
?

普通下載普通下載

相關(guān)電子資料下載

• 研華推出EPC-B3000系列嵌入式工控機(jī)，搭載先進(jìn)X86架構(gòu)CPU，助力邊緣人工智能應(yīng)用 91
• 典型汽車網(wǎng)絡(luò)系統(tǒng)架構(gòu)設(shè)計盤點 28
• 今日看點丨正面對決英特爾，傳英偉達(dá)研發(fā)Arm架構(gòu)PC芯片；郭明錤預(yù)估蘋果明年 266
• 基于Corundum架構(gòu)的100G RDMA網(wǎng)卡設(shè)計 32
• 異構(gòu)計算時代，RISC-V架構(gòu)發(fā)展應(yīng)該更大膽一些 501
• 什么是 “星閃”？星閃技術(shù)架構(gòu)和特點分析 149
• 高通Hexagon NPU架構(gòu)技術(shù)詳解 37
• 汽車電子電氣架構(gòu)車控軟件系統(tǒng)詳解 58
• 淺談博世智能駕駛架構(gòu)平臺EDMS的概念 43
• 基于Tricore芯片的AUTOSAR架構(gòu)下的多核啟動 63