This document has been created as an example of setting up a high availability Mendix Runtime Server environment on Windows, using the Microsoft Azure cloud platform. You will probably need to adapt this to your situation, as this guide is meant to illustrate what Mendix system and settings to take into account, and is not a complete guide or a supported ‘best practice’ for deploying a Mendix hosting environment. It describes the installation and configuration of the Mendix software on multiple systems running Microsoft Windows on the Microsoft Azure cloud platform and covers:
Setting up an Azure Load Balancer
Deploying a Mendix app with master and slave nodes
Configuring Azure Blob Storage as shared storage
Basic knowledge of administering Microsoft Azure and Windows servers
An active Azure subscription
Two or more servers, configured as described in the Deploy Mendix on Microsoft Windows guide. Make sure these servers have an extra data disk added which you configure to use as the location of apps and server files in the Mendix Service Console preferences.
An Azure admin account with sufficient permissions to create or modify:
3 Configure cluster slave nodes
In a clustered environment there are some tasks (for example, cleaning up expired user sessions from the database) that should only be handled by one of the cluster members. By default, each Mendix app server will execute these tasks, which can lead to issues. Ensure that only one server executes these tasks by adding the Custom Mendix setting com.mendix.core.isClusterSlave and setting it to true for all servers except one. So if you have a two server cluster, add this setting for one server and if you have five servers in your cluster, add it for four of them.
- Select your app and click Configuration.
- In the Configuration screen, click Advanced….
- In the Advanced screen add a line to Custom Mendix Settings with Name com.mendix.core.isClusterSlave and Value true.
- Click Close on both screens to return to the Service Console.
More information on the cluster leader and slave roles can be found in the Cluster Leader & Cluster Slaves section of Clustered Mendix Runtime.
4 Configuring the Azure Load Balancer
The exact configuration details of the load balancer will depend on your network environment and availability demands. The Mendix Runtime does not require sticky sessions. Make sure you have configured health probes for HTTP (port 80) and HTTPS (port 443), a back-end pool containing all your Mendix application servers, and load balancing rules to forward ports 80 and 443 to the servers in the back-end pool using the corresponding health probe. More information regarding the configuration of Azure Load Balancers is available in the Microsoft Azure documentation.
5 Configuring Azure Blob Storage as shared storage
Go to the Azure Portal to retrieve the Azure Storage account name and an access key:
Then select your application, click Configuration and then Advanced…. In the Advanced Settings screen, add the following Custom Mendix settings:
Name: com.mendix.core.StorageService, Value:
Name: com.mendix.storage.azure.AccountName, Value:
<your Azure Storage account name>
Name: com.mendix.storage.azure.AccountKey, Value:
<your Azure Storage access key>
Name: com.mendix.storage.azure.Container, Value:
<the Azure Storage blob container>
By default, the container will be created in the blob storage if it does not yet exist. More information about the configuration options for Azure Blob Storage in the Mendix Runtime is available in the Microsoft Azure Blob Storage Settings section of Runtime Customization.
It is also strongly recommended to add the setting com.mendix.storage.PerformDeleteFromStorage with value
false. This prevents the runtime from deleting files from the underlying storage when they are deleted in the app, which can result in missing files when restoring a database back-up.
If you do not want to enable this setting, make sure you have a restore strategy configured for your storage backend.
These settings have to be configured on all servers in the cluster.
Please note that, when using an Azure SQL database for your deployment, it is recommended you use either Premium (DTU-based model) or Business Critical (vCore-based model). Otherwise, the latency of the database affect the performance of your application. Also, keep in mind that each published application needs its own database! More information on database requirements can be found here: Databases