应用级集群系统的设计
集群系统在企业 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 |
|
|
集群资源监测器
为了保证集群系统运行时质量，提升集群的可用性，往往会采用软硬件冗余部署和分析利用业务资源监测数据两种手段。集群可用性是度量一个集群是否有良好表现的重要综合指标。它由集群可靠性和集群可维护性组成。
- 可靠性：以平均无故障时间为衡量标准，即集群系统能够正常持续运行的平均时长。故障发生的频度越低，系统的平均无故障时间越长，可靠性也就表现越好。
- 可恢复性：以平均恢复时间为衡量标准，即集群系统发生故障之后，系统维修到重新恢复正常运行状态所花销的平均时间。用于维修的平均时间越短，集群系统的可维护性表现就越好。
集群可用性定义为：
可靠性／（可靠性＋可恢复性）* 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 | _ 数据 | |
| 。。。。。。 | ||
根据监测数据，结合事先定义的健康度算法和健康度阈值，业务资源组监测器为每个业务资源组生成健康度评估表。如 表 7 所示为业务资源组健康度评估情况表。
表 7. 业务资源组健康度评估表
| BRG Monitor： BRC 内部 每个 BRG 宏观实时数据列表 | |||
| BRG 进程 ID | BRG 名称 | 健康度 | 网络位置 |
| 根据 BGU 细节数据计算得出 | |||
业务资源容器监测器
业务资源容器监测器负责监测集群内所有的资源容器，它收集整个集群系统中接收到的客户端访问请求总数、资源容器对访问请求的响应度等。通过容器监测器做出的评估，我们可以判断容器的负载，它也为负载均衡器提供了的负载决策的数据依据。
表 8. 业务资源容器健康度评估表
| BRC Monitor： 集群系统 内部 BRC 宏观实时数据列表 | ||
| BR C 名称 | 健康度 | 网络位置 |
| 根据 BCU 细节数据计算得出 | ||
表 9. 业务资源容器细节数据
| BRC Monitor 跟踪 BRC 的细节实时数据列表 | ||
| 事件请求 / 响应情况 | 请求总数 | |
| 响应总数 | ||
| 响应速度 | ||
| 处理有效率 | ||
| 容器内组进程 ID | PID_1 | _ 数据 |
| PID_2 | _ 数据 | |
| 。。。。。。 | ||
故障资源监测器
系统在系统数据监测器、业务资源心跳探测器和业务资源监测器收集数据的同时，应建立一个专门负责管理故障信息数据的组件 ---- 故障资源监测器（Trouble Monitor），它收集所有发生故障的业务资源，并产生一张动态的“全局故障资源分布列表”，记录当前正处于故障处理状态下的资源。故障资源监测器为以后提到的故障资源转移管理器提供了故障数据。
表 10. 全局故障资源分布列表
| BRC 名称 | BRG 名称 | BRU 名称 |
| BRC_1 | BRG_2 | BRU_1 |
| BRU_3 | ||
| BRC_2 | BRG_1 | BRU_2 |
| BRG_5 | BRU_1 | |
| BRC_5 | BRG_3 | BRU_3 |
| 。。。。。。 |
清单 2. 业务资源监测器接口设计
public interface IMonitor {
// 1. 将关心“全局故障资源分布列表”的组件注册到监测器，如故障转移管理器
// 2. 将关心“资源健康度列表”的组件注册到监测器，如负载均衡器
// 3.TroubleMonitor 也需要作为 listener 注册到业务资源监测器当中
public void addBRLinstener ( IListener listener );
// 当监测数据发生变化时，通知在 monitor 中已注册的 listener,
// 随即每个 listener 取到最新的数据来更新其本地数据，
// 以及进行相关的处理操作。
public void notify ( );
public void notify ( Class listenerClass );
// 得到业务资源的详细信息
public IDetail getDetail ( final IBR BR );
}
|
在部署系统前即为不同的业务资源预先定义出若干健康度算法，为了灵活适应不同运行时环境（业务数据环境和网络环境等），每一种资源都配置有健康度的缺省算法和若干次级算法，一般情况下使用缺省算法，次级算法只是用来应对某些特定的运行时环境。算法之间既有独立性又有相似性。将采集到的数据完全委托给算法器，算法器使用算法对数据计算得出对应业务资源的健康度。每个算法被设计为可以动态加载和相互替换的模式，算法和数据之间处于弱连接的关系。
清单 3. 健康度算法与数据接口设计
public interface IHealth {
// 为满足需求，监测数据可以委托给各式各样的算法
public IDegree delegate ( IStrategy strategy );
}
public interface IStrategy {
// 不同的算法此处有不同的实现方式
public IDegree operate (IHealth health ) {
}
}
|
|
|
负载均衡器
在传统的网络系统尤其是两层架构的系统中，单一设备承载了巨大的数据流量和计算强度，即便是采用最优的软硬件配置来建设网络系统，也会很快感到资源捉襟见肘，无法高效地完成应用。在现有网络系统中加入负载均衡器则可以从根本上改变过去的窘迫局面。负载均衡器在如今的集群应用系统中也毫无争辩地扮演了一个承上启下的关键角色，它是联系客户端访问请求与真实业务处理的中转站，提供了一种高效的手段扩展服务器带宽和增加吞吐量来提高数据处理能力。它采用适应的负载处理策略，对来自前端客户大量类型各异的访问请求数据，有选择的进行“分路”转发，最大程度地为其分配系统中较为“闲散”的业务处理资源，从而避免了大量请求数据集中涌向同一个业务处理资源，防范后端出现单点性能瓶颈和多点资源闲置的“尴尬局面”。负载均衡器应尽力使同类的若干业务处理资源都获得大致相同的负载效果。
负载均衡器的使用可以为系统增添许多的价值：
- 解决了网络拥塞问题；
- 服务器资源得到了充分利用，为客户端提供高质量的访问体验；
- 从体系架构的角度来讲，
- 负载均衡器作为中间层，它将访问核心业务处理资源的操作聚合为一组接口，为客户端的访问提供了一个一致的界面，使访问更加容易；
- 客户端访问请求由负载均衡器接受，避免直接同核心业务处理资源耦合，从而极大提高了系统的可扩展性（资源可扩展性、应用可扩展性和技术的升级换代）并保证了集群系统和客户端软件的兼容性；
- 为实现物理位置上业务处理资源部署的分布性提供了条件；
- 从客户端的访问体验来看，客户端并不知道也无需关心真正的核心业务处理资源的所有细节，负载均衡器是一组简单的访问接口，是业务处理访问请求的唯一入口，它常被客户端“误认为”是代表了所有核心业务处理资源。客户端软件只要符合负载均衡器的访问规范即可以访问整个集群系统。
目前，负载均衡器技术按数据流层次分为基于客户端的负载均衡技术、网络接入协议交换、高层协议交换和应用服务器技术等几种实现方式。
此处的负载均衡器被设计为两层，第一层借助 LVS 集群架构提供的 IP 级负载均衡技术，第二层采用高层协议交换技术来达到均衡负载的目的。
首先，作为 LVS 集群结构中的子集群，LVS 的负载均衡器完成操作系统级的 IP 负载均衡（LVS 提供了三种负载模型：地址转换、IP 隧道和直接路由。这里不做具体介绍）；之后，由 BRMF 提供的软件负载均衡器解析客户端访问请求，根据请求类型和业务处理资源健康度情况，将请求转发到正确的节点。
本节介绍的重点是 BRMF 提供的负载均衡器，它属于高层协议交换方式，可以针对具体的业务逻辑特征实现对访问请求的高层控制 -- 访问请求分发策略，它根据业务特征的不同，由基于内容的分发器（Content-based Distributor）和基于健康度的分发器（Health-based Distributor）两部分组成。
- 基于内容的分发器作为负载均衡器的第一级，首先完成对客户端访问请求内容的解析，确定其应该转发到哪些目标：所有满足类型匹配要求的合法目标，包括业务资源容器和业务资源组；
- 在第一级中通过内容分发器的解析得到了所有与访问请求匹配的候选分发目标，进而可以从“资源监测器”中提取出这些资源的健康度评估数据，从而甄选出最优目标资源作为访问请求的最终目的地。
经过内容解析和健康度评估两级的过滤筛选后，得出了一个完整且预期处理效果最优的访问请求传输路径。
基于内容的分发器（Content-based Distributor）
它掌握了应用集群环境中完整的业务功能列表。
根据协议定义，解析访问请求的所属“业务类型”，然后通过“业务类型标识符与业务资源映射表”找出所有匹配的目标资源。对于集群系统，通常都为处理每种业务类型的访问请求提供至少两个以上的业务资源组，以提高系统的可靠性和可用性。
表 11. 业务类型与业务资源的映射
| 业务类型 | BRC/BRG 名称 | |
| 业务类型 - 1 | BRC_1 | BRG_1 |
| BRC_2 | BRG_1 | |
| 业务类型 - 2 | BRC_1 | BRG_2 |
| BRC_2 | BRG_2 | |
| BRC_3 | BRG_2 | |
| 业务类型 -3 | BRC_1 | BRG_3 |
| BRC_3 | BRG_3 |
基于健康度的分发器
在不同类型的业务资源监测器中，都会生成相应的业务资源健康度评估列表。健康度分发器就是以这些评估列表提供的数据为基准点。结合在第一级分发器解析后得到的符合匹配条件的若干目标资源，根据相关联评估列表，从中筛选出最优的目标资源。健康度分发器在“业务类型与业务资源映射表”的基础上，最终形成最优目标资源分发路径表，它包括了当前系统中每种“业务类型”对应访问请求的最优分发目标资源。
表 12. 最优目标资源分发表
| 业务类型 | BRC/BRG 名称 | |
| 业务类型 - 1 | BRC_1 | BRG_1 |
| -- | -- | |
| 业务类型 - 2 | -- | -- |
| -- | -- | |
| BRC_3 | BRG_2 | |
| 业务类型 -3 | BRC_1 | BRG_3 |
| -- | -- |
分发器与业务资源监测器的关系
分发器并未实时地向业务资源监测器发送询问请求来得到当前最新的最优目标资源的分布情况，而是作为业务资源监测器的数据监听者，等待更新数据的通知。
- 分发器必須要作为监听方，注册到相关的业务资源监测器当中
- 当业务资源监测器在资源相关数据发生变化时，应立即向分发器发出更新通知。
- 资源正常运行，只是负载发生变化而引发的更新通知
- 资源发生故障，其分布信息发生变化而引发的更新通知
- 分发器获得更新通知后，从业务资源监测器中取出最新的数据，
- 更新“业务类型与业务资源映射表”
- 更新“最优目标资源分发表”
基于内容的分发器与基于健康度的分发器组合成一个负载均衡器，共同完成对客户端访问请求的路由选择，通过这个路由筛选过程，达到了用最优秀的资源服务客户端的目的。
清单 4. 分发器的接口设计
public interface IDistributor extends IListener {
public void update ( Object data );
}
|
|
|
故障转移管理器
任何一个系统都不能百分之一百的保证永远不发生任何故障，故障的发生将导致相关成本的提升，那么对于如何处理和管理故障以减少成本支出就显得尤为重要。故障管理器通过故障资源监测器可以得到当前所有处理故障状态的业务资源。故障管理器对这些资源完成停止、重启和转移等操作。
前面已经提到了，在集群系统运行时，对所有相关业务资源均受到 BRMF 的监测。当故障管理器接收到业务资源故障通知后，会遵循一个管理原则，即当某业务资源发生后立刻停止被中止，然后试图进行本地重启，如果重启不成功则对资源进行适当的迁移再运行。遵循这一原则的目的是为了能够保证组件在业务逻辑角度上的完整性和一致性。
从业务资源监测器与故障转移管理器的关系入手，以 BRG 发生故障为例，展开故障转移管理的基本过程：
- 当业务资源容器监测器监测到 RG 资源发生故障时，立即触发资源故障事件
- 业务资源容器监测器向 BRC 发送业务资源注销事件消息，将 BRC 中的这个故障 BRG 注销，停止对该 BRG 资源的监测
- 故障资源监测器将此故障 BRG 信息加入“故障资源分布列表”。
- 向故障转移管理器发送资源故障事件消息，并将此故障 BRG 的管理权移交给故障转移管理器。首先，故障转移管理器对资源进行重启操作，如果重启失败（一般而言，硬件发生故障是导致重启失败的常见原因）：
- 首先在系统中检查是否还有某些系统资源因此故障 BRG 而处于被占用状态，如果有则系统强制释放这些资源
- 检查 BRG 中的 BRU 进程是否还有遗留内存，如果有则将其从内存中清除。
- 此时系统中已没有任何与故障 BRG 相关的业务资源存在，可以开始转移工作，根据故障资源转移策略的裁定，在新 BRC 节点上以新 BRC 的名义重新激活先前发生故障的 BRG 资源。此时的 BRG 资源拥有权属于当前这个新的 BRC 节点。
- 当故障转移管理器成功完成故障资源重启或转移工作后，通知业务资源监测该 BRG 资源当前的分布信息，此时业务资源容器监测器重新开始对该 BRG 资源的监测工作。
表 13. 业务资源与故障转移策略配置
| BRC 名称 | BRG 名称 | 策略集 |
| BR C_1 | BRG_1 | failover_business_A.conf |
| BRG_2 | failover_business_A.conf | |
| BRG_3 | failover_business_B.conf | |
| BRC_2 | BRG_1 | failover_business_A.conf |
| BRG_2 | failover_business_D.conf | |
| BRC_3 | BRG_1 | failover_business_C.conf |
|
|
结束语
在大型的应用级集群服务系统的实施过程当中，设计人员需要考虑相当多的要素：功能、可靠性、可用性和性能等若干方面，本文仅从集群的业务资源设计、资源监测器、负载均衡器和故障转移管理器四个部分简要的阐述了集群系统的基本设计，抛砖引玉，希望能与大家共同深入探讨集群系统的设计与实施。
参考资料
学习
- “基于 Linux 的集群系统”（developerWorks，2001 年 6 月）：Linux Virtual Server 开源项目创立人章文嵩博的相关技术文章。
- 查看 developerWorks 上更多关于 集群 的文章和教程。
- developerWorks Java 技术专区：可以找到几百篇关于 Java 编程的各个方面的文章。
讨论
- 参与 developerWorks blogs 并加入 developerWorks 社区。
关于作者
|
||
|
|
|
陈松，软件架构设计师。有丰富的软件开发及架构设计经验，目前主要精力集中在企业级应用 Java 大型系统的前期架构和实施当中，并致力至系统的重构优化。闲暇之余，对中国古典哲学思想有着浓厚的兴趣。 |