如何对高性能计算群组进行监控（组图）

　　假设一个场景：你是一个自负的系统管理员，现在有一个全新的计算群组坐落在你面前，LINPACK已经安装完毕，一系列工作已经井然有序地开展。一切就位，用户也很开心，你开始处理其他未解决的问题。这时，你突然收到一封邮件：“为什么运行速度变慢了?”或者一位项目经理来找你，并询问那个新款高价硬件是否已经安装。或许你在做来年的计划，因此需要知道近期的产品使用趋势。对系统进行监控，以建立基线数据和群组当前的性能信息，上述问题将易于解决。

　　监控这一理念有多种解释方式。对于高性能计算(HPC)，人们更多关注的是利用率和计算结点性能的指标，而非服务的可用性和问题通知。这篇文章主要关注前者，但Nagios和OpenNMS程序则在管理后两类问题上更有优势。

　　在开始阅读这篇文章之前，先假设你走近了一个运行中的计算群组；一个文件形式为mod_php的机能网络服务器(也有GD支持)；可轻松处理基础的系统管理工作、配置Apache结构和应用命令行工具。下列命令行运行于CentOS 5和Gentoo系统，但通用概念应该适用于所有Linux系统(很多其他类似UNIX系统的操作系统同样可用)。

　　数据收集

　　监控可分为两个程序。其一事实上是选取所需的指标，接着收集来自主机的数据。最通用的指标是CPU使用率、内存利用率、网络带宽以及磁盘I/O统计数据。这些数据体现出系统各个方面的性能状况，同时也可以指出哪一部分存在潜在问题或者是系统性能提高的瓶颈所在。数据收集到之后，第二项工作是将这些数据进行整理并分析。

　　Linux系统提供了众多获取系统性能数据的方式。常用的工具有vmstat、iostat和netstat，还有很多其他不常用工具。这些程序在采用时通常被调整为非交互的形式——这是连续监控系统的重要理念。除非有易于解析的模态，否则交互式程序的运行状态会受到影响。部分程序(例如sar和atop)有数据收集模式，并且可生成大范围的指标的细节报告。即使其他的数据收集方式均失败了，也可直接从/proc或 /sys系统文件中得到数据，尽管你仅需要分析初级数据，以得到有用的信息。比如，不同的CPU利用率值事实上是通过计算/proc/stat中的数据得到。

　　几乎所有的指标都可以简化为数据或数据集合;盖上时戳;并将这些数据存储起来以留待系统恢复之用。存储模式有多种，可以是一般模式(普通的txt文件)，也可以是复杂模式(一系列规范的SQL表格)。rrdtool 工具采用的RRD模式是专门用来存储度量数据的，适用于此项工作。Ganglia则将RRD文件用于数据存储。

　　基本监控一般从vmstat开始。这一工具可提供大量系统的相关数据，同时也可定期报告系统的运行情况。表一中的命令是让vmstat每五秒钟报告一次运行情况，但仅显示一次标题行。就我们的目的来看，这一命令行的头三行不是必须的，因为命令行的第一、二行是栏目标题行，而第三行报告了从系统上次重新启动起的平均值。遗憾的是，vmstat不能显示平均工作量，但是我们可以通过采用其他程序的数据而计算出这一数值。

　　为了达到我们的目的，我们令awk给每一命令行盖个时间戳，同时获取/proc/loadavg(存储当前平均工作量的数据)的内容。最后，输出数据被发送到tee命令，这样输出数据就可以显示在STDOUT而存储在vmstat中。一般来说，对于普通文件的更改，仅存储数据就可以了。而对于每一个程序，请分别检查人员手册以了解使用细节和命令语法、以及输出模式。　　

　　$ vmstat -n 5 | awk '(NR>3){getline load < "/proc/loadavg"; print systime(), $0, load }' | tee vmstat.dat

　　1196738925 0 1 188 138820 254824 674948 0 0 2 0 3470 9566 35 11 54 0 0.46 0.38 0.52 1/140 31493

　　1196738935 1 0 188 123972 263420 674948 0 0 860 0 3648 9876 6 12 0 82 0.63 0.41 0.53 2/140 31493

　　1196738945 0 1 188 99296 273700 674976 0 0 1029 0 3708 10016 6 13 0 82 0.68 0.43 0.54 1/140 31493

　　1196738955 1 1 188 89716 281340 674976 0 0 764 0 3654 9921 6 10 0 84 0.73 0.45 0.54 1/140 31493

