@virtubox
A small comment to your response, which comment is only intended to clarify the idea behind the post that you quoted.
This is only my opinion but performing and restoring a Plesk full backup daily do not seems very efficient to me.
You are right, I just misread the word "migration" as "backup" in the post of the thread starter
Is it possible to schedule full migration on daily basis ?
and it is really stating "migration", not "backup". My bad! Must be a lack of sleep
The statement
Databases and emails should not be hosted on a Plesk HA cluster (especially emails, because only a single server will send/receive emails).
is not correct: just changing MX records is sufficient to create a mail cluster (read: set MX record priority to an equal value, often works with the one or two rare exceptions..... even though a proxy or load balancer setup is better to guide mail to the appropriate server) AND when wanting a mail cluster with a primary and secondary mail server, one still wants to have a slave (with lower priority than the master) with all the most recent mail data present.
Sure, we are not talking about a proper setup of a mail cluster: any mail cluster should
ideally be a separate infrastructure outside of the Plesk eco-environment.
The problem is that the thread starter
apparently wants to set up a dual and replicated Plesk instance ...... which is odd, in a sense: I will return to this later.
The statement
The remote MySQL server support provide the ability to host sites databases outside the cluster, and to only have to sync files between the Plesk servers.
is a bit "yes, true ...... and ........ no, not true", in the sense that the statement is out of context.
One should not really want to have a remote MySQL server when using Plesk: all of the communication is not safe and one is creating a huge security risk,
unless one is able to create an internal network that is fully shielded off for outside traffic.
Sure, when disregarding security considerations, we have to take into account that the thread starter already has a MySQL cluster (note: I assumed this, but I can be mistaken!) ................ and from that perspecitive, you are right and I have to say "yes, true".
However, when using a 2-server infrastructure for the creation of a "Plesk cluster + MySQL cluster"......... then the whole setup is a bit silly (read: both the Plesk and the MySQL cluster should be
separate and consist of
at least two nodes) and a bit error-prone (read: the smallest mismatch between slave and master config or Plesk/MySQL related files can lead to very, very big problems - especially when trying to restore a faulty node, certainly when the master has to be restored).
In essence, I am saying "no, not true" .......because of the sillyness of combining two types of clusters (Plesk and MySQL) on two nodes: sure, you are right that one only has to rsync (specific sets of) files.........but a shared file system (read: distributed file system) is more easy and does not require any rsyncing at all (and note that this apart from the advantages of distributed file systems, such as the fact that they are often "self-healing" and "self-managing").
Let's return to something really important for the original thread starter @nisamudeen97 : consider the facts that
1 - any Plesk cluster with two Plesk instances is a bit odd: twice the licensing costs, while only using one Plesk instance at the time
2 - any Plesk cluster with two Plesk instances is restricted to a master + passive slave model: load-balancing of requests is rather difficult or even impossible, in the sense that (on the one hand) a load-balancing based division of workloads across servers will cause differences in the two individual Plesk instances, making each of the individual Plesk instances not suited for the purpose of fail-over and (on the other hand) the method of data replication (from master to passive slave) is essentially limited by the data replication possibilities that are inherent to MySQL (read: master/slave MySQL data replication methods are very simple and, as a result, in some cases scripted dumping of data and scripting importing of data is more performant), with a particular disadvantage of huge overloads on the MySQL master server (read: when tweaked properly, the additional workload of master/slave data replication is not huge, but the default Plesk config for MySQL really has essentially to be rewritten completely)
3 - separation of the MySQL cluster can prevent a lot of problems, but it will not change the concept that Plesk still will be using a local MySQL database (note: you should not want differently, for reasons of security and for reasons of performance), whereas databases of domains/vhosts
could be hosted on an
external MySQL cluster
4 - Plesk does not support safe (read: TLS based) communication with remote MySQL servers
and the above is not a complete summary: it only contains some (of many) important facts to consider.
In essence, several alternatives are to be considered:
Option 1 - One Plesk instance + distributed file system
This setup is not that complicated and saves money on Plesk licenses: file data, including MySQL data and Plesk config (!), is replicated across various nodes.
Note that this setup can be made secure without much effort and/or that an
external MySQL cluster is optional.
Option 2 - One Plesk instance + mounted storage
This setup is almost identical to option 1, with this difference that one simply mounts some storage space that is accessible by many servers: just install or activate a second Plesk instance (note: you can use the same license, if the master server is down or broken) when needed and attach the storage space!
Note that you should NEVER put MySQL data in a mounted storage space: this will cause very severe problems.
Option 3 - One Plesk instance + Nginx proxy + another server
The second server can be anything, even a lightweight Nginx server: the master server can
mirror any request by using Nginx directives to the slave server, which then updates MySQL server and in some cases even file uploads (note: rather difficult to configure, but it is possible).
The disadvantage of this approach is that (on the one hand) mail related data will not be included and (on the other hand) rsyncing on a regular basis has to be done.
Note that all of the above options are very briefly described, it is a very
rough outline of what can be done
when trying to get the advantages of a cluster, while preventing the use of commonly used tools like HAProxy, Heartbeat and similar.
Anyway, it still is not clear why one should want to use two OVH servers + one OVH load balancer for something trivial as fail-over.
Fail-over alone can also be achieved by making use of
-
required: scripted migration (via the Plesk Migrator tool) to the slave master, on the basis of a cronjob
-
optional: managed MySQL clusters (read: many cloud and hosting service providers AND external parties offer those clusters), although it being at the price of increasing the attack surface (read: mysql related communication with external MySQL servers is not safe, as stated before)
and high-availability is a total different story that requires a more elaborate setup and infrastructure.
Please note that I am being objective with respect to OVH in all of the above, but it really has to be said that any fail-over or high-availibility solution at OVH (and any other hosting provider) is a bit "overcomplicated", since any
cloud environment supports fail-over and high-availability with a "click of the button".
This is all I can about this topic..........so this will be my final word in this topic thread.
Hope it helps a (tiny) bit.
Kind regards.........
Facebook
Twitter
