Configuration Cluster in WHM
-
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. 0 -
I view HA at the service level. So which services are the target, is the 1st question. Then it could be an active/active cluster for the targetted services 0 -
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. 0 -
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. 0 -
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.. 0 -
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. 0 -
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)0 -
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. 0 -
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?0 -
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. 0
Please sign in to leave a comment.
Comments
10 comments