Distributed/balanced installation?

Next topic

Author	Message
Nico Sabbi	Wednesday 25 June 2008 8:52:35 am Hi, I setup Ezpublish 4.0.0 in a distributed environment: EZ is installed on 4 different web servers (Linux RH3) in a NFS directory imported from a Solaris server. The DBMS used is a separate Linux server running Mysql. Web requests are intercepted by a web balancer that dispatches them to one of the four servers. So far so good, until I realized that the access to the hundreds of files in the cache (in NFS) was extremely slow. At this point I worked around the problem symlinking the cache directory in var/<SITE> to a local directory in each of the four servers, but apparently the balanced web site doesn't work correctly: an update to the contents of the DB isn't immediately reflected by the four web servers. Additionally the admin interface doesn't work correctly in my balanced configuration: often, after having signed up, I'm suddenly logged off. Is a configuration like this even supported? What kind of balancement can I obtain with EZ? Thanks, Nico
Gaetano Giunta	Wednesday 25 June 2008 2:13:36 pm You have basically a couple of choices when setting up an install using multiple frontends: A - share the var dir between all the servers via any shared-storage filesystem this usually means a "good" nfs server, eg. emc or netapp nas box, or a san box plus ocfs2 or gfs. Using a vanilla linux server with nfs is not going to cut it, as eZ Publish generates a massive amount of IO to files in the var directory. Most of the times, some nfs tuning is needed. You also have to make sure you are using nfs with locking. If you set this up, I would recommend to keep the var/log and var/siteaccess/log directories separate for every front server (using symlinks) B - set up the eZ Publish "cluster" mode. this means setting up a separate db, or a couple of new tables in the existing db, and moving all the content of the var directory in the db. Make sure the db you will be using has enough spare power to handle the new load (depending on chosen db you can usually set up some replication / clustering within the db to spread the load within more boxes). The script to move from standard to clusterized conf is very easy to run and pretty safe to test. C - set up your own "replication" of the var/storage and var/siteaccess/storage directories, usually using rsync. This way you will be creating binary content on one server, and it will propagate to the others. It gets tricky as soon as you have many files in the var dir and rsync takes a while to propagate changes. If the load balancers are not sticky, a user might see content on page a on server 1, then go to page a on server 2 and miss the content that has not yet been replicated. If the load balancer is sticky every user is kept going to the same physical server, so this risk is minimized. In every case, it is better if the eZ Publish cronjobs are run on a single server, possibly a dedicated one, so that ram and cpu used for the cronjobs are not subtracted from the frontends. If you are using one frontend for admin siteaccess only, that would be the ideal candidate. About the logging-in problem: eZ Publish stores session data in the db, so even when load balancers are not sticky you should not have any troubles. Can you check the traces of the lb to see if there is any misconfiguration? Principal Consultant International Business Member of the Community Project Board

Author

Message

Wednesday 25 June 2008 8:52:35 am

Hi,
I setup Ezpublish 4.0.0 in a distributed environment: EZ is installed on 4 different
web servers (Linux RH3) in a NFS directory imported from a Solaris server.
The DBMS used is a separate Linux server running Mysql.

Web requests are intercepted by a web balancer that dispatches them
to one of the four servers.

So far so good, until I realized that the access to the hundreds of files in the cache
(in NFS) was extremely slow. At this point I worked around the problem symlinking
the cache directory in var/<SITE> to a local directory in each of the four servers,
but apparently the balanced web site doesn't work correctly: an update to the
contents of the DB isn't immediately reflected by the four web servers.

Additionally the admin interface doesn't work correctly in my balanced
configuration: often, after having signed up, I'm suddenly logged off.

Is a configuration like this even supported?
What kind of balancement can I obtain with EZ?
Thanks,
Nico

Gaetano Giunta

Wednesday 25 June 2008 2:13:36 pm

You have basically a couple of choices when setting up an install using multiple frontends:

