Facebook
Twitter
Lets continue here:
@sergey,
As far as I am aware of, Plesk installations in the cloud are solely based on "images", being snapshots of pre-installed Plesk on specific VMs with specific VM sizes and similar VM configurations settings.
For instance, a cloud provider has to deliver 3 images when using three VM sizes.
Problem then is resizing an existing Plesk image to a larger or smaller VM: currently, most providers do not allow for dynamic resizing/scaling.
Please note that scaling has a dual meaning: on the one hand it is "increasing the number of VMs in a joint set of VMs" and the other hand it is "resizing one specific VM" (being the change of VM specs).
Scaling in the meaning of "resizing" is often not possible due to "image constraints".
Scaling in the meaning of "changing VM numbers in a given VM set" is possible in theory, but in practice it often will not be feasible at all.
The above is merely an illustration, the actual problems are too many and too diverse to be mentioned.
This actually represents a current flaw in structural design of Plesk.
In ONE server, the installed virtualization server software can allow for Plesk clustering, fail-over etc.
In TWO or MORE servers, it depends on the virtualization server software AND the chosen infrastructure, primarily that of the filesystem and the OS.
In the CLOUD, virtualization environments are given parameters, often not allowing clustering, fail-over etc.
Simply said, ONE Plesk installation
- CAN be distributed over multiple servers (huge degree of difficulty), AND
- CAN even be distributed over multiple (public or private) cloud servers (huge degree of difficulty), BUT
- CANNOT be SCALED from one VM to another VM with different specs,
since the latter would be merely installing Plesk on a fresh (virtual) server, hence requiring the adoption of the "image method" that most cloud providers and/or cloud software use.
In short, there is an absolute difference between clustering (fail-over, load-balancing etc.) and scaling.
However, it is absolutely true that clustering (irregardless the reason thereof) is often not necessary, but that often has nothing to do with the potential of virtualization techniques.
In essence, even though scaling and (cloud-based) clustering and scaling should be considered to be two separate discussions, the problems in both those areas are the result of one structural design "flaw".
This "flaw" is not really an actual design flaw, but a better word seems to lack.
This "flaw" is the usage of the OS-disk by Plesk for installation purposes.
That seems the logical thing to do, but in a cloud it often is not.
Both the OS and ephemeral disk are provisioned and re-provisioned at creation time of a VM.
The Plesk installation is therefore "lost" when scaling the VM, as such requiring a new provision of the VM.
The problem here is not that there is a functional flaw in the design of the infrastructure, the design of Plesk can be maintained as is.
The problem here is that one cannot easily define config directories and/or define the place (or even VMs) at which specific processes should be running.
A simple solution and a great step forward would be an "advanced" installer (not the command line one), that allows for installation on multiple machines.
To be honest, that would result in some license policy issues (one-server-one-license model), but that is not completely true: processes like MySql, drwebd, syslogd should be able to run from various places/VMs.
Note that I do not mention Apache, since currently an extensive reconfiguration of Nginx could allow for the use of a clustered Apache web server, residing on external VMs.
