29、计算网格中的监测与管理基础设施及主机负载跟踪回放技术

计算网格中的监测与管理基础设施及主机负载跟踪回放技术

计算网格监测与管理基础设施

在计算网格领域，有效的监测和管理系统对于保障系统的稳定运行和高效性能至关重要。现有的一些相关系统和工具各有其特点和局限性。

Autopilot 系统将动态性能监测和实时性能数据缩减与可配置的资源管理及自适应控制算法相结合，但数据收集主要是为了提供自适应控制，其底层数据收集服务能否用于其他应用并不明确。Java Agents for Monitoring and Management（JAMM）则仅针对基于 Java 的应用。基于 SNMP 的工具广泛应用于网络监测和管理，像 Big Brother 这样的监测、故障通知和基于 Web 的系统及网络管理工具对分布式系统也有帮助，但它们无法提供特定应用的事件通知，而我们的监测和管理基础设施则支持这一功能。

我们的基础设施基于三个基本模块构建：传感器、执行器和网格事件服务。
- 传感器 ：用于测量本地系统的属性。由于可测量的属性众多，监测基础设施为传感器定义了通用的应用程序编程接口（API）。这样一来，我们可以实现一组用于测量基本属性的传感器，其他用户也能添加他们想要监测的属性的传感器。传感器通常会执行 Unix 实用程序，如 df、ps、ping、vmstat 或 netstat 等，并提取特定于传感器的测量值，这些测量值以特定于传感器的属性值表示。此外，我们还提供内部传感器，可从调用进程内部收集资源使用信息。
- 执行器 ：与传感器的调用方式类似，但它使用 shell 来执行特定的配置、进程控制或其他用户定义的任务。我们正在实现的一些执行器包括：终止进程、发送邮件、执行 shell 命令、轻量级目录访问协议（LDAP）服务器查询以及一些 Globus 命令。
- 网格事件服务 ：该服务提供了一种将传感器收集的信息转发给对这些信息感兴趣的其他进程的机制。它支持发布 - 订阅模式，允许客户端请求特定信息，服务器则负责转发这些信息。同时，它也便于将特定应用的事件数据从用户进程转发到消费进程。

这些基本监测服务可以通过 API 调用。传感器和执行器的通用 API 使我们能够在不更改使用它们的代码的情况下实现新的传感器或执行器。我们还将这些 API 实现为独立的实用程序，以便可以在命令行上调用。我们已在 Irix、Solaris 和 Linux 三个平台上实现了这些组件，并使用可扩展标记语言（XML）表示监测数据。

基于这些基本组件，还可以构建一些更高级的组件。例如，我们实现了一个本地传感器管理器，它可以执行用户指定的传感器并转发事件数据。我们还开发了一个通用数据收集器组件，用于收集本地监测服务器转发的信息。目前，我们正在开发数据存档和查询服务器，以扩展监测和管理基础设施，支持不使用发布 - 订阅模式的工具和应用。

下面是监测基础设施的软件架构概述：
| 层次 | 组件 | 描述 |
| ---- | ---- | ---- |
| 底层 | 操作系统服务、Globus 中间件服务 | 提供基础的系统和通信支持 |
| 基础层 | 传感器、执行器、事件服务 | 实现基本的监测和控制功能 |
| 高级层 | 传感器管理器、数据收集器等 | 基于基本组件构建的更高级功能 |
| 应用层 | 监测、故障管理和 QoS 调节应用 | 利用监测和管理基础设施的具体应用 |

mermaid 代码如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(操作系统服务):::process --> B(Globus 中间件服务):::process
    B --> C(传感器):::process
    B --> D(执行器):::process
    B --> E(事件服务):::process
    C --> F(传感器管理器):::process
    D --> F
    E --> F
    C --> G(数据收集器):::process
    D --> G
    E --> G
    F --> H(监测、故障管理和 QoS 调节应用):::process
    G --> H

基础设施的应用

我们目前将该基础设施应用于一个网格服务和一个网格应用，以提供故障处理和应用状态跟踪功能。

元计算目录服务的故障管理

