|
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
|