CN102707951A

CN102707951A - 一种异构平台上高可用系统的设计方法

Info

Publication number: CN102707951A
Application number: CN2012101289698A
Authority: CN
Inventors: 谢若鸿; 吴楠
Original assignee: Inspur Electronic Information Industry Co Ltd
Current assignee: Inspur Electronic Information Industry Co Ltd
Priority date: 2012-04-28
Filing date: 2012-04-28
Publication date: 2012-10-03

Abstract

本发明提供了一种在异构平台上实现系统高可用的设计方法，该方法通过为异构平台高可用系统设计尽可能使用相同的架构、对可扩展的模块使用动态链接库、对与应用有关的模块使用脚本语言编写、适当减少对应用程序接管的考虑并将系统实现层次限定为用户层的方式，实现了异构平台上的高可用系统，填补了市场上缺乏异构平台高可用系统的空白。

Description

一种异构平台上高可用系统的设计方法

技术领域

本发明涉及一种计算机高可用系统技术`，具体的说是一种基于异构平台的高可用系统的设计方法。

背景技术

在今天的商务应用系统中，系统的稳定持续的运行变得越来越重要，由于计算机系统和硬件都不可能完全消除故障的发生，而这些故障如果没有给予相应的修复和挽救措施，将给企业带来极大的损失，所以市场对高可靠性的系统的需求将变得非常迫切，特别是金融、电信等对高可靠服务器产品有特殊需求的应用领域。这就需要一个高可用的环境，保证当正在提供服务的机器宕机或者发生故障之后，另外的机器可以在短时间内接管服务，并且保证能够把出现问题的机器自动启动，使其恢复到初始状态。

高可用系统的目的就是为了给用户提供一个可靠的运行环境，可用由两台以上的服务器组成一个高可用集群，高可用系统会对集群中的各种应用、资源及系统状态等进行监控，当发现某台服务器上出现系统异常（如宕机、网络链接中断等）时，将其上运行的应用切换到别的服务器上，并隔离出现故障的服务器，而且在整个切换过程中，不需要任何的人为干预，保证用户使用的连续性。

目前市场上虽然有很多高可用的产品，但都只能在同构的服务器上使用，在需要扩大系统规模时，不能方便的增加与现有系统架构不同的服务器。异构的高可用系统会遇到的主要问题有：

1) 编译环境差别。各平台的编译器会存在差别，虽然可能都遵循ISO/ANSI标准，但遵守的严格程度存在一些差异。编译器的调用使用方面也存在很多差异，比如AIX链接器使用扩展的通用目标文件格式（XCOFF格式），LINUX链接器采用可执行可链接格式（ELF格式），因此在编写不同平台上的高可用系统时，需要针对其编译环境做相应的调整；

2) 系统I/O差别。高级I/O操作select()需要注意平台间的兼容性。比如在AIX上select()函数用于用户I/O复用的同时还提供异常和事件处理，但Linux上的事件和异常通知必须同时使用sigprocmask系统调用；

3) 网络通信差别。由于不同的平台采用的字节序不同，因此在不同架构的机器进行网络通信传递数据时，可能一部分平台需要字节序的转换，一部分平台则不需要；

4) 应用程序差别。高可用系统需要对服务器上的各种用户应用程序进行监控，不同的系统上的系统实现的差异体现在：面向对象或面向过程的设计思路选择，进程通信方式的选择，编程语言的选择等；

5）其他进程间通信方式和系统API差别。包括信号机制、消息队列、套接字、管道等，各个平台存在差异。

发明内容

本发明的目的是提供一种异构平台上实现高可用系统的设计方法。

本发明的目的是按以下方式实现的，本发明的技术方案是：

1）为异构平台高可用系统设计尽可能使用相同的架构：

对不同的平台设计相同的架构可以减少大量的编码时间，同时降低系统复杂度。对不同的系统平台来说，在操作系统层面最大的区别主要是系统库的区别而导致的系统接口的区别，在设计阶段即考虑各个平台系统库的区别，根据这些区别设计出尽可能能够满足双方系统要求的架构，极大的减少了系统的复杂度，显著减少了开发周期；

2）对可扩展的模块使用动态链接库：

由于高可用系统的一些模块实现可能依赖与具体平台（比如在操作底层的设备文件时，ioctl函数在AIX与Linux平台上并不兼容），对这些模块采取动态链接库的方式，可以在保证系统的主体功能的前提下，针对各个平台开发相应的功能模块；

3）对与应用有关的模块使用脚本语言编写：

可降低对底层架构的依赖；

4）适当减少对应用程序接管的考虑：

由于不同系统的应用系统特性可能不完全相同，比如，应用程序异构性的体现之一是应用程序是否对用户透明，即用户是否知道系统内部的运行状态，抑或只能接受应用程序所提供的功能与服务，在不同平台上的设计可能不同。在系统具有较强扩展性的情况下，按需设计必要的应用系统接管，可以降低系统的复杂性；

5）系统实现层次限定为用户层：

对Linux系统来说，程序运行在内核层可以获得更多的特权，对主机状态能够做出更精确的判断，但对异构系统来说，而Unix之类的操作系统基本为闭源系统，无法进入系统内核态。故为了最大限度保证异构高可用系统的通用性，将高可用系统的一切实现都放置在用户层。

本发明的有益效果是：

该方法通过为异构平台高可用系统设计尽可能使用相同的架构、对可扩展的模块使用动态链接库、对与应用有关的模块使用脚本语言编写、适当减少对应用程序接管的考虑并将系统实现层次限定为用户层的方式，实现了异构平台上的高可用系统，填补了市场上缺乏异构平台高可用系统的空白。

附图说明

图1是异构平台高可用系统的整体架构图。

具体实施方式

参照附图对本发明的方法作以下详细的说明：

如附图所示，本发明的高可用系统架构整个系统结构可分为四层，具体是消息传递层、成员层、资源管理层和资源层；

1. 消息层

通常也称为Heartbeat层，集群内所有节点间的消息传递均需通过该层，同时，该层还将监控各个节点间的连通状态，并将其通知CCM（Consensus Cluster membership，一致性成员资格。用于确定组成集群的成员节点，并在集群中分享这些成员的信息，任何节点的并更都由CCM来决定）；

Heartbeat支持串口、单播、多播和广播等多种方式，使用通用的协议类型，通过管道的形式在集群各个节点之间进行通信。节点会通过Heartbeat定期将自己的状态发送给集群中的其他节点，同时接受来自其他各节点的状态信息；

2. 成员层

基于Heartbeat层提供的信息，负责计算集群中最大的连通集合，确定哪些节点属于集群，并将这一信息在各个集群成员中同步，这一工作由CCM模块来完成；

3. 资源分配层

对资源进行分配，由以下的组件组成：

集群资源管理器（CRM）：

在资源分配层中执行的每个操作都要经过集群资源管理器。如果本层或更高层中的组件之间需要通讯，均需经过本地CRM。在每个节点上，CRM维护一个集群信息库（CIB），如果当前节点为DC，则它拥有主CIB；

集群信息库（CIB）

用XML的方式来存储整个集群和当前状态的配置。它包括所有集群选项、节点、资源及其关系和当前状态的定义。CIB会自动的将更新同步到所有集群节点上，集群中有一个主CIB，由主CIB的节点DC维护，其他所有节点上均包含一个CIB复本；

策略引擎PE和转换引擎TE

每当主CIB的节点DC需要进行整个集群的更改时，策略引擎就会根据集群的当前状态和配置来计算集群的下一个状态，并由TE来执行。主CIB的节点DC将会将消息发送给集群中相关的CRM，CRM会调用LRM来执行必要的操作。PE和TE始终在DC上运行；

主CIB的节点DC是Designated Coordinator的缩写，即指定协调程序，它指的不是某种特定的设备，而是具有主CIB的节点，这个节点相当于集群的控制节点，只有该节点才拥有对整个集群执行更改（比如屏蔽某个节点，或是移动资源）的决定权；

本地资源管理器（LRM）

LRM代表CRM调用本地资源代理，具体的说，它可以执行启动、停止、监视资源状态等操作，并将结果报告给CRM。LRM还将隐藏资源代理支持的不同脚本标准之间的差别，便于在不同平台上对资源进行管理；

4. 资源层

包括一个或多个资源代理（RA），仅由LRM调用。资源代理指为启动、停止或指控服务状态而编写的程序，以Shell脚本的形式实现，最大程度上避免底层架构的影响。同时，如果用户需要第三方程序，可自行编写符合标准的脚本放在指定位置，供高可用系统调用。

除说明书所述的技术特征外，均为本专业技术人员的已知技术。

Claims

1.一种异构平台上实现系统高可用的设计方法, 其特征在于内容包括：

1）异构平台系统的高可用设计尽可能使用相同的系统架构：在设计阶段要考虑各个平台系统库的区别，根据这些区别设计出尽可能能够满足双方系统要求的系统架构，尽量减少了系统的复杂度，减少开发周期；

2）对可扩展的模块使用动态链接库：由于高可用系统的一些模块实现可能依赖于具体平台，对这些模块采取动态链接库的方式，在保证系统的主体功能的前提下，针对各个平台开发相应的功能模块；

3）对与应用有关的模块使用脚本语言编写以降低对底层架构的依赖；

4）适当减少对应用程序接管的考虑：在系统具有较强扩展性的情况下，按需设计必要的应用系统接管，降低系统的复杂性；

5）系统实现层次限定为用户层：为最大限度保证异构高可用系统的通用性，将高可用系统的一切实现都放置在用户层；

具体实施步骤如下：

实现系统架构的高可用，整个系统结构分为消息传递层、成员层、资源管理层和资源层，其中：

1）消息层

通常也称为Heartbeat层，集群内所有节点间的消息传递均需通过该层，同时，该层还将监控各个节点间的连通状态，并将其通知一致性成员资格CCM，一致性成员资格CCM用于确定组成集群的成员节点，并在集群中分享这些成员的信息，任何节点的并更都由CCM来决定；

Heartbeat支持串口、单播、多播和广播多种方式，使用通用的协议类型，通过管道的形式在集群各个节点之间进行通信，节点会通过Heartbeat定期将自己的状态发送给集群中的其他节点，同时接受来自其他各节点的状态信息；

2）成员层

3）资源分配层

对资源进行分配，由以下的组件组成：

（1）集群资源管理器CRM：

在资源分配层中执行的每个操作都要经过集群资源管理器CRM，如果本层或更高层中的组件之间需要通讯，均需经过本地集群资源管理器CRM，在每个节点上，集群资源管理器CRM维护一个集群信息库CIB，如果当前节点为DC，则它拥有主CIB；

（2）集群信息库CIB

用XML的方式来存储整个集群和当前状态的配置，它包括所有集群选项、节点、资源及其关系和当前状态的定义，集群信息库CIB会自动的将更新同步到所有集群节点上，集群中有一个主集群信息库CIB，由主CIB的节点DC维护，其他所有节点上均包含一个集群信息库CIB复本；

（3）策略引擎PE和转换引擎TE

每当主CIB的节点DC需要进行整个集群的更改时，策略引擎就会根据集群的当前状态和配置来计算集群的下一个状态，并由TE来执行，主CIB的节点DC将会将消息发送给集群中相关的CRM，CRM会调用LRM来执行必要的操作，策略引擎PE和转换引擎TE始终在主CIB的节点DC上运行；

主CIB的节点DC是Designated Coordinator的缩写，即指定协调程序，它指的不是某种特定的设备，而是具有主CIB的节点，这个节点相当于集群的控制节点，只有该节点才拥有对整个集群执行更改的决定权，包括屏蔽某个节点或是移动资源的更改决定权；

（4）本地资源管理器LRM

本地资源管理器LRM代表集群资源管理器CRM调用本地资源代理，具体的说，它可以执行启动、停止、监视资源状态等操作，并将结果报告给集群资源管理器CRM，本地资源管理器LRM还将隐藏资源代理支持的不同脚本标准之间的差别，便于在不同平台上对资源进行管理；

4）资源层

包括一个或多个资源代理RA，仅由本地资源管理器LRM调用，资源代理RA指为启动、停止或指控服务状态而编写的程序，以Shell脚本的形式实现，最大程度上避免底层架构的影响，同时，如果用户需要第三方程序，可自行编写符合标准的脚本放在指定位置，供高可用系统调用。