利用 WebSphere Application Server for z/OS 中面向目标的工作负载管理

核心提示： 该业务事务的资源消耗（CPU、I/O）)也可交由 Enclave 自己负责，使用 Enclave，利用 WebSphere Application Server for z/OS 中面向目标的工作负载管理(3)，可以对跨越从 WebSphere Application Server 到其他子系统

该业务事务的资源消耗（CPU、I/O）)也可交由 Enclave 自己负责。

使用 Enclave，可以对跨越从 WebSphere Application Server 到其他子系统的整个业务事务分配性能目标，并获得跨地址空间边界的事务资源消耗的集成视图。

共有两种类型的 Enclave：依赖 Enclave 实际上是现有地址空间的逻辑扩展。它简单地从原始地址空间继承服务分类。相反，独立 Enclave 则是单独地进行分类的。图 2 说明了依赖和独立 Enclave 的概念。WebSphere Application Server for z/OS 使用独立 Enclave，因此独立 Enclave 将是我们讨论的重点。

图 2. 依赖和独立 Enclave

使用独立 Enclave

如果没有为 J2EE 应用程序指定服务分类（甚至没有为 WebSphere Application Server 类型的工作负载设置缺省服务分类），则会将 Enclave 划分到 SYSOTHER 服务分类中，这是系统定义的服务分类，具有 WLM 的自助服务目标，该目标本质上就是让系统“竭尽所能地做得最好”。这样的结果在于，仅当没有资源竞争时才能为工作负载提供服务。因此，将 WebSphere Application Server 工作负载划分为 SYSOTHER 分类是不可取的，因为在受约束的环境中，该工作负载将无法与其他“更高优先级”的工作负载竞争资源。更糟的是，如果传入 WebSphere Application Server 的工作请求没有在某段时间内完成，则很可能会触及各种超时参数，例如 HTTP 超时、事务超时，等等。发生这种情况时，控制区域在缺省情况下将终止服务区域，以清理环境并防止重要系统资源被阻塞。服务区域将由 WLM 重新启动以继续该工作。如果 CPU 资源在该时段中非常紧张，则服务区域将很难启动。当所有这一切发生时，活动系统中的请求可能排队等候并超过另一个超时参数，从而导致另一个服务区域重新启动，同样影响到应用程序可用性。