Install mosparo with high availability

[raul810y]

Hi

Any consideration to install Mosparo in high availability?

For example, I want to install mosparo in some nodes with load balancer, but I don't know if:

1. Do I need an NFS with necessary data if another node responds on a second request?
2. Do I need configure sticky session or doesn't matter (in terms of functionality of Mosparo)?

Thanks for advance

[zepich]

Hi @raul810y

Thank you very much for your question.

While developing mosparo, we've made some performance tests with a load balancer and multiple nodes to ensure we do not have a problem with such a setup (performance-wise in the frontend). These tests were generally successful, but it was just the frontend, not the backend. After releasing mosparo to the public, we received some contributions to enhance problems with such a setup. The most important one was to store the sessions in the database instead of the file system.

Directories and files

The most important thing for a multi-node setup with a load balancer is to synchronize or share some files between the nodes. The used paths are:

• config/env.mosparo.php (main configuration file, required)
• public/resources (contains the prepared frontend CSS files) (required, but read below)
• var/data/geoip2 (contains the GeoIP2 database, if enabled, optional, otherwise, every node needs to download the database)
• var/data/import (contains the uploaded files for the import functionality, to use the function, this directory must be synchronized, or a sticky session is required)

The public/resources directory

As soon as you store the design settings of a project in mosparo, mosparo prepares the CSS file for the frontend with a unique URL to force browsers to redownload the CSS file (cache busting).

If you do not synchronize this directory between the nodes, the nodes will have different prepared CSS files and respond with different content.

But if you have only one or two websites for which you want to use mosparo, you do not even have to load the CSS file from mosparo directly. Instead, you could simply copy the CSS file content from one of the nodes and store it directly in the code of your website. You have to update that file after an update of mosparo or after changing the design settings of a project, but other than that, you will not have any negative effects.

While writing this answer, I started to think about this automatic generation of the CSS file, and I decided to add an environment variable to turn off the preparation of the CSS file, so synchronizing the files is not required anymore in mosparo v1.3.0+ if you enable the environment variable. If the CSS file does not exist, mosparo will generate the required CSS code on the fly so that the browser will receive the CSS content anyway. Using the cached CSS file is, of course, faster because it does not involve PHP, but for a multi-node setup, it's maybe the cheaper option. (see #287)

Sticky sessions

As written above, because mosparo stores the sessions in the database, sticky sessions are not required, except for the import functionality to import the settings of a project (or you can share the files of the var/data/import directory and then you do not need the sticky sessions). You do not need sticky sessions if you do not want to use the import functionality.

I will start a new discussion about this part in the list of ideas because solving this differently would be a good idea and eliminate one additional path to synchronize.

Cleanup process

With #284, we received the suggestion to optimize the caching adapter for the cleanup system. These optimizations will be released with v1.3.0 and allow you to use a shared cache like Redis or Memcached, especially in a Docker or multi-node setup. This is mainly used to ensure that only one of your nodes is executing the cleanup process.

Summary

If you have a solution to keep the files synchronized (NFS or some file synchronization tool), then mosparo should work without any problem. Sticks sessions are not required, except for the import functionality (if you do not want to or can't share the var/data/import directory).

Please let me know if you have any questions or need more information. We also look forward to hearing about your experience with such a setup and mosparo and what we can optimize.

Kind regards,

zepich

[raul810y]

Thanks for your reply!

Regarding the files that are created dynamically and need to be synchronized between nodes, I will use an NFS to have them shared and ready to use.

I will also enable sticky session to ensure that it is always the same node that responds and not have to do anything additional for the import functionality.

In my opinion, new ideas for future versions will definitely help to facilitate the configuration in balanced environments. From my point of view, it may not be necessary to sacrifice performance (like removing the creation of the stylesheet and saving it in the filesystem), but instead to have perhaps just one folder in the filesystem that contains all the dynamic files that the application generates and can be easily configured to be synchronized or shared between nodes (with NFS or some other solution).

If I find any problems with these configurations, I will comment on this post later.

[zepich]

Hi @raul810y

Thank you very much for your response and your suggestion.

Putting everything into one place is (probably) not easily possible without breaking backward compatibility. But we can add some environment variables with which you could define the directories in which the files should be stored. So, by default, mosparo uses the same directories/locations as it does now. If you want them in a different directory, you can set the environment variables (one for every file/path) and define a path somewhere else on your server where all files are stored. I will create an idea post for a future version of mosparo.

Kind regards,

zepich