CMDB原形第二稿完成
日期：2014-05-16 浏览次数：20408 次
CMDB原型第二稿完成。
从25日开始进行的CMDB的原型，到现在第二稿基本完成。
第一稿纯粹是进行数据结构的设计。手工添加数据进行脑力风暴式的验证。第一稿只做到配置建模数据结构，对配置实例并未涉及。
第二稿是对数据结构的原型验证，对所需技术进行了初步的探索，由于是边想边写，其中过程反复了几次。
这里把简单的一些思想记录下来：
什么是配置管理？配置管理的精髓在哪里？
配置管理，在运维概念中，就是把运行相关的所有外生变量（可以调整、变动的信息）搜集并加以管理的过程。它与运维的变更、事件、问题、上线等多个活动密不可分。它包括的内容五花八门，有硬件信息、软件信息等等，只要运行相关，影响运维活动并可被运维活动所改变，则都可以记为配置。
典型的配置有：主机类型、主机厂商、主机ip地址，配置文件、内核参数、CPU类型、CPU序列号等等。通常可以由配置项-配置值结对组成：
例如：
主机名
：= myhostname
主机厂商
：= HP
复杂一点的，配置可以是有结构的，例如：
主机ID
:= myserver1
主机名
:= myhostname
网卡1
:= intel
IP地址
:= 192.168.0.1
MASK
:= 255.255.255.0
网卡2
:= wan
IP地址
:= N/A
MASK
:= N/A
当然应用程序更是有配置，而且通常以配置文件出现。
XX APP
:= xxapp.ini
配置管理不是为了配置而配置，它是一个辅助系统，是为其他管理活动服务的。单单考虑配置管理没有任何意义（也许可以做资产管理使用）。考虑配置管理，一定要从变更、事件、问题等活动中去思考。这是配置管理的精髓，也是运维管理的最难点。
简单说来，一个变更，如果涉及对配置的修改，那么它修改了哪些配置，影响范围有多大，是否是配置完整/一致（没有遗漏项或不一致项目）的变更，都应当从配置管理中找到答案。无论是否运维单位是否建立了正式的配置管理，只要是实行变更控制，就肯定有自觉/不自觉的配置管理。
而配置管理要能帮助进行影响分析，就需要对现有配置项目进行建模分析，也就是建立一个立体的配置模型，这，就是配置管理的精髓。
配置建模的问题在哪里？
对一个特定系统、特定目的进行配置建模是容易的。例如，为某一个主机的网络进行配置建模是容易的，即主机/网络/网卡配置。每一层都有特定的配置项目，如下即为一个简单的模型：
主机层：
主机名：
网络1：本地网
192.168.0.*
网卡1:intel
mac：
pci槽口
网络2：远程网
10.0.0.*
网卡2:intel
mac：
pci槽口：
那么对此配置的变更影响分析就较容易分层做出，例如网卡变更、IP地址变更、主机名变更的影响范围（对此主机的影响而言，对此主机所属网络则不然）容易确定。
而如果需要对整个网络进行影响分析，则需要对整个网络进行建模。例如，如果确定某网络就是由两台主机，一个交换机，一个防火墙组成，而且拓扑方式确定，那么按此建模后，网络的配置描述起来就相当容易了，也容易进行影响分析。尝试用一种模型适用于任何网络结构，显而易见是非常非常困难的。
因此配置建模的问题在于，如何方便建立一个描述现有系统的模型。也就是说，配置管理的首要任务是配置模型管理，然后才是配置项目的管理。
配置模型用于描述系统结构，配置项目用于配置模型的实例化。
例如配置模型可以描述：
XX类型网络：
网络信息（IP段，用途等）
包含主机类型
包含交换机类型
包含防火墙类型
他们的组成信息（有多少主机、多少交换机、互联方式等等）。
组成信息难以通用，可以由一小段程序（脚本）描述。
配置管理可以根据配置模型进行实例化，成为配置项目。
配置模型+配置项目，很容易为变更控制提供可靠地影响分析。
这两天的工作小结
学习了CLR/C++编程，尝试了动态创建界面。mysql封装，Python无缝结合，C++/Python数据结构互相使用。
.NET CLR是好东西。mysql也不错。
实现了配置模型管理，完成了继承、引用、包含的模型
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
