7. Add Apache HTTP Server as a Cluster Service

Now that we have a basic but functional active/passive two-node cluster, we’re ready to add some real services. We’re going to start with Apache HTTP Server because it is a feature of many clusters and is relatively simple to configure.

7.1. Install Apache

Before continuing, we need to make sure Apache is installed on both hosts. We will also allow the cluster to use the wget tool (this is the default, but curl is also supported) to check the status of the Apache server. We’ll install httpd (Apache) and wget now.

# dnf install -y httpd wget
# firewall-cmd --permanent --add-service=http
# firewall-cmd --reload

Important

Do not enable the httpd service. Services that are intended to be managed via the cluster software should never be managed by the OS. It is often useful, however, to manually start the service, verify that it works, then stop it again, before adding it to the cluster. This allows you to resolve any non-cluster-related problems before continuing. Since this is a simple example, we’ll skip that step here.

7.2. Create Website Documents

We need to create a page for Apache to serve. On AlmaLinux 9, the default Apache document root is /var/www/html, so we’ll create an index file there. For the moment, we will simplify things by serving a static site and manually synchronizing the data between the two nodes, so run this command on both nodes:

# cat <<-END >/var/www/html/index.html
 <html>
 <body>My Test Site - $(hostname)</body>
 </html>
END

7.3. Enable the Apache Status URL

Pacemaker uses the apache resource agent to monitor the health of your Apache instance via the server-status URL, and to recover the instance if it fails. On both nodes, configure this URL as follows:

# cat <<-END >/etc/httpd/conf.d/status.conf
 <Location /server-status>
    SetHandler server-status
    Require local
 </Location>
END

Note

If you are using a different operating system, server-status may already be enabled or may be configurable in a different location. If you are using a version of Apache HTTP Server less than 2.4, the syntax will be different.

7.4. Configure the Cluster

At this point, Apache is ready to go, and all that needs to be done is to add it to the cluster. Let’s call the resource WebSite. We need to use an OCF resource agent called apache in the heartbeat namespace [1]. The script’s only required parameter is the path to the main Apache configuration file, and we’ll tell the cluster to check once a minute that Apache is still running.

[root@pcmk-1 ~]# pcs resource create WebSite ocf:heartbeat:apache  \
      configfile=/etc/httpd/conf/httpd.conf \
      statusurl="http://localhost/server-status" \
      op monitor interval=1min

By default, the operation timeout for all resources’ start, stop, monitor, and other operations is 20 seconds. In many cases, this timeout period is less than a particular resource’s advised timeout period. For the purposes of this tutorial, we will adjust the global operation timeout default to 240 seconds.

[root@pcmk-1 ~]# pcs resource op defaults
No defaults set
[root@pcmk-1 ~]# pcs resource op defaults update timeout=240s
Warning: Defaults do not apply to resources which override them with their own defined values
[root@pcmk-1 ~]# pcs resource op defaults
Meta Attrs: op_defaults-meta_attributes
timeout: 240s

Note

In a production cluster, it is usually better to adjust each resource’s start, stop, and monitor timeouts to values that are appropriate for the behavior observed in your environment, rather than adjusting the global default.

Note

If you use a tool like pcs to create a resource, its operations may be automatically configured with explicit timeout values that override the Pacemaker built-in default value of 20 seconds. If the resource agent’s metadata contains suggested values for the operation timeouts in a particular format, pcs reads those values and adds them to the configuration at resource creation time.

After a short delay, we should see the cluster start Apache.

[root@pcmk-1 ~]# pcs status
Cluster name: mycluster
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk-1 (version 2.1.2-4.el9-ada5c3b36e2) - partition with quorum
  * Last updated: Wed Jul 27 00:47:44 2022
  * Last change:  Wed Jul 27 00:47:23 2022 by root via cibadmin on pcmk-1
  * 2 nodes configured
  * 3 resource instances configured

Node List:
  * Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:
  * fence_dev       (stonith:some_fence_agent):      Started pcmk-1
  * ClusterIP       (ocf:heartbeat:IPaddr2):         Started pcmk-1
  * WebSite (ocf:heartbeat:apache):  Started pcmk-2

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Wait a moment, the WebSite resource isn’t running on the same host as our IP address!

Note

If, in the pcs status output, you see the WebSite resource has failed to start, then you’ve likely not enabled the status URL correctly. You can check whether this is the problem by running:

wget -O - http://localhost/server-status

