集群应用及运维经验小结

作者: 大圆那些事 | 文章可以转载,请以超链接形式标明文章原始出处和作者信息

网址: http://www.cnblogs.com/panfeng412/archive/2013/06/27/cluster-use-and-maintain-experience-summary.html

本人目前很重要的一部分工作是参与或负责部门内一些集群的维护、应用开发以及优化,其中包括:HBase集群、Storm集群、Hadoop集群、Super Mario集群(部门内部开发的实时流处理系统)等,随着业务的拓展,集群机器数已经小有规模。

接下来是我对自己这1年多以来,在集群应用与运维方面所做事情的梳理与总结。以下内容有些零散,大家姑且当做一篇非严格意义上的技术文章来阅读。

1)安装、部署过程要尽可能自动化。

将集群搭建的步骤脚本化,可以做到批量部署多个节点、快速上线/下线一个节点。集群的节点多,或者不断有节点上下线的话,都能省出不少的时间。

2)搭建并充分利用好集群的监控系统。

首先,最重要的是集群自带的监控系统。例如,HBase的Master、Region Server监控页面;Hadoop的JobTracker/TaskTracker、NameNode/DataNode监控页面;Storm的Storm UI监控页面,等等。这类监控侧重集群上的作业、资源等,而且包含的信息很全,包括作业运行的异常日志等,这对于排查、定位问题是非常及时有效的。

其次,既然是集群,就需要有一个统一的监控地址负责收集、展示各个节点的工作状态,集群既不能太闲,也不能负载过高。因此,我们需要对集群内各节点的CPU、内存、磁盘、网络等进行监控。Ganglia是个很不错的工具,它的安装配置过程简单,采集的指标丰富,而且支持自定义,像Hadoop、HBase都对Ganglia进行了扩展。

3)为集群内节点添加必要的运维脚本。

删除过期的、无用的日志文件,否则磁盘占满会导致节点不工作甚至发生故障,如Storm集群的Supervisor进程日志、Nimbus进程日志,Hadoop集群的各个进程日志。

为集群上的守护进程添加开机自启动脚本,尽可能避免宕机重启后的人工干预。例如,CDH已经为Hadoop、Hive、HBase等添加了启动脚本,rpm安装后进程可在机器重启后自启动。

同时监控集群上的守护进程是否存在,不存在则直接重启。这种方式只适用于无状态的进程,像Storm的Nimbus、Supervisor进程,Zookeeper进程等,都应该加上这样的监控脚本,确保服务进程终止后可以尽快被重启恢复。例如,通过设置crontab每分钟检查一次。

4)根据业务特点添加应用层的监控和告警。

对于业务层的计算任务,可以监控每天产出数据的大小和时间,如果出现异常情况(如数据文件的大小骤变,计算结果产出延迟等)则进行报警。

对于实时计算的应用,最重要的是数据处理是否出现明显延迟(分钟延迟、秒级延迟等),基于此,可以定义一系列的规则,触发不同级别的报警,以便第一时间发现并解决问题。

5)使多个用户能够共享集群的计算和存储资源。

使用集群的Quota限制不同用户的资源配额,例如Hadoop就提供了这一机制;但是,Storm和HBase目前并没有发现有什么方式可以限制。

通过多用户队列的方式对集群的资源进行限制与隔离。例如Hadoop为了解决多用户争用计算资源的情况,使用Capacity Scheduler或Fair Scheduler的方式,对不同用户提交的作业进行排队,可以直接部署应用,也可以根据业务需求对其进行定制后使用,很方便。

对于Storm集群,其计算资源也是按照Slots划分的,因此可以考虑在Storm之上加上一层资源控制模块,记录每个用户最大可占用的Slots数、当前已占有的Slots数等,从而实现用户的资源配额(不过目前Storm无论从集群规模还是内部使用用户来看,都还不算多,这一需求并不是特别迫切)。

另外,不同用户对集群的访问控制权限十分必要。比如,是否可以提交作业、删除作业,查看集群各类资源等,这是保证集群安全运行的一道基本保障。

6)实时计算应用要想办法应对流量峰值压力。

真实压测:例如为了应对双11当天流量压力,模拟平时3~5倍流量进行压测,提前发现解决问题,保证系统稳定性。

运维开关:通过加上运维开关,避免流量峰值时刻对系统带来的冲击,例如,通过ZooKeeper对实时计算应用加上开关,在线调整处理速度,允许一定时间的延迟,将流量平滑处理掉。

容错机制:实时计算的场景随流量的变化而变化,可能遇到各种突发情况,为此在做系统设计和实现时必须充分考虑各种可能出错的情况(如数据延迟、丢数据、脏数据、网络断开等等)。

稳定性与准确性折中:建议不要在实时计算中过于追求计算结果的准确性,为了保证系统的稳定运行,可以牺牲一定的准确性,保证应用能够“活下去”更重要。

7)多种方式追踪、定位、解决集群中的问题。

借助于集群的监控系统,定位问题所在的具体机器。登录到问题机器上,也可使用top、free、sar、iostat、nmon等常用命令进一步查看、确认系统资源使用情况、问题之处。

同时,通过查看集群上的日志(包括集群级别、业务级别),确认是否有异常日志及对应的原因。

另外,也可通过strace、jvm工具等方式追踪工作进程,从问题现场寻找原因。

8)集群运行任务的一些调优思路。

综合考虑系统资源负载:结合集群监控,从各个节点上任务实例的运行情况(CPU、内存、磁盘、网络),定位系统瓶颈后再做优化,尽可能使得每个节点的系统资源得到最大利用,尤其是CPU和内存。

任务实例并行化:可以并行化的直接采用多shard,多进程/多线程的方式;复杂的任务则可以考虑先进行拆解,然后进行并行化。

不同类型的任务:CPU密集型考虑利用多核,将CPU尽可能跑满;内存密集型则考虑选择合适的数据结构、数据在内存中压缩(压缩算法的选择)、数据持久化等。

缓存Cache:选择将频繁使用、访问时间开销大的环节做成Cache;通过Cache减少网络/磁盘的访问开销;合理控制Cache的大小;避免Cache带来的性能颠簸,等等。

 

posted on 2013-06-27 13:43  大圆那些事  阅读(10321)  评论(3编辑  收藏  举报

导航