云端磁盤(pán):網(wǎng)絡(luò)巨頭如何存儲(chǔ)數(shù)據(jù)(上)

責(zé)任編輯:vivian

2012-04-10 08:54:56

摘自:存儲(chǔ)在線(xiàn)

支持谷歌搜索引擎的存儲(chǔ)系統(tǒng)必須能夠承受每天由運(yùn)行于數(shù)以千計(jì)的服務(wù)器上的成千上萬(wàn)的獨(dú)立進(jìn)程所發(fā)出的數(shù)百萬(wàn)計(jì)的讀寫(xiě)請(qǐng)求,幾乎不能停機(jī)來(lái)備份或維護(hù)。

細(xì)想支持谷歌主頁(yè)搜索框需要的技術(shù):背后的算法,緩存的搜索詞,和其他一些隨之而來(lái)的特性,比如當(dāng)你輸入一個(gè)位于數(shù)據(jù)存儲(chǔ)中的查詢(xún)時(shí),基本相當(dāng)于絕大多數(shù)網(wǎng)絡(luò)的一個(gè)全文本快照。當(dāng)你和成千上萬(wàn)的其他人同時(shí)提交搜索時(shí),這個(gè)快照也正在不斷地隨著這些變化被更新著。與此同時(shí),數(shù)據(jù)是由數(shù)以千計(jì)的獨(dú)立服務(wù)器進(jìn)程處理的,每個(gè)都各司其職,從計(jì)算出給你提供的相關(guān)聯(lián)廣告,到?jīng)Q定搜索結(jié)果的排列順序。

支持谷歌搜索引擎的存儲(chǔ)系統(tǒng)必須能夠承受每天由運(yùn)行于數(shù)以千計(jì)的服務(wù)器上的成千上萬(wàn)的獨(dú)立進(jìn)程所發(fā)出的數(shù)百萬(wàn)計(jì)的讀寫(xiě)請(qǐng)求,幾乎不能停機(jī)來(lái)備份或維護(hù),還必須不斷擴(kuò)容以容納由谷歌網(wǎng)頁(yè)抓取機(jī)器人添加的日益擴(kuò)大的眾多頁(yè)面??傮w下來(lái),谷歌每天要處理超過(guò)20PB。

這可不是谷歌可以從一個(gè)現(xiàn)成的存儲(chǔ)架構(gòu)就能完成的。而且對(duì)于運(yùn)行超大規(guī)模的數(shù)據(jù)中心的其他網(wǎng)絡(luò)和云計(jì)算巨頭來(lái)說(shuō)也是如此,比如亞馬遜和Facebook。雖然大多數(shù)數(shù)據(jù)中心已經(jīng)通過(guò)在一個(gè)存儲(chǔ)區(qū)網(wǎng)絡(luò)添加更多硬盤(pán)容量來(lái)解決擴(kuò)充存儲(chǔ)的問(wèn)題,更多的存儲(chǔ)服務(wù)器,通常是更多的數(shù)據(jù)庫(kù)服務(wù)器,因?yàn)樵骗h(huán)境的性能限制,這些方法卻失效了。在云環(huán)境下,任何時(shí)候都可能有成千上萬(wàn)的活躍用戶(hù)的數(shù)據(jù),而且數(shù)據(jù)的讀寫(xiě)在任何時(shí)刻都能達(dá)到數(shù)千TB。

這不僅僅是一個(gè)關(guān)于磁盤(pán)讀寫(xiě)速度的簡(jiǎn)單問(wèn)題。以這些卷上的數(shù)據(jù)流來(lái)講,主要的問(wèn)題是存儲(chǔ)網(wǎng)絡(luò)的吞吐量;即使有最好的交換機(jī)和存儲(chǔ)服務(wù)器,傳統(tǒng)的SAN架構(gòu)也能成為數(shù)據(jù)處理的性能瓶頸。

