Cmdb intro

CMDB Intro

朱荣泽

大纲• CMDB是什么• 目前 IT的问题• CMDB能做什么• 如何构建 CMDB• 开源 CMDB软件• 在线 CMDB服务• CMDB厂商• 如何构建 CMDB

CMDB是什么

CMDB是什么A configuration management database (CMDB) is a repository of information related to all the components of an information system.

It contains the details of the configuration items (CI) in the IT infrastructure. Although repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems from ITIL.

In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A CMDB helps an organization understand the relationships between these components and track their configuration.

The CMDB is a fundamental component of the ITIL framework's Configuration Management process.

CMDB是什么The CMDB records CIs and details about the important attributes and relationships between CIs. Configuration managers usually describe CIs using three configurable attributes:• Status: define the current state of the item• Traces: list item history i.e. all modification applied on the record

such as record creation, status change, owner assignation, …• Attributes: attributes that qualify the physical object such as

name, serial number, memory, CPU, version, …• Relations: valuable relations with other Cis such as parent/child,

is installed on, is based on, utilize, refer to, owned by …

CMDBs contain metadata, and thus the concept overlaps with that of a metadata repository which are both used in running large IT organizations. Configuration management addresses how the data is to be kept up to date, which has historically been a weakness of metadata repositories.

CMDB是什么According to ITIL, a CMDB (Configuration Management Database),containing a logical model of the IT infrastructure, forms the basis for effective and efficient IT Service Management.

CMDB 是 IT 基础设施的逻辑模型。 CMDB 中的基本元素是 CI ，每个CI 是 IT 基础组件在 CMDB 中的映射。通过管理 CI ，进而可以管理整个 IT 基础架构，进而管理 IT service 。

目前 IT的问题

目前 IT的状态

资产管理发布管理配置管理

治理与合规管理事件与影响管理

性能和可用性管理

仪表盘企业调度

容量管理

变更管理

服务水平管理

数据管理服务请求管理

事件管理

常见 IT服务的问题（第一个层次）

1. ２号核心机房的７４号机柜中到底存放着多少个 IT设备？ --位置2. 网上银行的业务系统到底有多少台服务器？ --系统3. 一个具体的系统管理员手中管理着多台小型机？ --人员4. 6.5.21版本的 ESP软件到底安装了多少个？ --版本5. 刀片服务器有多少台？小型机有多少台？ --类型6. DL380的服务器有多少台？有多少台库存备机？ --型号7. 这台 PC服务器使用了多长时间？8. 整个公司有多少种 Oracle数据库版本？分别有多少个？

你的公司如何得到这些信息？要用多少资源？要用多少步骤？要用多久？

常见 IT服务的问题（第二个层次）

1. 这台序列号“ 99C9962”的 X3850PC服务器，过去发生过哪一些事件？2. 这款物流部门使用的 VLS系统现在还有多少个 BUG等待修正？3. Internet区的网络下周都安排了什么变更？4. 一个交换机接入了多少个对象？5. CM20101105007这张变更单，当时到底动了哪几个设备？6. ２号核心机房现在有多个设备现在处于非正常状态？7. 上个月事件最多的 10台机器是哪几个？8. 当一个用户做事件申报时，服务台怎样知道哪一些组件或服务与他相关？9. 对一台交换机做变更时，可能影响哪一些业务系统？10.哪一些软件与设备已经过保？或许可证不足？

你的公司如何得到这些信息？要用多少资源？要用多少步骤？要用多久？

常见 IT服务的问题（第三个层次）哪一些组件是我们的架构的薄弱点？，明年的 IT架构加固与改善的重点是什么？

工程师的时间资源花在哪一些对象上或哪一类对象上？

服务目录与 IT 架构的关系是否有可能梳理出来？是否可能明确每个 IT组件可能的操作动作是什么？

每一个组件类中，事件有哪一些分布特性？比如中间件的哪一个版本事件率最高？

