◆刘 媛
大数据时代自动化运维管理的实践和思考
◆刘 媛
(中国地震局第二监测中心 陕西 710054)
随着大数据时代的发展,数据中心逐渐开始转型。小型数据中心或通用业务的数据中心以托管为主,数据中心呈现集约化,集群化发展,运维管理面临着巨大的挑战。本文以大数据集群运维管理为例,基于运维管理的实践总结了大数据时代自动化运维管理所面临的挑战,并给出了自动化运维管理的思路,强调数据驱动,并针对自动化运维管理的发展提出了从运维效率实现向运维价值的转型。
自动化运维;大数据;集群;配置管理
随着大数据时代的到来,很多数据中心开始采用各种集群设备,设备及系统的数量、业务复杂程度大幅上升。用传统的人为管理、记忆管理的方式,基础配置信息的不全面,共享不充分的问题无法应对数据中心日常的管理,给运维管理带来巨大的挑战。笔者在大数据集群运维当中意识到这一问题,从而重新审视数据中心的运维管理体系并且推动自动化运维管理。自动化运维利用ITIL体系的运维思想,借助平台实现自动化的运维手段。不仅减少了人为操作的失误带来的损失,而且完全可以应对大规模集群上频发的问题处理。在基于Hadoop2.0开源框架搭建的大数据平台的运维上进行了实践尝试,通过四步让集群运维自动化。
在数据中心规模较小时,有些故障概率比较低、问题不明显,但是随着集群和业务规模增大,集群规模会逐渐扩大,概率所存在的基数增加。比如网络设备增多,网络传输过程所经过的路径变的复杂、环节增加,出现故障的频率也就随之增大。而在实际运维工作中,由于工作量的增加,导致人员也经常在软件配置方面发生遗漏现象。还有机器的环境变得复杂以后,对工具稳定性就有更高要求,比如某些机器不能接受某些协议的指令,就会在执行的过程中出现风险。之所以要构架自动化运维,主要是为了提升稳定性和执行效率。具体来说,人工操作代码下发配置的过程容易产生错误,用计算机来实现更为稳定,同样认为下发配置执行是低效的,对于简单重复性高的工作,机器的运算效率要远高于人工。 那么如何进行自动化运维的构架呢? 基于大数据集群的特性,主要从变更、问题排查、硬件维护及交付检查四个方面。
对于集群上各种软硬件的配置数据的梳理,并通过设定依赖、关联、连接等关系设计,对配置管理的中CI进行层级设计、属性设计等,基于业务的运行将CI的配置关系勾画出来,形成运维的基础数据,这是自动化运维的基础,更是数据驱动的前提。
这个工作基础打破了各种CI都是分散的,相互之间的关联不仅不清楚,还可能存在盲区的局面。通过基于业务来关联CI之间的基础路径,完成集合了CI映射的服务于运维的技术地图。
在传统数据中心的运维当中,我们就已经引入了配置管理的概念,将各类的CI以不同的规则关联在一起。但是,在传统数据中心业务当中并没有深刻地体现这一管理机制的优势。那么,在大数据集群管理上,配置管理的优势是否明显?我们可以看看如何利用日志,根据CI的关联路径实现问题的自动定位和解决。
图1 CI的配置关系图
首先通过部署在服务器上的 Agent依据配置的规则过滤信息。在日志服务当中可以通过索引来查询到相关的过滤信息,这些信息既可以实时进入流计算平台上分析运算,并将结果存入RDS数据库当中,也可以存入运维的存储中进行分析参考。
图2 实时日志分析架构
这样的架构借助配置管理的基础数据,改变了原来在运维管理当中盲目排查的困境,帮助问题快速的定位,尤其是在网络拥塞排查异常流量时,能够迅速发挥作用。例如,一旦出现了流量拥塞的情况,由于任何一个业务都清晰了端到端的路径,哪一条链路偏离基线呈现预警的状态,都可以通过日志记录的追查,从而细化定位到具体的作业或CI上,使得排查问题的层次分明、透明有序。即方便故障排查,快速定位问题。这些信息利用实时架构分析计算后,可以清晰呈现业务的实时流量和瓶颈,不再停留于基本的网络拓扑。
变更包括变更方案和变更执行,在整个运维过程中耗费了大量的时间,也存在着较高的风险。运维统计,70%稳定性事件是跟变更相关的。如何在确保运行的安全稳定的情况下发布变更是所有运维人员的难题。虽然很多数据中心都引入了ITIL的管理大数据的集群业务,在变更的时候更能体现出ITIL运维管理的核心。将日常的变更进行切割分解,并且将较为常用的抽象为一个工作流,各种工作流的组合来对应某一类比较稳定的变更类型,如数据集群的迁移等。为了进一步方便应用执行,还会将申请、审批等需求单封装在这些工作流的组合之上。并通过在执行中收集返回的信息、执行的时间对比等方式来丰富工作流执行中的知识库,从而更加有效、精准地应对变更需求和解决变更中容易出现风险的局面。运维的工作更多地聚焦到对于部分参数的审核和对测试报告的比对中。
大数据集群架构是去 IOE的,其集群特色导致核心设备都不是高可靠的,所以出现一些硬件问题还是比较常见的。人工确认机器硬件问题耗时耗力。硬件维修最需要的是做好硬件全生命周期管理。H3C的生命周期管理模块可以覆盖并且轻松掌握所有硬件的生命周期。一旦返现某个设备出现硬件问题,就可以迅速的通过集群的自动迁移,实现设备的隔离和下线,再进入机房具体查看设备的问题并进行报修,等到检修完毕再重新恢复作业。正是因为大数据集群松耦合的架构,只要提供满足条件的上下线 API 接口即可。
最重要的是大数据自有的调度机制可以完好地确保数据和业务的完整性。当然,如何进行硬件信息收集和分析,判断硬件问题呢?这其中需要长期的数据和经验积累。正常运行的数据要形成数据参照,利用上述的自动化运维的架构设置,在阈值外的自动做上述处理,主要关注异常原因,不断优化逻辑即可。当然对于这类自动处理建议采取比较保守的策略,优先隔离而不做进一步自动处理,人工介入分析异常原因,并注重知识库的积累完善硬件检测的模型。
开始采取大数据集群架构并且开始进行业务的创新开发后,需要不断地面对硬件交付和软件交付的出现。其中,用前面所说的工作流的方式进行软件的交付检查,用对硬盘、内存、CPU、网卡等进行检查。例如,对于硬盘的检查是通过按照不同强度的读写压力和不同大小的块来看起表现是否稳定。对于内存测压则更多是以行业惯用的stream 方法,反复进行复制、读取、加乘运算来看性能的指标是否出现严重的偏离。对于CPU的检查方式则是绑定单个CPU来计算π值从而得出消耗时间的分布,用曲线来看偏离的程度。
当然还有一些问题有可能会在交付检查中被错判。比如,读写速度的受限,并不是由于硬盘本身导致的,有可能是异构的机器配置,导致HDFS balancer平衡的速度赶不上读写的速度。还有写入的数据切片的大小也会影响到写入的空间占用等。因此在实际交付检查的时候,也需要建立知识库,将各种检查的结果进行记录,并对这个过程进行持续的分析和参考,从而进一步优化软硬件的交付。
通过对上述建设思路实践的总结,我们不难发现,我们都是以大量的运行数据来做支撑的。因此自动化运维的核心就是对于数据的把握。实践表明,数据越丰富,就可以越好地驱动精细化运维。举例来说,在资源调度器里有用户资源申请的值,和申请之后的实际消耗值。通过这两个数据的比值,与满载100%进行比较。比较的结果是对调度模型的资源使用情况的呈现,通过进一步的细化分解和对于这个结果进行优化,来实现资源的有效利用。通过前面的架构对作业的情况进行分析,从而进一步盘点其资源的使用趋势,通过连续的数据来判断一定时间内资源使用的尖峰值,更好掌握优化的趋势。在进行了包括提醒用户自行优化,平台层面的优化,来趋近尖峰值,达到节省成本的目的。数据驱动了自动化运维的发展。
另一方面,传统运维更多关注的是平台稳定、安全,但是平台质量、用户的体验、平台的成本与资源合理分配、平台的效益本身等要求也越来越多地被提出。运维是跟业务应用紧密关联的,这些指标正是关乎运营的。所以运维往深走,是运营的思路。 对于运维来说如何建立更为持久的知识库,将日常的运维经验、思路和运维的想法都能够沉淀到平台当中,为整个业务的开展提供价值,促进业务的升级,才是运维的方向。
本文介绍了通过对大数据集群运行信息和数据的积累、提取和处理来实现运维自动化的思路。在该思路中基于丰富的信息收集支撑以及设定工作流的过程来实现自动化变更;基于日志的关联来实现快速的问题排查;基于硬件信息收集和全生命周期管理来支撑硬件维护;基于测试的数据衡量来交付检查等一系列的运维工作,体现出了数据能够驱动运维的精细化。笔者认为在稳定性基础之上,借助于数据分析和运维能力产品化,实现从运维效率实现向运维价值的转型是运维未来的发展方向。
[1]戚伟强,沈潇军,洪建光等.基于ITIL的电力信息自动化运维体系研究[J].现代电子技术,2017.
[2]朱玉立,任义廷.浅谈大数据时代下的数据中心运维管理[J].信息系统工程,2015.
[3]马幸飞.数据中心自动化运维管理及平台的建设研究[J].科技创新与应用,2017.
[4]范伦挺.阿里云大数据计算平台的自动化、精细化运维之路[DB/OL].https://yq.aliyun.com/articles/71111,2017.