谷歌云計(jì)算架構(gòu)詳解

1、從整體來看， Google 的云計(jì)算平臺(tái)包括了如下的技術(shù)層次。網(wǎng)絡(luò)系統(tǒng)：包括外部網(wǎng)絡(luò) (Exterior Network) ，這個(gè)外部網(wǎng)絡(luò)并不是指運(yùn)營商自己的骨干網(wǎng)，也是 指在 Google 云計(jì)算服務(wù)器中心以外，由 Google 自己搭建的由于不同地區(qū) / 國家，不同應(yīng)用之間的負(fù)載平 衡的數(shù)據(jù)交換網(wǎng)絡(luò)。內(nèi)部網(wǎng)絡(luò)( Interior Network )，連接各個(gè) Google 自建的數(shù)據(jù)中心之間的網(wǎng)絡(luò)系統(tǒng)。硬件系統(tǒng)：從層次上來看，包括單個(gè)服務(wù)器、整合了多服務(wù)器機(jī)架和存放、連接各個(gè)服務(wù)器機(jī)架的 數(shù)據(jù)中心( IDC)。軟件系統(tǒng)：包括每個(gè)服務(wù)器上面的安裝的單機(jī)的操作系統(tǒng)經(jīng)過修改過的Redhat Li

2、nux。Google云計(jì)算底層軟件系統(tǒng)(文件系統(tǒng)GFS并行計(jì)算處理算法 Mapreduce、并行數(shù)據(jù)庫Bigtable ，并行鎖服務(wù)Chubby Lock ，云計(jì)算消息隊(duì)列 GW)QGoogle 內(nèi)部使用的軟件開發(fā)工具 Python、 Java、 C+ 等Google 自己開發(fā)的應(yīng)用軟件 Google Search 、 Google Email 、 Google Earth外部網(wǎng)絡(luò)系統(tǒng)介紹當(dāng)一個(gè)互聯(lián)網(wǎng)用戶輸入的時(shí)候，這個(gè)URL請求就會(huì)發(fā)到Google DNS解析服務(wù)器當(dāng)中去，Google的DNS 服務(wù)器會(huì)根據(jù)用戶自身的 IP 地址來判斷，這個(gè)用戶請求是來自哪個(gè)國家、哪個(gè)地區(qū)。根據(jù)不同用戶 的

3、IP 地址信息，解析到不同的 Google 的數(shù)據(jù)中心。進(jìn)入第一道防火墻，這次防火墻主要是根據(jù)不同端口來判斷應(yīng)用，過濾相應(yīng)的流量。如果僅僅接受瀏 覽器應(yīng)用的訪問，一般只會(huì)開放80端口 http，和443端口 https (通過SSL加密)。將其他的來自互聯(lián)網(wǎng)上的非 Ipv4 /V6 非 80/443 端口的請求都放棄，避免遭受互聯(lián)網(wǎng)上大量的 DOS 攻擊。在大量的web應(yīng)用服務(wù)器群 (WebServer Farm)前，Google使用反向代理 (Reverse Proxy)的技術(shù)。 反向代理( Reverse Proxy )方式是指以代理服務(wù)器來接受 internet 上的連接請求，然后將請求

4、轉(zhuǎn)發(fā)給內(nèi) 部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端，此時(shí)代理服務(wù)器 對外就表現(xiàn)為一個(gè)服務(wù)器。Google 使用的是 Squid Cache 的軟件方式來實(shí)現(xiàn)反向代理應(yīng)用的， Squid Cache 是一個(gè)流行的自由軟 件（GNU通用公共許可證）的代理服務(wù)器和Web緩存服務(wù)器。Squid有廣泛的用途，從作為網(wǎng)頁服務(wù)器的前置 cache 服務(wù)器緩存相關(guān)請求來提高 Web 服務(wù)器的速度。在 Google web 應(yīng)用服務(wù)器需要調(diào)用 Google 內(nèi)部存儲(chǔ)的信息和資源的時(shí)候，在通過一個(gè)防火墻進(jìn)入內(nèi) 部的網(wǎng)絡(luò)，來訪問其他的基于自身 GFS II 系統(tǒng)的應(yīng)用服