接下來(lái)就是老生常談的擴(kuò)大存儲(chǔ)的成本問(wèn)題。超大規(guī)模網(wǎng)絡(luò)公司增加容量的頻率(舉個(gè)例子,亞馬遜現(xiàn)在每天為其數(shù)據(jù)中心增加的容量相當(dāng)于整個(gè)公司在2001年全年的容量,根據(jù)亞馬遜副總裁杰姆斯·漢密爾頓的說(shuō)法),用大多數(shù)數(shù)據(jù)中心的同樣做法來(lái)擺平所需的存儲(chǔ),依照所需的管理,硬件和軟件成本,花費(fèi)將是巨大的。這種花費(fèi)在關(guān)系數(shù)據(jù)庫(kù)被添加到混合數(shù)據(jù)庫(kù)時(shí)甚至更高,這取決于一個(gè)組織對(duì)它們的分割和復(fù)制如何處理。

對(duì)于這種不斷擴(kuò)展和持久存儲(chǔ)的需求,驅(qū)使互聯(lián)網(wǎng)巨頭——谷歌,亞馬遜,F(xiàn)acebook,微軟等等——采取一種不同的存儲(chǔ)解決方案:基于對(duì)象存儲(chǔ)的分布式文件系統(tǒng)。這些系統(tǒng)至少都部分受到其他分布式集群文件系統(tǒng)的啟發(fā),如Red Hat的全局文件系統(tǒng)和IBM的通用并行文件系統(tǒng)。

這些云巨頭的分布式文件系統(tǒng)的架構(gòu)把元數(shù)據(jù)(關(guān)于內(nèi)容的數(shù)據(jù))從它存儲(chǔ)的數(shù)據(jù)中分開(kāi)。這能通過(guò)多個(gè)副本對(duì)數(shù)據(jù)進(jìn)行大量并行讀寫(xiě)操作,并且拋掉了像“文件鎖定”這樣的概念。

這些分布式文件系統(tǒng)的影響遠(yuǎn)遠(yuǎn)超出了它們?yōu)槌笠?guī)模數(shù)據(jù)中心而創(chuàng)建的范疇——它們會(huì)直接影響那些使用公共云服務(wù)的公司(比如亞馬遜的EC2,谷歌的AppEngine和微軟的Azure)如何開(kāi)發(fā)和部署程序。公司,大學(xué)和政府機(jī)構(gòu)尋找一種快速存儲(chǔ)和提供大量數(shù)據(jù)訪(fǎng)問(wèn)的方法正日益變成受云巨頭們啟發(fā)的數(shù)據(jù)存儲(chǔ)系統(tǒng)的新階段。因此有必要了解一下它們的發(fā)展史和過(guò)程中所做的工程折衷方案。

谷歌文件系統(tǒng)

谷歌是最早面對(duì)存儲(chǔ)容量問(wèn)題的主流網(wǎng)絡(luò)公司中的一家。在2003年,谷歌工程師們找到了問(wèn)題的答案,就是建立一個(gè)可為谷歌數(shù)據(jù)中心戰(zhàn)略定制的分布式文件系統(tǒng)——谷歌文件系統(tǒng)(GFS)。

谷歌文件系統(tǒng)幾乎是所有公司云服務(wù)的基礎(chǔ)。它能夠處理數(shù)據(jù)存儲(chǔ),包括公司的BigTable數(shù)據(jù)庫(kù)和為谷歌的AppEngine“平臺(tái)即服務(wù)”的數(shù) 據(jù)儲(chǔ)存,并且為谷歌搜索引擎和其他程序提供數(shù)據(jù)。谷歌創(chuàng)建谷歌文件系統(tǒng)的設(shè)計(jì)決定推動(dòng)了大量云架構(gòu)下的軟件工程技術(shù),反之亦然。谷歌往往把程序數(shù)據(jù)儲(chǔ)存在 大量的文件里,并把文件作為“生產(chǎn)者-消費(fèi)者隊(duì)列”使用,數(shù)以百計(jì)的機(jī)器收集的數(shù)據(jù)可能被寫(xiě)入同一個(gè)文件。這個(gè)文件可能會(huì)由另一個(gè)合并或分析數(shù)據(jù)的應(yīng)用程 序處理——或許甚至是在數(shù)據(jù)正被寫(xiě)入的時(shí)候。