元计算目录服务（MDS）是 Globus 工具包中基于 LDAP 的网格信息服务。在基于 Globus 的计算网格中，MDS 维护着资源、服务和应用的动态信息，这些信息对于许多服务和应用至关重要。MDS 服务器可能由于多种原因变得无法响应查询，例如大日志文件导致高磁盘使用率和 I/O 故障、过高的 CPU 负载、过多的客户端查询、网络故障以及 LDAP 服务器故障等。

为了在生产网格环境中提供可靠的目录服务，我们需要检测、报告和管理这些 MDS 故障。基于我们的网格监测和管理组件构建的 MDS 故障管理器的架构如下：每个运行 MDS 的 LDAP 服务器的主机都包含一个监测器和一个故障管理器。监测器定期调用传感器来收集磁盘使用情况、CPU 使用情况、到 MDS 主机的活动 TCP 连接数量以及 LDAP 服务器进程的状态等信息。本地故障管理器接收这些信息，并将其与预定义的故障条件进行比较。如果发生故障条件，故障管理器将使用执行器采取指定的操作。例如，如果 LDAP 日志文件超过了分配的磁盘空间，将旧的日志文件移动到磁带；如果 LDAP 服务器进程消失，则重新启动 LDAP 服务器。出于安全原因，故障管理器是一个独立于监测器的进程，因为故障管理器需要 root 权限来启动 LDAP 服务器，所以应尽可能简单以便进行验证。

此外，还使用了远程监测器和故障管理器来监测运行 LDAP 服务器的主机。本地监测器会定期向远程主机上的 MDS 故障管理器发送心跳消息。如果 MDS 故障管理器停止收到本地监测器的心跳消息，它会检查运行本地监测器的主机是否可以联系。如果主机在指定时间内无法访问，将向 MDS 管理员发送电子邮件以解决问题。

在为期四天的 MDS 故障管理器测试中，对收集的跟踪数据进行了时间分析。结果表明，大多数心跳传感器消息的到达间隔时间接近其实际采样周期 10 秒，只有少数例外超过了 12 秒的超时值。一些现有的故障管理工具依赖于定期心跳消息，并使用这些消息到达的“异常”延迟来确定故障的发生。但在本次测试中，仅基于心跳的方法可能会错误地将延迟到达的消息检测为故障。MDS 故障管理器使用 ping 传感器来确认 MDS 主机是否真的无法访问，从而区分故障和延迟到达的心跳消息。

下面是 MDS 故障管理器的架构图：
mermaid 代码如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(MDS 基于 LDAP 服务器):::process --> B(传感器):::process
    A --> C(本地监测器):::process
    B --> C
    C --> D(本地故障管理器):::process
    D --> E(执行器):::process
    E --> A
    C --> F(事件服务):::process
    D --> F
    F --> G(MDS 监测/故障管理器):::process
    G --> H(MDS 故障管理器主机):::process

参数研究应用的监测和故障管理

参数研究应用由于其粗粒度的并行性，通常被认为是分布式计算平台的合适应用。对于这个参数研究应用，传感器会监测进程状态、可用磁盘空间、文件暂存、主机状态和应用执行进度。在执行过程中，需要进行监测以检测与主机可访问性、磁盘空间可用性和应用进程状态相关的故障。

参数研究应用的前端 ILab 将各个进程分布在计算网格中的多个并行系统上。每个并行系统的前端主机上的 shell 脚本会确定相关进程的进程 ID，并使用进程状态传感器的命令行实现，定期将进程状态信息从前端主机发送到 ILab 主机。同时，还会调用磁盘空间传感器来监测磁盘使用情况。ILab 前端使用这些进程和磁盘使用信息来确定进程是否终止或是否使用了过多的磁盘空间。如果进程终止，ILab 会使用单独的脚本来检查进程输出文件，以确定它是正常终止还是异常终止。如果是异常终止，ILab 可以进一步分析原因，并可能改变未来作业提交的方式。同样，如果特定文件系统的磁盘使用超过指定值，后续启动的进程将被配置为将其输出写入不同的文件系统。通过网格监测组件进行监测和故障检测，可以自动管理选定的故障条件。

在一次参数研究应用的实验中，我们跟踪了磁盘空间使用情况和特定应用进程的状态。通过这些信息，ILab 前端可以检测到特定进程终止的情况，并进行测试以确定它是否正常终止。

