ProcessMaker Load Balancing

Instead of trying to upgrade the hardware on your ProcessMaker server, it is recommended to use load balancing to scale up ProcessMaker to serve more users. The idea of load balancing is to redistribute the usage of memory and processing power among multiple servers so that an application like ProcessMaker can be accessed by more users than can be handled by a single server.

There are a number of ways to implement load balancing, but this guide will describe how to do it using a reverse proxy and the Apache mod_proxy_balancer module, which any organization or business can set up at a minimal cost. This guide describes how to set up a frontend server that receives the requests from the users and passes them along to multiple backend servers. Although only two backend servers are used in this guide, as many backend servers can be added as needed. This guide describes using a separate frontend server as the load balancer, however the frontend could also reside on the same machine as one of the backends to cut down on costs.

The setup

Steps

There will be one frontend server which will act as the load balancer to redirect traffic to several backend servers which will act as application servers. One of the backend servers will be the master, which contains the ProcessMaker application code. This code will be shared with the other backend servers, so that all the servers will run ProcessMaker from the same copy of the code.

The advantage of running all the backends from the same shared directory is that the cache files, form templates, uploaded files and generated files will never get out of sync; however, all the backends should be on a fast local network so they can quickly access the application code on the master server.

The steps required for setting up load balancing are:

1. Install ProcessMaker in the master server.
2. Copy installation files to other backends
3. Share ProcessMaker files in the network with the other backends, either using NFS in Linux/UNIX or Windows Shares in Windows.
4. Granting permission in MySQL for all the backend servers to connect to it in the local network.
5. Configure the frontend server to send web requests to multiple backend servers.
6. Add a cookie in the backends so that the same PHP session is always handled by the same backend, otherwise the user will keep getting disconnected.

Installing ProcessMaker on the Master Backend

Follow the standard procedure to install ProcessMaker on the server which will be the master backend, but when specifying the location of the database server, do not use a relative address like "localhost" or "127.0.0.1". Instead use the database server address as seen in the network (either the IP address or a qualified name in the network).

Your existing ProcessMaker server can be used as the master backend server, however when ProcessMaker was first installed, it had to be configured to connect to the MySQL database via a fixed IP address or domain name and not use a direction like "localhost" or "127.0.0.1". During the installation procedure ProcessMaker generates an encrypted hash with information about how to connect to the database.

Unfortunately, ProcessMaker doesn't currently provide a way to alter this hash. The only option is to backup your existing ProcessMaker workspaces, then do a fresh install of ProcessMaker in the master backend and restore the workspaces in the new installation. Make sure that the version of ProcessMaker is the same in both the old and new installations when doing backups and restores.

Copy files to other backends

Now copy the ProcessMaker installation files over to the different backends. This way each backend is accessing it's own local files of the ProcessMaker installation and it will only share the required files.

Login to the backend and copy the files from /opt/processmaker or the directory you installed ProcessMaker. For instance, in Linux you could use the rsync command:

rsync -avz <ROOT_USER>@<MASTER-IP>:<PROCESSMAKER-DIRECTORY> /opt

Do not include a backslash in the PROCESSMAKER-DIRECTORY, just like in /opt/processmaker. For instance, if master is at 192.168.1.10 and the ProcessMaker directory is /opt/processmaker:

rsync -avz root@192.168.1.10:/opt/processmaker /opt

Share ProcessMaker

This guide shows how to share the ProcessMaker files using NFS on Linux/UNIX servers, but other methods can also be used as well. For more information on configuring and managing NFS, see this guide for CentOS, this guide for Debian, or this general guide.

