LAXCUS 分布式操作冗余容错之节点篇

本文所说的“节点”，包含了软件的“进程和硬件的“计算机”两个概念，请诸位注意一下。在早期版本中，节点故障更多是软件故障造成的，比如节点的运行管理机制处理不善，模块间的 API 接口协同、衔接的错误。这些问题都与详细设计和编程有很大关系，随着版本演进，现在越来越多的情况是硬件问题导致。在 Laxcus 分布式操作系统集群里，由于 Front 节点归用户使用，而且功能简单，实质只是一个用于输入输出的显示终端，所以本文忽略它，将主要介绍集群管理员管理下的节点冗余容错。

一、管理节点的冗余容错

前面已经提到过，在 Laxcus 中无论是主域集群还是子域集群，都只能有一个 Master 管理节点来负责所属集群的管理工作，它在自己集群里的地位是独一无二的，是保证整个集群正常运行的关键。同时，为保证集群不会因为 Master 节点故障造成集群的管理混乱，通常还有一至数个 Monitor 管理节点做为备份存在着，它们将监视 Master 节点运行。

在我们的测试环境，有 1 个 Master 节点和 2 个 Monitor 节点。为检查管理节点容错能力，我们进行了这样的试验。我们使用 Linux  kill 命令杀掉一个 Master 节点进程，在第 5 秒钟的时候，其中一个 Monitor 节点感知到 Master 节点发生了故障，并且立即启动故障协商机制，询问另一个 Monitor 节点，它对 Master 节点的判断，双方很快共同确认了 Master 节点发生了故障。然后，它们按照自己的网络地址排序，选择数字最大的那个 Monitor 节点，成为新的 Master 节点。新 Master 节点立即将自己从 Monitor 状态转入 Master 状态，并且通知原来所有下属节点（包括另一个 Monitor 节点），让它们重新注册到新 Master 节点下面，同时将故障的 Master 节点和切换过程通知给 Watch 节点。整个容错处理在 20 秒内完成。

二、Data 节点的冗余容错

Data 节点保存着集群的全部数据，它的重要性仅次于管理节点，所以 Data 节点的冗余容错管理也与其它节点大不相同。上面已经介绍过，每个节点宕机都会被管理节点及时捕捉到。在 Data 节点宕机后，管理节点会在报警的同时，对 Data 节点的数据做出如下处理：取出这个 Data 节点的数据块编号，按照数据块编号，找到同源备份，产生一个新的备份到其它节点上，如果是 Data 主节点，其它从节点备份会恢复到一个新的主节点上，并且这些从块也升级成主块。如果是 Data 从节点，这些备份会从主节点产生备份，分发到其它从节点上。由于 Data 主节点的数据量一般都比较大（最多时候有几个 TB)，又要保证不能太过于占用网络带宽，实际上这个恢复备份过程是缓慢的。在这段时间里，管理员有足够的时间来检查和恢复故障计算机。当重新启动计算机后，它会在网络上进行主块冲突检查，避免同质数据块出现。尤其是主节点故障，在恢复完成前，存在着数据不全的可能性，这个时间内发生的更新/删除操作，Call 节点将拒绝它们执行，直到全部数据完成恢复。

三、集群内其它节点冗余容错

相较于以上两种，集群内的其它节点由于只保存着少量实时的元数据，不负责集群管理工作，只是为了满足分布处理流程而存在，且运行过程中通常也不止一个同类节点，这使得每类节点之间，可以互相替代。这些单个节点的退出和加入，对于整个集群的运行来说，只会产生微小的影响。所以在 Laxcus 分布式操作系统的冗余容错设计里，对这些节点的容错管理要宽泛很多。它们的故障，大都以报警方式通知给 Watch 节点，由管理员来判断和选择处理。它们缺失的工作，会在管理节点的干涉下，把业务切换到其它同类正常节点上。这些故障感知和切换过程都是实时的，被控制在数秒以内，保证将对集群的影响降到最低。