工程师的时间资源花费最多的是做哪一些事务（服务目录）？同样的动作，在不同的机型上花费的时间不同吗？明年的人员能力提升的重点是什么？

哪一类组件的变更失败率或回退率最高？有怎样的分布特性？

终端机器的事件率与使用年限有没有函数关系？与品牌或厂商有没有相关性？

服务质量的下降到底是由哪一些组件决定的？反向的每一个组件可能与哪一些 SLA相关？

应怎样去记录 IT服务？

一个问题是：我们应该如何记录？？

CMDB能做什么

CMDB改变记录模式• 记录不旦意味着记录“事情”（事件、变更、发布），还意味着记录“物体”，

只有“事物”相结合，记录才完整。• 事情（工单）记录于 IT 服务流程之上。• 物体（对象）记录于 CMDB 之上。• 要实现真正面对服务的管理，必须有一个坚实的基础： CMDB• 只有记录足够结构化与标准化，科学而全面的统计分析才有可能

CMDB+ 流程 = 事 + 物 = 完整记录完整记录全面分析科学管理

面向对象的 CMDB

采用 ITSM构建统一的 IT管理平台

发布管理

事件和影响管理

容量管理

事件管理服务请求管理

数据管理

服务水平管理

资产管理

治理和合规管理

仪表盘配置自动化

企业调度性能和可用性

管理

变更管理

ITSM

CMDB的价值

价值

更有效的管理 IT 架构

信息化标准化平台化服务化

BMC Atrium CMDB解决方案

“Single Source of Truth”

基于 ITIL v3 标准的 CMS

CAHPIBM

配置大类包括设备和实体配置构件类型

主机后台服务器、前置主机和客户端主机基础架构 CI

网络设备网络设备基础架构 CI

数据中心设备存储、备份、安全、场地基础架构 CI

基础架构软件操作系统、数据库、中间件等基础架构 CI

业务应用系统业务应用系统实例基础架构 CI

业务服务计费业务、彩信业务、短信平台等服务 CI

关系名称描述

依赖 / 支持主要指软件之间的依赖关系，指某 CI的功能正常运行需要其他 CI的功能正常运行时的关系；例如某业务应用依赖于中间件 ,反之中间件支持某业务应用

运行 / 运行于主要描述一个 CI 运行于另外一个 CI 之上，例如：某应用实例运行于某一台主机之上，反之主机上运行了某些应用实例

安装 /安装于指软件包安装于某硬件平台上。例如数据库安装在主机上，反之主机上安装了某些数据库

使用 / 被使用指 CI间的相互使用关系。如逻辑主机使用存储系统，反之存储系统被逻辑主机使用

父 / 子主要指某 CI是其他 CI一部分时的关系。例如某端口是某交换机的子 CI，反之该交换机是该端口的父 CI

部署 /部署于指物理设备上架安装的关系。例如主机上架部署于机柜上，反之机柜上部署了哪些主机

包含 / 属于描述多个 CI组合成一个单独的 CI，并对外提供服务，且用于组合的每个个体 CI 均能独立对外服务。例如多个逻辑主机属于一个群集，反之一个群集包含多个逻辑主机

连接 / 被连接指存在物理连接情况下的关系。例如主机连接到交换机上，反之交换机被主机连接

备份关系主要描述一个 CI是另一个 CI的备份时的关系，如某服务器通过冷备或热备的方式对另一台服务器进行备份

CI 和关系的基本分类

业务建模

业务模型实例

业务影响分析

变更流程集成

变更审计

事件关联

变更管理－流程概览

关键技术点－变更影响分析

需要进行影响分析的 CI

需要进行影响分析的 CI

图形化视图描述变更影响范围

图形化视图描述变更影响范围

切换到表格视图

切换到表格视图

模拟影响按钮

模拟影响按钮

关键技术点－变更影响模拟

•冲突检查–确定在同一时间是否存在 CI 项被不同变更请求处理

– 基于变更请求计划的开始 / 结束日期及与变更请求直接关联的 CI 项

