Monthly Archives: August 2008
Xen quick start guide on openSuSE Linux 10.3
If you had installed VMWare workstation on any Linux, you may have kernel source problem. Because a default Linux installation do not include kernel source package. I’m just saying that you should always play with open source Virtualization, Xen or Virtial Box are all good stuff to run ;) . I got some screen-shots for
Open Source Total IT management Solution
在IT管理领域里,商业软件厂商中有自称Big 4的集团:CA,HP,BMC, IBM;在开源软件项目中也好像有自称“开源Big 4”的集团,他们是Groundwork、Hyperic、Qlusters和Zenoss公司。商业厂商向用户推出自己的产品的时候,往往都会打着一些比较大的概念和幌子,说“我们是IT管理的Total Solution”;潜台词是我们的产品非常多,可以满足您所有的需求,而且只要您选择了我们,我们能保证所有的产品模块之间是无缝集成的。事实上的确如此,商业厂商凭着后台开发团队的强大,还有本地服务商的支持,在解决方案的集成性上的确没有什么问题。对于开源软件来说,由于每个软件都在各自为政的状态下独立发展,即使是彼此之间的功能有着某种衔接和集成性,在多数的情况下也往往是各自独立发展;没有考虑到彼此的组合和集成。不过换一个角度看,既然是开源软件,人家把源代码都全开放出来了,如果你想做两个开源软件的集成的话,从技术的角度上说,没有任何障碍;对比商业的闭源软件产品来说,似乎他们又在这方面有着与生俱来的优势。 开源的IT管理软件中有非常多的种类,就拿网管软件来说吧。我的blog上介绍了很多,其中很多的软件都是功能非常重复,而各有千秋的。要想组合一个纯开源的整体IT管理解决方案不是不可能的,需要的是对一些比较精华的软件系统有所了解,并且了解他们之间集成的方式和实现功能。在此基础上做出合理的组合,方能搭建出一个整体的方案。 由于现在ITIL已经成为了大家耳熟能详的“GOOD PRACTICE”,这是08年V3之后的一个转变,V3提出之后,它就以一种亲民的身份,自称自己不再是“BEST PRACTICE”了。既然是要攒一个“开源IT管理整体解决方案”,同时为了保持本方案具有一定的理论高度 ;) 选择ITIL作为理论依据当然是不会错了呵呵~~ 不好意思今天心情比较好,废话实在太多,抱歉,下面将开始方案书写了。 本方案将兼顾ITIL中的两大块:IT交付和IT支持。我所选取的是OpenNMS, Hyperic HQ 和 OTRS来分别支撑IT交付和IT支持者两个部分。OpenNMS和Hyperic HQ组合来完成网络和系统监控,它们为可用性管理、性能(容量)管理和服务水平管理提供支持和实现,注意这里说的是为这几个流程提供支持的工具,这些工具本身并不是流程工具。OTRS完成事件管理、问题管理、配置管理和服务水平管理等流程,OTRS本身是一个工单跟踪管理系统,他现在的ITSM模块以及发展到1.1的版本了,同时自称是ITIL兼容的软件。 IT Delivery OpenNMS和Hyperic HQ的功能定位有所不同,在这里选择他们俩来作为监控网络和系统的平台由一下的一些理由。OpenNMS是agentless的监控软件,它的网络自动发现功能非常好使,而且现在能支持越来越多的网络设备,对于国内的华为等厂商的设备需要做一些定制后才能监控,否则只能看到标准的mib2的信息。最新的版本也能支持分布式的管理功能,也就是remote monitor的模块。我没有让Zenoss入选网络监控的一个重要原因是,OpenNMS是纯开源软件项目,它的所有功能都是可用的,而且它是Java程序,配置文件大多是xml文件。对支持非常大量的网络设备和端口,你需要有的是对Tomcat和Java应用的调优能力,和通过OpenNMS的邮件组来解决bug的能力。OpenNMS里面有非常好的告警事件管理功能,它本身是一个非常好的事件平台,事件升级、报警、过滤等功能都有。而且现在OpenNMS已经能和Hyperic HQ做事件集成,Hyperic HQ的报警事件能传递到OpenNMS中,这就意味着OpenNMS可以作为一个统一集成的事件管理平台,在这里对集中管理所有类型的告警事件。HQ是一种Agent based的监控软件,对于系统监控而言,很多商业厂商的软件功能都无法很好的做到单一代理的技术,当然我认为BMC的Patrol是例外,它的单一代理技术是我见到最好的。HQ的单一代理技术意味着,通过在一台服务器上部署一次代理程序后,其他的工作就都转到web console上了,在那里,你可以配置代理对各种资源的管理,它的代理能发现非常广泛的基础架构应用:Web, midtier, DB等。由于HQ是一个商业开源的软件,所以它对商业基础架构软件的平台支持的非常好,能支持目前流行的所有基础架构软件包括各种商业的操作系统、数据库、中间件;当然它对开源的软件也能够监控。监控参数很多,配置容易,有开放的接口提供功能扩展开发。从OpenNMS和HQ的各种图形上可以很好的评价和监控和各种IT服务的质量。OpenNMS中的界面中最多的就是对某个节点或者上面的某个服务可用性的计算。 OpenNMS和HQ实现和完成的功能能为IT交付中的:可用性管理、性能管理和服务水平管理提供实时的数据支持,OpenNMS作为总的事件平台,同时它还监控所有的网络设备。HQ用来监控所有重要业务服务器,那些边缘的非重要的业务服务器或者是客户端设备也可以交给OpenNMS来管理,它的无代理监控,对这些设备也能管理的不错。 IT Support OTRS本身是一个非常不错的工单跟踪系统,它在加载了ITSM模块之后,就把ITIL的很多精髓理论做了很好的诠释和实现。对于很多大型企业用户而言可能会笑话OTRS的简陋,不过实施ITIL的过程,我觉得应该是:把当前的繁杂工作,按照ITIL的几个流程简化梳理的过程,每个流程完成比较单一而纯粹的目标;流程之间又能有一定的集成就可以了。对于OTRS的研究,我目前也处于安装和读管理员手册阶段,没时间细看。选择OTRS的一个最重要原因是,今年也开发了一个事件集成模块,它能通过这个模块与Nagios,openNMS,OpenView,Tivoli等监控产品做事件集成,也就是说告警事件能自动在OTRS中生成事件单,而OTRS的事件管理模块就负责吧入站的事件单自动化的分配给相关的技术支持人员受理解决。详情请参考Automated System Monitoring with OTRS Download这个白皮书是在OTRS.com的网站上下载的,我当初怀疑这个事件集成模块是否是开源的软件,所以在Christopher T. Kuhn 的Blog上问他了一下,他向我确认该模块是开源的,并提供了下载地址。从技术路线上来说OTRS是实现了服务台的功能,并且实现事件、问题、配置和SLA管理;从界面上看它对这些流程的支持是比较简洁的实现,你完全不能把它和商业的服务台软件来比较。不过实施ITIL的道路,我觉得应该是丰俭由人的,我相信一定会有人走简洁路线的。想想Apple的产品,它的设计无比的简洁,它简洁并不丑陋,而且还很cool,很流行。 由于这个方案攒的还是比较匆忙,而且技术上没有实际测试和验证,本文旨抛砖引玉的提出一些思路和想法,未经详细推敲,欢迎提出您的建议。
配置管理中几个的误区
配置管理的项目可以从CMDB的建设开始,也可以从配置管理的流程建设开始。我在一些配置管理的项目中发现了一些用户容易犯的错误有很多。先说说配置管理,做ITSM的项目,往往CMDB的建设,或者配置管理流程大多不会非常重视,往往作为一种辅助性的环节在项目中得到实施。例如ITSM项目一上来就做服务台,然后是变更管理流程和其他流程;在一些后续的资产管理的项目中CMDB的到重视并建设。其实配置管理流程和CMDB是ITSM项目中非常重要的一环,它建设的效果对整体效果有乘法放大的效果。CMDB的主要功能我认为有两点: 提供唯一、精确的配置信息库,让所有IT团队的人都明确IT管理配置项范围,有了它所有人都起码能清楚“我管理的东西是什么有哪些?”。都说ITIL的语言是IT管理的共同语言,那么配置信息就是这个语言的主语和宾语;从这里可以看到,如果我们没有这样一个准确的配置信息库,我们彼此之间的沟通会出现多大的误解和迷惑。我在用户现场做项目的时间比较多,耳闻目睹很多沟通障碍;这些障碍不是沟通方式和技术造成的,而是大家没有能从一开始就说清楚“谈论的CI对象到底是什么” 实现一定程度上的业务影响分析。往往都是有IT部门牵头做CMDB,后期也主要是IT部门用。有效的业务影响分析能力,可以彻底提高事件管理的有效性。一般用户可能会有一个集中Event Console,从这个console中事件一般是以生成的时间先后顺序查看和处理的。最差的事件管理方式就是这种“先进先出”的处理应对方式。如果你能说清楚,发生事件的对象(配置项)对业务系统的影响程度,那么你就能够做到按照这些事件的优先级别来处理;事件的优先级就是该事件对业务系统所造成的影响的严重程度。需要做到业务影响分析,就必须做业务模型梳理。每一个业务服务和业务流程也是配置项,IT的人也需要能理解业务。 下面列出一些常见错误,这些错误发生在企业做ITSM项目的前后都有可能,不过多是在实施ITSM项目之前,或者上CMDB工具之前,或者过程中。 1)目标不明确,实施结果无法衡量 Goal 所谓目标不明确,并不是说没有目标,而是说:目标定的不太合理。不合理的原因有一下几种:目标过大、目标过于模糊、过于教条、拘泥于ITIL的书本、和实际的工作联系不紧密、没有衡量和控制的方式。在一定的项目时间周期内,总结之前配置管理的问题,作出一个切实可行的配置管理数据库建立目标应该不难,主要以使用为主,不要拘泥于细节。 2)配置项信息混乱,信息结构无序 Scope 这里的“信息结构”是说CMDB的CI配置项信息查看应该是立体的有结构的很直观的数据信息。在访谈的过程中,有些用户在讨论过程中认为配置项组成的信息结构应该是网状的。其实现实中的IT基础架构组件的确是以网状的形式相关联的,这种想法非常实际。不过人们都太偏重IT了,遗忘了IT部门的最终使命“为企业交付各种业务服务”。业务服务就是CMDB数据金字塔的顶端部分。从IT部门提供的业务服务开始来梳理和建立CMDB配置库是一种“自顶向下”有效方式,是IT部门做CMDB配置管理过程中,与业务部门沟通的“翻译机”。自顶向下的方式需要业务部门的配合,或者IT部门内有精通业务的强人。通过这种方式做出了的CMDB,CI之间的构成方式,从宏观上看:屏幕的投影是树根型的,立体的看是金字塔形的,业务系统模型是树根的根部,是金字塔的顶端部分。微观上看,局部可能是网状的,或者是星型的。没有业务服务作为头部,很难说出CMDB的scope究竟是多大,很难说清楚哪些CI可能会在CMDB中出现。 3)配置信息随意堆积,纠缠于过多的CI属性 Level 每一个CI都可能具有非常多的属性,成功选择的标准是:够用就好,精简是王。很多用户都存在的误区就是“复杂比简单好,越复杂越放心”;大多数用户在项目初期的需求整理的时候都觉得,需求提的越全面,越好,越保险。这种心情是可以理解的,毕竟ITSM项目的周期和投入通常都是非常多的。不过对于配置管理来说却,万万不能有这种想法;否则,CMDB的维护和审计的工作量将非常巨大。一个信息量过载的CMDB,就是一个不可用的配置库。一个只有10个属性的CI和有50个属性的CI展现在你面前的时候;你找到你所关心的信息花的时间上看,前者是后者的1/5时间。属性一定要精简,特别是CMDB从零开始的用户。在设计的初期一定预留属性扩展的可能性。 4)疏于配置信息的准确性和实时性 update CMDB一旦建立了之后,所有用户一定要对CMDB使用起来,要为CMDB提供反馈。最终使用配置信息的人,如果发现信息不准确,需要及时报告配置经理。配置经理需要及时维护。配置经理最重要的职责是,确保每一个大小变更实施完毕之后对要对相关CI做更新。你可以没有正规的变更流程系统去跑变更单,不过我所看到的是很多企业即使没有实施ITSM项目,其实他们手工变更单的流程跑的有板有眼,一点都不差。美中不足的是,变更后的结果没有地方更新和反馈。而CMDB就是这样一个变更结果反馈和汇集的目的地。在大家都频繁使用CMDB,并且每一个大小变更都更新CMDB的完美情况下,CMDB中的信息会随之时间的流逝,愈来愈精确,愈来愈完善。 5)拘泥于工具的功能,忽略了最终目标 Tool 我看到的最多的工具是MS Excel,也有使用自开发系统的,可有自开发系统最终丁不住在转向商业工具的 :( 无论何种工具,假如在一个正确的事实和使用的策略下,我觉得都是可以获得CMDB建设的成功的。一个好的工具还是有必要的。在选择一个成品工具或者开发一个CMDB工具时,需要考虑工具的几个方面。工具应该参考或者借鉴某种国际标准,这里的标准是指某种通用模型标准 Common Data Model (CDM),例如DTMF的 Common Information Model (CIM),或者WMI等。好的工具需要能和其他ITSM流程紧密结合,特别是事件管理、问题管理和配置管理者三个流程。如果这三个流程是建立在某种工具平台之上的,那么CMDB的信息最好能无缝的整合的流程的处理过程中。
one minute to build your wap version blog
Wap version of my blog http://tinyurl.com/martinliu You could also build yours within one minute. I think it is worth to do, since more and more peoples are surfing from mobile device. You might get a wap link on your home page, I will do it after get this post publish out. Now, it time to
开源软件的能量
可惜yo2.cn开张的太晚了。 否则我的blog http://www.martinliu.cn 就可能在这里了,先注册一个好的名字 opensource.yo2.cn 先呵呵~~ 如果有需要请和我联系,不想浪费这么好的blog地址。