If you see Not Found or Forbidden in the output, then this is likely the problem. Ensure that the <Location /server-status> block is correct.

7.5. Ensure Resources Run on the Same Host

To reduce the load on any one machine, Pacemaker will generally try to spread the configured resources across the cluster nodes. However, we can tell the cluster that two resources are related and need to run on the same host (or else one of them should not run at all, if they cannot run on the same node). Here, we instruct the cluster that WebSite can only run on the host where ClusterIP is active.

To achieve this, we use a colocation constraint that indicates it is mandatory for WebSite to run on the same node as ClusterIP. The “mandatory” part of the colocation constraint is indicated by using a score of INFINITY. The INFINITY score also means that if ClusterIP is not active anywhere, WebSite will not be permitted to run.

Note

If ClusterIP is not active anywhere, WebSite will not be permitted to run anywhere.

Note

INFINITY is the default score for a colocation constraint. If you don’t specify a score, INFINITY will be used automatically.

Important

Colocation constraints are “directional”, in that they imply certain things about the order in which the two resources will have a location chosen. In this case, we’re saying that WebSite needs to be placed on the same machine as ClusterIP, which implies that the cluster must know the location of ClusterIP before choosing a location for WebSite

[root@pcmk-1 ~]# pcs constraint colocation add WebSite with ClusterIP INFINITY
[root@pcmk-1 ~]# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  WebSite with ClusterIP (score:INFINITY)
Ticket Constraints:
[root@pcmk-1 ~]# pcs status
Cluster name: mycluster
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk-1 (version 2.1.2-4.el9-ada5c3b36e2) - partition with quorum
  * Last updated: Wed Jul 27 00:49:33 2022
  * Last change:  Wed Jul 27 00:49:16 2022 by root via cibadmin on pcmk-1
  * 2 nodes configured
  * 3 resource instances configured

Node List:
  * Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:
  * fence_dev       (stonith:some_fence_agent):      Started pcmk-1
  * ClusterIP       (ocf:heartbeat:IPaddr2):         Started pcmk-1
  * WebSite (ocf:heartbeat:apache):  Started pcmk-1

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

7.6. Ensure Resources Start and Stop in Order

Like many services, Apache can be configured to bind to specific IP addresses on a host or to the wildcard IP address. If Apache binds to the wildcard, it doesn’t matter whether an IP address is added before or after Apache starts; Apache will respond on that IP just the same. However, if Apache binds only to certain IP address(es), the order matters: If the address is added after Apache starts, Apache won’t respond on that address.

To be sure our WebSite responds regardless of Apache’s address configuration, we need to make sure ClusterIP not only runs on the same node, but also starts before WebSite. A colocation constraint ensures only that the resources run together; it doesn’t affect order in which the resources are started or stopped.

We do this by adding an ordering constraint. By default, all order constraints are mandatory. This means, for example, that if ClusterIP needs to stop, then WebSite must stop first (or already be stopped); and if WebSite needs to start, then ClusterIP must start first (or already be started). This also implies that the recovery of ClusterIP will trigger the recovery of WebSite, causing it to be restarted.

[root@pcmk-1 ~]# pcs constraint order ClusterIP then WebSite
Adding ClusterIP WebSite (kind: Mandatory) (Options: first-action=start then-action=start)
[root@pcmk-1 ~]# pcs constraint
Location Constraints:
Ordering Constraints:
  start ClusterIP then start WebSite (kind:Mandatory)
Colocation Constraints:
  WebSite with ClusterIP (score:INFINITY)
Ticket Constraints:

Note

The default action in an order constraint is start If you don’t specify an action, as in the example above, pcs automatically uses the start action.

Note

We could have placed the ClusterIP and WebSite resources into a resource group instead of configuring constraints. A resource group is a compact and intuitive way to organize a set of resources into a chain of colocation and ordering constraints. We will omit that in this guide; see the Pacemaker Explained document for more details.

7.7. Prefer One Node Over Another

Pacemaker does not rely on any sort of hardware symmetry between nodes, so it may well be that one machine is more powerful than the other.

In such cases, you may want to host the resources on the more powerful node when it is available, to have the best performance – or you may want to host the resources on the less powerful node when it’s available, so you don’t have to worry about whether you can handle the load after a failover.

To do this, we create a location constraint.

In the location constraint below, we are saying the WebSite resource prefers the node pcmk-2 with a score of 50. Here, the score indicates how strongly we’d like the resource to run at this location.