– 客户价值 : 阻止常见的由于变更之间的冲突带来的负面影响。提供机会来整合变更从而提高效率。

关键技术点－变更冲突检查

导致冲突的变更请求 ID

关键技术点－图形化变更日历

6款开源 CMDB

http://linuxaria.com/article/6-cmdb-open-source?lang=en• Itop• OneCMDB• RapidOSS• ECDB• i-doit 可以访问 demo• CMDBuild

http://linuxaria.com/article/6-cmdb-open-source?lang=en



在线 CMDB服务

• http://www.cmdbcloud.com/

http://www.cmdbcloud.com/

http://www.cmdbcloud.com/

CMDB厂商

• VMware• HP• BMC• IBM• CA• Zynga• ManageEngine• http://www.zohocorp.com.cn/manageengine/index.html• NETWAYS• CloudExpo• http://www.netways.de/en/de/home/• easyCMDB

如何构建我们的 CMDB

《 Step-by-Step Guide to Building a CMDB 》

如何构建我们的 CMDB

• 定 user case• 定架构• 定分工和里程碑• 吃自己的狗食，这套简单的 ITSM可以跑我们的测试服务

步骤• 5 Stages• 26 Steps• N Tasks

5 Stages

• Stage 1. Assemble the Project Team and Define the Project

• Stage 2. Define Requirements and Create IT Service Model Blueprint

• Stage 3. Select CMDB Solution and Tools• Stage 4. Construct and Maintain Your CMDB• Stage 5. Driving Ongoing Value

Stage 1. Assemble the Project Team and Define the Project

• Step 1.Assemble Project Team• Step 2.Obtain CMDB Knowledge• Step 3.Create and Agree on CMDB Goals and Mission Statement• Step 4.Review and Define Benefits• Step 5.Build a Business Case

Step 3.Create and Agree on CMDB Goals and Mission Statement

Mission Statement:• 创建 CMDB 和相应的流程以便支持互联网公司的运维。• 实现 service 生命周期管理。 life cycle• 实现 device 生命周期管理• 和 change management整合• 和 incident management整合• 和 configuration management整合• 和 asset management整合Goals ：• 找到所有 Infrastructure CIs 和它们的关系。• 找到所有的 Service CIs 和它们的关系。• 实现 CIs的版本控制• 连接数据生产者和消费者。包括 change management 、 incident

management 、 configuration management 。

Action: 需要完善

Step 4.Review and Define Benefits明确包括哪些 Management:• Incident management.• Problem management.• Change management.• Configuration management.• Release management. • Availability management.• Capacity management.• Asset management.• Service performance and quality management. • Release management. • Service desk. • Financial management. • Project management.

各个Management的介绍： http://itil.osiatis.es/ITIL_course/index.phpAction: 需要明确

Stage 2. Define Requirements and Create IT Service Model Blueprint

• Step 6. Identify and Review Governance Requirements• Step 7. Review and Select Supporting Best Practices• Step 8. Identify Requirements to Address• Step 9. Identify Inventory and Asset Requirements• Step 10. Define Service Catalog Requirements• Step 11. Define CMDB Requirements to Support Other Processes• Step 12. Define Configuration Item Level and IT Service Model• Step 13. Define Configuration Item Relationships• Step 14. Define Configuration Item Attributes• Step 15. Design IT Service Model Blueprint

Step 6. Identify and Review Governance Requirements

任务：1 、明确谁是相关人员。2 、找到潜在的 CMDB用法。3 、收集需求，并文档化。

Action: 需要确定

Step 8. Identify Requirements to Address

主要解决：• 运维问题• 部署问题• 监控问题• 资产管理问题• 流程问题

问题的根源是：• 没有四化。自动化、流程化、系统化、标准化。

解决办法是：• 记录所有 device 和 service，使用 CMDB作为 IT 基础架构和 Servcie的逻辑映

射。


Step 9. Identify Inventory and Asset Requirements

任务：• 定义资产和库存类型• 定义资产的属主


Step 10. Define Service Catalog Requirements

