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.
- 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.
- 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
- 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.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
