Chapter 6. Configuring Red Hat High Availability Add-On With the ccs Command
Chapter 6. Configuring Red Hat High Availability Add-On With the ccs Command As of the Red Hat Enterprise Linux 6.1 release and later, the Red Hat High Availability Add-On provides support for the ccs cluster configuration command. The ccs command allows an administrator to create, modify and view the cluster.conf cluster configuration file. You can use the ccs command to configure a cluster configuration file on a local file system or on a remote node. Using the ccs command, an administrator can also start and stop the cluster services on one or all of the nodes in a configured cluster. This chapter describes how to configure the Red Hat High Availability Add-On cluster configuration file using the ccs command. For information on using the ccs command to manage a running cluster, see Chapter 7, Managing Red Hat High Availability Add-On With ccs . This chapter consists of the following sections: Section 6.1, "Operational Overview" Section 6.2, "Configuration Tasks" Section 6.3, "Starting ricci " Section 6.4, "Creating and Modifying a Cluster" Section 6.5, "Configuring Fence Devices" Section 6.7, "Configuring Fencing for Cluster Members" Section 6.8, "Configuring a Failover Domain" Section 6.9, "Configuring Global Cluster Resources" Section 6.10, "Adding a Cluster Service to the Cluster" Section 6.13, "Configuring a Quorum Disk" Section 6.14, "Miscellaneous Cluster Configuration" Section 6.14, "Miscellaneous Cluster Configuration" Section 6.15, "Propagating the Configuration File to the Cluster Nodes" Note Make sure that your deployment of High Availability Add-On meets your needs and can be supported. Consult with an authorized Red Hat representative to verify your configuration prior to deployment. In addition, allow time for a configuration burn-in period to test failure modes. Note This chapter references commonly used cluster.conf elements and attributes. For a comprehensive list and description of cluster.conf elements and attributes, see the cluster schema at /usr/share/cluster/cluster.rng , and the annotated schema at /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (for example /usr/share/doc/cman-3.0.12/cluster_conf.html ). 6.1. Operational Overview This section describes the following general operational aspects of using the ccs command to configure a cluster: Section 6.1.1, "Creating the Cluster Configuration File on a Local System" Section 6.1.2, "Viewing the Current Cluster Configuration" Section 6.1.3, "Specifying ricci Passwords with the ccs Command" Section 6.1.4, "Modifying Cluster Configuration Components" 6.1.1. Creating the Cluster Configuration File on a Local System Using the ccs command, you can create a cluster configuration file on a cluster node, or you can create a cluster configuration file on a local file system and then send that file to a host in a cluster. This allows you to work on a file from a local machine, where you can maintain it under version control or otherwise tag the file according to your needs. Using the ccs command does not require root privilege. When you create and edit a cluster configuration file on a cluster node with the ccs command, you use the -h option to specify the name of the host. This creates and edits the /etc/cluster/cluster.conf file on the host: To create and edit a cluster configuration file on a local system, use the -f option of the ccs command to specify the name of the configuration file when you perform a cluster operation. You can name this file anything you want. As of Red Hat Enterprise Linux 6.6, if you do not specify the -h or the -f parameter of the ccs command, the ccs will attempt to connect to the localhost. This is the equivalent of specifying -h localhost . After you have created the file locally you can send it to a cluster node using the --setconf option of the ccs command. On a host machine in a cluster, the file you send will be named cluster.conf and it will be placed in the /etc/cluster directory. For information on using the --setconf option of the ccs command, see Section 6.15, "Propagating the Configuration File to the Cluster Nodes" . 6.1.2. Viewing the Current Cluster Configuration If at any time during the creation of a cluster configuration file you want to print the current file, use the following command, specifying a node in the cluster as the host: If you are creating your cluster configuration file on a local system you can specify the -f option instead of the -h option, as described in Section 6.1.1, "Creating the Cluster Configuration File on a Local System" . 6.1.3. Specifying ricci Passwords with the ccs Command Executing ccs commands that distribute copies of the cluster.conf file to the nodes of a cluster requires that ricci be installed and running on the cluster nodes, as described in Section 3.13, "Considerations for ricci " . Using ricci requires a password the first time you interact with ricci from any specific machine. If you have not entered a password for an instance of ricci on a particular machine from the machine you are using, you will be prompted for that password when the ccs command requires it. Alternately, you can use the -p option to specify a ricci password on the command line. When you propagate the cluster.conf file to all of the nodes in the cluster with the --sync option of the ccs command and you specify a ricci password for the command, the ccs command will use that password for each node in the cluster. If you need to set different passwords for ricci on individual nodes, you can use the --setconf option with the -p option to distribute the configuration file to one node at a time. 6.1.4. Modifying Cluster Configuration Components You use the ccs command to configure cluster components and their attributes in the cluster configuration file. After you have added a cluster component to the file, in order to modify the attributes of that component you must remove the component you have defined and add the component again, with the modified attributes. Information on how to do this with each component is provided in the individual sections of this chapter. The attributes of the cman cluster component provide an exception to this procedure for modifying cluster components. To modify these attributes, you execute the --setcman option of the ccs command, specifying the new attributes. Note that specifying this option resets all values that you do not explicitly specify to their default values, as described in Section 6.1.5, "Commands that Overwrite Settings" . 6.1.5. Commands that Overwrite Settings There are several options of the ccs command that implement overwriting semantics when setting properties. This means that you can issue the ccs command with one of these options without specifying any settings, and it will reset all settings to their default values. These options are as follows: --settotem --setdlm --setrm --setcman --setmulticast --setaltmulticast --setfencedaemon --setlogging --setquorumd For example, to reset all of the fence deamon properties, you can enter the following command. Note, however, that if you use one of these commands to reset a property, then the other properties of the command will be reset to their default values. For example, you can use the following command to set the post_fail_delay property to 5: If, after running that command, you enter the following command to reset the post_join_delay property to 10, the post_fail_delay property will be restored to its default value: To reset both the post_fail_delay and the post_join_delay properties, you indicate them both on the same command, as in the following example: For more information on configuring fence devices, see Section 6.5, "Configuring Fence Devices" . 6.1.6. Configuration Validation When you use the ccs command to create and edit the cluster configuration file, the configuration is automatically validated according to the cluster schema. As of the Red Hat Enterprise Linux 6.3 release, the ccs command validates the configuration according to the cluster schema at /usr/share/cluster/cluster.rng on the node that you specify with the -h option. Previously the ccs command always used the cluster schema that was packaged with the ccs command itself, /usr/share/ccs/cluster.rng on the local system. When you use the -f option to specify the local system, the ccs command still uses the cluster schema /usr/share/ccs/cluster.rng that was packaged with the ccs command itself on that system.
ccs -h host [ options ] ccs -f file [ options ] ccs -h host -f file --setconf ccs -h host --getconf ccs -h host -p password --sync --activate ccs -h hostname --setfencedaemon ccs -h hostname --setfencedaemon post_fail_delay=5 ccs -h hostname --setfencedaemon post_join_delay=10 ccs -h hostname --setfencedaemon post_fail_delay=5 post_join_delay=10