gfs文件存儲原理

❶ gfs採用了哪些容錯措施來確保整個系統的可靠性

GFS的精彩在於它採用了多種方法，從多個角度，使用不同的容錯措施來確保整個系統的可靠性。
2.1.1 系統架構
GFS的系統架構如圖2-1[1]所示。GFS將整個系統的節點分為三類角色：Client（客戶端）、Master（主伺服器）和Chunk Server（數據塊伺服器）。Client是GFS提供給應用程序的訪問介面，它是一組專用介面，不遵守POSIX規范，以庫文件的形式提供。應用程序直接調用這些庫函數，並與該庫鏈接在一起。Master是GFS的管理節點，在邏輯上只有一個，它保存系統的元數據，負責整個文件系統的管理，是GFS文件系統中的「大腦」。Chunk Server負責具體的存儲工作。數據以文件的形式存儲在Chunk Server上，Chunk Server的個數可以有多個，它的數目直接決定了GFS的規模。GFS將文件按照固定大小進行分塊，默認是64MB，每一塊稱為一個Chunk（數據塊），每個Chunk都有一個對應的索引號（Index）。

客戶端在訪問GFS時，首先訪問Master節點，獲取將要與之進行交互的Chunk Server信息，然後直接訪問這些Chunk Server完成數據存取。GFS的這種設計方法實現了控制流和數據流的分離。Client與Master之間只有控制流，而無數據流，這樣就極大地降低了Master的負載，使之不成為系統性能的一個瓶頸。Client與Chunk Server之間直接傳輸數據流，同時由於文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使得整個系統的I/O高度並行，系統整體性能得到提高。

相對於傳統的分布式文件系統，GFS針對Google應用的特點從多個方面進行了簡化，從而在一定規模下達到成本、可靠性和性能的最佳平衡。具體來說，它具有以下幾個特點。
1．採用中心伺服器模式
GFS採用中心伺服器模式來管理整個文件系統，可以大大簡化設計，從而降低實現難度。Master管理了分布式文件系統中的所有元數據。文件劃分為Chunk進行存儲，對於Master來說，每個Chunk Server只是一個存儲空間。Client發起的所有操作都需要先通過Master才能執行。這樣做有許多好處，增加新的Chunk Server是一件十分容易的事情，Chunk Server只需要注冊到Master上即可，Chunk Server之間無任何關系。如果採用完全對等的、無中心的模式，那麼如何將Chunk Server的更新信息通知到每一個Chunk Server，會是設計的一個難點，而這也將在一定程度上影響系統的擴展性。Master維護了一個統一的命名空間，同時掌握整個系統內Chunk Server的情況，據此可以實現整個系統范圍內數據存儲的負載均衡。由於只有一個中心伺服器，元數據的一致性問題自然解決。當然，中心伺服器模式也帶來一些固有的缺點，比如極易成為整個系統的瓶頸等。GFS採用多種機制來避免Master成為系統性能和可靠性上的瓶頸，如盡量控制元數據的規模、對Master進行遠程備份、控制信息和數據分流等。
2．不緩存數據
緩存（Cache）機制是提升文件系統性能的一個重要手段，通用文件系統為了提高性能，一般需要實現復雜的緩存機制。GFS文件系統根據應用的特點，沒有實現緩存，這是從必要性和可行性兩方面考慮的。從必要性上講，客戶端大部分是流式順序讀寫，並不存在大量的重復讀寫，緩存這部分數據對系統整體性能的提高作用不大；而對於Chunk Server，由於GFS的數據在Chunk Server上以文件的形式存儲，如果對某塊數據讀取頻繁，本地的文件系統自然會將其緩存。從可行性上講，如何維護緩存與實際數據之間的一致性是一個極其復雜的問題，在GFS中各個Chunk Server的穩定性都無法確保，加之網路等多種不確定因素，一致性問題尤為復雜。此外由於讀取的數據量巨大，以當前的內存容量無法完全緩存。對於存儲在Master中的元數據，GFS採取了緩存策略，GFS中Client發起的所有操作都需要先經過Master。Master需要對其元數據進行頻繁操作，為了提高操作的效率，Master的元數據都是直接保存在內存中進行操作。同時採用相應的壓縮機制降低元數據佔用空間的大小，提高內存的利用率。
3．在用戶態下實現
文件系統作為操作系統的重要組成部分，其實現通常位於操作系統底層。以Linux為例，無論是本地文件系統如Ext3文件系統，還是分布式文件系統如Lustre等，都是在內核態實現的。在內核態實現文件系統，可以更好地和操作系統本身結合，向上提供兼容的POSIX介面。然而，GFS卻選擇在用戶態下實現，主要基於以下考慮。
在用戶態下實現，直接利用操作系統提供的POSIX編程介面就可以存取數據，無需了解操作系統的內部實現機制和介面，從而降低了實現的難度，並提高了通用性。


POSIX介面提供的功能更為豐富，在實現過程中可以利用更多的特性，而不像內核編程那樣受限。
用戶態下有多種調試工具，而在內核態中調試相對比較困難。
用戶態下，Master和Chunk Server都以進程的方式運行，單個進程不會影響到整個操作系統，從而可以對其進行充分優化。在內核態下，如果不能很 好地掌握其特性，效率不但不會高，甚至還會影響到整個系統運行的穩定性。
用戶態下，GFS和操作系統運行在不同的空間，兩者耦合性降低，從而方便GFS自身和內核的單獨升級。


4．只提供專用介面
通常的分布式文件系統一般都會提供一組與POSIX規范兼容的介面。其優點是應用程序可以通過操作系統的統一介面來透明地訪問文件系統，而不需要重新編譯程序。GFS在設計之初，是完全面向Google的應用的，採用了專用的文件系統訪問介面。介面以庫文件的形式提供，應用程序與庫文件一起編譯，Google應用程序在代碼中通過調用這些庫文件的API，完成對GFS文件系統的訪問。採用專用介面有以下好處。


降低了實現的難度。通常與POSIX兼容的介面需要在操作系統內核一級實現，而GFS是在應用層實現的。
採用專用介面可以根據應用的特點對應用提供一些特殊支持，如支持多個文件並發追加的介面等。
專用介面直接和Client、Master、Chunk Server交互，減少了操作系統之間上下文的切換，降低了復雜度，提高了效率。

❷ GFS的GFS架構

