Experiences using clustering with eZ publish 3.8

ez Publish version 3.8 introduced a specialised clustering functionality that allowed for the storage of all content related caches, images and binary files in the database. All other files are stored on the local file systems.

This is a great improvement over previous versions of eZ Publish that did not include any specific clustering support.

In a recent install we utilised the clustering functionality and found a number of issues that are not highlighted in any of the documentation.

In our setup there are 2 web servers. Both systems serve the site while one was designated the "master" and used for administration.

Our design uses the toolbar functionality to allow editors to add and update content that appears in a right hand column.

Synchronisation of toolbar.ini files from the mater server to the slave is performed using rsync.

After a while inconsistencies in the display of toolbar content was noticed. In tracking this down it was discovered that the toolbar parameters are written to the compiled templates:

The toolbar.ini files were check and verified to be in sync. Examination of the compiled pagelayout templates on both servers reviled that only the master had the updated toolbar information.

When toolbars are updated via the admin the compiled templates for pagelayout.tpl are cleared. Due to the fact that admin is accessed via one system and the compiled templates are stored on the local file system only the compiled templates on the master are cleared and recompiled with the new toolbar data.

To solve this problem we've started rsyncing the compiled templates from the master to the slaves. I'm not convinced that this is the ideal solution and am interested in any ideas of how this issue could be addressed.

This issue highlighted the fact that when clearing the cache via the admin, for files stored on the file system, only the master system will be cleared. This may result in systems losing synchronisation.

There are a number of functions that can be performed via the admin interface that will result in synchronisation issues. At the very least these need to be highlighted in the documentation.

The clustering functionality introduced in eZ publish 3.8 is a large step forward in options in previous versions. However until there is a solution for cleanly dealing with dynamic files that are stored on the filesystem the solution is not complete.

Comments

This might help: ezini( 'BlockName', 'SettingName', 'FileName', 'IniPath', 'Dynamic fetch: if 'true()' value of variable will be fetched dynamically', 'Check for existence: if 'hasVariable' or true() and if the variable exists true will be returned, false otherwise')

In the preface to the current Admin interface specification the last paragraph caught my eye:A overview of user task need a dashboard, where she can follow here own content, approval and other tasks she might do on a regular basis.I recently saw a demo of the latest version of the bug tracking system JIRA 4.0 by Atlassian. It used an OpenSocial dashboard to allow users to customise their homepage to access and interact with information that was important to them. The system not only displays JIRA widgets but any OpenSocial widgets (and those from other Atlassian products). You can check out a video of it in action here and more information on how Atlassian is using OpenSocial here.

What is OpenSocial? From the official site:OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML,
developers can create apps that access a social network's friends and update feeds. Google personal home page is an example of an OpenSocial da…

The following presentation was given on 24 July 2012 to the DevOps Brisbane group. Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.