logo资料库

Linux操作系统高性能集群监控管理之道.doc

第1页 / 共7页
第2页 / 共7页
第3页 / 共7页
第4页 / 共7页
第5页 / 共7页
第6页 / 共7页
第7页 / 共7页
资料共7页,全文预览结束
Linux 操作系统高性能集群监控管理之道 监控是集群管理的核心任务。监控数据可用于调度任务、负载平衡、向管理员报告软 硬件故障,并广泛地控制系统使用情况。监控信息必须在不影响集群性能的情况下获得。本 文将讨论使用/proc 文件系统和 Java 来获得监控数据的方法。 Java 在 Linux 集群中的应用 Java 技术为集群管理开发者提供了许多解决问题的办法。Java 是动态、灵活、可移植 的,这些不寻常的特征使得它成为了在异构网络及平台上构造集群管理的理想基础。 Java 具有广泛的例程库,很容易处理 IP 协议,如 TCP、UDP,并可在 multi-homed 主 机上进行网络程序设计,用它创建网络连接比用 C 或 C++更容易。通过 Java 本地接口 (JNI),运行在 Java 虚拟机(JVM)内的 Java 代码能够与用其它语言编写的应用及库文 件相互操作并汇编。 在构造集群监控和管理时,Java 早已是一个可选的语言。然而,Java 语言通常只 被 用于系统的前端或集群主机部分,而将用 C 语言编写的守护进程安装在集群结点上。尽管 Java 程序设计语言提供了许多优点,但是,对于高性能集群监控,Java 能够有效地替换运 行在每个结点上的 C 语言守护进程吗?这将是本文讨论的重点。 高性能监控 监控 Linux 集群工具传统上以秒为测量频率来提供有限量的数据。而高性能集群监控 被定义为“以 intrasecond 为测量频率,从结点有效地采集数据的能力”。当涉及较大集群 时,监控软件的低效率问题就变得更加严重,这是因为所运行 的应用软件必须互相协调或 共享全局资源。 在一个结点上的阻隔冲突(Interference)能影响其它结点上作业的运行。 例如,一 个 MPI 作用需要与所有参与的结点同步。一种解决办法是收集少量的数据,并以小频率传输。 然而,如果是高性能监控,这种解决办法是不可接受的,因 为有较重利用率的集群应该被 频繁持续地监控。本地作业调度器必须能够基于资源使用情况做快速决策。管理员经常希望 收到紧急事件的立即通知,并希望观察到历 史趋势数据,如果集群不能被频繁持续地监控, 那么这些要求是不可能实现的。因此,必须采取一些措施,如使用更有效的算法、增加传输 的并行性、提高传输协议 及数据格式的效率、减少冗余等。 在跟踪运行中的资源使用情况时,压缩 Profiling 应用有助于调试程序或优化程序。 对一个给定的应用而言,像存储器、网络、CPU 这样动态资源的使用可能快速地改变着,为 了能够观察应用是怎样使用这些资源的,一种可能的办法是使用高频率的监控。 即使用户对高频率监控没有兴趣,如果算法是有效的,不管监控频率是多少,它也将 消费 很少的资源。在异构集群中这种效率将更重要,用户的作业可以被分散到较快的及较 慢的结点上,慢的结点需要全部 CPU 来跟上较快的结点并与之同步。一个监控 程序花费在 较慢结点上的 CPU 时间是作业的关键路径。
监控阶段 集群监控主要消耗 CPU 周期与网络带宽这两个重要资源。然而,资源消费问题与这两 个资源是根本不同的。CPU 利用问题对结点而言是完全本地化的问题,可通过创建有效的收 集与合并算法来解决。网络带宽是共享资源,是规模问题,可以通过最小化网络上传输的数 据量来解决。 为了解决这两个问题,我们将集群监控分为三个阶段:收集、合并、传输。收集阶段 负责 从操作系统装载数据、分析数据值,并存储数据。合并阶段负责将来自多个数据源的 数据合在一起,决定数据值是否改变并过滤它们。传输阶段负责压缩并传输数 据。本文集 中讨论 Linux 集群监控的收集阶段。 1.收集阶段 Linux 有几种方法来进行系统统计,每种方法都各有其优缺点。 ◆ 使用现有的工具 标准及非标准工具能执行一个或多个收集、合并及传输阶段,如 rstatd 或 SNMP 工具, 然而标准的 rstat 后台程序提供的信息是有限的,速度慢而且效率低。 ◆ 内核模块 几个系统监控工程利用内核模块来存取监控数据。一般情况下,这是很有效的收集系 统数 据的方法。然而这种方法存在的问题是,当主内核源内有其它改变时,必须保持代码 一致性。一个内核模块可能与用户想使用的其它内核模块相冲突。此外,在使用 监控系统 之前,用户必须获得或申请模块。 ◆ /proc 虚拟文件系统 /proc 虚拟文件系统是一个较快的、高效率执行系统监控的方法。使用/proc 的主要缺 点是必须保持代码分析与/proc 文件格式改变的同步。事实表明,Linux 内核的改变比/proc 文件格式的改变要更频繁,所以,用/proc 虚拟文件系统比用内核模块存在的问题要少。 ◆ 混合系统 某些监控系统采用混合方式,用内核模块收集数据,用/proc 虚拟文件系统作为数据接 口。 2.合并阶段 合并阶段的实现可以在结点上、集群管理的主机上,或者分布在两者上。考虑到效率, 我 们只采用在结点上的合并。原因在于结点是监控数据的收集器与提供者。两个或多个同 时的数据请求不会引起两次操作系统调用来收集数据,而是将第一次请求获得 的数据缓存, 并可以提供给第二次请求调用。这种方法减少了操作系统的负担,提高了监控系统的响应性。
合并阶段也可以用于将多个数据源的数据以相互独立的收 集速率结合,因为并不是所有的 数据都以同样的速度改变,或者需要以同样的速率收集。 使用在结点层上合并的另一个原因是,减少了包括传输在内的信息量。许多/proc 文件 既包含动态数据也包含静态数据。删除最近一次传输后没有改变的值,一个结点发送的数据 量可以大大地减少。合并不仅除去了不经常改变的动态值的传输,也解决了从不改变的静态 值的传输。 3.传输阶段 监控数据几乎总是按一个层次结构组织起来。传输阶段的任务就是将层次数据进行有 效的 编码,形成一种能高效传输的数据格式。Java 拥有的文件格式是存储层次数据的有效 方法,并且用提供的 Java APIs 很容易完成。S-Expressions 已经被认为是传输这种数据的 另一个有效的方法。 关于传输监控数据普遍讨论的问题是,数据应该按二进制编码还是按文本格式编码。 二进 制数据更容易压缩,因此也能更有效地传输。但是,当采用/proc 文件系统时,监控 数据通常以人们易读的格式存储。在传输之前,将数据转换为二进制格式将 需要更多的处 理资源与时间。以文本格式保留收集的数据,结点资源能被用于更多非监控性的相关工作。 采用文本格式的数据将提供如下额外的益处: ◆ 平台独立性 当监控异构集群时,机器之间数据字节指令的配置不是永远相同的。文本格式的使用 在代码方面解决了这个问题,而且体系结构独立不会影响更多的处理需求。 ◆ 易读的格式 文本数据能以人们易读的格式进行组织。如果需要的话,这种特征能容易地进行程序 调试或允许用户观看数据流。 ◆ 有效压缩 数值数据的文本表示由来自 10 个字节集中的字符组成,而不是二进制下的 256 个字节 集。它们产生的数字及模式的相对频率允许有效地使用基于压缩算法的字典及熵(平均信息 量)。 /proc 虚拟文件系统 /proc 虚拟文件系统(也叫 procfs)是 Unix 操作系统所使用的虚拟文件系 统的 Linux 实现,包括 Sun Solaris、LinuxBSD。在/proc 开始时,它以一个标准文件系统出现,并包 含与正在运行的进程 IDs 同样名字的文件。然而,在/proc 中 的文件不占用磁盘空间,它 们存在于工作存储器(内存)中。/proc 最初的目的是便于进程信息的存取,但是现在,在 Linux 中,它可被内核的每一部分使 用来报告某些事情。
在/proc 文件系统提供的成百上千的值当中,我们将集中考虑集群监控所需的最小集, 它们包括: ◆ /proc/loadavg:包含系统负载平均值; ◆ /proc/meminfo:包含存储管理统计量; ◆ /proc/net/dev:包含网卡度量; ◆ /proc/stat:包含内核统计量; ◆ /proc/uptime:包含总的系统正常工作时间及空闲时间。 每个文件提供的值的数量是不同的。这些文件的完整有效值列表如下。 ◆ /proc/loadavg 提供以下数据: 1 秒钟平均负载; 5 秒钟平均负载; 15 秒钟平均负载; 总作业数; 正在运行的作业总数。 ◆ /proc/meminfo 提供的存储器信息包括: 活动存储器; 不活动存储器; 缓冲存储器; 高速缓冲存储器; 总的自由存储器; 总的高位存储器; 自由高位存储器; 总的低位存储器; 自由低位存储器;
共享存储器; 交换存储器; 交换高速缓冲存储器; 交换自由存储器; 总存储器。 ◆ /proc/net/dev 中包括每个网卡的如下数据: 接收到的字节; 接收到的压缩字节; 收到的误码数; 收到的漏失误码; 收到的 FIFO 误码; 收到的帧误码; 收到的多播误码; 收到的总包数; 已传输的字节; 已传输的压缩字节; 传输误码总数; 传输载波误码; 传输冲突误码; 传输漏失误码; 传输 FIFO 误码; 传输的总包数。 ◆ /proc/stat 提供: 引导时间;
上下文切换数量; 中断总量; 进页面总数; 出页面总数; 进程总数; 换入总数; 换出总数; 合计 CPU 空闲时间; 合计 CPU nice 时间; 合计 CPU 系统时间; 合计 CPU 用户时间。 同时提供对每个 CPU 的: 单个 CPU 空闲时间; 单个 CPU nice 时间; 单个 CPU 系统时间; 单个 CPU 用户时间。 以及对每个磁盘驱动器的如下数据: 单个磁盘块读; 单个磁盘块写; 单个磁盘 I/O 总数; 单个磁盘 I/O 读; 单个磁盘 I/O 写。 ◆ /proc/uptime 中包括: 系统总工作时间;
系统总空闲时间。 值得注意的是,每次某个/proc 被读时,一个句柄函数都被内核或特有模块调用,来 产 生数据。数据在运行中产生,不管是读一个字符还是一个大的字块,整个文件都将被重建。 这对效率是至关重要的一点,因为使用/proc 的任何系统监控器将 吞下整个文件,而不是 一点一点地处理它。 Java 提供了丰富的文件 I/O 类集,包括基于类的流、基于类的块设备,以及 J2SDK 1.4 提供的新的 I/O 库。实验表明,一般而言,对基本的块读写文件操作,用 RandomAccessFile 类进行 I/O 是最佳的。例如,块读文件操作如下: mFile = new RandomAccessFile( "/proc/meminfo", "r" ); //以读方式打开文件 mFile.read( mBuffer ); //读文件块 结论 本文讨论了如何将 Java 语言有效地用于 Linux 集群结点上的高性能监控。在程序设计 中,要注意以下方面: ◆ 采用/proc 文件系统; ◆ 以块形式读/proc 文件,而不是以行或字符形式; ◆ 在读文件期间保持文件打开; ◆ 消除不必要的数据转换; ◆ 在结点上合并数据; ◆ 以压缩形式传输数据; ◆ 注意与性能问题相关的语言或库。 对高性能监控而言,内核模块不是必要条件,这点很重要,因为它在 Linux 版本和分 类 之间提供了很大程度的可移植性,在监控器实现语言上有很多的选择。但是,/proc 文件系 统的性能却很依赖内核代码的效率,因此,适当地理解有关的机制 将对以任何语言编写的 监控器性能有非常大的影响。
分享到:
收藏