hadoop小型集群_小型Hadoop集群的Ganglia配置和一些故障排除

最新推荐文章于 2020-10-14 22:10:14 发布

dnc8371

最新推荐文章于 2020-10-14 22:10:14 发布

阅读量219

点赞数

文章标签：大数据 python java linux hadoop

原文链接：https://www.javacodegeeks.com/2013/04/ganglia-configuration-for-a-small-hadoop-cluster-and-some-troubleshooting.html

版权

hadoop小型集群

Ganglia是一个针对大型集群的开源，可扩展且分布式的监视系统。它收集，汇总并提供数十种与计算机相关的指标（例如CPU，内存，存储，网络使用情况）的时序视图。您可以在UC Berkeley Grid上看到Ganglia的运行情况。

Ganglia也是监视Hadoop和HBase群集的流行解决方案，因为Hadoop（和HBase）具有将其度量发布到Ganglia的内置支持。使用Ganglia，您可以轻松地查看特定HDSF数据节点随时间写入的字节数，给定HBase区域服务器的块缓存命中率，对HBase集群的请求总数，在垃圾收集上花费的时间以及许多很多其他。

基本神经节概述

神经节由三部分组成：

Ganglia监视守护程序（gmond） –一个守护程序，需要在每个受监视的节点上运行。它收集本地监视指标并宣布它们，并且（如果已配置）接收并汇总从othergmond发送给它的指标
s（甚至来自自身）。
Ganglia meta守护程序（gmetad） –定期从一个或多个数据源（数据源可以是agmond或othergmetad）进行轮询以接收和汇总当前指标的守护程序。汇总结果存储在数据库中，并且可以XML格式导出到其他客户端，例如Web前端。
Ganglia PHP Web前端 –它从meta守护程序检索组合的指标，并以精美的动态HTML页面的形式显示它们，其中包含各种实时图形。

如果您想了解有关gmond，gmetad和Web前端的更多信息，请在Ganglia的Wikipedia页面上找到很好的描述。希望下面的图片（显示一个示例性配置）有助于理解这个想法：

在本文中，我将重点介绍Ganglia的配置。如果您使用的是Debian，请参考以下教程进行安装（只需键入几个命令）。我们在这篇文章中使用Ganglia 3.1.7。

小型Hadoop集群的Ganglia

尽管Ganglia是可伸缩的，分布式的并且可以监视数百乃至数千个节点，但是小型集群也可以从中受益（开发人员和管理员也可以从中受益，因为Ganglia是学习Hadoop和HBase内部的一种很好的经验方法）。在本文中，我将描述我们如何在运行Hadoop和HBase的五节点群集（1个主节点和4个从属节点）上配置Ganglia。我相信5节点集群（或类似大小）是许多公司和组织开始使用Hadoop的典型配置。请注意，Ganglia具有足够的灵活性，可以通过多种方式进行配置。在这里，我将简单描述我想要实现的最终效果以及实现方式。我们的监视要求可以指定如下：

从每个节点轻松获取指标
轻松获取所有从属节点的汇总指标（这样我们将知道MapReduce作业和HBase操作使用了多少资源）
轻松获取所有主节点的聚合指标（到目前为止，我们只有一个主节点，但是当集群增长时，我们会将一些主重传（例如JobTracker，Secondary Namenode）移动到单独的机器上）
轻松获取所有节点的汇总指标（以获取群集的总体状态）

这意味着我希望Ganglia将集群视为两个“逻辑”子集群，例如“主”和“从”。基本上，我希望看到这样的页面：

可能的Ganglia配置

这是一张说明图，显示了满足我们所有要求的5节点Hadoop集群的简单Ganglia配置。因此，让我们以这种方式进行配置！

请注意，我们希望保留尽可能多的默认设置。默认：

gmond在UDP端口8649上通信（在gmond.conf中指定了inudp_send_channel和inudp_recv_channel部分）
gmetad在TCP端口8649上下载指标（在intcp_accept_channel部分ingmond.conf中指定，在gmetad.conf中的data_source条目中）

但是，一项设置将被更改。我们将gmond之间的通信方法设置为单播UDP消息（而不是多播UDP消息）。与多播相比，单播具有以下优点：对于较大的群集（例如，具有一百多个节点的群集）更好，并且Amazon EC2环境中支持单播（与多播不同）。

Ganglia监视守护程序（gmond）配置

根据上图：

