cPanelDustin

Product Owner
Staff member
Jan 28, 2020
22
15
78
Houston, Texas
cPanel Access Level
Root Administrator
As we further explore the cPanel High Availability path, we are researching expanding and retooling the configuration cluster within WHM. I hope to use this thread to have a continued discussion around that technology.

What do you expect to happen when a new server is added to the cluster? Specifically when that server is a brand new cPanel server vs an existing cPanel server with configurations?

Once the configuration is set up, what would you expect the workflow of replicating configuration changes on one server to the other servers in the cluster.
 
  • Like
Reactions: cPRex

ffeingol

Well-Known Member
PartnerNOC
Nov 9, 2001
765
310
363
cPanel Access Level
DataCenter Provider
Personally, I can't really answer your question, as I don't really understand the configuration of proposed "High Availability" in cPanel. Is this just an active/standby server or will it be a true cluster? Once I know what options we'd have, I can provide more useful feedback.
 
  • Like
Reactions: Spirogg

cPanelDustin

Product Owner
Staff member
Jan 28, 2020
22
15
78
Houston, Texas
cPanel Access Level
Root Administrator
Mostly my question at this point is focused on server configurations themselves. Not the overall HA infrastructure as a whole. For the purposes of this discussion, thinking about a fleet of cPanel servers you'd want to keep feature-synced and config-synced is where I'm trying to gather information. Currently we support Update Preferences within the existing version of configuration cluster. If we were to greatly expand that offering, that's the workflow I'm working on understanding.
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
12,498
1,969
363
cPanel Access Level
Root Administrator
I just work here and you guys hear me talk all the time, but I'll throw some thoughts out anyway. My expectation would be similar to a DNS cluster - I add my server to the configuration cluster and all the config options from that particular parent get automagically synced. All the cluster children are also automatically updated in the future should I decide to change a config option on the parent.
 

ffeingol

Well-Known Member
PartnerNOC
Nov 9, 2001
765
310
363
cPanel Access Level
DataCenter Provider
While I like the idea of a configuration cluster, I doubt that we'd ever implement it. We (for example) try to keep the configuration (tweak settings, Exim, Apache etc.) in sync between classes of cPanel servers (shared, reseller etc.). When we do make a change, we typically test it out on a few servers, see if it resolves the issue we having and then roll it out to the rest of the servers in that class. Any type of configuration cluster defeats that process and would roll it out to all servers at the same time..
 

andrew.n

Well-Known Member
Jun 9, 2020
930
345
63
EU
cPanel Access Level
Root Administrator
I would expect to be able to push the current HA cluster configurations (exim, apache, mysql etc etc..) over to the newly added server. As to keep the configurations in sync I'm thinking similar approach than what you currently have with the DNS cluster.
 

PeteS

Well-Known Member
Jun 8, 2017
324
67
78
Oregon
cPanel Access Level
Root Administrator
I'm assuming the idea here it that in the future setting types (like the service configurations in Transfer Tool) would be added to this interface.

What do you expect to happen when a new server is added to the cluster? Specifically when that server is a brand new cPanel server vs an existing cPanel server with configurations?
It seems logical to have the new secondary server adopt all settings from the master. In the case of an existing server having only an adopt all, or adopt nothing, choice seems useless (either cluster it or don't). I could imagine a case where an admin doesn't want certain setting types to follow the master, so having a choice on adding to update individual setting types never, once, or continuously might make sense.

Having gone that far, I suggest we ignore the new vs existing server scenario, and instead be able to configure the master per setting type to send: never/once (sync now button)/always, AND be able to configure each secondary server to receive settings per type: never/once (sync now button)/always. (Privilege logic to be: never > once > always when it comes to conflict between master and secondary settings.)

Once the configuration is set up, what would you expect the workflow of replicating configuration changes on one server to the other servers in the cluster.
I would expect that to depend on the never > once > always that applies per type between any two servers.

Master - Secondary
always - always (do it on update of master, via a "sync all applicable now" button, and an option to set "auto sync" that enables a once a day cron)
always - once (do it when a sync request comes from a secondary)
once - always (do it when a sync request is initiated on master)
once - once, or never on either side (nothing happens - meaning master not available, or secondary not wanted)
 

IndicHosts.net

Well-Known Member
Mar 11, 2006
74
30
168
Online
cPanel Access Level
Root Administrator
Just a small caveat, please allow new server settings overridden on local to be exempted from next sync. Certain settings are hardware-dependent, so we must allow of local overriding of synced settings which are excluded from future syncs.
 
  • Like
Reactions: PeteS

PeteS

Well-Known Member
Jun 8, 2017
324
67
78
Oregon
cPanel Access Level
Root Administrator
Just a small caveat, please allow new server settings overridden on local to be exempted from next sync. Certain settings are hardware-dependent, so we must allow of local overriding of synced settings which are excluded from future syncs.
From my suggestion above, wouldn't setting that server's cluster setting for any settings you don't want messed with to "never" accomplish what you need?
 

daveefordays

Registered
Aug 24, 2022
1
0
1
Australia
cPanel Access Level
DataCenter Provider
I think the way I would handle it is you change settings on the master, but then need to run a task to sync those settings, and when you are running the task you can tick tickboxes of child nodes you want to write settings to. You could even break down categories of settings to write across.

If you haven't yet written settings across you should get a warning at the top of WHM that reminds you that you have child nodes that aren't in sync with the primary node yet.


As for DNS, sites and file storage, these should automatically sync as soon as there is a node connected.

How will DNS servers be handled? I'm thinking I'd like each node of mine to have its own DNS server so that if all bu 1 go down, there is still active DNS.