Part 16:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(集群成员变更-通过联合共识支持任意的配置变更&系统集成)

Part 16:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(集群成员变更-通过联合共识支持任意的配置变更&系统集成)

4.3 ** Arbitrary confifiguration changes using joint consensus**(集群成员变更-通过联合共识支持任意的配置变更)

本节介绍了一种更复杂的方法来处理集群成员更改,以实现在一次处理中实现任意的成员变更。例如,可以同时将两个服务器添加到一个集群中,或者也可以一次替换一个五个服务器集群中的所有服务器。这是我们最先提出的成员变更的方法,对它的描述只是为了完整性。现在我们知道了更简单的单服务器变更方法,我们建议使用单服务器变更,因为处理任意更改需要额外的复杂性。任意成员变化通常是学术界喜欢讨论的问题,我们不认为在现实系统中需要这样的能力。

(此处先不看这个小节的内容,毕竟Raft也不推荐这样的方法)

4.4 System integration(系统集成)

Raft提供了很对RPC方法来实现集群中成员的变更(单个成员/次)。例如图4.1给出的AddServer和RemoveServer RPC,这些RPC可以被系统管理员调用或者使用脚本的方式使用。

可能需要在集群中服务器失效的时候自动化的调用上述RPC以实现自动的成员加入。然而,这需要在有合理的理由的情况下使用。例如,集群自动删除出现故障的服务器可能是危险的,因为它可能会留下太少的副本以满足预期的持久化属性和容错要求。一种合理的方法是让系统管理员配置所需的集群大小,在此限制下,可用的服务器可以自动替换发生故障的服务器。

当需要多次进行单服务器变更时,最好在删除服务器之前添加服务器。例如,要替换三服务器集群中的服务器,添加一个服务器,然后删除另一个服务器,将允许系统在整个过程中始终处理一个服务器故障。但是,如果在添加另一个服务器之前首先删除了它,系统将暂时无法屏蔽任何故障(因为两个服务器集群需要两个服务器都可用)。

成员变更引发了一种新的集群启动方法。如果没有动态成员身份,每个服务器都有一个静态配置文件。随着动态成员身份更改,不再需要静态配置文件,因为系统通过Raft日志来管理集群的配置;它还可能容易出错(例如,应该使用新服务器初始化哪个配置?)。相反,我们建议在第一次创建集群时,初始化一个服务器的配置log entry作为其日志中的第一个log entry。此配置仅列出了一个服务器;集群中的多数派就是这个服务器自己,因此他可以认为集群配置已经提交。从那时起,其他服务器应该使用空日志进行初始化;并通过集群变更机制加入到集群中并学习集群变更配置。

成员变更还需要客户端的动态方法来找到集群;这将在第6章中讨论。

<< 上一章:集群成员变更-可用性
下一章:集群成员变更-第4章小结 >>

你可能感兴趣的:(Part 16:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(集群成员变更-通过联合共识支持任意的配置变更&系统集成))