　　举例说明，表一存储的是单一ASCII平面文件的数据。优点在于这一模式简单易用：数据既存即用，同时不需要特殊的工具对之进行选取分析。缺点在于以纯文本形式存储的数据没有实现对磁盘空间的有效利用，同时，对于很大的文件，阅读和处理数据所需时间过长。没有保留元数据，且只有在知道显示哪些数据的情况下，才可处理文件。比如，上述输出文件，除非获知数据来自vmstat，否则我们无法重新显示数据。一般的监控，平面文件就足够了。但对于严格的数据收集，我们则需要选取更有效的解决方案——例如采用RRD文件或数据库。

　　数据显示

　　即使数据量在刚开始收集时很少，但是很快就会膨胀到一定规模，数据应用是监控工作的另一个环节。事实上，这才是关键所在。正如人们常说的：“一幅图比几千个词都清楚。”

　　来自vmstat的数据，我们可以将其发送到gnuplot以获得这个时间段系统性能的数据。Vmstat和awk命令将21种不同的指标生成一个文件，同时盖上一个时间戳;这也就说明了为什么管理很多不同的指标是一项挑战。在本文所给出的案例中，我们希望得到第1、14、15、18栏(代表时间戳)、用户CPU%、系统CPU%和一分钟平均工作量的数据信息。

　　图一：来自vmstat 和/proc/loadavg的数据图

　　如图一所显示的，系统在这个时段里相当繁忙：多台虚拟机都在运行，同时几个大型软件包也处于编译状态。系统CPU利用率水平取决于磁盘的输入输出情况和虚拟机的负载状况。我们可以看到这一图表很好的记录了CPU的使用情况。

　　Ganglia

　　对于开放源码，一般情况是，其他人已经编写出解决相关问题的软件，但监控系统却处于缺位状态。

　　Ganglia包括多个来自HPC系统的组件，这些组件效率很高，可升级，专门进行系统监控、数据收集和指标显示。Ganglia最先由加州大学的Matt Massie编写，当前由一个小型研发团队来改进。Ganglia被用于世界各地的商业、教育、政府和非营利性组织，用来监控最大型的计算群组。在Ganglia的网站上可以看到采用Ganglia的企业名录。最近发布的Ganglia稳定版是ganglia-3.1.0。相对于之前的3.0.x系列，新版本有了很大改进，改进包括：将指标直接添加到gmond的新模块界面、部分新的核心指标和数据显示。尽管下面的屏幕截图来自3.0.5版本，Ganglia 3.1.0的安装情况也基本相同。

　　Ganglia易于安装，并且经销商近期提供了软件包，部分红帽软件包管理程序(RPM)也可从SourceForge网站下载。如果软件包无法获得或者过期，tarballs可在Ganglia主页上下载。网络前端的运行需要Apachemod_php模块, 而PHP语言必须有GD支持。安装网络前端时，仅仅将“web”地址复制到Apache文件的根目录是不够的，还需要进行重命名。请看表二。　　

　　$ tar xzf ganglia-3.0.5.tar.gz

　　$ cd ganglia-3.0.5

　　$ ./configure --with-gmetad

　　$ make

　　$ sudo make install

　　$ sudo cp -r web html_docroot/ganglia

　　如图二所示，这里是Ganglia的四个主要组成部分

　　1，Gmond负责收集本地机核心指标的基本设置——如CPU使用情况、基础网络和内存数据等。gmond daemons通过多播或单播模式给同一群组的其他gmond daemons发送数据。这样，每个daemon都可在任何时间追踪到全球的计算群组，且每一台均可给gmetad提供完整的数据报告。

　　2，gmetad daemon是系统的核心。它从一个或多个gmetad daemon中收集指标，将其存储在RRD文件中留待以后系统恢复之用。gmetad daemon也可以选择其他gmetad来收集其他集成系统的信息。这一过程被称作“联合”，对于分散但有关联的群组，这是了解总体运行状态的有效方式。

　　3，网络前端构建在PHP上，实际是用来显示数据的。当每一页都已下载完毕，PHP程式需要来自gmetad的相关数据，以便生成需求页。有很多事先做好的报告，这些报告已提供群组整体运行状态的信息，因此，现在仅将用户报告完成即可。网络前端不像gmetad那样必须在同一台计算机上运行。

　　4，对于不直接支持gmetad的指标，Ganglia和命令行程序gmetric共同追踪附加的指标。这些信息都报告给gmond，gmond可将这些信息和已建立起的统计数据一起传递给gmetad。最新发布的3.1.0版本可通过用c语言或Python语言来编写模块，达到直接扩展gmond的目的。　　

　　图二：Gangliafont-size: 10.5pt; mso-font-kerning: 0pt; mso-bidi-font-family: 宋体">原理略图

　　每个计算节点都需要进行gmond处理以收集数据，而管理结点则需要运行gmetad。Gmond接收来自TCP端口8649的gmetad，同时发送和接收239.2.11.71，端口8649多点传送的信息流。gmetad daemon接收TCP端口8651和8652的信息。如果多点传送出现问题，确保IP路由表格已经制好，且可以正确管理多点传送信息流。

