我是靠谱客的博主 深情小刺猬,最近开发中收集的这篇文章主要介绍2.2. Cluster Consensus Membership,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

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提供这种功能。目前,打算直接在两个应用进程之间进行数据拷贝,这样在很大程度上节约了内存,不过带来的问题是,如何保证在不影响应用进程业务逻辑正常工作的情况下,进行数据备份的工作?




 

最后

以上就是深情小刺猬为你收集整理的2.2. Cluster Consensus Membership的全部内容,希望文章能够帮你解决2.2. Cluster Consensus Membership所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(41)

评论列表共有 0 条评论

立即
投稿
返回
顶部