Debug Size:

- RSF-1 Configuration File Explained

In the example configuration file on the previous page, there are three main sections:

  1. Header with global variables
  2. The "Machines" section defining which nodes form the cluster and how heartbeats are configured
  3. The "Services" section which details the services that are managed by the cluster
The areas highlighted in are those, which should be amended for your environment.

Other variables and settings can also be modified but they are beyond the scope of this Quick Start guide.

The defaults given here are sufficient for general evaluation configuration and testing. Further information is available in the RSF-1 Administrator's Guide.

The first section contains some global variable settings:
The second section details the cluster nodes and heartbeats: For each node, the corresponding lines detail the heartbeat configurations with each other node in the cluster.
NOTE - For disk heartbeats, the offset ":518:512" component is reversed on the other node to ":512:518" – these numbers detail the "read" and "write" disk blocks respectively, so the first node
The final section details the services to be managed by RSF-1:
In this case, we have defined two services: POOLA and POOLB. The syntax of the SERVICE line is as follows:
SERVICE <service-name> <VIP-address> / <netmask> "<Description>"
For the POOLA service, we have defined the VIP address resolving to sales_staff-public with a netmask of 255.255.255.0. The VIP will be plumbed into the IPDEVICE interface (in this case bge0) as a secondary IP addressing mechanism (alongside any IP address already defined on bge0).

We have also specified the two ZFS pools A and C with their respective mount points are to be part of this service.

For the POOLB service, the associated VIP is support_staff-public with a netmask of 255.255.255.0 and ZFS pool B.

Each service has two timeouts associated: INITIMEOUT and RUNTIMEOUT. If the service has not been running on any cluster node, INITIMEOUT must countdown before the service will be started if other cluster nodes are not contactable. If the service has been running elsewhere, then RUNTIMEOUT must countdown before the service will be restarted.
NOTE - the ordering of the "SERVER" section at the end of each SERVICE section is important, as the first node in the list is the preferred node to start that service. If all services have the same SERVER order, all services will start on that preferred node. In this example, we want romulus to be the preferred starting node for the POOLA service and remus for POOLB
Prev Page
Next Page