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.
For more info on clustering in eZ publish 3.8 see:
http://ez.no/community/articles/clustering_in_ez_publish_3_8/
http://ez.no/doc/ez_publish/technical_manual/3_8/features/clustering
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:
$vars[$currentNamespace]['display_node'] = '3600';
$vars[$currentNamespace]['tool_id'] = 'Tool_homerow1_home_promo_1';
$vars[$currentNamespace]['offset'] = 1;
$vars[$currentNamespace]['first'] = true;
$vars[$currentNamespace]['last'] = false;
$vars[$currentNamespace]['placement'] = 'first';
if ( !isset( $dKeys ) )
{
$resH =& $tpl->resourceHandler( "design" );
$dKeys =& $resH->keys();
}
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.
For more info on clustering in eZ publish 3.8 see:
http://ez.no/community/articles/clustering_in_ez_publish_3_8/
http://ez.no/doc/ez_publish/technical_manual/3_8/features/clustering
This might help:
ReplyDeleteezini( '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')
http://pubsvn.ez.no/viewcvs/ezp/trunk/doc/features/3.9/added_away_to_check_existence_of_var_in_ezini_or_ezhttp.txt?rev=17117&view=markup