初期阶段IT基础设施通常处在小规模状态。几台至几十台机器的规模,足以满足业务需求。很多公司都不一定配有专门的运维人员或者部门,业务开发人员完成自己业务工作的同时,也一并完成所负责管理相关业务的设备。随着云时代到来了,IT基础设施迅速发展成几百上千服务器。更多的业务系统上线,业务人员也无暇再顾及运维工作。此时,运维人员开始专业化,独立成部门。各类孤岛式的运维管理工具上线,提升运维效率。
可是在各类运维工具上线之后,大家发现运维人员仍然时常要充当“救火队员”,收警告、修机器,哪里宕机去哪里。虽然有了运维管理工具自动化收集监控数据之后,但还是有很多问题,让底层物理资源运维工作无法实现完全自动化。
逃不开的人工巡检
目前,多数客户所选择的运维监控方式都是在操作系统上安装Agent访问设备驱动,读取硬件状态数据。所有监控状态的数据抓取都受限于驱动程序。而驱动程序的编写人员所关注的重点在于设备的正常运行,而不在于设备的状态监控。因此,通过驱动程序所抓取的硬件状态参数始终有限。这也就能解释,为什么很多客户在上线了运维监控软件之后,还是需要人工巡检。我们来看几个大家经常遇到的问题:
事例1:某客户数据库系统上线,3块900G 硬盘做raid5。当出现一块坏盘之后,监控软件看不到有坏盘,因为系统还在正常运行。人工巡检之后,发现设备上有硬盘告警灯。监控软件下又无法查看到系统是JBOD还是做了raid。巡检中,数据库服务器出现硬盘告警,监控软件在这种时候却帮不上忙。如果不是人工巡检,甚至可能都没有发现这个严重告警。
事例2:某客户的核心业务服务器配置双电源,却在一次电源故障中出现了服务器掉电问题。严重事故之后,追查责任,才发现原来双电源中的备用电源一直处于离线状态。系统下的agent无法监控到冗余电源离线,因为一直有一个电源在线,供电没有出现任何问题,因而没有告警信息出现。最终客户发现,监控系统上线了,还是得巡检。
事例3:某客户想要扩容旧系统上内存容量,监控软件显示内存容量为256G。还有多少内存槽位呢?机器上是16G*16,还是32G*8呢?监控软件获取不到!很崩溃,只能去机房拆机器验内存T_T
……
日常工作量大,加班是常态。还要经常面临设备问题而带来了业务中断风险。监控系统上线了,一切都没有开始好转。
带外解带内之困,远离人工巡检
从专业的角度来看,网络管理可分为带外管理(out-of-band)和带内管理(in-band)两种管理模式。上述在系统下,也就是客户的生产环境下抓取数据,通过生产网络读取监控数据属于带内管理。这种管理方式,最大的问题就在于当系统出现故障时,机器就无法管理。而且如上所述,获取的监控数据有限。而几乎所有的it设备厂商都为客户提供带外管理口,也就是与生产系统相隔离的管理口。管理口下,设备厂商本身就提供了详细的硬件参数。这些硬件参数直接来自于服务器上百多个sensor,直接从硬件层面获取的状态参数。数据更为细节、全面和直观。