BMC配置管理库

1.配置管理
1.1.Atrium CMDB
Atrium CMDB是配置管理系统核心,Atrium CMDB的配置管理数据方式，是面向生产设计的工作结构，有几种特性帮助高效地管理CI：
支持面向对象数据模型
类管理器（Class Manager）
具备服务模型影响模拟器功能
数据的联邦关联（Federation of data）
数据的灵活模型（Flexible data model)
配置的分区（Partitioning of configurations）
配置的调和（Reconciliation of configurations）
数据的开放访问（Open access to data）
强大的沙盒
1.2.可视化展示
CI和关系的展示底层服务器端使用Flex技术，前台显示工具同时支持B/S 和C/S，能支持IE和Firefox浏览器
可视化CI和关系展示工具不仅能显示相关配置项和关系，还能在界面上直接编辑，所见即所得的编辑方法，能修改CI和关系的属性，能用拖拽的方式创建新的CI和关系，能立刻保存编辑结果到CMDB中
查询功能：不仅能查询指定的某个类的实例，而且能同时设置多个类的属性作为查询条件，如：安装了MS SQL 2000的Dell服务器；运行于AAA
服务器上的VMWare虚拟系统BBB
CI和关系能够以业务模型的形式，展示各个CI之间的拓扑链接关系，拓扑视图中的CI能任意拖动，转换各种视角和排列方式：循环、有机、分层和正交；拓扑图型显示和数据列表可以在一个视图中随意切换
系统用户能按照自己的需求，把查询的结果或者所见到的内容保持成视图，每个能管理自己的视图，视图中的CI和关系是CMDB当中的一组配置项及关系的集合
过滤器是按照类、或者类的属性设置查询过滤条件，不同用户能管理和定义过滤器，管理员可以管理公共过滤器，过滤器能过滤关系和类，能立刻生效与用户视图
CI和关系的模型或者某个独立的CI能够通过URL的方式展示，能与第三方应用集成
1.3.类管理器
配置管理人员可以通过CMDB提供类管理器控制台访问系统中的配置类和关系类，查看类之间的继承关系，维护类的属性，定义类属性的参数，甚至新建类。

该控制台带来了巨大的灵活性，可以根据业务要求随时调整缺省的类库，并根据基类或子类进行派生，也可以独立构建类树，具有专业的类管理机制，比如抽象类、独类、类别类。

1.4.具备服务模型影响模拟器功能
能将在静态的CI关系和拓扑图之上做动态的业务影响模拟
影响模拟器模块能模拟某个CI的可用性故障，当发生了某种程度的变化后，其他相关CI因此受到的影响。

这种模拟的测试能帮助用户来做：变更影响分析、灾难恢复计划、网络弱点分析等。

例如：如果把“服务器A”
关机或者离线，这对整个系统造成的影响是什么？
模拟器能对作用于CMDB中的所有类型的CI对象，能直接利用现有的配置项直接的影响关系，业务影响关系的传递不受对象类型的限制
可以更具所需要选择影响模拟范围，把相关CI添加到一次模拟影响测试中。

影响模拟的结果可以通过报表的形式保存，结果内容可以以图片、xml和报表格式保存。

结果能作为CAB做变更前的变更申请资料。

能保存和加载多个模拟方案，如某些特定的CI可能经常发生变更，例如：某个核心网络设备的周期性维护，某些数据库服务器上数据库的定期升
级。

对这些特定集合的模拟测试方案可以保存，并在需要的时候加载运行，在使用的过程中可以不断维护和定制这些影响模拟方案。

该影响模拟的算法和市场中的服务影响管理工具具有一致性
服务影响模型能一次性创建、持续使用和维护；该模型能真实展现业务系
统的架构，能被业务服务影响管理的监控类工具集成。

能够被服务影响管
理直接引用。

1.5.数据的联邦关联
联邦是指集中数据存储，它直接存储者一些数据，同时链接到其他数据源中的其他数据。

有一些希望跟踪的属性并不需要像CI关键属性那样频繁那样旺盛，它们是作为联邦数据的两个首选属性。