5、務(wù)和數(shù)據(jù)庫。內(nèi)部網(wǎng)絡(luò)架構(gòu)介紹Google 自己已經(jīng)建設(shè)了跨國的光纖網(wǎng)絡(luò)，連接跨地區(qū)、跨國家的高速光纖網(wǎng)絡(luò)。內(nèi)部網(wǎng)絡(luò)已經(jīng)都是IPv6的協(xié)議在運(yùn)行。網(wǎng)絡(luò)中的路由交換設(shè)備主要還是來自Juniper、Cisco、Foundry、HP這四家公司。內(nèi)部網(wǎng)關(guān)協(xié)議（IRP）是基于OSPF開放式最短路徑優(yōu)先）進(jìn)行修改的。在每個(gè)服務(wù)器機(jī)架內(nèi)部連接每臺(tái)服務(wù) 器之間網(wǎng)絡(luò)是100M以太網(wǎng)，在服務(wù)器機(jī)架之間連接的網(wǎng)絡(luò)是1000M以太網(wǎng)。在每個(gè)服務(wù)器機(jī)架內(nèi)，通過 IP 虛擬服務(wù)器（ IP Virtual Server ）的方式實(shí)現(xiàn)傳輸層負(fù)載 Linux 內(nèi)核 內(nèi)的平衡，這個(gè)就是所謂四層 LAN 交換。 IPVS 使一個(gè)服務(wù)

6、器機(jī)架中的眾多服務(wù)成為基于 Linux 內(nèi)核虛擬 服務(wù)器。這就像在一堆服務(wù)器前安裝一個(gè)負(fù)載均衡的服務(wù)器一樣。當(dāng)TCP/UDP的請求過來后，使一群服務(wù)器可以使用一個(gè)單一的 IP 地址來對外提供相關(guān)的服務(wù)支撐。大規(guī)模IDC部署戰(zhàn)略Google 應(yīng)該是目前世界上存儲(chǔ)信息最多的企業(yè)了。 而且還在一直不斷的致力于將傳統(tǒng)信息盡可能地?cái)?shù) 字化。將這樣海量的信息進(jìn)行存儲(chǔ)、進(jìn)行處理。就需要大量的計(jì)算機(jī)服務(wù)器。為了滿足不斷增長的計(jì)算需 求。 Google 很早就進(jìn)行了全球的數(shù)據(jù)中心的布局。由于數(shù)據(jù)中心運(yùn)行后， 面臨的幾個(gè)關(guān)鍵問題的就是充足 電力供應(yīng)、大量服務(wù)器運(yùn)行后的降溫排熱和足夠的網(wǎng)絡(luò)帶寬支持。所以Google

7、 在進(jìn)行數(shù)據(jù)中心布局的時(shí)候，就是根據(jù)互聯(lián)網(wǎng)骨干帶寬和電力網(wǎng)的核心節(jié)點(diǎn)進(jìn)行部署的，盡快考慮在河邊和海邊，想辦法通過引入 自然水流的方式來降低降溫排熱的成本。Dalles 是美國俄勒岡州北部哥倫比亞河（ Columbia River ）岸上的一個(gè)城市， Google 在 Dalles 的 邊上擁有的 30 英畝土地， 他們在這里建立了幾乎是世界上最大， 性能最好的數(shù)據(jù)中心。 四個(gè)裝備有巨大空 調(diào)設(shè)施的倉庫內(nèi)，放置著數(shù)萬臺(tái) Internet 服務(wù)器，這些服務(wù)器每天處理著數(shù)十億條 Google 網(wǎng)站傳遞給世 界各個(gè)角落的用戶的數(shù)據(jù)。圖表1 Google 在Dalles的數(shù)據(jù)中心這個(gè)數(shù)據(jù)中心占用了附近一

8、個(gè)180萬千瓦水力發(fā)電站的大部分電力輸出。對比來看目前中國長江三峽水電站的額定功率是1820萬千瓦。目前Google已經(jīng)在全球運(yùn)行了 38個(gè)大型的IDC中心，超過300多個(gè)GFSII服務(wù)器集群，超過80 萬臺(tái)計(jì)算機(jī)。從服務(wù)器集群部署的數(shù)量來看美國本地的數(shù)量第一，歐洲地區(qū)第二，亞洲地區(qū)第三，在南美 地區(qū)和俄羅斯各有一個(gè)IDC數(shù)據(jù)中心。在中國的北京和香港，Google也建設(shè)了自己的IDC中心，并部署了 自己的服務(wù)器農(nóng)場。 其中目前還在進(jìn)行建設(shè)的第38個(gè)IDC是在奧地利的林茨市（Linz）附近的Kronstorf村。未來，Google還準(zhǔn)備在中國臺(tái)灣地區(qū)、馬來西亞、立陶宛等地區(qū)來進(jìn)行部署。從目前的G

