zoukankan      html  css  js  c++  java
  • 集群应用及运维经验小结

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

    网址: 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带来的性能颠簸,等等。

  • 相关阅读:
    XML(学习笔记)
    css样式学习笔记
    Request(对象)
    sql一些错误修改的总结
    转载(如何学习C#)
    sql server(学习笔记2 W3Cschool)
    sql sqrver(学习笔记1 W3Cschool)
    关于 flutter开发碰到的各种问题,有的已经解决有的一直没解决或者用其他方法替代
    关于 Flutter IOS build It appears that your application still contains the default signing identifier.
    关于 flutter本地化问题 The getter 'pasteButtonLabel' was called on null
  • 原文地址:https://www.cnblogs.com/panfeng412/p/cluster-use-and-maintain-experience-summary.html
Copyright © 2011-2022 走看看