云计算时代,为何要重提CMDB
前段时间,领导丢过来了一个已经做了10多年、经过了至少5个厂家的不断失败的CMDB项目,真天降铁饼了。从事运维服务的IT背锅侠,对于CMDB一定都是如雷贯耳,但是对笔者这种软件开发及行业解决方案出身的程序猿及产品汪来说,CMDB是个什么鬼东西啊,对于产品任务基本一脸懵逼,也不知道为何要做这样一个产品。说来其实笔者也当局者迷,人在庐山中,不认庐山真面目罢了。
笔者在2014年底糊里糊涂的从传统行业解决方案转型云计算,短短的几年间,云计算已经从百花齐放到今日寡头市场格局,除了AWS、阿里云等云计算寡头,大部分自行研发建设云计算的企业基本都是内部自娱自乐,难以向外进行市场的拓展。业内非寡头企业的团队,为了能继续在云市场内分一杯羹,纷纷转身为MSP(云管理服务提供商,Cloud Managed Service Provider),名字听着还是挺高大上的,但是在商业模式上传统IT运维服务外包类似。
虽然商业模式上云MSP和传统的IT运维服务外包类似,但是MSP服务商却在技术、产品及运维理念上有着一定的优势,也就是说并不是任何一个传统的IT服务外包商就能够提供MSP服务的。具体如下:
技术来看:大部分MSP商家基本具备openstack云平台的研发、实施及运维能力,对云计算技术有深刻的了解,能够快速掌握其他云平台技术的集成和运行,也能快速了解各个云平台的优缺点。这是传统运维服务商往往难以具备的。
产品来看:传统IT运维商具备都是采用甲方采购HP等大厂家的CMDB产品,遵从ITIL原则,做了很多笨拙、繁琐的工作,投入产出比严重失调。在云计算已经为主导的今天,这些CMDB产品基于传统的企业IT架构出发,难以适应多云架构环境,无法适应业务的快速变化。传统CDMB、ITSM主要服务于稳态运维,管理流程繁杂冗长,是典型的IOE式产品,价格昂贵不说,还产品操作繁杂,存在众多人工维护的无用配置项,就连操作手册也苦涩难读,在互联网角度来看简直就是反人性的产品。现在的MSP商家借鉴了传统以ITIL为准的稳态运维经验、也考虑了以devops为准的敏态运维需求,构建了轻量级的CMDB产品,以更高的投入产出比快速占领了市场。
理念来看,传统IT运维人员真是深受稳态运维的严重影响,总希望所有操作都按照自己熟悉的、既定的流程有条不紊的完成、别出任何差错,这种工作模式和工作习惯,保障传统IT运维的稳态功不可没,但是它们也使得传统运维人员对所有的新技术、新产品都有一种莫名的抵抗,担心这些新的东西会出现错误。MSP商家却大都从云计算研发转型过来,团队对新技术、新产品都有较好的接受能力,能够快速适应云计算时代对运维的新要求。
随着云计算越来越普及,企业原来以内部IDC机房为载体的IT基础架构也逐渐发生了很大的变化,企业的业务系统除了部署在原来物理架构外,可能部署在VMware私有云、openstack私有云、阿里云公有云、AWS公有云、腾讯云、Azure等等各种云平台之上,形成了更加复杂在多云IT基础架构。传统的信息部运维团队或者IT服务商的技术能力及产品都难以对多云架构进行更好的运维管理,使得这些新形成的MSP厂家有了更加广阔的市场。这些MSP厂家在新的市场群雄逐鹿的过程中,除了云计算技术核心能力外,相关配套产品也是其构成核心竞争优势的重要组成部分。在相关的配套产品中,适应于多云架构及“双态运维”(稳态运维、敏态运维)的CMDB是其中的拳头型产品。由此,已经老掉牙的CMDB又重新以更加吸引眼球的方式出现在我们的眼前。
归根结底,一句话“一切都是市场的需求”。
对于运维行业软件,相信还是比较小众的。在开始前还是简要的从百度百科科普一下,比如像前一个月前的笔者,基本不懂啥是ITIL、啥是ITSM、啥是CMDB。
ITIL、ITSM、CMDB简介
ITIL概述
ITIL即IT基础架构库(Information Technology Infrastructure Library, ITIL,信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订,现由英国商务部OGC(Office of Government Commerce)负责管理,主要适用于IT服务管理(ITSM)。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。
它和运维(IT服务管理)相关性很大,传统的运维完全就是以ITIL来蓝本构建的。ITIL主要包括六个模块,即业务管理、服务管理、ICT基础架构管理、IT服务管理规划与实施、应用管理和安全管理。其中服务管理是其*核心的模块,该模块包括“服务提供”和“服务支持”两个流程组。
传统企业(银行、电信、制造、航空等等传统企业集团)业务相对稳定,对应的IT支撑架构也是稳定支持生产运行为主要目标,为此,内部IT服务流程也一个严格的、缓慢冗长的管理流程。而互联网企业日新月异的业务变化,使得其IT支撑架构也是快速而敏捷的,笨拙缓慢的ITIL无法满足互连网企业的需求,因而,更加偏向使用DevOps。
ITSM概述
ITSM (IT Service Management,IT服务管理 ),它是一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的高质量方法。它结合了高质量服务不可缺少的流程、人员和技术三大要素 —标准流程负责监控IT服务的运行状况,人员素质关系到服务质量的高低,技术则保证服务的质量和效率。对于传统行业的开发人员来说,对应ITSM*直接的体验就是提交变更的繁琐流程。
CMDB概述
CMDB –Configuration Management Database 配置管理数据库:存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。在实际的项目中,CMDB常常被认为是构建其它ITIL(Information Technology Infrastructure Library,IT基础架构库)流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。
通俗浅薄的解释一下CMDB
从上述百度百科的定义来看,还是有些苦涩难懂的。我们从应用场景切入来理解CMDB,可能更加容易一些:
场景一:应用运维工程师从业务线/产品线的角度去,去查看某个业务线/产品线有多少个应用系统、哪些是核心的应用系统,这些应用系统是不是部署那些主机上,是否存在单点问题,资源是否合理分布等等。在一般的运维过程中,每个应用系统的信息都存在,但这些关键信息可能都是散乱的,比如用物理机部署的可能在某一个工具上维护,用云主机部署的却是在云平台上进行维护,给整体的分析带来了不便,使得无法从更高的业务角度来判断和分析资源情况。
场景二:在日常的运维管理中,我们需要面临很多的IT资源,有物理形态的,比如机房、机柜、网络设备、安全设备、物理服务器、SAN存储、刀箱等等;有数字形态的,比如云平台、云主机、IP、操作系统、中间件、数据库、代码等等。其中的任何一个资源出现故障,可能都会影响到业务的稳定运行,那么我们怎么来统一管理这些IT资源、怎么来理清这些资源之间的关联关系、它们之间又是如何相互影响的。
CMDB的提出就是要解决这些问题的,以提高运维的效率、甚至以达到智能运维的目的。从管理角度看,CMDB的核心就是对这些IT资源进行管理。为了进行有效的管理,CMDB有这些IT资源必要的属性信息(注意不是*完整、*全面的信息),及这些IT资源之间是如何相互关联、相互影响的关联信息。从运维角度,可以一句话来简单描述就是:
“CMDB知道一个IT资源的必要信息,也知道这个IT资源发生变动后,会影响到哪些IT资源及业务”
在CMDB中,还有两个比较费脑细胞的概念就是“模型”及“关联关系”:
模型:我们通过模型定义各个资源对象(可以理解为:对于这些资源对象,我们需要关注哪些信息–类似数据库中的表有哪些字段一样)。
关联关系:定义说明这些对象之间的关联关系,比如应用和云主机是运行关系,某某应用运行在某某云主机上,某某云主机运行了某某应用。
这就是CMDB的模型之说,文章的后面我们通过实际例子来正式说明。定义好了这些模型、关联关系后就要把这些模型实例化,类似我们往表中插入一行数据一样,这行数据有主键key、各个字段属性、各个外健等等。
下面,我们将从产品理念、产品架构、资源模型、原型设计、应用场景方面进行来说明我们如果构建一个符合多云架构、符合“双态运维”的轻量级CMDB产品。
产品理念和目标
产品理念:以应用场景为驱动,建立高效化、轻量化的运维数据枢纽。
产品目标:构建符合多云架构、符合“双态运维”的轻量级CMDB,并形成运维数据中心枢纽,该数据枢纽能够支持多种业务场景,比如资产管理、资源可视化、运维监控、自动化运维、多云管理等等。
产品框架规划设计
CMDB产品功能规划上,我们做了一个*简化的组成,即由模型管理、数据中心、资源管理、采集平台、资源可视化等组成,具体如下:
从业务操作流程来看其实并不复杂:
- 模型管理模块定义好模型
- 数据中心根据定义,创建模型。
- 从过手工录入或者自动采集实例化资源。
- 通过数据中心构建各种可视化应用,包括资源查阅、资源拓扑展现、运维大屏之类的可视化应用。
- 通过数据中心提供其他应用。
模型规划设计(核心部分)
传统CMDB模型的缺点
在传统CMDB项目的实施过程中,大家都是看了仿佛都是各种各样的模型、五花八门的配置项目,然后,项目工作都落入定义各种配置项中去,笔者了解到之前的CMDB项目中也s落入这个陷阱而导致项目失败。虽然我们看到项目过于关注模型而导致失败,但是也从侧面说明了模型的重要性。开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事。如何用好CMDB系统,规划设计一套可用的CMDB模型是一个关键。那么,我们又应该如何规划CMDB模型才能满足我们的产品目标呢?
在如何规划设计CMDB模型前,我们先先说说传统的CMDB模型,传统的CMDB基本都是由国外的大厂家开发的,产品围绕数据中心以基础资源管理为主,模型配置项也*其繁杂,比如明细到了某个插座的型号、位置之类的,似乎要穷举所有资源的所有属性才摆休。传统CMDB常常需要运维人员进行各种配置项后才能使用,即没有一个可以开箱即用的模型,这个配置的过程基本把运维人员挡在系统门外,*后,肯定是不如Excel来得方便。另外是过分依赖人工维护,缺少自动化发现及自动采集功能,数据维护工作量巨大,系统投入产出比严重失调,*后也是不了了之。对于敏态运维DevOps的支持,更是无从谈起。
新一代CMDB模型的出发点
为此,在规划设计CMDB模型时,我们可以如下几点出发
- 要从业务应用角度出发,不能从IDC的资源管理出发,毕竟所以的IT资源归根到底都是为业务服务的。
- 至少要存在一套可以开箱使用的模型,不能只是提供一个工具的平台,而把难题丢给了用户。谨记“开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事”
- 模型属性尽量精简化,只需要必要属性信息,而不是穷举所有属性信息。
- 人工维护是必要的,但是能够系统自动化就要系统自动化,手工录入是一个迫不得已的手段。
- 要场景应用为驱动,反推和检验模型。
- 模型要考虑多云架构、考虑内外部资源
- 模型是为了管理,不能为了模型而模型,不能因为各种配置项、各种配置属性,而把精力放在库表的设计和管理上。
一个开箱即用的CMDB模型
如下是笔者为了满足多云架构及“双态运维”初步规划的CMDB模型规划:
当然,笔者只是做一个开箱即用的简要模型,但可以满足80%以上的运维管理要求。
常见的关联关系
比如,应用和云主机是运行关系,某某应用运行于某某云主机上,某某云主机运行了某某应用,其中应用是源、主机是目标。
如何定义模型属性
重复一句:“尽量精简化,只需要必要属性信息,而不是穷举所有属性信息。”
如何定义模型关联关系
建立源与目标的概念,任何一个对象在不同关联关系中都不同的定位。下面以云主机为例,
- 云主机与云平台是归属关系,云主机是源,云平台是目标。
- 云主机与应用是运行关系,云主机却是目标,应用却是源。
如下图:
当然,我们也可以通过拓扑方式更加直观来管理这些关联关系:
确定好有哪些模型,如何定义这些模型及模型之间的关联关系,那么模型工作基本就可以告一段落了。接下来就是如何根据定义实例化这些模型。
实例化模型有些需要注意的地方
实例化数据库的选择
传统的CMDB是基于关系型数据库实现的,使得整个库表架构*其复杂,可读性*差,对外接口更是复杂了。新一代CMDB利用MongoDB这非结构化数据库能够更加适合CMDB的建模,推荐的做法是:
- 利用Mysql等关系型数据库,存储模型的定义。
- 利用MongoDB等NOSQL文档存储数据库,以json的格式存储资源实例。
实例和视图分开
CMDB数据中心同时事务数据库及数据仓库的功能,为了能够满足数据实时更新的同时,也要满足各种运维的监控及分析。因此,建议分成实例库和视图库
尽量减少人工录入
手工录入是一个迫不得已的手段,能够采集就自动采集,能够自定发现的就自动发现。
常见资源可视化视角需求
实现核心模型,即业务、应用和主机Host的关系。运维人员可以
从云主机host 为起点向拓展云平台、宿主机、网络设备、存储等。
扩展模型3,以机房为起点拓展机柜、网络设备、安全设备、物理主机、存储设备、云平台。
以云平台为起点拓展机柜、机房、网络设备、存储设备、物理主机。
通过不同的视图可以满足不同用户对资源整体管控。
总结
一句话:开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事。