9、oogle數(shù)據(jù)中心部署的情況來看，中東和非洲地區(qū)目前Google還沒有建設(shè)計(jì)劃。圖表2 Google 的IDC中心/服務(wù)器農(nóng)場(Google Server Farm )的全球分布圖Google自己設(shè)計(jì)了創(chuàng)新的集裝箱服務(wù)器，數(shù)據(jù)中心以貨柜為單位，標(biāo)準(zhǔn)Google模塊化集裝箱裝有30個(gè)的機(jī)架，1160臺(tái)服務(wù)器，每臺(tái)服務(wù)器的功耗是 250KW (Google 2009年公布的信息)。這種標(biāo)準(zhǔn)的集 裝箱式的服務(wù)器部署和安裝策略可以使Google非?？焖俚夭渴鹨粋€(gè)超大型的數(shù)據(jù)中心。大大降低了對于機(jī)房基建的需求。、彗耳:3,-3圖表3 Google 模塊化集裝箱的設(shè)計(jì)示意圖自己設(shè)計(jì)的服務(wù)器機(jī)架架構(gòu)Goog

10、le的服務(wù)器機(jī)架有兩種規(guī)格40U/80U的。這主要是因?yàn)樵瓉砻總€(gè)服務(wù)器刀片是1U高，新的服務(wù)器刀片都是2U高的。據(jù)說Google后期使用的服務(wù)器主板是臺(tái)灣技嘉，服務(wù)器主板可以直接插入到服務(wù)器 機(jī)架中。圖表4 Google服務(wù)器機(jī)架及主板自己設(shè)計(jì)的PC服務(wù)器刀片絕大部分企業(yè)都會(huì)跟諸如戴爾、惠普、IBM或Sun購買服務(wù)器。不過 Google所擁有的八十萬臺(tái)服務(wù)器都是自己設(shè)計(jì)打造來的， Google認(rèn)為這是公司的核心技術(shù)之一。 Google的硬件設(shè)計(jì)人員都是直接和芯 片廠商和主板廠商協(xié)作工作的。2009年，Google開始大量使用2U高的低成本解決方案。標(biāo)準(zhǔn)配置是雙核雙通道 CPU據(jù)說有Intel的

11、， 也有AMD的在使用。8個(gè)2GB的DDR3支持ECC容錯(cuò)的高速內(nèi)存，采用 RAID 1的磁盤鏡像，來提升I/O 效率。磁盤采用SATA單機(jī)存儲(chǔ)容量可以達(dá)到 1-2TB。每個(gè)服務(wù)器刀片自帶 12V的電池來保證在短期沒有 外部電源的時(shí)候可以保持服務(wù)器刀片正常運(yùn)行。Google的硬件設(shè)計(jì)人員認(rèn)為， 這個(gè)自帶電池的方式， 要比傳統(tǒng)的使用UPS的方式效率更高。一般數(shù)據(jù)中心多倚賴稱為不間斷電源系統(tǒng)(UPS)的大型中控機(jī)型，這基本上算是大電池，會(huì)在主電力失效而發(fā)電機(jī)還來不及啟動(dòng)時(shí)，暫時(shí)協(xié)助供電。Google的硬件設(shè)計(jì)人員表示，直接把電力內(nèi)建到服務(wù)器比較便宜，而且成本能直接跟服務(wù)器數(shù)量相符合?！斑@種作法比使