A - share the var dir between all the servers via any shared-storage filesystem
this usually means a "good" nfs server, eg. emc or netapp nas box, or a san box plus ocfs2 or gfs. Using a vanilla linux server with nfs is not going to cut it, as eZ Publish generates a massive amount of IO to files in the var directory. Most of the times, some nfs tuning is needed. You also have to make sure you are using nfs with locking.
If you set this up, I would recommend to keep the var/log and var/siteaccess/log directories separate for every front server (using symlinks)

B - set up the eZ Publish "cluster" mode.
this means setting up a separate db, or a couple of new tables in the existing db, and moving all the content of the var directory in the db. Make sure the db you will be using has enough spare power to handle the new load (depending on chosen db you can usually set up some replication / clustering within the db to spread the load within more boxes).
The script to move from standard to clusterized conf is very easy to run and pretty safe to test.

C - set up your own "replication" of the var/storage and var/siteaccess/storage directories, usually using rsync.
This way you will be creating binary content on one server, and it will propagate to the others. It gets tricky as soon as you have many files in the var dir and rsync takes a while to propagate changes. If the load balancers are not sticky, a user might see content on page a on server 1, then go to page a on server 2 and miss the content that has not yet been replicated. If the load balancer is sticky every user is kept going to the same physical server, so this risk is minimized.

In every case, it is better if the eZ Publish cronjobs are run on a single server, possibly a dedicated one, so that ram and cpu used for the cronjobs are not subtracted from the frontends. If you are using one frontend for admin siteaccess only, that would be the ideal candidate.

About the logging-in problem: eZ Publish stores session data in the db, so even when load balancers are not sticky you should not have any troubles. Can you check the traces of the lb to see if there is any misconfiguration?

Principal Consultant International Business
Member of the Community Project Board

eZ debug

Timing:	Jan 18 2025 16:27:13
Script start
Timing:	Jan 18 2025 16:27:13
Module start 'layout'
Timing:	Jan 18 2025 16:27:13
Module start 'content'
Timing:	Jan 18 2025 16:27:14
Module end 'content'
Timing:	Jan 18 2025 16:27:14
Script end

Main resources:

Total runtime	0.6896 sec
Peak memory usage	4,096.0000 KB
Database Queries	54

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0059	588.0391	152.6406
Module start 'layout'	0.0059	0.0026	740.6797	39.4766
Module start 'content'	0.0085	0.6794	780.1563	537.2734
Module end 'content'	0.6879	0.0016	1,317.4297	12.1406
Script end	0.6895		1,329.5703

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0036	0.5287	16	0.0002
Check MTime	0.0014	0.2059	16	0.0001
Mysql Total
Database connection	0.0005	0.0751	1	0.0005
Mysqli_queries	0.6426	93.1843	54	0.0119
Looping result	0.0004	0.0647	52	0.0000
Template Total	0.6618	96.0	2	0.3309
Template load	0.0019	0.2800	2	0.0010
Template processing	0.6599	95.6936	2	0.3299
Template load and register function	0.0001	0.0207	1	0.0001
states
state_id_array	0.0009	0.1289	1	0.0009
state_identifier_array	0.0006	0.0864	2	0.0003
Override
Cache load	0.0016	0.2303	33	0.0000
Sytem overhead
Fetch class attribute can translate value	0.0005	0.0705	2	0.0002
Fetch class attribute name	0.0010	0.1385	3	0.0003
XML
Image XML parsing	0.0005	0.0700	2	0.0002
class_abstraction
Instantiating content class attribute	0.0000	0.0010	3	0.0000
General
dbfile	0.0008	0.1093	16	0.0000
String conversion	0.0000	0.0010	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded
1	node/view/full.tpl	full/forum_topic.tpl	extension/sevenx/design/simple/override/templates/full/forum_topic.tpl
2	content/datatype/view/ezxmltext.tpl	<No override>	extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tpl
8	content/datatype/view/ezxmltags/line.tpl	<No override>	design/standard/templates/content/datatype/view/ezxmltags/line.tpl
9	content/datatype/view/ezxmltags/paragraph.tpl	<No override>	extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tpl
1	content/datatype/view/ezimage.tpl	<No override>	extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tpl
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 22 Number of unique templates used: 6

Time used to render debug report: 0.0001 secs