Tivoli developerWorks

Archive for March, 2010

TWS 学习笔记 – FTA内部结构

03.29.2010 · Posted in 作业调度自动化

FTA,DM,MDM在很多环节上有类似的结构,下面的图并没有涵盖所有的部分,只包含了作业调度,作业分发的部分。其关键性的组件是Batchman,jobman,和mailman。 启动顺序:当一个FTA启动的时候,首先启动脚本启动的是netman,然后由netman初始化mailman,batchman,jobman。 netman的主要职责是接受远程FTA的消息,并动态的生成一个Writer的进程,将消息写入Mailman的消息队列mailbox.msg,Writer进程将随着任务的完成而结束。 batchman是整个任务调度的核心,主要两个任务:1)它负责根据mailman提供的任务完成最新情况(定期读取intercom.msg队列),更新任务计划文件(Symphony file),2)读取Symphony文件,解析作业之间依赖,将可以执行的作业写入courier.msg队列。 Jobman定期读取courier.msg队列中获取可以执行的作业信息,执行任务,完成之后将执行结果通知mailman(把结果写入mailman的mailbox.msg队列)。 Mailman做消息传递的核心组件,他负责接收远程FTA传递过来的作业完成情况(从netman渠道),以及本地(从jobman渠道),并将结果汇总发给batch。 从中可以看出,其中两个环节对作业的执行性能有较大的影响: 进程之间的通信都是通过异步的消息传递,因此,消息队列的查看频率是我们调优的一个主要环节,以上涉及到的哦三个重要的队列,batchman队列:intercom,jobman队列courier,以及mailman队列mailbox,在adminguide 143页有每个队列的长度以及检查频度的调优方式。 另一个重要的环节就是batchman对symphony的解析,因为TWS的调度依赖跨机器,因此任何一个任务的结束势必将广播消息,导致所有FTA的batchman扫描整个Symphony,即便所有的工作都在内存完成,也会比较慢(当symphony所包含的job数量超过一定的限度-假定按照文档是40000个,那么性能的瓶颈将会出现在batchman,最近的测试所展现的症状是这样),我目前能想到的绕行的方法是定期jnextplan,将整个作业计划切分成较小的部分。 注:由于本人也刚开始接触TWS,有些理解未必正确,仅供参考: 大图:http://ext.xoopit.com/2/m4QrH71SZXGtFDcRf.b068kLcXWV_AI2w/rmm.contents.raw?cd=a ...

TWS 性能调优

03.27.2010 · Posted in 作业调度自动化

最近的一个TWS测试,在大量Job(几十万个),Job Stream(十几万)同时提交的情况下,TWS效率有明显的下降,文档也只说明了在40000以上Jobs 对象以上,需要在各个方面进行调优,也没有确切的承载极限,下面是从Admin Guide摘出来,所用到的性能调优参数: @Network traffic Optimize the network performance on admin guide page 141 1.Critical business activities must be as close as possible to the master domain manager 2. The domain manager must be installed on as powerful a workstation as possible 3.A similarly powerful backup domain manager must be included in the network 4.The network link between the domain ...

BAM 解决方案设想

03.12.2010 · Posted in 服务可用性和性能管理

§Business Activity(业务活动) 是指一项业务执行过程(Business Process)中,所包含到业务操作,以及这些业务操作之间的关联关系,拓扑结构,和每个操作的执行状态。 §Business Activity Management(业务活动管理) 是一套企业解决方案(Enterprise Solution),旨在为业务活动状态(status),业务活动过程(process),业务活动交易(Transaction)提供实时信息,并对与之相关的业务应用,IT资源进行管理和关联。 BAM的结构 业务层面的监控:客户最终关心的依然是业务,包括业务的可用性,性能和操作过程,理想的情况是我们能直接让客户对于整个业务以白盒的形式呈现出来一旦业务出现故障,那么必定需要drill down来诊断故障。 应用层面的监控:一个真实的业务必定对应一个或者多个应用程序,对应用本身的监控,其实对业务最好的监控视角(如果我们无法直接的监控业务)。我们也希望应用的过程,也能以白盒呈现给客户。但现在依然不能,WRT/RRT只能最外层的终端响应时间做监控,roundtrip time,对于客户,应用依然大量的部分是黑盒子。因此,我们依赖一ITCAM for TT,但TT对客户应用容器有一些要求 容器层面的监控:有些时候,由于我们无法在应用层面做到白盒(TT最适用的场合是银行的WAS+MQ+MB+CICS的结构),因此,我们只能通过从容器的某些指标,辅助判断应用的执行。这和直接监控应用比较,当然是差一些的视角,但目前只能退而求其次。容器的哪些指标可以反映性能呢?以Siebel为例,Task相关指标就可以,如果DB,那么SQL的执行时间可以作为衡量指标之一,如果是J2EE容器,那么Servlet request的响应时间,可以作为衡量指标,诸如此类…… BAM的生命周期: ...