12、用大型UPS節(jié)省得多，如此也不會(huì)浪費(fèi)多余的容量?！毙室彩橇硪粋€(gè)財(cái)務(wù)考量因素。大型UPS可達(dá)92-95%的效率，這意味著許多電力還是被浪費(fèi)掉了。但Google采用的內(nèi)建電池作法卻好很多，Google相關(guān)人員表示，“我們測量的結(jié)果是效率超過 99.9%。圖表5內(nèi)建電池的服務(wù)器刀片操作系統(tǒng)與云計(jì)算文件系統(tǒng)GFS/GFSIIGoogle服務(wù)器使用的操作系統(tǒng)是基于 Redhat Linux2.6 的內(nèi)核，并做了大量修改。修改了 GNU C函 數(shù)庫(glibc )，遠(yuǎn)程過程調(diào)用(RPC，開發(fā)了自己的Ipvs，自己修改了文件系統(tǒng)，形成了自己的 GFSII， 修改了 linux 內(nèi)核和相關(guān)的子系統(tǒng)，使其支持

13、 IPV6。采用了 Python來作為主要的腳本語言。Google文件系統(tǒng)中最基礎(chǔ)的模塊是 GFSII cell。任何文件和數(shù)據(jù)都可以利用這種底層模塊。GFSII通過基于Linux分布存儲(chǔ)的方式，對于服務(wù)器來說，分成了主服務(wù)器(Master Servers )和塊存儲(chǔ)服務(wù)器(Chunk Servers)，GFS上的塊存儲(chǔ)服務(wù)器上的存儲(chǔ)空間以 64MB為單位，分成很多的存儲(chǔ)塊，由主服務(wù)器來進(jìn)行存儲(chǔ)內(nèi)容的調(diào)度和分配。每一份數(shù)據(jù)都是一式三份的方式，將同樣的數(shù)據(jù)分布存儲(chǔ)在不同的服務(wù)器集群中,以保證數(shù)據(jù)的安全性和吞吐的效率提高。當(dāng)需要對于文件、數(shù)據(jù)進(jìn)行存儲(chǔ)的時(shí)候，應(yīng)用程序之間將需求發(fā) 給主服務(wù)器，主服務(wù)

14、器根據(jù)所管理的塊存儲(chǔ)服務(wù)器的情況，將需要存儲(chǔ)的內(nèi)容進(jìn)行分配，并將可以存儲(chǔ)的 消息（使用那些塊存儲(chǔ)服務(wù)器，那些地址空間），由應(yīng)用程序下面的GFS接口在對文件和數(shù)據(jù)直接存儲(chǔ)到相應(yīng)的塊存儲(chǔ)服務(wù)器當(dāng)中。GEXclIrfif -JimiL fun JI.-.vhu iiiIrtS4.File代謂r ”1侏丿Junk All：| III-." 11.11 r. j . Inrrik irnh1、InstfuclKHts io chunk wtvrL*空 lid；Dal ji“ill I “izwhunk huriLlk*. btehi mk .I .：i.uchunk wnerLinux til

15、eLimn fik 陽理nChLinl'n cr UjIl*j=X '-JsL 圖表6 GFS架構(gòu)塊存儲(chǔ)服務(wù)器要定時(shí)通過心跳信號(hào)的方式告知主服務(wù)器，目前自己的狀況，一旦心跳信號(hào)岀了問題，主服務(wù)器會(huì)自動(dòng)將有問題的塊存儲(chǔ)服務(wù)器的相關(guān)內(nèi)容進(jìn)行復(fù)制。以保證數(shù)據(jù)的安全性。數(shù)據(jù)被存儲(chǔ)時(shí)是經(jīng)過壓縮的。采用的BMDiff和Zippy算法。BMDiff使用最長公共子序列進(jìn)行壓縮，壓縮100MB/S,解壓縮約1000MB/S.類似的有IBM Hash SuffixArray DeltaCompression.Zippy 是LZW的改進(jìn)版本，壓縮比不如LZW,但是速度更快。并行計(jì)算架構(gòu)-Mapred

16、uce有了強(qiáng)大的分布式文件系統(tǒng)，Google遇到的問題就是怎么才能讓公司所有的程序員都學(xué)會(huì)些分布式計(jì)算的程序呢？于是，那些Google工程師們從lisp和其他函數(shù)式編程語言中的映射和化簡操作中得到靈感，搞出了 Map/Reduce這一套并行計(jì)算的框架。Map/Reduce被Google 拿來重新了 Google Search Engine 的 整個(gè)索引系統(tǒng)。而 Doug Cutting 同樣用Java將這一套實(shí)現(xiàn)和 HDFS合在一起成為 Hadoop的CoreMapReduce是Google提出的一個(gè)軟件架構(gòu)，用于大規(guī)模數(shù)據(jù)集（大于仃B）的并行運(yùn)算。概念“ Map（映射）”和“ Reduce

17、（化簡）”，和他們的主要思想，都是從函數(shù)式編程語言借來的，還有從矢量編程語言借來的特性。映射和化簡簡單說來，一個(gè)映射函數(shù)就是對一些獨(dú)立元素組成的概念上的列表（例如，一個(gè)測試成績的列表）的 每一個(gè)元素進(jìn)行指定的操作（比如前面的例子里，有人發(fā)現(xiàn)所有學(xué)生的成績都被高估了一分，他可以定義 一個(gè)“減一”的映射函數(shù)，用來修正這個(gè)錯(cuò)誤。）。事實(shí)上，每個(gè)元素都是被獨(dú)立操作的，而原始列表沒 有被更改，因?yàn)檫@里創(chuàng)建了一個(gè)新的列表來保存新的答案。這就是說，Map操作是可以高度并行的，這對高性能要求的應(yīng)用以及并行計(jì)算領(lǐng)域的需求非常有用。而化簡操作指的是對一個(gè)列表的元素進(jìn)行適當(dāng)?shù)暮喜ⅲɡ^續(xù)看前面的例子，如果有人想知道班

