이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Appendix E. Cluster Service Resource Check and Failover Timeout


This appendix describes how rgmanager monitors the status of cluster resources, and how to modify the status check interval. The appendix also describes the __enforce_timeouts service parameter, which indicates that a timeout for an operation should cause a service to fail.

Note

To fully comprehend the information in this appendix, you may require detailed understanding of resource agents and the cluster configuration file, /etc/cluster/cluster.conf. For a comprehensive list and description of cluster.conf elements and attributes, refer to the cluster schema at /usr/share/system-config-cluster/misc/cluster.ng, and the annotated schema at /usr/share/doc/system-config-cluster-X.Y.ZZ/cluster_conf.html (for example /usr/share/doc/system-config-cluster-1.0.57/cluster_conf.html).

E.1. Modifying the Resource Status Check Interval

rgmanager checks the status of individual resources, not whole services. (This is a change from clumanager on Red Hat Enterprise Linux 3, which periodically checked the status of the whole service.) Every 10 seconds, rgmanager scans the resource tree, looking for resources that have passed their "status check" interval.
Each resource agent specifies the amount of time between periodic status checks. Each resource utilizes these timeout values unless explicitly overridden in the cluster.conf file using the special <action> tag:
<action name="status" depth="*" interval="10" />
This tag is a special child of the resource itself in the cluster.conf file. For example, if you had a file system resource for which you wanted to override the status check interval you could specify the file system resource in the cluster.conf file as follows:

  <fs name="test" device="/dev/sdb3">
    <action name="status" depth="*" interval="10" />
    <nfsexport...>
    </nfsexport>
  </fs>
Some agents provide multiple "depths" of checking. For example, a normal file system status check (depth 0) checks whether the file system is mounted in the correct place. A more intensive check is depth 10, which checks whether you can read a file from the file system. A status check of depth 20 checks whether you can write to the file system. In the example given here, the depth is set to *, which indicates that these values should be used for all depths. The result is that the test file system is checked at the highest-defined depth provided by the resource-agent (in this case, 20) every 10 seconds.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.