运维经验（转）

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带来的性能颠簸，等等。

 

 

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