上世纪九十年代，IBM推出了新一代的工作负载和性能管理工具——工作负载管理器（Workload Manager，WLM）。在Sysplex级，WLM与工作负载入口（例如Sysplex分发器（Sysplex Distributor，SD）和VTAM通用资源（VTAM Generic Resources））互相配合，将接受的负载分配给最空闲的LPAR（逻辑分区）。尽管这种机制在全局级非常有效，但是对于子系统中的一个工作负载分区而言，不同类型的效率定义可能会产生一些出人意料的后果。

　　LPAR中的效率定义

　　当工作负载到达一个LPAR时，就由接受该负载的子系统支配。对于各种子系统，效率的定义似乎都是围绕响应时间、指令路径长度和避免I/O通路切换等指标。

　　事实上，效率的定义最近已经成为一个需要进行修改和重新定义的主题。例如，一名CICS（客户信息控制系统）代表去年曾表示，“CICSplex系统管理器（CICSplex System Manager，CPSM）的动态事务路由（Dynamic Transaction Routing，DTR）并不是一个工作负载平衡器。DTR的工作是将负载分配给在最短的时间内能够最有效地处理事务的工作负载分区。”在这种情况下，“最短的时间”意味着CICS试图将工作负载保持在相同的LPAR上，以避免CPU和I/O通路的切换。

　　同样地，MQ（消息队列）支持人员最近也改变了以前的观点。之前他们曾认为，通过触发器接口消息出队，共享队列可以理所当然地平衡工作负载。Orwellian文档APAR PK60692对此做了详细解释，并概述了新的负载处理过程。这一新的策略美名其曰“快进早出（Fast Put to Waiting Getters）”，在负载被分配到耦合设备（Coupling Facility，CF）之前就将消息发送到仍有未完成的等待的触发器。这样避免了大量开销，但往往会使更多的负载进入到接收消息最多的队列管理器。

　　就其本身而言，IMS（信息管理系统）将通过使用公共存储区并行处理本地LPAR中的负载，以继续减轻事务路由的压力并维持其久负盛名的效率。

　　出人意料的后果

　　这种出人意料的后果很容易理解。例如，假设有一个工作负载通过SD连接到IMS。WLM建议系统在凌晨3点开始运行该工作负载，但这可能不是最佳运行时间。这意味着容易与主机维护长期会话的“粘滞型”应用程序可能会在一个无法承受该工作负载的LPAR上发生拥塞。Parallel Sysplex解决此问题的办法是，将每个IMS子系统配置为能够处理全部工作负载。尽管这种效率定义考虑了响应时间和网络流量，但却是以增加CF活动、虚拟存储器和系统管理为代价的。

　　另一个例子是一个CICSPlex覆盖多个LPAR，而这些LPAR由来自一组分布式服务器的共享消息队列驱动。接收传入消息的本地队列管理器将尝试把负载分配给一个空闲的本地CICS。只要不同LPAR中的队列管理器接收到的消息数量大致相同，这种机制就可以很好地工作。但是，如果一台分布式服务器与一个主机队列管理器之间的通信中断时，则通道出现故障的LPAR接收到的消息将减少，此时各LPAR之间的负载将失去平衡。由于具有完全备用通道的LPAR将达到更高的事务处理率，所以CICS的工作负载将反映这种不平衡。另一个办法是创建足够多的分区，使每个LPAR都能够处理全部工作负载。利用这种方法，可以获得更短的响应时间和指令路径，产生更高的CPU和实际存储器使用率。
　
　　效率才是王道

　　我认为大多数客户都难以负担将每个LPAR配置为可以处理全部工作负载的成本。相反，大多数客户将根据硬件和软件成本来定义效率。他们还希望能够直接管理工作负载，而不是通过操作WLM目标或LPAR权重来达到适当的负载平衡。为了实现这些目标，他们采用了一些缺乏效率的方法。

　　在IMS的情况下，企业可以使用共享消息队列。在共享消息队列中，接收到消息的IMS将该消息发送到CF上，任何其他控制区都可以获得CF上的消息。因此，工作负载将被分配给首先获得消息的IMS。另一种办法是，将客户端配置为每隔一段时间先中断与IMS的连接，然后再重新连接到IMS。理想情况下，当一个客户端重新连接到IMS时，SD将根据更多的当前WLM信息做出决策。因此，根据LAPR的空闲情况，可以将工作负载从一个LPAR迁移到另一个LPAR。

　　根据典型的DTR策略，驱动本地CICS触发器的MQ决策过程将被跳过。在这种机制下，占用MQ触发器的CICS将启动被路由到其他LPAR中应用程序自有区（Application Owning Regions，AOR）的另一个事务。

　　令人费解的是，尽管IBM客户可能要经历漫长的响应时间、网络负载失衡、更高的CPU使用率、过度频繁的CF活动和I/O通道切换，但他们最终节约了资金。他们之所以能够节约资金，是因为他们可以更有信心地运行不均衡的硬件配置，并在必要时平衡工作负载。当然，最终的解决办法是由IBM为客户提供选项，使他们能够利用子系统而不是受制于子系统，以有效地管理工作负载。