翻译自:How-to: Deploy Apache Hadoop Clusters Like a Boss
源文章链接:https://blog.cloudera.com/how-to-deploy-apache-hadoop-clusters-like-a-boss/

简介

       虽然可见这是一篇15年的博客,但至今为止我安装大数据时候一些基础考量还是会参照这个,个人感觉写的非常不错,百度似乎没有找到翻译版本,随便结合自己的经验写一下这个。要看英文原版还是看顶上链接哈。
       这篇文章没有具体的描述如何搭建大数据环境,而是着重于一些重要的系统和硬件优化,可以避免一些日后需要伤经动骨才能修改的问题,适合刚搭建完成或者将要搭建的朋友参考下。

了解如何以最大程度地成功实现Hadoop生产化并最大程度地减少正在进行的长期调整的方式设置Hadoop集群。

       以前,我们发布了一些建议,有关为Apache Hadoop部署选择新硬件的建议。那篇文章涵盖了有关群集规划和部署的一些重要想法,例如工作负载分析以及有关CPU,磁盘和内存分配的一般建议。在这篇文章中,我们将为实施过程的下一部分提供一些最佳做法和准则:机器到达后进行配置。在这两篇文章之间,您将朝着将生产规模化的Hadoop迈进一个很好的起点。
       具体来说,我们将介绍您必须做出的一些重要决定,以确保正确配置网络,磁盘和主机。我们还将说明如何布置磁盘和服务,以便有效利用数据并在数据集扩展时最大程度地减少问题。

网络模块:愿您所有的SYN都被原谅

       主机名解析方案,DNS和FQDNS
       诸如DataNode之类的Hadoop Java进程获取正在其上运行的主机的主机名,然后进行查找以确定IP地址。然后,它将使用此IP确定存储在DNS服务或在本地的/etc/hosts中的规范名称。每个主机必须能够在其自己的主机名上执行正向查找,并能够使用其自己的IP地址执行反向查找。此外,群集中的所有主机都需要解析其他主机。您可以使用Linux host命令验证正向和反向查找是否已正确配置。

$ host `hostname`
bp101.cloudera.com has address 10.20.195.121
$ host 10.20.195.121
121.195.20.10.in-addr.arpa domain name pointer bp101.cloudera.com

Cloudera Manager 使用一个简单的python指令来测试解析

$ python -c 'import socket; print socket.getfqdn(), socket.gethostbyname(socket.getfqdn())'

       虽然很想依靠/etc/hosts进行此步骤,但我们建议改用DNS。 DNS与使用hosts文件相比,不容易出错,并且使更改更容易实现。主机名应设置为标准域名(FQDN)。重要的是要注意,使用Kerberos需要使用FQDN,这对于启用安全功能(例如TLS加密和Kerberos)很重要。您可以使用如下指令来进行验证:

$ hostname --fqdn
bp101.cloudera.com

       如果使用的是/etc/hosts 文件进行控制的话,请确认是否用了适当的顺序来排列他们

192.168.2.1 bp101.cloudera.com bp101 master1
192.168.2.2 bl102.cloudera.com bp102 master2

名称服务器缓存

       Hadoop广泛使用基于网络的服务,例如DNS,NIS和LDAP。为了帮助缓解网络故障,减轻共享基础结构的压力并改善名称解析的延迟,启用名称服务器缓存守护程序(nscd)可能会有所帮助。 nscd将本地和远程调用的结果都缓存在内存中,通常避免了潜在的网络往返。在大多数情况下,您可以启用nscd,让它工作,然后再将其保留。如果您运行的是红帽系统 SSSD 协议,则需要修改nscd配置;在启用SSSD的情况下,请勿使用nscd缓存passwd,group或netgroup信息。
网关设备链路聚合(LINK AGGREGATION)
       也称为NIC绑定或NIC分组,是指组合网络接口以提高吞吐量或冗余。确切的设置将取决于您的环境。
       绑定接口有很多不同的方法。通常,我们建议绑定吞吐量而不是可用性,但这种权衡将在很大程度上取决于接口的数量和内部网络策略。 NIC绑定是Cloudera错误配置的最高级驱动程序之一。我们通常建议在启用绑定之前启用集群并验证所有工作,这将有助于解决您可能遇到的任何问题。

个人意见:自建机房的话,不要在乎1,2个网关的成本,链路聚合对于吞吐量还是很有效的,特别现在数据量都越来越大的情况下,不要让交换机的流量限制了你物理机的万兆口们。