First of all, install the NFS server software on the master backend server (if it isn't already installed).
In Red Hat/CentOS:

yum install nfs-utils nfs-utils-lib portmap

In Debian/Ubuntu:

apt-get install nfs-kernel-server nfs-common portmap

Then, install the NFS client software on the other backend servers, which will need to access the files on the master server.
In Red Hat/CentOS:

yum install nfs-utils nfs-utils-lib portmap

In Debian/Ubuntu, install NFS client:

apt-get install nfs-common portmap

Once NFS is installed, go to the master backend server and export the shared directory where ProcessMaker is installed (which is generally the /opt/processmaker/shared directory) to the other backend server(s). Add the following line to /etc/exports on the master server to share the ProcessMaker directory with the other backend server(s):

<PROCESSMAKER-DIRECTORY>/shared <IP-ADDRESS>/255.255.255.0(rw,sync)

For example, if sharing the /opt/processmaker directory with another backend located at 192.168.1.25:

/opt/processmaker/shared 192.168.1.25/255.255.255.0(rw,sync)

To share the directory with all the computers in the 192.168.1.XXX network, then use 0 as the final number of the IP address:

/opt/processmaker/shared 192.168.1.0/255.255.255.0(rw,sync)

Even if just sharing the directory with just one other backend server, it is a good idea to specify a network rather than a single machine, because additional backend servers can be added in the future without reconfiguring NFS.

Then, restart the NFS server to use the new configuration in /etc/exports
In Red Hat/CentOS:

service nfs restart

In Debian/Ubuntu:

/etc/init.d/nfs restart

Then try mounting the NFS directory, to see if it works:

mount -t nfs <MASTER-IP>:<PROCESSMAKER-DIRECTORY>/shared <PROCESSMAKER-DIRECTORY>/shared

For example, if the master backend is located at 192.168.1.10 and ProcessMaker is installed at /opt/processmaker, then:

mount -t nfs 192.168.1.10:/opt/processmaker/shared /opt/processmaker/shared

In order to automatically mount the shared directory on the backend servers during bootup, add the following line to /etc/fstab:

<MASTER-IP>:<PROCESSMAKER-DIRECTORY>/shared  <PROCESSMAKER-DIRECTORY>/shared   nfs   intr,hard 0 0

For example:

192.168.1.10:/opt/processmaker/shared  /opt/processmaker/shared   nfs   intr,hard 0 0

Copy the ProcessMaker Apache configuration file pmos.conf from the master to the backends, changing the IP address of the master to the backend's IP address.

Then reload Apache and ProcessMaker should be running on the backends.

Granting permissions in MySQL

Now grant permissions for other computers to connect to the MySQL server. Log on as root or other administrative user to MySQL such as:

mysql -u root -p

Then execute the following command, replacing USER with the user configured for the ProcessMaker to connect and 192.168.1.% to your network IP address (the % symbol is used as a wildcard):

mysql> grant all on *.* to "USER"@"192.168.1.%" identified by "PASSWORD" with grant option;

Frontend

A frontend server must also have Apache installed. The frontend can either be on a separate server or it can be on the same machine as one of the backends--just make sure that ProcessMaker is running in a different port then the default port, so that the load balancer works at port 80.

Install Apache and create a new configuration file (for instance, in CentOS, create /etc/httpd/conf.d/proxy.conf):

ProxyPass / balancer://cluster/ lbmethod=byrequests stickysession=BALANCEID
ProxyPassReverse / balancer://cluster/
<Proxy balancer://cluster>
  BalancerMember http://<BACKEND-1> route=server1
  BalancerMember http://<BACKEND-2> route=server2
</Proxy>

Don't forget to change <BACKEND-1> and <BACKEND-2> to point to the backends' IP addresses. The stickysession parameter is very important and will be used below.

For more information about the mod_proxy_balancer, see the Apache manual.

Cookie to handle sessions

Sessions in PHP are handled by each of the backends, so in order to get it to work the same session must be handled by the same backend. This is important, otherwise the users will keep getting disconnected.

A cookie must then be set when the request in handled by a backend, so that each subsequent request is handled by the same server. However, this is only possible if the frontend machine has a domain name, because of the way cookies are handled. For more information see here.

On each of the backends, modify the pmos.conf configuration file in Apache and add the following lines after the <VirtualServer ..> line:

RewriteEngine On
RewriteRule .* - [CO=BALANCEID:balancer.serverX:FRONTEND-DOMAIN]

Change serverX to the server number, such as server1. And change FRONTEND-DOMAIN to the domain users will connect to the fronted.

Did it work?

To see if load balancing is working, check the error_log in the frontend (in CentOS it is located at /var/log/httpd/error_log). Debug verbosity of Apache can be increased so that you watch which requests are going to which servers, by changing the LogLevel in the Apache configuration file to debug mode:

LogLevel debug

Remember to change this back to a normal level in a production server.

If there are a lot of lines with proxy: BALANCER: Found value (null) for stickysession BALANCEID then the cookies are not set correctly and the frontend domain name might have been set up incorrectly.