High Availability / Disaster Recovery Plan

Today let's discuss about high availability (HA) or more precisely disaster recovery plan (DRP).

As with any system, downtime can have major consequences for businesses. This quick article simply discuss two ways of achieving HA for ProActive.

Overall architecture

There are multiple ways for ProActive to be configured for High Availability (HA) / Disaster Recovery Plan (DRP).

• ProActive stores its state within a database and includes an abstraction layer to configure the connection to a database. By default, the database is embedded within the ProActive folder. The objective is consequently to connect ProActive to a HA database (e.g. MariaDb can be configured this way, AWS RDS, ...)
• The state being stored in an external database, it is important to monitor the behavior of ProActive. If it does not respond, it can be restarted which will then restart the scheduler, the diverse interfaces and connect to the database.

Below are two simple examples.

On AWS

• As explained above, the first step is to connect to AWS RDS.
• On AWS, create an autoscaling group of min 1 and maximum 1 with a simple script to detect a failing service. An AWS image will have to be attached to this group. This will enable AWS to restart an instance and start the scheduler as soon as it does not respond properly.
• Finally, an Elastic Load Balancing system will have to be configure to enable ProActive to be reachable at the same IP.

With Kubernetes

• With Kubernetes, a HA database will have to be configure. Multiple solutions are available using containers.
• In this example, Kubernetes will handle the HA like any other service. The admin will have to configure a pod containing a ProActive container with the relevant configuration and setup the number of replica set expected. In our example this would be of one.
• Finally, Kubernetes will be configured to route the traffic to this pod.

As an example, this is the approach used for our own production processes.