• 不要迷信品牌。品牌能为他的质量提供多大的保障？我觉得只有50%，另50%需要你自己的来判断，尤其是面对当一家做的范围很广企业。
• 要自己去思考。找几个大的供应商来讲讲，然后拼凑一把，所谓，博取众家之长，实际上，你会发现，其实众家的目的都是一致的。就像，狐狸诱因乌鸦投票，乌鸦开口说“普京”，结果肉掉到了狐狸嘴里；但乌鸦如果开口说“梅德韦杰夫”，肉还是掉到狐狸口里。其实乌鸦可以不投票。
• 成就客户。其实是，你成就我的口袋，我就成绩你的业绩。千万别以为，你成就了我的口袋，我就一定会成就的你的业绩。只不过，很多国企，一旦成交，就不得不承认“我确实成就了你的业绩”。
• 客户案例。没有人希望做白老鼠，第一个吃螃蟹，但最大的风险不是没有成功案例，而是轻易的相信所谓的成功案例。并且用成功案例取代自己的思考和判断。
• 自己负责。没有谁会替你负责，最终也是“流程”负责，除非你用钱来换特例。但这样做实际上是不划算的。
• 专家。其实很多专家，和我们从电视里面看到的那些“专家”是一样的，不管是否真懂，都不妨碍他用万分肯定的语气描述给你。这不是专家的错，他们要生存，你得学会自己判断，如果你愿意花1个小时Google一下，那么你会发现你也是专家。
• 必要的苛刻。如果你太nice，太善良，乙方不但价格上宰你一刀，还给你配不好的售后服务人员，同时还把你做成成功案例。

• Validate Situation
• History Data Collection

TEMA分发的的Situation的数量，Situation巡检的平率高低，Situation是否在TEMA端验证，都会给TEMA的性能开销带来很大的不同，因此不能一概而论，简单的说，Situation数量越多，巡检频率越高，需要在Server端验证的Situation，Situation验证是所要检索的表的行数越大，那么对资源开销就越高。比如表行数过多，将消耗更多的CPU。如果在Server端验证，将消耗更多的内存，和网络开销。

历史数据收集同理，如果搜集的频率高，搜集的属性指标多，那么对系统开销越大，每次搜集带来的开销主要依赖采集的方式和数据量大小，比如，DB的Agent，性能采集通过SQL，那么消耗来自SQL本身，如果磁盘性能采集，而系统有很大的磁盘阵列，那么性能开销来自list 整个磁盘阵列……等等。

当某个Agent的对资源消耗过大，比如CPU，内存消耗太多，那么我们诊断的方法是（假定不是Agent的bug带来的性能问题），逐个的取消Situation，和历史数据搜集，看看哪个带来的性能问题，换言之，如果没有负载situation和历史数据搜集，TEMA的资源消耗应该非常之小。

The Amazon EC2 Agent is one of our most feature rich agents yet:

• ITM subnoding gives extensive information on each individual instance in your EC2 environment
• High level views of all instances on your EC2 account
• Auto discovery of new or deleted instances
• Historical data for monitoring long term performance or problem areas
• ITM Take actions to start and stop your instances
• Pre-made ITM situations to alert you to important events such as the termination of critical instances or an abnormally high CPU utilization

Blue Medora是一家位于美国密歇根州的IBM Tivoli BP，致力于基于ITM/ITCAM的扩展解决方案。

在此，有些感想和大家分享一下，通常认为，对于Tivoli不论售前咨询，还是售后服务，都似乎不太需要看起来过于贴近开发领域的设计模式的知识，其实我倒是觉得，设计模式的思维方式可以运用于任何建模的环节，当然也包括售前的架构咨询，和售后的服务的前期设计。

据我的观察，国内大部分的架构都来自“对成功案例的复制”，很少创新，其原因一部分是，对企业应用架构，企业集成架构的缺乏理解和灵活运用的能力，只能重复前人的经验，或者搭建简单的积木。此外，了解设计模式，能有助于快速的理解大型软件，因为很多组件的命名能直接反映它在架构中的位置和作用，比如常见的Adapter，Gateway，Probe，Filter，Bridge，等等，在Tivoli软件中经常见到。

