cloudera高可用性及容灾方案

CDH高可用性方案

Cloudera存储级别的高可用HDFSHA使用基于Quorum的机制实现HDFS高可用HBaseHA通过备份/复制HBaseMaster实现Hbase高可用YARNRM高可用Work保存及恢复OozieHue

Impala

ImpalaProxyHAHiveMetastore创建多个HiveMetastore，并使用共享Database创建多个HiveServer2，实现负载均衡SearchisProductionMode=trueisIgnoringRecoverableExceptions=trueCloudera

Manager高可用及负载均衡Service级别高可用更多关于高可用的文档CDH5高可用性

技术博客

YARNMaster/Worker架构为什么要使用高可用？－－单点故障YARN高可用架构设计通过多个RM实现active-standby的模式消除RM单点故障Oozie高可用-Active/Active对Oozie来说,主要通过“active-active”或者“hot-hot”实现高可用,即所有Oozie的服务器都在线且对外提供服务.用户可以根据需要建立任意多个Oozie服务器.Oozie服务可以实现水平扩展.Oozie高可用架构-Database共享metadata，并存储在高可用的数据库中Oozie高可用架构-客户端访问HAProxy采用Round-robin轮询机制实现透明访问和负载均衡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实现Oozie高可用图形化配置Oozie高可用架构-日志流写入Hue高可用架构在Hadoop集群中配置多个HueServices（5.4以前版本）安装独立的HueService服务在Hue

Service中配置多个HueServer（5.4及以后版本）安装独立的HueService实例HAProxy实现透明访问和负载均衡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–统计报告Hadoop备份及灾难恢复是什么让Hadoop与众不同?并不多除了TB到PB的数据廉价的硬件高度分布多种不同的服务Hadoop中哪些数据需要保护?配置:支持客户应用运行的所有配置信息数据集:数据&元数据(Hive)应用程序:系统应用程序(RM,NN,RegionServers等)及用户的应用程序我们应聚焦哪些数据？数据集聚焦数据集并非因为其他不重要...而是因为现有的系统及流程能够帮助管理应用和配置，保证数据安全灾难的分类硬件类问题磁盘上的数据失效硬盘/服务器节点失效机柜失效用户/应用程序错误意外的数据删除坏数据写入数据中心问题数据中心永久损毁–如火灾、地震等数据中心临时不可用–网络故障、电力故障等(更常见)业务目标驱动技术方案灾难恢复时间目标RTOs(RecoveryTimeObjective)灾难恢复点目标RPOs(RecoveryPointObjective)必须针对不同的灾难故障类型采取不同的灾备和恢复计划灾难模式发生概率损失成本磁盘失效高低节点失效高低机柜失效中中意外删除中中中心失效低高HDFS的基本概念**FromHadoopdocumentation数据块复制数据节点硬件故障之－数据块损坏磁盘上的数据块损坏文件的数据块的元数据Checksum检查如果checksums结果不匹配,namenode将丢弃该数据块，并从其他可用的拷贝中复制Namenode还可以把元数据进行多份复制到不同的文件系统进行备份硬件故障之-磁盘/节点损坏Datacorruptionondisk磁盘／节点损坏同步复制的数据保障了数据安全-前两份数据副本存放在相同Rack的不同服务器上，第三份副本保存在另一机柜的服务器中节点失效后，心跳线丢失，NameNode会自动检测到节点失效Namenode高可用保证元数据安全如果HDFS上的数据块的副本数少于复制因子（如3），Hadoop会自动复制数据块，保障数据安全硬件故障之–Rack失效DatacorruptionondiskRack失效配置至少3份数据副本，保证数据安全。HDFS中配置Rack

信息第3份副本应该存储在不同的Rack的服务器上第3份副本非常重要－在整个Rack不可用的情况下，仍然能保证对外提供数据服务千万别忘记metadata元数据Hivemetadata记录了你的数据的描述Metadata数据备份非常简单!通过SQL的方式来备份Metadata

