| title | category | space |
|---|---|---|
Architecture Options |
On-premises Deployment |
Mendix 5 How-to's |
When designing your server architecture there are an infinite number of possibilities in how you want to setup your environment. There isn't really a right or wrong configuration, it depends on what your requirements are on security, availability and performance.
The options below are just a few examples of the most commonly used architectures. The Mendix Cloud uses a (more complex) architecture based on option 2 without a separate file server(4), and with a proxy server(1) to redirect the traffic to the correct environment.
Simplest solution with the least configuration and connection problems. This configuration is used in the Mendix cloud as well, except the cloud is linux based, with nginx instead of IIS and postgresql as database server.
_
_
_This option is hardest to maintain, every update has to be performed twice. Once on your application server as normal, but after an update you have to replicate all static content to the webserver as well. This means you have to copy the contents of the web folder (including mxclientsystem) to the webserver every time you do an update. This is an option that should be avoided. _
_
_
The platform can handle a load balancer in front of the platform. The only additional requirement is that the load balancer uses sticky sessions. When a problem occurs on a single instance, the only thing an active user could lose is the data he is working on. Everything that was only available in the memory of the failed instance will be gone. All the stored data will still be available for the user. When updating the application, it is best to stop every instance. If the database structure has changed, and a single instance updates the database structure it could cause some strange behavior on all running instances since they are still expecting the old database structure.
For more information please see the How to page on High availability