How to set up Apache HTTPD high availability with PCS

An Apache HTTPD high availability setup keeps a web endpoint reachable during node failure or maintenance by moving the service and its floating IP together as a single unit.

The pcs CLI configures Pacemaker resources on top of Corosync membership. A floating IP is commonly implemented with IPaddr2, while Apache HTTPD is managed as a systemd resource pointing to httpd.service or apache2.service, and grouping enforces colocation and start order so the VIP comes up before the daemon.

High availability requires identical configuration and content across nodes, including virtual hosts, modules, TLS keys, and the DocumentRoot tree. Disable automatic Apache starts outside the cluster, select an unused VIP on the correct subnet, and plan fencing/STONITH to reduce split-brain risk where multiple nodes attempt to serve the same endpoint.

Steps to set up Apache HTTPD high availability with PCS:

Confirm the cluster is online and has quorum.

$ sudo pcs status
Cluster name: clustername
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node-01 (version 2.1.6-6fdc9deea29) - partition with quorum
  * Last updated: Thu Jan  1 00:49:23 2026 on node-01
##### snipped #####

Confirm Apache HTTPD configuration and web content are consistent on every cluster node.

Keep virtual hosts, modules, and certificates identical across nodes, including common configuration locations like /etc/httpd or /etc/apache2 and the DocumentRoot tree under /var/www.
Validate the Apache HTTPD configuration syntax on every node.
```
$ sudo apachectl configtest
Syntax OK
```
Use apache2ctl configtest on systems that ship the apache2 tooling.

Related: How to test Apache configuration

Identify the Apache HTTPD service unit name.

$ systemctl list-unit-files --type=service | grep -E '^(apache2|httpd)\.service'
apache2.service                              disabled        enabled

Stop and disable the Apache HTTPD unit on every node to hand service control to PCS.

$ sudo systemctl disable --now apache2
Synchronizing state of apache2.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install disable apache2
Synchronizing state of apache2.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install disable apache2
Synchronizing state of apache2.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install disable apache2

Use apache2 when apache2.service is the installed unit.

Active connections can reset during the handover from direct systemd control to cluster-managed starts.

Create a floating IP resource for the web endpoint.
```
$ sudo pcs resource create apache_ip ocf:heartbeat:IPaddr2 ip=192.0.2.60 cidr_netmask=24 op monitor interval=30s timeout=20s
```
Select an unused IP on the correct L2 subnet to avoid IP conflicts, ARP flapping, and intermittent client connectivity.

Related: How to create a floating IP address in Pacemaker

Create the Apache HTTPD service resource.

$ sudo pcs resource create apache_service systemd:apache2 op start timeout=60s op stop timeout=60s op monitor interval=30s timeout=20s

Use systemd:apache2 when apache2.service is the installed unit.

Group the IP and Apache HTTPD resources.
```
$ sudo pcs resource group add apache-stack apache_ip apache_service
```
Related: How to create a Pacemaker resource group

Verify the resource group placement.

$ sudo pcs status resources
  * Clone Set: dummy-check-clone [dummy-check]:
    * Started: [ node-01 node-02 node-03 ]
##### snipped #####
  * Resource Group: apache-stack:
    * apache_ip (ocf:heartbeat:IPaddr2): Started node-01
    * apache_service (systemd:apache2): Started node-01

Verify the floating IP is attached to the active node interface.

$ ip -br addr show | grep 192.0.2.60
eth0@if456       UP             192.0.2.11/24 192.0.2.60/24

Verify the web endpoint responds through the floating IP.

$ curl -sI http://192.0.2.60/
HTTP/1.1 200 OK
Date: Thu, 01 Jan 2026 00:49:32 GMT
Server: Apache/2.4.58 (Ubuntu)
Last-Modified: Thu, 01 Jan 2026 00:28:55 GMT
ETag: "3-64748ad945d38"
Accept-Ranges: bytes
Content-Length: 3
Content-Type: text/html

Name-based virtual hosts may require an explicit Host header, for example:

curl -I -H 'Host: www.example.test' http://192.0.2.60/

Run a failover test after the group is running.

Failovers can interrupt in-flight HTTP connections and reset keep-alives, so testing is best performed during a maintenance window.

Related: How to run a Pacemaker failover test with PCS