Google提供全球大量的服務，幾乎已經快橫跨整個資訊科技的服務，但是Google資料中心的內部運作一直都是秘而不宣，
許多人可能都碰過Google的服務出狀況，但是這些狀況總能在可容忍的範圍內解決，你可能發現你的Gmail的容量一直在改變，
是什麼架構讓空間像捏橡皮糖一樣越捏越大?前陣子Google伙伴Jeff Dean在Google I/O會議中稍微揭開了公司基礎設施的神秘面紗。
Google的神秘面紗包括了: (1)軟體 (2)硬體 (3)叢集平行處理機置
Google軟體的三個核心要素：GFS（Google檔案系統）、BigTable和MapReduce演算法。而硬體卻是一般的伺服器、處理器、硬碟、
記憶體等等。另一方面伺服器的叢集能在半秒之內回應700至1,000台伺服器的搜尋請求。
根據Google的說法，
GFS是"a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance
while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients".
就是這個GFS的分散式檔案系統，讓Google服務可以隨時長出空間或是切去毀損的部分，而管理這個GFS的機置就是
BigTable。
目前有超過200個叢集在執行GFS，其中許多都包含數千台主機。
GFS把一塊儲存的資料(通常是64MB)，至少放在三台稱為chunkserver的主機內。
如果chunkserver發生故障，Master Server(主伺服器)便負責把資料備份到一個新的地方。至少在儲存層級，主機故障完全由GFS系統處理。
Google到底擁有多少台伺服器?據Dean表示，每個機櫃存放40台伺服器。而根據某項估計，Google目前在全球有36個資料中心，
以每個中心有150個機櫃計算，Google的伺服器至少超過20萬台，並且每天都在增加中...下圖就是Google最早期的server rack，
當然目前的硬體比這個肯定更驚人了。
Google之所以成為Google，部分原因是他們推翻了電腦界的傳統作法。當所有的超大型資料中心都使用主流伺服器和軟體，Google的資料中心絕大部分是靠本身的技術構建而成。Google把命運操縱在自己手中，共同創辦人Larry Page鼓勵員工"別太相信有什麼不可能的事情"。
要維持如此大規模的運作，也許可以說全世界是卯起來操Google的架構，Google必須對每一台機器抱有一種隨時可犧牲的態度。伺服器製造商喜歡主打他們的高階主機承受故障或當機的能力，但Google寧願把錢投資在容錯軟體上。他們認為擁有兩倍數量但較不可靠的硬體，勝過一半數量但較可靠的硬體。你必須在軟體的層級提供可靠度，如果你有1萬台主機在運作，每天一定會有一些東西掛掉。這個跟我們一般的認知確實有蠻大的差異，我們通常都希望有數量雖少，但功能穩定的機器，而不願意有一大籮筐兩光的機器。
每個新叢集上線的第一年，通常會發生1,000次個別主機的故障，數千次硬碟故障...
一次電力輸送問題，導致500至1,000台主機失效約6小時...
20次機櫃損壞，每次造成40至80台主機下線...
5次機櫃搖晃，導致半數的網路封包在傳送過程中遺失...
整個叢集至少一次重新上線，在兩天之內的任何時間，影響5%的主機...
整個叢集還有一半的機率會過熱，在5分鐘之內讓幾乎所有伺服器當機，並且花上1到2天的時間恢復...
雖然Google用一般硬體組件來組裝其伺服器，但卻不用傳統的封裝，他們要求Intel提供特製的主機板。Google目前在每40台伺服器的機櫃外，
包覆一層外殼，而不是每台伺服器有個別的外殼。
Google在2004年開始設計的BigTable，用BigTable為所有資料提供若干結構，目前用在超過70個Google計畫，包括Google Maps、Google Earth
、Blogger、Google Print、Orkut和核心搜尋索引。最大的BigTable實用範例管理橫跨數千台主機、約6 PT(petabytes)的資料。
Google在2003寫出第一版的
MapReduce，讓該公司有辦法實際發揮那些資料的用處。舉例來說，MapReduce能找出某個特定字彙在Google的搜尋
索引中出現的次數、列出所有特定字彙出現的網頁，和連結到某個特定網站的所有網站。
利用MapReduce，Google能用相對迅速的時間，建立一個包含"digital"、"network"和"society"三個字的所有網頁索引。"Dean說：「你必須能夠依序地
橫跨數千台主機作業，才能在一個合理的時間內完成這項工作。」
MapReduce軟體在Google內部的應用日漸增加，2004年8月，該軟體執行2.9萬項工作，到2007年9月，已經暴增到220萬項。在這段期間，完成一項
工作的平均時間也從634秒降至395秒，而MapReduce的工作產出則從193 terabytes上升到約1.4萬terabytes。Dean說，Google在任何一天都要執行約
10萬項MapReduce工作，每一項工作佔用400台伺服器，且需要5到10分鐘完成。
MapReduce就像GFS，是特別設計用來迴避伺服器問題的。Dean表示：「當某台主機故障，主伺服器知道那台機器正在執行什麼工作，將命令其他主機
接手那項map工作。你可能影響到100個map工作，但會有100台主機接手那些工作。」
MapReduce的可靠度一度遭到嚴厲的試煉，當時一個1,800台伺服器的叢集正進行維護作業，工作人員一次拔下80台主機的插頭，同時另外1,720台主機
必須接下停頓的工作。Dean說：「速度變得有點慢，但工作全部完成。」而在一次2004年的簡報中，一個1,800台叢集的系統，承受了1,600台伺服器同時故障。
所以，Google資料中心的運作似乎如魚得水，一切順利。但該公司還不滿足，列出了一長串待改進的事項。大多數公司都試圖找出如何平順地將工作在
伺服器之間轉移，但Google已經超越了那項挑戰，他們要能夠自由、平順，且自動地，將工作在各個資料中心間轉移。
Dean說：「我們下一代的基礎設施要是一個能夠橫跨大區塊主機轉移，而非單一機器的系統。」目前，某些大型的檔案系統具有不同的名稱，如
GFS/Oregon和GFS/Atlanta，但他們都是彼此的拷貝。他表示：「我們要一個單一的名稱集。」
Google種種獨創的系統替他們開創了天下，也建立了其他競爭者很難跨過的門檻，但是隨著越來越複雜的環境，Google自己需要解決的問題，肯定挑戰會越來越大。
From:
http://www.dns.com.tw/blog/2008/06/google.html
