Totem协议（SRP/RRP）讲解

基本概念

•SRP: The Totem Single-Ring Ordering and MembershipProtocol
–基于以太网的组通信协议，节点间组成单环结构
–所有数据都采用UDP广播(message)、单播(token)
–消息的可靠性和有序性，基于token-passing实现
–每个节点都接收到同样的消息序列，故可容忍消息丢失、节点崩溃

•RRP: The Totem Redundant Ring Protocol
–基于SRP，RRP嵌入于SRP的网络层（相当于修改了SRP的recv/send函数）
–通过使用冗余网络把多个节点连接起来，可容忍网络的损坏

术语解释
•Processor：
–节点，组通信成员，它需要实现SRP/RRP协议，并对外提供组通信接口，例如corosync，它提供组通信服务（叫CPG）。
•Application：
–程序，使用组通信服务的应用程序，它调用Processor提供的组通信接口。例如sheepdog就是调用corosync提供的CPG接口。



•Broadcast：
–One Processor => all Processors
•Transmit/Forwardtoken：
–OneProcessor => next Processor
•Delivery：
–OneProcessor => associatedApplication

基本概念

•Causal Order：
–消息的传播是可靠的，即每一个结点都能收到该消息
–所有消息都有先后次序，不存在并发的情况
–Processor将消息传送给Application时，严格按照消息的先后次序传送
•Agreed Order：
–满足Causal Order
–Processor在传送某个消息给Application时，必须确保该消息之前的所有消息都已经传送完毕，确保消息不会丢失
•Safe Order：
–满足Agreed Order
–Processor在传送某个消息给Application时，必须确保该消息之前的所有消息都已经被所有Processor接收

SRP细分为三个子协议

•The Totem Ordering Protocol（OP）：
–确保消息从Single-Ring中传播，到最终传递给Application时，满足Agreed Order或SafeOrder。
•The Membership Protocol（MP）：
–当有新的Processor加入或旧的Processor离开时，自动形成新的Single-Ring。
•The Recovery Protocol（RP）：
–从Old Ring过渡到New Ring的过程中，恢复属于（残缺的）Old Ring的消息（使它们满足Agreed或SafeOrder）。

SRP的四个状态



子协议与状态的关系

•TheTotem Ordering Protocol（OP）：
–工作在Operational状态
•TheMembership Protocol（MP）：
–工作在Gather、Commit状态
•TheRecovery Protocol（RP）：
–工作在Recovery状态

TheTotal Ordering Protocol

•TheTotem Ordering Protocol（OP）：
–工作在Operational状态
–确保消息从Single-Ring中传播，到最终传递给Application时，满足Agreed Order或SafeOrder。
–由Application在发送消息时，指定采用Agreed还是Safe方式。
–通过token，以“丢手绢”的方式，实现消息的有序传递。

消息传播示意图

ØA1请求P1依次广播三个消息：M1, M2, M3，这些消息暂存在P1的请求队列中
Ø假设P1已拿到token，P1向集群依次广播：M1,M2,M3
ØP1广播的消息，也会保存在它自己的接收队列中



消息传播示意图

ØP2只收到两个消息M2M1,P3,P4完整的收到三个消息M3M2M1
ØP1把Token传递给P2，Token中记录了P1接收队列中消息的max

seq:3
ØP2通过比较Token中的seq，发现自己没有接收到M3。



消息传播示意图

ØP2把token传给P3，更新token的aru(all-received-up-to)为:2
在Token的重传请求列表(rtr)中记录了未收到的消息序号:3

ØP3收到token后，向集群广播M3，清除token的rtr后，把token传给P4



ØP2收到P3广播的消息M3,

其它节点乎略消息M3
ØP4收到P3传过来的token，没做任务事情，把token传给P1



ØP1收到P4传过来的token，没做任务事情，把token传给P2



ØP1收到P4传过来的token，没做任务事情，把token传给P2
ØP2发现token中的aru_id是它自己，并且知道自己已经收到M3，
所以它更新token中的aru为3，至此P2知道集群的所有节点都收到了M3M2M1

ØP2把更新后的token传给P3



满足Agreed/Safe Order么？

•AgreedOrder
–在token的上述传递过程中，拿到token的Processor，把已接收到的消息按次序传递给Application，则满足Agreed

Order。
•SafeOrder
在token的上述传递过程中，如果连续两次转发的token的aru大于等于某个消息的序号，则把该消息传递给Application时满足Safe

Order。

与OP协议相关的Corosync选项

•token_retransmit
–Processor在转发完token后，在多长时间内没有收到token或消息后，将引发token重传。
–默认值：238ms
–如果设置了下面的token值，本值由程序自动计算。
•token
–Processor在多长时间内没有收到token（中间包含token重传）后，将触发token丢失事件（将激活MembershipProtocol，进入Gather状态）。
–默认值：1000ms
本值等于Token在Ring中循环一圈的时间，这个时间取决了三个因素：结点数，结点之间的网络速率，每个结点在拿到token后可以发送的max_messages。

与OP协议相关的Corosync选项

•hold
–在Ring不怎么繁忙时，RingRepresentative在转发token前，休息多长时间。
–默认值：180ms
–本值通常由程序根据地其他选项自动计算。
•token_retransmits_before_loss_const
–Token最大重传次数
–默认值：重传4次
–若设置本值，token_retransmit和hold的值，由程序根据地本值和token值计算。
•fail_recv_const
–在多少次token循环中，没有收到任何消息（本该收到消息：token.seq>my_aru），超过这个次数将激活Membership

Protocol，进入Gather状态。
–默认值：2500次

TheMembership Protocol

