Server configuration and data auto-sync (mirroring)

[dwykofka]

There certainly are 2 topics here with 2 distinct audiences.

People who build/rollout new servers:
1. Backup settings from a master cpanel server to be used in say yaml format when rolling out new servers.

People who administer servers:
2. Synchronize changes across cpanel servers so that you dont have to go change a setting on 50 boxes.

Both seem very important and would be a good use of developer time.

[myusername]

Agreed the yamls would be good to have but the part I am wondering about is why do you guys want yaml files that you have to import/export manually when these yamls could be sync'd by cPanel? That would cover both groups 1 and 2 above.

[dwykofka]

Agreed the yamls would be good to have but the part I am wondering about is why do you guys want yaml files that you have to import/export manually when these yamls could be sync'd by cPanel? That would cover both groups 1 and 2 above.

Because some people want to use this feature to build a static config that they apply when rolling out cpanel servers to customers or within their corporation but they dont want to sync the servers going forward.

[myusername]

So then why not add the new server to the (proposed) group of servers that are all in the (proposed) settings manager (this group is the group that is always synced), then, setup the new server by syncing the latest settings, then remove it from the list. I think that is a pretty flexible option that would suit both groups mentioned. Adding and removing a host from a web form is a lot faster than building custom build scripts using yaml.

A master server could even support different groups. One for a static setup that differs from your normal setup, so that hosts can be added to get the settings, and removed. Another group could be your always synchronized group.

[dwykofka]

Using a yaml setup is better for rolling out servers. You dont want to have to create a sync relationship with every server that you are provisioning. You can post the current yaml in your intranet and all techs can just upload that file to new servers. It's a lot cleaner that creating / destroying a sync.

[cPanelDavidG]

To clarify, this feature request is explicitly about mirroring all data among multiple servers.

Conversation about just copying server configurations should take place in the feature request thread for this: http://forums.cpanel.net/f145/case-4...on-144297.html

[Drake]

Any progress? What's the status of "Complete Server Mirroring" for backup / faliover / load balancing ? Or did this cP dream go dead?

[cPanelDavidG]

Any progress? What's the status of "Complete Server Mirroring" for backup / faliover / load balancing ? Or did this cP dream go dead?

The core of this feature request is mirroring files among servers. Anyone have any technical suggestions on how this should be implemented other than what we saw on page 1 of this thread of perhaps implementing as an active/passive system? How should the files be mirrored given that rsync tends to show its shortcomings quite readily when transferring terabytes of information? Maybe this should be done with central file storage, but wouldn't that present yet another single point of failure?

[SoftDux]

The core of this feature request is mirroring files among servers. Anyone have any technical suggestions on how this should be implemented other than what we saw on page 1 of this thread of perhaps implementing as an active/passive system? How should the files be mirrored given that rsync tends to show its shortcomings quite readily when transferring terabytes of information? Maybe this should be done with central file storage, but wouldn't that present yet another single point of failure?

rsync / unison would probably be the best / ideal way of doing this.
And yes, a central storage system would have it's benefits, but what if someone wants to mirror accounts between 2 servers, in 2 different data centers spread across the globe? in many cases you won't be able to connect a SAN or NAS to another server, in another DC, on another IP subnet. So this is something to keep in mind as well.