Google這個搜索巨人很少暴露其數(shù)據(jù)中心，但在上周，Google研究員Jeff Dean在Google I/O會議上揭秘了它的部分運行情況。
一方面，Google使用了一些常規(guī)服務器，另外一方面，Google將1800臺服務器組成了集群，這些集群服務器負責Google日常的搜索處理任務，這部分服務器的數(shù)量大約是700到1000臺。
Google并未透露擁有多少臺服務器，但我們估計的數(shù)量有成千上萬。Dean透露，Google將40臺服務器編為一個集群，而在全球范圍，Google擁有36個數(shù)據(jù)中心。每個數(shù)據(jù)中心有150個服務器集群，這意味著Google擁有的服務器數(shù)量超過20萬臺，不過Google服務器的數(shù)量應該遠遠超過這一數(shù)字，而且每天都在增長。
無論有多少臺服務器，Google取得的成就都引人矚目。像紐約證券交易所和航空公司訂票系統(tǒng)都使用大量的主干機服務器與軟件，而Google主要使用自己的技術。
可以肯定，許多服務器廠商對此會感到酸溜溜的，但Google明顯認為，將自己的技術命運掌握在自己手中最安全。Google搜索產(chǎn)品與用戶體驗部門副總裁Marissa Mayer說，創(chuàng)始人Larry Page鼓勵在公司中形成一種“健康的，對不可能說不”的氣氛。
![]()
數(shù)據(jù)中心入口
為了應對Google這樣的搜索規(guī)模，需要讓每臺機器的性能發(fā)揮到極致。雖然服務器廠商們對其高端機型中的容錯性能津津樂道，但Google更樂意將錢投到容錯軟件上。
Dean說：“我們的觀點是，不可靠的硬件數(shù)量最好是可靠機型的兩倍。你需要將可靠性放在軟件層面。假如你運行1萬臺機器，那么每天都有一些死機�！�
Dean說，在每個服務器集群運行的頭一年，一般有1千臺機器會發(fā)生故障；數(shù)千塊硬盤會出問題；一個“電源分配單元”（PDU）將壞掉，令500到1000臺機器當機6小時；20個服務器機架將出現(xiàn)故障，造成40到80臺機器從網(wǎng)絡上掉線；5個服務器機架將變得不穩(wěn)定，這使得機架上的服務器處理的一半信息包失去響應；一個服務器集群需要重新連接，這將影響5%的機器，影響的時間跨度一般為2天。服務器集群有50%的過熱可能性，過熱會讓絕大多數(shù)服務器在5分鐘內當機，并且耗時1到2天來重新恢復。
雖然Google使用了一般的硬件設備，但在軟件上卻沒有使用尋常的軟件。Google要求英特爾提供專門定制的電路板。Dean還透露，Google目前為每40個服務器組成的機架配備一個機箱，而不是象一般情況那樣為每個服務器配備一個機箱。
對于服務器本身，Google喜歡多核芯片配置。盡管許多軟件公司正在努力適應多核芯片時代的來臨，但Google對這種芯片使用起來得心應手。Google不得不讓自己的技術適應有限的硬件資源架構，因此，他們已經(jīng)進入了并行處理時代。
Dean說：“我們確實喜歡多核機器。對我們來說，多核機器用少量的機器實現(xiàn)了良好的連接性能。對我們而言，它們更容易使用�！�
盡管Google需要對搜索以及其它服務進行快速響應，并行處理能夠完成這一任務需要，雖然有可能單個線程的速度并不快。
Dean說：“單個線程的性能對我們來說確實沒有多大關系。我們將重點主要放在并行處理問題上�！�
Google如何讓這些普通的硬件發(fā)揮作用？用軟件。
![]()
圖為數(shù)據(jù)中心的電力系統(tǒng)，超級計算機需要巨大的電力支持
Dean闡述了Google軟件的三大核心元素：Google文件系統(tǒng)（GFS）；Google大表(BigTable：是Google一種對于半結構化數(shù)據(jù)進行分布存儲與訪問的接口或服務)；MapReduce算法（它是Google開發(fā)的C++編程工具，用于大于1TB數(shù)據(jù)的大規(guī)模數(shù)據(jù)集并行運算）。盡管Google依靠許多開源項目實現(xiàn)了企業(yè)的騰飛，但Google對這三套核心元素秘而不宣。
Google文件系統(tǒng)處于這三個元素的最底層，它負責許多服務器，機器的數(shù)據(jù)存儲工作。很多Google文件系統(tǒng)的體積都異常龐大，有好幾個petabyte規(guī)模（1 petabyte相當于1百萬gigabytes）。有200多個服務器集群運行有Google文件系統(tǒng)，其中很多集群包含了上千臺機器。
Google文件系統(tǒng)至少在三臺名為“塊服務器”（chunkservers）上存儲大體積數(shù)據(jù)（一般為64MB）；如果一臺塊服務器發(fā)生故障，那么主服務器會負責將數(shù)據(jù)恢復到新的區(qū)域。Dean說：“至少在存儲層面，機器故障的處理由Google文件系統(tǒng)來完成。”
為了給全部這些數(shù)據(jù)提供一些結構，Google使用了大表。象甲骨文和IBM公司的商業(yè)數(shù)據(jù)庫在這里發(fā)揮不了作用，因為這些產(chǎn)品無法滿足Google的需要，Dean說，如果要使用商業(yè)數(shù)據(jù)庫的話，價格將非常的昂貴。
Google從2004年開始設計大表，現(xiàn)在已經(jīng)在Google 70多個項目中使用，包括Google地圖，Google地球，Blogger，Google Print和核心的搜索目錄。Dean說，大表管理的最大一個數(shù)據(jù)表格有6 petabytes大小，覆蓋上千臺機器。
2003年，Google編寫了MapReduce的第一個版本，這種算法給了Google公司一條讓自己數(shù)據(jù)發(fā)揮作用的途徑來。例如，MapReduce能夠找出一個詞語在Google搜索目錄中出現(xiàn)的次數(shù)；一系列網(wǎng)頁中特定詞語出現(xiàn)的頻率；鏈接到某個特定網(wǎng)站的所有網(wǎng)站數(shù)量等。
有了MapReduce，Google可以編寫出一個索引目錄，迅速顯示出與特定詞語相關的網(wǎng)頁出來。Dean說：“為了在可以接受的時間內完成這一工作，你需要在上千臺機器上進行處理�！�
Google對MapReduce軟件的使用正在增多。2004年，MapReduce運行了2.9萬個工作任務，到2007年，已有220萬個工作由MapReduce來完成。同期，MapReduce對于一個工作的平均運行響應時間從634秒下降到了395秒，MapReduce任務的數(shù)據(jù)產(chǎn)出量從193 terabytes上升到了14018 terabytes。
Dean說，在任何一天，Google運行有大約10萬個MapReduce工作任務；每項任務大約會占用4百臺服務器，時間大約是5到10分鐘。
這是一個有趣的數(shù)學計算。假設服務器只完成MapReduce工作，每臺服務器一次只完成一項任務，那么大約要耗時24小時，如果這些工作任務每個耗時5分鐘，這意味著MapReduce任務要占用大約13.9萬臺服務器。如果耗時7.5分鐘，那么需要的服務器數(shù)量增加到20.8萬臺；如果需要10分鐘，服務器的數(shù)量增加至27.8萬臺。
和Google文件系統(tǒng)一樣，MapReduce的設計也要考慮服務器的當機問題。
![]()
數(shù)據(jù)中心內巡邏的保安車
Dean說：“當一臺機器當機，主服務器會了解分配給這臺機器的任務是什么，然后直接指定其它機器來完成這一任務。”
MapReduce的可靠性曾經(jīng)在一個由1800臺服務器組成的集群進行維護時經(jīng)受住了嚴格考驗。工作人員將其中80臺機器拔掉，其它1720臺機器承擔起了80臺機器的處理任務。Dean說：“它運行有一些慢，但全部完成了任務�！�
在2004年，Dean表示，曾經(jīng)有一個1800臺機器組成集群，其中1600臺當機了，但整個系統(tǒng)經(jīng)受住了考驗。
盡管Google的數(shù)據(jù)中心取得了很大的成功，但公司并不滿足，他們有很長遠的改進發(fā)展計劃。
對于一般的企業(yè)來說，他們只需要考慮將工作任務從一臺服務器轉移到另外一臺，但Google面臨的工作量級不同，他們希望能夠將工作任務由一個數(shù)據(jù)中心自動轉移到另外一個中心。
Dean說：“我們希望自己的下一代架構是一種能夠超越單個機器的系統(tǒng)。”
考慮到Google的業(yè)務數(shù)量級，這無疑是一個艱巨的挑戰(zhàn)。毫無疑問，很多小公司正在羨慕的看著他們。 | 
免費注冊
發(fā)表于 2008-06-06 10:30
發(fā)表于 2008-06-08 14:50
