CDH高可用性方案

Cloudera存儲級別的高可用HDFSHA使用基于Quorum的機制實現(xiàn)HDFS高可用HBaseHA通過備份/復(fù)制HBaseMaster實現(xiàn)Hbase高可用YARNRM高可用Work保存及恢復(fù)OozieHue

Impala

ImpalaProxyHAHiveMetastore創(chuàng)建多個HiveMetastore，并使用共享Database創(chuàng)建多個HiveServer2，實現(xiàn)負載均衡SearchisProductionMode=trueisIgnoringRecoverableExceptions=trueCloudera

Manager高可用及負載均衡Service級別高可用更多關(guān)于高可用的文檔CDH5高可用性

技術(shù)博客

YARNMaster/Worker架構(gòu)為什么要使用高可用？－－單點故障YARN高可用架構(gòu)設(shè)計通過多個RM實現(xiàn)active-standby的模式消除RM單點故障Oozie高可用-Active/Active對Oozie來說,主要通過“active-active”或者“hot-hot”實現(xiàn)高可用,即所有Oozie的服務(wù)器都在線且對外提供服務(wù).用戶可以根據(jù)需要建立任意多個Oozie服務(wù)器.Oozie服務(wù)可以實現(xiàn)水平擴展.Oozie高可用架構(gòu)-Database共享metadata，并存儲在高可用的數(shù)據(jù)庫中Oozie高可用架構(gòu)-客戶端訪問HAProxy采用Round-robin輪詢機制實現(xiàn)透明訪問和負載均衡Oozie高可用配置文件haproxy-oozie.cfg樣例global

daemon

nbproc1

maxconn100000

log/dev/loglocal6defaults

logglobal

modetcp

optiontcplog

optiontcpka

timeoutconnect3600000ms

timeoutclient3600000ms

timeoutserver3600000mslistenoozie

bind:11000

balanceroundrobin

serveroozie1:11000check

serveroozie2:11000check

serveroozie4:11000checkCM實現(xiàn)Oozie高可用圖形化配置Oozie高可用架構(gòu)-日志流寫入Hue高可用架構(gòu)在Hadoop集群中配置多個HueServices（5.4以前版本）安裝獨立的HueService服務(wù)在Hue

Service中配置多個HueServer（5.4及以后版本）安裝獨立的HueService實例HAProxy實現(xiàn)透明訪問和負載均衡HueHAHue高可用配置haproxy-hue.cfg舉例global

daemon

nbproc1

maxconn100000

loglocal6debugdefaults

optionhttp-server-close

modehttp

timeouthttp-request5s

timeoutconnect5s

timeoutserver10s

timeoutclient10slistenHue:80

logglobal

modehttp

statsenable

balancesource

serverhue1:8888cookieServerAcheckinter2000fall3

serverhue2:8888cookieServerBcheckinter2000fall3HAProxy開源的TCP/HTTP負載均衡工具

安裝和配置步驟yuminstallhaproxyconfigurehaproxy-cloudera.cfghaproxy-f/etc/haproxy/haproxy-cloudera.cfgglobal

daemon

nbproc1

maxconn100000

loglocal6debugdefaults

logglobal

modetcp

optiontcplog

optiontcpka

optiondontlognull

timeoutconnect5000

timeoutserver50000

timeoutclient50000frontendoozie

bind:11000

default_backendoozie_servers

modehttp

optionhttplogbackendoozie_servers

balanceroundrobin

modehttp

optionhttplog

serveroozie1:11000check

serveroozie2:11000check

serveroozie4:11000check

frontendhue

bind:80

default_backendhue_servers

modehttp

optionhttp-server-close

timeouthttp-request5s

backendhue_servers

balancesource

modehttp

optionhttp-server-close

serverhue1:8888cookieServerAcheckinter2000fall3

serverhue2:8888cookieServerBcheckinter2000fall3listenimpala

bind:10001

balanceleastconn serverimpala_1:21000

serverimpala_2:21000

serverimpala_3:21000

serverimpala_4:21000listenstats*:1936

modehttp

statsenable

statsuri/

