YMC uses an alternative strategy for clustering eZ Publish. Have a look at
http://www.ymc.ch/weblog/some_due_modifications_to_the_ez_cluster Please ask my collegue Daniel Beyer for technical details.
For clustering mode with lots of "static" content (I presume you mean pdf, images, ...), a new cluster handler is available in trunk (hence will be part of ez publish 4.2, release end of september).
This uses NFS (or any distributed file system like GFS, ..) as a transport between cluster nodes. The caches are still served by each node individually from a local storage.
The meta data on whether files are expired and so, is handled by a DB layer to avoid latencies and subsequent cache inconsistencies
Best practices for using NFS mounts and clusters of web servers with eZ Publish are:
- get a hardware-based NFS server, not a linux-based pc (eg. emc, netapp, hp, etc...)
- make sure locking-over-nfs has been enabled
- have somebody in-house knowledgeable about nfs setup and tuning
- minimize the usage of files over nfs shares as much as you can, since eZ Publish will generate a big amount of nfs calls (nb: nfs calls != bandwidth) for dealing with cache
That might include:
-- store ezp files and settings locally, use rsync to deploy them -- store ezp (and apache) log files locally, use simlynks to get a working setup
Principal Consultant International Business
Member of the Community Project Board
NFS versions up to 3 by default does not support locking - it was not built into the protocol.
You can overcome this limitation by usage of external locking mechanisms, and yes, it might be enabled or disabled. Or you can use nfs 4, which has locking built in. But the hw/os will usually dictate the version of nfs you can use.
http://nfs.sourceforge.net/ is a good source of nfs information.
About sharing the complete eZP install or not: ymmv.
Knowing that nfs traffic can easily become the bottleneck in such a configuration, I'd play it safe and try to limit the number of files mounted over nfs to the strict minimum. But you might prefer a simplified administration/deployment scheme instead. If you can afford it, test your setup by executing the 'worst case scenario': delete the complete cache dirs (by hand: real cold hard delete) while using ab to simulate the peak load moment of your site.
Principal Consultant International Business
Member of the Community Project Board
The above observations in the post by Gaetano are not relevant for the new nfs/dfs cluster system introduced in eZ Publish 4.2 (and installed with success for very large media sites as a backport to previous versions)
In the new cluster handler, NFS based locking is not used at all and it will work with other distributed file systems too. File meta-data is handled in a dedicated DB table instead.
The basic idea implemented is that NFS is used as a transport for cache files, images, .... between cluster nodes. The cluster nodes still serve the files from their local file system.