转：应用级集群系统的设计(上)
集群系统在企业 IT 应用中的部署越来越广泛，基于某个具体业务的应用级集群服务系统也越来越得到重视，围绕这个主题，本文简要地探讨了应用级集群一般性的设计思路，重点针对分层业务资源、业务资源监测器、负载均衡器和故障转移管理器等四部分。
集群类型
按集群系统的应用范围，大体可分为操作系统级集群和业务应用级集群。通常，操作系统级集群作为底层基础集群架构为业务应用级集群提供操作系统级的集群服务；而业务应用级集群则作为操作系统级集群的子集群，部署在操作系统级集群之上，完成特定业务的集群服务。
操作系统级集群
Linux 下主要的几个操作系统集群：
- LSF：通过网络将多个异构的集群体系相联系，共享计算资源 ，而用户则以透明的方式来访问这些资源。
- TurboCluster：是一个企业级软件集群系统解决方案，支持异构的网络环境。有较强的可用性和可扩展性。
- Linux Virtual Server：LVS 项目是国内章文嵩博士领导开发的 Linux 服务集群系统，它集合了集群技术和 Linux 操作系统内核实现了一个具有高伸缩性、高可靠性和高可管理性的集群解决方案，同时也为完成大访问量、可灵活部署、高可用的企业级集群系统的开发提供了一个 完美的架构。LSF、TurboCluster 和 LVS 三者类似，在体系中都部署了一个负责完成平衡访问负载的主控制机，由它来根据环境数据决定负载均衡策略完成整个访问请求的转发，内部核心处理部分基本上是 对外端客户完全透明的。
- MOSIX：与前三者对比有很大的不同，它没有一个单独的专用部件来完成访问请求的负载均衡，所有的服务器节点是都平等的和完全分布的。
- EDDIE：它由 HTTP 网关和特殊的 DNS 服务器组成，共同构成了一个分布式的 WEB 服务集群。
操作系统集群具备的基本特点：
- 提供强大的计算处理能力
- 提供高可用性的应用
- 提供可伸缩的软件硬件部署
- 提供对系统资源强大全面的调度与管理
业务应用级集群
业务应用级集群在继承操作系统级集群特性的基础上，重点集中在自身所支持的业务特性，也有自身的特点。
业务应用级集群基于具体的业务规则，它将关注焦点放在框架内运行的各个业务资源，以及资源内部或资源之间的业务数据流，结合事先定制的业务策略，进而做出符合业务的管理操作。
业务应用级集群对资源的管理与调度范围相对有限，局限于框架内部的组件；而对于框架之外的组件无能为力，须借助于底层的操作系统级集群的功能进行间接的管理。
业务应用级集群运行在操作系统集群之上作为其子部分，要接受操作系统集群的监管。
本文中讨论的内容就是基于 LVS 体系架构的业务应用级集群的开发。它提供针对对象生命周期的管理、差错检测、自我修复和自我迁移等功能。以下的章节介绍业务应用集群软件框架 BRMF（Business Resource Management Framework，业务资源管理框架）的设计。
  |
