There are two final pieces of the puzzle that will produce a fully functional Pacemaker cluster. At this point, we have three independent base-level entries in Pacemaker: DRBD, the PGServer group, and the e-mail alert. They are independent because Pacemaker may start or stop them on any server in the list of active nodes.
We can fix this by defining a colocation between related resources. When we create a colocation, we are effectively stating that wherever this service goes, this other service should follow. Of course, this by itself is not sufficient. We also need to declare the expected order necessary for the services to start.
In this recipe, we'll finish our Pacemaker setup by creating necessary colocation entries, and define a service start order.
As we're continuing to configure Pacemaker, make sure that you've followed all the previous recipes.
Perform these steps on any Pacemaker node as the root user:
- Add a
colocationfor DRBD to Pacemaker withcrm:crm configure colocation col_pg_drbd inf: PGServer ms_drbd_pg:Master
- Add a
colocationfor the e-mail alert withcrm:crm configure colocation col_pg_mail inf: pg_mail PGServer
- Add a resource
orderto Pacemaker withcrm:crm configure order ord_pg inf: ms_drbd_pg:promote PGServer:start
- Display the status of our new group with
crm:crm resource status
As with all of our changes to Pacemaker, we configure the item we're adding. For this first step, we are adding a colocation named col_pg_drbd to represent the dependency between the PGServer group and the ms_drbd_pg master/slave resource. To do this, we need three elements. They are as follows:
- The strength of the relationship, as expressed as a score: We used
inf:to represent infinity, meaning that these two items should always be associated - The name of the resource we are trying to colocate: We use the group name
PGServer, as we want all Pacemaker resources to follow it to the same node - The name of a resource this entry should be colocated with, and is dependent upon: By setting this to
ms_drbd_pg:Master, we are telling Pacemaker that thePGServergroup must be on the same server where DRBD is the master node, wherever that might be
We then repeat this process with the e-mail alert. This time, we name the colocation col_pg_mail to express it as a colocation of the pg_mail resource. The score remains at inf: for infinity, and we made one final and very important change. When defining a colocation, the order is extremely important. In fact, all colocation entries should be read as: resource a depends on resource b.
With the e-mail alert colocation, we now have what amounts to a dependency chain. The e-mail alert depends on the state of the PGServer group, and the PGServer group depends on the DRBD master server. Yet, colocations are rules, so Pacemaker is still free to execute these resources independently of each other, as long as the final result matches the defined state we dictated.
As colocations have no inherent order, we need to impose one. We create one final configure entry by defining an order named ord_pg. Once again, we need to provide a score, and once again, we use inf: for infinity; the order of services is very important to us. When we define the order of our resources, we can also dictate an action that Pacemaker should take, as separated by a colon.
The order we defined tells Pacemaker that it should promote the ms_drbd_pg resource before it is allowed to start the PGServer group. Why didn't we add the e-mail alert to our order definition? Because its order doesn't matter. By being a colocation, it is associated with the PGServer group, but since it has no imposed order, any change to the group or to DRBD will trigger an e-mail alert.
One crm command we haven't used until now is configure show. Colocation and order definitions don't alter the outward appearance of resource status, so we needed another way to prove Pacemaker incorporated our changes. This is what we see on our test system:
Notice that we ran this command on the pg2 server, and we were still shown the current Pacemaker configuration. Pacemaker also takes it upon itself to remove all of our formatting for these particular entries. If we were to remove the egrep statement, we'd see the entire Pacemaker configuration for our cluster, containing all of the additions we've made in this chapter.