cc [flags…] –I/usr/cluster/include file –L/usr/cluster/lib
–l scha#include <scha.h> scha_err_t scha_control(const char *
tag, const char *rgname, const char *rname);
scha_err_t scha_control_zone(const char *tag, const char *
rgname, const char *rname, const char *zonename);
scha_control() 和 scha_control_zone() 函数均提供一个接口，用于请求重新启动或重定位受资源组管理器 (Resource Group Manager, RGM) 控制的资源或资源组。请在资源监视器中使用这些函数。
请仅对 Global_zone 属性设置为 TRUE 的资源类型使用 scha_control_zone() 函数。如果 Global_zone 属性设置为 FALSE，则不需要此函数。有关更多信息，请参见 rt_properties(5) 手册页。 在全局区域调用 scha_control_zone() 函数。zonename 参数指定在其中配置资源组的区域群集的名称。
所指定的资源的 Failover_mode 属性设置可能会抑制所请求的 scha_control() 或 scha_control_zone() 操作。如果 Failover_mode 为 RESTART_ONLY，则只允许 SCHA_RESOURCE_RESTART。其他请求（包括 SCHA_GIVEOVER、SCHA_CHECK_GIVEOVER、SCHA_RESTART 和 SCHA_CHECK_RESTART）将返回 SCHA_ERR_CHECKS 退出代码，并且所请求的移交或重新启动操作不会执行，而只生成 syslog 消息。如果在资源上设置了 Retry_count 和 Retry_interval 属性，则资源重新启动次数限制为 Retry_interval 中的 Retry_count 尝试次数。如果 Failover_mode 为 LOG_ONLY，则任何 scha_control() 或 scha_control_zone() 移交、重新启动或禁用请求将返回 SCHA_ERR_CHECKS 退出代码，并且所请求的移交或重新启动操作不会执行，而只生成 syslog 消息。
tag 参数指明是请求重新启动还是重定位资源或资源组。该参数应当是一个字符串值，该值由 scha_tags.h 中定义的以下宏之一定义：
请求使 rname 参数指定的代理资源在本地节点上脱机。代理资源是一种 Oracle Solaris Cluster 资源，它可以从另一群集（例如 Oracle Clusterware）导入某个资源的状态。Oracle Clusterware 是一组适用于群集环境的不依赖于平台的系统服务。在 Oracle Solaris Cluster 软件的上下文中，这种状态变化反映了外部资源的状态变化。
当您使用该 tag 参数更改某个代理资源的状态时，不会执行该代理资源的方法。
如果节点上的“被依赖”资源发生故障，并且该资源无法恢复，则监视器将使该资源在该节点上脱机。监视器将会通过随 SCHA_RESOURCE_DISABLE 请求调用 scha_control() 或 scha_control_zone() 函数来使该资源脱机。监视器还会通过触发重新启动操作，使被依赖资源的所有 offline-restart 依赖项脱机。当群集管理员解决故障并重新启用被依赖资源时，监视器还会使被依赖资源的 offline-restart 依赖资源重新联机。
请求使 rname 参数指定的代理资源在本地节点上联机。代理资源是一种 Oracle Solaris Cluster 资源，它可以从另一群集（例如 Oracle Clusterware）导入某个资源的状态。在 Oracle Solaris Cluster 软件的上下文中，这种状态变化反映了外部资源的状态变化。
当您使用该 tag 参数更改某个代理资源的状态时，不会执行该代理资源的方法。
对 rgname 参数指定的资源组执行与 SCHA_GIVEOVER 相同的有效性检查，但不实际重定位该资源组。
对 rgname 参数指定的资源组执行与 SCHA_RESTART 请求相同的有效性检查，但不实际重新启动该资源组。
SCHA_CHECK_GIVEOVER 和 SCHA_CHECK_RESTART 请求用于供资源监视器直接对资源采取操作（例如，终止并重新启动进程），而不是通过调用 scha_control() 或 scha_control_zone() 函数来执行移交或重新启动。如果检查失败，监视器应该休眠，然后重新启动其探测器，而不是调用其故障转移操作。请参见 错误。
rgname 参数是要重新启动或重定位的资源组的名称。如果该组未在发出请求的节点上联机，则请求会被拒绝。
rname 参数是资源组中某个资源的名称。该资源很可能是其监视器正在发出 scha_control() 或 scha_control_zone() 请求的资源。如果指定的资源不在资源组中，则请求会被拒绝。
该命令的退出代码指示是否拒绝了所请求的操作。如果接受了请求，则在资源组或资源已完成脱机并已重新联机之前，该函数不会返回。调用 scha_control() 或 scha_control_zone() 函数的故障监视器可能会由于资源组脱机而停止，因此，可能永远无法收到成功的请求的返回状态。
请求使 rgname 参数指定的资源组在本地节点上脱机，然后再在 RGM 选择的其他节点上重新联机。请注意，如果该资源组当前已在两个或更多个节点上联机，并且没有其他可用节点可供该资源组在其上联机，则可使它在本地节点上脱机且无需再让它在其他位置联机。请求可能会被拒绝，具体取决于各项检查的结果。例如，如果组是由于在 Pingpong_interval 属性指定的时间间隔内某个节点上发出的 SCHA_GIVEOVER 请求而脱机，则可能会拒绝将该节点用作主机。
如果群集管理员配置了一个或多个资源组的 RG_affinities 属性，而您对一个资源组发出了 scha_control GIVEOVER 请求，那么，可能会重定位多个资源组。rg_properties(5) 中介绍了 RG_affinities 属性。
通过故障监视器调用 scha_control() 或 scha_control_zone() 函数或者发出 scha_control 或 scha_control_zone() 命令后，将包含该资源的资源组重定位到新节点之前，将会调用 MONITOR_CHECK 方法。请参见 scha_control(1HA) 手册页。
您可以在资源组潜在的任何新主节点上调用 MONITOR_CHECK 方法。MONITOR_CHECK 方法旨在评估某个节点的运行状况是否良好，足以运行某个资源。MONITOR_CHECK 方法必须以这样一种方式实现，即它不与同时运行的其他方法相冲突。
如果 MONITOR_CHECK 方法失败，则会禁止将资源组重定位到调用了回调的节点。
请求在当前执行的 Prenet_start 或 Start 方法失败时不对资源组进行故障转移，无论 Failover_mode 属性的设置如何。
换言之，该请求将覆盖当 Failover_Mode 属性设置为 SOFT 或 HARD 的资源无法启动时通常情况下会采取的恢复操作。通常，资源组会故障转移到另一个节点。而资源的行为却如同 Failover_Mode 设置为 NONE 一样。如果未发生其他错误，资源将进入 START_FAILED 状态，而资源组最终将进入 ONLINE_FAULTED 状态。
仅当通过 Start 或 Prenet_start 方法（该方法随后会退出并返回非零状态，或者超时）调用时，该请求才有意义。该请求仅对 Start 或 Prenet_start 方法的当前调用有效。在 Start 方法确定资源在其他节点上无法成功启动的情况下，应随该请求调用 scha_control() 或 scha_control_zone() 函数。如果由其他任何方法调用该请求，将返回错误 SCHA_ERR_INVAL。该请求可防止资源组发生不使用该请求时会发生的“弹跳”故障转移。有关 SCHA_ERR_INVAL 错误代码的描述，请参见 scha_calls(3HA) 手册页。
在调用 scha_control() 或 scha_control_zone() 函数的节点上禁用 rname 参数指定的资源。
如果节点上的“被依赖”资源发生故障，并且该资源无法恢复，则监视器将使该资源在该节点上脱机。监视器将会通过随 SCHA_RESOURCE_DISABLE 请求调用 scha_control() 或 scha_control_zone() 函数来使该资源脱机。监视器还会通过触发重新启动操作，使被依赖资源的所有 offline-restart 依赖项脱机。当群集管理员解决故障并重新启用被依赖资源时，监视器还会使被依赖资源的 offline-restart 依赖资源重新联机。
请求在本地节点上递增 rname 参数指定的资源的资源重新启动计数器，但不实际重新启动该资源。
没有在 SCHA_RESOURCE_RESTART 请求中调用 scha_control() 或 scha_control_zone() 函数而直接重新启动资源（例如，使用 pmfadm(1M) 命令）的资源监视器可以使用该请求来通知 RGM 该资源已重新启动。随后使用 NUM_RESOURCE_RESTARTS 查询调用 scha_resource_get() 函数时会反映该事实。
如果资源的类型无法声明 Retry_interval 标准属性，则不允许 scha_control() 或 scha_control_zone() 函数的 SCHA_RESOURCE_IS_RESTARTED 请求，并且 scha_control() 或 scha_control_zone() 函数将返回错误代码 13 (SCHA_ERR_RT)。
请求使 rname 参数指定的资源在本地节点上脱机然后重新联机，而无需停止该资源组中的任何其他资源。这将通过在本地节点上对该资源应用以下方法序列来使其停止后再启动：
MONITOR_STOP STOP START MONITOR_START
如果资源类型没有声明 STOP 和 START 方法，则会改用 POSTNET_STOP 和 PRENET_START 来重新启动该资源：
MONITOR_STOP POSTNET_STOP PRENET_START MONITOR_START
如果资源的类型没有声明 MONITOR_STOP 和 MONITOR_START 方法，则只会调用 STOP 和 START 方法或者 POSTNET_STOP 和 PRENET_START 方法来执行重新启动。资源的类型必须声明 START 和 STOP 方法。有关 SCHA_ERR_RT 错误代码的描述，请参见 scha_calls(3HA) 手册页。
如果重新启动资源时某个方法调用失败，RGM 可能会设置一个错误状态、重定位资源组，或者重新引导节点，具体取决于对该资源的 Failover_mode 属性的设置。有关其他信息，请参见 r_properties(5) 中的 Failover_mode 属性。
使用该请求重新启动资源的资源监视器可以使用 scha_resource_get () 的 NUM_RESOURCE_RESTARTS 查询来统计最近的重新启动尝试次数。
具有 PRENET_START 或 POSTNET_STOP 方法的资源类型需慎用 SCHA_RESOURCE_RESTART 请求。只会对此类资源应用 MONITOR_STOP、STOP、START 和 MONITOR_START 方法。该资源所依赖的网络地址资源不会重新启动，将保持联机状态。
如果节点上的“被依赖”资源发生故障，并且该资源无法恢复，则监视器将使该资源在该节点上脱机。监视器将会通过随 SCHA_RESOURCE_DISABLE 请求调用 scha_control() 或 scha_control_zone() 函数来使该资源脱机。监视器还会通过触发重新启动操作，使被依赖资源的所有 offline-restart 依赖项脱机。当群集管理员解决故障并重新启用被依赖资源时，监视器还会使被依赖资源的 offline-restart 依赖资源重新联机。
请求使 rgname 参数指定的资源组脱机，然后再联机，而无需强制重定位到其他节点。如果该资源组中的某个资源无法重新启动，该请求最终可能会导致重定位该组。使用该请求重新启动资源组的资源监视器可以使用 scha_resource_get 的 NUM_RG_RESTARTS() 查询来统计最近的重新启动尝试次数。
这些函数返回以下值：
该函数成功。
该函数失败。
该函数成功。
请求被拒绝。对重定位执行的检查失败。
有关其他错误代码的描述，请参见 scha_calls(3HA) 手册页。
通常，从 scha_control() 或 scha_control_zone() 函数接收到错误代码的故障监视器应休眠片刻，然后重新启动其探测器。这些函数必须这样做，因为经过片刻后，某些错误状态可以自行修复。这种错误状况的一个示例是某个全局设备服务发生了故障转移，导致磁盘资源暂时不可用。在错误状况修复后，资源本身的状况将恢复正常。否则，后续的 scha_control() 或 scha_control_zone() 请求可能会成功。
头文件
库
有关以下属性的描述，请参见 attributes(5)：
|
rt_callbacks(1HA)、scha_control(1HA)、pmfadm(1M)、scha_calls(3HA)、scha_resource_open(3HA)、scha_strerror(3HA)、attributes(5)、r_properties(5)、rg_properties(5)、rt_properties(5)