Language and Page Formatting Options
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
ccscluster configuration command. The
ccscommand allows an administrator to create, modify and view the
cluster.confcluster configuration file. You can use the
ccscommand to configure a cluster configuration file on a local file system or on a remote node. Using the
ccscommand, 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
ccscommand. For information on using the
ccscommand to manage a running cluster, see Chapter 7, Managing Red Hat High Availability Add-On With ccs.
This chapter consists of the following sections:
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.
This chapter references commonly used
cluster.confelements and attributes. For a comprehensive list and description of
cluster.confelements and attributes, see the cluster schema at
/usr/share/cluster/cluster.rng, and the annotated schema at
6.1. Operational Overview
This section describes the following general operational aspects of using the
ccscommand to configure a cluster:
6.1.1. Creating the Cluster Configuration File on a Local System
ccscommand, 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
ccscommand does not require root privilege.
When you create and edit a cluster configuration file on a cluster node with the
ccscommand, you use the
-hoption to specify the name of the host. This creates and edits the
/etc/cluster/cluster.conffile on the host:
ccs -h host [options]
To create and edit a cluster configuration file on a local system, use the
-foption of the
ccscommand to specify the name of the configuration file when you perform a cluster operation. You can name this file anything you want.
ccs -f file [options]
As of Red Hat Enterprise Linux 6.6, if you do not specify the
-fparameter of the
ccswill attempt to connect to the localhost. This is the equivalent of specifying
After you have created the file locally you can send it to a cluster node using the
--setconfoption of the
ccscommand. On a host machine in a cluster, the file you send will be named
cluster.confand it will be placed in the
ccs -h host -f file --setconf
For information on using the
--setconfoption of the
ccscommand, 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:
ccs -h host --getconf
If you are creating your cluster configuration file on a local system you can specify the
-foption instead of the
-hoption, 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
ccscommands that distribute copies of the
cluster.conffile 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
ccscommand requires it. Alternately, you can use the
-poption to specify a ricci password on the command line.
ccs -h host -p password --sync --activate
When you propagate the
cluster.conffile to all of the nodes in the cluster with the
--syncoption of the
ccscommand and you specify a ricci password for the command, the
ccscommand 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
--setconfoption with the
-poption to distribute the configuration file to one node at a time.
6.1.4. Modifying Cluster Configuration Components
You use the
ccscommand 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
cmancluster component provide an exception to this procedure for modifying cluster components. To modify these attributes, you execute the
--setcmanoption of the
ccscommand, 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 Previous Settings”.
6.1.5. Commands that Overwrite Previous Settings
There are several options of the
ccscommand that implement overwriting semantics when setting properties. This means that you can issue the
ccscommand with one of these options without specifying any settings, and it will reset all settings to their default values. These options are as follows:
For example, to reset all of the fence deamon properties, you can enter the following command.
ccs -h hostname --setfencedaemon
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_delayproperty to 5:
ccs -h hostname --setfencedaemon post_fail_delay=5
If, after running that command, you enter the following command to reset the
post_join_delayproperty to 10, the
post_fail_delayproperty will be restored to its default value:
ccs -h hostname --setfencedaemon post_join_delay=10
To reset both the
post_join_delayproperties, you indicate them both on the same command, as in the following example:
ccs -h hostname --setfencedaemon post_fail_delay=5 post_join_delay=10
For more information on configuring fence devices, see Section 6.5, “Configuring Fence Devices”.
6.1.6. Configuration Validation
When you use the
ccscommand 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
ccscommand validates the configuration according to the cluster schema at
/usr/share/cluster/cluster.rngon the node that you specify with the
-hoption. Previously the
ccscommand always used the cluster schema that was packaged with the
/usr/share/ccs/cluster.rngon the local system. When you use the
-foption to specify the local system, the
ccscommand still uses the cluster schema
/usr/share/ccs/cluster.rngthat was packaged with the
ccscommand itself on that system.