HP XC System Software Administration Guide Version 3.1

The cconfigure scripts are executed inside the cluster_config utility as follows:
script_path cconfigure client server1 server2 ...
script_path cunconfigure client server1 server2 ...
The client is the node name on which the script is running. The servers are the nodes providing this service
to this client. Typically, this is a single server. The cconfigure action is performed only on nodes that
are clients of the service. The cconfigure scripts return 0 (zero) on success and return a nonzero value
on failure. Any failure causes the node to be put into single-user mode so that the error can be investigated.
The cconfigure scripts cannot have a user interface.
The cunconfigure action is not performed automatically, but it should be available to be performed
manually.
4.6.6 Understanding Global Configuration Scripts
Imagine a role containing two or more services. With the present roles interface, every node for which this
role is specified is selected as a potential server for these services. Imagine further that 10 nodes are assigned
with this role. This potentially assigns these services to these 10 nodes. Eventually, these 10 nodes are
passed as potential servers to the gconfig scripts for these services.
This results in two or more gconfig scripts receiving the same 10 nodes on which to schedule services.
The instruction to each gconfig script is to use all of the servers it is passed, if possible.
Two or more services might not have compatible or consistent uses for the same set of 10 server nodes
passed into them. Also, each service might benefit from optimizing its service assignments relative to the
other services on the same set of nodes; however, there are no mechanisms to achieve this.
Another possible behavior of the system that you might want is that each gconfig script could identify
that it needs only 5 of the 10 servers to satisfy optimal scale out requirements, and these scripts could
choose that each use a disjoint 5 of 10 servers passed in order to spread the load. At present, for services
that are part of the same role, there are no mechanisms in place to achieve this.
4.6.7 Advance Planning
You use the cluster_config utility to assigns roles, and hence, services, to nodes. To add a new service
to the roles model, perform one of the following:
• Add a new service to an existing role or roles.
• Add a new role or roles for the new service, and add the new service into the new role or roles.
Ask yourself the following questions when you are adding a customized service to your HP XC system:
• Is this a service or a policy?
• Does the service have specific servers?
• Does the service have specific clients?
• Does the service have specific daemons?
• Where do configuration steps need to occur?
If you have a systemwide policy or behavior, an sconfigure script may be all you need. Any changes
made in sconfigure scripts become part of the golden image.
Typically, if the service needs to run on specific servers and clients, you perform these tasks:
1. Edit the roles_services.ini file to include the new service or service name and roles or both as
appropriate. See “Editing the roles_services.ini File” for more information about editing this file.
2. Create a service_name.ini file to provide service configuration details to the cluster_config
utility. See “Creating a service.ini File” (page 68) for more information about the contents of this file.
3. Write a gconfigure script for any service configuration that is part of the golden image.
4. Write a nconfigure script for any service configuration that varies by server.
5. Write a cconfigure script for any service configuration that varies by client.
In general, your customized service configuration might require gconfigure, nconfigure, and
cconfigure scripts for any new service, but you only have to provide the scripts actually needed to
perform the configuration. For example, many services need no special client configuration and do not
require a cconfigure script.
Writing gconfigure Scripts 67