hdfs的学习和高可用部署
HDFS的數據遷移解決方案：
1，理解HDFS數據遷移方案及工具DistCp（分布式拷貝工具）的使用：
數據遷移的場景：
冷熱集群數據同步，分類存儲
集群數據整體搬遷（業務增長，需要將數據整體遷移到新的集群）
數據的準實時同步（數據準實時同步的目的在于數據的雙備份可用，比如某天A集群突然宣告不允許再使用了,此時可以將線上使用集群直接切向B的同步集群
, 因為B集群實時同步A集群數據,擁有完全一 致的真實數據和元數據信息，所以對于業務方使用而言是不會受到任何影響的。）
數據遷移要素考量：
●Bandwidth-帶寬：帶寬用多了會影響線上的業務，帶寬少了有會導致同步數據過慢的問題
●Performance-性能：采用簡單的單機程序還是多線程的性能更佳的分布式程序？
●Data-Increment-增量同步：可以針對變化的增量數據進行同步。可以配合HDFS快照等技術實現增量數據的同步
●Syncable-數據遷移的同步性：數據遷移的過程中需要保證周期內數據是一定能夠同步完的. 不能差距太大.比如A集群7天內的增量數據，我只要花半天就可以完全同步
到B集群，然后我又可以等到下周再次進行同步.最可怕的事情在于A集群的7天內的數據，我的程序花了7天還同步不完，然后下一一個周期又
來，這樣就無法做到準實時的一致性.其實7天還是一個比較大的時間， 最好是能達到按天同步.
HDFS分布式拷貝工具：DistCp
DistCp是hadoop中的一種工具，在hadoop-tools工程下，作為獨立子工程存在。
定位用于數據遷移，定期在集群之間和集群內部備份數據。
在備份過程中，每次運行DistCp都稱為一個備份周期。盡管性能相對較慢，但是普及成都已經是越來越高。
DistCp底層使用mapreduce在集群之間活并行在同意集群內復制文件，執行復制的mapreduce只有mapper階段。
●DistCp的優勢：
帶寬限流：可以通過參數來bandwidth來為程序進行帶寬限流。
增量數據同步：可以使用三個參數實現增量的同步：
updata：只拷貝不存在的文件或者目錄
Append：追加寫目標路徑下已存在的文件
diff： 通過快照的diff對比信息來同步源端路徑于目標路徑
updata解決了新增文件、目錄的同步。append解決了已存在文件的增量更新同步。diff解決了刪除或者重命名類型文件的同步
高性能性：分布式的特性
DistCp底層使用mapreduce執行數據同步，mapreduce本身一類分布式的程序。
●DistCp命令：
distcp options [source_path …] <target_path>
-append :拷貝文件時支持對現有文件進行追加寫操作
-async ：異步執行distcp拷貝任務
-bandwidth :對每個map任務的帶寬限速
-delete :刪除相對于源端，目標端多出的文件
-diff ：通過快照diff信息進行數據的同步
-overwrite:已覆蓋的方式進行拷貝，如果目標端已經就存在，則直接覆蓋
-p :拷貝數據時，擴展屬性信息的保留，包括權限信息，塊大小信息等
-skipcrcccheck :拷貝文件時是否跳過cheacksum的校驗
-updata：拷貝數據時，只拷貝相對于源端，目標端不存在的文件數據
其中 source_path、target_path需要【帶上地址前綴以區分不通的集群】
例：hadoop distcp hdfs://nn1:8020/foo/a hdfs://nn2:8020/bar/foo
表示：從nn1集群拷貝/foo/a路徑下的數據到nn2集群的/bar/foo路徑下
HDFS namenode的安全模式：
●安全模式：只讀，不可寫和刪除（是namenode的維護狀態）
●在NameNode啟動過程中 ,首先會從fsimage和edits日志文件加載文件系統狀態。然后,等待DataNodes匯 報可用的block信息。在此期間, NameNode保持在安全模式。
隨著DataNode的block匯 報持續進行,當整個系統達到安全標準時, HDFS自動離開安全模式。在NameNode Web主頁上會顯顯安全模式是打開還是關閉。
HDFS的安全模式原理，進入離開的條件：
自動進入安全模式的時間：hdfs集群啟動時，當namenode啟動成功后，此時集群會自動進入安全模式
安全模式自動離開：條件由（hdfs-aite.xml、hdfs-default.xml）默認配置文件管理。
dfs.replication #hdfs block的副本數據,默認3
dfs.replication.max #最大塊副本數。默認512
dfs.namenode.replication.min #最小塊副本數， 默認1
dfs.namenode.safemode.threshold-pct #已匯報可用數據塊數量占整體塊數量的百分比閾值。默認0.999f。
#小于或等于0,則表示退出安全模式之前,不要等待特定百分比的塊。大于1的值將使安全模式永久生效。
dfs.namenode. safemode min.datanodes #指在退出安全模式之前必須存活的DataNode數量,默認0
dfs.namenode.safemode. extension #達到閾值條件后持續擴展的時間。倒計時結束如果依然滿足閾值條件自動離開安全模式。默認30000毫秒
安全模式手動進入離開：
手動獲取安全模式狀態：
hdfs dfsadmin -safemode get
手動進入安全模式：
hdfs dfsadmin -safemode enter
手動離開安全模式：
hdfs dfsadmin -safemode leave
HDFS高階優化方案：
1，短路本地讀取
●客戶端讀取數據的順序：dfsclient->datanodes->data directores->datanodes->dfsclient ##讀取數據要經過datanode中轉，效率不高
理解：在HDFS中,不管是Local Reads ( DFSClient和Datanode在同一個節點)還是Remote Reads ( DFSClient和Datanode不在同一個節點) , 底層處理方式都是一樣的,都是先由Datanode讀取數據,然后再通過RPC (基于TCP )把數據傳
給DFSClient。這樣處理是比較簡單的,但是性能會受到一些影響，因為需要Datanode在中間做一次中轉。尤其Local Reads的時候,既然DFSClient和數據是在一個機器 上面,那么很自然的想法,就是讓DFSC1 ient繞開
Datanode自己去讀取數據。所謂的“短路”讀取繞過了DataNode，從而允許客戶端直接讀取文件。顯然，這僅在客戶端與數據位于同一機器的情況下才可行。短路讀取為許多應用提供了顯著的性能提升。
實現：
在HDFS–347中,提出了一種新的解決方案 ,讓短路本地讀取數據更加安全。
在Linux中,有個技術叫做Unix Domain Socket。 Unix Domain Socket 是一種進程間的通訊方式，它使得同一個機器上的兩個進程能以Socket的方式通訊。
它帶來的另一大好處是,利用它兩個進程除了可以傳遞普通數據外,還可以在進程間傳遞文件描述符。
●客戶端獲取數據的描述信息：dfsclient->datanodes->data directores->datanodes->（open）dfsclient ##客戶端獲取到數據描述符
●客戶端讀取數據的順序：dfsclient->(read)file descriptor ###根據描述信息在本地找到數據
●配置：
需要安裝：libhadoop.so
檢查是否安裝： hadoop checknative
配置hdfs-site.xml:
添加：dfs.client.read.shortcircuit–“true”
####打開短路讀取本地功能的開關
dfs.domain.socket.path–"/var/lib/hadoop-hdfs/dn_socket"
###datanode和dfsclient之間溝通的socket的本地路徑，需要先創建好"/var/lib/hadoop-hdfs"。dn_socket是文件，是系統之間生成的。
確認配置生效：配置修改完成啟動集群，打開hadoop datanade的日志，查找“more /usr/local/hadoop/logs/hadoop-hadoop-datanode-master.log |grep domain”
[hadoop@master ~]$ more /usr/local/hadoop/logs/hadoop-hadoop-datanode-master.log |grep domain
2021-06-04 18:56:09,254 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Listening on UNIX domain socket: /var/lib/hadoop-hdfs/dn_socket
方式2：讀取一個文件到本地
hdfs dfs -get /tmp/hadoop-yarn/staging/hadoop/.staging/job_1617001022520_0001 .
查看日志：[hadoop@master ~]$ more /usr/local/hadoop/logs/hadoop-hadoop-datanode-master.log |grep SHORT_CIRCUIT
2021-06-04 19:06:48,450 INFO org.apache.hadoop.hdfs.server.datanode.DataNode.clienttrace: cliID: DFSClient_NONMAPREDUCE_-754604018_1, src: 127.0.0.1, dest: 127.0.0.1, op: REQUEST_SHORT_CIRCUIT_SHM, shmId: 6586ba296ba797be3e7d0e6b93370ffa, srvID: b9d1d200-1bfb-499b-9b5b-07677a4dfbc9, success: true
2021-06-04 19:06:48,484 INFO org.apache.hadoop.hdfs.server.datanode.DataNode.clienttrace: src: 127.0.0.1, dest: 127.0.0.1, op: REQUEST_SHORT_CIRCUIT_FDS, blockid: 1073741826, srvID: b9d1d200-1bfb-499b-9b5b-07677a4dfbc9, success: true
2021-06-04 19:06:48,553 INFO org.apache.hadoop.hdfs.server.datanode.DataNode.clienttrace: src: 127.0.0.1, dest: 127.0.0.1, op: REQUEST_SHORT_CIRCUIT_FDS, blockid: 1073741827, srvID: b9d1d200-1bfb-499b-9b5b-07677a4dfbc9, success: true
2021-06-04 19:06:48,559 INFO org.apache.hadoop.hdfs.server.datanode.DataNode.clienttrace: src: 127.0.0.1, dest: 127.0.0.1, op: REQUEST_SHORT_CIRCUIT_FDS, blockid: 1073741828, srvID: b9d1d200-1bfb-499b-9b5b-07677a4dfbc9, success: true
2，負載均衡
●HDFS數據可能并不總 是在DataNode之間均勻分布。一個常見的原因是向現有群集中添加了新的DataNode。HDFS提供
了一個Balancer程序,分析block放置信息并且在整個DataNode節點之間平衡數據，直到被視為平衡為止。
●所謂的平衡指的是每個DataNode的利用率(本機已用空間與本機總容量之比)與集群的利用率( HDFS整體已用空間
與HDFS集群總容量的比)之間相差不超過給定閾值百分比。
●平衡器無法在單個DatalNode.上的各個卷(磁盤)之間進行平衡。
●命令行：
hdfs balancer --help ##查看參數
-threshold 10 ##集群平衡的條件，datanode間磁盤使用率相差閾值，區間：0-100
-policy datanode ##平衡策略，默認為datanode，若datanode平衡，則集群已平衡
-ecxclude -f /tmp/ip1.txt ##默認為空，指定該部分IP不參與balance,-f 指定輸入為文件
-iclude -f /tmp/ip2.txt ##默認為空，只允許這部分ip參與balance，-f指定輸入為文件
-idleiteation 5 ###迭代5
●如何運行
設置平衡數據傳輸帶寬
hdfs dfsadmin -setBalancerBandwidth new_bandwidth
其中new_bandwidth是每個datanode在平衡操作期間可以使用的最大網絡帶寬，以每秒字節數為單位。
例如：hdfs dfsadmin -setBalancerBandwidth 104857600(100M)
3，磁盤均衡器(HDFS Disk Balancer)[hadoop3.0引入的]:
作用：均衡單個datanode中各個磁盤的存儲數據平衡
單機中的存儲策略：
●循環策略:它將新block均勻分布在可用磁盤上。默認此策略。
●可用空間策略:此策略將數據寫入具有更多可用空間(按百分比)的磁盤。
功能：
1，數據傳播報告：
為了衡量集群中哪些計算機遭受數據分布不均的影響,磁盤平衡器定義了Volume Data Density metric (卷/磁盤數據密度度量標準)
和Node Data Density metric (節點數據密度度量標準)。
●卷/磁盤數據密度度量標準：比較同臺機器上不通卷之間的數據分布情況
●節點數據密度度量標準：比較的是不同機器之間的
2，磁盤平衡
hdfs disk balancer開啟：
默認情況下，hadoop集群上已經啟用了disk balancer功能。通過hdfs-site.xml中調整
dfs.disk.balancer.enabled參數值，選擇在hadoop中是否啟用磁盤均衡器
相關命令：
1，plan計劃：
命令：hdfs diskbalancer -plan
-out ###控制計劃文件的輸出位置
-bandwidth ##設置用于disk balancer的最大帶寬。默認是10M/s
-thresholdPercentage #定義磁盤開始參與數據重新分配或平衡操作的值默認的thresholdPercentage值為10%，
#這意味著僅當磁盤包含的數據比理想存儲值多10%或更少時,磁盤才用于平衡操作.
-maxerror ###它允許用戶在中止移動步驟之前為兩個磁盤之間的移動操作指定要忽略的錯誤數.
-V #詳細模式，指定此選項將強制plan命令在stdout上顯示計劃的摘要.
-fs #此選項指定要使用的NameNode如果未指定則Disk Balancer將使用配置中的默認NameNode.
2，Execute執行：
hdfs diskbalancer -execute
execute命令針對為其生成計劃的datanode執行計劃
Query查詢：
hdfs diskbalancer -query
query命令從運行計劃的datanode獲取hdfs磁盤均衡器的當前狀態
3，Canel取消：
hdfs diskbalancer -canel
hdfs diskbalancer -canel planID node
canel 命令取消運行計劃
Report匯報：
hdfs diskbalancer -fs hdfs://nn_host:8020 -report ###這里的端口是8020/9000
4，糾刪碼存儲技術（EC）：
●糾刪碼技術 ( Erasure coding )簡稱EC ,是一種編碼容錯技術。最早用于通信行業,數據傳輸中的數據恢復。它通
過對數據進行分塊,然后計算出校驗數據,使得各個部分的數據產生關聯性。當-部分數據塊丟失時,可以通過剩
余的數據塊和校驗塊計算出丟失的數據塊。
EC集群的部署方式：
●Stepl :集群和硬件配置
編碼和解碼二工作會消耗HDFS客戶端和DataNode.上的額外CPU。
糾刪碼文件也分布在整個機架上,以實現機架容錯。這意味著在讀寫條帶化文件時,大多數操作都是在機架上進行的。因此,網絡帶寬也非常重要。
對于機架容錯,擁有足夠數量的機架也很重要,每個機架所容納的塊數不超過EC奇偶校驗塊的數。機架數量= ( 數據塊+奇偶校驗塊) /奇偶校驗塊后取整。
比如對于EC策略RS (6,3) , 這意味著最少3個機架(由(6 + 3)/ 3 = 3計算) , 理想情況下為9個或更多,以處理計劃內和計劃
外的停機。對于機架數少于奇偶校驗單元數的群集, HDPS無法維持機架容錯能力,但仍將嘗試在多個節點之間分布條帶化文件以保留節
點級容錯能力。因此,建議設置具有類似數量的DataNode的機架。
●Step2 :糾刪碼策略設置
糾刪碼策略由參數dfs. namenode. ec. system. default. policy指定,默認是RS- 6-3-1024k
（RS表示編碼器算法Reed- Solomon, 6、3中表示數據塊和奇偶校驗塊的數量, 1024k表示條帶化單元的大小。）,其他策略默認是禁用的。
可以通過hdfs ec [-enablePolicy -policy ]命令啟用策略集。
●Step3 :啟用英特爾ISA-L (智能存儲加速庫)
默認RS編解碼器的HDFS本機實現利用Intel ISA-L庫來改善編碼和解碼計算。要啟用和使用Intel ISA-L ,需要執行三個步驟。
1）建立ISA-L庫;
2）使用ISA-.支持構建Hadoop ;
3）使用Dbundle.isal將isal.lib目錄的內容復制到最終的tar文件中。使用tar文件部署Hadoop。確保ISA-L在HDFS客戶端和DataNode上可用。
●Step4 : hdfs ec
[-setPolicy -path [-policy ] [-replicatel]
#在指定路徑的目錄上設置擦除編碼策略。
#ath: HDFS中的目錄。這是必填參數。設置策略僅影響新創建的文件， 而不影響現有文件。
#policy:用于此目錄下文件的擦除編碼策略。默認RS-6-3-1024k策略。
#replicate在目錄上應用默認的REPLICATION方案，強制目錄采用3x復制方案。replicate 和-policy 是可選參數。不能同時指定它們。
[-getPolicy -path < path >]
#獲取指定路徑下文件或目錄的擦除編碼策略的詳細信息。
[-unsetPolicy -path < path >]
#取消設置先前對日錄上的setPolicy的調用所設置的擦除編碼策略。如果該日錄從祖先日錄繼承了擦除編碼策略，則unsetPolicy是no-op。在沒有顯式策略集的目錄上取消策略將不會返回錯誤。
[-listPolicies]
#列出在HDFS中注冊的所有(啟用，禁用和刪除)擦除編碼策略。只有啟用的策略才適合與setPolicy命令-起使用。
[-addPolicies -policyFile <文件>]
#添加用戶定義的擦除編碼策略列表。。
[-listCodecs]
#獲取系統中支持的擦除編碼編解碼器和編碼器的列表。
[-removePolicy -policy ]
#刪除用戶定義的擦除編碼策略。
[-enablePolicy -policy ]
#啟用擦除編碼策略。
[-disablePolicy -policy ]
#禁用擦除編碼策略。
HDFS動態節點管理：
動態擴容（節點上線）：
step1 :新機器基礎環境準備：
●主機名、ip
●hosts映射
●防火墻，時間同步
●ssh免密登錄
●jdk環境
step2 :hadoop配置：
●修改namenode節點workers配置文件，增加節點主機名，便于后續一鍵啟停
●從namenode節點復制hadoop安裝包到新節點。注意不包括hadoop.tmp.dir指定的數據存儲目錄
scp -r /usr/local/hadoop hadoop@slave3:/usr/local/
或者 cd /usr/local/ ；scp -r /usr/local/hadoop hadoop@slave3:$PWD
注：要事先在新機器中建好目錄（不是root用戶的話），要不然會報scp沒權限問題
●新機器上配置Hadoop環境變量
step3 :手動啟動datanode進程：
●hadoop-daemon.sh start datanode 或者 hdfs --daemon start datanode
報錯：ERROR: Cannot set priority of datanode process 4217
看日志：Too many failed volumes - current valid volumes: 0, volumes configured: 1, volumes failed: 1, volume failures tolerated: 0
原因：存放數據的路徑dfs屬性是root的，需要改為hadoop
解決：root操作：chown -R hadoop:hadoop hadoop
●yarn-daemon.sh start nodemanager 或者 yarn --daemon start nodemanager
step4 :datanode的負載均衡(主節點操作)：
新加的機器沒有數據，需要和舊的datanode做一個負載均衡：
設置負載均衡的數據傳輸帶寬：hdfs dfsadmin -setBalancerBandwidth 104857600
然后啟動balancer，等待集群自均衡完成即可：hdfs balancer -threshold 5
動態縮容（節點下線）：
step1 :添加退役節點：
在namenode機器hdfs-site.xml配置文件中需要提前配置dfs.hosts.exclude屬性，該屬性指向的文件就是所謂的黑名單列表，
會被namenode排除在集群外。如果文件內容為空，則意味著不禁止任何機器
這個配置具有前瞻性，建集群時提前加進去，否則需要重啟集群加載
dfs.hosts.exclude
/usr/local/hadoop/etc/hadoop/excludes
datanode黑名單
注意：如果副本數是3，服役的節點數小于等于3，是不能退役成功的，需要修改副本數后才可以成功退役
step1 :刷新集群
在namanode所在集群刷新節點：hdfs dfsadmin -refreshNodes
等待退役節點服務器狀態為decommissioned(所有塊已經復制完成)
例：[hadoop@master local]$ hdfs dfsadmin -refreshNodes
Refresh nodes successful
白名單：
●所謂的白名單指的是允許哪些機器加入到當前的HDFS集群中，是一種準入機制。
●名單由dfs.hosts參數指定,該參數位于hdfs-site.xml。默認值為空。
●dfs.hosts指向文件,文件包含允許連接到namenode的主機列表。必須指定文件的完整路徑名。如果該值為空則允許所有主機準入。
黑名單：
●所謂的黑名單指的是禁止哪些機器加入到當前的HDFS集群中。是一種禁入機制。
●黑名單由dfs. hosts. exclude參數指定,該參數位于hdfs -site. xml。默認值為空。
●dfs. hosts. exc lude指向文件。該文件包含不允許連接到名稱節點的主機列表。必須指定文件的完整路徑名。如果該值為空,則不禁上任何主機加入。
HDFS 的HA高可用機制：
HA系統設計核心問題( 1 )
●腦裂問題：
腦裂(split-brain)是指”大腦分裂”, 本是醫學名詞。
在HA集群中,腦裂指的是當聯系主備節點的"心跳線”斷開時(即兩個節點斷開聯系時) ,本來為一個整體、動作協調的HA系統,就分
裂成為兩個獨立的節點。由于相互失去了聯系,主備節點之間像裂腦人"-樣,使得整個集群處于混亂狀態。腦裂的嚴重后果:
1 )集群無主:都認為對方是狀態好的，自己是備份角色,后果是無服務;
2)集群多主:都認為對方是故障的，自己是主角色。相互爭搶共享資源,結果會導致系統混亂,數據損壞。此外對于客戶端訪問也是一頭霧水,找誰呢?
避免腦裂問題的核心是:保持任意時刻系統有且只有一個主角色提供服務。
HA系統設計核心問題( 2)
●數據狀態同步問題
備切換保證服務持續可用性的前提是主備節點之間的狀態數據是一致的 ,或者說準一致的。 如果說備用的節點和主節點之間的數據差距過大,即使完成了主備切換的動作,那也是沒有意義的。
數據同步常見做法是:通過日志重演操作記錄。主角色正常提供服務,發生的事務性操作通過日志記錄,備用角色讀取日志重演操作。
解決：
●在同一群集中運行兩個(從3.0. 0起.支持超過兩個)冗余NameNode. 形成主備架構。
●這樣可以在機器崩潰的情況 下快速故障轉移到新的NameNode ,或者出于計劃維護的目的由管理員發起的正常故障轉移。
Quorum Journal Manager介紹
●QJM全稱Quorum Journal Manager (仲裁日志管理器), Hadoop官方推薦的HDFS HA解決方案之一。
●使用zookeeper中ZKFC來實現主備切換 ;
●使用Journal Node(JN )集群實現edits_log的共享以達到數據同步的目的。
主備切換、腦裂問題解決–ZKFai loverController ( zkfc )
ZKFailoverController ( ZKFC )是一個ZooKeeper客戶端。主要職責:
1)監視和管理NameNode健康狀態
ZKFC通過命令監視的NameNode節點及機器的健康狀態。
2)維持和ZK集群聯系
如果本地NameNode運行狀況良好,粗ZKFC看到當前沒有其他節點持有鎖znode ,它將自己嘗試獲取該鎖。如果成功，則表明它"贏得了選舉”,
復責運行故障轉移以使其本地NameNode處于Active狀態。如果已經有其他節點持有鎖，zkfc選舉失敗,則會對該節點注冊監聽,等待下次繼續選舉。
主備切換、腦裂問題解決–Fencing( 隔離)機制
●故障轉移過程也就是俗稱的主備角色切換的過程 .切換過程中最怕的就是腦裂的發生。因此需要Fencing機制來避免,將先前的Active節點隔離,然后將Standby轉換為Active狀態。
●Hadoop公共庫中對外提供了兩種Fenching實現,分別是sshfence和shellfence (缺省實現)。
sshfence是指通過ssh登陸目標節點上,使用命令fuser將進程殺死(通過tcp端口號定位進程pid ,該方法比ips命令更準確);
shellfence是指執行一個用戶事先定義的shell命令(腳本)完成隔離。
主備數據狀態同步問題解決
●Journal Node ( JN)集群是輕量級分布式系統,主要用于高速讀寫數據、存儲數據。
●通常使用2N+1臺JournalNode存儲共享edits Log (編輯日志)。–底層類似于zk的分布式一致性算法。
●任何修改操作在 Active NN 上執行時, JournalNode進程同時也會記錄edits log到至少半數以上的JN中,這時
Standby NN監測到JN里面的同步log發生變化了會讀取JN里面的edits log ,然后重演操作記錄同步到自己的目錄鏡像樹里面。
HA hdfs配置：
strp1：基礎環境的準備：
1，修改linux主機名 /etc/hostanme
2,修改ip vim /etc/sysconfig/network-scripts/ifcfg-enp0s3
3,修改主機名和hosts的映射關系
4,關閉防火墻
5,ssh免密登陸
6,安裝JDK，配置環境變量 /etc/profile
7,集群時間同步
8,配置準備NN之間的互相免密登陸
step2: HA集群規劃
機器 運行角色
master namenode、zkfc、datannode、zookeeper、journal node(共享編輯日志，edits log)
slave1 namenode、zkfc、datannode、zookeeper、journal node
slave2 datannode、zookeeper、journal node
操作：
上傳安裝包
解壓縮：tar -zxvf /usr/local/hadoop-3.2.2.tar.gz -C /usr/local/
mv /usr/local/hadoop-3.2.2 /usr/local/hadoop
配置hadoop環境變量：
#hadoop
export HADOOP_HOME=/usr/local/hadoop
export PATH=HADOOPHOME/bin:HADOOP_HOME/bin:HADOOPH?OME/bin:HADOOP_HOME/sbin:$PATH
修改hadoop-env.sh
vim /usr/local/hadoop/etc/hadoop/hadoop-env.sh
export JAVA_HOME=/usr/local/jdk-16 ###找到修改
export HDFS_NAMENODE_USER=hadoop ##添加
export HDFS_JOURNALNODE_USER=hadoop ##添加
export HDFS_DATANODE_USER=hadoop ##添加
export HDFS_ZAKC_USER=hadoop ##添加
修改core-site.xml：
vim /usr/local/hadoop/etc/hadoop/core-site.xml
fs.defaultFS
hdfs://mycluster
hadoop.tmp.dir
/tmp/data/ha-hadoop
ha.zookeeper.quorum
master:2181,slave1:2181,slave2:2181
修改hdfs-site.xml:
dfs.nameservices
mycluster
HA集群初始化：
啟動zk集群：
su - hadoop
啟動方式1：每臺集群都去操作：zookeepers.sh
啟動方式2：自寫腳本 zoo_start.sh start
腳本為：
#!/bin/bash
case $1 in
格式化namonode：
在master上執行：
格式化：hdfs namenode -format ##格式化后會根據在core-site.xml中的hadoop.tmp.dir配置的目錄下生成hdfs初始化文件
啟動namenode進程：hdfs --daemon start namenode
錯誤：可能主動切換namenode不成功，出現nn1節點的namenode掛掉后nn2還是standby狀態，再啟動nn1時，nn1也是standby狀態的情況。這是由于centos7最小化安裝導致系統中沒有
fuser導致的，使用yum -y install psmisc安裝即可【兩個namenode都要操作】
舊集群的啟動：
1，hdfs --daemon start namenode
2，hdfs --daemon start zkfc
3，hdfs --daemon start journalnode
4，start-dfs.sh 或者hdfs --daemon start datanode
5，start-yarn.sh 或者yarn --daemon start resourcemanager
HDFS Federation聯邦機制：
當前的HDFS架構有兩個主要的層:
●命名空間( namespace )
由文件,塊和目錄組成的統一抽象的目錄樹結構。 由namenode根據用戶操作實時維護樹結構。
●塊存儲層 ( Block Storage )
包括兩個部分:
?塊管理: NameNode執行塊管理。 塊管理通過處理注冊和定期心跳來提供DataNode群集成員身份。它處理塊報告并支持與塊相關的操作,如創建,刪除,修改或獲取塊位置。它還維護塊的位置,副本位置。為未復制的塊管理塊復制,并在已復制的塊中刪除。
?存儲: DataNode通過在本地文件系統上存儲塊并提供讀(寫訪問權限來管理存儲空間。
當前HDFS體系架構–局限性：
當下的HDFS體系結構僅允許單個NameNode維護文件系統名稱空間。這種體系目前存在著一些弊端和局限性 :
●DataNode磁盤存儲空間不夠增加節點, NameNode內存不夠是否可以無限擴容。思考一下: 一種是DataNode橫向擴展機器增加節點, 一種是縱向擴展單機加內存。
●由于名稱空間和存儲層的緊密耦合, NameNode的替代實現很困難。這限制了其他服務直接使用塊存儲。NameNode成了唯一入口。
●文件系統的操作還限于NameNode一次處理的任務數。因此,群集的性能取決于NameNode吞吐量。
●同樣,由于使用單個名稱空間,因此使用群集的占用者組織之間沒有隔離。
聯邦Federation架構–簡介：
●Federation中文意思為聯邦,聯盟,是NameNode之間的Federat ion,也就是集群中會有多個NameNode。多個NameNode的情況意味著有多個namespace。注意,這區別于HA模式下的多NameNode , HA中它們是擁有著同一個namespace.
●Federation體系中多個namenode之間相互獨立且不需要互相協調,各自分工,管理自己的區域。每個DataNode要向集群中所有的namenode注冊,且周期性地向所有namenode發送心跳和塊報告,并執行來自所有namenode的命令。
聯邦Federation架構–好處：
●命名空間可伸縮性
使用Federation ,可以水平擴展名稱空間。這對大型群集或包含太多文件的群集有利,因為向群集添加了更多的NameNode。
●性能
由于文件系統操作不受單個NameNode吞吐量的限制,因此可以提高文件系統的性能。
●隔離
由于有多個名稱空間,它可以為使用群集的占用者組織提供隔離。
HDFS集群滾動升級：
介紹：
●在Hadoop v2中, HDFS支持NameNode高可用( HA)。使得不停機升級HDFS變得可行。請注意,僅從Hadoop-2. 4. 0起才支持滾動升級。
●因此為了在不停機的情況下升級HDFS群集,必須使用HA設置群集。
●在HA群集中,有兩個或多個NameNode ( NN) ,許多DataNode ( DN), 一些JournalNode ( JN )和一些ZooKeeperNode( ZKN)。
●JN相對穩定,在大多數情況下,升級HDFS時不需要升級。
●滾動升級過程中,僅針對NNs和DNs , JNS和ZKNs都沒有。升級JN和ZKN可能會導致群集停機。
不停機滾動升級–非聯邦HA集群：
假設有兩個名稱節點NN1和NN2 ,其中NN1和NN2分別處于Active和StandBy狀態。
●Stepl :滾動升級準備
#創建一個新的tsimage文件用于回滾：
hdfs dfsadmin -ollingUpgrade prepare
#不斷運行下面命令檢查回滾fsimage是否創建完畢。
#如果顯示Proceeding with Rolling Upgrade表示已經完成。
hdfs dfsadmin -ollingUpgrade query
●Step2:升級Active N和Standbys NN
#關閉NN2 :
hdfs --daemon stop namenode
#升級啟動NN2:
hdfs --daemon start namenode -rollingUpgrade started
#做一次failover切換, 使得NN2成為Active節點NN1變為Standby節點
#關閉NN1:
hdfs - daemon stop namenode
#升級啟動NN1 :
hdfs --daemon start namenode -rollingUpgrade started
有兩個名稱節點WI和M2 ,經過升級自前12:ire狀志。
●Step3: 升級DN
#選擇整體中的一小部分DataNode 節點進行升級(比如按照DataNode所在的不同機架來篩選)。
#關閉開級所選的DN其中IPC_PORT由參數dfs.datanode.ipc.address指定，默認9867.
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST:IPC_PORT> upgrade
#檢查下線DataNode是否已經停止服務如果還能得到節點信息，意味著此節點還未真正被關閉。
hdfs dfsadmin -getDatanodelnfo <DATANODE_HOST:IPC_PORT>
#啟動DN節點。
hdfs --daemon start datanode
#對選中的所有DN節點執行以上步驟。
#重復上述步驟，直到升級群集中的所有DN節點。
不停機滾動升級–聯邦HA集群:
●聯邦集群 ( federation )是擁有多namespace的集群。每個namespace對應一對主備NameNode節點。
●上述這套 集群就是俗稱的聯邦+HA集群。
聯邦集群的升級過程與非聯邦集群的升級過程比較相似，沒有什么本質區別,只是需要為不同的namespace多重復執行幾遍升級操作而已。
操作步驟：
#1、在每個namespace下執行升級級準備
hdfs dfsadmin -rollingUpgrade prepare
#2、升級每個namespace下的Active/Standby節點
#2.1、關閉NN2:
hdfs --daemon stop namenode
#2.2、升級啟動NN2:
hdfs --daemon start namenode -rollingUpgrade started
#2.3、做一次tailover切換,使得NN2成為Active節點NN1變為Standby節點。
#2.4、關閉NN1:
hdfs --daemon stop namenode
#2.5、升級啟動NN1:
hdfs --daemon start namenode -rollingUpgrade started
#3、升級每個DataNode節點
#3.1、關閉升級所選的DN其中IPC_PORT由參數dts.datanode.ipc.address指定，默認9867。
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST:IPC_PORT> upgrade
#3.2、檢查下線DataNode是否已經停止服務.如果還能得到節點信息，意味著此節點還未真正被關閉。
hdfs dfsadmin -getDatanodelnfo <DATANODE_HOST:IPC_PORT>
#3.3.啟動DN節點。
hdfs --daemon start datanode
#4、升級過程執行完畢在每個namespace下執行finalize確認命令.
hdfs dfsadmin -rollingUpgrade finalize
停機升級–非HA集群
●在升級的過程中， 勢必會存在服務短暫停止的時間,因為NameNode需要重啟，而這段時間并沒有備用節點可選.
●整體過程同非聯邦HA模式的4個步驟類似。 過步驟二的過程要略微修改 :
#Step1:滾動升級準備
hdfs dfsadmin -rollingUpgrade prepare
#Step2:升級NN和SNN
#1、關閉NN
hdfs --daemon stop namenode
#、升級啟動NN 1
hdfs --daemon start namenode -ollingUpgrade started
#3、停止SNN
hdfs --daemon stop secondarynamenode
#4、開級啟動SNN
hdfs -daemon start secondarynamenode -ollingUpgrade started
#Step3:升級DN
#3.1、關閉升級所選的DN其中IPC_PORT由參數dts.datanode.ipc.address指定，默認9867。
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST:IPC_PORT> upgrade
#3.2、檢查下線DataNode是否已經停止服務.如果還能得到節點信息，意味著此節點還未真正被關閉。
hdfs dfsadmin -getDatanodelnfo <DATANODE_HOST:IPC_PORT>
#3.3.啟動DN節點。
hdfs --daemon start datanode
#Step4:完成滾動升級
hdfs dfsadmin -rollingUpgrade finalize
HDFS集群降級和回滾:
降級( downgrade )和回滾( rollback)區別
●共同點:
都會將版本退回到升級前的版本;
在升級的finalize動作執行之后，將不允許再執行降級和回滾。
●不同點:
降級能支持ro1lling的方式，可以滾動降級,而回滾需要停止服務-段時間，
降級過程只會將軟件版本還原成升級前的,會保留用戶現有的數據狀態;
而回滾則會將用戶數據還原成升級前的狀態模式,現有的數據狀態不保存。
降級( downgrade )和回滾( rollback )
●友情提示: 升級慎重,降級、回滾更要慎重。
生產環境中,集群升級之前必須進行科學調研，評估升級后的版本跟現有業務的兼容性。
在測試環境下完整模擬升級流程,且針升級前集群狀態進行備份,避免意外發生導致集群中斷。
不要奢求升級失敗時,通過回滾、降級等操作挽救集群。
HA集群降級( downgrade ):
●Stepl :降級DataNode
#1.選中部分集合DataNode節點(可以按照機架進行區分)
#執行降級操作，其中IPC PORT由參數dfs. datanode.ipc.address指定，默認9867.
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST:IPC_PORT> upgrade
#執行命令檢查節點是否完全停止
hdfs dfsadmin -getDatanodelnfo <DATANODE_HOST:IPC_PORT>
并在選中集合內的其他DataNode節點上重復執行上述操作.
#2.在集群中所有的DataNode節點上重復執行1.的操作.
HA集群降級( downgrade )注意事項:
●降級與升級在HA模式下有一個共同點
在操作NameNode時,都是先從Standby節點開始操作，等Standby節點升/降結束,做一次切換使另外一個節點得以進行升/降操作.在全程中，始終保持一個Active節 點對外提供服務。
●降級過程NameNode與DataNode的操作和在升級時操作順序正好相反
新版本一般在協議、API是兼容老版本的,如果先降級NN,那么則會造成DN是新版，NN是舊版。
新DN中的許多協議將會在舊版NN中可能不兼容。
所以這里必須要先降級DN,然后再把服務端NN進行降級.看似簡單的一次順序顛倒,背后其實是有更深層的原因的.
●聯邦集群和非HA集群的降級操作與升級操作相對應,進行相應操作命令的替換即可。
集群回滾( rollback )操作
●回滾注意事項:
Rollback不支持滾動操作的方式，在操作期間，它需要集群對外停止提供服務.
Rollback操作不僅會將軟件版本退回到升級前的版本，還會將用戶數據退回到升級前的狀態
●回滾步驟
#1.停止所有的NameNode利DataNode節點
#2.在所有的節點機器上恢復升級前的軟件版本
#3.在NN1節點上執行-rollingUpgrade rollback命令來啟動NN1,將NN1作為Active節點
#4.在NN2上執行-bootstrapStandby命令并正常啟動NN2,將NN2作為Standby節點
#5.以-rollback參數啟動所有的DataNode.
總結
以上是生活随笔為你收集整理的hdfs的学习和高可用部署的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GBK与GB2312
- 下一篇： 水晶报表CrystalReports很强