• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Any plans for an HA solution?

HostaHost

Regular Pleskian
Curious if there is anything on the roadmap for a version that implements any type of HA features, such as managing multiple servers and then we provide the load balancing on the front end? Example; Plesk manages nginx/apache config across two servers so SSL updates, etc. happen on both, we stick an haproxy instance in front and deal with the shared storage issue to ensure /var/www is the same on both servers.
 
Thanks; just added vote and comment there. I have a feeling this is going to be a bit too far from the needs of Plesk's normal customer base to make it attractive for them to develop. There's so many factors that go into an HA solution, and choices that may be good or bad from one entity to the next, that they probably wouldn't be able to come up with something that works for all that many users.

My vision was haproxy or hardware in front, Plesk on a 'master' server A, slave server B, then database on back end server. The /var/www/vhosts can be implemented via hardware or software NFS on an independent device or perhaps the same system serving as database server, or a cluster filesystem can be used so server A and B share the filesystem for the site-specific directories. Plesk's responsibility would be maintaining configs for the normal daemons it touches, nginx, apache, dovecot, etc., it would know about both servers' unique IP addresses and let you pick the address for a site on both servers, you can put in the public IP like you can now and DNS is based on that, an update that requires a daemon restart (such as new SSL install) does one server at a time, etc.
 
How would you manage HA if you have a single point of failure with the shared filesystem ;) There's enough info out there to replicate MySQL, load balance Apache, etc. But as far as Plesk - yea, don't see that really happening. You never know though!
 
In our case the shared filesystem would be implemented on top of redundant enterprise storage, whether that be hardware-redundant NFS, or two VM's using a cluster filesystem on top of multi-path block storage, so either way that would not be the concern. The database would be one, and haproxy would be if not implemented as two nodes, but both of those are minor concerns if the db server is a VM on top of a hypervisor that supports auto recovery on another hardware node, or could be made redundant too if absolutely necessary. That would all be easily managed outside of Plesk so not too worried; it's all the daemon configs for things customers need the ability to self-manage that are the real problem. If we need to get to the point where we're watching and replicating everything Plesk manages to redundant servers, not much point in not just building our own panel at that point.
 
In my opinion, HA solutions are already hard enough to deploy without Plesk (HA with Mutli-master database cluster and at least two frontend with a load-balancer).

I'm using MariaDB Galera Cluster as an external database for some Plesk servers, but adding redundancy for web servers do not increase websites availability enough to be an interesting solution at the moment.
 
Just regular kernel and hypervisor updates are generating enough downtime to create problems these days, then you add in downtime from customers who want to do something like Lets Encrypt so web server restarts are occurring every 90 days for every site on a given server (all of course on different schedules), nightly log rotation, Plesk webstats that still pipe to 'sort' and run the server out of memory on big sites, so on and so forth; all adds up to an appreciable amount of downtime if the server houses a high volume commerce website; i.e., financial loss.

We can work around it on a site by site basis, but a more formal solution means effectively building our own panel...
 
Just regular kernel and hypervisor updates are generating enough downtime to create problems these days, then you add in downtime from customers who want to do something like Lets Encrypt so web server restarts are occurring every 90 days for every site on a given server (all of course on different schedules), nightly log rotation, Plesk webstats that still pipe to 'sort' and run the server out of memory on big sites, so on and so forth; all adds up to an appreciable amount of downtime if the server houses a high volume commerce website; i.e., financial loss.

We can work around it on a site by site basis, but a more formal solution means effectively building our own panel...

Kernel and Hypervisor (KVM) can be upgraded without reboot with kexec-tools or KernelCare ($3/mo to never need to reboot).
And about Apache restart, with Nginx micro-caching it's not a problem anymore.
 
For a transactional site, caching doesn't help; any interruption to the application results in potential lost revenue, so the kind of sites I'm talking about even a few seconds for an SSL-related restart could cost money. We do HA manually to get around that, but anything to make life easier is desirable. Unfortunately not using KVM due to numerous reasons mostly related to performance and features from the vsphere/vcenter enterprise plus suite.
 
For a transactional site, caching doesn't help; any interruption to the application results in potential lost revenue, so the kind of sites I'm talking about even a few seconds for an SSL-related restart could cost money. We do HA manually to get around that, but anything to make life easier is desirable. Unfortunately not using KVM due to numerous reasons mostly related to performance and features from the vsphere/vcenter enterprise plus suite.

Nginx micro-caching with the proxy_cache_use_stale directive will only use cache if the next upstream isn't available, With a low cache timeout value, it provide a good solution to never display 502 bad gateway again to your visitors.

vSphere was providing more features than KVM by the past. But i do not use ESXI or vCenter anymore, due to the lack of features compared to open-source platform like Proxmox VE 5, especially for HA.

VM live migration (even with local storage) and Multi-master host cluster are powerful solution to avoid downtime.
 
Back
Top