HDFS namenode 高可用（HA）搭建指南 QJM方式 ——本质是多个namenode选举master，用paxos实现一致性-低调大师

HDFS namenode 高可用（HA）搭建指南 QJM方式 ——本质是多个namenode选举master，用paxos实现一致性

2017-11-14 523

一、HDFS的高可用性

1.概述

本指南提供了一个HDFS的高可用性（HA）功能的概述，以及如何配置和管理HDFS高可用性(HA)集群。本文档假定读者具有对HDFS集群的组件和节点类型具有一定理解。有关详情，请参阅Apache的HDFS的架构指南。

http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html

2.背景

CDH4之前，在HDFS集群中NameNode存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现故障，那么整个集群将无法使用，直到NameNode重新启动。

NameNode主要在以下两个方面影响HDFS集群:

(1). NameNode机器发生意外，比如宕机，集群将无法使用，直到管理员重启NameNode

(2). NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS的HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

3.架构

HDFSHA的解决方案可谓百花齐放，Linux HA, VMware FT, sharedNAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shard NAS+NFS，因为简单易用，但是需要提供一个HA的共享存储设备。而社区已经把基于QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的发行版中也包含了这个feature，这种方案也是社区在未来发行版中默认的 HA方案。

在HA具体实现方法不同的情况下，HA框架的流程是一致的。不一致的就是如何存储和管理日志。在Active NN和Standby NN之间要有个共享的存储日志的地方，Active NN把EditLog写到这个共享的存储日志的地方，Standby NN去读取日志然后执行，这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接管Active NN的工作（虽然要经历一小段时间让原来Standby追上原来的Active，但是时间很短）。

说到这个共享的存储日志的地方，目前采用最多的就是用共享存储NAS+NFS。缺点有：1）这个存储设备要求是HA的，不能挂掉；2）主从切换时需要 fencing方法让原来的Active不再写EditLog，否则的话会发生brain-split，因为如果不阻止原来的Active停止向共享存储写EditLog，那么就有两个Active NN了，这样就会破坏HDFS的元数据了。对于防止brain-split问题，在QJM出现之前，常见的方法就是在发生主从切换的时候，把共享存储上存放EditLog的文件夹对原来的Active的写权限拿掉，那么就可以保证同时至多只有一个Active NN，防止了破坏HDFS元数据。

Clouera为解决这个问题提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法实现的HDFS HA方案。QJM的结构图如下所示：

QJM的基本原理就是用2N+1台JournalNode存储EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos算法的，可以参考http://en.wikipedia.org/wiki/Paxos_(computer_science)。

用QJM的方式来实现HA的主要好处有：1）不需要配置额外的高共享存储，这样对于基于commodityhardware的云计算数据中心来说，降低了复杂度和维护成本；2）不在需要单独配置fencing实现，因为QJM本身内置了fencing的功能；3）不存在Single Point Of Failure；4）系统鲁棒性的程度是可配置的（QJM基于Paxos算法，所以如果配置2N+1台JournalNode组成的集群，能容忍最多N台机器挂掉）；5）QJM中存储日志的JournalNode不会因为其中一台的延迟而影响整体的延迟，而且也不会因为JournalNode的数量增多而影响性能（因为NN向JournalNode发送日志是并行的）。

摘自：http://blog.csdn.net/dangyifei/article/details/8920164

本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/6516424.html，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/397862

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

事物复制中大项目(Large Article)出问题如何快速修复

事物日志中如果大的发布项目(Article)出问题了，并且影响了系统的使用，如何快速的解决？一般的做法是重新用快照或者备份初始化，但是如果出问题的表非常大(上亿的记录，几十GB的数据)，使用初始化是非常耗费时间的。其实可以重建发布订阅，而不用快照初始化的方式解决，这样就极大的节省了初始化的时间，而且不会对主库的表加锁。具体的步骤如下：１.将发布订阅的脚本导出到SSMS新的查询窗口这里我们需要注意的是两个参数： execsp_addarticle@pre_creation_cmd=N'drop' drop:表示删除存在的对象重新创建 execsp_addsubscription@sync_type=N'automatic' Automatic：数据和Schema由发布表初始化２.修改脚本，将上面的两个属性修改为： @pre_creation_cmd=’none’　（数据架构都已经在订阅段准备好了，不需要snapshot同步了）． @sync_type=N'replicationsupportonly'(架构和数据已经初始化) ３.使用SSMS删除发布订阅４.同步数据，可以使...

2017-11-15

584

v1.接口Class<?> resourceClass v2.获取builder BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition(resourceClass); v3.获取接口对应的动态代理class Class<?> targetProxyClass = Proxy.getProxyClass(XXX.class.getClassLoader(), new Class[]{resourceClass}); v4.targetProxyClass构造参数类型InvocationHandler，通过builder设置 builder.addConstructorArgValue(Proxy.getInvocationHandler(xxxProxyBean) 或者 newInvocationHandler(){...}); 　AbstractBeanDefinition beanDefinition = builder.getBeanDefinition();...

2017-11-15

599

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。