文档章节

让我们聊聊脑裂这事情

安小乐
 安小乐
发布于 2017/02/26 17:30
字数 2707
阅读 421
收藏 0

万事皆有因

最近IM云平台也好,社交应用也好,大量的使用ejabberd的厂商涌现出来了。不过所有使用ejabberd厂商可能都会遇到Mnesia脑裂的问题。在这里打算简单的谈谈脑裂这个事情。

 

什么是脑裂

我在这里面给个非官方的定义吧。当一个集群的不同部分在同一时间都认为自己是活动的时候,我们就可以将这个现象称为脑裂症状。我们当如何理解这句话呢?

  1. 首先我们需要是个集群。

  2. 其次当中有业务是Master-Backup模式或双星模式。也就是说当主节点挂掉了,备用节点需要接管业务或者是两个节点直接有数据同步。

让我们举个例子(图片来自https://blog.process-one.net/angie_introducing_flexarch/):

 

其中ejabberd front是不存在Router的,只有Client Manager。而ejabberd back是具有Message router 的。那么我们可以将这个图简单的抽象为这样的:

 

 

UserA和UserB分别将自己的信息注册在RouterA和RouterB中。RouterA和RouterB使用数据同步(2PC),来同步信息。那么当UserA想要向UserB发送一个消息的时候,需要现在RouterA中查询出UserA到UserB的消息路由路径,然后再交付给相应的路径进行路由。

当脑裂发生的时候,相当RouterA和RouterB直接的联系丢失了,RouterA认为整个系统中只有它一个Router,RouterB也是这样认为的。那么相当于RouterA中没有UserB的信息,RouterB中没有UserA的信息了,此时UserA再发送消息给UserB的时候,RouterA会认为UserB已经离线了,然后将该信息进行离线持久化。

说到这里面估计大家已经明白了脑裂是什么东西了。

 

怎么解决

  1. paxos算法,使用奇数性质的节点来进行表决,必须选出一个说的算的老大,这个集群才能正常工作。

  2. 双星模式下,使用专线直连,从硬件上保障。

  3. 使用额外的探测节点,当双方直连断开之后,使用一个约定好的共同节点来探测是否是直连故障。

转载自:https://my.oschina.net/u/236698/blog/525413

 

转载另一篇博客:Namenode HA原理详解(脑裂)

Namenode HA原理详解

社区hadoop2.2.0 release版本开始支持NameNode的HA,本文将详细描述NameNode HA内部的设计与实现。

 

为什么要Namenode HA?

1. NameNode High Availability即高可用。

2. NameNode 很重要,挂掉会导致存储停止服务,无法进行数据的读写,基于此NameNode的计算(MR,Hive等)也无法完成。

 

Namenode HA 如何实现,关键技术难题是什么?

1. 如何保持主和备NameNode的状态同步,并让Standby在Active挂掉后迅速提供服务,namenode启动比较耗时,包括加载fsimage和editlog(获取file to block信息),处理所有datanode第一次blockreport(获取block to datanode信息),保持NN的状态同步,需要这两部分信息同步。

2. 脑裂(split-brain),指在一个高可用(HA)系统中,当联系着的两个节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏。

3. NameNode切换对外透明,主Namenode切换到另外一台机器时,不应该导致正在连接的客户端失败,主要包括Client,Datanode与NameNode的链接。

社区NN的HA架构,实现原理,各部分的实现机制,解决了哪些问题?

1. 非HA的Namenode架构,一个HDFS集群只存在一个NN,DN只向一个NN汇报,NN的editlog存储在本地目录。

2. 社区NN HA的架构

图1,NN HA架构(从社区复制)

    社区的NN HA包括两个NN,主(active)与备(standby),ZKFC,ZK,share editlog。流程:集群启动后一个NN处于active状态,并提供服务,处理客户端和datanode的请求,并把editlog写到本地和share editlog(可以是NFS,QJM等)中。另外一个NN处于Standby状态,它启动的时候加载fsimage,然后周期性的从share editlog中获取editlog,保持与active的状态同步。为了实现standby在sctive挂掉后迅速提供服务,需要DN同时向两个NN汇报,使得Stadnby保存block to datanode信息,因为NN启动中最费时的工作是处理所有datanode的blockreport。为了实现热备,增加FailoverController和ZK,FailoverController与ZK通信,通过ZK选主,FailoverController通过RPC让NN转换为active或standby。

 

2.关键问题:

(1) 保持NN的状态同步,通过standby周期性获取editlog,DN同时想standby发送blockreport。

(2) 防止脑裂

  共享存储的fencing,确保只有一个NN能写成功。使用QJM实现fencing,下文叙述原理。

  datanode的fencing。确保只有一个NN能命令DN。HDFS-1972中详细描述了DN如何实现fencing

     (a) 每个NN改变状态的时候,向DN发送自己的状态和一个序列号。

    (b) DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active。

     (c) 如果这时原来的active(比如GC)恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令。

     (d) 特别需要注意的一点是,上述实现还不够完善,HDFS-1972中还解决了一些有可能导致误删除block的隐患,在failover后,active在DN汇报所有删除报告前不应该删除任何block。

   客户端fencing,确保只有一个NN能响应客户端请求。让访问standby nn的客户端直接失败。在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间。

ZKFC的设计

1. FailoverController实现下述几个功能

  (a) 监控NN的健康状态

  (b) 向ZK定期发送心跳,使自己可以被选举。

  (c) 当自己被ZK选为主时,active FailoverController通过RPC调用使相应的NN转换为active。

2. 为什么要作为一个deamon进程从NN分离出来

  (1) 防止因为NN的GC失败导致心跳受影响。

  (2) FailoverController功能的代码应该和应用的分离,提高的容错性。

  (3) 使得主备选举成为可插拔式的插件。

图2 FailoverController架构(从社区复制)

3. FailoverController主要包括三个组件,

  (1) HealthMonitor 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成。

  (2) ActiveStandbyElector 管理和监控自己在ZK中的状态。

  (3) ZKFailoverController 它订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NameNode的状态。

 

QJM的设计

  1. Namenode记录了HDFS的目录文件等元数据,客户端每次对文件的增删改等操作,Namenode都会记录一条日志,叫做editlog,而元数据存储在fsimage中。为了保持Stadnby与active的状态一致,standby需要尽量实时获取每条editlog日志,并应用到FsImage中。这时需要一个共享存储,存放editlog,standby能实时获取日志。这有两个关键点需要保证, 共享存储是高可用的,需要防止两个NameNode同时向共享存储写数据导致数据损坏。

  2. 是什么,Qurom Journal Manager,基于Paxos(基于消息传递的一致性算法)。这个算法比较难懂,简单的说,Paxos算法是解决分布式环境中如何就某个值达成一致,(一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个"一致性算法"以保证每个节点看到的指令一致)

     

    图3 QJM架构

  3. 如何实现,

    (1) 初始化后,Active把editlog日志写到2N+1上JN上,每个editlog有一个编号,每次写editlog只要其中大多数JN返回成功(即大于等于N+1)即认定写成功。

    (2) Standby定期从JN读取一批editlog,并应用到内存中的FsImage中。

    (3) 如何fencing: NameNode每次写Editlog都需要传递一个编号Epoch给JN,JN会对比Epoch,如果比自己保存的Epoch大或相同,则可以写,JN更新自己的Epoch到最新,否则拒绝操作。在切换时,Standby转换为Active时,会把Epoch+1,这样就防止即使之前的NameNode向JN写日志,也会失败。

    (4) 写日志:

      (a) NN通过RPC向N个JN异步写Editlog,当有N/2+1个写成功,则本次写成功。

      (b) 写失败的JN下次不再写,直到调用滚动日志操作,若此时JN恢复正常,则继续向其写日志。

      (c) 每条editlog都有一个编号txid,NN写日志要保证txid是连续的,JN在接收写日志时,会检查txid是否与上次连续,否则写失败。

    (5) 读日志:

      (a) 定期遍历所有JN,获取未消化的editlog,按照txid排序。

      (b) 根据txid消化editlog。

    (6) 切换时日志恢复机制

      (a) 主从切换时触发

      (b) 准备恢复(prepareRecovery),standby向JN发送RPC请求,获取txid信息,并对选出最好的JN。

      (c) 接受恢复(acceptRecovery),standby向JN发送RPC,JN之间同步Editlog日志。

      (d) Finalized日志。即关闭当前editlog输出流时或滚动日志时的操作。

      (e) Standby同步editlog到最新

    (7) 如何选取最好的JN

      (a) 有Finalized的不用in-progress

      (b) 多个Finalized的需要判断txid是否相等

      (c) 没有Finalized的首先看谁的epoch更大

      (d) Epoch一样则选txid大的。

     

    参考:

    1.https://issues.apache.org/jira/secure/attachment/12480489/NameNode%20HA_v2_1.pdf

    2.https://issues.apache.org/jira/secure/attachment/12521279/zkfc-design.pdf

    3.https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf

    4. https://issues.apache.org/jira/browse/HDFS-1972

    5.https://issues.apache.org/jira/secure/attachment/12490290/DualBlockReports.pdf

    6.http://svn.apache.org/viewvc/hadoop/common/branches/branch-2.2.0/

    7.http://yanbohappy.sinaapp.com/?p=205

转载自:http://www.cnblogs.com/shenh062326/p/3870219.html

本文转载自:https://my.oschina.net/u/236698/blog/525413

安小乐
粉丝 18
博文 179
码字总数 77673
作品 0
朝阳
后端工程师
私信 提问

暂无文章

分布式协调服务zookeeper

ps.本文为《从Paxos到Zookeeper 分布式一致性原理与实践》笔记之一 ZooKeeper ZooKeeper曾是Apache Hadoop的一个子项目,是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它...

ls_cherish
今天
4
0
redis 学习2

网站 启动 服务端 启动redis 服务端 在redis 安装目录下 src 里面 ./redis-server & 可以指定 配置文件或者端口 客户端 在 redis 的安装目录里面的 src 里面 ./redis-cli 可以指定 指定 连接...

之渊
昨天
2
0
Spring boot 静态资源访问

0. 两个配置 spring.mvc.static-path-patternspring.resources.static-locations 1. application中需要先行的两个配置项 1.1 spring.mvc.static-path-pattern 这个配置项是告诉springboo......

moon888
昨天
4
0
hash slot(虚拟桶)

在分布式集群中,如何保证相同请求落到相同的机器上,并且后面的集群机器可以尽可能的均分请求,并且当扩容或down机的情况下能对原有集群影响最小。 round robin算法:是把数据mod后直接映射...

李朝强
昨天
4
0
Kafka 原理和实战

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介:郑志彬,毕业于华南理工大学计算机科学与技术(双语班)。先后从事过电子商务、开放平...

vivo互联网技术
昨天
24
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部