运维管理

作者: 时待吾 | 来源:发表于2017-06-17 18:52 被阅读24次

Ganglia是个很不错的工具,它的安装配置过程简单,采集的指标丰富,而且支持自定义,像Hadoop、HBase都对Ganglia进行了扩展。

在做系统设计和实现时必须充分考虑各种可能出错的情况(如数据延迟、丢数据、脏数据、网络断开等等)。

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

登录到问题机器上,也可使用top、free、sar、iostat、nmon等常用命令进一步查看、确认系统资源使用情况、问题之处。

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

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

系统的自动安装 kickstart cobbler

1.      服务器型号的区分,为以后的统一化和标准化作硬件上的准备,很多人忽视这一点,其实如果这一点做得好会使后面的运维工作轻松很多,根据应用我们主要把服务器分为3中,cpu密集型,主要用于大量计算应用,比如p2p;内存密集型,用于cache类应用,比如squid,varnish缓存服务器;磁盘密集型,用于大存储类应用,比如视频存储服务器,Hadoop日志存储集群。

2.      系统的的自动安装,主要有kickstart和cobbler

3.      统一的yum源和定制化的rpm包, 并集成至yum源站,为后续的环境初始化做软件上的准备

4.      构建专属于自己的内网DNS

5.      标准化的统一的命名方式(标准化基础),便于使用puppet管理,并且减少操作的错误,如果每个机器的hostname都为localhost,那将是一个多么可怕的事。。。在我们的生产环境中主要使用下面这种命名方式

机房-主业务-应用程序-IP后两位-公司域名,这样一眼就可以看出是哪台服务器,应用于什么业务,报警也可以直接定位。

6.自动化的配置管理和环境部署工具:puppet,puppet的模块编写要尽量减少模块直接的耦合度,并使用class继承的方式来减少运维的工作量,定制化的facter变量会使软件的配置环境更加灵活,由于puppet暂时不支持群集,所以在实际应用中需要部署多套,根据经验,1500台左右的server时puppet会出现性能问题。

7.      强大有效的监控系统,在生产环境中我们使用了zabbix proxy+zabbix master的群集结构,zabbix可以实现有效的系统和应用级别的监控,应用监控同时也使用了ppmon来实现多点监控。

选择zabbix有一个最大的好处,就是监控数据是存放在数据库中的,这样就可以利用数据库中的数据做很多操作,比如可以分析一段时间内服务器的各个性能指标,查看服务器的资源利用率,可以对数据进行聚合操作,从而分析全网的指标,比如总的流量,总的http code分布情况。

8.      日志收集服务器群集 和qos分析系统,构建 有效的日志收集系统可以有效地对用户的访问数据进行整合和分析,可以快速的分析qos,对应重要的节点我们采用本地分析并导入mongodb,最后导入zabbix的方式,非重要节点则直接将日志打包压缩,通过ftp上传至hadoop数据仓库集群中。

9.      构建冗余的结构,消除单点,在生成环境中对于一些重要节点都采用keepalived-ha的方案来提高冗余度。对于resin,php等应用服务器则在前端使用nginx做反向代理,同时nginx使用keepalived-ha

10.  自动化的代码分发系统,主要是controltier + svn的使用,可以方便快速地部署代码。

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

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

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

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

相关文章

网友评论

    本文标题:运维管理

    本文链接:https://www.haomeiwen.com/subject/gudbqxtx.html