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.
The MDM cluster with load balancing and high availability
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 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 Nginx or HAProxy.
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.
Using multiple web servers may require maintaining a single (shared) file storage, so each node could provide file and application download services.
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 overloads and congestions, it is recommended to manage the speed of sending Push notifications. Headwind MDM allows the admin to specify the delay between Push notifications in milliseconds. Specifying the delay of 1 – 10 ms leads to a good performance and avoids 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.