“這當(dāng)中的某些服務(wù)器一定會(huì)出錯(cuò)——因此谷歌文件系統(tǒng)被設(shè)計(jì)為能夠容忍這種錯(cuò)誤,不會(huì)丟失(太多)數(shù)據(jù)”。

谷歌為自己保留了大量技術(shù)細(xì)節(jié),原因很明顯。但是由谷歌研究員Sanjay Ghemawat,首席工程師Howard Gobioff和高級(jí)工程師Shun-Tak Leung在2003首次發(fā)表的報(bào)告中提到,谷歌文件系統(tǒng)在設(shè)計(jì)上是帶有一些非常具體的優(yōu)先考慮的:谷歌想把大量便宜的服務(wù)器和硬盤(pán)驅(qū)動(dòng)器變成一個(gè)可以?xún)?chǔ) 存數(shù)百TB數(shù)據(jù)的能夠在出錯(cuò)時(shí)自行管理可靠的數(shù)據(jù)存儲(chǔ)。并且它需要被設(shè)計(jì)成按谷歌的方式收集和讀取數(shù)據(jù),允許多個(gè)應(yīng)用程序同時(shí)把大批量數(shù)據(jù)添加到系統(tǒng)上, 且能以高速訪(fǎng)問(wèn)。

就像是一個(gè)RAID 5存儲(chǔ)陣列通過(guò)多磁盤(pán)放置數(shù)據(jù)進(jìn)行出錯(cuò)保護(hù),谷歌文件系統(tǒng)把文件分成固定大小的塊,復(fù)制到整個(gè)服務(wù)器集群。因?yàn)樗鼈兪怯弥畠r(jià)硬盤(pán)的電腦,其中一些服務(wù)器肯定會(huì)出錯(cuò)——因此谷歌文件系統(tǒng)被設(shè)計(jì)為能夠容忍這種錯(cuò)誤,不會(huì)丟失(太多)數(shù)據(jù)。

但是RAID和GFS的相同點(diǎn)就到此為止了,因?yàn)槟切┓?wù)器可以分布于網(wǎng)絡(luò)——既可以在第一個(gè)單獨(dú)的物理數(shù)據(jù)中心也可以分散于不同的數(shù)據(jù)中心,取決 于數(shù)據(jù)的用途。GFS設(shè)計(jì)主要用于批量處理大量數(shù)據(jù)。重點(diǎn)是高速讀取數(shù)據(jù),而不是到文件中某個(gè)部分的訪(fǎng)問(wèn)速度,也不是數(shù)據(jù)寫(xiě)入到文件系統(tǒng)的速度。GFS提 供如此高輸出是以犧牲更高密度的讀寫(xiě)和更快速度的數(shù)據(jù)寫(xiě)入為代價(jià)的。正如Ghemawat和公司在文件中所說(shuō),“在文件中任意位置的小的寫(xiě)入是支持的,但 不一定非要高效。”

這種分布式的性質(zhì),隨著GFS處理數(shù)據(jù)量的龐大——數(shù)百萬(wàn)的文件,當(dāng)中很多都超過(guò)100MB而且通常都會(huì)變成GB——需要一些取舍,以便讓GFS和 你通常安裝在一臺(tái)服務(wù)器上的文件系統(tǒng)有很大的不同。因?yàn)槌砂偕锨У莫?dú)立進(jìn)程可能同時(shí)對(duì)一個(gè)文件進(jìn)行寫(xiě)入和讀取,GFS需要支持“原子性”數(shù)據(jù)——在不影響 其他程序的情況下回滾出錯(cuò)的寫(xiě)入。而且它需要以非常低的同步開(kāi)銷(xiāo)保持?jǐn)?shù)據(jù)的完整性以避免拖垮性能。

