GlusterFS复制卷修复原理以及脑裂分析
2015-11-17 16:20
232 查看
裂脑
所谓脑裂,就是指两个或多个节点都“认为”自身是正常节点而互相“指责”对方,导致不能选取正确的节点进行接管或修复,导致脑裂状态。这种现象出现在数据修复、集群管理等等高可用场景。
Glusterfs的冗余镜像(下文简称AFR)提供了数据副本功能,能够在即使只有一个冗余节点的情况下仍能正常工作,不中断上层应用。当节点恢复后,能够将数据修复到一致状态,保证数据的安全。
AFR工作原理
AFR数据修复主要涉及三个方面:ENTRY,META,DATA,我们以冗余度为2即含有两个副本A和B的DATA修复为例进行讲解。记录描述副本状态的称之为ChangeLog,记录在每个副本文件扩展属性里,读入内存后以矩阵形式判断是否需要修复以及要以哪个副本为Source进行修复。初始值以及正常值为0.(注:ENTRY和META,DATA分布对应着一个数值)。 Write的步骤可分解为:
1)下发Write操作。 2)加锁Lock。 3)向A,B副本的ChangeLog分别加1,记录到各个副本的扩展属性中。 4)对A,B副本进行写操作。 5)若该副本写成功则ChangeLog减1,若该副本写失败则ChangLog值不变,记录到各个副本的扩展属性中。 6)解锁UnLock。 7)向上层返回,只要有一个副本写成功就返回成功。 上述在AFR中是完整的一个transaction动作。根据两个副本记录的ChangeLog的数值确定了副本的几种状态: 1)WISE,智慧的,即该副本的ChangeLog中对方对应的数值大于0而且自身对应的数值等于0. 2)INNOCENT,无辜的,即该副本上的ChangeLog即不指责对方也指责自己,ChangeLog全为0. 3)FOOL,愚蠢的,即该副本上的ChangeLog是指责自己的。 4)IGNORANT,忽略的,即该副本的ChangeLog丢失。
所以一般情况下,会选取WISE的副本作为Sourse进行修复。但是当两个节点都是WISE状态时,这就出现了声名狼藉的脑裂状态。
AFR脑裂 两个副本均为WISE时发生脑裂,那么在哪种场景下会产生脑裂呢?我们还是以冗余度为2的情况举一个简单的例子: 某文件X的两个副本位于物理机A和物理机B上,在A和B上分别运行着进程a和进程b,a和b持续通过各自所在的物理机上的客户端对文件X进行不同的写操作。然后物理机A和B之间网络中断,因为AFR在一个副本的情况下仍能不中断上层应用,所以进程a和进程b仍会持续运行,但因为网络中断,文件X在A和B上的副本数据不再一致且都认为对方是异常的,当网络恢复时,两个副本互相“指责”,即出现了脑裂。 当然这是脑裂发生的场景之一,有时候是有可能发生脑裂,而有时候是必然发生脑裂。脑裂,也是很多人关心的一个问题,不能一概而论。
关于脑裂,不同的场景处理方法也是不同的,甚至某些场景的脑裂是无法避免的,只能尽量避免脑裂的发生。
如何预防裂脑 预防裂脑,可以配置服务器端和客户端的仲裁机制。
客户端和服务器端仲裁对比可见:GlusterFS 客户端与服务器端仲裁机制对比。
参考资料说明
绝大多数内容来自:GlusterFS冗余镜像(AFR)修复原理以及脑裂分析,写的不错,做了一些的小的改动,特别是对裂脑的态度。这里标成原创,提高曝光率。
所谓脑裂,就是指两个或多个节点都“认为”自身是正常节点而互相“指责”对方,导致不能选取正确的节点进行接管或修复,导致脑裂状态。这种现象出现在数据修复、集群管理等等高可用场景。
Glusterfs的冗余镜像(下文简称AFR)提供了数据副本功能,能够在即使只有一个冗余节点的情况下仍能正常工作,不中断上层应用。当节点恢复后,能够将数据修复到一致状态,保证数据的安全。
AFR工作原理
AFR数据修复主要涉及三个方面:ENTRY,META,DATA,我们以冗余度为2即含有两个副本A和B的DATA修复为例进行讲解。记录描述副本状态的称之为ChangeLog,记录在每个副本文件扩展属性里,读入内存后以矩阵形式判断是否需要修复以及要以哪个副本为Source进行修复。初始值以及正常值为0.(注:ENTRY和META,DATA分布对应着一个数值)。 Write的步骤可分解为:
1)下发Write操作。 2)加锁Lock。 3)向A,B副本的ChangeLog分别加1,记录到各个副本的扩展属性中。 4)对A,B副本进行写操作。 5)若该副本写成功则ChangeLog减1,若该副本写失败则ChangLog值不变,记录到各个副本的扩展属性中。 6)解锁UnLock。 7)向上层返回,只要有一个副本写成功就返回成功。 上述在AFR中是完整的一个transaction动作。根据两个副本记录的ChangeLog的数值确定了副本的几种状态: 1)WISE,智慧的,即该副本的ChangeLog中对方对应的数值大于0而且自身对应的数值等于0. 2)INNOCENT,无辜的,即该副本上的ChangeLog即不指责对方也指责自己,ChangeLog全为0. 3)FOOL,愚蠢的,即该副本上的ChangeLog是指责自己的。 4)IGNORANT,忽略的,即该副本的ChangeLog丢失。
所以一般情况下,会选取WISE的副本作为Sourse进行修复。但是当两个节点都是WISE状态时,这就出现了声名狼藉的脑裂状态。
AFR脑裂 两个副本均为WISE时发生脑裂,那么在哪种场景下会产生脑裂呢?我们还是以冗余度为2的情况举一个简单的例子: 某文件X的两个副本位于物理机A和物理机B上,在A和B上分别运行着进程a和进程b,a和b持续通过各自所在的物理机上的客户端对文件X进行不同的写操作。然后物理机A和B之间网络中断,因为AFR在一个副本的情况下仍能不中断上层应用,所以进程a和进程b仍会持续运行,但因为网络中断,文件X在A和B上的副本数据不再一致且都认为对方是异常的,当网络恢复时,两个副本互相“指责”,即出现了脑裂。 当然这是脑裂发生的场景之一,有时候是有可能发生脑裂,而有时候是必然发生脑裂。脑裂,也是很多人关心的一个问题,不能一概而论。
关于脑裂,不同的场景处理方法也是不同的,甚至某些场景的脑裂是无法避免的,只能尽量避免脑裂的发生。
如何预防裂脑 预防裂脑,可以配置服务器端和客户端的仲裁机制。
客户端和服务器端仲裁对比可见:GlusterFS 客户端与服务器端仲裁机制对比。
参考资料说明
绝大多数内容来自:GlusterFS冗余镜像(AFR)修复原理以及脑裂分析,写的不错,做了一些的小的改动,特别是对裂脑的态度。这里标成原创,提高曝光率。
相关文章推荐
- 浅谈web上存漏洞及原理分析、防范方法(安全文件上存方法)
- Linux使用libnet实现ARP攻击脚本原理分析以防被攻击
- 探讨:web上存漏洞及原理分析、防范方法
- 关于glusterfs-3.3.1的两个bug
- Glusterfs:趋于成熟的集群文件系统
- Glusterfs简介以及其工作流程的简单分析
- Glusterfs3.3.1DHT(hash分布)源代码分析
- Glusterfs的编译选项 #pragma GCC poison system popen
- 关于Glusterfs为何采用哈希分布式算法
- 关于glusterfs的directory-layout-spread参数
- 基于外部ZooKeeper的GlusterFS作为分布式文件系统的完全分布式HBase集群安装指南
- GlusterFS学习
- GlusterFS基础知识
- 基于 GlusterFS 的高可用 MySQL 数据库系统测试
- glusterfs中split-brain的重现与修复
- 【一】GlusterFS 快速部署指南
- 【GlusterFS学习之一】:GlusterFS分布式文件系统的基本概念及搭建
- 【GlusterFS学习之二】:GlusterFS的Self-Heal特性
- 【GlusterFS学习之四】:自动在volfile中生成需要的xlator
- 【GlusterFS学习之五】:trashdir回收站目录只读权限以及白名单的设计与实现