28、主动框架系统与计算网格监控管理：技术解析与应用评估

主动框架系统与计算网格监控管理：技术解析与应用评估

在当今的计算领域，分布式计算和资源管理变得愈发重要。主动框架系统为应用级调度提供了灵活的机制，而计算网格的监控与管理基础设施则有助于保障系统的稳定运行。下面将详细介绍主动框架系统的调度策略、远程可视化服务的应用，以及计算网格监控管理基础设施的设计与实现。

主动框架系统的调度策略

主动框架系统允许应用在执行过程中的不同点做出调度决策，支持多种调度策略，以下是几种常见的调度策略：
- 静态调度 ：应用为所有相同类型的框架使用相同的主机分配。每个框架访问相同的服务器集并执行相同的计算集。虽然这种策略可以利用应用自身的资源需求信息来创建调度，但无法适应动态的资源可用性。

class StaticScheduler implements Scheduler {
    StaticScheduler(HostAddress[] list) {
        this.hosts = list;
    }
    HostAddress getHost(int hopCount) {
        if(hopCount<numberOfHosts) {
            return this.hosts[hopCount];
        }
        return null;
    }
}
// 使用示例
HostAddress[] list = getHostList();
Scheduler sched = new StaticScheduler(list);
ActiveFrame frame = new SampleFrame(sched);
server.send(frame);

• 框架创建时调度 ：框架在源服务器进行调度。调度器可以结合应用特定信息和资源监控系统（如Remos或NWS）的数据来做出调度决策。不同的框架可能遵循不同的路径并使用不同的计算资源，但单个框架的调度是静态的，适应仅发生在源端。

class AtCreationTimeScheduler implements Scheduler {
    HostAddress getHost(int hopCount) {
        if(hopCount==0) {
            this.hosts = computePath();
        }
        if(hopCount<numberOfHosts) {
            return this.hosts[hopCount];
        }
        return null;
    }
}

• 框架交付时调度 ：应用可以在主动框架交付到下一个服务器之前做出调度决策。即使框架正在传输中，应用也能对不断变化的资源条件做出反应，提供了最高程度的适应性，但可能会根据决策过程的复杂性引入显著的开销。

class AtDeliveryTimeScheduler implements Scheduler {
    HostAddress getHost(int hopCount) {
        if(hopCount<numberOfHosts) {
            return getHostNow();
        }
        return null;
    }
}

远程可视化服务（Dv）

Dv是基于主动框架系统构建的工具包，使用户能够可视化和交互存储在远程站点的数据集。以Quakeviz应用为例，它生成1994年北岭地震期间地面运动的动画。Quakeviz输入数据集通常非常大，从数百GB到TB不等，因此需要远程可视化服务。

数据处理流程

以下是Quakeviz应用中每个框架数据处理的步骤：
1. 读取数据 ：从文件中加载数据集后，在时间和空间上选择感兴趣的区域。
2. 生成等值面 ：在数据集中找到具有相似特征的区域以生成等值面。
3. 场景合成与渲染 ：将颜色映射应用于数据集中的值，合成场景，然后渲染最终图像。

Dv框架示例

// 请求框架
class RequestFrame implements ActiveFrame {
    HostAddress execute(ServerState state) {
        Source source = new QvDataSource();
        while (moreFrames()) {
            Dataset data = source.getFrame(roi_parameters);
            ResponseFrame fr = new ResponseFrame();
            fr.setData(data);
            Scheduler sched = createScheduler();
            fr.setScheduler(sched);
            state.getServer().send(fr);
        }
        return null;
    }
}

// 响应框架
class ResponseFrame implements ActiveFrame {
    HostAddress execute(ServerState state) {
        Filter filter = new Filter();
        filter.setInput(this.data);
        filter.compute();
        this.data = filter.getOutput();
        return scheduler.getHost(hopCount);
    }
}

评估

为了评估主动框架系统的性能，对远程可视化服务在不同资源配置下进行了评估。

单主机设置

使用相对较小的数据集（包含30K非结构化网格节点和151K四面体元素）在单主机上运行可视化应用。以下是不同等值面数量下的平均执行时间和帧率：
| 等值面数量 | 读取帧数据时间(ms) | 等值面提取时间(ms) | 渲染时间(ms) | 总时间(ms) | 帧率(帧/秒) |
| — | — | — | — | — | — |
| 10 | 584.35 | 1044.37 | 55.72 | 1684.44 | 0.59 |
| 20 | 582.65 | 1669.73 | 63.73 | 2316.11 | 0.43 |
| 50 | 586.13 | 3562.36 | 125.77 | 4274.26 | 0.23 |

