(一)分布式文件系統概述
數據量越來越多，在一個操作系統管轄的范圍存不下了，那么就分配到更多的操作系統管理的磁盤中，但是不方便管理和維護，因此迫切需要一種系統來管理多臺機器上的文件，這就是分布式文件管理系統 。是一種允許文件通過網絡在多臺主機上分享的文件系統，可讓多機器上的多用戶分享文件和存儲空間。通透性。讓實際上是通過網絡來訪問文件的動作，由程序與用戶看來，就像是訪問本地的磁盤一般。 容錯。即使系統中有某些節點脫機，整體來說系統仍然可以持續運作而不會有數據損失。分布式文件管理系統很多，hdfs只是其中一種，不合適小文件。
HttpFS訪問方式
1：httpfs是一個hadoop hdfs的一個http接口，通過WebHDFS REST API 可以對hdfs進行讀寫等訪問
2：與WebHDFS的區別是不需要客戶端可以訪問hadoop集群的每一個節點，通過httpfs可以訪問放置在防火墻后面的hadoop集群
3：httpfs是一個Web應用,部署在內嵌的tomcat中
NFS:
The NFS Gateway supports NFSv3 and allows HDFS to be mounted as part of the client’s local file system. Currently NFS Gateway supports and enables the following usage patterns: Users can browse the HDFS file system through their local file system? on NFSv3 client compatible operating systems.? Users can download files from the the HDFS file system on to their? local file system.? Users can upload files from their local file system directly to the? HDFS file system.? Users can stream data directly to HDFS through the mount point. File? append is supported but random write is not supported.? The NFS gateway? machine needs the same thing to run an HDFS client like Hadoop JAR files, HADOOP_CONF directory. The NFS gateway can be on the same host as DataNode, NameNode, or any HDFS client.
HDFSNFSGateway能夠把HDFS掛載到客戶機上作為本地文件系統來管理，支持NFSv3。當前版本的NFSGateway有如下可用特性。用戶在支持NFSv3的操作系統上可以通過本地文件系統瀏覽HDFS。使用NFSGateway用戶能夠直接下載和上傳HDFS文件到本地文件系統中。用戶可以通過掛載點直接傳輸數據流至HDFS，但只能增量添加不能隨機寫數據。
NameNode之間共享數據（NFS 、QuorumJournalNode（用得多））:
兩個NameNode為了數據同步，會通過一組稱作JournalNodes的獨立進程進行相互通信。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。standby狀態的NameNode有能力讀取JNs中的變更信息，并且一直監控editlog的變化，把變化應用于自己的命名空間。standby可以確保在集群出錯時，命名空間狀態已經完全同步了。
hadoop2.2.0（HA）中HDFS的高可靠指的是可以同時啟動2個NameNode。其中一個處于工作狀態，另一個處于隨時待命狀態。這樣，當一個NameNode所在的服務器宕機時，可以在數據不丟失的情況下，手工或者自動切換到另一個NameNode提供服務。這些NameNode之間通過共享數據，保證數據的狀態一致。多個NameNode之間共享數據，可以通過Nnetwork File System或者QuorumJournalNode。前者是通過linux共享的文件系統，屬于操作系統的配置；后者是hadoop自身的東西，屬于軟件的配置。使用QuorumJournalNode的配置方式，方式是手工切換。
集群啟動時，可以同時啟動2個NameNode。這些NameNode只有一個是active的，另一個屬于standby狀態。active狀態意味著提供服務，standby狀態意味著處于休眠狀態，只進行數據同步，時刻準備著提供服務，如圖2所示。
在一個典型的HA集群中，每個NameNode是一臺獨立的服務器。在任一時刻，只有一個NameNode處于active狀態，另一個處于standby狀態。其中，active狀態的NameNode負責所有的客戶端操作，standby狀態的NameNode處于從屬地位，維護著數據狀態，隨時準備切換。
兩個NameNode為了數據同步，會通過一組稱作JournalNodes的獨立進程進行相互通信。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。standby狀態的NameNode有能力讀取JNs中的變更信息，并且一直監控edit
log的變化，把變化應用于自己的命名空間。standby可以確保在集群出錯時，命名空間狀態已經完全同步了，如圖3所示。
為了確保快速切換，standby狀態的NameNode有必要知道集群中所有數據塊的位置。為了做到這點，所有的datanodes必須配置兩個NameNode的地址，發送數據塊位置信息和心跳給他們兩個。
對于HA集群而言，確保同一時刻只有一個NameNode處于active狀態是至關重要的。否則，兩個NameNode的數據狀態就會產生分歧，可能丟失數據，或者產生錯誤的結果。為了保證這點，JNs必須確保同一時刻只有一個NameNode可以向自己寫數據。
為了部署HA集群，應該準備以下事情：
* NameNode服務器：運行NameNode的服務器應該有相同的硬件配置。
*JournalNode服務器：運行的JournalNode進程非常輕量，可以部署在其他的服務器上。注意：必須允許至少3個節點。當然可以運行更多，但是必須是奇數個，如3、5、7、9個等等。當運行N個節點時，系統可以容忍至少(N-1)/2(N至少為3)個節點失敗而不影響正常運行。
在典型的HA架構中，有兩個獨立的機器作為Namenode，任何時刻，只有一個Namenode處于Active狀態，另一個處于standby狀態(passive,備份)；Active
Namenode用于接收Client端請求，Standy節點作為slave保持集群的狀態數據以備快速failover。
為了支持快速failover，Standbynode持有集群中blocks的最新位置是非常必要的。為了達到這一目的，Datanodes上需要同時配置這兩個Namenode的地址，同時和它們都建立心跳鏈接，并把block位置發送給它們。
任何時刻，只有一個Active Namenode是非常重要的，否則將會導致集群操作的混亂，那么兩個Namenode將會分別有兩種不同的數據狀態，可能會導致數據丟失，或者狀態異常，這種情況通常稱為“split-brain”(腦裂，三節點通訊阻斷，即集群中不同的Datanodes卻看到了兩個Active Namenodes)。對于JNS(JournalNodes)而言，任何時候只允許一個Namenode作為writer；在failover期間，原來的StandbyNode將會接管Active的所有職能，并負責向JNS寫入日志記錄，這就阻止了其他Namenode基于處于Active狀態的問題。
自動Failover
上述介紹了如何配置手動failover，在這種模式下，系統不會自動觸發failover，即不會將Standby提升為Active，即使Active已經失效。接下來介紹如何實現自動failover。
一)、組件
Automatic Failover中，增加了2個新的組件：zookeeper集群，ZKFailoverController進程(簡稱為ZKFC)。
Zookeeper是一個高可用的調度服務，可以保存一系列調度數據，當這些數據變更(notify)時可以通知Client，以及監控(montitor)Clients失效，自動failover的實現將依賴于Zookeeper的幾個特性：
1、Failure delection：失效檢測，每個Namenode將會和zookeeper建立一個持久session，如果Namenode失效，那么次session將會過期失效，此后Zookeeper將會通知另一個Namenode，然后觸發Failover。
2、Active Namenode election：zookeeper提供了簡單的機制來實現AcitveNode選舉，如果當前Active失效，Standby將會獲取一個特定的排他鎖(lock)，那么獲取(持有)鎖的Node接下來將會成為Active。
ZKFailoverControllor(ZKFC)是一個zookeeper客戶端，它主要用來監測和管理Namenodes的狀態，每個Namenode機器上都會運行一個ZKFC程序，它的職責為：1、Health monitoring：ZKFC間歇性的使用health-check指令ping本地的Namenode，Namenode也會及時的反饋自己的health status。如果Namenode失效，或者unhealthy，或者無響應，那么ZKFS將會標記其為“unhealthy”。
2、Zookeeper session manangement：當本地Nanenode運行良好時，ZKFC將會持有一個zookeeper session，如果本地Namenode為Active，它同時也持有一個“排他鎖”(znode)；這個lock在zookeeper中為“ephemeral” znode(臨時節點)，如果session過期，那么次lock所對應的znode也將被刪除。
3、Zookeeper-based election：如果本地Namenode運行良好，并且ZKFS沒有發現其他的的Namenode持有lock(比如Active失效后，釋放了lock)，它將嘗試獲取鎖，如果獲取成功，即“贏得了選舉”，那么此后將會把本地Namenode標記為Active，然后觸發Failover：首先，調用fencing method，然后提升本地Namenode 為Active。
在Automatic Failover中，需要把一個重要的配置項添加到hdfs-site.xml中。dfs.ha.automatic-failover.enabled設置為true，
1、ZKFC和Namenodes守護進程的啟動順序是否重要？
No，對于指定的Namenode，你可以在其之前或者之后啟動ZKFC均可以，ZKFC只是調度Namenode的存活狀態，如果不啟動ZKFC，此Namenode將無法參與自動failover過程。
2、是否需要額外的monitoring？
你需要在Namenode機器上，添加額外的monitor用來監控ZKFC是否運行。在某些情況下，zookeeper集群的故障可能導致ZKFC意外中斷，你需要適時的重啟ZKFC。此外，還需要監控Zookeeper集群的運行狀況，如果Zookeeper集群失效，那么HA集群將無法failover。
3、如果Zookeeper失效，將會怎么樣？
如果zookeeper集群故障，那么Automatic Failover將不會觸發，即使Namenode失效，這也意味著ZKFC無法正常運行。不過，如果Namenodes正常(即使有一個失效)，那么HDFS系統將不會受到影響。因為HDFSClient并沒有基于zookeeper做任何事情，當zookeeper集群仍需要盡快的恢復以避免當前Active失效而造成的“split-brain”等問題。
4、是否可以在Namenodes之間指定優先級？
NO，這是不能支持的。首先啟動的Namenode將作為Active，我們只能認為控制Namenode啟動的順序來做到“優先級”。
5、在Automatic Failover中，手動Failover怎么做？
和普通的Failover一樣，我們總是可以通過"hdfshaadmin -DFSHAAdmin -failover"來實現手動Failover。
在Automatic Failover中，需要把一個重要的配置項添加到hdfs-site.xml中。
zkfailover：
1.基本原理
zk的基本特性：(1) 可靠存儲小量數據且提供強一致性 (2) ephemeral node, 在創建它的客戶端關閉后，可以自動刪除 (3) 對于node狀態的變化，可以提供異步的通知(watcher)
zk在zkfc中可以提供的功能：(1) Failure detector: 及時發現出故障的NN，并通知zkfc (2) Active node locator: 幫助客戶端定位哪個是Active的NN (3) Mutual exclusion of active state: 保證某一時刻只有一個Active的NN
2. 模塊
(1) ZKFailoverController(DFSZKFailoverController): 驅動整個ZKFC的運轉，通過向HealthMonitor和ActiveStandbyElector注冊回調函數的方式，subscribe HealthMonitor和ActiveStandbyElector的事件，并做相應的處理
(2) HealthMonitor: 定期check NN的健康狀況，在NN健康狀況發生變化時，通過回調函數把變化通知給ZKFailoverController
(3) ActiveStandbyElector: 管理NN在zookeeper上的狀態，zookeeper上對應node的結點發生變化時，通過回調函數把變化通知給ZKFailoverController
(4) FailoverController: 提供做gracefulfailover的相關功能(dfs admin可以通過命令行工具手工發起failover)
3. 系統架構
如上圖所示，通常情況下Namenode和ZKFC同布署在同一臺物理機器上,HealthMonitor, FailoverController,ActiveStandbyElector在同一個JVM進程中(即ZKFC),Namenode是一個單獨的JVM進程。如上圖所示，ZKFC在整個系統中有幾個重要的作用：
(1) Monitor and try to take active lock: 向zookeeper搶鎖，搶鎖成功的zkfc，指導對應的NN成為active的NN; watch鎖對應的znode，當前active NN的狀態發生變化導致失鎖時，及時搶鎖，努力成為active NN
(2) Monitor NN liveness and health: 定期檢查對應NN的狀態, 當NN狀態發生變化時，及時通過ZKFC做相應的處理
(3) Fences other NN when needed: 當前NN要成為active NN時，需要fence其它的NN，不能同時有多個active NN
4. 線程模型
ZKFC的線程模型總體上來講比較簡單的，它主要包括三類線程，一是主線程；一是HealthMonitor線程; 一是zookeeper客戶端的線程。它們的主要工作方式是：
(1) 主線程在啟動所有的服務后就開始循環等待
(2) HealthMonitor是一個單獨的線程，它定期向NN發包，檢查NN的健康狀況
(3) 當NN的狀態發生變化時，HealthMonitor線程會回調ZKFailoverController注冊進來的回調函數，通知ZKFailoverController NN的狀態發生了變化
(4) ZKFailoverController收到通知后，會調用ActiveStandbyElector的API，來管理在zookeeper上的結點的狀態
(5) ActiveStandbyElector會調用zookeeper客戶端API監控zookeeper上結點的狀態，發生變化時，回調ZKFailoverController的回調函數，通知ZKFailoverController，做出相應的變化
5. 類關系圖
ZKFC的主類是org.apache.hadoop.hdfs.tools.DFSZKFailoverController。
formatZK 創建特定目錄，作為后續寫節點狀態的父路徑。如果該目錄已經存在，清理原有目錄為空目錄。
HealthMonitor 在一個獨立線程中，通過RPC方式，周期性的調用HAServiceProtocol接口的monitorHealth方法，獲取NN的狀態。并把狀態報告給ActiveStandbyElector。
ActiveStandbyElector ActiveStandbyElector負責判斷哪個NN可以成為Active。它通過ZK，看哪個能夠成功的創建一個特定的ephemeral?lock?file?(znode)，哪個就是Active，其它的成為Standby。在一個節點被通知變成Active后，它必須確保自己能夠提供一致性的服務（數據一致性），否則它需要主動退出選舉。
如果一個Active因HealthMonitor監控到狀態異常，這里會作出判斷，先通過Fenceing功能關閉它（確保關閉或者不能提供服務），然后在ZK上刪除它對應ZNode。發送上述事件后，在另外一臺機器上的ZKFC中的ActiveStandbyElector會收到事件，并重新進行選舉（嘗試創建特定ZNode），它將獲得成功并更改NN中狀態，從而實現Active節點的變更。
HDFS體系結構
Client客戶端+Namenode+DataNode
是整個文件系統的管理節點。它維護著1.整個文件系統的文件目錄樹，2.文件/目錄的元信息和每個文件對應的數據塊列表。3.接收用戶的操作請求。文件包括：（hdfs-site.xml的dfs.namenode.name.dir屬性）
fsimage:元數據鏡像文件。存儲某一時段NameNode內存元數據信息。edits:操作日志文件。fstime:保存最近一次checkpoint的時間 以上這些文件是保存在linux的文件系統中。
NameNode維護著2張表：1.文件系統的目錄結構，以及元數據信息；2.文件與數據塊（block）列表的對應關系
元數據存放在fsimage中，在運行的時候加載到內存中的(讀寫比較快)。操作日志寫到edits中。（類似于LSM樹中的log）
（剛開始的寫文件會寫入到內存中和edits中，edits會記錄文件系統的每一步操作，當達到一定的容量會將其內容寫入fsimage中）
dfs.namenode.name.dir -- /lvm/dfs/nn
/lvm/dfs/nn/current
保存有fsimage和edit文件? 確定namenode在本地文件系統上的DFS名稱節點應存儲名稱表（fsimage）。
fsimage的內容會被存儲到以逗號分隔的列表的目錄中，然后在所有的目錄中復制名稱表目錄，用于冗余。
查看NameNode內容
啟動服務器bin/hdfs oiv -i 某個fsimage文件 --offline image viewer? -i(input) -o(output)
查看內容bin/hdfs dfs -ls -R webhdfs://127.0.0.1:5978/
導出結果bin/hdfs oiv -p XML -i tmp/dfs/name/current/fsimage_0000000000000000055 -o fsimage.xml
查看edtis內容bin/hdfs oev -i tmp/dfs/name/current/edits_0000000000000000057-0000000000000000186 -o edits.xml
2.Datanode
提供真實文件數據的存儲服務。
文件塊（block）：最基本的存儲單位。對于文件內容而言，一個文件的長度大小是size，那么從文件的０偏移開始，按照固定的大小，順序對文件進行劃分并編號，劃分好的每一個塊稱一個Block。HDFS默認Block大小是128MB(dfs.blocksize,dfs.block.size)，以一個256MB文件，共有256/128=2個Block. 不同于普通文件系統的是，HDFS中，如果一個文件小于一個數據塊的大小，并不占用整個數據塊存儲空間。(這樣設置可以減輕namenode壓力，因為namonode維護者文件與數據塊列表的對應大小) Replication。多復本。默認是三個。（hdfs-site.xml的dfs.replication屬性）.注意區別：一個文件可以產生多個塊，多個文件是不可能成為一個塊信息的，處于減輕namenode的壓力，最好的方式就是一個文件一個塊.
文件塊存放路徑查看與具體信息解釋
（a）查找datanode存放數據的位置，配置信息在hdfs-site.xml中
cd /lvm/data8/dfs/dn/current/BP-625280320-192.168.191.130-1483628038952/current/finalized/subdir0/subdir0
DataNode:使用block形式存儲。在hadoop2中，默認的大小是128MB。使用副本形式保存數據的安全，默認的數量是3個。
