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