我们选择Linux作为 *** 作系统。Linux有许多不同的发行版,包括Ubuntu、RedHat和CentOS等,无论选择哪一个都可以。基于支持和许可费用的考虑,我们最终选择了CentOS 57。最好是定制一个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),因此集群内的硬件配置不要超过两种或三种。
图2 - Hadoop集群服务器角色
硬件建议:
Namenode/Jobtracker:1Gb/s以太网口x2、16GB内存、4个CPU、100GB磁盘
Datanode:1Gb/s以太网口x2、8GB内存、4个CPU、多个磁盘,总容量500GB以上
实际的硬件配置可以与我们建议的配置不同,这取决于你们需要存储和处理的数据量。但我们强烈建议不要在集群中混用不同的硬件配置,以免那些较弱的机器成为系统的瓶颈。
Hadoop的机架感知
Hadoop有一个“机架感知”特性。管理员可以手工定义每个slave数据节点的机架号。为什么要做这么麻烦的事情有两个原因:防止数据丢失和提高网络性能。
图3 - Hadoop集群的机架感知
为了防止数据丢失,Hadoop会将每个数据块复制到多个机器上。想象一下,如果某个数据块的所有拷贝都在同一个机架的不同机器上,而这个机架刚好发生故障了(交换机坏了,或者电源掉了),这得有多悲剧为了防止出现这种情况,必须要有一个人来记住所有数据节点在网络中的位置,并且用这些知识来确定——把数据的所有拷贝们放在哪些节点上才是最明智的。这个“人”就是Name Node。
另外还有一个假设,即相比不同机架间的机器,同一个机架的机器之间有着更大的带宽和更小的延时。这是因为,机架交换机的上行带宽一般都小于下行带宽。而且,机架内的延时一般也小于跨机架的延时(但也不绝对)。
机架感知的缺点则是,我们需要手工为每个数据节点设置机架号,还要不断地更新这些信息,保证它们是正确的。要是机架交换机们能够自动向Namenode提供本机架的数据节点列表,那就太棒了。
Hadoop软件的安装和配置
Hadoop集群有多种构建方式:
手工下载tar文件并复制到集群中
利用Yum仓库
利用Puppet等自动化部署工具
我们不建议采用手工方式,那只适合很小的集群(4节点以下),而且会带来很多维护和排障上的问题,因为所有的变更都需要用scp或ssh的方式手工应用到所有的节点上去。
从以下方面来看,利用Puppet等部署工具是最佳的选择:
安装
配置
维护
扩展性
监控
排障
Puppet是Unix/Linux下的一个自动化管理引擎,它能基于一个集中式的配置执行增加用户、安装软件包、更新服务器配置等管理任务。我们将主要讲解如何利用Yum和Puppet来安装Hadoop。
利用Yum/Puppet搭建Hadoop集群
要利用Puppet搭建Hadoop集群,首先要符合以下前置条件:
包含所有必需Hadoop软件的中央仓库
用于Hadoop部署的Puppet装载单(manifest)
用于Hadoop配置管理的Puppet装载单
用于集群维护的框架(主要是sh或ksh脚本),以支持集群的start/stop/restart
利用puppet构建整个服务器(包括 *** 作系统和其它软件)
注:如果要用Yum来安装Hadoop集群,则所有服务器应该预先构建完成,包括 *** 作系统和其它软件都应安装完毕,yum仓库也应在所有节点上设置完毕。
构建Datanode/Tasktracker
如果用Yum安装Datanode/Tasktracker,需在所有数据节点上执行以下命令:
yum install hadoop-020-datanode –y
yum install hadoop-020-tasktracker –y
换成Puppet的话,则是:
class setup_datanode {
if ($is_datanode == true) {
make_dfs_data_dir { $hadoop_disks: }
make_mapred_local_dir { $hadoop_disks: }
fix_hadoop_parent_dir_perm { $hadoop_disks: }
}
# fix hadoop parent dir permissions
define fix_hadoop_parent_dir_perm() {
…
}
# make dfs data dir
define make_dfs_data_dir() {
…
}
# make mapred local and system dir
define make_mapred_local_dir() {
…
}
} # setup_datanode
构建Namenode(及辅助Namenode)
如果用Yum安装Namenode,需在所有数据节点上执行以下命令:
yum install hadoop-020-namenode –y
yum install hadoop-020-secondarynamenode –y
换成Puppet的话,则是:
class setup_namenode {
if ($is_namenode == true or $is_standby_namenode == true) {
}
exec {"namenode-dfs-perm":
}
exec { "make ${nfs_namenode_dir}/dfs/name":
}
exec { "chgrp ${nfs_namenode_dir}/dfs/name":
}
if ($standby_namenode_host != "") {
}
exec { "own $nfs_standby_namenode_dir":
}
}
# /standby_namenode_hadoop
if ($standby_namenode_host != "") {
}
exec { "own $standby_namenode_hadoop_dir":
}
}
}
}
class setup_secondary_namenode {
if ($is_secondarynamenode == true) {
}
}
exec {"namenode-dfs-perm":
}
}
}
构建JobTracker
如果用Yum安装Jobtracker,需在所有数据节点上执行以下命令:
yum install hadoop-020-jobtracker –y
换成Puppet的话,则是使用与构建Namenode相同的装载单,唯一的区别在于,在Jobtracker机器上,会启动Jobtracker——即将该机器上的is_jobtracker设置为true。在Hadoop 20之前,只有namenode一个节点,存在单点问题,namenode单点故障,难以应用与在线场景,也不利于生产上维护集群。namenode压力过大,且内存受损,影响系统延展性。0
HA:高可用集群(High Availability Cluster),是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务,把因软件、硬件、人为造成的故障对业务的影响降到最小。
在hadoop20引入了HA机制。hadoop20的HA机制官方介绍了有2种方式,一种是NFS(Network File System)方式,另外一种是QJM(QuorumJournal Manager)方式。
NFS(Network File System)
在QJM出现之前,为保障集群的HA,设计的是一种基于NAS的共享存储机制,即主备NameNode间通过NAS进行元数据的同步。该方案有什么缺点呢,主要有以下几点:
1 定制化硬件设备:必须是支持NAS的设备才能满足需求
2 复杂化部署过程:在部署好NameNode后,还必须额外配置NFS挂载、定制隔离脚本,部署易出错
3 简陋化NFS客户端:Bug多,部署配置易出错,导致HA不可用
所以对于替代方案而言,也必须解决NAS相关缺陷才能让HA更好服务。即设备无须定制化,普通设备即可配置HA,部署简单,相关配置集成到系统本身,无需自己定制,同时元数据的同步也必须保证完全HA,不会因client问题而同步失败。所以引出了QJM方式。
QJM全称是Quorum Journal Manager, 由JournalNode(JN)组成,一般是奇数点结点组成。每个JournalNode对外有一个简易的RPC接口,以供NameNode读写EditLog到JN本地磁盘。当写EditLog时,NameNode会同时向所有JournalNode并行写文件,只要有N/2+1结点写成功则认为此次写 *** 作成功,遵循Paxos协议。性能运行快。Docker容器是一个开源的应用容器引擎,搭建hadoop好处是提供比传统虚机更好的性能,运行更快。docker让开发者可以以统一的方式打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何安装了docker引擎的服务器上也可以实现虚拟化。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)