- 每个节点都运行agmond。

从站子集群配置

- slave1，slave2，slave3和slave4节点上的每个gmond定义udp_send_channel，以将度量标准发送到slave1（端口8649）
- slave1上的gmond定义udp_recv_channel（端口8649）以侦听传入的度量，并定义tcp_accept_channel（端口8649）以宣布它们。这意味着该gmond是该子集群的“引导节点”，并收集所有gmond从属节点（甚至从自身）通过UDP（端口8649）发送的所有度量标准，稍后可以由gmetad通过TCP（端口8649）进行轮询。

掌握子集群配置

主节点上的gmond定义了udp_send_channel以将数据发送到主节点（端口8649），udp_recv_channel（端口8649）和tcp_accept_channel（端口8649）。这意味着它成为该单节点群集的“主导节点”，并从自身收集所有指标并将其公开给gmetad。该配置应在gmond.conf文件中指定（您可以在/ etc / ganglia /中找到它）。 slave1的gmond.conf（仅包括最重要的设置）：

cluster {
  name = 'hadoop-slaves'
  ...
}
udp_send_channel {
  host = slave1.node.IP.address
  port = 8649
}
udp_recv_channel {
  port = 8649
}
tcp_accept_channel {
  port = 8649
}

适用于slave2，slave3，slave4的gmond.conf（实际上，也可以使用与slave1相同的gmond.conf文件）：

cluster {
  name = 'hadoop-slaves'
  ...
}
udp_send_channel {
  host = slave1.node.IP.address
  port = 8649
}
udp_recv_channel {}
tcp_accept_channel {}

主节点的gmond.conf文件应与slave1的gmond.conf文件类似–只需将master1的IP地址替换为slave1的IP地址，并将群集名称设置为“ hadoop-masters”。您可以在此处阅读有关gmond的配置部分和属性的更多信息。

Ganglia meta守护程序（gmetad）

gmetad的配置更加简单：

大师级跑步
gmetad定义了两个数据源：

data_source 'hadoop-masters' master.node.IP.address
data_source 'hadoop-slaves' slave1.node.IP.address

该配置应在gmetad.conf文件中指定（您可以在/ etc / ganglia /中找到它）。

Hadoop和HBase与Ganglia集成

Hadoop和HBase使用GangliaContext类将每个守护程序收集的指标（例如datanode，tasktracker，jobtracker，HMaster等）发送到gmond。成功设置Ganglia后，您可能需要编辑/etc/hadoop/conf/hadoop-metrics.properties和/etc/hbase/conf/hadoop-metrics.properties，以向Ganglia宣布与Hadoop和HBase相关的度量。由于我们使用与Ganglia版本3.1.x兼容的CDH 4.0.1，因此我们在属性文件中使用了新引入的GangliaContext31（而不是较旧的GangliaContext类）。

从站的度量标准配置

# /etc/hadoop/conf/hadoop-metrics.properties
...
dfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
dfs.period=10
dfs.servers=hadoop-slave1.IP.address:8649
...
mapred.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
mapred.period=10
mapred.servers=hadoop-slave1.IP.address:8649
...

主站的指标配置

应该与奴隶相同–只需使用hadoop-master.IP.address：8649（而不是hadoop slave1.IP.address：8649）即可：

# /etc/hbase/conf/hadoop-metrics.properties
...
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=hadoop-master.IP.address:8649
...

切记在所有节点上编辑两个属性文件（对于Hadoop编辑/etc/hadoop/conf/hadoop-metrics.properties，对于HBase编辑/etc/hbase/conf/hadoop-metrics.properties），然后重新启动Hadoop和HBase集群。无需其他配置。

单点故障

在节点开始出现故障之前，此配置效果良好。而且我们知道他们会的！而且我们知道，不幸的是，我们的配置至少有两个单点故障（SPoF）：

在slave1上的gmond（如果该节点发生故障，则有关所有从节点的所有监视统计信息将不可用）
gmetad和master上的Web前端（如果该节点发生故障，则整个监视系统将不可用。这意味着我们不仅会释放最重要的Hadoop节点（实际上，它应称为SUPER-master，因为它有很多master守护程序）已安装，但我们也失去了宝贵的监视信息源，可通过查看该节点在故障发生前一刻生成的图形和度量来帮助我们检测故障原因）

避免在slave1节点上使用Ganglia的SPoF