GFS由三層組成:GFS客戶(hù)端,處理程序數(shù)據(jù)請(qǐng)求;管理服務(wù)器,用內(nèi)存中的索引追蹤數(shù)據(jù)文件名和所在區(qū)塊的位置;還有數(shù)據(jù)存儲(chǔ)服務(wù)器本身。最初, 為簡(jiǎn)單起見(jiàn),GFS為每個(gè)集群使用一個(gè)單獨(dú)的管理服務(wù)器,因此系統(tǒng)被設(shè)計(jì)成讓管理服務(wù)器盡可能避開(kāi)數(shù)據(jù)訪(fǎng)問(wèn)。谷歌已經(jīng)發(fā)開(kāi)出了一個(gè)分布式管理服務(wù)器系統(tǒng), 可以控制數(shù)百臺(tái)管理服務(wù)器,每一臺(tái)都能處理大約1億個(gè)文件。

當(dāng)GFS客戶(hù)端收到一個(gè)特定數(shù)據(jù)文件的請(qǐng)求,它需要從管理服務(wù)器請(qǐng)求數(shù)據(jù)的位置。管理服務(wù)器提供其中一個(gè)副本的位置,之后客戶(hù)端就可以直接與存儲(chǔ)服務(wù)器進(jìn)行溝通,用來(lái)讀寫(xiě)剩下的其他部分。管理服務(wù)器就不再參與其中了,除非有錯(cuò)誤發(fā)生。

為確保數(shù)據(jù)是高度可用的,GFS舍棄了其他一些東西——比如各副本間的一致性。GFS確實(shí)堅(jiān)持?jǐn)?shù)據(jù)的原子性——如果寫(xiě)入失敗,它將返回一個(gè)錯(cuò)誤,然 后將寫(xiě)入回滾到元數(shù)據(jù),并產(chǎn)生一個(gè)舊數(shù)據(jù)的副本。但是管理服務(wù)器在數(shù)據(jù)寫(xiě)入上的介入缺失意味著當(dāng)數(shù)據(jù)寫(xiě)入到系統(tǒng)時(shí),它不能立刻讓副本遍布整個(gè)GFS集群。 在處理對(duì)數(shù)據(jù)同時(shí)訪(fǎng)問(wèn)和網(wǎng)絡(luò)限制的必要性之外,該系統(tǒng)遵循谷歌所謂的“寬松一致性模型”。

這意味著GFS對(duì)于在必要時(shí)從舊的副本提供陳舊的數(shù)據(jù)完全不在乎——只要數(shù)據(jù)最終得以更新。管理服務(wù)器的追蹤變化,或“突變”,當(dāng)變化發(fā)生時(shí),區(qū)塊中的數(shù)據(jù)會(huì)用版本號(hào)來(lái)指示。由于一些副本被留下了(或變“舊了”),GFS管理服務(wù)器會(huì)確保這些區(qū)塊在更新前不會(huì)送至客戶(hù)端。

但這并不一定發(fā)生在已經(jīng)連接到那些區(qū)塊的部分。元數(shù)據(jù)的變更在管理服務(wù)器處理這些變更,并將它們反映在元數(shù)據(jù)前是不可見(jiàn)的。元數(shù)據(jù)也需要在多個(gè)位置 生成副本,以防管理服務(wù)器出錯(cuò)——那樣的話(huà)整個(gè)文件系統(tǒng)就丟失了。而且如果在寫(xiě)入過(guò)程中管理服務(wù)器有錯(cuò)誤發(fā)生,變更同樣會(huì)消失。由于谷歌處理數(shù)據(jù)的方式, 這并不是一個(gè)大問(wèn)題:程序使用的大部分的數(shù)據(jù)很少變化,而且當(dāng)變化發(fā)生時(shí),數(shù)據(jù)通常是擴(kuò)充的而不是原地修改的。

當(dāng)GFS在為2003年運(yùn)行的谷歌應(yīng)用設(shè)計(jì)出來(lái)時(shí),離谷歌開(kāi)始遭遇擴(kuò)展性問(wèn)題并不遠(yuǎn)。甚至是在公司收購(gòu)YouTube之前,GFS開(kāi)始碰壁——很大 原因是谷歌新添加的應(yīng)用在64M文件大小下工作的不是很好。為了繞過(guò)它,谷歌轉(zhuǎn)向了Bigtable,一種基于表格的數(shù)據(jù)存儲(chǔ),那依稀類(lèi)似于數(shù)據(jù)庫(kù),位于 GFS之上。Bigtable大多是一次寫(xiě)入,因此變更被作為對(duì)表的擴(kuò)展進(jìn)行存儲(chǔ)的——谷歌將其用于如對(duì)Google Docs進(jìn)行版本控制的類(lèi)似應(yīng)用上。

