Plesk problems in Clouds

[Sergey L]

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.

 

[Sergey L]

So my comment from the other trhead was that Plesk VMs are commonly scaled up with resources and disk re-provisioning problem sounds unamiliar to me.
Yes, sometimes in hardware setups data go on separate disk, but this is easily solved via mounting disk to a proper folder.

If we talk about complete DevOps with frequent re-provisioning, then I am not even sure Autoinstaller needs a support for it - anyway new Plesk would be empty.
I would assume, that Plesk shall be a part of a VM image and re-deploy process shall refill fresh Plesk with existing data.

Can you give a specific example of Plesk used in Cloud infrastructure from your experience? How it worked?

 

[trialotto]

Sergey,

It is somewhat difficult to maintain the "eagle view" over topics discussed in this forum, but I will give it a try.

Please note that more concrete reactions/proposals will be sent to your mailbox on this forum.

With respect to cloud-related issues of Plesk installations, I will keep the discussion constrained to

- Ubuntu OS: 12.04, 14.04, 14.10 and (optional) 15.x (in development) (other OS-es are also tested, but less relevant, given the stability and/or frequent use of Ubuntu)
- cloud-init: 0.7.5, 0.7.6 and 0.7.7 (these cloud-init versions are shipped with the various Ubuntu versions)
- Azure (using the waagent script and cloud-init to provision VMs)
- Plesk: 12.0.18 and higher (lower versions of Plesk are less relevant, also given the change in business model within Plesk)
- Linux environments (Windows environments are even more buggier in the cloud)
- Plesk CLI installer (headless)

and the following (problematic) scenario´s (amongst others) will occur:

a) disk infrastructure, as provided and initiated by the Azure fabric, resulting in

- "disk overflow issues", since Plesk essentially installs on the OS disk (that is relative small)
- "persistent storage issues", since the ephemeral disk is lost (re-formatted) at shut-down and/or re-provisioning,

and the above issues are not limited to Azure, but are a general issue with various cloud providers.

b) image infractructure, being a (improper) solution to the issues in point a), resulting in

- "scalability issues": the VM with the Plesk installation cannot and/or cannot be easily scaled to a VM of different size (due to static size of the image with Plesk installed),
- "cluster issues": provisioning a second VM with an image does only result in an identical Plesk installation, not a number of VMs that allow for clustering, HA, fail-over etc.

and the above issues are (again) not limited to Azure, these are general cloud-related issues.

c) storage infrastructure, resulting in

- "mount issues": non persistent mounts of disks or storage shares (note that cloud fabric often re-initiates all the disk and storage settings)
- "partition issues": Plesk is rather specific in required disk partitions and file/directory locations, leaving less space for individual partition settings (as often required by clouds)
- "fileshare issues": some protocols/functionalities in Plesk do not necessarily coincide with the cloud fabric (for instance, SMB protocol)

and the above issues are (again) not limited to Azure.

d) process infrastructure: various processes should be able to run from different VMs, in order to allow for VM clustering, HA, fail-over etc.

e) network infrastructure (for the sake of convenience, I will not split up into separate issues).

All the above can be summarized to:

"In general, a Plesk installation in the cloud can be deemed to be static, hence not being able to make optimal use of cloud fabric and associated advantages".

A potential candidate for resolution of various issues seemed to be the CLI installer, but that proves to be rather buggy and/or documentation is not up-to-date.

A good starting point for the resolution of many issues should therefore be found in a two-step method:

1) provisioning of a VM, according to and (more important) agreeing with cloud fabric specifications,

2) automatically installing plesk autoinstaller script, as part of the provisioning script.

The second step can be arranged by scripting provisioning via custom script, Chef, Puppet etc. etc.

However, in order to have Plesk installations making optimal use of cloud fabric, one should introduce in the plesk installer the options to define

- config locations (on the OS disk, not on the non-persistent ephemeral disk)
- file/directory locations (on added and persistently mounted disks, not the OS and/or ephemeral disks)
- optional: cache locations (on the ephemeral disk, with overflow methods, if the ephemeral disk becomes full)

and that would lead to the resolution of issues, as mentioned in point a) to c).

Furthermore, the plesk installer or some other install script should allow for "license key unprohibited installation" of Open Source packages, used by Plesk, whilst maintaining the possibility to monitor and/or manage these packages (and their processes) via a central (licensed) Plesk master server.

In short, Plesk can make optimal use (without any issues occurring) of cloud fabric, if and only if "distributed installation" options do exist.

That seems to be rather complicated, but it really is not.

The question is whether Parallels would like to develop in that direction, i.e. supporting the Cloud in a more thorough manner.

In a sense, there currently already exists some necessity to make Plesk more suitable for cloud-based installations, given the fact that many Plesk installations are residing on a server that has been sold as a dedicated server, but actually is a virtual server (part of a huge bare metal server).

The before mentioned installations are often causing problems, that can also be found (if one reads carefully) on this forum.

As a final note: I am willing to contribute to development, aimed at making optimal use of cloud fabric.

If you want me to, how are we going to coordinate?

Kind regards...