18、級(jí)的平 均分該怎么做？他可以定義一個(gè)化簡函數(shù)，通過讓列表中的元素跟自己的相鄰的元素相加的方式把列表減 半，如此遞歸運(yùn)算直到列表只剩下一個(gè)元素，然后用這個(gè)元素除以人數(shù)，就得到了平均分。）。雖然他不 如映射函數(shù)那么并行，但是因?yàn)榛喛偸怯幸粋€(gè)簡單的答案，大規(guī)模的運(yùn)算相對獨(dú)立，所以化簡函數(shù)在高 度并行環(huán)境下也很有用。分布和可靠性MapReduce通過把對數(shù)據(jù)集的大規(guī)模操作分發(fā)給網(wǎng)絡(luò)上的每個(gè)節(jié)點(diǎn)實(shí)現(xiàn)可靠性；每個(gè)節(jié)點(diǎn)會(huì)周期性的 把完成的工作和狀態(tài)的更新報(bào)告回來。如果一個(gè)節(jié)點(diǎn)保持沉默超過一個(gè)預(yù)設(shè)的時(shí)間間隔，主節(jié)點(diǎn)（類同 Google中的主服務(wù)器）記錄下這個(gè)節(jié)點(diǎn)狀態(tài)為死亡，并把分配給這個(gè)節(jié)點(diǎn)的數(shù)據(jù)發(fā)到別的節(jié)

19、點(diǎn)。每個(gè)操作使用命名文件的原子操作以確保不會(huì)發(fā)生并行線程間的沖突；當(dāng)文件被改名的時(shí)候，系統(tǒng)可能會(huì)把他們復(fù) 制到任務(wù)名以外的另一個(gè)名字上去?；啿僮鞴ぷ鞣绞胶茴愃疲怯捎诨啿僮髟诓⑿心芰^差，主節(jié)點(diǎn)會(huì)盡量把化簡操作調(diào)度在一個(gè)節(jié)點(diǎn)上，或者離需要操作的數(shù)據(jù)盡可能進(jìn)的節(jié)點(diǎn)上了；這個(gè)特性可以滿足Google的需求，因?yàn)樗麄冇凶銐虻膸?，他們的?nèi)部網(wǎng)絡(luò)沒有那么多的機(jī)器。在Google，MapReduce用在非常廣泛的應(yīng)用程序中，包括“分布 grep，分布排序，web連接圖反轉(zhuǎn)， 每臺(tái)機(jī)器的詞矢量，web訪問日志分析，反向索引構(gòu)建，文檔聚類，機(jī)器學(xué)習(xí)，基于統(tǒng)計(jì)的機(jī)器翻譯 ”值得注意的是，MapReduc