集群业务资源的设计
分析大多数的业务系统，我们都可以将其业务资源分为两类：形成业务特征的逻辑业务资源和最终执行业务服务运行的物理业务资源。对于这两类资源，往往 又以“部分”从属于“整体”的树形层次结构来展现，物理业务资源从属于逻辑业务资源，“从属”的关系决定了二者已具有功能上的一致性。其中，划分粒度的最 细单位为 BRU（Business Resource Unit，业务资源单元）；若干的 BRU 可以组成 BRG（Business Resource Group，业务资源组），每一个 BRG 就代表了一个完整的业务处理服务过程；若干个 BRG 可以组成一个 BRC（Business Resource Container，业务资源容器），形成一个服务节点。其中，BRU 属于物理业务资源，BRG 和 BRC 属于逻辑业务资源。
BRMF 框架采用严格的分层管理机制，至上而下来看，当前业务资源层只能对下一层的业务资源进行管理；至下而上来看，当前层业务资源层只能接受上一层的管理。总 之，只能在相邻的上下两层之间产生管理与被管理的关系，不允许纵向跨层管理，例如 BRC 不能对 BRU 直接进行管理；类似的，也不允许横向上的平层管理，即处于同一层次的业务资源不能相互管理，它们之间是平行且独立的关系，例如从属于 BRC_A 的 BRG_A 不能对从属于 BRC_B 的 BR_B 直接进行管理。如果 BRC 需要对 BRU 实施管理操作，BRC 就必須通过 BRU 所属的 BRG 进行管理指令的下达；对于 BRU 的回馈信息也只能层层上报，即 BRC 只能通过 BRG 才能了解相关的 BRU 的信息。如 表 1 所示为 BRMF 框架中业务资源部署结构。
表 1.BRMF 柜架业务资源部署结构图
| BRMF 框架业务资源层次部署结构 |
| — BRC_1（物理节点，IP: xxx.xxx.xxx.n） |
| — BRG_1 |
| — BRU_1 |
| — BRU_2 |
| — BRG_2 |
| — BRU_1 |
| — BRU_2 |
| — BRC_2（物理节点，IP: xxx.xxx.xxx.n+1，RC1 的冗余部署） |
| — BRG_1 |
| — BRU_1 |
| — BRU_2 |
| — BRG_2 |
| — BRU_1 |
| — BRU_2 |
| — BRC_3（物理节点，IP: xxx.xxx.xxx.n+2） |
| — BRG_1 |
| — BRU_1 |
| — BRU_2 |
BRU 表示处理业务服务的最细节过程，它是业务服务的直接载体，它与真实的业务之间表现为两种映射关系：
- 一对一关系，即一个 BRU 映射一个业务功能，它能独立的表示某个完整业务生命周期。这种关系下的 BRU 一般只能处理简单的业务服务。
- 多对一关系，这种关系下单一 BRU 只代表业务过程的一个片段，多个 BRU 之间相互依存，并协同处理某个复杂度较高的业务。
通过 BRU，我们可以看到真实的业务规则实施和业务数据流。每一个 BRU 都只从属某一个 BRG，接受 BRG 的管理。
BRG 实现了某个完整的业务生命周期。BRG 由若干 BRU 组合的方式来表现，这种方式更多的是体现出实际业务的逻辑性上，它是若干 BRU 业务逻辑集合的反映，与完整的真实业务功能呈现一对一的关系。BRG 的集合粒度可根据软硬件技术因素和业务规则等因素进行集合或拆分，可分为两种：
- 一般而言，简单的 BRG 体现出了 BRU 与业务之间的一对一关系，即一个 BRG 只集合了一个 BRU，此 BRG 负责处理某个较简单的业务；稍微复杂的 BRG 集合了若干（大于 1）个 BRU 协调处理较复杂的业务服务；
- 特殊情况下，若干 BRG 可以再次被集合形成一个体积更大功能含盖范围更广层次更高的 BRG，以便于表示更加复杂的业务。不过这种情况增加了业务资源的管理复杂度，特别是在发生故障需要做迁移操作时，所以不建议采用。为了在不影响业务服务 的前提下，避免这种情况的发生，可考虑重新选择业务资源的粒度进行划分。
在 BRG 的属性中，包括了对 BRU 组成的业务链的定义，从起始输入点，中间过程处理点，到最终输出点。
从逻辑上引入 BRG 的概念，还有一个更重要的原因，就是为了划定出在集群应用系统中故障管理情况下最小的逻辑迁移单元，因此，BRG 还需要具有集群特性 ---- BRG 中所有的 BRU 必須作为一个完整的实体存在，任何一个 BRU 运行失败都代表所属的整个 BRG 运行的失败。在故障转移发生的情况下，BRG 只能做整体性操作，包括重启和迁移等。每一个 BRG 都只从属某一个 BRC，接受 BRC 的管理。
BRC 表示物理上的服务节点，一个 BRC 对外提供若干完整的业务服务过程，若干个 BRC 便形成了更加全面综合的业务服务体系，或者一个提供冗余特性的业务服务体系。BRC 接收负载均衡器转发的客户端访问请求，每个 BRC 都有各自的内部 IP 地址。
在集群系统当中，一般都提供资源的冗余配置，如将两个相同的 BRG 部署在不同的 BRC 上，为实现均衡的负载和故障的平滑处理，以提高服务响应度和保证服务可用性。
可以观察到 BRC、BRG 和 BRU 三者之间存在一种“整体－部分”的树形层次结构。在业务操作方面，为了使这种具有明显树形特点的对象组合拥有操作简易性和一致性，可以用“复合模式 （composite design pattern）”来设计展现三者之间的层次关系。这种设计下，树形复合体内部的各个元素对象都拥有共同的接口。当调用元素对象的某个接口时，自动递归地 遍历以当前元素为起始根节点的以下的所有节点元素，在遍历的同时对每个经历的元素对象调用相同的接口，达到“一令齐动”的效果。具体讲，就是只需要操作 BRC 即可完成对 BRC 中所有 BRG 的相同操作，操作 BRG 即可完成对 BRG 中所有 BRU 的相同操作。
清单 1. BR 相关接口的设计
// 根据业务资源展现出的形态，采用 composite 模式作为开发实现
public interface IElement {
// 基本属性
public void setName ( String name );
public String getName ( );
public void setId ( int id );
public int getId ( );
// 业务数据
public void setData ( Object data );
public Object getData ( );
// 结构管理，实现树形的结构
public void addChildElement ( IElement child );
public boolean contains ( IElement child );
public void removeChildElement ( int index );
public void removeChildElement ( IElement child );
public void removeChildrenAll ( );
public void enable();
public void disable();
public IElement getChildElement ( int index );
public int getChildCount();
public int getIndexOfChild ( IElement child);
public IElement[] getChildElements ( );
public IElement getParentElement ( );
public void setLeaf ( boolean leaf );
// 如果返回为 true 则表示此业务资源为 BRU，返回 false 则有可能为 BRG 或 BRC
public boolean isLeaf ( );
}
// 定义业务操作接口
public interface IOperation {
// 让 parentElement 业务资源及其以下的所有业务资源执行业务服务 business_1
public boolean doBusiness_1 ( IElement parentElement );
public boolean doBusiness_2 ( IElement parentElement );
public boolean checkDetailsOfBusiness ( IElement parentElement, Map details );
}
public interface IBR extends IElement, IOperation { }
public class AbstractBR implements IBR {
....
public boolean doBusiness_1 ( IElement parentElement ) {
// TODO: 实现 parentElement 真实的业务操作
........
// 实现 parentElement 节点下所有节点的 doBusiness_1 业务的递归操作
for ( int i=0; i<parentElement.getChildCount(); i++) {
IElement childElement = parentElement.getChildElement ( i ) ;
childElement.doBusiness_1 ( childElement );
}
}
}
// 完成 BRC 自身的服务后，将服务命令传递给 BRG
public class BRC extends AbstractBR { ...... }
// 完成 BRG 自身的服务后，将服务命令传递给 BRU
public class BRG extends AbstractBR { ...... }
// 负责完成通过 BRC 和 BRG 下达的服务命令，它是服务处理最核心最主要的执行者
public class BRU extends AbstractBR { ...... }
// 测试代码
public class Test {
.....
public void fun ( ) {
AbstractBR BR = new BRG ( );
// BR 完成 business_1 业务 :
// 最终由此业务资源组中的业务资源单元来完成相关的业务实现
BR.doBusiness_1 ( BR );
}
}
集群资源监测器
为了保证集群系统运行时质量，提升集群的可用性，往往会采用软硬件冗余部署和分析利用业务资源监测数据两种手段。集群可用性是度量一个集群是否有良好表现的重要综合指标。它由集群可靠性和集群可维护性组成。
- 可靠性：以平均无故障时间为衡量标准，即集群系统能够正常持续运行的平均时长。故障发生的频度越低，系统的平均无故障时间越长，可靠性也就表现越好。
- 可恢复性：以平均恢复时间为衡量标准，即集群系统发生故障之后，系统维修到重新恢复正常运行状态所花销的平均时间。用于维修的平均时间越短，集群系统的可维护性表现就越好。
集群可用性定义为：
可靠性／（可靠性＋可恢复性）* 100% |
通常，根据集群不同的部署环境要求将集群的可用性归纳为 5 个等级。如 表 2 所示为集群系统可用性等级的划分。
表 2. 集群系统可用性等级划分
| 可用性等级 | 可用性百分比（％） | 停机时间／ 1 年 |
| 容错可用性 | 99.9999 | < 1 分钟 |
| 极高可用性 | 99.999 | < 5 分钟 |
| 具有故障自动恢复能力的可用性 | 99.99 | < 53 分钟 |
| 高可用性 | 99.9 | < 8.8 小时 |
| 商品可用性 | 99 | < 43.8 小时 |
本节以资源监测器为例，它主要监测各个资源的运行时数据以获得相关资源的健康度，它负责监测的内容十分全面，按性质不同分为物理监测和业务逻辑监测。
- 物理资源监测包括：非业务相关的技术指标，如 CPU、Memory/swap、I/O 和 Network 数据等。
- 逻辑资源监测包括：业务规则执行，业务数据流量，业务响应速率，业务数据有效性等。
综合两种数据的监测对业务资源运行时健康状态做出判定，判定原则根据具体的物理环境和业务规则决定。当业务资源处于运行时状态下，如果有任何达不到 要求的最低指标数据的情况发生，则视为此业务资源当前正处于非健康状态。这个判定结果在全系统中发挥着极其重要的作用，它为集群执行负载均衡决策和故障转 移操作提供了数据支撑。
BRMF 集群框架提供集群监测器，监测集群中相关软硬件资源的健康度。按监测范围和层级不同分为三种类型：系统资源监测器 ( SRM， System Resource Monitor )、业务资源心跳探测器 ( BRHD，Business Resource Heartbeat Detector ) 和业务资源监测器 ( BRM，Business Resource Monitor )。
系统资源监测器
由于 BRMF 集群框架是构筑于操作系统级集群之上的集群系统，所以它可以借助于底层操作系统级集群提供的硬件监测功能，完成对其自身关心的相关硬件运行时系统层面的健 康度监测。如系统 CPU 占用率、Memory/swap 开销、I/O 速率、节点网络流量、端口网络流量和 TCP/IP 负载等数据。硬件数据监测器可以快速给出全系统总体健康度数据，但是这只是一个很粗略的评估，我们还要依靠更加精细的监测手段。
业务资源心跳探测器
BRMF 集群框架内部通过心跳包来判断各业务资源的网络通信状态。它周期性地向所有业务资源（BRC/BRG/BRU）发出心跳命令。探测器只收集业务资源当前是否能够通信的信息，并根据这个信息计算得到两组数据：
- 最近周期内心跳有效率：它以当前时刻之前最近最完整的周期作为参考基准点，为负载均衡策略等提供实时（及时）趋势数据的支持。
周期内心跳有效率 = 周期内心跳响应次数 / 周期内心跳发送次数 * 100% |
- 平均心跳有效率：它将当前时刻之前收集到的所有完整周期积累的心跳活动总量作为参考基准点，衡量系统长期以来的健康情况，提供对下一个长期时间段的健康度预期。
平均心跳成功率 = 心跳响应总次数 / 心跳发送总次数 * 100% |
根据“最近周期内心跳有效率”得出的数据，可以将业务资源的网络状态分为：畅通、不稳定、无响应（未启动 / 假死）等三种情况。如 表 3 所示为网络心跳状态划分。
表 3. 网络心跳状态划分
| 最近周期心跳有效率（R） | 状态 |
| R = 1 | 畅通 |
| 0 < R < 1 | 不稳定 |
| R = 0 | 无响应（未启动 / 假死） |
业务资源监测器
对于系统数据监测器和业务资源心跳探测器而言，我们只能从它们身上获得粗略的监测数据，可以即时了解系统现在总体的运行状态，但对于全面细致了解各 个业务资源具体运行数据和定位系统瓶颈甚至故障等则束手无策，所以必须建立针对所有业务资源的监测器－－业务资源监测器，以深入其全面细致的运行数据。
业务资源监测器有不同的监测尺度，一般而言，可以按照 BRMF 集群业务资源部署的层次结构来确定，即按自下而上纵向地分为业务资源单元监测器（BRU Monitor）、业务资源组监测器（BRG Monitor）和业务资源容器监测器（BRC Monitor）三个监测层次，每个层次的监测器对感兴趣的监测内容各有侧重。
业务资源单元监测器
业务资源单元监测器是尺度最小的监测器，它局限于一个业务资源组的范围内，监测目标直接指向业务资源组内部已注册的所有具体单一的业务资源单元。它 对内部所有资源单元做出业务逻辑上的检查，是否符合业务规则，是否满足业务数据有效性等；监测业务服务执行情况；同时，也监测每个资源单元花销内存等情 况。
对于业务资源单元的监测内容需要在开发就确定下来，它真实的反映出业务资源单元在运行时的每一个细节表现，下表只是一个监测模型。如 表 4 所示为业务资源单元细节数据。
表 4. 业务资源单元细节数据
| BRU Monitor 跟踪 BRG 内部每个 BRU 的细节实时数据列表 | ||
| BRU 进程 ID | ||
| 通信端口数据 ( 进 / 出 ) | 端口 _1 | _ 数据 |
| 端口 _2 | _ 数据 | |
| 端口 _3 | _ 数据 | |
| 内存使用情况 | 内存分配总数 | |
| 空闲内存数 | ||
| 已使用内存数 | ||
| 线程数据 | 线程 _1 | _ 数据 |
| 线程 _2 | _ 数据 | |
| 业务展现 | 业务 _1 | _ 数据 |
| 业务 _2 | _ 数据 | |
| 业务 _3 | _ 数据 | |
| 。。。。。。 | ||
根据监测数据，结合事先定义的健康度算法和健康度阈值，业务资源单元监测器为每个业务资源单元生成健康度评估表。如 表 5 所示为业务资源单元健康度评估情况表。
表 5. 业务资源单元健康度评估表
| BRU Monitor：BRG 内部 BRU 宏观实时数据列表 | |||
| BR U 进程 ID | BRU 名称 | 健康度 | 网络位置 |
| 根据 BRU 细节数据计算得出 | |||
业务资源组监测器
业务资源组监测器关注业务资源容器之下分布的各个业务资源组，可以跟踪收集每个资源组的具体细节。它结合业务资源单元健康度评估表得出此组监测器的 健康度。同时，它也有自身的细节监测内容，例如资源组接受的访问请求事件数、组内所有资源单元进程 ID 列表。业务资源组的健康度为负载均衡决策提供了直接的数据依据。如 表 6 所示为业务资源组细节数据。
表 6. 业务资源组细节数据
| BRG Monitor 跟踪 BRG 的细节实时数据列表 | ||
| BRG 进程 ID | ||
| 事件请求 / 响应情况 | 事件请求总数 | |
| 事件响应总数 | ||
| 周期事件处理有效率 | ||
| 组内单元进程数据 | PID_1 | _ 数据 |
| PID_2 | _ 数据 | |
| 。。。。。。 | ||
