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