GFS的新穎之處並不在於它採用了多麼令人驚訝的新技術，而在於它採用廉價的商用計算機集群構建分布式文件系統，在降低成本的同時經受了實際應用的考驗。
如上圖所示，一個GFS包括一個主伺服器（master）和多個塊伺服器（chunk server），這樣一個GFS能夠同時為多個客戶端應用程序（Application）提供文件服務。文件被劃分為固定的塊，由主伺服器安排存放到塊伺服器的本地硬碟上。主伺服器會記錄存放位置等數據，並負責維護和管理文件系統，包括塊的租用、垃圾塊的回收以及塊在不同塊伺服器之間的遷移。此外，主伺服器還周期性地與每個塊伺服器通過消息交互，以監視運行狀態或下達命令。應用程序通過與主伺服器和塊伺服器的交互來實現對應用數據的讀寫，應用與主伺服器之間的交互僅限於元數據，也就是一些控制數據，其他的數據操作都是直接與塊伺服器交互的。這種控制與業務相分離的架構，在互聯網產品方案上較為廣泛，也較為成功。
⑷單master
只 有一個master也極大的簡化了設計並使得master可以根據全局情況作出精密的塊放置和復制決定。但是我們必須要將master對讀和寫的參與減至 最少，這樣它才不會成為系統的瓶頸。Client從來不會從master讀和寫文件數據。Client只是詢問master它應該和哪個 chunkserver聯系。Client在一段限定的時間內將這些信息緩存，在後續的操作中Client直接和chunkserver交互。
以圖1解釋一下一個簡單的讀操作的交互。
⒈client使用固定的塊大小將應用程序指定的文件名和位元組偏移轉換成文件的一個塊索引（chunk index）。
⒉給master發送一個包含文件名和塊索引的請求。
⒊master回應對應的chunk handle和副本的位置（多個副本）。
⒋client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。
⒌Client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個位元組區間。
⒍除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以後對同一個塊的讀操作不再需要client和master間的交互。
通常Client可以在一個請求中詢問多個chunk的地址，而master也可以很快回應這些請求。
⑸塊規模
塊規模是設計中的一個關鍵參數。我們選擇的是64MB，這比一般的文件系統的塊規模要大的多。每個塊的副本作為一個普通的Linux文件存儲，在需要的時候可以擴展。
塊規模較大的好處有：
⒈減少client和master之間的交互。因為讀寫同一個塊只是要在開始時向master請求塊位置信息。對於讀寫大型文件這種減少尤為重要。即使對於訪問少量數據的隨機讀操作也可以很方便的為一個規模達幾個TB的工作集緩緩存塊位置信息。
⒉Client在一個給定的塊上很可能執行多個操作，和一個chunkserver保持較長時間的TCP連接可以減少網路負載。
⒊這減少了master上保存的元數據（metadata）的規模，從而使得可以將metadata放在內存中。這又會帶來一些別的好處。
不利的一面：
一個小文件可能只包含一個塊，如果很多Client訪問該文件的話，存儲這些塊的chunkserver將成為訪問的熱點。但在實際應用中，應用程序通常順序地讀包含多個塊的文件，所以這不是一個主要問題。
⑹元數據（metadata）
master 存儲了三種類型的metadata：文件的名字空間和塊的名字空間，從文件到塊的映射，塊的副本的位置。所有的metadata都放在內存中。前兩種類型 的metadata通過向操作日誌登記修改而保持不變，操作日誌存儲在master的本地磁碟並在幾個遠程機器上留有副本。使用日誌使得我們可以很簡單 地、可靠地更新master的狀態，即使在master崩潰的情況下也不會有不一致的問題。相反，master在每次啟動以及當有 chunkserver加入的時候詢問每個chunkserver的所擁有的塊的情況。
A、內存數據結構：
因為metadata存儲在內存中，所以master的操作很快。進一步，master可以輕易而且高效地定期在後台掃描它的整個狀態。這種定期地掃描被用於實現塊垃圾收集、chunkserver出現故障時的副本復制、為平衡負載和磁碟空間而進行的塊遷移。
這 種方法的一個潛在的問題就是塊的數量也即整個系統的容量是否受限與master的內存。實際上，這並不是一個嚴重的問題。Master為每個 64MB的塊維護的metadata不足64個位元組。除了最後一塊，文件所有的塊都是滿的。類似的，每個文件的名字空間數據也不足64個位元組，因為文件名 是以一種事先確定的壓縮方式存儲的.如果要支持更大的文件系統，那麼增加一些內存的方法對於我們將元數據（metadata）保存在內存中所獲得的簡單 性、可靠性、高性能和靈活性來說，這只是一個很小的代價。
B、塊位置：
master並不為chunkserver所擁有的塊的副本的保存一個不變的記錄。它在啟動時通過簡單的查詢來獲得這些信息。Master可以保持這些信息的更新，因為它控制所有塊的放置並通過HeartBeat消息來監控chunkserver的狀態。
這樣做的好處：因為chunkserver可能加入或離開集群、改變路徑名、崩潰、重啟等，一個集群中有成百個server，這些事件經常發生，這種方法就排除了master與chunkserver之間的同步問題。
另一個原因是：只有chunkserver才能確定它自己到底有哪些塊，由於錯誤，chunkserver中的一些塊可能會很自然的消失，這樣在master中就沒有必要為此保存一個不變的記錄。
C、操作日誌：
操作日誌包含了對metadata所作的修改的歷史記錄。它作為邏輯時間線定義了並發操作的執行順序。文件、塊以及它們的版本號都由它們被創建時的邏輯時間而唯一地、永久地被標識。
操作日誌是如此的重要，我們必須要將它可靠地保存起來，並且只有在metadata的改變固定下來之後才將變化呈現給用戶。所以我們將操作日誌復制到數個遠程的機器上，並且只有在將相應的日誌記錄寫到本地和遠程的磁碟上之後才回答用戶的請求。
Master可以用操作日誌來恢復它的文件系統的狀態。為了將啟動時間減至最小，日誌就必須要比較小。每當日誌的長度增長到超過一定的規模後，master就要檢查它的狀態，它可以從本地磁碟裝入最近的檢查點來恢復狀態。
創 建一個檢查點比較費時，master的內部狀態是以一種在創建一個檢查點時並不耽誤即將到來的修改操作的方式來組織的。Master切換到一個新的日誌文件並在一個單獨的線程中創建檢查點。這個新的檢查點記錄了切換前所有的修改。在一個有數十萬文件的集群中用一分鍾左右就能完成。創建完後，將它寫入本地和 遠程的磁碟。
⑺數據完整性
名字空間的修改必須是原子性的，它們只能有master處理：名字空間鎖保證了操作的原子性和正確性，而master的操作日誌在全局范圍內定義了這些操作的順序。
文件區間的狀態在修改之後依賴於修改的類型，不論操作成功還是失敗，也不論是不是並發操作。如果不論從哪個副本上讀，所有的客戶都看到同樣的數據，那麼文件 的這個區域就是一致的。如果文件的區域是一致的並且用戶可以看到修改操作所寫的數據，那麼它就是已定義的。如果修改是在沒有並發寫操作的影響下完成的，那麼受影響的區域是已定義的，所有的client都能看到寫的內容。成功的並發寫操作是未定義但卻是一致的。失敗的修改將使區間處於不一致的狀態。
Write操作在應用程序指定的偏移處寫入數據，而record append操作使得數據（記錄）即使在有並發修改操作的情況下也至少原子性的被加到GFS指定的偏移處，偏移地址被返回給用戶。
在一系列成功的修改操作後，最後的修改操作保證文件區域是已定義的。GFS通過對所有的副本執行同樣順序的修改操作並且使用塊版本號檢測過時的副本（由於chunkserver退出而導致丟失修改）來做到這一點。
因為用戶緩存了會位置信息，所以在更新緩存之前有可能從一個過時的副本中讀取數據。但這有緩存的截止時間和文件的重新打開而受到限制。
在修改操作成功後，部件故障仍可以是數據受到破壞。GFS通過master和chunkserver間定期的handshake，藉助校驗和來檢測對數據的破壞。一旦檢測到，就從一個有效的副本盡快重新存儲。只有在GFS檢測前，所有的副本都失效，這個塊才會丟失。

