核心组协调程序

每个核心组都有一个协调程序,用来管理核心组成员之间的高可用性活动。协调程序负责管理高可用性单一服务的故障转移,并将实时服务器状态数据分发给感兴趣的核心组成员。协调程序使用一些 CPU 和内存(JVM 堆)资源来执行这些任务。在某些配置中,协调程序使用的资源数量可能很大。

注: 本主题引用了一个或多个应用程序服务器日志文件。作为另一种建议采用的方法,您可以在分布式系统和 IBM® i 系统上配置服务器以使用高性能可扩展日志记录 (HPEL) 记录和跟踪基础结构,而不使用 SystemOut.logSystemErr.logtrace.logactivity.log 文件。您还可以将 HPEL 与本机 z/OS® 日志记录设施结合使用。如果要使用 HPEL,那么可从服务器概要文件 bin 目录使用 LogViewer 命令行工具来访问所有日志和跟踪信息。有关使用 HPEL 的更多信息,请参阅有关使用 HPEL 对应用程序进行故障诊断的信息。

可以将协调程序工作负载分配给多个协调程序实例。每个实例在不同的核心组成员上运行,且将分担整个协调工作负载的一部分。通过将工作负载分配给多个协调程序实例,可以实现由多台机器来分担相关资源成本。无论协调程序将它的工作负载如何分配给各个核心组成员,协调程序功能仍然保持高可用性。

选择协调程序

当核心组成员启动或停止时,“视图同步协议”都会安装新视图。视图由互相连接且协作的各个核心组成员组成。每当安装新视图时,可能都需要在各个核心组成员之间重新分配协调程序工作负载。例如,用来管理协调程序实例的核心组成员可能已失败,那么高可用性管理器必须选择一个替代协调程序。

当选择特定核心组成员作为协调程序时,会将类似于以下消息的参考消息记录到 SystemOut.log 文件中:

HMGR0206I: The coordinator is an active coordinator for core group DefaultCoreGroup

如果某个核心组成员不再是所选择的协调程序,那么会记录与以下消息相似的消息:

HMGR0207I: The coordinator was previously an active coordinator for core group 
           DefaultCoreGroup but has lost leadership.
避免故障 避免故障: 记住,每当视图更改时就会出现选择协调程序的情况。因为选择新的协调程序时会增加网络流量和 CPU 占用率,所以,此过程将使用许多资源。只要有可能,就指定一个首选协调程序服务器,这样就不需要频繁地更改协调程序。gotcha

多个协调程序

核心组配置数据中包含一个字段,用户可以在该字段中指定协调程序的数目。此字段的缺省值是 1。对于大多数安装和应用程序,使用此缺省值就足够了。当被选择作为协调程序的核心组成员使用的内存或 CPU 资源远远超过其他核心组成员的使用量时,就要使用多个协调程序。另外,某些大量使用高可用性框架的软件产品将指示您增加协调程序数。

首选服务器

配置核心组时,如果存在一些核心组成员,那么可以指定高可用性管理器应当用作协调程序的核心组成员。首选协调程序服务器应该是那些尽可能很少执行的核心组进程。还应该在具有超多容量的机器上主管首选协调程序服务器。

指定首选协调程序服务器是一个好方法。在视图更改期间选择了协调程序时,高可用性管理器就会检查首选服务器的列表。如果有一个列表,那么高可用性管理器就会从该列表中选择一个服务器作为协调程序。如果没有列表,那么高可用性管理器就会选择其名称按词汇排序位于最前面的视图成员作为协调程序。如果这样做导致移动协调程序,那么会产生一些开销。


指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_coordinator
文件名:crun_ha_coordinator.html