If it is not possible to reserve shared storage for use as a CCA device, you can use two alternative methods:
Neither of these methods requires shared storage to store CCS data.
The first alternative to a CCA device is to use a single network server to serve CCS configuration files to all nodes in the cluster. If used, this CCS server is a single point of failure in a cluster. If a single (non-redundant) LOCK_GULM server daemon is being used, it would be reasonable to run a CCS server on the same node as the LOCK_GULM server. The CCS server does not have failover capabilities.
The CCS server is called ccs_servd, it can be run on any node in or out of the cluster. When CCS daemons (ccsd) are started on cluster nodes, the IP address of the node running ccs_servd is specified instead of the name of the CCA device. The name of the cluster is also passed to ccsd.
The CCS server does not read CCS files directly; rather, it reads a CCA file that is a local file containing a CCS archive.
Steps related to CCS in the setup procedure must be modified to use a CCS server in place of a CCA device.
Note | |
---|---|
ccs_servd provides information to any computer that can connect to it. Therefore, ccs_servd should not be used at sites where untrusted nodes can contact the CCS server. |
Like a CCA device, a CCA file is created by the ccs_tool command from a directory of CCS configuration files. Instead of specifying a CCA device as the last parameter when creating an archive, a local file name is specified. The ccs_tool command creates the named file, which is the CCA file. That file should be named ClusterName with a .cca extension. (ClusterName is the user-supplied variable that specifies the name of the cluster.) The CCA file must be located on the node that runs ccs_servd.
ccs_tool create Directory CCAFile |
The relative path to the directory containing the CCS files for the cluster.
Specifies the CCA file to create.
In this example, the name of the cluster is alpha and the name of the CCA file is alpha.cca. The CCA file is saved in the /etc/sistina/ccs-build/ directory, which is the default location where ccs_servd looks for CCA files.
ccs_tool create /root/alpha/ /etc/sistina/ccs-build/alpha.cca |
There are two parts to starting CCS in the cluster when using a CCS server. The first is starting ccs_servd and the second is starting ccsd on all the cluster nodes. When starting ccs_servd, no command line options are required unless the CCA file is saved in a location other than /etc/sistina/ccs-build/.
This example shows starting the CCS server normally; that is, using the default location for CCA files.
ccs_servd |
This example shows starting the CCS server using a user-defined location for CCA files. In this case, CCA files are saved in /root/cca/.
ccs_servd -p /root/cca/ |
When using a CCS server, ccsd must connect to it over the network, and requires two parameters on the ccsd command line: the IP address (and optional port number) of the node running ccs_servd, and the name of the cluster.
ccsd -s IPAddress[:PortNumber] -c ClusterName |
The IP address of the node running the CCS server.
(Optional) The non-default port number. A colon and port number can optionally follow the IPAddress to specify a non-default port number: IPAddress:PortNumber.
Specifies the name of the cluster. The CCS server uses this to pick the correct CCA file that is named for the cluster.
This example starts ccsd on a node for cluster alpha when using a CCS server with the IP address shown.
ccsd -s 10.0.5.1 -c alpha |
An alternative to both a CCA device and a CCS server is to replicate CCA files on all cluster nodes.
Note | |
---|---|
Care must be taken to keep all the copies identical. |
A CCA file is created using the same steps as for a CCS server. The CCA file is manually copied to all cluster nodes.
When the CCS daemon is started on each node, it must be given the location of the local copy of the CCA file.
This example starts ccsd on a node using a local copy of a CCA file.
ccsd -f /etc/sistina/ccs-build/alpha.cca |