幸运的是，您可以指定任意数量的udp_send_channels，以将度量标准冗余地发送到其他gmond（假设这些gmond指定udp_recv_channels来监听传入的度量标准）。在我们的例子中，我们可能选择slave2作为额外的引导节点（与slave1一起）以冗余地收集度量（并向gmetad宣布）

在所有从属节点上运行updategmond.conf并定义其他udp_send_channel部分以将度量标准发送到slave2（端口8649）
在slave2上的updategmond.conf上定义udp_recv_channel（端口8649）以侦听传入的度量，并在tcp_accept_channel（端口8649）上宣布它们（在slave1的gmond.conf中已经设置了相同的设置）
在从属节点上运行的Hadoop和HBase守护程序的updatehadoop-metrics.properties文件，以将其度量标准同时发送到slave1和slave2，例如：

# /etc/hbase/conf/hadoop-metrics.properties
...
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=hadoop-slave1.IP.address:8649,hadoop-slave2.IP.address:8649

最终updatedata_source“ hadoop-slaves” ingmetad.conf从两个冗余gmond s轮询数据（如果gmetad无法从slave1.node.IP.address提取数据，它将继续尝试slave2.node.IP.address）：

data_source 'hadoop-slaves' slave1.node.IP.address slave2.node.IP.address

也许下面的图片不是很幸运（有很多箭头），但是它的意思是，如果slave1发生故障，那么gmetad将能够从slave2节点上的gmond获取指标（因为所有从节点都将指标冗余地发送给在slave1上运行的gmond s和slave2）。

避免在主节点上使用Ganglia的SPoF

这里的主要思想是不要将gmetad（和Web前端）与Hadoop主守护程序并置，这样，如果主节点发生故障（或根本变得不可用），我们就不会丢失监视统计信息。一个想法是，例如，将gmetad（和Web前端）从slave1移到slave3（或slave4），或者简单地引入一个在slave3（或slave4）上运行的冗余gmetad。前者的想法似乎还可以，而后者则使如此小的集群变得非常复杂。我想，更好的主意是引入一个额外的节点（如果可能，称为“边缘”节点），该节点运行gmetad和Web前端（它可能还安装了基本的Hadoop和HBase软件包，但不运行任何Hadoop的守护程序-它仅充当客户端计算机，以启动MapReduce作业并访问HBase。实际上，“边缘”节点通常用于在用户和群集之间提供接口（例如，它运行Pig和Hive ， Oozie ）。

故障排除和提示可能会有所帮助

由于调试配置的各个方面是设置Ganglia的最长部分，因此我在这里分享了一些技巧。请注意，本文并不涵盖所有可能的故障排除，而是基于我们遇到并最终设法解决的问题。

从小开始

尽管Ganglia的过程配置不是那么复杂，但是最好仅从两个节点开始，如果可行，将其扩展到更大的集群。但是之前，您要安装任何Ganglia的守护程序…

尝试将“ Hello”从node1发送到node2

确保可以使用UDP协议与给定目标主机上的端口8649进行通信。 netcat是一个简单的工具，可以帮助您进行验证。打开节点1（稍后称为“引导节点”）上的端口8649以进行入站UDP连接，然后从节点2向其发送一些文本。

# listen (-l option) for inbound UDP (-u option) connections on port 8649 
# and prints received data
akawa@hadoop-slave1:~$ nc -u -l -p 8649

# create a UDP (-u option) connection to hadoop-slave1:8649 
# and send text from stdin to that node:
akawa@hadoop-slave2:~$ nc -u hadoop-slave1 8649
Hello My Lead Node

# look at slave1's console to see if the text was sucessfully delivered
akawa@hadoop-slave1:~$
Hello My Lead Node

如果不起作用，请仔细检查您的iptables规则（如果使用IPv6，则为iptables或ip6tables）是否为UDP和TCP连接打开了端口8649。

让gmond将数据发送到另一个gmond

在两个节点上安装gmond，并验证一个节点是否可以使用端口8649上的UDP连接将其度量标准发送到另一个节点。您可以在gmond.conf文件中为两个节点使用以下设置：

cluster {
  name = 'hadoop-slaves'
}
udp_send_channel {
  host = the.lead.node.IP.address
  port = 8649
}
udp_recv_channel {
  port = 8649
}
tcp_accept_channel {}

运行完gmonds后（sudo /etc/init.d/ganglia-monitor start），可以使用lsof检查连接是否建立：