任务：1. 定义相关的 service catalog2. 找到 services 之间的关系3. 找到 CIs 之间的关系。

目前找到的 service 有：• 游戏业务• 公有云业务• 私有云业务• Openstack-infra


Step 10. Define Service Catalog Requirements

Sample service management attributes could include:• Service level targets and priority• Service entitlement information (hours of service, required approvals, etc.)• Service-related notification, communication information, etc.• Service owners (by their job titles, for example)• Service maintainers • Service managers (by their job titles, for example)

Keep in mind that the service level measures and management information may also vary according to the types of service offerings you identified earlier.


Step 10. Define Service Catalog Requirements任务：• 定义好 service configuration structure 和 infrastructure configuration structure• 画出 service 和 sub-service的关系图，这个需要和大家继续商量。

Action: 需要定义 Service的关系图

Step 11. Define CMDB Requirements to Support Other Processes

需求• 在 presentation layer ，能够对 service 和 device 进行可视化。• 在 knowledgen processing layer ，有以下服务：

– Incident management.– Problem management.– Change management.– Configuration management.– Release management. – Availability management.– Capacity management.– Asset management.– Service performance and quality management.

• 在 information integration layer ，能够收集调和数据源的数据。比如从 nova得到虚拟机的数据。


Step 12. Define Configuration Item Level and IT Service Model

Goal: Define the optimum level for CIs — both service CIs and infrastructure CIs — in your CMDB. This step helps determine the overall breadth and depth of the structure of your CMDB data model.

一个 CI应该是一个单独的组件，或者是一个完整的系统。比如一个 CI可以是一个工作站，也可以是工作站的每个组件 ( 键盘、 CPU 、屏幕等 ) 。你可以为每个CI catagory 指定 level或者 type 。

You must understand ：the potential service impacts of proposed changes. And, you need to assign the right priority and escalation to incidents and problems. To meet these requirements, you need an IT service model that provides a decision-support view of infrastructure and service configurations


考虑 workstation 、 workstation component 、 screen 、 processor 、 keyboard 、software suite 、 patch 等是否是一个 CI ？1. cost or value. 它的代价和价值。2. change considerations. 你是否经常对这个组件进行修改？ CI level上能否支持对这种修改的控制和记录、报告。

3. Traceability. 你是否需要 trace这个组件，特别是因为 audit 的原因。4. Governance and compliance requirements 。5. Management of service commitments 。这个组件是否是一个服务的关键组件。

它会影响到服务的质量。6. Maintainability . 这个 CI level是否会影响你的数据库和 information的维护。比如当你要更新上千个 PC CIs去显示一个新的软件发行版已经安装在每个 PC上。

7. Delivery cost and quality . 哪种级别的 CI已经足够你去记录 incidents 和changes去支持 problem management.

8. Interrogation capability 。能否被搜索和分析。


考虑 workstation 、 workstation component 、 screen 、 processor 、 keyboard 、software suite 、 patch 等是否是一个 CI ？1. cost or value. 它的代价和价值。2. change considerations. 你是否经常对这个组件进行修改？ CI level上能否支持对这种修改的控制和记录、报告。

3. Traceability. 你是否需要 trace这个组件，特别是因为 audit 的原因。4. Governance and compliance requirements 。5. Management of service commitments 。这个组件是否是一个服务的关键组件。

它会影响到服务的质量。6. Maintainability . 这个 CI level是否会影响你的数据库和 information的维护。比如当你要更新上千个 PC CIs去显示一个新的软件发行版已经安装在每个 PC上。

7. Delivery cost and quality . 哪种级别的 CI已经足够你去记录 incidents 和changes去支持 problem management.

8. Interrogation capability 。能否被搜索和分析。Action: 需要确定


任务1 、定义 CI levels2 、画出Model Structure 。

Action: 需要定义好


任务：1. Defining configuration structure terms.

– Service Configuration Levels:• Business Service Offsering• IT Service Offering

– Infrastructure Configuration Levels:• IT Component Set• IT Components and Subcomponents

