随笔-111  评论-9  文章-0 

Totem协议(SRP/RRP)讲解

基本概念

SRP:  The Totem Single-Ring Ordering and MembershipProtocol
           –基于以太网的组通信协议,节点间组成单环结构
           –所有数据都采用UDP广播(message)、单播(token)
           –消息的可靠性和有序性,基于token-passing实现
           –每个节点都接收到同样的消息序列,故可容忍消息丢失、节点崩溃
 
RRP:  The Totem Redundant Ring Protocol
          –基于SRPRRP嵌入于SRP的网络层(相当于修改了SRPrecv/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 ProtocolOP):
确保消息从Single-Ring中传播,到最终传递给Application时,满足Agreed OrderSafeOrder
The Membership ProtocolMP):
当有新的Processor加入或旧的Processor离开时,自动形成新的Single-Ring
The Recovery ProtocolRP):
Old Ring过渡到New Ring的过程中,恢复属于(残缺的)Old Ring的消息(使它们满足AgreedSafeOrder)。
 
SRP的四个状态
 
 
子协议与状态的关系
TheTotem Ordering ProtocolOP):
工作在Operational状态
TheMembership ProtocolMP):
工作在GatherCommit状态
TheRecovery ProtocolRP):
工作在Recovery状态
 
TheTotal Ordering Protocol
TheTotem Ordering ProtocolOP):
工作在Operational状态
确保消息从Single-Ring中传播,到最终传递给Application时,满足Agreed OrderSafeOrder
Application在发送消息时,指定采用Agreed还是Safe方式。
通过token,以“丢手绢”的方式,实现消息的有序传递。
 
消息传播示意图
ØA1请求P1依次广播三个消息:M1, M2, M3,这些消息暂存在P1的请求队列中
Ø假设P1已拿到tokenP1向集群依次广播:M1,M2,M3
ØP1广播的消息,也会保存在它自己的接收队列中
 
 
消息传播示意图
 
ØP2只收到两个消息M2M1,P3,P4完整的收到三个消息M3M2M1
ØP1Token传递给P2Token中记录了P1接收队列中消息的max
seq:3
ØP2通过比较Token中的seq,发现自己没有接收到M3
 
 
 
消息传播示意图
ØP2token传给P3,更新tokenaru(all-received-up-to):2

      Token的重传请求列表(rtr)中记录了未收到的消息序号:3

ØP3收到token后,向集群广播M3,清除tokenrtr后,把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中的aru3,至此P2知道集群的所有节点都收到了M3M2M1

ØP2把更新后的token传给P3
 
满足Agreed/Safe Order么?
AgreedOrder
token的上述传递过程中,拿到tokenProcessor,把已接收到的消息按次序传递给Application,则满足Agreed
Order
SafeOrder

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

 
OP协议相关的Corosync选项
token_retransmit
Processor在转发完token后,在多长时间内没有收到token或消息后,将引发token重传。
默认值:238ms
如果设置了下面的token值,本值由程序自动计算。
token
Processor在多长时间内没有收到token(中间包含token重传)后,将触发token丢失事件(将激活MembershipProtocol,进入Gather状态)。
默认值:1000ms

本值等于TokenRing中循环一圈的时间,这个时间取决了三个因素:结点数,结点之间的网络速率,每个结点在拿到token后可以发送的max_messages

 
OP协议相关的Corosync选项
 
hold
Ring不怎么繁忙时,RingRepresentative在转发token前,休息多长时间。
默认值:180ms
本值通常由程序根据地其他选项自动计算。
token_retransmits_before_loss_const
Token最大重传次数
默认值:重传4
若设置本值,token_retransmithold的值,由程序根据地本值和token值计算。
fail_recv_const
在多少次token循环中,没有收到任何消息(本该收到消息:token.seq>my_aru),超过这个次数将激活Membership 
Protocol,进入Gather状态。
默认值:2500
 
TheMembership Protocol
TheMembership ProtocolMP):
工作在GatherCommit状态
当有新的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没有收到P3JoinMsgP2consensus列表中consensus[P3]=false
 
 
 
Ø上一张PPT讨论失败的情况,现在讨论正常的情况
Ø假设经过若干次JoinMsg的接收与转发,所有Processor

    my_proc_set中的成员都已标记为consensus

ØP2接收到P1传过来的Commit Token后,更新memb_listmemb_idx

    转发Commit Token,并进入Commit状态

 

ØP3接收到P2传过来的Commit Token后,更新memb_listmemb_idx

    转发Commit Token,并进入Commit状态

 

ØP4接收到P3传过来的Commit Token后,更新memb_listmemb_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 ProtocolRP):
工作在Recovery状态
Old Ring过渡到New Ring的过程中,恢复属于(残缺的)Old Ring的消息(使它们满足AgreedSafeOrder)。
Rcovery状态中,Application发到新Ring的消息,不会被广播(需要等到Operational状态)。
 
步实现Recovery
Step1
与同属于相同的Old Ring的其它Processors交换消息(这个过程,与OP协议类似,不再详述)。
同一个New Ring中,可能有多个Old Ring并存。
Step2
把在本ProcessorOld Configuration下,满足AgreedSafe
Order的消息直接deliveryApplicationmessage.seq<=high_ring_delivered
 
Step3
Application传递第一个ConfingChangeMsg,即Transitional
Configuration
内含在New Ring中与本Processor同属于一个OldRing的成员列表。
Step4
把在本ProcessorTransitional Configuration下,满足AgreedSafe
Order的消息deliveryApplication(注意与Step2的区别)。
 
Step3
Application传递第一个ConfingChangeMsg,即Transitional
Configuration
内含在New Ring中与本Processor同属于一个OldRing的成员列表。
Step4
把在本ProcessorTransitional Configuration下,满足AgreedSafe
Order的消息deliveryApplication(注意与Step2的区别)。
 
SRPFlow Control Mechanism
window_size:
在一次token的循环中,整个集群可以广播的最大的消息数。
max_messages:
节点在拿到token后,可以广播的最大消息数。
以上两个参数,也可以在Corosync中配置。
 
RPR协议简介
工作原理
基于SRPRRP嵌入于SRP的网络层(相当于修改了SRPrecv/send函数)
通过使用冗余网络把多个节点连接起来,可容忍网络的损坏
 
RPR的三种Replication Styles
 
Active replication
所有消息都同时发送到N个冗余网络。
每个消息都被接收N次。
Processor的带宽消耗随着N的增大而减少。
Passive replication
所有消息只发送到N个冗余网络的其中一个。
每个消息都只被接收到一次。
Processor的带宽消耗与Sing-Ring相同。
Active-passive replication

混合模式,所有消息都同时发送到K1<K<N,例如为3)个冗余网络。

 
 
rrp_mode
ReplicationStyle
可能的值:none, active, passive
目前corosync还不支持active-passive混合模式。
rrp_token_expired_timeout
在多长时间内,没有从任意一个冗余网络中收到token,则把ProblemCounter1
默认值:47ms
 
rrp_problem_count_timeout
在多长时间内,如果某个网络没被标记为faulty,则把ProblemCounter1
默认值:2000ms
rrp_problem_count_threshold
ProblemCounter达到某个值后,则把某个网络标记为faulty
本值*token_expired_timeout<=(token-50ms)
默认值:10
 
posted on 2015-10-26 16:48 BFP 阅读(...) 评论(...) 编辑 收藏