OpenClovis应用服务平台（ASP）和基成化开发环境（IDE）帮助网络设备厂商快速经济地在它们的下一代通信产品中实现平台可管理性和高可靠性。OpenClovis ASP提供了一个遵循标准的、具有高度可靠性和可管理性的off-the-shelf软件解决方案。OpenSAF，一个开发高可用性中间件的开源项目。本文比较了二者的异同。
1. Active System Controller
openClovis使用GMS（Group Membership Service）进行Active System Controller选举。当Cluster的一个Node进入、退出服务，整个Cluster将会触发一次Leader election，选举出Active System Controller和Deputy System Controller。理论上Cluster内所有节点都可以承担Active System Controller的角色，但在实际应用中，Payload Node的Credential为0，不能成为Active System Controller。如果选举产生的Active System Controller或者Deputy System Controller发生改变，Cluster内所有节点都将收到广播通知，并更新System Controller的通信地址。如果Deputy System Controller发生改变，则新任的Deputy System Controller将从Active System Controller快速同步，保证内部信息与Active System Controller保存的信息一致。
cli[Test:SCNodeI0:gms]-> memberList 0
--------------------------------------------------------------------------------------------------------
Cluster/Group Name : cluster0
bootTime : Mon Dec 15 17:22:28 2008
View Number : 6
--------------------------------------------------------------------------------------------------------
NodeId NodeName HostAddr Port Leader Credentials PrefLead LeadshipSet BootTime
--------------------------------------------------------------------------------------------------------
1 SCNodeI0 1 9 Yes 100 No No Mon Dec 15 17:22:28 2008
2 SCNodeI1 2 9 No 100 No No Tue Dec 16 01:24:56 2008
3 PayloadNodeI0 3 9 No 0 No No Mon Dec 15 17:23:53 2008
4 PayloadNodeI1 4 9 No 0 No No Mon Dec 15 17:27:22 2008
openSAF使用RDE（Role Distribution Entity）决定Active System Controller和Deputy System Controller。充当System Controller的Node必须预先固定，并修改配置文件
File Path: /etc/opt/opensaf/rde.conf
Typical entries in a rde.conf are:
export CONTROLLER1=10.232.92.160
export CONTROLLER2=10.232.92.206
export RDE_PORT_NUMBER=5003
| Entries | Description |
| CONTROLLER1 | Enter the IP address of one controller |
| CONTROLLER2 | Enter the IP address of another controller . |
| SERVERPORTNUM | RDE uses this port for its TCP communication with its peer RDE. |
点评：openClovis使用Leader election的方式较openSAF固定System Controller节点的方式要好一些。不仅减少了系统配置，而且可以实现多个Deputy System Controller备份，增强了系统的可靠性。
2. 消息通信
openClovis使用TIPC（Transparent Inter-Process Communication）作为底层通信协议，并在TIPC之上进行封装，向上层应用提供IOC（Intelligent Object Communication）。
openClovis的IOC提供二种通信地址方式：
A. Physical Address
在一个Node中最多存在1024个“Service PortId”，整个Cluster最多存在1024个Nodes，因此在Cluster中最大通信Instance为1024 x 1024，通过一个128K的共享内存描述各个通信Instance之间的路由关系（Bitmap中1为可达，否则为0）。
Port Naming : Port name typically denoted as {type, instance}
Node之间通信地址：
Bind Port Naming {0x100+ Service PortId , slotNo}
Node内部通信地址
Bind Port Naming {0x4000000+ slotNo, Service PortId}
B. Logical Address
Logical Address通常用于HA 1+1地址绑定。只有Master服务进程才能绑定特定的Logical Address。通过逻辑地址机制，在Cluster内提供唯一的通信地址，保证在HA切换后，通信不会中断。
Bind Port Naming {0x1000000，Service PortId}
Bind Port Naming {0x3000000+Service PortId，slotNo}
openSAF同样使用TIPC作为底层通信协议，通过封装TIPC向上提供MDS（Message Distribution Service）。
MDS Addresses涉及的概念较多，主要地址模式有下面几种：
<PWE-id, ADEST, Service-id>
<PWE-id, VDEST-id, Service-id>
<PWE-id, <VDEST-id, VDEST-qualifier>, Service-id>
由于openSAF的MDS代码较多，实现算法复杂，具体实现细节有待深入研究。
点评：openClovis的IOC通信机制简单，相关的代码总行数是8K行左右，封装比较薄，容易理解，方便日常修改、维护。openSAF的MDS+VDS代码总行数在28K行左右，代码量较多，而且有众多的概念，代码不太容易理解。
3. CheckPoint Server
openSAF使用MBCSv(Message Based Checkpointing Service)为Active System Controller和Standby System Controller之间进行信息同步。其他应用程序则使用SAF定义的Checkpoint Service进行信息通过。
openClovis只有一种Checkpoint Service。无论是System Controller还是其他应用程序的信息同步都使用同样的Checkpoint Service。
点评：openSAF提供了MBCSv，为应用程序提供了一种新的同步机制，可以给程序开发提供更多的选择。但同时也增大了代码的维护工作量。MBCSv的代码总行数在10k左右。
| Project | Checkpoint Service | MBCSv |
| openSAF | 42183 | 10864 |
| openClovis | 64151（29810行代码由IDL工具自动生成，无需维护，实际代码行数为34341行） | N/A |
除去代码工具自动生成的代码，openClovis的CheckPoint Service代码总行数较openSAF要少8k行左右。
4. 体系结构
openSAF采用2- Tier或3- Tier结构。总体结构为Agent—Node Director—SC Director，应用程序的请求通过消息的方式发送到本节点的Node Director，再由Node Director根据功能需求是否转发到SC Director。大部分决策动作由SC(System Controller)完成，并将结果逐层返回给调用者。SC采用1+1备份方式，SC之间通过MBCSv(Message Base Checkpoint Service)完成数据同步。
openClovis采用Client/Server的结构，通过RMD (Remote Method Dispatch )，一种类似RPC的调用方式，完成功能服务函数的调用。RMD可以跨进程、跨节点完成功能函数的调用。RMD调用的参数通过IDL(Interface Definition Language)进行描述。IDL代码生成工具根据参数描述XML文件，自动生成相应的代码。openClovis有二个SC(System Controller)，采用1+1备份方式。
openClovis CheckPoint Open
openSAF CheckPoint Open
5. RMD(Remote Method Dispatch )
RMD (Remote Method Dispatch )是openClovis特有的代码实现模式，一种类似RPC的调用方式，完成功能服务函数的调用。RMD可以跨进程、跨节点完成功能函数的调用。
应用程序可以使用RMD请求Cluster中另一台计算机上某程序的服务而不需知道网络细节。RMD使用Client/Server模型。请求程序是Client，而服务提供程序则为Server。就像一般的本地函数调用一样，RMD可以是一个同步操作，直到远程过程结果返回请求程序才可以挂起；也可以是一个异步操作，当异步操作完成后，调用注册的回调函数通知调用者RMD操作已经完成。
RMD：工作原理
运行时,一次客户机对服务器的RMD调用,其内部操作大致有如下步骤：
1) 调用客户端句柄；将传送参数根据预定规则XDR进行消息打包
2) 调用IOC发送网络消息，通过Linux内核的TIPC将消息发送到Server
3) 消息传送到远程主机
4) Server得到消息，对消息根据预定规则XDR进行解包，取得调用参数
5) Server执行本地的服务函数
6) Server返回结果，将执行结果根据预定规则XDR进行消息打包，调用TIPC发送网络消息
7) 消息传回本地主机
8) Client通过TIPC接收消息，消息根据预定规则XDR进行解包，取得返回的数据
XDR（External Data Representation）外部数据表示
XDR提供了一种与体系结构无关的表示数据，解决了数据字节排序的差异、数据字节大小、数据表示和数据对准的方式。使用XDR的应用程序，可以在异构硬件系统上交换数据。使用XML文件描述XDR的编码和解码规则，通过分析XML文件，可以自动生成相关的接口代码，大大较轻了开发工作量。
由于mSwitch的实现代码存在一部分模块间函数同步调用过程，如取网管的配置数据，取板块的槽号，取机框号等函数。这些函数可以通过封装使用RMD的方式实现，大大减轻了这部分代码的移植工作量。
点评：整个openClovis都是建立在RMD之上。通过RMD屏蔽了消息调用，向应用呈现了函数调用接口，增强了代码的可读性。openSAF则是使用消息调用的方式，应用程序需要关心消息的打包、解包过程，过程比较繁琐，增加了代码维护工作量。同时对一些在移植过程中需要的同步函数调用，需要重新开发，工作量较大。
6. Log Service
openClovis不支持SAI-AIS-LOG定义的接口，但有提供类似的功能函数。openClovis提供二种类型的log Stream
enum ClLogStreamScopeT {
CL_LOG_STREAM_GLOBAL = 0,
CL_LOG_STREAM_LOCAL = 1 }
Local Log Stream
A Log Stream local to one node. This stream is not visible for Logging on any other node in the system. Components running on the same node only can log into this stream. But consumers on any node can consume this Log Stream.
Global Log Stream
A Log Stream visible in the cluster. Any component in the cluster can log into this stream.
openSAF的Log Service支持SAI-AIS-LOG-A.02.01，整体结构如下：
扫一扫
3358
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