2. Defining categories.


Step 13. Define Configuration Item Relationships

• CI 之间的关系是 CMDB 的核心。• 在 CMDB 中使用 Two-way model of relationships.

Step 14. Define Configuration Item Attributes

Attributes are data elements that describe CIs, much like adjectives that describe nouns. Attributes help to identify and detail the important characteristics of what is in use, the statusof the items, and their location. Samples of hardware CI attributes could include make, model, serial number, location, version, license number, and so forth.



Attributes 的来源：


When you determine what to store (discover and maintain) in your CMDB and what to link (federate) to other data stores you will need to con-sider data maintenance and access needs. Consider the following:

Frequency of information change » — If the information changes often, and real-time replica-tion and synchronization cannot occur, a link from the CMDB to the data store may be more suitable to ensure the most up-to-date information is accessed in the best possible way

Frequency of information access » — If the information will not be accessed frequently,a link may be a better choice as it would minimize overhead of synchronization and still ensure timely access to the data when required.

Step 15. Design IT Service Model Blueprint

Just as a builder or architect would translate these requirements into an architectural diagram before building your home, you should follow the same approach and represent your require-ments in a consolidated IT service model blueprint before building your CMDB. Once completed, the blueprint will clearly show the service configuration structure, the infrastructure configuration structure, and the levels required to store your CI information. Your blueprint also will detail the relationships between CIs to ensure that dependencies are understood and enable both interrogation and analysis from the perspectives of services and infrastructure. The blueprint will further define what critical attributes you need to store and where.


Stage 3. Select CMDB Solution and Tools

• Step 16. Select CMDB Solution• Step 17. Plan the CMDB Population• Step 18. Select Tools to Automate CMDB Population• Step 19. Calculate Project ROI

Step 16. Select CMDB Solution

有以下的功能：• CI administration • Reporting and querying • Visualization • CI data modeling • Version control • Reconciliation• Synchronization • Discovery and monitoring tools


Step 16. Select CMDB Solution

有三种方法建立 CMDB 中的数据 :• Integrated multiple data repositories • One single centralized data repository • Federated data repositories with one central data repository


Stage 4. Construct and Maintain Your CMDB

• Step 20. Construct Your CMDB• Step 21. Create CI Lifecycle Management Processes• Step 22. Build Supporting Processes• Step 23. Populate Your CMDB• Step 24. Train the CMDB Team and Users

Step 21. Create CI Lifecycle Management Processes任务：1. 定义 CI Groups [ 图 21.2]2. 定义每个 CI Groups的生命周期 lifecycle steps [ 图 21.3]:

– Request for new equipment – Request authorized – Order placed– Equipment received – Equipment tested– Equipment installed– Equipment maintained– Equipment retired

3. 定义 CI Type Attributes 在 Each Step [ 图 21.4]4. 定义每个 Attributes的Owners [ 图 21.5]5. 定义每个 Attributes如何收集6. Agree on Owner’s Responsibilities7. Establish CI Update Methods and Procedures8. Install Control Points9. Implement Lifecycle Management for Each CI Group [ 图 21.6]Action: 需要确定

Step 22. Build Supporting Processes

In this step, you will build, document, and implement all of the processes required to support and maintain your production CMDB

建立一些 Processes，维护 CMDB的数据和实际 IT架构和服务是一致的，以便保证 CMDB的可用性和正确性。


Step 22. Build Supporting Processes

任务 :1. 你需要和 CMDB整合以下的服务，以保证 CMDB可用性

– Incident management.– Problem management.– Change management.– Configuration management.– Release management. – Availability management.– Capacity management.– Asset management.– Service performance and quality management. – Release management.

2. 设计 Process的 Flow3. Identify Actions for Key Process Steps4. Identify Control Points for Each Process Step5. Implement Each Support ProcessAction: 需要确定

Stage 5. Driving Ongoing Value

• Step 25. Implement Measures and Metrics• Step 26. Create a Continual Service Improvement Program

Technology

Cmdb intro