❸ 對比gfs和hdfs兩種文件系統的區別

分布式文件系統很多，包括GFS，HDFS，HDFS基本可以認為是GFS的一個簡化版實現，二者因此有很多相似之處。首先，GFS和HDFS都採用單一主控機+多台工作機的模式，由一台主控機(Master)存儲系統全部元數據，並實現數據的分布、復制、備份決策，主控機還實現了元數據的checkpoint和操作日誌記錄及回放功能。工作機存儲數據，並根據主控機的指令進行數據存儲、數據遷移和數據計算等。其次，GFS和HDFS都通過數據分塊和復制（多副本，一般是3）來提供更高的可靠性和更高的性能。當其中一個副本不可用時，系統都提供副本自動復制功能。同時，針對數據讀多於寫的特點，讀服務被分配到多個副本所在機器，提供了系統的整體性能。最後，GFS和HDFS都提供了一個樹結構的文件系統，實現了類似與Linux下的文件復制、改名、移動、創建、刪除操作以及簡單的許可權管理等。然而，GFS和HDFS在關鍵點的設計上差異很大，HDFS為了規避GFS的復雜度進行了很多簡化。首先，GFS最為復雜的部分是對多客戶端並發追加同一個文件，即多客戶端並發Append模型 。GFS允許文件被多次或者多個客戶端同時打開以追加數據，以記錄為單位。假設GFS追加記錄的大小為16KB ~ 16MB之間，平均大小為1MB，如果每次追加都訪問GFS Master顯然很低效，因此，GFS通過Lease機制將每個Chunk的寫許可權授權給Chunk Server。寫Lease的含義是Chunk Server對某個Chunk在Lease有效期內(假設為12s)有寫許可權，擁有Lease的Chunk Server稱為Primary Chunk Server，如果Primary Chunk Server宕機，Lease有效期過後Chunk的寫Lease可以分配給其它Chunk Server。多客戶端並發追加同一個文件導致Chunk Server需要對記錄進行定序，客戶端的寫操作失敗後可能重試，從而產生重復記錄，再加上客戶端API為非同步模型，又產生了記錄亂序問題。Append模型下重復記錄、亂序等問題加上Lease機制，尤其是同一個Chunk的Lease可能在Chunk Server之間遷移，極大地提高了系統設計和一致性模型的復雜度。而在HDFS中，HDFS文件只允許一次打開並追加數據，客戶端先把所有數據寫入本地的臨時文件中，等到數據量達到一個Chunk的大小（通常為64MB），請求HDFS Master分配工作機及Chunk編號，將一個Chunk的數據一次性寫入HDFS文件。由於累積64MB數據才進行實際寫HDFS系統，對HDFS Master造成的壓力不大，不需要類似GFS中的將寫Lease授權給工作機的機制，且沒有了重復記錄和亂序的問題，大大地簡化了系統的設計。然而，我們必須知道，HDFS由於不支持Append模型帶來的很多問題，構建於HDFS之上的Hypertable和HBase需要使用HDFS存放表格系統的操作日誌，由於HDFS的客戶端需要攢到64MB數據才一次性寫入到HDFS中，Hypertable和HBase中的表格服務節點(對應於Bigtable中的Tablet Server)如果宕機，部分操作日誌沒有寫入到HDFS，可能會丟數據。其次是Master單點失效的處理 。GFS中採用主從模式備份Master的系統元數據，當主Master失效時，可以通過分布式選舉備機接替主Master繼續對外提供服務，而由於Replication及主備切換本身有一定的復雜性，HDFS Master的持久化數據只寫入到本機（可能寫入多份存放到Master機器的多個磁碟中防止某個磁碟損害），出現故障時需要人工介入。另外一點是對快照的支持 。GFS通過內部採用-on-write的數據結構實現集群快照功能，而HDFS不提供快照功能。在大規模分布式系統中，程序有bug是很正常的情況，雖然大多數情況下可以修復bug，不過很難通過補償操作將系統數據恢復到一致的狀態，往往需要底層系統提供快照功能，將系統恢復到最近的某個一致狀態。總之，HDFS基本可以認為是GFS的簡化版，由於時間及應用場景等各方面的原因對GFS的功能做了一定的簡化，大大降低了復雜度。

❹ 如何利用Linux和GFS打造集群存儲

