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:
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:
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:
ccs -h host [options]
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.
ccs -f file [options]
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.
ccs -h host -f file --setconf
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:
ccs -h host --getconf
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.
ccs -h host -p password --sync --activate
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 Previous Settings”.
6.1.5. Commands that Overwrite Previous 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.
# 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_delay
property 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_delay
property to 10, the post_fail_delay
property will be restored to its default value:
# ccs -h hostname --setfencedaemon post_join_delay=10
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:
# 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
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.