[root@pcmk-1 ~]# pcs constraint location WebSite prefers pcmk-2=50
[root@pcmk-1 ~]# pcs constraint
Location Constraints:
  Resource: WebSite
    Enabled on:
      Node: pcmk-2 (score:50)
Ordering Constraints:
  start ClusterIP then start WebSite (kind:Mandatory)
Colocation Constraints:
  WebSite with ClusterIP (score:INFINITY)
Ticket Constraints:
[root@pcmk-1 ~]# pcs status
Cluster name: mycluster
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk-1 (version 2.1.2-4.el9-ada5c3b36e2) - partition with quorum
  * Last updated: Wed Jul 27 00:51:13 2022
  * Last change:  Wed Jul 27 00:51:07 2022 by root via cibadmin on pcmk-1
  * 2 nodes configured
  * 3 resource instances configured

Node List:
  * Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:
  * fence_dev       (stonith:some_fence_agent):      Started pcmk-1
  * ClusterIP       (ocf:heartbeat:IPaddr2):         Started pcmk-1
  * WebSite (ocf:heartbeat:apache):  Started pcmk-1

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Wait a minute, the resources are still on pcmk-1!

Even though WebSite now prefers to run on pcmk-2, that preference is (intentionally) less than the resource stickiness (how much we preferred not to have unnecessary downtime).

To see the current placement scores, you can use a tool called crm_simulate.

[root@pcmk-1 ~]# crm_simulate -sL
[ pcmk-1 pcmk-2 ]

fence_dev   (stonith:some_fence_agent):      Started pcmk-1
ClusterIP   (ocf:heartbeat:IPaddr2):         Started pcmk-1
WebSite     (ocf:heartbeat:apache):  Started pcmk-1

pcmk__native_allocate: fence_dev allocation score on pcmk-1: 100
pcmk__native_allocate: fence_dev allocation score on pcmk-2: 0
pcmk__native_allocate: ClusterIP allocation score on pcmk-1: 200
pcmk__native_allocate: ClusterIP allocation score on pcmk-2: 50
pcmk__native_allocate: WebSite allocation score on pcmk-1: 100
pcmk__native_allocate: WebSite allocation score on pcmk-2: -INFINITY

7.8. Move Resources Manually

There are always times when an administrator needs to override the cluster and force resources to move to a specific location. In this example, we will force the WebSite to move to pcmk-2.

We will use the pcs resource move command to create a temporary constraint with a score of INFINITY. While we could update our existing constraint, using move allows pcs to get rid of the temporary constraint automatically after the resource has moved to its destination. Note in the below that the pcs constraint output after the move command is the same as before.

[root@pcmk-1 ~]# pcs resource move WebSite pcmk-2
Location constraint to move resource 'WebSite' has been created
Waiting for the cluster to apply configuration changes...
Location constraint created to move resource 'WebSite' has been removed
Waiting for the cluster to apply configuration changes...
resource 'WebSite' is running on node 'pcmk-2'
[root@pcmk-1 ~]# pcs constraint
Location Constraints:
  Resource: WebSite
    Enabled on:
      Node: pcmk-2 (score:50)
Ordering Constraints:
  start ClusterIP then start WebSite (kind:Mandatory)
Colocation Constraints:
  WebSite with ClusterIP (score:INFINITY)
Ticket Constraints:
[root@pcmk-1 ~]# pcs status
Cluster name: mycluster
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk-1 (version 2.1.2-4.el9-ada5c3b36e2) - partition with quorum
  * Last updated: Wed Jul 27 00:54:23 2022
  * Last change:  Wed Jul 27 00:53:48 2022 by root via cibadmin on pcmk-1
  * 2 nodes configured
  * 3 resource instances configured

Node List:
  * Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:
  * fence_dev       (stonith:some_fence_agent):      Started pcmk-1
  * ClusterIP       (ocf:heartbeat:IPaddr2):         Started pcmk-2
  * WebSite (ocf:heartbeat:apache):  Started pcmk-2

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

To remove the constraint with the score of 50, we would first get the constraint’s ID using pcs constraint --full, then remove it with pcs constraint remove and the ID. We won’t show those steps here, but feel free to try it on your own, with the help of the pcs man page if necessary.

[1]Compare the key used here, ocf:heartbeat:apache with the one we used earlier for the IP address, ocf:heartbeat:IPaddr2.