•TheMembership Protocol（MP）：
–工作在Gather、Commit状态
–当有新的Processor加入或旧的Processor离开时，自动形成新的Single-Ring。

新加入一个节点示意图

Ø设P4为新加入的节点，旧环为{P1,P2,P3}，旧环的seq=100
旧环的三个结点都在各自的my_proc_set里记录了节点成员

ØP4加入集群后，广播一个join

msg。
ØP1,P2,P3收到join

msg后，进入Gather状态，根据msg的内容
做不同的动作



Ø当某个结点发现自己的my_proc_set中的所有成员都达到consensus后，
若它的id是成员中最小的id，则它发出一个CommitToken并进入commit状态，

CommitToken’sring_id.seq = max(old

ring_id and

JoinMsg’sring_id) + 4

Ø按照上面的过程，经过若干次JoinMsg的接收与转发，假设P1,P3,P4的
my_proc_set中的成员都已标记为consensus。

Ø设P2没有收到P3的JoinMsg，P2的consensus列表中consensus[P3]=false。

Ø上一张PPT讨论失败的情况，现在讨论正常的情况
Ø假设经过若干次JoinMsg的接收与转发，所有Processor的
my_proc_set中的成员都已标记为consensus。

ØP2接收到P1传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进入Commit状态

ØP3接收到P2传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进入Commit状态

ØP4接收到P3传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进入Commit状态

ØP1接收到P4传过来的Commit Token后，因为P1已处于Commit状态，
故P1知道此时所有成员，都已经进入了Commit状态。

ØP1第二次转发CommitToken，进入Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。

ØP2第二次转发CommitToken，进入Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。

ØP3第二次转发CommitToken，进入Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。

ØP4第二次转发CommitToken，进入Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。

Ø由于P4是新加入的结点，它的my_trans_memb只有它自己
Ø当P1第三次收到Commit Token时，所有结点都达到Reovery状态

与MP协议相关的Corosync选项

•join

•
–Processor在发送JoinMsg后，在多长时间内没有收到其他成员的JoinMsg，将引发JoinMsg重传。
–默认值：50ms

•send_join
–当Processor数量比较大时（>30），某个节点的加入/离开，可能造成各节点瞬间同时发出JoinMsg，造成网络拥塞。通过设置此值，程序发送JoinMsg前，将随机等待[0,send_join]区间内的某个时长。
–默认值：0ms

•consensus
–Processor从进入Gather状态起，在多长时间内必须使（my_proc_set-my_fail_set）集合的成员达到consensus（被标记为true）。否则清除已被标记为true的成员，重发JoinMsg。
–若设置此值，必须>=1.2*token。
–若未设置此值，程序将按1.2*token值处理。
–注：为了简化PPT的讲解，前面的PPT没有介绍my_fail_set（它用来保存OldRing中失效的节点）

TheRecovery Protocol

•TheRecovery Protocol（RP）：
–工作在Recovery状态
–从Old Ring过渡到New Ring的过程中，恢复属于（残缺的）Old Ring的消息（使它们满足Agreed或SafeOrder）。
–在Rcovery状态中，Application发到新Ring的消息，不会被广播（需要等到Operational状态）。

步实现Recovery

•Step1：
–与同属于相同的Old Ring的其它Processors交换消息（这个过程，与OP协议类似，不再详述）。
–同一个New Ring中，可能有多个Old Ring并存。
•Step2：
–把在本Processor的Old Configuration下，满足Agreed或Safe

Order的消息直接delivery给Application（message.seq<=high_ring_delivered）

•Step3：
–向Application传递第一个ConfingChangeMsg，即Transitional

Configuration。
–内含在New Ring中与本Processor同属于一个OldRing的成员列表。
•Step4：
–把在本Processor的Transitional Configuration下，满足Agreed或Safe

Order的消息delivery给Application（注意与Step2的区别）。

•Step3：
–向Application传递第一个ConfingChangeMsg，即Transitional

Configuration。
–内含在New Ring中与本Processor同属于一个OldRing的成员列表。
•Step4：
–把在本Processor的Transitional Configuration下，满足Agreed或Safe

Order的消息delivery给Application（注意与Step2的区别）。

•SRP的Flow Control Mechanism
–window_size:

在一次token的循环中，整个集群可以广播的最大的消息数。
–max_messages:

节点在拿到token后，可以广播的最大消息数。
–以上两个参数，也可以在Corosync中配置。

RPR协议简介

•工作原理
–基于SRP，RRP嵌入于SRP的网络层（相当于修改了SRP的recv/send函数）
–通过使用冗余网络把多个节点连接起来，可容忍网络的损坏

RPR的三种Replication Styles

•Active replication
–所有消息都同时发送到N个冗余网络。
–每个消息都被接收N次。
–Processor的带宽消耗随着N的增大而减少。
•Passive replication
–所有消息只发送到N个冗余网络的其中一个。
–每个消息都只被接收到一次。
–Processor的带宽消耗与Sing-Ring相同。
•Active-passive replication
混合模式，所有消息都同时发送到K（1<K<N,例如为3）个冗余网络。

•rrp_mode
–ReplicationStyle。
–可能的值：none, active, passive。
–目前corosync还不支持active-passive混合模式。
•rrp_token_expired_timeout
–在多长时间内，没有从任意一个冗余网络中收到token，则把ProblemCounter增1。
–默认值：47ms。

•rrp_problem_count_timeout
–在多长时间内，如果某个网络没被标记为faulty，则把ProblemCounter减1。
–默认值：2000ms。
•rrp_problem_count_threshold
–当ProblemCounter达到某个值后，则把某个网络标记为faulty。
–本值*token_expired_timeout<=(token-50ms)
–默认值：10