根据监测数据，结合事先定义的健康度算法和健康度阈值，业务资源组监测器为每个业务资源组生成健康度评估表。如 表 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 |
2571
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