这意味着，例如，员工的CMDB记录中的技能属性包括一系列的技能，部门属性包括了雇员的部门名称。

同时，它还关联到HR数据存储中的额外数据，比如薪酬等，这些在配置的角度并不重要的数据。

其他的数据类型是与CI相关但并不是CI的属性；也就是说，这些数据指向CI或被CI参考，为CI提供功能性，但又不是CI自身的一部分。

例如，软件实例的CI记录会有相关的许可证记录，它包括许可证在内部网
的URL位置，又或者CI记录可能关联到故障,包含查询CI相关故障数据库的必要信息。

1.6.联邦数据模式价值
能够节省耗费在导入，跟踪和整合CMDB中数据的开销
建立了交叉引用关联数据的标准方法
联合数据可被存储在多个地方
可保留在别的数据存储上的投资
1.7.灵活数据模型
许多不同类型的CI，从计算机系统，到网络硬件，再到软件服务器。

如果不用数据模型，那就不能准确地反应这些数据类型和数据之间的关系类型，CMDB 就只存储着一些CI的概要属性，缺少必要的属性，这样就很难按组查找CI。

因此数据模型必是面向对象的和可扩展的。

1.8.面向对象
面向对象的数据模型有一系列层次类，每个类能从基类继承属性，并且能把属性加到自己的属性里来创建特定类型的对象：子类。

子类能有自己的子类，可以扩展这个层级结构，添加用户希望跟踪的内容。

CMDB应用面向对象的数据模型的好处包括强制类似CI的共同属性，和在任何下级分支层次内搜索类的能力。

假如数据类型有一个基类，其它的都是子类，这样的话，就能从基类搜索到所有子类CI和它们的关系。

数据模型符合的行业标准：DMTF CIM, MOF, ITIL等，开盒即用的属性丰富。

开盒即用的类能表达IT组件、环境组件、人、流程、开放系统、主机系统、资源池和虚拟环境。

面向对象的类能表达CI和关系，具有唯一的基础CI类，和基础关系类；
所有子类都能继承父类的关系。

CI类和关系类的继承结构都呈树状结构。

可以按类来设置审计，可以定义审计条件和方式。

可以按类来设置访问权限，可以定义基于用户组的访问权限：可见和隐藏。

具有可视化，图形化的数据模型编辑器，在图形化的界面中能添加、编辑和删除类。

类修改之后，所有已有的该类实例的相关属性立刻发生变化，此过程实时
生效，无需任何手工数据维护操作。

1.9.可扩展性
组织结构的技术可能经常变化,这意味着CMDB中CI数据类型和它们的关系也必然随之而变，因此，需要数据类型是可扩展的。

CMDB应用能增加或删除属性，甚至增加或删除类。

虽然，这个特性是重要的，应用不要过度使用它。

配置管理数据库应用有一个公共的CI和它们的关系。

在配置管理数据库中为不重要的CI增加类和属性，
不要为配置管理数据库增加负担。

1.10.配置分区
分区能够把用户的配置数据分成叫作数据集的片断，每个代表某个特定时间的一组数据，这允许相同的CI或关系实例存在于多个数据集中。

针对基于基础设施确认和纠正配置的目标，这种技术很重要。

能够创建一个数据集来代表用户的预计配置，然后用自动发现应用来创建另外的数据集来代表实际配置。

分区是一个有用的工具，用这个工具能够实现很多别的目的。

数据集能够描述：
过期的配置
将来的配置
经过测试的“黄金标准”配置
不同版本的当前配置
总体配置的子集
不同自动发现工具提供的数据
不同客户端配置的数据
用户能创新的其他想法
1.11.配置的调和
当有多个数据集包括相同的实例时，调合过程识别所有数据集当中匹配的实例，然后比较每个实例的不同版本，报告查询或者将数据集合并入新的数据集。

它观察到不同时期的变化，在不同的发现源中确定所需要的数据。

识别实例（Identify instances）
在比较不同版本之前，必须确定他们确实表示相同的实体。

识别活动完成该任务，它将指定的规则应用中在两个或多个数据集中相同的类。