虚拟局域网(VLAN)

       VLAN不是必需的,但是从网络角度来看,它们可以使事情变得更容易。建议迁移到专用的交换基础结构以进行生产部署,以尽可能多地利用网络上的其他流量。然后,确保所有Hadoop流量都在一个VLAN上,以便于故障排除和隔离。

个人意见:如果是自建IDC,主机摆放的时候记得机架敏感哦,还有master尽量分开放,VLAN给个大点的就行,如果都是一个集群的,内部其实没必要分的太细。

操作系统(OS)

       Cloudera Manager在识别操作系统配置中的已知和常见问题方面做得很好,但是请仔细检查以下内容:

防火墙(IPTABLES)

       一些客户在其初始群集设置中完全禁用了IPTABLES。当然,从管理的角度来看,这样做使事情变得容易,但同时也带来了一些风险。根据群集中数据的敏感性,您可能希望启用IPTABLES。 Hadoop需要许多端口才能通过众多生态系统组件进行通信,但是我们的文档将帮助您进行配置。
附赠CDH端口官方表链接:https://docs.cloudera.com/documentation/manager/5-0-x/Cloudera-Manager-Installation-Guide/cm5ig_config_ports.html

个人意见:Iptbales,或者Centos7默认的firewalld还是有必要开启的,有备无患,实在慵懒的可以设置对内网开启全部端口开放的策略。

SELINUX

       构建管理Hadoop生态系统中所有不同组件的SELINUX策略是一项挑战,因此我们的大多数客户都在禁用SELINUX的情况下运行。如果您对运行SELINUX感兴趣,请确保验证它是否在受支持的OS版本上。我们建议仅在开始时才启用许可模式,以便您可以捕获输出以定义满足您需求的策略。

个人意见:SELINUX太麻烦了,去掉吧,disable把。

交换内存(SWAPPINESS)

       对于工作程序节点的传统建议是将swappiness(vm.swappiness)设置为0。但是,此行为在较新的内核中已更改,我们现在建议将其设置为1。(本文有更多详细信息。)

$ sysctl vm.swappiness=1
$ echo "vm.swappiness = 1" >> /etc/sysctl.conf

系统LIMITS设置

       大多数发行版的默认文件句柄限制(即ulimits)1024可能设置得不够高。 Cloudera Manager将解决此问题,但是如果您没有运行Cloudera Manager,请注意这一事实。 Cloudera Manager不会在Hadoop的默认限制之外更改用户的限制。尽管如此,将全局限制提高到64k仍然是有益的。

透明大页面(THP)

       CDH 5支持的大多数Linux平台都包含一个称为“透明大页面压缩”的功能,该功能与Hadoop工作负载的交互性很差,并且可能严重降低性能。 Red Hat声称6.4以后的版本已修复了该错误,但仍然存在会导致性能问题的残余。我们建议禁用碎片整理,直到可以进行进一步的测试为止。
如下是不同系统的defrag_file_pathname的路径
Red Hat / CentOS:/sys/kernel/mm/redhat_transparent_hugepage/defrag
Ubuntu / Debian,OEL,SLES:/sys/kernel/mm/transparent_hugepage/defrag

$ echo 'never' > defrag_file_pathname

切记把相关语句加到 /etc/rc.local ,不然重启无效就很尴尬.

时区
       每台服务器都要安装NTP服务并确保其可用

存储(Storage)

       正确配置群集的存储是最重要的初始步骤之一。未能正确执行此操作将导致痛苦,因为更改配置可能是毁灭性的,通常需要完全重做当前存储层。

操作系统,日志驱动器和数据驱动器

       典型的2U机器配备有16至24个驱动器托架,用于专用数据驱动器,以及一些专用于操作系统和日志的驱动器(通常为两个)。 Hadoop的设计原则很简单:“硬件失败”。这样,它将承受磁盘,节点甚至机架故障。 (这一原则确实开始在大规模领域得到普及,但让我们面对现实吧:如果您正在阅读此博客,则可能不在Google或Facebook。)
       即使在正常人规模(少于4,000个节点)下,Hadoop仍可以像老板一样经受住硬件故障的影响,但合理的做法是增加一些额外的冗余以减少这些故障。作为一般准则,我们建议对OS驱动器(即系统盘根路径所在的硬盘)使用RAID-1(镜像),以在丢失OS驱动器的情况下使数据节点的滴答声保持更长的时间。尽管这一步骤并非绝对必要,但是在较小的群集中,一个节点的丢失可能会导致计算能力的显着降低。
       其他驱动器应在运行RHEL6 +,Debian 7.x或SLES11 +的系统上以JBOD(“一堆磁盘”)配置,并带有单独安装的ext4分区。在某些硬件配置文件中,当必须为该特定计算机构建强制使用RAID控制器时,必须使用单个RAID-0卷。这种方法与将驱动器安装为单个主轴的效果相同。
       有一些挂载选项可能有用。这些内容在Hadoop Operations这本书中都有很好的介绍,作者Alex Moundalexis,在这里就稍微提一句。