BAM是什么

03.07.2010 · Posted in 服务可用性和性能管理

BAM,Business Activity Management,是Garnter首先提出的,目前广泛被使用在各个IT服务提供商的一个术语名词,在ITSM领域,这种术语层出不穷,常见的BSM,Business Service Mangement,之外,还有开始耳熟能详的BTM,Business Transaction Management,等等。但BAM是一个很容易让人误会的词,有多容易误会,我先讲一个真实的故事。下文中的客户,和提供商都是行业有名有姓的,来头比较大的,居然也有这么晕。 2009年的某天,销售打来电话,说需要我们给某客户提供一个BAM的方案,我说BAM是什么,我能有什么帮助,销售说不清楚,和架构师联系,也是含糊其辞,最后大家打着飞的,在杭州回合,次日,来到客户会议厅,架构师给客户讲了半天的IBM BSM的方案是怎样怎样,现在看来,原来都不知道BAM是做什么,更夸张的(其实一点也不难理解),客户也不知道,迷惑的听了一上午,随着我们的思路一起讨论。最终,可能也不了了之。回头去看这此交流,结论是居然所有与会者都不知道BAM是干什么的。 由于项目的需要,开始学习BAM,但很快发现了一个现象,当从google中搜索“IBM BAM”,我们得到的方案,全部来自WebSphere家族或者FileNet,搜索“Oracle BAM”全部来自对应的中间件家族,搜索HP BAM,其方案和MS的BizTalk是很紧密结合的(HP自Oracle收购sun后,与其分道扬镳,开始和MS合作)。这说明什么?业界的BAM方案,不属于ITSM范畴,而是和业务流程紧密联系的中间件平台。 那么,BAM的核心概念到底在哪个环节?如果读Garnter(Gartner overview of BAM, Definition (PDF)),和百科上的解释,BAM的外延很广,和BSM也有大量的重叠部分,即基础的IT资源,已经IT服务的管理监控,并且所谓的业务活动(Business Activity)也是构建在业务应用之上,而业务应用也是构建在,诸多的IT服务之上,IT服务构建在IT基础框架(中间件,数据库,OS,网络,硬件……)之上,而不同之处在于:在业务活动层面,对业务活动的过程进行管理和监控。 在现行很多BSM解决方案中,Tivoli产品所能直接覆盖只能是低下三层,业务应用,容器,基础平台。对于BSM而言,低下三层都可以被看作对业务请求直接或者间接的支持,都可以通过TBSM来建立映射模型,但对于业务活动的监管,则必须依赖业务流程平台数据支持,这就是为什么我们搜索出来的BAM放来都绑定中间件产品的原因,并且,那些产品也必定不可能是通用方案,因为这一层和业务流程平台的实现紧耦合。换句话说,BAM更应该是业务流程平台实现的一个附属物。 举个例子说明,BAM应该展示出来的应该是这样一个试图: 比如,在电信业,一个欠费停机业务,包含若干子业务,当我们执行一个欠费停机操作的过程中,涉及到若干子业务的操作,而这些子业务是否都正常的,执行,并最终完成整个计费停机业务是客户所需要从中知道的核心信息,如果不正常,客户可以:跟踪业务活动的状态,查看业务活动的进展,并向下追溯到与业务活动相对应的业务应用的执行情况,以及业务应用所使用的IT资源…… 而这部分——并向下追溯到与业务活动相对应的业务应用的执行情况,以及业务应用所使用的IT资源……,就和BSM同源了。这个层面之上,关于业务活动的追踪和管理,监控等等,应该才是BAM的核心概念。 ...

JVM 线程资源消耗

03.04.2010 · Posted in 服务可用性和性能管理

今天和客户交流ITCAMfAD功能时,客户希望对单个JVM中线程资源消耗,包括线程的CPU,内存消耗进行统计。确实这部分信息在ITCAMfAD中不能直接得到,只能得到JVM中线程的列表,和之间从属关系,以及线程优先级等等。 在Windows下有一个很好的工具pslist,需要的可以从这下载:http://technet.microsoft.com/en-us/sysinternals/bb896682.aspx 可以直接获取如下信息: pslist -d <Java PID> Tid Pri    Cswtch            State     User Time   Kernel Time   Elapsed Time 2908   8      2025   Wait:Executive  0:00:00.359   0:00:01.312    1:48:08.046 4344  15       157     Wait:UserReq  0:00:00.218   0:00:00.015    1:48:07.921 4836  15    415456     Wait:UserReq  0:00:00.000 ...