akawa@hadoop-slave1:~$ sudo lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   48746 ganglia    4u  IPv4 201166172      0t0  UDP *:8649 
gmond   48746 ganglia    5u  IPv4 201166173      0t0  TCP *:8649 (LISTEN)
gmond   48746 ganglia    6u  IPv4 201166175      0t0  UDP hadoop-slave1:35702->hadoop-slave1:8649

akawa@hadoop-slave2:~$ sudo lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   31025 ganglia    6u  IPv4 383110679      0t0  UDP hadoop-slave2:60789->hadoop-slave1:8649

要查看是否实际有任何数据发送到引导节点，请使用tcpdump转储端口8649上的网络流量：

akawa@hadoop-slave1:~$ sudo tcpdump -i eth-pub udp port 8649
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth-pub, link-type EN10MB (Ethernet), capture size 65535 bytes
18:08:02.236625 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 224
18:08:02.236652 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 52
18:08:02.236661 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 236

使用调试选项

tcpdump显示某些数据已传输，但没有告诉您发送哪种数据。希望在调试模式下运行gmond或gmetad可以为我们提供更多信息（由于它不能在调试模式下作为守护程序运行，因此只需使用Ctrl + C即可停止运行）

akawa@hadoop-slave1:~$ sudo /etc/init.d/ganglia-monitor stop
akawa@hadoop-slave1:~$ sudo /usr/sbin/gmond -d 2

loaded module: core_metrics
loaded module: cpu_module
...
udp_recv_channel mcast_join=NULL mcast_if=NULL port=-1 bind=NULL
tcp_accept_channel bind=NULL port=-1
udp_send_channel mcast_join=NULL mcast_if=NULL host=hadoop-slave1.IP.address port=8649

	metric 'cpu_user' being collected now
	metric 'cpu_user' has value_threshold 1.000000
        ...............
	metric 'swap_free' being collected now
	metric 'swap_free' has value_threshold 1024.000000
	metric 'bytes_out' being collected now
 ********** bytes_out:  21741.789062
        ....
Counting device /dev/mapper/lvm0-rootfs (96.66 %)
Counting device /dev/mapper/360a980006467435a6c5a687069326462 (35.31 %)
For all disks: 8064.911 GB total, 5209.690 GB free for users.
	metric 'disk_total' has value_threshold 1.000000
	metric 'disk_free' being collected now
        .....
	sent message 'cpu_num' of length 52 with 0 errors
	sending metadata for metric: cpu_speed

我们看到收集了各种指标并将其发送到host = hadoop-slave1.IP.address port = 8649。不幸的是，它只能告诉您您是通过UDP发送的，因此无法成功传递它们。

不要混合使用IPv4和IPv6

让我们看一下集群中遇到的实际情况（这是神秘而烦人的Ganglia错误配置的根本原因）。首先，查看lsof结果。

akawa@hadoop-slave1:~$ sudo  lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   38431 ganglia    4u  IPv4 197424417      0t0  UDP *:8649 
gmond   38431 ganglia    5u  IPv4 197424418      0t0  TCP *:8649 (LISTEN)
gmond   38431 ganglia    6u  IPv4 197424422      0t0  UDP hadoop-slave1:58304->hadoop-slave1:864913:56:33

akawa@ceon.pl: akawa@hadoop-slave2:~$ sudo  lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   23552 ganglia    6u  IPv6 382340910      0t0  UDP hadoop-slave2:36999->hadoop-slave1:8649

在此，hadoop-slave2将度量发送到右侧端口上的hadoop-slave1，并且hadoop-slave1也将在右侧端口上侦听。除了一个重要的细节外，所有内容都与上一节中的代码片段几乎相同– hadoop-slave2通过IPv6发送，而hadoop-slave1通过IPv4读取！最初的猜测是更新ip6tables（除iptables之外）规则以打开端口8649，以通过IPv6进行UDP和TCP连接。但这没有用。当我们在gmond.conf文件中将主机名“ hadoop-slave1.vls”更改为其IP地址时，它就起作用了（是的，我之前在每个文件中都使用主机名而不是IP地址）。确保将您的IP地址正确解析为主机名，反之亦然。

使用gstat获取集群摘要

