CCM爲集羣成員的服務提供強有力的鏈接，它確保了每個計算節點與其他節點的有效通訊。 CCM同時實現了OCF draft membership API和the SAF AIS membership API。通常情況下，它的成員間計算只需要亞秒級。
補充：SAF AIS membership API 來源日誌：http://blog.csdn.net/xrb66/article/details/6046034
對AIS有兩種開源實現，一種是openSAF，另外一種是openAIS。這兩種實現都是用C語言開發的。接下來我們主要分析openAIS對規範的實現。
OpenAIS主要分爲三個部分，他們是openAIS業務框架，組播通信系統和業務，其中業務包括SAF中定義的標準業務，同時，也包含自定義的業務。我們接下來對這三部分進行簡要分析。
openAIS業務框架，他是整個openAIS開發的基礎，所有的業務都是構建在這個框架之上的，它定義了每種業務應該遵循的標準接口，以便框架根據一定的規則回調這些標準的接口。業務開發者，只需要實現具體業務邏輯，並且以動態鏈接庫的形式進行發佈即可，業務的加載，調用和卸載都由openAIS框架來完成，換句話說，這個框架對業務的生命週期進行了管理。加載業務時，框架只需根據環境變量所定義的搜索路徑，對動態鏈接庫進行搜索，並採用動態加載庫（dl庫），運行時動態加載業務邏輯。業務的調用，框架會根據業務類型，以及對應的消息標識符通過查找業務邏輯映射表，進行業務邏輯的調用。業務的卸載，當openAIS守護進程終止或者收到動態卸載業務指令後，框架會利用運行時動態鏈接庫函數，對業務進行卸載。
組播通信系統，他是整套系統的通信基礎。openAIS適用於cluster環境的應用，他爲在這個cluster環境中的各種應用程序提供了通知，協作和保護的功能。由於消息的組播是建立在UDP/IP的基礎上的，如何保證消息可靠並且高效的傳遞到在cluster環境下的其他節點呢？我們知道UDP是一種高效的協議，但是他並不提供可靠的傳輸，因此，openAIS實現了一套RRP（Redundant ring protocol）。該協議可以保證建立在不可靠傳輸基礎上的數據的傳遞的可靠性。並且這套協議很適合分佈式計算環境的應用，不僅爲分佈式計算環境提供了數據的可靠性傳輸，同時也提供了對數據的備份方法。我們知道，一般做redundancy是在節點之間，或者是同一節點不同應用之間，而這種協議提出，這種redundancy是在兩個局域網之間。提供網絡數據的備份，提供分佈式計算環境的數據傳輸的備份。在很大程度上保證了系統的健壯性。現在，大概講講RRP協議，該協議主要由兩部分組成，第一部分探討了在同一個cluster網絡環境中，數據傳輸的唯一性，可靠性以及不存在競態。第二部分探討的是如何在兩個或者多個網絡間進行數據備份。我們先來看看第一部分，在同一個cluster網絡中，存在一個令牌，這個令牌採用單播的方式進行傳輸，當cluster中某個節點獲取了這個令牌之後，才具有組播消息的權限，這個時候他會將令牌中攜帶的計數器加1後付值給將要向局域網組播的消息的消息頭，之後將該消息組播出去，接着，該節點負責將令牌傳遞給下一個節點。以此類推。這樣就能保證在cluster環境中組播的消息是唯一的，並且消息是由消息頭中的序列號字段來標識的。同時，當下一個節點拿到令牌後，可以根據令牌中的消息計數器來判斷局域網中組播的消息是否有丟失，如果有，可以申請重傳。另外一部分討論瞭如何在局域網間進行數據備份，協議提供了三種方式，他們是passive，active和passive-active。Passive模式，假如目前有N個redundant network用於數據備份，當working network中某個節點拿到令牌後，需要從這N個網絡中選擇一個，並將組播消息和令牌發送一份到該網絡中去，網絡的選擇採用RR算法（Round-Robin）。Active模式，節點將組播消息和令牌同時發送到所有網絡。Active-passive模式，從N個redundant network中，選擇一個子集K，將消息和令牌發送到這個子集中的所有網絡。下層所做的redundancy對於上層應用來說是完全透明的，上層應用並不知道目前所獲取的消息是來自於哪個物理網絡。
OpenAIS的業務部分，目前提供了遵循SAF規範的業務的實現（AMF，CLM，Event，Message，Lock和check point等），同時也提供了openAIS的一些補充業務，比如configuration。對於業務的實現，值得一提的是check point service，因爲目前在實現一套用來做主備倒換中數據備份的一套系統。對於check point service來講的話，他的所有備份數據，在所有節點上都保留了一份，這樣的話，對於某些數據量很大，並且內存吃緊的應用來說的話，是不適合。比如AGW中，一個session佔有8k數據，一張卡所提供的用戶容量假如是10萬，按照這樣計算，內存消耗都是相當大的。所以經過考慮，不採用check point service提供這種功能。目前，打算直接在兩個應用進程之間進行數據拷貝，這樣在很大程度上節約了內存，不過帶來的問題是，如何保證在不影響應用進程業務邏輯正常工作的情況下，進行數據備份的工作？