例如，用于识别计算机系统的规则是两个实例的IP地址相同。

当规则找到匹配的实例时，两个实例被标记成相同的调和识别号,一个额外的属性显示了他们每个代表在各自数据集里的相同的元素。

比较数据集（Compare datasets）
比较活动针对两个数据集中的实例进行操作，产生报告显示那些只在一个数据集中出现的实例，并且详细描述实例之间的差异。

比较活动只考虑那些已经标记了调合识别号的实例。

比较活动还可以用希望的配置与一个实际配置相比较。

可以用它作很多事情。

可以设置比较活动当希望保持稳定的配置发生变化时进行报警。

或者当某个变更请求正在处理时，可能用比较活动来确认配置是否到了一个希望的新状态。

合并数据集（Merge datasets）
合并活动根据规则将两个或更多数据集中的数据合并入一个新数据集。

该活动经常工作在当不同的自动发现工具对同一项目提供了重叠数据的情况下，确立一个有效的配置。

合并活动只考虑那些已经被标识了调和识别号的实例。

优先规则应该对于每个数据集中的不同的类和属性指定权重数值。

哪个数据集有越高的权重，那么它的类和属性就会优先被放在结果数据集中。

当有两个或多个自动发现应用发现相同的CI时，合并活动非常关键。

不同自动发现应用存在着各自的优势和弱项，因此，可以根据它们的优势创建优先规则。

采众家所长，这样得到的将会是所有发现数据中最好的CI描述集合。

1.1
2.数据的开放访问
正如我们以前提到的那样，即使有最准确的数据，如果不能访问，那也是没有用的。

非常重要的一点是必须让用户和应用程序都能读写CMDB。

消费者查看
并更改现存的数据，与此同时，数据的提供者也可创建和修改数据。

CMDB应用提供如下特性：
程序级访问：CMDB必须提供可编程的接口（API）或其它的方式来为应用程序提供接口来修改数据。

这种方式必须包括修改实例数据和数据模型的类定义。

批量数据装载：CMDB必须提供一种方式来同时导入多个实例，从而自动发现应用和其它应用才能迅速地数据生命化。

数据库和平台独立：CMDB应该与各种操作系统和数据库厂商相兼容，适应用户灵活多变的环境。

1.13.强大的沙盒
为了保证配置管理库数据的准确性、防止误操作行为的发生而同时有允许用户方便直观的进行手工数据维护或数据中间环节干预，CMDB提供了“沙盒”功能。

从本质上来讲，沙盒是一种特殊的数据集，该数据集同其他数据集一样，容纳可能与最终生产数据不一致的数据，且不被其他管理需求引用到，而其主要的设计目标在于让用户自如而安全的对生产数据进行手工的维护，并将该维护过程方便的纳入管理流程以及各种校验规则中，从而避免对生产数据的直接影响。

在CMDB中，当用户需要对某生产数据进行手工修改时，系统会将该修改的目标数据复制到沙盒。

这样，用户就在一个相对临时/非生产的数据集进行编辑，而不论该过程是非常快速的或者相对漫长的——这个过程中，只要编辑不被提交，生产数据集就不被该编辑影响，从而完全不影响CMDB消费者（各种工具和流程）。

用户在这个沙盒数据集中可以按照希望的方式更新数据（包括关系数据，包括增加、删除、更新数据），也可以针对这份数据拷贝空间进行讨论和分析。

当需要将该沙盒中的数据“提升”为生产数据时，系统则会根据规则进行必要的校验，并将数据融入生产数据集中。

在这个过程中，校验规则起到重要的作用，它有效防止生产数据集数据完整性被破坏（充分考虑到手工编辑可能带来一些容易被忽
略的底层数据不一致，如拼写错误，一致性规则忽略等），相当于在沙盒被升格为生产数据的过程中，进行了自动的检查，从而极大程度的保障了生产数据集数据的质量和可用性。

沙盒的存在大大的方便了用户的数据管理过程，同时对数据质量的保障又毫不妥协；大大提高了CMDB的可用性，对发挥CMDB的管理价值起着重要的作用。