如果你不是在谷歌工作,那上述內(nèi)容太過(guò)于學(xué)術(shù)性了(雖然它可以幫助AppEngine,谷歌云存儲(chǔ)和谷歌其他服務(wù)的用戶(hù)更好地了解臺(tái)面下是怎么事 兒)。雖然谷歌云存儲(chǔ)通過(guò)一個(gè)網(wǎng)絡(luò)接口提供了一個(gè)公開(kāi)方式來(lái)儲(chǔ)存和訪(fǎng)問(wèn)位于GFS上的文件,但是操控GFS的真正接口和工具并不是公開(kāi)的。但報(bào)告稱(chēng)GFS 引領(lǐng)了更廣泛使用的分布式文件系統(tǒng)的發(fā)展,如:Hadoop分布式文件系統(tǒng)。

Hadoop分布式文件系統(tǒng)(HDFS)

Hadoop是用Java開(kāi)發(fā)的,作為Apache基金會(huì)的一個(gè)開(kāi)源項(xiàng)目,它在網(wǎng)絡(luò)公司和其他有“大數(shù)據(jù)”問(wèn)題的公司間已經(jīng)有了如下的口碑,它被稱(chēng) 之為“二十一世界的瑞士軍刀”。所有這些宣傳意味著,你很可能會(huì)發(fā)現(xiàn)你遲早要以某種形式用Hadoop處理問(wèn)題而不是用其他的分布式文件系統(tǒng)——特別是當(dāng) 微軟開(kāi)始將其列入Windows Server的擴(kuò)展中的時(shí)候。

Hadoop是由開(kāi)發(fā)者Doug Cutting在他兒子給一只玩具大象起名后用它命名的,“靈感”來(lái)自于GFS和谷歌的MapReduce分布式計(jì)算環(huán)境。在2004年,Cutting 和其他工作于Apache Nutch搜索引擎項(xiàng)目的人試圖尋求一種可以將抓取器和索引帶向“網(wǎng)絡(luò)規(guī)模”的方式,Cutting閱讀了谷歌關(guān)于GFS和MapReduce的論文并開(kāi) 始動(dòng)手開(kāi)發(fā)自己的項(xiàng)目。雖然對(duì)于Hadoop的大多數(shù)熱情來(lái)自于它由MapReduce啟發(fā)的分布式處理管理衍生出的分布式數(shù)據(jù)處理能力,但使用 Hadoop分布式文件系統(tǒng)還是因?yàn)樗軐?duì)大量數(shù)據(jù)進(jìn)行處理。

Hadoop是在Apache許可證下開(kāi)發(fā)的,有許多商業(yè)和自由發(fā)行版可用。我用的版本來(lái)自Cloudera公司(Doug Cutting現(xiàn)在的東家)——Cloudera發(fā)行版包括了Apache Hadoop(CDH),Cloudera企業(yè)平臺(tái)的開(kāi)源版本,和Cloudera服務(wù)和配置特別版,它可免費(fèi)支持50個(gè)節(jié)點(diǎn)。

HortonWorks,該公司與微軟合作幫助后者把Hadoop移植到Azure和Windows Server,有其自己的基于Hadoop和HortonWorks數(shù)據(jù)平臺(tái),是一個(gè)受限的“技術(shù)預(yù)覽版”。同樣還有Apache Core的Debian包,和許多其他開(kāi)源的或商業(yè)的基于Hadoop的某種形式的產(chǎn)品。