这些结果表明，处理单个帧所需的总时间过长，无法实现交互性。通过改变应用参数（如等值面数量），可以在资源充足时生成更高质量的可视化效果，或减少帧处理时间以满足帧的截止日期。

流水线设置

为了提高动画的响应性，切换到三主机设置，其中两个主机作为计算服务器，另一个作为显示客户端。以下是不同等值面数量下的平均执行时间和帧率：
| 等值面数量 | 读取帧数据时间(ms) | 程序传输(s-s)(ms) | 数据传输(s-s)(ms) | 等值面提取时间(ms) | 程序传输(s-c)(ms) | 多边形传输(ms) | 渲染时间(ms) | 总时间(ms) |
| — | — | — | — | — | — | — | — | — |
| 10 | 286.21 | 110.14 | 118.88 | 696.43 | 39.54 | 175.10 | 64.99 | 1491.29 |
| 20 | 285.98 | 94.47 | 116.92 | 1152.03 | 44.13 | 435.66 | 162.32 | 2291.51 |
| 50 | 287.11 | 86.51 | 119.52 | 2561.41 | 46.40 | 1700.59 | 340.40 | 5141.95 |

等值面数量	源处理时间(ms)	服务器处理时间(ms)	客户端处理时间(ms)	源帧率(帧/秒)	服务器帧率(帧/秒)	客户端帧率(帧/秒)	最大帧率(帧/秒)
10	515.23	1140.09	279.63	1.94	0.88	3.58	0.88
20	497.37	1843.21	642.11	2.01	0.54	1.56	0.54
50	493.15	4514.44	2087.40	2.03	0.22	0.48	0.22

虽然数据和程序传输增加了额外的成本，但可以获得资源聚合的好处。计算服务器的帧率最慢，决定了流水线的整体帧率。与单主机设置相比，客户端现在有更多的空闲周期用于与用户交互。

扇形设置

使用两个额外的计算服务器执行应用。源服务器读取数据集，客户端生成并渲染场景。调度器通过循环方式将每个服务器发送不同的帧来执行等值面提取。以下是不同等值面数量下的平均执行时间和帧率：
| 等值面数量 | 读取数据时间(ms) | 程序传输(s-s)(ms) | 点数据传输(ms) | 等值面提取时间(ms) | 程序传输(s-c)(ms) | 多边形传输(ms) | 渲染时间(ms) | 总时间(ms) |
| — | — | — | — | — | — | — | — | — |
| 10 | 283.46 | 13.61 | 116.36 | 677.09 | 65.26 | 337.45 | 123.24 | 1616.47 |
| 20 | 283.58 | 15.09 | 116.18 | 1098.01 | 83.47 | 434.13 | 183.44 | 2213.88 |
| 50 | 284.52 | 17.73 | 115.99 | 2384.19 | 173.76 | 1899.29 | 271.99 | 5147.48 |

等值面数量	源处理时间(ms)	服务器处理时间(ms)	客户端处理时间(ms)	源帧率(帧/秒)	服务器帧率(帧/秒)	客户端帧率(帧/秒)	最大帧率(帧/秒)
10	413.43	1209.77	525.96	2.42	2.48	1.90	1.90
20	414.85	1746.87	701.03	2.41	1.72	1.43	1.43
50	418.24	4590.96	2345.04	2.39	0.65	0.43	0.43

客户端主机饱和导致整个系统变慢，但通过在调度器中使用应用特定信息，与单主机设置相比，在三种情况中的两种情况下总帧率提高了3倍，另一种情况提高了一倍。

计算网格监控管理基础设施

计算网格由分布式资源、服务和应用组成，这些资源和应用容易受到故障和过度负载的影响。因此，需要一个基础设施来监控资源使用情况，检测可能导致故障的条件，并在发生故障时进行恢复。

设计需求

• 可扩展性 ：能够扩展以监控和管理计算网格中的大量实体。
• 可扩展性 ：随着时间的推移，能够适应被监控实体、故障模式和故障恢复或QoS调节方法的变化。
• 模块化 ：允许添加新组件和修改现有组件，而不改变其余代码。
• 安全性 ：支持多种安全级别，包括无、认证和授权，以及认证、授权和加密通信。

基础设施组件

该基础设施基于三个基本监控组件构建：
- 传感器 ：执行测量。
- 执行器 ：执行操作。
- 事件服务 ：在远程进程之间通信事件。

应用案例

