
如何构建最优化的Hadoop集群
推荐于2016-11-11 · 知道合伙人数码行家

知道合伙人数码行家
向TA提问 私信TA

本文将逐步介绍这些部分的安装和配置:
•网络体系结构
•操作系统
•硬件要求
•Hadoop软件安装/设置
网络架构
根据我们目前能够拿到的文档,可以认为云内的节点越在物理上接近,越能获得更好的性能。根据经验,网络延时越小,性能越好。
为了减少背景流量,我们为这个云创建了一个虚拟专用网。另外,还为应用服务器们创建了一个子网,作为访问云的入口点。
这个虚拟专用网的预计时延大约是1-2毫秒。这样一来,物理临近性就不再是一个问题,我们应该通过环境测试来验证这一点。
建议的网络架构:
•专用TOR(Top of Rack)交换机
•使用专用核心交换刀片或交换机
•确保应用服务器“靠近”Hadoop
•考虑使用以太网绑定
操作系统
我们选择Linux作为操作系统。Linux有许多不同的发行版,包括Ubuntu、RedHat和CentOS等,无论选择哪一个都可以。基于支持和许可费用的考虑,我们最终选择了CentOS 5.7。最好是定制一个CentOS的映像,把那些需要的软件都预装进去,这样所有的机器可以包含相同的软件和工具,这是一个很好的做法。
根据Cloudera的建议,OS层应该采用以下设置:
•文件系统
Ext3文件系统
取消atime
不要使用逻辑卷管理
•利用alternatives来管理链接
•使用配置管理系统(Yum、Permission、sudoers等)
•减少内核交换
•撤销一般用户访问这些云计算机的权限
•不要使用虚拟化
•至少需要以下Linux命令:
/etc/alternatives
ln、chmod、chown、chgrp、mount、umount、kill、rm、yum、mkdir
硬件要求
由于Hadoop集群中只有两种节点(Namenode/Jobtracker和Datanode/Tasktracker),因此集群内的硬件配置不要超过两种或三种。
硬件建议:
•Namenode/Jobtracker:1Gb/s以太网口x2、16GB内存、4个CPU、100GB磁盘
•Datanode:1Gb/s以太网口x2、8GB内存、4个CPU、多个磁盘,总容量500GB以上
实际的硬件配置可以与我们建议的配置不同,这取决于你们需要存储和处理的数据量。但我们强烈建议不要在集群中混用不同的硬件配置,以免那些较弱的机器成为系统的瓶颈。
Hadoop的机架感知
Hadoop有一个“机架感知”特性。管理员可以手工定义每个slave数据节点的机架号。为什么要做这么麻烦的事情?有两个原因:防止数据丢失和提高网络性能。
为了防止数据丢失,Hadoop会将每个数据块复制到多个机器上。想象一下,如果某个数据块的所有拷贝都在同一个机架的不同机器上,而这个机架刚好发生故障了(交换机坏了,或者电源掉了),这得有多悲剧?为了防止出现这种情况,必须要有一个人来记住所有数据节点在网络中的位置,并且用这些知识来确定——把数据的所有拷贝们放在哪些节点上才是最明智的。这个“人”就是Name Node。
另外还有一个假设,即相比不同机架间的机器,同一个机架的机器之间有着更大的带宽和更小的延时。这是因为,机架交换机的上行带宽一般都小于下行带宽。而且(+本站微信networkworldweixin),机架内的延时一般也小于跨机架的延时(但也不绝对)。
机架感知的缺点则是,我们需要手工为每个数据节点设置机架号,还要不断地更新这些信息,保证它们是正确的。要是机架交换机们能够自动向Namenode提供本机架的数据节点列表,那就太棒了。