目前绝大部分IBM软件产品的界面，只要是WEB的，多半都基于ISC，一个既不美观，也不高效的框架，Tivoli集成门户TIP基于eWAS的Portal框架，不但是管理端复用了ISC，展示层定制化部分则依赖于WebSphere 的Portal Server，每个小的数据区域通过客户化Portlet来实现，Portal技术和ISC同样的不美观，由于和ISC类似，需要在服务端wrap展示内容，因此经常为了获取少量数据而提交整个页面，并且对数据的来源也没有选择。

这些基本的问题，如果通过Mashup，几乎都可以轻易的避开，更重要的是，在定制开发层面，有大的多的灵活性。这对于IBM解决方案来说尤为重要，因为很多东西对于客户而言都只能算是半成品，加上Tivoli家族产品繁多，来源复杂，集成的需求无处不在，而mashup是看起来，把展示层面和数据提供层之间的耦合度降到最低的一种方式了。希望能尽快的看到一些进展。

同时，这是对集成商的好建议，展示层基于Mashup方式构建，非常有利于应付IT服务管理这一类的集成项目，这类项目的特点就是厂商多，标准少，产品线长，集成度不高。

IBM Mashup Center Wiki：http://www-10.lotus.com/ldd/mashupswiki.nsf

启动顺序：当一个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

@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 manager and its backup must be as fast as possible to pass all the updates received from the subtree

5.If intervention is needed directly on the domain, either give shell access to the operators to use the Tivoli Workload Scheduler command line, orinstall a connector so that the Tivoli Dynamic Workload Console and the Job Scheduling Console can be used.

About  the downstream node capability:

The maximum:20 for Solaris, 50 for Windows, 100 for other UNIX workstations

Typical downstream connections is : 10 for Solaris, 15 for Windows, 20 for other UNIX workstations.

@Tracing

Log file metric: Admin guide page 193

@Symphony file size

The most important thing is making file system has enough space for Symphony file, and there is a way to estimate the Symphony file size.

Please go to admin guide page 192

@UNIX MDM handle lots of FTA

We may need change some kernel parameters for better performance, there is reference in admin guide page 266 for HP UNIX tuning.

@Planning space of queue

In admin guide page 143, there is a table with all the queue and their purpose.

“evtsize -show” to show the length of queue, evtsize to change the queue max length

@Mailman server

In admin page 148

@ To improve job processing performance

:Use optman to change the configuration, which is described in user guide page 106

@ Mail box caching – Default is Yes, parameter: mm cache mailbox

:localopts

Caching Advantage: deduce IO, but will bring the potential consistent issue

Caching Disadvantage: More real time msg handling, but bring more IO consuming

More details in admin guide page 269

@Sync level parameter – Only impact UNIX environment

:In localopts

synch level = high

Each write operation on the event files is immediately physically written to

disk. This has a heavy impact on performance caused by the high I/O

dependency.

synch level = medium

Each write event is considered as a single operation. For example, while

TWS_write_event_lock contains only one action, TWS_write_event_update

comprises five actions. With synch level at medium, the five actions in this

write event would be completed in one physical disk access, thus

drastically reducing the I/O overhead.

synch level = low (default)

The operating system decides how and when to synchronize the data to

disk. The impact of this option is more difficult to assess, because the rules

are different for each operating system and file system.

@FTA  Switch manager

The fault-tolerant switch manager is enabled by setting the enSwfaultTol global option to yes. When it is set, the master domain manager

distributes messages to all fault-tolerant agents with FullStatus set to yes.  Enable this feature will impact:

1.  network traffic

2.  Disk space

@Scalability, In large number of job scheduling object

1.Impact on Jnextplan: JnextPlan need handle lots of job scheduling. For jobs exceed 40000,

JVM: It is better to extend the JVM heap size to be 1024M, default is 512M

DB2: Default DB2 configuration can only handle 180000 instance, if exceed this, we need to extend the DB2 log capabililty

2.Impact on Reporting:

JVM: If Reporting contain more than 70000 objects, the JVM heap size need to be extended to 1024M

3.Impact on event rule deployment

JVM: if event rule exceed 8000 rules, heap size need to be extended to be 1024M

JVM Change: change server.xml of WAS, and update the generic JVM parameters

DB2 Change: determine how big size we need, and how to change the log capacity on admin guide page 274

]]> http://tivolidw.org/blog/?feed=rss2&p=123 0 http://tivolidw.org/blog/?p=118 http://tivolidw.org/blog/?p=118#comments Thu, 11 Mar 2010 17:50:49 +0000 Roberto http://tivolidw.org/blog/?p=118 §Business Activity（业务活动）

