集群应用及运维经验小结
作者: 大圆那些事 | 文章可以转载，请以超链接形式标明文章原始出处和作者信息
本人目前很重要的一部分工作是参与或负责部门内一些集群的维护、应用开发以及优化，其中包括：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带来的性能颠簸，等等。