如果您设法将发送指标从slave2发送到slave1，则表明您的集群正在运行。在Ganglia的术语中，群集是一组主机，它们在gmond.conf文件中共享相同的群集名称属性，例如“ hadoop-slaves”。 Ganglia提供了一个有用的名为gstat的功能，它可以打印由在给定节点上运行的gmond表示的主机列表。

akawa@hadoop-slave1:~$ gstat --all
CLUSTER INFORMATION
       Name: hadoop-slaves
      Hosts: 2
Gexec Hosts: 0
 Dead Hosts: 0
  Localtime: Tue Aug 21 22:46:21 2012

CLUSTER HOSTS
Hostname                     LOAD                       CPU              Gexec
 CPUs (Procs/Total) [     1,     5, 15min] [  User,  Nice, System, Idle, Wio]
hadoop-slave2
   48 (    0/  707) [  0.01,  0.07,  0.09] [   0.1,   0.0,   0.1,  99.8,   0.0] OFF
hadoop-slave1
   48 (    0/  731) [  0.01,  0.06,  0.07] [   0.0,   0.0,   0.1,  99.9,   0.0] OFF

检查gmetad从哪里轮询指标

在运行gmetad的主机上运行以下命令，以检查其轮询度量标准的主机和主机（以某种方式grep以仅显示有用的行）：

akawa@hadoop-master:~$ nc localhost 8651 | grep hadoop

<GRID NAME='Hadoop_And_HBase' AUTHORITY='http://hadoop-master/ganglia/' LOCALTIME='1345642845'>
<CLUSTER NAME='hadoop-masters' LOCALTIME='1345642831' OWNER='ICM' LATLONG='unspecified' URL='http://ceon.pl'>
<HOST NAME='hadoop-master' IP='hadoop-master.IP.address' REPORTED='1345642831' TN='14' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345632023'>
<CLUSTER NAME='hadoop-slaves' LOCALTIME='1345642835' OWNER='ICM' LATLONG='unspecified' URL='http://ceon.pl'>
<HOST NAME='hadoop-slave4' IP='...' REPORTED='1345642829' TN='16' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345478489'>
<HOST NAME='hadoop-slave2' IP='...' REPORTED='1345642828' TN='16' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345581519'>
<HOST NAME='hadoop-slave3' IP='...' REPORTED='1345642829' TN='15' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345478489'>
<HOST NAME='hadoop-slave1' IP='...' REPORTED='1345642833' TN='11' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345572002'>

备择方案

由于监视群集是一个非常广泛的主题，因此有许多工具可以帮助您完成此任务。对于Hadoop集群，除了Ganglia之外，您还可以找到许多其他有趣的替代方案。我只想简短地提到其中的几个。

Cloudera Manager 4（企业）

除了极大地简化Hadoop集群的安装和配置过程外，Cloudera Manager还提供了一些有用的功能来监视和可视化Hadoop的数十种服务性能指标以及与主机相关的信息，包括CPU，内存，磁盘使用率和网络I / O。此外，它会在您接近关键阈值时向您发出警报（Ganglia本身不提供警报，但可以与Nagios和Hyperic等警报系统集成）。您可以在此处了解有关Cloudera Manager关键功能的更多信息。

仙人掌，Zabbix，Nagios，Hyperic

请访问仙人掌网站以了解有关此工具的更多信息。这也是有关使用Cacti进行Hadoop Graphing的非常有趣的博客文章。 Zabbix ， Nagios和Hyperic是您可能还需要研究的工具。

致谢

我要非常感谢我的同事Pawel Tecza和Artur Czeczko，他们帮助我在集群上配置和调试了Ganglia。

参考： 针对小型Hadoop集群的Ganglia配置以及 Hakuna MapData的 JCG合作伙伴 Adam Kawa的一些疑难解答！博客。

翻译自: https://www.javacodegeeks.com/2013/04/ganglia-configuration-for-a-small-hadoop-cluster-and-some-troubleshooting.html

hadoop小型集群

dnc8371

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
hadoop小型集群_小型Hadoop集群的Ganglia配置和一些故障排除

hadoop小型集群 Ganglia是一个针对大型集群的开源，可扩展且分布式的监视系统。它收集，汇总并提供数十种与计算机相关的指标（例如CPU，内存，存储，网络使用情况）的时序视图。您可以在UC Berkeley Grid上看到Ganglia的运行情况。 Ganglia也是监视Hadoop和HBase群集的流行解决方案，因为Hadoop（和HBase）具有将其度量发布到Ganglia的...
复制链接

扫一扫