負載均衡是一項困難的任務。我們經常需要通過NFS(網路文件系統)或其他機制來為數據提供中心地址，從而共享文件系統。雖然你的安全機制可能可以讓你免於Web伺服器節點的故障，但是你仍然需要通過中央存儲節點來共享數據。
通過GFS(全局文件系統)——Linux的一個免費集群文件系統——你可以創建一個不需要依賴其他伺服器的真正穩定的集群。在這篇文章中，我們將展示如何正確地設置GFS.
從概念上來說，一個集群文件系統可以允許多個操作系統載入同一個文件系統並可以在同一時間內向同一文件系統寫入數據。現在有許多集群文件系統，包括Sun的Lustre，Oracle的OCFS(Oracle集群文件系統)，以及Linux的GFS.
有許多方法可以讓一個塊設備同時被多個伺服器所使用。你可以分區出一個對多個伺服器都可視的SAN(存儲區域網)LUN(邏輯單元號)，設置好相應的iSCSI(互聯網小型計算機系統介面)，或使用DRBD(分布式復制塊設備)在兩台伺服器之間復制一個分區。在使用DRBD的時候，你將需要在主/主節點中設置好DRBD以使用GFS.
GFS要求
運行GFS意味著你在運行一個集群。目前為止，運行GFS的最簡單的手段就是使用Red Hat Cluster Suite(RHCS：Red Hat集群套件)。這個套件在CentOS中就有。此外，還需要下面這些包：cman——集群管理器;lvm2-cluster——使LVM(邏輯卷管理器)可以支持集群的CLVM(集群邏輯卷管理器)包;kmod-gfs——GFS內核模塊;最後是gfs-utils.
集群管理器(cman)包含必要的工具，比如分布式鎖管理器。除非你希望花時間來確認各種不同的分發版本是如何採用cman的，否則我們強烈推薦使用CentOS或RHEL.同時，你還將獲得RH(Red Hat)所維護的各種最新版本的集群服務，此外你還可以獲得一個比較穩定的環境。
Fencing(阻絕)機制是絕對必要的。一些指導性文章建議將阻絕模式設定成"手動"，因為阻絕設置有可能比較復雜。阻絕意味在集群中進行隔離，或馬上中斷某些危險節點的運作。如果集群無法阻絕某個發生故障的節點，那麼你的GFS將會出現很多問題，因此不要跳過這個步驟。
創建集群設置
你可以通過/etc/cluster/裡面的cluster.conf完成大部分的集群設置。我不建議使用各種集群管理應用程序來創建這個設置文件。即使是完全支持的RHEL應用程序，比如兩個月前發布的Conga，也經常會創建一些無效的cluster.conf文件，並且無法被必要的服務所解析。
下面是一個cluster.conf文件的例子。這個設置文件採用漂亮的XML格式，其內容非常直接。首先，我們對集群進行命名，我們將這個集群稱作"Web.1".
先跳過fence daemon選項，下一個部分就是集群主體的設置內容。你需要在clusternodes部分定義兩個節點。設置文件將同時存放在兩個節點上，這樣這兩個節點就都知道彼此的情況。
集群內的每個節點都聲明其阻絕方式的名稱是獨一無二的。在clusternames結束標簽下面，我們看到fencedevice部分定義了每個節點如何阻絕其他節點的方式。使用一個支持IPMI(智能平台管理介面)的伺服器是最好的方式，而且其設置也是相當簡單。你只要將IPMI的地點以及登錄方式告訴IP就可以了。為了避免在cluster.conf中留下密碼，你可以將它指向一個由根所擁有的腳本並由這個腳本來返回密碼。
我們還要指出的是我們在設置中定義了兩個節點。這是必須的，因為通常來說，除非大部分節點都同意自己的狀態，否則集群無法達到"Quorate"狀態。如果只有兩個節點的話，沒有肯定多數，因此這種方式讓集群只能在兩個節點下工作，而不能只在只有一個節點的情況下工作。這是設置基本集群的必要方式。
在每個節點上運行"service cman start"，系統應該可以開始正常運作。你可以檢查"clustat"或"cman nodes"來確認節點是否良好運行。如果有哪個必要的部分沒有啟動，那麼集群將不會顯示"Quorate"狀態。
GFS設置
首先，我們需要設置CLVM，這樣我們才可以通過GFS使用LVM.激活CLVM只要在lvm.conf中設定"locking type=3"就可以了。
然後，就像平常一樣創建一個LVM卷組和卷，但是使用的是共享的塊設備。如果你使用的是DRBD，你將有可能使用/dev/drbd0.我創建了一個物理卷，然後創建一個名為vg01的卷組，然後創建一個名為web1的邏輯卷，這個卷在：/dev/vg01/web1.
最後，我們需要創建文件系統：
gfs_mkfs -t web1：mygfs -p lock_dlm -j 2 /dev/vg01/web1
-t中給定的名稱必須是集群的名稱，然後後面是你給這個文件系統所起的名字。只有web1集群的成員才可以載入這個文件系統。然後，設定分布式鎖管理器的鎖鑰類型，指明你需要兩份journal(因為這是一個雙節點集群)。如果你預計未來要增加更多的節點，那麼你需要在這時設定足夠高的journal數量。
總結
我們現在可以開始使用這個文件系統了。在兩個節點上啟動"clvmd"和"gfs"服務。現在你就可以通過"-t gfs"來將類型指定為GFS，從而載入文件系統。
在開始啟動之前，一定要設定好cman，clvmd和gfs服務。你最好能熟悉clustat和gfs_tool命令，因為在系統出現問題的時候，你可以用這些命令來查找問題所在。
不要指望GFS能很快。如果有一個節點在進行大量的寫入操作的話，那麼在訪問文件系統的時候出現停頓是很正常的。對於一個數據讀取操作比數據寫入操作多得多的Web集群來說，這倒不是什麼問題。如果出現明顯延遲，那麼首先要檢查一下所有組件的狀況，然後評估正在寫入的數據。防止延遲現象的最常見措施就是確保HTTP對話中的數據不是寫入GFS卷。

❺ GFS採用了哪些容錯措施來確保整個系統的可靠性

GFS的精彩在於它採用了多種方法，從多個角度，使用不同的容錯措施來確保整個系統的可靠性。
客戶端在訪問GFS時，首先訪問Master節點，獲取將要與之進行交互的Chunk Server信息，然後直接訪問這些Chunk Server完成數據存取。GFS的這種設計方法實現了控制流和數據流的分離。Client與Master之間只有控制流，而無數據流，這樣就極大地降低了Master的負載，使之不成為系統性能的一個瓶頸。Client與Chunk Server之間直接傳輸數據流，同時由於文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使得整個系統的I/O高度並行，系統整體性能得到提高。

❻ 4.GFS文件管理技術有哪些特點

雲計算關鍵技術 雲計算是分布式處理、並行計算和網格計算等概念的發展和商業實現，其技術實質是計算、存儲、伺服器、應用軟體等IT軟硬體資源的虛擬化，雲計算在虛擬化、數據存儲、數據管理、編程模式等方面具有自身獨特的技術。雲計算的關鍵技術包括以下幾個方向： 虛擬機技術 虛擬機，即伺服器虛擬化是雲計算底層架構的重要基石。在伺服器虛擬化中，虛擬化軟體需要實現對硬體的抽象，資源的分配、調度和管理，虛擬機與宿主操作系統及多個虛擬機間的隔離等功能，目前典型的實現（基本成為事實標准）有Citrix Xen、VMware ESX Server 和Microsoft Hype-V等。 數據存儲技術 雲計算系統需要同時滿足大量用戶的需求，並行地為大量用戶提供服務。因此，雲計算的數據存儲技術必須具有分布式、高吞吐率和高傳輸率的特點。目前數據存儲技術主要有Google的GFS（Google File System，非開源）以及HDFS（Hadoop Distributed File System，開源），目前這兩種技術已經成為事實標准。 數據管理技術 雲計算的特點是對海量的數據存儲、讀取後進行大量的分析，如何提高數據的更新速率以及進一步提高隨機讀速率是未來的數據管理技術必須解決的問題。雲計算的數據管理技術最著名的是谷歌的BigTable數據管理技術，同時Hadoop開發團隊正在開發類似BigTable的開源數據管理模塊。 分布式編程與計算 為了使用戶能更輕松的享受雲計算帶來的服務，讓用戶能利用該編程模型編寫簡單的程序來實現特定的目的，雲計算上的編程模型必須十分簡單。必須保證後台復雜的並行執行和任務調度向用戶和編程人員透明。當前各IT廠商提出的雲計劃的編程工具均基於Map-Rece的編程模型。 虛擬資源的管理與調度 雲計算區別於單機虛擬化技術的重要特徵是通過整合物理資源形成資源池，並通過資源管理層（管理中間件）實現對資源池中虛擬資源的調度。雲計算的資源管理需要負責資源管理、任務管理、用戶管理和安全管理等工作，實現節點故障的屏蔽，資源狀況監視，用戶任務調度，用戶身份管理等多重功能。 雲計算的業務介面 為了方便用戶業務由傳統IT系統向雲計算環境的遷移，雲計算應對用戶提供統一的業務介面。業務介面的統一不僅方便用戶業務向雲端的遷移，也會使用戶業務在雲與雲之間的遷移更加容易。在雲計算時代，SOA架構和以Web Service為特徵的業務模式仍是業務發展的主要路線。 雲計算相關的安全技術 雲計算模式帶來一系列的安全問題，包括用戶隱私的保護、用戶數據的備份、雲計算基礎設施的防護等，這些問題都需要更強的技術手段，乃至法律手段去解決。

❼ 簡述這三種分布式系統中計算和數據的協作機制的有什麼共同點和不同點