基本的硬件故障已经尽在掌握！同时…使用监控工具来跟踪节点的健康状态定期检查DataNode上的数据块扫描报告()Hadoopfsck命令是非常实用的工具ClouderaManager提供您所需的全方位集群健康检查同时，还应关注另外一些细节需要注意…HDFS升级需要格外注意任何磁盘上的修改都是存在风险的!Name

node的元数据需要单独备份先在小规模的测试集群上测试升级过程，再在生产环境实施升级前，务必把所有重要的数据先备份到远程的节点上，以防万一!应用或用户错误首先，务必遵守最小权限原则权限许可范围用户应该仅仅被赋予必须的数据权限配额管理命名配额:限制挂载的文件数量空间配额:限制挂载文件的大小数据意外删除的防护Trashserver－回收站如果启用，被删除的数据会保留在回收站中通过设置erval参数来控制数块在回收站中保留的时间需要注意:回收站保护仅对fsshell操作有效，采用程序的删除不被保护.Trash是用户级别的保护，每个用户都有自己的回收站同时，别忘了元数据保护同样的，通过SQL按照计划有规律的备份是关键HDFSSnapshots（快照）什么是快照?Snapshots表现的是在某一个时间点上，系统的状态采用的是copy-on-write实现机制因为HDFS中采用的是append-only机制，因此快照仅对数据删除进行管理HDFSSnapshots（快照）实现细节–NameNode快照:非常快一致性保证恢复时，需要进行数据拷贝.snapshot目录的访问与每一个文件匹配

那么HDFSSnapshots能解决什么问题?处理用户/应用

级别的数据错误处理偶然性的意外数据删除同时，还能用于测试/开发目的－快速部署基于生产数据的测试/开发环境!HBasesnapshots（快照）与HDFS的快照工作方式类似快速建立快照一致性恢复仅需一个copy命令

Snapshots（快照）管理存储空间的考虑:集群存储空间多少%可用于snapshotsSnapshots的数量空间问题的告警调度恢复:基于时间的策略基于工作流的策略数据中心的DR数据中心A数据中心BHDFSHiveHBaseHDFSHiveHBase多通路vs拷贝多通路方式在数据接入阶段，采用多路复制的方式，把数据发送到主数据中心及备份中心集群间的延时最小网络带宽要求高故障发生时，主备集群都需要进行恢复主备集群会发生数据不一致拷贝方式数据从主集群通过拷贝（批量/实时）的方式备份到备份集群集群间的数据保持一致数据接入只需处理一次恢复时会有更多时延需要更多的带宽实现方法数据接入阶段故障恢复阶段如何选择?使用场景来决定！但是通常情况，更倾向于使用数据拷贝的方式针对每种服务采用不同策略HDFS多通路:Flume、Sqoop支持多通路拷贝:使用DistCP工具进行数据拷贝HBase多通路:采用应用程序级别多通路数据拷贝:HBase数据库复制机制Hive多通路:NA数据拷贝:数据库import/export**Databaseimport/exportisn’tthefullstoryHive元数据拷贝理想情况下，元数据的备份应该于核心数据备份在同一个过程中进行因为保持数据于元数据一致非常重要海量数据拷贝值得考虑的问题你的数据是否压缩?没有哪个系统支持在传输线路上进行压缩WAN加速器虽然可以在一定程度上解决问题，但是需要付出更大代价你是否了解你的网络带宽需求?初始化数据加载每日数据接入的量–相对于历史数据数据的比例你是否了解网络安全设置?Datanodes及RegionServers相互通讯–他们需要彼此保持连接性你是否进行了合理的网络安全设置?让Kerberos支持跨realm信任仍然是个挑战是否考虑跨版本的数据拷贝?很难保证任何时候两个集群都拥有相同的版本，需要更多的测试和考虑管理数据复制计划及调度数据复制作业基于时间的调度基于工作流的调度优先级保持采用独立的调度组来调度具有不同优先级的数据复制作业调度的数据复制作业所使用的带宽不要超过集群间所能提供的最大网络带宽其他的思考硬件方面的思考磁盘的密度的选择–4TB盘

、2TB盘取决于数据中心集群站点的负载目标考虑尽可能只复制最重要的数据注意复制因子使用率的思考