jelastic-jps/wordpress-cluster

Enterprise WordPress Cluster for Auto Scaling, High Performance and High Availability

Highly Available and Auto-Scalable WordPress Cluster v2

Out-of-the-box automated Enterprise WordPress Cluster solution v2 for large businesses and mission-critical sites

WordPress Cluster Topology

Upon the package installation, a new environment with the following topology will be created:

• Either highly available LiteSpeed ADC or NGINX load balancer is used for distributing the incoming traffic within a cluster
• WordPress Brute Force Attack Protection option will protect WordPress admin panel in case LiteSpeed Web Server is chosen
• Web Application Firewall will be enabled by the default if LiteSpeed Web Server will be installed
• The WordPress application itself is handled by either LiteSpeed Web Server or NGINX PHP servers with preconfigured automatic horizontal scaling to handle load spikes
• Redis is high-performance RAM-allocated data structure store used as a highspeed caching solution
• Highly-available MariaDB Galera Cluster is used to store and operate user data
• Shared Storage cluster, ensuring high avaiablity with GlusterFS, is mounted to all application server nodes for sharing common data
• Traffic encryption is provided by Let's Encrypt Add-On with automatic issuing of trusted SSL certificate and Auto-Renewal.
• Premium CDN integration in order to provide Lightning-fast static assets loading

Deployment to the Cloud

Click the Deploy button below, specify your email address within the widget, choose one of the Jelastic Public Cloud providers and press Install.

Note:

• The installation of this clustered solution is available only for billing customers
• If you are already registered at Jelastic, you can deploy this cluster by importing the the package manifest raw link within the dashboard.

Installation Process

In the opened confirmation window at Jelastic dashboard, if required change:

• preconfigured horizontal Scaling Strategy

• what Advanced Features should be installed or not

• Environment name

• Display Name

• destination Region if several are available

and click on Install.

Once the deployment is finished, you’ll see an appropriate success pop-up with access credentials to your administration WordPress panel, whilst the same information will be duplicated to your email box.

So now you can just click on the Open in browser button within the shown frame and start filling your highly available and reliable WP installation with the required content, being ready to handle as much users as your service requires.

Note: Keep in mind that you can't do redeploy from previous WordPress Cluster edition to the new version. So in case you have decided to move your site to the WordPress Cluster v2 you should migrate it following the Tutorial "How to Migrate a WordPress Site to Jelastic PaaS or any other one you prefer.

WordPress Managed Hosting Business

To start offering this solution to your customers please follow to Auto-Scalable Clusters for Managed Cloud Business

wordpress-cluster's Issues

Would it be possible to update the stack to latest versions when auto deploying in Jelastic

Hi,

I've noticed when I auto-deployed Wordpress Cluster in Jelastic There are all nodes on old versions.
Load balancer OLD Version Nginx 1.10.1 should be latest 1.14.2
AppServer OLD Version Nginx 1.10.1 should be latest 1.14.2-php-7.3.0
MySQL OLD Version MySQL 5.7.19 should be latest 8.0.13

I tried to deploy manually MySQL 8.13 to Wordpress Cluster Environment, but it will destroy all WP install.

Would it be possible to update the stack configuration to the latest versions, so that, there is no need to to do it manually?

Thank you

keepalive_timeout issue

Any idea why there would be a constant issue with keepalive_timeout? I have been battling with this for days and absolutely nothing I have tried is working.

I just keep on getting the same error spamming my logfiles

client 192.168.1.101 closed keepalive connection
How does one fix this?
And it would be great if this mysql could be updated to v8.0.13 - I tried to edit the manifest.jps file and imported from local file and it failed

Nginx configuration not copied on horizontal scale

Hi,
I'm using a Wordpress cluster env with a WP in multi-site mode.
For the multi-site to work, I modified the configuration of nginx on the App servers.
But when a new app server is added, it doesn't take the custom configuration of nginx, resulting to 404 errors at the worst moments.
Is there a way to copy the nginx config on the new app server ? Using an add-on manifest ?

403 error when setting permalinks to symlinks

Hi, as the title says, this image gives a hard 403 error if you change the permalink structure from the default to eg "post name"

Repro: wp-admin -> Settings -> Permalinks -> Set to 'post name'.

Are there any workarounds for this at present?

Server not working reliably after changing document root

I'm trying to use this template with a custom document root.
Instead of using $VH_ROOT/ROOT/, I want to use $VH_ROOT/ROOT/current/public/

My configuration works for a moment, but after a few minutes, the server tries to load files from $VH_ROOT/ROOT/ instead of $VH_ROOT/ROOT/current/public/ without any changes in the configuration.

When I redeploy the load balancers and the the application servers, I works again.

Here's what I did to change the document root:

In LiteSpeedWEB Server, the virtual host root has been updated

• Virtual Hosts → General → Virtual Host Root : $VH_ROOT/ROOT/current/public/
• Virtual Hosts Templates → PHP_SuEXEC → General → Virtual Host Root $VH_ROOT/ROOT/current/public/
• Virtual Hosts Templates → centralConfigLog → General → Virtual Host Root $VH_ROOT/ROOT/current/public/

In /home/litespeed/bin/setupWP.sh, the following constant value has been updated
SERVER_WEBROOT=/var/www/webroot/ROOT/current/public/

In /etc/jelastic/redeploy.conf, the following path were added:

• /home/litespeed/bin/setupWP.sh
• /usr/local/lsws/lsphp/etc/php.ini
• /var/www/conf/vhconf.xml

Did I miss something?

—

Update : I have found that one of the vhconf.xml kept the default value for the document root. After having changed the value manually in this file all web servers use the desired document root.

Random disconnection on admin dashboard

Hi,
I've some headache trying to fix a strange bug: I have installed an existent Wordpress in a cluster env (from the marketplace) on hidora.com. But when I log in on the admin dashboard (/wp-admin), I am randomly disconnected and redirected to the login page, saying that my session has expired. The disconnection happened in ~10-15s when I try to acces to an admin page or I stay a few moment without activity.

This not happened with the same installation of Wordpress in a simple env with one app server and no load balancer.

This is what I tried:

• Check if sticky session works with load balancers : one user is always redirected to the same app serveur instance
• Update timezone on app servers & load balancers
• Check timezone and cookie expiration (I'm in timezone GMT+1, Switzerland)
• Check every URL in WP settings
• Disable all extensions
• Clear cache and cookies in the browser

But nothing help. An idea of the problem ?

Import existing WP (multisite) setup?

Not sure if these 'issues' are being monitored, but is it possible to use this setup and import and existing Wordpress multisite setup to it?

Regards.

MySQL with Orchestrator and ProxySQL seems to get out of sync

This is weird.

You introduced ProxySQL + orchestrator into the setup, yet, the wordpress connects via hosts file entry to one MySQL server only, leaving out orchestrator...

from wp-config.php on both nginx nodes:

/** MySQL hostname */
define( 'DB_HOST', 'DB_1' );

From /etc/hosts file on both nginx nodes:

bash-4.2# cat /etc/hosts
x.x.x.x DB_1 db_1
y.y.y.y DB_2 db_2

This poses several issues:

1. unnecessary cost coming out of the fact, there's additional, not used node.
2. problems with writing into the database - both nginx services want to write to one, and this can cause problems with writes, breaking replication.

You should either:

1. make sure Wordpress connects through proxysql, not directly to 1 node
2. get rid of orchestrator and set up the database connection in a more proper way, e.g. using haproxy or proxysql installed on nginx nodes?