主流的3種分布式存儲文件系統存儲架構分兩種，一種是傳統存儲陣列架構，另一種就是分布式存儲架構。
一、當前市場上，比較主流的3種分布式存儲文件系統，分別有AFS、GFS、Lustre。它們基本都有一個共通點——全局名字空間、緩存一致性、安全性、可用性和可擴展性。
二、3種分布式存儲文件系統的各自特點 1.AFS 由卡內基美隆大學最初設計開發的AFS，目前已經相當成熟，用於研究和部分大型網路中。AFS是AndrewFileSystem的簡稱，它的主要組建包括Cells、AFSclients、基本存儲單元Volumes、AFSservers和Volumereplication。 擁有良好可擴展性的AFS，能夠為客戶端帶來性能的提升和可用性的提高。AFS將文件系統的可擴展性放在了設計和實踐的首要位置，因此AFS擁有很好的擴展性，能夠輕松支持數百個節點，甚至數千個節點的分布式環境。它實現的是模塊化的，所以並不要求在每台伺服器上運行所有伺服器進程。 但值得一提的是，AFS的缺點在於管理員界面友好性不足，需要更多的專業知識來支持。
2.GFS 被稱為文件系統的GFS（GoogleFileSystem），是用以實現非結構化數據的主要技術和文件系統。它的性能、可擴展性、可靠性和可用性都受到了肯定。它主要運行在大量運行Linux系統的普通機器上，能大大降低它的硬體成本。 文件的大小，一直是文件系統要考慮的問題。對於任何一種文件系統，成千上萬的幾KB的系統很容易壓死內存。所以，對於大型的文件，管理要高效，對於小型的文件，也需要支持，但是並沒有進行優化。在GFS中，chunkserver的大小被固定為64MB，這樣的塊規模比一般的文件系統的塊規模要大得多，可以減少元數據metadata的開銷，減少Master的交互。但是，太大的塊規模也會產生內部碎片，或者同一個chunk中存在多個小文件可能會產生訪問熱點。 3.QKFile qkf是qkfile項目的燃料，qkfile項目是一個全球性的公共分布式文件系統，可以給網盤、雲存儲、短視頻、圖片、cdn等領域提供可靠的文件存儲分發服務。

❽ GFS是什麼意思