statshide-versionHAProxyConfig樣例HAProxy–統(tǒng)計報告Hadoop備份及災(zāi)難恢復(fù)是什么讓Hadoop與眾不同?并不多除了TB到PB的數(shù)據(jù)廉價的硬件高度分布多種不同的服務(wù)Hadoop中哪些數(shù)據(jù)需要保護?配置:支持客戶應(yīng)用運行的所有配置信息數(shù)據(jù)集:數(shù)據(jù)&元數(shù)據(jù)(Hive)應(yīng)用程序:系統(tǒng)應(yīng)用程序(RM,NN,RegionServers等)及用戶的應(yīng)用程序我們應(yīng)聚焦哪些數(shù)據(jù)？數(shù)據(jù)集聚焦數(shù)據(jù)集并非因為其他不重要...而是因為現(xiàn)有的系統(tǒng)及流程能夠幫助管理應(yīng)用和配置，保證數(shù)據(jù)安全災(zāi)難的分類硬件類問題磁盤上的數(shù)據(jù)失效硬盤/服務(wù)器節(jié)點失效機柜失效用戶/應(yīng)用程序錯誤意外的數(shù)據(jù)刪除壞數(shù)據(jù)寫入數(shù)據(jù)中心問題數(shù)據(jù)中心永久損毀–如火災(zāi)、地震等數(shù)據(jù)中心臨時不可用–網(wǎng)絡(luò)故障、電力故障等(更常見)業(yè)務(wù)目標驅(qū)動技術(shù)方案災(zāi)難恢復(fù)時間目標RTOs(RecoveryTimeObjective)災(zāi)難恢復(fù)點目標RPOs(RecoveryPointObjective)必須針對不同的災(zāi)難故障類型采取不同的災(zāi)備和恢復(fù)計劃災(zāi)難模式發(fā)生概率損失成本磁盤失效高低節(jié)點失效高低機柜失效中中意外刪除中中中心失效低高HDFS的基本概念**FromHadoopdocumentation數(shù)據(jù)塊復(fù)制數(shù)據(jù)節(jié)點硬件故障之－數(shù)據(jù)塊損壞磁盤上的數(shù)據(jù)塊損壞文件的數(shù)據(jù)塊的元數(shù)據(jù)Checksum檢查如果checksums結(jié)果不匹配,namenode將丟棄該數(shù)據(jù)塊，并從其他可用的拷貝中復(fù)制Namenode還可以把元數(shù)據(jù)進行多份復(fù)制到不同的文件系統(tǒng)進行備份硬件故障之-磁盤/節(jié)點損壞Datacorruptionondisk磁盤／節(jié)點損壞同步復(fù)制的數(shù)據(jù)保障了數(shù)據(jù)安全-前兩份數(shù)據(jù)副本存放在相同Rack的不同服務(wù)器上，第三份副本保存在另一機柜的服務(wù)器中節(jié)點失效后，心跳線丟失，NameNode會自動檢測到節(jié)點失效Namenode高可用保證元數(shù)據(jù)安全如果HDFS上的數(shù)據(jù)塊的副本數(shù)少于復(fù)制因子（如3），Hadoop會自動復(fù)制數(shù)據(jù)塊，保障數(shù)據(jù)安全硬件故障之–Rack失效DatacorruptionondiskRack失效配置至少3份數(shù)據(jù)副本，保證數(shù)據(jù)安全。HDFS中配置Rack

信息第3份副本應(yīng)該存儲在不同的Rack的服務(wù)器上第3份副本非常重要－在整個Rack不可用的情況下，仍然能保證對外提供數(shù)據(jù)服務(wù)千萬別忘記metadata元數(shù)據(jù)Hivemetadata記錄了你的數(shù)據(jù)的描述Metadata數(shù)據(jù)備份非常簡單!通過SQL的方式來備份Metadata

基本的硬件故障已經(jīng)盡在掌握！同時…使用監(jiān)控工具來跟蹤節(jié)點的健康狀態(tài)定期檢查DataNode上的數(shù)據(jù)塊掃描報告()Hadoopfsck命令是非常實用的工具ClouderaManager提供您所需的全方位集群健康檢查同時，還應(yīng)關(guān)注另外一些細節(jié)需要注意…HDFS升級需要格外注意任何磁盤上的修改都是存在風(fēng)險的!Name

node的元數(shù)據(jù)需要單獨備份先在小規(guī)模的測試集群上測試升級過程，再在生產(chǎn)環(huán)境實施升級前，務(wù)必把所有重要的數(shù)據(jù)先備份到遠程的節(jié)點上，以防萬一!應(yīng)用或用戶錯誤首先，務(wù)必遵守最小權(quán)限原則權(quán)限許可范圍用戶應(yīng)該僅僅被賦予必須的數(shù)據(jù)權(quán)限配額管理命名配額:限制掛載的文件數(shù)量空間配額:限制掛載文件的大小數(shù)據(jù)意外刪除的防護Trashserver－回收站如果啟用，被刪除的數(shù)據(jù)會保留在回收站中通過設(shè)置erval參數(shù)來控制數(shù)塊在回收站中保留的時間需要注意:回收站保護僅對fsshell操作有效，采用程序的刪除不被保護.Trash是用戶級別的保護，每個用戶都有自己的回收站同時，別忘了元數(shù)據(jù)保護同樣的，通過SQL按照計劃有規(guī)律的備份是關(guān)鍵HDFSSnapshots（快照）什么是快照?Snapshots表現(xiàn)的是在某一個時間點上，系統(tǒng)的狀態(tài)采用的是copy-on-write實現(xiàn)機制因為HDFS中采用的是append-only機制，因此快照僅對數(shù)據(jù)刪除進行管理HDFSSnapshots（快照）實現(xiàn)細節(jié)–NameNode快照:非?？煲恢滦员ＷC恢復(fù)時，需要進行數(shù)據(jù)拷貝.snapshot目錄的訪問與每一個文件匹配

