High availability · backend tier
Requests reach this cluster through a floating VIP held by a pair of controller nodes running Keepalived and HAProxy. HAProxy then routes the request into the cPanel backend tier, where 137-63-148-50.cprapid.com is the node that happened to answer this one. The backend tier is configured active–passive, so the other node only takes traffic if this one fails its health check.
Two tiers, not one. The VIP lives on the controller tier — never on a cPanel node directly. HAProxy on the controller that owns the VIP decides which backend serves each request.
The literal sequence a single request follows, in order.
The application's hostname resolves to the floating VIP — never to a specific controller or cPanel node.
Keepalived elects one controller to hold the VIP at a time via VRRP. The client only ever sees one address.
HAProxy on the VIP-holding controller health-checks both cPanel nodes and routes the request to one of them — this is the only load-balancing decision in the chain.
The receiving cPanel node's Apache matches the request to the correct virtual host and document root.
This script runs, reading whatever it needs from local or shared storage.
Home directories and mail/database state are replicated between cPanel nodes, so either node can serve the same account.
Backend node → controller → VIP → client. The client never learns which physical node answered.
| Hostname | 137-63-148-50.cprapid.com |
| Server IP | 137.63.148.50 |
| Server name | app07.school.sys.renu.ac.ug |
| Web server | Apache |
| Operating system | Linux 5.14.0-611.5.1.el9_7.x86_64 |
| PHP version | 8.2.33 |
| Client IP | 137.63.148.184 |
| Request time | 2026-08-25 11:51:36 EAT |
haproxy_stats_url in the config block at the top of
this file (or the HAPROXY_STATS_URL environment variable) to a reachable HAProxy CSV
stats endpoint, for example http://ctrl-a.renu.example:8404/haproxy?stats;csv, to
pull real UP/DOWN state for both cPanel nodes here.