HDFS可被用于支持在大量廉價(jià)硬件和大數(shù)據(jù)下廣泛的應(yīng)用。但由于其架構(gòu),它不完全適合于通用數(shù)據(jù)存儲(chǔ),并且放棄了一定的靈活性。HDFS必須廢除 某些經(jīng)常與文件系統(tǒng)有關(guān)的事情,以確保它能更好地處理在分布著數(shù)百甚至數(shù)千臺(tái)物理機(jī)器上的大量數(shù)據(jù)——如對(duì)數(shù)據(jù)交互訪(fǎng)問(wèn)這種事情。

雖然Hadoop運(yùn)行于Java上,但是除了它的Java API之外還有許多種方式和HDFS進(jìn)行交互。有一種C語(yǔ)言版本的API,通過(guò)Hadoop的命令行界面,文件可以通過(guò)HTTP請(qǐng)求瀏覽。還有 MountableHDFS,一個(gè)基于FUSE的擴(kuò)展,允許HDFS被大多數(shù)操作系統(tǒng)作為一個(gè)文件系統(tǒng)掛載。開(kāi)發(fā)者們正在制作一個(gè)WebDAV接口,讓系 統(tǒng)可以進(jìn)行基于網(wǎng)絡(luò)的數(shù)據(jù)寫(xiě)入。

HDFS嚴(yán)格遵循了由谷歌的GFS奠定的架構(gòu)路線(xiàn),延續(xù)了它的三層,單管理服務(wù)器模型。每個(gè)Hadoop集群有一個(gè)叫做“名字節(jié)點(diǎn)”的管理服務(wù)器, 它來(lái)追蹤關(guān)于位置和每個(gè)64M存儲(chǔ)“塊”副本的狀態(tài)的元數(shù)據(jù)。數(shù)據(jù)通過(guò)集群中的“數(shù)據(jù)節(jié)點(diǎn)”復(fù)制——從屬系統(tǒng)處理數(shù)據(jù)的讀寫(xiě)。默認(rèn)情況下每個(gè)塊都會(huì)被復(fù)制 三次,而且復(fù)制的次數(shù)還可以通過(guò)改變集群設(shè)置來(lái)增加。

像GFS一樣,HDFS讓管理服務(wù)器盡可能快地避開(kāi)讀寫(xiě)循環(huán),避免產(chǎn)生性能瓶頸。當(dāng)從HDFS上訪(fǎng)問(wèn)數(shù)據(jù)的請(qǐng)求產(chǎn)生時(shí),名字節(jié)點(diǎn)發(fā)回與這個(gè)請(qǐng)求最近 的數(shù)據(jù)節(jié)點(diǎn)上的塊的位置信息。名字節(jié)點(diǎn)還可以通過(guò)一個(gè)“心跳”協(xié)議追蹤每個(gè)數(shù)據(jù)節(jié)點(diǎn)的健康度并停止向不響應(yīng)的數(shù)據(jù)節(jié)點(diǎn)發(fā)送請(qǐng)求,把它們標(biāo)記為“死的”。

在切換后,名字節(jié)點(diǎn)就不處理任何更進(jìn)一步的交互。對(duì)數(shù)據(jù)節(jié)點(diǎn)上數(shù)據(jù)的編輯被報(bào)告回名字節(jié)點(diǎn)并記錄在日志里,之后用變動(dòng)的數(shù)據(jù)副本對(duì)其他數(shù)據(jù)節(jié)點(diǎn)進(jìn)行 復(fù)制。同GFS一樣,這導(dǎo)致了一致性上相應(yīng)的懶散形式,而且雖然名字節(jié)點(diǎn)將為最近修改的數(shù)據(jù)塊發(fā)送新的請(qǐng)求,正在進(jìn)行的工作仍然會(huì)碰到它們被分配到的數(shù)據(jù) 節(jié)點(diǎn)上的陳舊數(shù)據(jù)。

那不應(yīng)該是經(jīng)常發(fā)生的,然而,因?yàn)镠DFS數(shù)據(jù)應(yīng)該被“寫(xiě)入一次”——變動(dòng)通常是擴(kuò)充數(shù)據(jù),而不是改動(dòng)現(xiàn)有數(shù)據(jù),為了更簡(jiǎn)單的一致性。而且由于Hadoop應(yīng)用的性質(zhì),數(shù)據(jù)往往會(huì)大批量地寫(xiě)入HDFS。