　　任何可量化的信息均可传送到gmetric。举例说明：为了计算登录到系统的单个用户数目，并将数据传送到Ganglia，需要应用表三中的shellscript语句。

　　#!/bin/sh

　　USERS=`who | awk '{print $1}' | sort -u | wc -l`

　　gmetric -n users_loggedin -v $USERS -t uint8 -u Users

　　Gmetric的每次调用都需要命令行选项-n (指标的名称)、-v (指标的值) 和-t(指标的数据类型)。-u选项指明的是这一指标的单位，不是必须选用，但推荐选用。

　　对于不能直接运行gmond的设备，可采用gmetric来发送数据。Ganglia可篡改来自其他主机的报告，因此Ganglia可监控来自嵌入式系统、硬盘和其他设备的数据。例如，很多UPS有内置温度传感器，并可通过建立SNMP代理来支持网络管理卡。假设你有Net-SNMP项目的snmpget，就可以通过采用表四的脚本将UPS的温度数据传给Ganglia。　　

　　#!/bin/sh

　　# Name and IP address of the UPS, and OID.

　　# The OID is specific to APC hardware,

　　# but other vendors provide similar support.

　　UPS=ClusterUPS1

　　IP=192.168.200.101

　　OID=.1.3.6.1.4.1.318.1.1.2.1.1.0

　　TEMPERATURE=`snmpget -O qv -c public -v 1 $IP $OID`

　　gmetric -n temperature -v $TEMPERATURE -t int8 -u 'deg C' -S $IP:$UPS

　　这一指令应与来自crond的调用相匹配。Ganglia预计指标每六十秒升级一次，但需要时也可调整，这取决于预期行为。

　　注意：此例中的数据类型是“int8″而非前例中的“uint8″。这说明通过采用rrdtool，Ganglia应该用8-bit有符号整数来存储温度数据，这与存储登录用户数目的无符号8-bit整数不同。温度可以是负数，尽管数据中心的温度一般不会这么低。而登录用户的数目永远不可能是负数，因此采用无符号整数即可。这一脚本易于扩充，这样就可以选出其他信息，例如UPS的流出安培数或流入电压数。长度为32 bits的整数和浮点小数数据也可获得。

　　为了写这篇文章，我采用虚拟机创建了一个小型四结点计算群组——1个头结点和3个计算结点，每个都有一个单核CPU。尽管这一群组没有动力装置，作为范例来说足够了。每个计算结点运行gmond，头结点运行gmond、gmetad和网络前端。

　　Gmond(”/etc/gmond.conf”)和gmetad (”/etc/gmetad.conf”)的默认配置文件在不进行修正的情况下工作。然而，对于Ganglia的产品安装，更改“gmetad.conf”中data_source的设置和群组{ name = "unspecified" }的“gmond.conf"入口，使之相匹配。也需要考虑到由daemon支持的多种访问控制方式(特别是在采用“欺骗”功能的情况下)。

　　图三的屏幕截图显示了运行在测试群组上的Ganglia安装过程。Ganglia在相当有限的空间中显示了大量信息。网页顶部提供了群组整体状况、CPU、内存和网络统计数据的信息。当主机脱机时，这些数据仍可显示。

　　图三：运行中的Ganglia

　　网页底部显示了每个结点的统计数据，每个系统一个图表。缺省设置显示的是一分钟的负载量。结点按负载量递减的顺序排列，因此负载量高的结点排在第一位。这一选择可通过网页上部说显示的“度量基准”下拉框来更改。这一彩色图表是基于当前一分钟的负载量，由CPU的数目分开。因此，单一CPU机箱的负载量为1.02则被标记为红色，然而一个负载量为2.06的八核机箱被标记为绿色。显示特定主机细节信息的网页可通过点击每个结点图标得到。

　　所有图表都是同一时间段的，这样，不同的指标就易于互联。比如，在01:10，结点2就不在线。负载报告显示，从3.0 到2.0大约有一分钟有负载。由于显示的数值是群组一分钟负载量的总和，而每两个结点报告的负载量略小于1.0。当一个结点离线时，另一个报告的数据显示将出现类似变化，尽管在本测试中这一变化很不明显。

　　对于HPC系统，对性能指标的监控是确保群组正常运行的重要环节。也有很多其他方式来管理和显示数据，不同的因素决定了具体的选择。Ganglia提供了可升级的灵活解决方案，可以考虑采用。Ganglia也可采用命令行工具和用户脚本来编写用户解决方案。尽管可能不如一个解决方案配置起来那么方便，但编写这样一个程序可使你更了解系统。