除了监测系统级资源使用情况，我们的监测和故障管理基础设施还可以动态监测分布式进程中发生的特定应用事件。这通过内部传感器和事件服务 API 实现。分布式应用进程通过在代码中嵌入内部传感器来发布所需信息，客户端订阅发布者以异步接收所需的事件数据。这种信息可用于性能监测或允许客户端控制应用。

下面是参数研究应用的监测和故障报告设施的架构图：
mermaid 代码如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(ILab GUI):::process --> B(事件服务):::process
    C(前端主机 - 并行系统):::process --> D(传感器):::process
    C --> E(shell 脚本):::process
    D --> E
    E --> B
    F(前端主机 - 工作站集群):::process --> G(传感器):::process
    F --> H(shell 脚本):::process
    G --> H
    H --> B

主机负载跟踪回放技术

在评估分布式中间件系统时，如应用级调度器、动态负载均衡器、分布式软实时系统和资源预测系统等，能够生成逼真且可重复的背景 CPU 工作负载是一项必要的前提条件。这些系统会对其他运行程序产生的 CPU 争用做出反应，以提高其所服务应用的性能。因此，需要一种机制来产生逼真且可重复的 CPU 争用情况。

本文介绍了一种新的技术——主机负载跟踪回放，用于根据 Unix 负载平均值的跟踪记录生成背景工作负载，从而产生逼真且可重复的 CPU 争用行为。Unix 负载平均值衡量了在真实机器上运行的真实工作负载所导致的随时间变化的 CPU 争用情况。回放过程的目标是在给定回放主机和记录跟踪的机器的情况下，尽可能准确地重现这种争用情况。回放过程可以配置为基于时间的方式，即争用情况仅在特定时间发生。

我们开发了一个名为 playload 的工具来实现这种技术。在我们评估的四个平台上，playload 都能忠实地从跟踪记录中重现工作负载。playload 和大量的主机负载跟踪记录都可以从以下网址公开获取：http://www.cs.cmu.edu/~pdinda/LoadTraces

下面是主机负载跟踪回放技术的实现步骤：
1. 记录负载跟踪 ：在真实机器上运行工作负载，并记录 Unix 负载平均值的跟踪记录。
2. 配置回放 ：根据需要配置回放过程，如时间间隔、工作负载强度等。
3. 运行 playload ：使用 playload 工具根据记录的负载跟踪生成背景工作负载。
4. 评估系统 ：在生成的背景工作负载下评估分布式中间件系统的性能。

以下是一个简单的表格，展示了主机负载跟踪回放技术的主要特点：
| 特点 | 描述 |
| ---- | ---- |
| 逼真性 | 基于真实的 Unix 负载平均值跟踪记录，产生逼真的 CPU 争用行为 |
| 可重复性 | 能够重复生成相同的工作负载，便于系统评估 |
| 灵活性 | 可以根据需要配置回放过程，适应不同的评估场景 |

mermaid 代码如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(记录负载跟踪):::process --> B(配置回放):::process
    B --> C(运行 playload):::process
    C --> D(评估系统):::process

总结与展望

计算网格中的监测与管理基础设施为计算网格提供了模块化、可重定向和可扩展的数据收集组件，能够实现更高级别的故障处理和管理服务。通过传感器、执行器和事件服务等基本组件，结合高级组件的构建，可以有效地监测和管理计算网格中的系统和应用。在实际应用中，如元计算目录服务的故障管理和参数研究应用的监测和故障管理，该基础设施都展现出了良好的效果。

主机负载跟踪回放技术则为评估分布式中间件系统提供了一种有效的方法，能够生成逼真且可重复的背景 CPU 工作负载，有助于更准确地评估系统性能。

未来，我们计划进一步扩展监测和管理基础设施，支持更多的数据转发模型，如查询监测信息的存档。同时，我们将使用基于时间序列模型的规则故障检测机制，更好地理解和表征导致故障的条件，从而提高故障检测和管理的准确性。对于主机负载跟踪回放技术，我们将继续优化 playload 工具，提高其在不同平台上的性能和稳定性，并探索更多的应用场景。