Google文件系統
GFS是一個可擴展的分布式文件系統，用於大型的、分布式的、對大量數據進行訪問的應用。它運行於廉價的普通硬體上，但可以提供容錯功能。它可以給大量的用戶提供總體性能較高的服務。
1、設計概覽
（1）設計想定
GFS與過去的分布式文件系統有很多相同的目標，但GFS的設計受到了當前及預期的應用方面的工作量及技術環境的驅動，這反映了它與早期的文件系統明顯不同的設想。這就需要對傳統的選擇進行重新檢驗並進行完全不同的設計觀點的探索。
GFS與以往的文件系統的不同的觀點如下：
1、 部件錯誤不再被當作異常，而是將其作為常見的情況加以處理。因為文件系統由成百上千個用於存儲的機器構成，而這些機器是由廉價的普通部件組成並被大量的客 戶機訪問。部件的數量和質量使得一些機器隨時都有可能無法工作並且有一部分還可能無法恢復。所以實時地監控、錯誤檢測、容錯、自動恢復對系統來說必不可 少。
2、按照傳統的標准，文件都非常大。長度達幾個GB的文件是很平常的。每個文件通常包含很多應用對象。當經常要處理快速增長的、包含數以 萬計的對象、長度達TB的數據集時，我們很難管理成千上萬的KB規模的文件塊，即使底層文件系統提供支持。因此，設計中操作的參數、塊的大小必須要重新考 慮。對大型的文件的管理一定要能做到高效，對小型的文件也必須支持，但不必優化。
3、大部分文件的更新是通過添加新數據完成的，而不是改變已 存在的數據。在一個文件中隨機的操作在實踐中幾乎不存在。一旦寫完，文件就只可讀，很多數據都有這些特性。一些數據可能組成一個大倉庫以供數據分析程序掃 描。有些是運行中的程序連續產生的數據流。有些是檔案性質的數據，有些是在某個機器上產生、在另外一個機器上處理的中間數據。由於這些對大型文件的訪問方 式，添加操作成為性能優化和原子性保證的焦點。而在客戶機中緩存數據塊則失去了吸引力。
4、工作量主要由兩種讀操作構成：對大量數據的流方式 的讀操作和對少量數據的隨機方式的讀操作。在前一種讀操作中，可能要讀幾百KB，通常達 1MB和更多。來自同一個客戶的連續操作通常會讀文件的一個連續的區域。隨機的讀操作通常在一個隨機的偏移處讀幾個KB。性能敏感的應用程序通常將對少量 數據的讀操作進行分類並進行批處理以使得讀操作穩定地向前推進，而不要讓它來來回回的讀。
5、工作量還包含許多對大量數據進行的、連續的、向文件添加數據的寫操作。所寫的數據的規模和讀相似。一旦寫完，文件很少改動。在隨機位置對少量數據的寫操作也支持，但不必非常高效。
6、系統必須高效地實現定義完好的大量客戶同時向同一個文件的添加操作的語義。
（2）系統介面
GFS提供了一個相似地文件系統界面，雖然它沒有向POSIX那樣實現標準的API。文件在目錄中按層次組織起來並由路徑名標識。
（3）體系結構：
一 個GFS集群由一個master和大量的chunkserver構成，並被許多客戶（Client）訪問。如圖1所示。Master和 chunkserver通常是運行用戶層服務進程的Linux機器。只要資源和可靠性允許，chunkserver和client可以運行在同一個機器 上。
文件被分成固定大小的塊。每個塊由一個不變的、全局唯一的64位的chunk－handle標識，chunk－handle是在塊創建時 由 master分配的。ChunkServer將塊當作Linux文件存儲在本地磁碟並可以讀和寫由chunk－handle和位區間指定的數據。出於可靠 性考慮，每一個塊被復制到多個chunkserver上。默認情況下，保存3個副本，但這可以由用戶指定。
Master維護文件系統所以的元 數據（metadata），包括名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置。它也控制系統范圍的活動，如塊租約（lease）管理，孤兒 塊的垃圾收集，chunkserver間的塊遷移。Master定期通過HeartBeat消息與每一個 chunkserver通信，給chunkserver傳遞指令並收集它的狀態。
與每個應用相聯的GFS客戶代碼實現了文件系統的API並與master和chunkserver通信以代表應用程序讀和寫數據。客戶與master的交換只限於對元數據（metadata）的操作，所有數據方面的通信都直接和chunkserver聯系。
客 戶和chunkserver都不緩存文件數據。因為用戶緩存的益處微乎其微，這是由於數據太多或工作集太大而無法緩存。不緩存數據簡化了客戶程序和整個系 統，因為不必考慮緩存的一致性問題。但用戶緩存元數據（metadata）。Chunkserver也不必緩存文件，因為塊時作為本地文件存儲的。
（4）單master。
只 有一個master也極大的簡化了設計並使得master可以根據全局情況作出先進的塊放置和復制決定。但是我們必須要將master對讀和寫的參與減至 最少，這樣它才不會成為系統的瓶頸。Client從來不會從master讀和寫文件數據。Client只是詢問master它應該和哪個 chunkserver聯系。Client在一段限定的時間內將這些信息緩存，在後續的操作中Client直接和chunkserver交互。
以圖1解釋一下一個簡單的讀操作的交互。
1、client使用固定的塊大小將應用程序指定的文件名和位元組偏移轉換成文件的一個塊索引（chunk index）。
2、給master發送一個包含文件名和塊索引的請求。
3、master回應對應的chunk handle和副本的位置（多個副本）。
4、client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個位元組區間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以後對同一個塊的讀操作不再需要client和master間的交互。
通常Client可以在一個請求中詢問多個chunk的地址，而master也可以很快回應這些請求。
（5）塊規模：
塊規模是設計中的一個關鍵參數。我們選擇的是64MB，這比一般的文件系統的塊規模要大的多。每個塊的副本作為一個普通的Linux文件存儲，在需要的時候可以擴展。
塊規模較大的好處有：
1、減少client和master之間的交互。因為讀寫同一個塊只是要在開始時向master請求塊位置信息。對於讀寫大型文件這種減少尤為重要。即使對於訪問少量數據的隨機讀操作也可以很方便的為一個規模達幾個TB的工作集緩緩存塊位置信息。
2、Client在一個給定的塊上很可能執行多個操作，和一個chunkserver保持較長時間的TCP連接可以減少網路負載。
3、這減少了master上保存的元數據（metadata）的規模，從而使得可以將metadata放在內存中。這又會帶來一些別的好處。
不利的一面：
一個小文件可能只包含一個塊，如果很多Client訪問改文件的話，存儲這些塊的chunkserver將成為訪問的熱點。但在實際應用中，應用程序通常順序地讀包含多個塊的文件，所以這不是一個主要問題。
（6）元數據（metadata）：
master 存儲了三中類型的metadata：文件的名字空間和塊的名字空間，從文件到塊的映射，塊的副本的位置。所有的metadata都放在內存中。前兩種類型 的metadata通過向操作日誌登記修改而保持不變，操作日誌存儲在master的本地磁碟並在幾個遠程機器上留有副本。使用日誌使得我們可以很簡單 地、可靠地更新master的狀態，即使在master崩潰的情況下也不會有不一致的問題。相反，mater在每次啟動以及當有 chuankserver加入的時候詢問每個chunkserver的所擁有的塊的情況。
A、內存數據結構：
因為metadata存儲在內存中，所以master的操作很快。進一步，master可以輕易而且高效地定期在後台掃描它的整個狀態。這種定期地掃描被用於實現塊垃圾收集、chunkserver出現故障時的副本復制、為平衡負載和磁碟空間而進行的塊遷移。
這 種方法的一個潛在的問題就是塊的數量也即整個系統的容量是否受限與master的內存。實際上，這並不是一個嚴重的問題。Master為每個 64MB的塊維護的metadata不足64個位元組。除了最後一塊，文件所有的塊都是滿的。類似的，每個文件的名字空間數據也不足64個位元組，因為文件名 是以一種事先確定的壓縮方式存儲的.如果要支持更大的文件系統，那麼增加一些內存的方法對於我們將元數據（metadata）保存在內存種所獲得的簡單 性、可靠性、高性能和靈活性來說，這只是一個很小的代價。
B、塊位置：
master並不為chunkserver所擁有的塊的副本的保存一個不變的記錄。它在啟動時通過簡單的查詢來獲得這些信息。Master可以保持這些信息的更新，因為它控制所有塊的放置並通過HeartBeat消息來監控chunkserver的狀態。
這樣做的好處：因為chunkserver可能加入或離開集群、改變路徑名、崩潰、重啟等，一個集群重有成百個server，這些事件經常發生，這種方法就排除了master與chunkserver之間的同步問題。
另一個原因是：只有chunkserver才能確定它自己到底有哪些塊，由於錯誤，chunkserver中的一些塊可能會很自然的消失，這樣在master中就沒有必要為此保存一個不變的記錄。
C、操作日誌：
操作日誌包含了對metadata所作的修改的歷史記錄。它作為邏輯時間線定義了並發操作的執行順序。文件、塊以及它們的版本號都由它們被創建時的邏輯時間而唯一地、永久地被標識。
操作日誌是如此的重要，我們必須要將它可靠地保存起來，並且只有在metadata的改變固定下來之後才將變化呈現給用戶。所以我們將操作日誌復制到數個遠程的機器上，並且只有在將相應的日誌記錄寫到本地和遠程的磁碟上之後才回答用戶的請求。
Master可以用操作日誌來恢復它的文件系統的狀態。為了將啟動時間減至最小，日誌就必須要比較小。每當日誌的長度增長到超過一定的規模後，master就要檢查它的狀態，它可以從本地磁碟裝入最近的檢查點來恢復狀態。
創 建一個檢查點比較費時，master的內部狀態是以一種在創建一個檢查點時並不耽誤即將到來的修改操作的方式來組織的。Master切換到一個新的日子文 件並在一個單獨的線程中創建檢查點。這個新的檢查點記錄了切換前所有的修改。在一個有數十萬文件的集群中用一分鍾左右就能完成。創建完後，將它寫入本地和 遠程的磁碟。
（7）數據完整性
名字空間的修改必須是原子性的，它們只能有master處理：名字空間鎖保證了操作的原子性和正確性，而master的操作日誌在全局范圍內定義了這些操作的順序。
文 件區間的狀態在修改之後依賴於修改的類型，不論操作成功還是失敗，也不論是不是並發操作。如果不論從哪個副本上讀，所有的客戶都看到同樣的數據，那麼文件 的這個區域就是一致的。如果文件的區域是一致的並且用戶可以看到修改操作所寫的數據，那麼它就是已定義的。如果修改是在沒有並發寫操作的影響下完成的，那 么受影響的區域是已定義的，所有的client都能看到寫的內容。成功的並發寫操作是未定義但卻是一致的。失敗的修改將使區間處於不一致的狀態。
Write操作在應用程序指定的偏移處寫入數據，而record append操作使得數據（記錄）即使在有並發修改操作的情況下也至少原子性的被加到GFS指定的偏移處，偏移地址被返回給用戶。
在一系列成功的修改操作後，最後的修改操作保證文件區域是已定義的。GFS通過對所有的副本執行同樣順序的修改操作並且使用塊版本號檢測過時的副本（由於chunkserver退出而導致丟失修改）來做到這一點。
因為用戶緩存了會位置信息，所以在更新緩存之前有可能從一個過時的副本中讀取數據。但這有緩存的截止時間和文件的重新打開而受到限制。
在修改操作成功後，部件故障仍可以是數據受到破壞。GFS通過master和chunkserver間定期的handshake，藉助校驗和來檢測對數據的破壞。一旦檢測到，就從一個有效的副本盡快重新存儲。只有在GFS檢測前，所有的副本都失效，這個塊才會丟失。
2、系統交互
（1）租約（lease）和修改順序：
（2）數據流
我們的目標是充分利用每個機器的網路帶寬，避免網路瓶頸和延遲
為了有效的利用網路，我們將數據流和控制流分離。數據是以流水線的方式在選定的chunkerserver鏈上線性的傳遞的。每個機器的整個對外帶寬都被用作傳遞數據。為避免瓶頸，每個機器在收到數據後，將它收到數據盡快傳遞給離它最近的機器。
（3）原子性的record Append：
GFS 提供了一個原子性的添加操作：record append。在傳統的寫操作中，client指定被寫數據的偏移位置，向同一個區間的並發的寫操作是不連續的：區間有可能包含來自多個client的數 據碎片。在record append中， client只是指定數據。GFS在其選定的偏移出將數據至少原子性的加入文件一次，並將偏移返回給client。
在分布式的應用中，不同機 器上的許多client可能會同時向一個文件執行添加操作，添加操作被頻繁使用。如果用傳統的write操作，可能需要額外的、復雜的、開銷較大的同步， 例如通過分布式鎖管理。在我們的工作量中，這些文件通常以多個生產者單個消費者隊列的方式或包含從多個不同 client的綜合結果。
Record append和前面講的write操作的控制流差不多，只是在primary上多了一些邏輯判斷。首先，client將數據發送到文件最後一塊的所有副本 上。然後向primary發送請求。Primary檢查添加操作是否會導致該塊超過最大的規模（64M）。如果這樣，它將該塊擴充到最大規模，並告訴其它 副本做同樣的事，同時通知client該操作需要在下一個塊上重新嘗試。如果記錄滿足最大規模的要求，primary就會將數據添加到它的副本上，並告訴 其它的副本在在同樣的偏移處寫數據，最後primary向client報告寫操作成功。如果在任何一個副本上record append操作失敗，client將重新嘗試該操作。這時候，同一個塊的副本可能包含不同的數據，因為有的可能復制了全部的數據，有的可能只復制了部 分。GFS不能保證所有的副本每個位元組都是一樣的。它只保證每個數據作為一個原子單元被寫過至少一次。這個是這樣得出的：操作要是成功，數據必須在所有的 副本上的同樣的偏移處被寫過。進一步，從這以後，所有的副本至少和記錄一樣長，所以後續的記錄將被指定到更高的偏移處或者一個不同的塊上，即使另一個副本 成了primary。根據一致性保證，成功的record append操作的區間是已定義的。而受到干擾的區間是不一致的。
（4）快照（snapshot）
快照操作幾乎在瞬間構造一個文件和目錄樹的副本，同時將正在進行的其他修改操作對它的影響減至最小。
我 們使用-on-write技術來實現snapshot。當master受到一個snapshot請求時，它首先將要snapshot的文件上塊上 的lease。這使得任何一個向這些塊寫數據的操作都必須和master交互以找到擁有lease的副本。這就給master一個創建這個塊的副本的機 會。
副本被撤銷或終止後，master在磁碟上登記執行的操作，然後復制源文件或目錄樹的metadata以對它的內存狀態實施登記的操作。這個新創建的snapshot文件和源文件（其metadata）指向相同的塊（chunk）。
Snapshot 之後，客戶第一次向chunk c寫的時候，它發一個請求給master以找到擁有lease的副本。Master注意到chunk c的引用記數比1大，它延遲對用戶的響應，選擇一個chunk handle C』,然後要求每一有chunk c的副本的chunkserver創建一個塊C』。每個chunkserver在本地創建chunk C』避免了網路開銷。從這以後和對別的塊的操作沒有什麼區別。
3、MASTER操作
MASTER執行所有名字空間的操作，除此之外，他還在系統范圍管理數據塊的復制：決定數據塊的放置方案，產生新數據塊並將其備份，和其他系統范圍的操作協同來確保數據備份的完整性，在所有的數據塊伺服器之間平衡負載並收回沒有使用的存儲空間。
3.1 名字空間管理和加鎖
與傳統文件系統不同的是，GFS沒有與每個目錄相關的能列出其所有文件的數據結構，它也不支持別名（unix中的硬連接或符號連接），不管是對文件或是目錄。GFS的名字空間邏輯上是從文件元數據到路徑名映射的一個查用表。
MASTER 在執行某個操作前都要獲得一系列鎖，例如，它要對/d1/d2…/dn/leaf執行操作，則它必須獲得/d1，/d1/d2，…， /d1/d2/…/dn的讀鎖，/d1/d2…/dn/leaf的讀鎖或寫鎖（其中leaf可以使文件也可以是目錄）。MASTER操作的並行性和數據的 一致性就是通過這些鎖來實現的。
3.2 備份存儲放置策略
一個GFS集群文件系統可能是多層分布的。一般情況下是成千上萬個文件塊 伺服器分布於不同的機架上，而這些文件塊伺服器又被分布於不同機架上的客戶來訪問。因此，不同機架上的兩台機器之間的通信可能通過一個或多個交換機。數據 塊冗餘配置策略要達到連個目的：最大的數據可靠性和可用性，最大的網路帶寬利用率。因此，如果僅僅把數據的拷貝置於不同的機器上很難滿足這兩個要求，必須 在不同的機架上進行數據備份。這樣即使整個機架被毀或是掉線，也能確保數據的正常使用。這也使數據傳輸，尤其是讀數據，可以充分利用帶寬，訪問到多個機 架，而寫操作，則不得不涉及到更多的機架。
3.3 產生、重復制、重平衡數據塊
當MASTER產生新的數據塊時，如何放置新數據 塊，要考慮如下幾個因素：（1）盡量放置在磁碟利用率低的數據塊伺服器上，這樣，慢慢地各伺服器的磁碟利用率就會達到平衡。（2）盡量控制在一個伺服器上 的「新創建」的次數。（3）由於上一小節討論的原因，我們需要把數據塊放置於不同的機架上。
MASTER在可用的數據塊備份低於用戶設定的數 目時需要進行重復制。這種情況源於多種原因：伺服器不可用，數據被破壞，磁碟被破壞，或者備份數目被修改。每個被需要重復制的數據塊的優先順序根據以下幾項 確定：第一是現在的數目距目標的距離，對於能阻塞用戶程序的數據塊，我們也提高它的優先順序。最後， MASTER按照產生數據塊的原則復制數據塊，並把它們放到不同的機架內的伺服器上。
MASTER周期性的平衡各伺服器上的負載：它檢查 chunk分布和負載平衡，通過這種方式來填充一個新的伺服器而不是把其他的內容統統放置到它上面帶來大量的寫數據。數據塊放置的原則與上面討論的相同， 此外，MASTER還決定那些數據塊要被移除，原則上他會清除那些空閑空間低於平均值的那些伺服器。
3.4 垃圾收集
在一個文件被刪除之後，GFS並不立即收回磁碟空間，而是等到垃圾收集程序在文件和數據塊級的的檢查中收回。
當 一個文件被應用程序刪除之後，MASTER會立即記錄下這些變化，但文件所佔用的資源卻不會被立即收回，而是重新給文件命了一個隱藏的名字，並附上了刪除 的時間戳。在MASTER定期檢查名字空間時，它刪除超過三天（可以設定）的隱藏的文件。在此之前，可以以一個新的名字來讀文件，還可以以前的名字恢復。 當隱藏的文件在名字空間中被刪除以後，它在內存中的元數據即被擦除，這就有效地切斷了他和所有數據塊的聯系。
在一個相似的定期的名字空間檢查中，MASTER確認孤兒數據塊（不屬於任何文件）並擦除他的元數據，在和MASTER的心跳信息交換中，每個伺服器報告他所擁有的數據塊，MASTER返回元數據不在內存的數據塊，伺服器即可以刪除這些數據塊。
3.5 過時數據的探測
在數據更新時如果伺服器停機了，那麼他所保存的數據備份就會過時。對每個數據塊，MASTER設置了一個版本號來區別更新過的數據塊和過時的數據塊。
當MASTER 授權一個新的lease時，他會增加數據塊的版本號並會通知更新數據備份。MASTER和備份都會記錄下當前的版本號，如果一個備份當時不可用，那麼他的 版本號不可能提高，當ChunkServer重新啟動並向MASTER報告他的數據塊集時，MASTER就會發現過時的數據。
MASTER在 定期的垃圾收集程序中清除過時的備份，在此以前，處於效率考慮，在各客戶及英大使，他會認為根本不存在過時的數據。作為另一個安全措施， MASTER在給客戶及關於數據塊的應答或是另外一個讀取數據的伺服器數據是都會帶上版本信息，在操作前客戶機和伺服器會驗證版本信息以確保得到的是最新 的數據。
4、容錯和診斷
4.1 高可靠性
4.1.1 快速恢復
不管如何終止服務，MASTER和數據塊伺服器都會在幾秒鍾內恢復狀態和運行。實際上，我們不對正常終止和不正常終止進行區分，伺服器進程都會被切斷而終止。客戶機和其他的伺服器會經歷一個小小的中斷，然後它們的特定請求超時，重新連接重啟的伺服器，重新請求。
4.1.2 數據塊備份
如上文所討論的，每個數據塊都會被備份到放到不同機架上的不同伺服器上。對不同的名字空間，用戶可以設置不同的備份級別。在數據塊伺服器掉線或是數據被破壞時，MASTER會按照需要來復制數據塊。
4.1.3 MASTER備份
為 確保可靠性，MASTER的狀態、操作記錄和檢查點都在多台機器上進行了備份。一個操作只有在數據塊伺服器硬碟上刷新並被記錄在MASTER和其備份的上 之後才算是成功的。如果MASTER或是硬碟失敗，系統監視器會發現並通過改變域名啟動它的一個備份機，而客戶機則僅僅是使用規范的名稱來訪問，並不會發 現MASTER的改變。
4.2 數據完整性
每個數據塊伺服器都利用校驗和來檢驗存儲數據的完整性。原因：每個伺服器隨時都有發生崩潰的可能性，並且在兩個伺服器間比較數據塊也是不現實的，同時，在兩台伺服器間拷貝數據並不能保證數據的一致性。
每個Chunk按64kB的大小分成塊，每個塊有32位的校驗和，校驗和和日誌存儲在一起，和用戶數據分開。
在 讀數據時，伺服器首先檢查與被讀內容相關部分的校驗和，因此，伺服器不會傳播錯誤的數據。如果所檢查的內容和校驗和不符，伺服器就會給數據請求者返回一個 錯誤的信息，並把這個情況報告給MASTER。客戶機就會讀其他的伺服器來獲取數據，而MASTER則會從其他的拷貝來復制數據，等到一個新的拷貝完成 時，MASTER就會通知報告錯誤的伺服器刪除出錯的數據塊。
附加寫數據時的校驗和計算優化了，因為這是主要的寫操作。我們只是更新增加部分的校驗和，即使末尾部分的校驗和數據已被損壞而我們沒有檢查出來，新的校驗和與數據會不相符，這種沖突在下次使用時將會被檢查出來。
相反，如果是覆蓋現有數據的寫，在寫以前，我們必須檢查第一和最後一個數據塊，然後才能執行寫操作，最後計算和記錄校驗和。如果我們在覆蓋以前不先檢查首位數據塊，計算出的校驗和則會因為沒被覆蓋的數據而產生錯誤。
在空閑時間，伺服器會檢查不活躍的數據塊的校驗和，這樣可以檢查出不經常讀的數據的錯誤。一旦錯誤被檢查出來，伺服器會拷貝一個正確的數據塊來代替錯誤的。
4.3 診斷工具
廣 泛而細致的診斷日誌以微小的代價換取了在問題隔離、診斷、性能分析方面起到了重大的作用。GFS伺服器用日誌來記錄顯著的事件（例如伺服器停機和啟動）和 遠程的應答。遠程日誌記錄機器之間的請求和應答，通過收集不同機器上的日誌記錄，並對它們進行分析恢復，我們可以完整地重現活動的場景，並用此來進行錯誤 分析。
6 測量
6.1 測試環境
一台主控機，兩台主控機備份，16台數據塊伺服器，16台客戶機。
每台機器：2塊PIII1.4G處理器，2G內存，2塊80G5400rpm的硬碟，1塊100Mbps全雙工網卡
19台伺服器連接到一個HP2524交換機上，16台客戶機倆接到領外一台交換機上，兩台交換機通過1G的鏈路相連。
[編輯本段]Government Flying Service
政府飛行服務隊
政府飛行服務隊是香港特別行政區政府保安局轄下的紀律部門，專責執行搜索及拯救行動。另外，亦會拍攝照片供製作地圖、測量填海工程、以及支援位處偏遠山區和離島的各項政府服務。現時雇有225名公務員。現任政府飛行服務隊總監為畢耀明，是服務隊的最高指揮官，直接向保安局局長負責。
政府飛行服務隊的總部位於香港國際機場，佔地84,000平方米，包括一幢辦公和工場大樓、一座單層的飛機庫、多座附屬建築物、停機坪及其他相關設施等。
理想
香港政府飛行服務隊理想是成為「被舉世公認為優秀的空中搜救及飛行支援部隊」。
歷史
於1993年4月1日成立，前身為皇家香港輔助空軍。
架構
香港政府飛行服務隊共分為五個主要小組：行政組、行動組、訓練及標准組、品質保證組及工程組。
服務范圍
它們的主要任務為香港政府各部門提供每星期七天及每日二十四小時的直升機和定翼機緊急支援服務。其中包括：
搜索及拯救
空中救護服務
警務支援服務
滅火服務
空中測量服務
一般政府支援服務
警務支援服務

❾ 雲平台存儲架構最穩定的是GFS

GFS的整體架構
三部分組成：
1:唯一的主控伺服器{Master}
負責管理工作
2: 眾多的Chunk伺服器
負責數據存儲並響應GFS客戶端的讀、寫請求
3:GFS客戶端
負載跟數據存儲節點交互，屏蔽訪問的細節，讓具體應用操作跟本地操作一樣

GFS：海量非結構化信息的存儲平台，並提供了數據的冗餘備份、上萬台伺服器的自動負載均衡以及失效伺服器的檢測等機制
GFS的設計原則：
一：以普通PC作為存儲節點、控制節點，數據支持冗餘備份、自動檢測機器是否有效提供服務，故障機器的自動恢復。
二：存儲文件為大文件100M到10G之間，必須對大文件的讀寫操作做出優化
三：系統存在大量的追加寫，寫入的內容很少變化，很少出現隨機寫，支持高效的追加寫

四：數據的讀取多數為順序讀，少量的隨機讀

❿ gfs和hdfs有什麼區別

HDFS 最早是根據 GFS（Google File System）的論文概念模型來設計實現的，但是也有一些區別。