Synchronize Plesk Servers (Failover)
Keep two (or more) Plesk servers in sync for a failover scenario.
Migration Manager only allows manual "sync"
Although the implemented solution differs from the initial demand, we are closing the request as "already available”. We have thoroughly investigated the idea to solve the redundancy issue using a Plesk cluster. Our research has proved that this solution is not in step with the times, is no longer demanded by our partners, and has its limitations. We would like to give an explanation of each point.
More than nine years ago, when the request was created, the IT world had already begun to change. Previously, partners and customers bought or rented bare-metal servers and organized them in data centers. If the servers did not have sufficient component redundancy, there was a risk that a power supply or hard drive failure would lead to service downtime. However, a synchronized failover server could save hosting from such problems. But since then, hosting infrastructure has changed significantly. These days, public clouds are everywhere, partners and customers use virtualization systems, and software runs in containers.
We interviewed our partners to make sure they still needed a high-availability (failover) cluster for Plesk. It turned out that the majority of partners already had virtualization systems in their infrastructure. To protect a server with Plesk from failures, many partners already use high-availability features provided by virtualization systems. Some partners are no longer interested in a high-availability (failover) cluster. Instead, they would like to have a high-load cluster with active/active nodes, where the load is balanced between all cluster members.
In the meantime, we tried building a Plesk cluster. It proved to be possible but with many limitations. A Plesk cluster also requires more servers and resources for deployment from partners and customers, which leads to increased infrastructure costs. The solution would be unreasonably expensive for end users. Developing a Plesk cluster further and making it suitable for production requires lots of additional investments. They will not justify themselves from the point of view of our partners, customers, end users, and Plesk itself. Should anyone decide to continue the research on how to adapt Plesk to be a part of a failover cluster, we have published our research results together with the proof of concept. If you have any feedback, we have created a topic about high availability Plesk on our forum.
Note: We recommend using a centralized database and centralized file storage (NFS) together with virtualization systems and/or cloud providers that provide high-availability functionality on the server rather than the software level. At the same time, we do not plan to continue developing any high-availability redundancy on the application level.
Laju Sangat commented
Bye bye plesk... I have more 200 plesk license... move to aaPanel...
Bryan S. Katz commented
For the record, my business remains in the world of bare-metal in data centers. It's far faster, far cheaper, and far less convoluted. For all of the reliability concerns that existed 11 years ago, bare-metal failure rates have simply plummeted the same way. Bare-metal lets the infrastructure remain so simple that there is simply so little to go wrong.
I don't need "high-availability on the software level". We're talking about a once-a-decade failure scenario. I just need a recent backup (an hour, a day, even a week) to expedite the return of business during repairs.
In the plesk world, I just want all vhosts to be configured on all plesk servers. That's it.
But I get it. Plesk is fast becoming the wrong fit for my business. That's to be expected of any tool over time.
While we're discussing containers and virtualized clouds with respect to high-availability, it's worth noting that while these 11 years have solved hardware failures, they've made it absolutely impossible to recover from a cybersecurity attack. We've just watched a major corporation take two days to get a single html file online, two weeks to get a static catalogue back online and credit cards in their physical stores, and an entire month to return to normal business. The right bare-metal strategy allows for some very small fixes to very big concerns.
Danir Toma commented
This is not at all a desired state and won't solve any problems.
Plesk is very "stateful" and cannot be easily recovered with all it's configuration using a configuration management tool.
It's not only about "failing hardware", but also about maintenances or logic failures.
Declining this means that all plesk maintenance interaction cannot be fully automated and always needs a human around.
It's very sad seeing Plesk going this way, since that's not the way enterprise software in the modern cloud aera is going.
Les Fenison commented
I don't understand why all this talk about this feature not happening. It has happened. https://www.plesk.com/blog/product-technology/install-plesk-high-availability-cluster/
Using the suggested solution would make Plesk unnecessary for my servers. I am deploying Plesk, exactly because I am not relying on third-party cloud-infrastructure, but rather dedicated servers, that make up my own system of systems.
If by partner you mean your resellers, they themselves of course do not deploy Plesk for their hosting products - they want to sell their cloud-services.
How does virtualization at the cloud provider provide failover. Is that why cPanel is working on a Kubernetes version.
> We recommend using a NFS
Yeah, that's the thing that was needed - the most difficult part.
What a way to drop the ball...
"We interviewed our partners" - hmm, I have over 500 licenses and never got the interview, so I guess that makes me not a partner.
In any case, the need here is not to solve for underlying hardware problems; everyone virtualizes these days, that's easy. Your own software tends to cause more outages than hardware, which is why one may want such a solution, but also for disaster recovery scenarios which differ from the underlying DR config on the hypervisors.
Michael Lenz commented
Clustering is even with virualization a required feature. - Shell/Do we need a new voting?
After nine years plesk decides to ditch the most voted request based on the fact that there could be some partial workaround for this, and that some users already utilize such workarounds.
Also your justification has a technological bias. Having a virtualized infrastructure indeed in many cases solves a big part of the problem but does not solve the equation.
Even a virtual server on a clusted could go down for a significant time or fail alltogether. We have seen this over and over. Either due to a corruption in the file system or db corruption, hardware failure in the storage, human error , network problems, or even the entire data center in some rare cases could go down.
So in this case a second replica server and with the use of CDN that already provides a built in failover IP to start serving the website or websites from an alternate server , would instantly mitigate the problem with zero or minimal impact to the services.
I do believe this request must be looked again and is still a valid feature request.
Mathias Bank commented
Recommending centralized databases without supporting ssl connections to them is …. A bad joke, isn’t it?
Plesk & CPanel are owned by the same company Oakley Capital. I can see why Plesk would not want to implement this, the frustration is if client needs this desperately you can switch to more expensive option CPanel. To me this is all business rather than technical limitations by Plesk !
I agree that this is kind of dissapointment, but hey, guys, there is something like lsyncd service which works on i-node level and is fast as ****. with galera on database level you can easily build what you need
@Adam : Using a rsync would only allow to sync files. You would need some additional settings to sync databases, and ideally to sync Plesk's own setting (if the user creates an FTP account, changes a PHP setting, etc.).
It's a bit of a bummer to limit ourselves to a silly file sync, or to do it all ourselves, when there's a Plesk migration tool that does almost all of this already, that we just need to be able to automate, to launch it periodically... Why re-invent the wheel?
Regarding the cloud and centralized storage, it's a NO-GO for my clients: Their goal is to have an A server at one provider, and a B server at another, and simply have the same data (within an hour) between the two servers.
Customers don't want to depend on a complicated HA storage infrastructure, which usually requires relying on a single hosting provider. This type of setup is possible for active-active infrastructure (where files must be identical at all times), but for active-passive (with a maximum of 1 hour delay), it seems a bit disproportionate
Alvaro Luis Castro Tomás commented
Hora de migrar a cPanel, adiós Plesk
we have seen this end result coming, in our case we host critical web applications for schools, hospitals and CRMs unlike regular website that needs redundancy at all levels.
It was a good decision we took this year to start investing our time on Clustercs solutions and we believe in Q2 we can finally say goodbye to Plesk .
Never the less, Plesk support is one of the best in the industry in my experience but unfortunately now for us to move on !!!!!!!!!!!!!!!!
@Charley - I'm newer to network support so this may be a dumb question... if it is really just the 15 minute sync that you are after, why not just use rsync or similar?
And, if you are fortunate enough to be in a cloud environment, this could easily be done using a combination of the centralized storage listed above and, rsync and/or snapshot backups. No?
It seems the bigger issue is the management of the clusters, IPs, etc. The replication of data can be done by a few different programs, couldn't it?
Gijsbert Schrijvers commented
Time to say goodby to plesk. I waited for a long time for this feature. After waiting and hoping this feature would be available, I carried on… no other option than moving to Cpanel.
I understand the thinking on Plesk's side, but I find the end result disappointing. The answer seems to be "we don't find it interesting (despite the number of recent votes & comments here that seem to show the opposite), we don't want to spend more time and money on it, figure it out yourself".
Plesk already has a great migration tool, which allows you to synchronize sites between multiple servers. A simple derivative of this tool, which would have allowed for example to synchronize one (or more) sites every 15 minutes, would have already met the needs of a large number of users I think.
At least, it would have solved the need of several of my customers. Their request is simple: Have two Plesk servers with synchronized content (less than an hour difference), and be able to switch from one server to another.
The "switch" part can be complicated to manage on the Plesk side, and I understand that. But this part can be done by a CDN very simply, no need to worry about floating IP. A Cloudflare Load Balancer subscription for 5$ allows to do the switch in a perfect way. Only the data sync between the two Plesk is missing.
Now it's time to say goodby Plesk. Last week on the Cloudfest, nobody from the team, was talking over the fact that it will never come and now this message... ufff
Understandable, but disappointing nonetheless