根目录保留空间需求

       默认情况下,ext3和ext4都为根用户保留给定文件系统上5%的块。 HDFS数据目录不需要此保留,但是您可以在创建分区时或分别使用mkfs和tune2fs之后将其调整为零。

个人意见:不建议调整为0,没必要,分配合理的话根目录其实用的空间很小,非master节点,不存储数据只放程序的情况下,哪怕普通300G的硬盘也绰绰有余。尊重原创的情况下,还是放下清零指令

$ mkfs.ext4 -m 0 /dev/sdb1
$ tune2fs -m 0 /dev/sdb1

文件系统Access Time配置

       Linux文件系统维护元数据,该元数据记录了上次访问每个文件的时间,因此,甚至读取也会写入磁盘。此时间戳称为atime(即Access Time),应在为Hadoop配置的驱动器上禁用此时间戳。通过/etc/fstab中的mount选项进行设置:

/dev/sdb1 /data1    ext4    defaults,noatime       0

配置好之后可以不重启生效,指令如下.

mount -o remount /data1

目录权限

       这只是次要点,但是在装入数据驱动器之前,应考虑将目录的权限更改为700。因此,如果卸载驱动器,则写入这些目录的进程将不会填满OS挂载。

LVM, RAID or JBOD(三种硬盘的展现方式)

       经常询问我们是否需要JBOD配置,RAID配置或LVM配置。整个Hadoop生态系统的创建都考虑了JBOD配置。 HDFS是一个不变的文件系统,旨在用于具有较长顺序读取的大型文件。此目标与独立SATA驱动器配合使用非常好,因为它们通过顺序读取可获得最佳性能。总之,RAID通常用于向现有系统添加冗余,而HDFS已经内置了冗余。实际上,将RAID系统与Hadoop一起使用可能会对性能产生负面影响。
       RAID-5和RAID-6都将奇偶校验位添加到RAID条带中。这些奇偶校验位必须在标准操作期间进行写入和读取,并且会增加大量开销。独立的SATA驱动器将连续写入/读取,而无需担心奇偶校验位,因为它们不存在。相比之下,HDFS利用具有多个单独的挂载点的优势,并且可以允许单个驱动器/卷在节点发生故障之前发生故障-这不是HDFS并行I / O的秘密。在RAID-5或RAID-6阵列中设置驱动器将根据驱动器配置创建单个阵列或几个非常大的安装点阵列。这些RAID阵列将破坏HDFS对数据保护的自然促进,减慢顺序读取速度以及Map任务的数据局部性。
RAID阵列也会影响其他需要大量安装点的系统。例如,Impala会在系统中为每个主轴增加一个线程,与大型的单个RAID组相比,它在JBOD环境中将具有良好的性能。出于相同的原因,既不需要也不建议在LVM下配置Hadoop驱动器。

个人观点:简而言之,除了系统盘RAID1之外 其他的尽量JBOD,实在不行就RAID0 千万千万千万不要LVM!!!

混合硬件部署

       许多客户定期购买新硬件;随着数据量和工作量的增加,添加新一代的计算资源是有意义的。对于包含异构磁盘,内存或CPU配置的此类环境,Cloudera Manager允许使用角色组,管理员可以使用角色组来指定每个节点或每个节点组的内存,YARN容器和Cgroup设置。
       尽管Hadoop当然可以在混合硬件规格下运行,但是我们建议尽可能保持工作节点配置相同。在分布式计算环境中,工作负载分布在各个节点之间,因此最好对本地数据访问进行优化。配置了较少计算资源的节点可能会成为瓶颈,并且使用混合硬件配置运行可能会导致SLA窗口变化更大。有几件事情要考虑:

  • 混合硬盘配置–默认情况下,HDFS块放置在dfs.data.dir指定的所有目录中以循环方式工作。例如,如果您的节点具有六个1.2TB驱动器和六个600GB驱动器,则将更快地填充较小的驱动器,从而导致容量不平衡。使用“可用空间”策略需要额外的配置,在这种情况下,I / O绑定的工作负载可能会受到影响,因为您可能只在写入磁盘的一部分。预先了解以这种方式部署驱动器的含义。此外,如果您部署具有更多整体存储的节点,请记住HDFS按百分比平衡。
  • 混合内存配置–在工作节点中混合可用内存可能会出现问题,因为它确实需要其他配置。
  • 混合CPU配置–相同的概念;作业可能受到最慢的CPU的限制,从而实际上抵消了运行更新/更多内核的好处。
    了解以上几点很重要,但是请记住,Cloudera Manager可以帮助将资源分配给不同的主机。使您可以轻松管理和优化配置。

    个人观点:硬盘配置问题不大,特别是整体存储量没有满负荷(85%以上)的时候,但包括内存频率,CPU计算能力确实会造成一定差异,但也无需吹毛求疵,不要差太多就行,YARN计算主要还是按容易跑,一般单核在系统正常运行前提下,不会差的太离谱。