當(dāng)一個(gè)客戶(hù)端發(fā)送要寫(xiě)入HDFS的數(shù)據(jù)時(shí),它首先被客戶(hù)端程序安置在一個(gè)臨時(shí)的本地文件中,直到寫(xiě)入的數(shù)據(jù)達(dá)到了數(shù)據(jù)塊的大小——默認(rèn)64MB。之 后客戶(hù)端聯(lián)系名字節(jié)點(diǎn)并獲得一個(gè)數(shù)據(jù)節(jié)點(diǎn)和要寫(xiě)入數(shù)據(jù)的塊位置。這一過(guò)程對(duì)每個(gè)塊的數(shù)據(jù)重復(fù)進(jìn)行,一次一個(gè)塊。這減少了產(chǎn)生網(wǎng)絡(luò)阻塞的數(shù)量,但也減慢了寫(xiě) 入過(guò)程。但是HDFS是用于讀取的,而不是寫(xiě)入。

HDFS可以減少網(wǎng)絡(luò)寫(xiě)入流量的另一個(gè)辦法是在于它處理復(fù)制的方式。通過(guò)激活一個(gè)叫做“機(jī)架感知”的HDFS特性來(lái)管理分布的副本,管理員可以為每 個(gè)節(jié)點(diǎn)指定一個(gè)機(jī)架序號(hào),通過(guò)網(wǎng)絡(luò)配置腳本中的一個(gè)變量指定它的物理位置。默認(rèn)情況下,所有的節(jié)點(diǎn)都在同一個(gè)“機(jī)架”中。但是當(dāng)機(jī)架感知被配置以 后,HDFS把每個(gè)塊上的一個(gè)副本放置于同一個(gè)數(shù)據(jù)中心機(jī)架的另一個(gè)節(jié)點(diǎn)上,另一個(gè)則在不同的機(jī)架上,來(lái)減少網(wǎng)絡(luò)中數(shù)據(jù)寫(xiě)入量——基于如下理由,就是一整 個(gè)機(jī)架出錯(cuò)的幾率比一個(gè)單一節(jié)點(diǎn)出錯(cuò)的幾率要小。理論上,它整體改善了HDFS的寫(xiě)入性能而沒(méi)有犧牲掉可靠性。

與GFS早期版本一樣,對(duì)于一個(gè)要成為高度可用的分布式系統(tǒng),HDFS的名字節(jié)點(diǎn)創(chuàng)建一個(gè)單一的故障點(diǎn)。如果名字節(jié)點(diǎn)中的元數(shù)據(jù)丟失了,整個(gè) HDFS環(huán)境就變成不可讀了——就像一個(gè)缺少了文件分配表的硬盤(pán)。HDFS支持使用“備份節(jié)點(diǎn)”,它能與內(nèi)存中的名字節(jié)點(diǎn)的元數(shù)據(jù)保持版本同步,并儲(chǔ)存前 一系統(tǒng)狀態(tài)的快照,以便能夠在需要時(shí)回滾??煺找部梢员环珠_(kāi)儲(chǔ)存在叫做“檢查節(jié)點(diǎn)”的地方。然而,根據(jù)HDFS的文檔,目前還不支持自動(dòng)重啟一個(gè)破壞的名 字節(jié)點(diǎn),而且備份節(jié)點(diǎn)不會(huì)自動(dòng)移除和替代管理服務(wù)器。

HDFS和GFS都是用搜索引擎式任務(wù)的思想而開(kāi)發(fā)的。但是對(duì)于面向更多通用計(jì)算類(lèi)型的云服務(wù),“寫(xiě)入一次”的方法和其他妥協(xié)辦法使得大數(shù)據(jù)查詢(xún)性能不盡理想——這就是為什么亞馬遜開(kāi)發(fā)了自己的分布式存儲(chǔ)平臺(tái),叫做Dynamo。

云端磁盤(pán):網(wǎng)絡(luò)巨頭如何存儲(chǔ)數(shù)據(jù)(下)

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)