20、e實(shí)現(xiàn)以后，它被用來重新生成Google的整個(gè)索引，并取代老的ad hoc程序去更新索引。MapReduce會(huì)生成大量的臨時(shí)文件，為了提高效率，它利用 Google文件系統(tǒng)來管理和訪問這些 文件。并行計(jì)算數(shù)據(jù)庫BigTable有了強(qiáng)大的存儲(chǔ)，有了強(qiáng)大的計(jì)算能力，剩下的Google要面對的是：它的應(yīng)用中有很多結(jié)構(gòu)化、半結(jié)構(gòu)化的數(shù)據(jù)，如何高效地管理這些結(jié)構(gòu)化、半結(jié)構(gòu)化的數(shù)據(jù)呢？Google需要的是一個(gè)分布式的類DBMS的系統(tǒng)，于是催生了 BigTable這個(gè)東西Google的BigTable從2004年初就開始研發(fā)了，BigTable讓Google在提供新服務(wù)時(shí)的運(yùn)行成本降低，最大限度地利用了計(jì)算

21、能力。BigTable是建立在GFS和MapReduce之上的。每個(gè)Table由行和列組成，并且每個(gè)存儲(chǔ)單元 cell都有一個(gè)時(shí)間戳，在不同的時(shí)間對同一個(gè)存儲(chǔ)單 元cell有多份拷貝，這樣就可以記錄數(shù)據(jù)的變動(dòng)情況。不同一個(gè)單元格的版本都存儲(chǔ)在時(shí)間戳順序遞減， 因此，最近的版本可以首先閱讀。下圖是一個(gè)使用BigTable存儲(chǔ)網(wǎng)頁的例子，這一 “行”的名字是網(wǎng)頁的反向 URL “n.www"， 名為“contents:"的這一 “列"存儲(chǔ)網(wǎng)頁內(nèi)容，帶有名為“anchor "的列存儲(chǔ)所有引用該網(wǎng)頁的錨 （anchor） 文本。CNN的首頁被“ ”和“my.lo

22、ok.ca ”這兩個(gè)網(wǎng)站的首頁引用，所以該行就包含了這兩列：“anchor: ”和“ anchor:my.look.ca ”。這兩列下的單元都只有一個(gè)版本，而“contents: ”這一列下的單元有三個(gè)版本，分別是時(shí)間戳t3、t5和t6,分別對應(yīng)著網(wǎng)頁變動(dòng)的情況。contentsanchoncn ""anchor: my. look ca-；1 ；_- 論II«|圖表7 一個(gè)BigTable存儲(chǔ)網(wǎng)頁的例子BigTable中最重要的選擇是將數(shù)據(jù)存儲(chǔ)分為兩部分， 主體部分是不可變的，以SSTable的格式存儲(chǔ)在 GFS中，最近的更新則存儲(chǔ)在內(nèi)存（稱為 memtable

23、）中。讀操作需要根據(jù) SSTable和memtable還綜合決定 要讀取的數(shù)據(jù)的值。Google的Bigtable 是不支持事務(wù)，只保證對單條記錄的原子性。事務(wù)是好東西，但事務(wù)也是導(dǎo)致數(shù)據(jù)庫實(shí)現(xiàn)復(fù)雜化、性能下降最主要的根源。BigTable的開發(fā)者通過調(diào)研后發(fā)現(xiàn)其實(shí)大家對事務(wù)都沒什么需求，只要保證對單條記錄的更新是原子的就可以了。這樣，為了支持事務(wù)所要考慮的串行化、事務(wù)的回滾等、死鎖檢測（一般認(rèn)為，分布式環(huán)境中的死鎖檢測是不可能的，一般都用超時(shí)解決）等等復(fù)雜問題都不 見了。系統(tǒng)實(shí)現(xiàn)進(jìn)一步簡化。借鑒與總結(jié)Google的云計(jì)算軟件系統(tǒng)的完善是一個(gè)迭代開發(fā)，逐步升級(jí)替代的螺旋式上升過程。今天的整個(gè)軟件技術(shù)架構(gòu)已經(jīng)與10年前大相徑庭，GFS完成于2003年，MapReduce完成于2004年，Bigtable完成于2006年，并且此外還有持續(xù)的修改升級(jí)。每一次應(yīng)用新的軟件系統(tǒng)，都給Google帶來了運(yùn)營效率的極大提升，甚至發(fā)生了根本性的變化，如使用MapReduce重新生成Google的整個(gè)索引，并取代老的ad hoc程序去更新索引。"云計(jì)算”的完整概念并不是