Deploying the MDM cluster

A single instance of Headwind MDM installed on a recommended virtual machine may get the performance issues while hosting more than few thousands of mobile devices.

Before diving deep into the cluster development, consider these optimization hints which may improve the performance on a single server.

The performance may be improved by deploying the software components to different virtual machines forming a cluster.

Headwind MDM Enterprise can be clusterized and scaled to manage up to hundreds of thousands of mobile devices.

Separating the database

The first step of the clusterization is to deploy the PostgreSQL database on a dedicated virtual machine. Many cloud hosting providers propose “managed database” services. If you don’t have the DB management expertise and don’t want to bother for the database engine optimization, you may prefer using managed database to host Headwind MDM.

Push messaging broker and remote control module

The recommended option for a push notification server in a cluster is HTTP Polling (a persistent connection with the server over HTTPS).

If you still wish to use MQTT for push notifications delivery (for example, for performance reasons), the Enterprise license allows the admin to use the external Push messaging broker (the ActiveMQ Classic MQTT server).

If your license includes the remote control module, it is recommended to deploy it on a separate VM having a separate domain name.

Reverse proxy and load balancing

A “reverse proxy” is a high performance gateway optimizing access to the application server (Tomcat) and caching static resources (images, style sheets, scripts).

As a reverse proxy, you can set up HAProxy (recommended) or Nginx.

Both software modules support load balancing, so you could clone the application server to multiple virtual machines (nodes), distribute the load among the nodes, and prioritize nodes according to their availability and performance.

If your version of Headwind MDM doesn’t support database sessions, use the “sticky sessions” load balancing algorithm. Headwind MDM v7 supports database-stored sessions, so you can use round-robin for balancing.

Shared file storage

Using multiple web servers may require maintaining a single (shared) file storage, so each node could provide file and application download services.

We recommend using a special directory (for example, /var/lib/tomcat9/hmdm) hosted by a dedicated NFS server.

Managing loads and congestions

Updating multiple devices at once may cause peak loads when all devices connect to the server and download updates at the same time.

To avoid congestions when all the fleet requests updates at the same time, we recommend to set up Push message throttling. The delay of 1 – 10 ms between subsequent Push messages is optimal for getting good performance and preventing congestions.

High availability

High Availability is a complex approach, including absence of the Single Point of Failure (SPoF). To achieve this, you may need to duplicate the critical servers by using the Active-Standby architecture. We recommend using Linux-HA utility.

Database clustering

Whereas managed database services often include high availability and load balancing, you may decide to clusterize the database yourself. There are many instructions on how to set up a PostgreSQL database cluster. We recommend using the Pgpool clustering utility.

System monitoring

The whole cluster should be properly monitored, to notify the admin about possible failures. The following points of failure must be monitored:

• CPU usage
• Storage usage
• Availability of each node
• Active-standby node failovers
• HTTP protocol responses

The most of the cluster failures could be automatically recovered. Nevertheless, the automatically recovered issues should be reported.

As a monitoring tool, we recommend using Nagios.

Network usage diagram

This diagram describes the typical deployment of Headwind MDM, servers and communication ports. Without additional clusterization efforts, Headwind MDM can be deployed on up to 4 virtual machines.

We recommend to use this diagram before the deployment, to make sure all required ports are open.