hadoop作为一门拥有很多年历史的技术,虽然公开资料很多,但对于企业生产环境到底怎样管理好一个hadoop集群资料还是很少的。从今天开始,笔者会将几年来hadoop在生产环境管理经验介绍给各位,希望可以帮助到大家。
1、首先说使用哪个版本的hadoop,如果你碰巧有从0到1建设一家公司hadoop的机会的话,建议使用较新的版本,原因如下:
hadoop是个一旦使用就会应用在很多台节点的服务,升级版本是重量级的操作;
现实来说,99%的公司对于hadoop都没有什么深度定制能力,大概率你给你们hadoop迭代的能力比社区慢的多,所以这个情况下,就需要你尽量依赖社区版本所能提供的hadoop特性,那么高版本就需要优先考虑了;
最新版本各种没有人踩过的地雷,所以使用“较新”的版本。
2、搭建一个生产环境的hadoop环境的要点
如何搭建出个能“用”的集群,资料太多了,各位请自行查阅。一言以蔽之:按照服务的依赖树从根节点开始搭建,每次启动新服务,都要检查好状态。
下面重点介绍一些企业生产环境搭建时就需要注意的事项(换句话说等搭建完再想起来,再想弥补就很麻烦啦),而不是简简单单能“用”:
1)一定要确定好服务日志的删除方案,例如namenode日志怎么删,datanode日志怎么删。 最简单的方式是使用RollingFileAppender 让log4j帮你删
2)datanode的数据目录,nodemanager的数据目录是可以配置多块磁盘的,一定要配置多块磁盘保证磁盘重复利用
3)性能参数,按照未来一段时间可以达到的节点数来预估
4)配置中对于服务的配置尽量使用域名而不是ip地址。原因是域名可以通过公司运维的支持改变它所解析成的ip,这样未来即使因为某种不可抗力原因你要迁移服务(例如namenode),域名可以不变,那么一票客户端都不需要修改配置
5)机架感知。一谈hadoop,大家都知道“移动计算而不是移动数据”,“计算本地化”。 这些对于性能有重大影响的特性,都需要hadoop集群本身知道节点,机架等的信息才可以生效。机架感知是需要重启集群来更新的,因此搭建的时候尽可能把所有datanode的机架感知都配置好。
6)gc日志。这也是需要重启才能开启的功能,gc日志对于我们分析故障,了解服务性能非常重要,建议搭集群的时候就开启。
7)审计日志。这也是默认不开启的,是否要开启要注意一下
8)选择一个适合自己的Yarn调度器,FairScheduler和CapacityScheduler在功能上有很大的不同,需要做合适的选型。这点非常重要,如果变更调度器,不仅要重启Resourcemanager,还需要所有任务变更queue的配置,绝对重量级的操作。
3、hadoop的监控:
通过端口存活性可以判断出服务是否正常,这是最基础同时也是最重要的监控。
更进一步,需要服务器的基础指标,例如五分钟负载,cpu,内存情况等,这些信息可以帮助排查单个节点所导致的问题。
再进一步,需要hadoop自身服务的性能指标,例如rpc接口的耗时等,有这些指标才可以指导对于hadoop的改造和优化。
4、日常运维操作:
hadoop是集群性质的服务,节点数量多,需要协助批量操作的工具,或者自研运维平台。
一个正常发展的公司,hadoop节点会随着业务增长也不断增长,最好通过脚本把这个过程自动化,一个好的扩容脚本需要包含以下功能: 自动识别磁盘信息;自动了解服务器内存cpu容量;自动安装datanode;自动安装nodemanager;自动添加监控。
由于oom-killer等原因, nodemanager或datanode偶尔挂掉是很正常的现象,为了保证服务稳定性,最好在每台节点都部署一个自动拉起的脚本,会方便很多。
对于主节点的变更,在变更前一定要在测试环境测试好,变更需要做好详细的方案,包含如何变更,如何回滚等内容。
总结:
本文着重介绍了将一个hadoop集群push到线上可用的重要技术点,难度并不高,对于hadoop的管理者只是一个入门。想要管理好hadoop,还需要对hadoop各方面的原理机制有深入的掌握。这些内容后续有机会再探讨。