标签归档:ipv6

hadoop集群升级到yarn遇到的数据本地化(data-locality)很低的问题分析

最近将hadoop集群从hadoop-2.0.0-mr1-cdh4.1.2升级到hadoop-2.0.0-cdh4.3.0,遇到了一些任务(如scan hbase table)数据本地化data-local很低的问题,原因就是前篇文章中说到的ipv4和ipv6导致的机器名长短问题。本文是对整个过程的分析。

我们的yarn集群采用的是capacity-scheduler调度,data-local很低的原因是:机器名不一致,导致分配container时无法匹配上。在yarn内部(NodeManager)用的机器名是 test042097.sqa.cm4 这种短的,而job的split信息(如scan hbase)里面带的机器名是 test042097.sqa.cm4.site.net 这种完整机器名。

在 ResourceManager 分配container的地方:(RMContainerAllocator.java:967行)

代码里面是按照 host, rack, any 三种方式顺序匹配的,在 mapsHostMapping 里面存的是资源的请求,<hostname, List<TaskAttemptId>>,意思是对请求在某台机器上启动几个task。hostname是来自于job输入的split信息,比如扫描hbase表的job,split信息里面就有region所在的机器信息。

在hbase里面,用到的机器名都是 test042097.sqa.cm4.site.net 这种带了 site.net 后缀的,所以mapsHostMapping的key就是 test042097.sqa.cm4.site.net。而Yarn的NodeManager所用的机器名都是 test042097.sqa.cm4 这种不带后缀的,也就是 allocated.getNodeId().getHost();的值。因此机器名是没法匹配上的。


后来,我们的集群采用斯盛同学提出的改法:“每台机器一个rack”后,rack local比例提高了很多,此时的rack local其实就是data locale。

这样改后,上面的代码中 RackResolver.resolve(host).getNetworkLocation(); 这个会调用集群配置的rack脚本,会读取一个rack文件信息:

所以,通过search042097.sqa.cm4可以映射到 /rack/4,与 mapsRackMapping 中的数据就匹配上了。(mapsRackMapping中存有请求的资源rack信息,yarn中的资源请求是超额请求的,用一个申请三个,主机+机架+any)

YARN中的NodeManager获取hostname的地方,是在ContainerManagerImpl.java:243行

底层调用的是jdk的 方法,得到的是 search042097.sqa.cm4 这种短主机名。

而普通map … --> 阅读全文

java网络编程中ipv4和ipv6导致的机器名长短问题

使用了Java网络编程,涉及到ipv4和ipv6的问题,在hadoop集群中由于机器配置不一,会导致不同机器获取的机器名长短不一,从而引发一系列问题,如“hadoop或yarn集群任务数据本地化很差(后面会写篇文章进行分析)”。

FQDN是Fully Qualified Domain Name的缩写, 含义是完整的域名。例如, 一台机器主机名(hostname)是www, 域后缀(domain)是example.com, 那么该主机的FQDN应该是www.example.com.。其实FQDN最后是以”.”来结尾的, 但是大部分的应用和服务器都允许忽略最后这个点。

Linux下用户可以通过hostname命令查看并设置主机名. 用户也可以通过

hostname -f

命令得到该主机的FQDN。

java文档中的说法是:

java.net.preferIPv4Stack (default: false)
If IPv6 is available on the operating system, the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept … --> 阅读全文