• Globus元计算目录服务 ：通过监控该服务的资源使用情况和性能指标，及时发现并解决潜在的故障。
• 长时间运行的粗粒度参数研究应用 ：监控应用的执行状态，确保其在规定的时间内完成，并根据资源使用情况进行动态调整。

通过上述的主动框架系统和计算网格监控管理基础设施，可以提高分布式计算系统的性能和可靠性，更好地满足不同应用的需求。

主动框架系统与计算网格监控管理：技术解析与应用评估（续）

现有监控系统分析

在构建计算网格监控管理基础设施时，对现有的一些监控系统进行了研究，发现它们大多无法完全满足设计需求，以下是对部分现有监控系统的分析：
- NetLogger、Paradyn、AIMS、Gloperf、SPI ：这些系统能够从分布式系统中收集数据，并通过特定工具进行分析，但不能作为其他工具和应用的数据收集组件。
- Heart Beat Monitor（HBM） ：是Globus的扩展，通过定期发送“心跳”到集中收集器来提供分布式系统中的故障检测服务。然而，仅依赖一种“传感器”（即本地监视器生成的心跳）会导致故障检测不准确。
- Network Weather Service（NWS） ：测量可用网络带宽和系统负载，以预测其未来状态。未来状态预测可被调度器用于高效地预留和分配资源。如果将状态估计器视为特殊类型的传感器，其未来状态预测可造福于依赖资源动态调度的实时应用。
- Dinda等人的研究 ：比较和评估了几种时间序列建模技术，用于预测未来系统负载，可应用于动态资源管理。
- Dynamic Soft Real - Time（DSRT）调度工具 ：依赖定制的CPU监视器来实现该工具的各种特定调度策略。
- JEWEL/DIRECT ：可作为控制系统反馈回路的一部分，但该监控系统的复杂性使其使用具有挑战性。
- RMON ：监控运行RT - Mach的分布式多媒体系统的资源使用情况，通过操作系统的实时特性自适应管理系统资源。

计算网格监控管理基础设施的优势

与现有监控系统相比，所设计的计算网格监控管理基础设施具有显著优势：
- 高度模块化 ：允许用户根据需求添加或修改组件，而不影响其他部分的代码。例如，在监控不同类型的服务或应用时，可以轻松添加新的传感器或执行器。
- 方便重定向 ：能够方便地应用于不同的网格服务和应用，如Globus元计算目录服务和长时间运行的粗粒度参数研究应用。
- 可扩展性 ：可以随着被监控实体、故障模式和恢复方法的变化而扩展，适应不断变化的计算环境。

基础设施应用流程

下面以Globus元计算目录服务为例，说明该基础设施的应用流程：

graph LR
    A[传感器测量资源使用情况和性能指标] --> B[事件服务传输测量数据]
    B --> C{是否检测到异常}
    C -- 是 --> D[执行器执行相应操作]
    C -- 否 --> A
    D --> E[继续监控和评估]
    E --> A

1. 传感器测量 ：传感器持续测量Globus元计算目录服务的资源使用情况和性能指标，如CPU使用率、内存占用、响应时间等。
2. 事件服务传输 ：事件服务将传感器测量的数据传输到监控中心。
3. 异常检测 ：监控中心根据预设的规则和阈值，判断是否存在异常情况。
4. 执行器操作 ：如果检测到异常，执行器将执行相应的操作，如重启服务、调整资源分配等。
5. 持续监控 ：执行操作后，继续进行监控和评估，确保服务恢复正常运行。

总结与展望

主动框架系统通过多种调度策略为应用级调度提供了灵活性，远程可视化服务（Dv）利用主动框架系统实现了对大规模远程数据集的可视化和交互。在不同的资源配置下进行评估，结果表明主动框架系统虽然引入了一定的开销，但能获得资源聚合的好处，提高系统的性能和响应性。

计算网格监控管理基础设施基于传感器、执行器和事件服务构建，具有可扩展性、模块化、安全性等优点，能够有效地监控和管理计算网格中的资源、服务和应用。通过对现有监控系统的分析，发现该基础设施在满足设计需求方面具有明显优势。

未来，可以进一步优化主动框架系统的调度策略，减少调度开销，提高系统的适应性。对于计算网格监控管理基础设施，可以探索更智能的故障检测和恢复机制，提高系统的可靠性和稳定性。同时，随着计算网格的不断发展，将该基础设施应用于更多的实际场景，验证其有效性和实用性。

总之，主动框架系统和计算网格监控管理基础设施为分布式计算系统的发展提供了有力支持，有望在未来的计算环境中发挥重要作用。