霸气配置CDH Manager(Cloudera Manager Like A Boss)

       我们强烈建议使用Cloudera Manager管理您的Hadoop集群。 Cloudera Manager提供了许多有价值的功能,使生活更加轻松。 Cloudera Manager文档对此非常清楚,但是为了消除任何歧义,下面是使用Cloudera Manager进行生产就绪的Hadoop部署的高级步骤。
1,设置一个外部数据库并预创建部署所需的架构。(MySQL的例子,记得改密码)
create database amon DEFAULT CHARACTER SET utf8;
grant all on amon. TO 'amon'@'%' IDENTIFIED BY 'amon_password';
create database rman DEFAULT CHARACTER SET utf8;
grant all on rman.
TO 'rman'@'%' IDENTIFIED BY 'rman_password';
create database metastore DEFAULT CHARACTER SET utf8;
grant all on metastore. TO 'metastore'@'%' IDENTIFIED BY 'metastore_password';
create database nav DEFAULT CHARACTER SET utf8;
grant all on nav.
TO 'nav'@'%' IDENTIFIED BY 'nav_password';
create database sentry DEFAULT CHARACTER SET utf8;
grant all on sentry.* TO 'sentry'@'%' IDENTIFIED BY 'sentry_password';
(Please change the passwords in the examples above!)

2,根据文档安装cloudera-manager-server和cloudera-manager-daemons软件包。

yum install cloudera-manager-server cloudera-manager-daemons

原文就给了一个安装指令,,有点偷懒的感觉,具体各位可以先看官方安装文档,我觉得还是蛮详细的
附赠链接:https://docs.cloudera.com/documentation/enterprise/release-notes/topics/rg_release_notes.html

3, 运行scm_prepare_database.sh脚本确定数据库类型.

/usr/share/cmf/schema/scm_prepare_database.sh mysql -h cm-db-host.cloudera.com -utemp -ptemp --scm-host cm-db-host.cloudera.com scm scm scm

注:这个写的比较早了,现在新版本CDH不一定用这个脚本了

4,启动Cloudera Manager Service,然后从那时开始遵循向导。
这是安装Cloudera Manager的最简单方法,它将使您在20分钟内开始进行生产就绪型部署
注:所谓的向导应该就是启动 master:7180端口之后的网页向导,具体安装还是见上方链接靠谱

发挥作用:服务布局指南

       对于基于Cloudera Manager的部署,下图提供了一种合理的方法,可以在大多数配置中跨集群布置服务角色。
如何霸气的安装CDH大数据环境(附个人见解)

       在较大的群集(50个以上的节点)中,可能需要移动到五个管理节点,并为ResourceManager和NameNode对使用专用节点。此外,为Cloudera Manager,Hive Metastore等使用外部数据库并不罕见,并且还可以部署其他HiveServer2或HMS服务。
       我们建议每个管理节点128GB,工作节点256-512GB。内存相对便宜,并且随着计算引擎越来越依赖于内存中执行,额外的内存将得到充分利用。
       深入探讨一下,以下图表描述了到各种服务存储组件的适当磁盘映射。
如何霸气的安装CDH大数据环境(附个人见解)

如何霸气的安装CDH大数据环境(附个人见解)

       我们在此处为Cloudera Manager数据库指定使用LVM,但是RAID 0也可以选择。
注:这点我并不赞同,数据库其实最忌讳这个,用RAID1把
如何霸气的安装CDH大数据环境(附个人见解)

结论
       一旦拥有适当的知识,建立Hadoop集群就相对简单了。花额外的时间购买正确的基础架构并从一开始就正确配置它。遵循上述准则将为您提供在Hadoop部署中获得成功的最佳机会,并且您可以避免对配置进行麻烦,从而使您可以将时间集中在解决真正的业务问题上,例如老板。

个人观点:整片文章,许多还是可借鉴的,非常不错,大多数人的集群,不会上千台,都可以参照这个做一定的配置