• 是指一项业务执行过程（Business Process）中，所包含到业务操作，以及这些业务操作之间的关联关系，拓扑结构，和每个操作的执行状态。 §Business Activity Management（业务活动管理）
• 是一套企业解决方案（Enterprise Solution），旨在为业务活动状态（status)，业务活动过程（process），业务活动交易（Transaction）提供实时信息，并对与之相关的业务应用，IT资源进行管理和关联。

BAM的结构

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的核心概念。

在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   0:00:00.000    1:48:07.921

2496   8         1     Wait:UserReq  0:00:00.000   0:00:00.000    1:48:07.796

4648   9         1     Wait:UserReq  0:00:00.000   0:00:00.000    1:48:07.796

3116   9         7     Wait:UserReq  0:00:00.000   0:00:00.000    1:48:07.796

5268   8       189     Wait:UserReq  0:00:00.015   0:00:00.000    1:48:07.796

5220   7   6991523          Running  1:47:42.031   0:00:01.218    1:48:05.593

3932   9         2     Wait:UserReq  0:00:00.000   0:00:00.000    1:48:05.125

整体思路：

在业务请求（business request）环节上，通过TBSM建模来映射业务请求和IT 服务之间的关系。

在IT Service体系内部，通过ITCAM家族的工具来动态发现应用（ITCAMfTT），隔离问题（ITCAMfTT），并通过Launch In Context，结合SME工具（ITCAM for APP + ITCAM for AD）来诊断应用问题。

因此，Tivoli中BTM的方案通常涉及到两个产品家族：TBSM+ITCAM for Transaction

当我们从dashboard上看到异常时，整体上BTM的思路大致是这样三个步骤：

1. 通过BTM（Business　Service　Management）评估某对业务的影响

2. 隔离问题发生的区域

3. 结合SME Tool诊断问题

关于更多BTM的范围，职责，以及目标，我参考了Doug部分内容：

Reference：Business Transaction Management

另，TBSM和ITCAM for Transaction的集成已经从FP2开始提供。

效果如下：

届时，IBM将为您展现对于云计算的整体规划和清晰的实施路线，从“软件、硬件与服务”三方面探讨云计算整合解决方案。IBM融丰富实践经验与创新精神于一体，通过硬件的虚拟化、软件的服务管理与自动化部署、云服务、云架构设计等，将力求改变当前零散、混乱的云计算市场现状, 与您携手共铸未来。

有兴趣的可以注册：http://www.cloud4u2010.com/

Intelliden公司的软件产品可通过对集线器、交换机与路由器的自动配置，帮助电信企业管理自身网络。该公司称超过60%的网络故障是由于不当的手动配置造成的。Intelliden是一家总部位于美国加州门洛帕克的非上市公司。公司产品会在收购后并入IBM Tivoli软件中。

估计应该是纳入Automation Pillar，让我们等等看IBM准备把它放到整体架构中的哪个位置。

我问过一个无聊的问题，“Tivoli还会持续这种不断并购的策略吗”，今年的Acadmey有人说了些真话，或许是的。IBM是头大象，大象的特点是移动缓慢，但一旦移动能量巨大。老大举例说，当youtube风光无限的时候，一夜之间，出现了千万个youtube，IBM能跟风吗？下面的话，我补充完，IBM没有可能在这一时间迅速的响应，即便是研究院盯着，也不敢轻举妄动，因为他是大象，他必须为自己每迈出去的一步负责，大象不能苛求敏捷。但或许一旦证明这是一个符合公司策略并有利可图的领域，大象则大步迈进，赶走同舞台的小动物，成为笑到最后的人。

“铁打的品牌，流水的产品”，想踏入Tivoli的同仁们要有心理准备，把有限的生命的奉献给无限的产品翻新当中去:)

ps，2010年2月4日，也就是3天前，收购了initiate，总部在芝加哥，主做医疗和政府行业的数据管理领域。

云计算的定义和理解，应该超过了SOA和Web2.0，成为最让人困惑计算机术语：），而Tivoli作为IT服务管理，也积极的参与到云计算当中来，当然作为动态基础架构环节的一分子，Tivoli定位不在其中，而是提供对云的支持，供给，管理。

