Procedure 13.1. Configuring Ticket Dependencies¶

The crm configure rsc_ticket command lets you specify the resources depending on a certain ticket. Together with the constraint, you can set a loss-policy that defines what should happen to the respective resources if the ticket is revoked. The attribute loss-policy can have the following values:

1. On one of the cluster nodes, start a shell and log in as root or equivalent.

2. Enter crm configure to switch to the interactive shell.

3. Configure a constraint that defines which resources depend on a certain ticket. For example:

   crm(live)configure#
   rsc_ticket rsc1-req-ticketA ticketA: rsc1 loss-policy="fence"

   This creates a constraint with the ID rsc1-req-ticketA. It defines that the resource rsc1 depends on ticketA and that the node running the resource should be fenced in case ticketA is revoked.

   If resource rsc1 was not a primitive, but a special clone resource that can run in master or slave mode, you may want to configure that only rsc1's master mode depends on ticketA. With the following configuration, rsc1 is automatically demoted to slave mode if ticketA is revoked:

   crm(live)configure#
   rsc_ticket rsc1-req-ticketA ticketA: rsc1:Master loss-policy="demote"

4. If you want other resources to depend on further tickets, create as many constraints as necessary with rsc_ticket.

5. Review your changes with show.

6. If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

   The constraints are saved to the CIB.

Procedure 13.2. Configuring a Resource Group for boothd¶

Each site needs to run one instance of boothd that communicates with the other booth daemons. The daemon can be started on any node, therefore it should be configured as primitive resource. To make the boothd resource stay on the same node, if possible, add resource stickiness to the configuration. As each daemon needs a persistent IP address, configure another primitive with a virtual IP address. Group booth primitives:

1. On one of the cluster nodes, start a shell and log in as root or equivalent.

2. Enter crm configure to switch to the interactive shell.

3. To create both primitive resources and to add them to one group, g-booth:

   crm(live)configure#
   primitive booth-ip ocf:heartbeat:IPaddr2 params ip="IP_ADDRESS"
   primitive booth ocf:pacemaker:booth-site \
         meta resource-stickiness="INFINITY" \
         op monitor interval="10s" timeout="20s"
   group g-booth booth-ip booth

4. Review your changes with show.

5. If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

6. Repeat the resource group configuration on the other cluster sites, using a different IP address for each boothd resource group.

   With this configuration, each booth daemon will be available at its individual IP address, independent of the node the daemon is running on.

Procedure 13.3. Adding an Ordering Constraint¶

If a ticket has been granted to a site but all nodes of that site should fail to host the boothd resource group for any reason, a “split-brain” situation among the geographically dispersed sites could occur. In that case, no boothd instance would be available to safely manage fail-over of the ticket to another site. To avoid a potential concurrency violation of the ticket (the ticket is granted to multiple sites simultaneously), add an ordering constraint:

1. On one of the cluster nodes, start a shell and log in as root or equivalent.

2. Enter crm configure to switch to the interactive shell.

3. Create an ordering constraint:

   crm(live)configure#
   order order-booth-rsc1 inf: g-booth rsc1

   This defines that rsc1 (that depends on ticketA) can only be started after the g-booth resource group.

   In case rsc1 is not a primitive, but a special clone resource and configured as described in Step 3, the ordering constraint should be configured as follows:

   crm(live)configure#
   order order-booth-rsc1 inf: g-booth rsc1:promote

   This defines that rsc1 can only be promoted to master mode after the g-booth resource group has started.

4. Review your changes with show.

5. For any other resources that depend on a certain ticket, define further ordering constraints.

6. If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

Procedure 13.4. Editing The Booth Configuration File¶

1. Log in to a cluster node as root or equivalent.

2. Create /etc/booth/booth.conf and edit it according to the example below:

   Example 13.1. Example Booth Configuration File

   transport="UDP" 
   port="6666" 
   arbitrator="147.2.207.14" 
   site="147.4.215.19" 
   site="147.18.2.1"  
   ticket="ticketA;1000"
   ticket="ticketB;1000"     

   	Defines the transport protocol used for communication between the sites. For SP2, only UDP is supported, other transport layers will follow.
   	Defines the port used for communication between the sites. Choose any port that is not already used for different services. Make sure to open the port in the nodes' and arbitrators' firewalls.
   	Defines the IP address of the arbitrator. Insert an entry for each arbitrator you use in your setup.
   	Defines the IP address used for the boothd on each site. Make sure to insert the correct virtual IP addresses (IPaddr2) for each site, otherwise the booth mechanism will not work correctly.
   	Defines the ticket to be managed by the booth. For each ticket, add a ticket entry.
   	Optional parameter. Defines the ticket's expiry time in seconds. A site that has been granted a ticket will renew the ticket regularly. If the booth does not receive any information about renewal of the ticket within the defined expiry time, the ticket will be revoked and granted to another site. If no expiry time is specified, the ticket will expire after 600 seconds by default.

   
   

   An example booth configuration file is available at /etc/booth/booth.conf.example.

3. Verify your changes and save the file.

4. Copy /etc/booth/booth.conf to all sites and arbitrators. In case of any changes, make sure to update the file accordingly on all parties.

   	Synchronize Booth Configuration to All Sites and Arbitrators
   All cluster nodes and arbitrators within the multi-site cluster must use the same booth configuration. While you may need to copy the files manually to the arbitrators and to one cluster node per site, you can use Csync2 within each cluster site to synchronize the file to all nodes.

Procedure 13.5. Starting the Booth Services¶

1. Start the booth resource group on each other cluster site. It will start one instance of the booth service per site.

2. Log in to each arbitrator and start the booth service:

   /etc/init.d/booth-arbitrator start

   This starts the booth service in arbitrator mode. It can communicate with all other booth daemons but in contrast to the booth daemons running on the cluster sites, it cannot be granted a ticket.