• 关于

    假设参考连接宕机的原因

    的搜索结果

回答

Hbase 是一个always-available的服务,在机器故障的时候保持可用性,集群中的机器都运行regionserver daemons。但一个regionserver出现故障,或者机器掉线,那么保存在上面的regions也同样掉线。Hbase中MTTR的能够检测异常,尽可能早的恢复对掉线region的访问。 文章解释了hbase如何管理MTTR,并且介绍了一些hbase和hdfs的设置。 Hbase是一致性时对故障的如何保持弹性 Hbase通过让一个单独的server负责数据的子集,也就是说,一个region在同一时刻只能被一个region server进行管理。 Hbase对失败的弹性,归功于hdfs,因为在写数据的时候,数据会被复制到到不通的节点。 Hbase将数据写入到hfiles中,hfile保存在hdfs上面,hdfs完成对hfiles的block的副本(replica)。默认情况下是副本数是3. Hbase使用commit log(或者称之为Write-Ahead-log,WAL),提交日志也同样写在HDFS上面,默认副本数为3. Hbase在故障检测以及访问恢复的步骤: 识别宕机的节点(Identifying that a node is down):由于过载或者直接死掉,节点会不再响应。 在write操作进行中的时候进行恢复(Recovering the writes in progress):通过读取commit log,恢复还没有被flush的edit。 重新分配region:失败的regionserver之前在正在处理一些region,这些region需要被重新分配给其他的RS(regionSever),这个分配过程要根据每台RS不通的workload的情况 那上面三个过程中哪一个步骤最痛苦?在检测以及恢复步骤发生的时候,客户端会被阻塞。MTTR的作用就是加速这个处理过程,让客户端对数据downtime的感知时间尽可能的短。 检测失败节点: 一个RS的失败原因很多:正常的情况下,可能是由于clean stop,比如管理员关闭了某个节点,这就允许RS能安全适当的关闭region,然后告诉HMaster,正在关闭。这种情况下,commit log会被清除,然后HMaster会立刻安排region的重新分配。 另外的regionserver关闭的的情况:比如运行RS的计算机静默死亡(silent death),比如网络原因。导致region server不能够发出告警,这种情况有Zookeeper进行处理。 每一个RS都会连接到Zookeeper上面,而Master监测这些连接,Zookeeper自己管理heartbeat。所以timeout出现的时候,Hmaster会申明region server 已经死亡,启动一个恢复处理过程 恢复正在进行中的写操作。 当一个RS 出现了宕机,那么commit logs的恢复工作就发生了。这个恢复工作是并行开始的。 第一步:随机的RS会提取commit logs(从设置好的commit log 目录中),并且按照region来分割日志成多个文件,保存在HDFS上面,然后region会被重新分配给其他任意的RS, 然后每一个被分配的RS的都会去读取已经前面分割好的对应的region 日志文件,并且进行将该region恢复到正确状态。 当出问题的是一个node 失败了,而不是一个进程崩溃了,那么问题就会出现了。 出现进程崩溃的的regionserver,会将数据写入到处于同一台机上面的datanode上面。假设副本因素为3,那么当一个node丢失的时候,你丢失的不仅仅是一个region server,并且还有这个数据的一个副本。 进行split,就意味着要读取block,而1/3的副本已经死了,那么对于每一个block,你会有三分之一的几率被引导到错误的副本上面。还有,split操作需要创建新的文件。每一个文件都会有3个副本,这些副本可能会被指派给已经丢失的datanode,而这个write数据的过程由于datanode已经死亡,会在经过一个timeout之后失败,而重新回转到另外一个datanode上面,这就延缓了数据的恢复的过程。 重新分配region 分配region的工作会进行的很快,这依赖于Zookeeper,需要通过Zookeeper完成master和region server的异步工作。 MTTR带来的提升(The MTTR improvements) 检测失败节点: 首先,可以减小默认的timeout时间。Hbase 被配置成3分钟的Zookeepertimeout时间,这就保证了GC不会介入进来(GC parse会导致ZK的timeout,会导致错误的failure检测。) 对于生产系统,关注MTTR的话,设置timeout时间为1分钟,或者30秒,是很有必要的。 一个合理的最小设置时20秒。所以你可以设置hbase.zookeeper.timeout=60000 你同样设置你GC(incremental, generational GC with good figures for the young and old generations, etc., this is a topic by itself) ,这样使GC的暂停时间不要超过ZK timeout。 恢复正在进行中的写操作。 在正常情况下,会有足够的活跃的RS来并行的完成commit log files的split工作,所以问题的就转到能否直接找到HDFS上面仅存的副本。该问题的解决方案是,配置HDFS,是hdfs对于故障的检测快于hbase的检测。那就是说,如果hbase的timeout为60s,HDFS应该设置成20s(就是设置成20s之后就认为node已经死亡)。在这里我们要描述一下HDFS是如何处理dead node。HDFS的故障检测也同样是依赖于heartbeat和timeout,在HDFS中,如果一个node被申明为dead,那么保存在该datanode上面的replicas将会被复制到其他活跃的datanode上面去,而这个是一个消耗很大的过程,并且,如果多个datanode同事死亡,那么这就会引发“replication storms”,replication storms指所有的副本被重新拷贝,这会加剧系统负载,从而导致某些节点不响应,进而导致这些节点被NN视为已经死亡,而这些节点上面block又要重新被复制,周而复始,这样的replication storms实在是可怕了。 因此,HDFS在开始恢复过程之前会等待一段时间,会比10分钟长一点。而这一点,对于低延时系统来说就是一个问题:访问dead datanode就会促发timeout。在HDFS versions 1.0.4 or 1.2, and branches 2 and 3中,引入一个新的状态:stale。当一个datanode不再发送hearbeat,并且这个时间持续到一个指定的时间,那么datanode处于stale状态。 处于stale状态的节点就是在读写过程中最后一个选择(a last resort for reads),所以启用这种性质,会是恢复更加快。 设置启用stale的方法:修改hdfs-site.xml dfs.namenode.avoid.read.stale.datanodetruedfs.namenode.avoid.write.stale.datanodetrue dfs.namenode.write.stale.datanode.ratio1.0fdfs.namenode.check.stale.datanodetrue注:我在cloudera cdh-4.1.2 提供的doc的配置项目文档中没有找到该参数,看了源码才找到这些参数。 具体参考HDFS-3912, HDFS-4350: 重新分配region Region分配的是纯粹hbase的内部实现,在Hbase 0.94+的版本中,region 分配过程的处理被优化了,允许在很短的时间异步分贝更多的region。 具体可以参考[example - Apache jira HBASE-7247]. 结论。 在Hbase中没有global failure,如果一个region server 失败了,其他的region server 仍然可用,对于给定的一个数据集,MTTR 通常是 10分钟左右。 该经验数值是从是从比较普遍的情况是中得到的,因为需要使用dead datanode的节点上面副本数,恢复就需要时间。HDFS需要花费10分钟的时间来申明datanode死亡了。 当引入了stale状态的时候,这就不再是一个问题了。这个时候恢复时间就变成Hbase本身的问题,如果你需要考虑MTTR,那么你采用这里的设置,从节点真的出现失败,到数据在其他RS上面又重新变得可用,这个过程只需要2分钟,或者更少。

hiekay 2019-12-02 01:42:58 0 浏览量 回答数 0

问题

HBase最佳实践-读性能优化策略

pandacats 2019-12-20 21:02:08 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站