落实到与云相关的Tivoli产品就是TSAM（IBM Tivoli Service Automation Manager）。此产品以TPM和TSRM为核心而构建，具体的了解非常粗浅。官网了解更多：http://www-01.ibm.com/software/tivoli/products/service-auto-mgr/

• 尽量不必要使用Group Function，也就是MIN, MAX, AVG, SUM, COUNT，这种函数。原因是这样，当配置了这些函数，那么Agent无法在采集的那一刹那，判断出是否满足Situatoin的公式条件，只能把数据传递给TEMS，在一个缺省的时间段内，把Agent连续传过来的值做平均，然后判断是否告警。这样效率肯定是很低，首先Agent自身不能验证Situatoin，一旦把验证的任务交给TEMS，那么对性能就是极大的伤害，而且低效。这里，绕行的方法很多，比如可以采集一些平均值（比如AIX OS中有些指标本省就是平均值，就利用之，不要用瞬时值，依靠ITM来做运算），或者，用连续多次，超过阀值，来告警，以避免偶尔阀值超越产生的无告警。
• 把最严格的Situation限制条件放到第一个，这个应该比较好理解，这样能让验证的数据量尽快的降到最小。比如，Situation有3个条件，采集的数据有100 rows，那么第一个条件导致满足的只有10条，那么后两个条件，只用面对这10条做验证了。
• 为重要的系统建立单独的managed System，这样能尽量的让其他的Situation减少对重要系统的干扰，在Situation tuning中可以有针对性的tuning。
• 尽量不要使用太短的sample interval，一旦告警的验证周期，不足以确保采集，那么必然会导致数据丢失或者告警延时。比如，很多客户轮询SOAP，N个系统，几百个SOAP，轮询下来10分钟，但是告警周期是8分钟，那么就会出这个问题。
• 尽量减少大数据量属性组的Situation，有的属性组返回数据量极大，最常见的就是有的系统进程数几百个，或者磁盘mount的几百块，比如Situation要检查某个进程的CPU消耗，要把所有的进程信息都获取到，然后做判断，这种情况内存，CPU，消耗都很大。需要提一下的是，从ITM622开始，进程的missing function在Agent端验证了，以前实在TEMS上。
• 如果需要到TEMS验证的Situation，可以考虑分散到不同RTEMS，某些情况，我们不得不考虑在Server上验证Situation，包括前面的AVG，MIN，等函数，还包括一些关联Situation，比如A发生，同时B也发生了，才告警，牵扯到不同的属性组等等，都需要到TEMS验证，这时候，考虑到压力分担道不同的RTEMS。
• 不需要的Situation不要启动，缺省系统有些Situation自启动的，在生产环境中，这些都要仔细检查，没用的都不要启。

需要了解采集数据的机制，基本上目的两方面：

• 出了问题，知道从哪去找根源
• 从采集方式上可以大致判断Agent对J2EE容器性能的影响

ITCAM for WR的TEP上有四类数据：

1. Resource data：数据来源PMI
2. Request data：数据来源DC
3. Data from WebSphere log files：数据来源WAS系统日志，SystemOut.log，gclog，DC mesg event
4. 进程信息，比如WAS进程CPU使用率 ：来源OS API。

Resource Data相关Worspace：

• Web Applications
• Web Applications : Servlets/JSPs
• Web Applications : Sessions
• EJB Containers
• EJB Containers : Enterprise Java Beans
• EJB Containers : Container Transactions
• EJB Containers : Container Object Pools
• DB Connection Pools
• J2C Connection Pools
• Thread Pools
• Cache Analysis : Dynamic Cache
• Cache Analysis : Dynamic Cache Templates
• Workload Management : Workload Management Server
• Workload Management : Workload Management Client
• Scheduler
• Web Services
• Web Services Gateway
• Messaging Engines
• Client Communications
• Messaging Engine Communications
• WMQ Client Link Statistics
• WMQ Link Statistics

DC 来源的数据：

• Request Analysis：需要DC工作在L1
• Datasource：需要DC工作在L2
• JMS summary：需要DC工作在L2

日志来源的数据：

• Garbage Collection Analysis：在配置的时候有选项，通过GC verbose选项开启JVM的GC详细日志，缺省gc.log。
• Log Analysis：SystemOut.log，DC Event log

OS来源的数据：

• WAS进程的CPU消耗