那么HDFSSnapshots能解決什么問題?處理用戶/應(yīng)用

級別的數(shù)據(jù)錯誤處理偶然性的意外數(shù)據(jù)刪除同時，還能用于測試/開發(fā)目的－快速部署基于生產(chǎn)數(shù)據(jù)的測試/開發(fā)環(huán)境!HBasesnapshots（快照）與HDFS的快照工作方式類似快速建立快照一致性恢復(fù)僅需一個copy命令

Snapshots（快照）管理存儲空間的考慮:集群存儲空間多少%可用于snapshotsSnapshots的數(shù)量空間問題的告警調(diào)度恢復(fù):基于時間的策略基于工作流的策略數(shù)據(jù)中心的DR數(shù)據(jù)中心A數(shù)據(jù)中心BHDFSHiveHBaseHDFSHiveHBase多通路vs拷貝多通路方式在數(shù)據(jù)接入階段，采用多路復(fù)制的方式，把數(shù)據(jù)發(fā)送到主數(shù)據(jù)中心及備份中心集群間的延時最小網(wǎng)絡(luò)帶寬要求高故障發(fā)生時，主備集群都需要進行恢復(fù)主備集群會發(fā)生數(shù)據(jù)不一致拷貝方式數(shù)據(jù)從主集群通過拷貝（批量/實時）的方式備份到備份集群集群間的數(shù)據(jù)保持一致數(shù)據(jù)接入只需處理一次恢復(fù)時會有更多時延需要更多的帶寬實現(xiàn)方法數(shù)據(jù)接入階段故障恢復(fù)階段如何選擇?使用場景來決定！但是通常情況，更傾向于使用數(shù)據(jù)拷貝的方式針對每種服務(wù)采用不同策略HDFS多通路:Flume、Sqoop支持多通路拷貝:使用DistCP工具進行數(shù)據(jù)拷貝HBase多通路:采用應(yīng)用程序級別多通路數(shù)據(jù)拷貝:HBase數(shù)據(jù)庫復(fù)制機制Hive多通路:NA數(shù)據(jù)拷貝:數(shù)據(jù)庫import/export**Databaseimport/exportisn’tthefullstoryHive元數(shù)據(jù)拷貝理想情況下，元數(shù)據(jù)的備份應(yīng)該于核心數(shù)據(jù)備份在同一個過程中進行因為保持數(shù)據(jù)于元數(shù)據(jù)一致非常重要海量數(shù)據(jù)拷貝值得考慮的問題你的數(shù)據(jù)是否壓縮?沒有哪個系統(tǒng)支持在傳輸線路上進行壓縮WAN加速器雖然可以在一定程度上解決問題，但是需要付出更大代價你是否了解你的網(wǎng)絡(luò)帶寬需求?初始化數(shù)據(jù)加載每日數(shù)據(jù)接入的量–相對于歷史數(shù)據(jù)數(shù)據(jù)的比例你是否了解網(wǎng)絡(luò)安全設(shè)置?Datanodes及RegionServers相互通訊–他們需要彼此保持連接性你是否進行了合理的網(wǎng)絡(luò)安全設(shè)置?讓Kerberos支持跨realm信任仍然是個挑戰(zhàn)是否考慮跨版本的數(shù)據(jù)拷貝?很難保證任何時候兩個集群都擁有相同的版本，需要更多的測試和考慮管理數(shù)據(jù)復(fù)制計劃及調(diào)度數(shù)據(jù)復(fù)制作業(yè)基于時間的調(diào)度基于工作流的調(diào)度優(yōu)先級保持采用獨立的調(diào)度組來調(diào)度具有不同優(yōu)先級的數(shù)據(jù)復(fù)制作業(yè)調(diào)度的數(shù)據(jù)復(fù)制作業(yè)所使用的帶寬不要超過集群間所能提供的最大網(wǎng)絡(luò)帶寬其他的思考硬件方面的思考磁盤的密度的選擇–4TB盤

、2TB盤取決于數(shù)據(jù)中心集群站點的負載目標考慮盡可能只復(fù)制最重要的數(shù)據(jù)注意復(fù)制因子使用率的思考