Load balancing nodes configuration (3 Craft nodes behind F5 Big-IP) Craft deployed and working well on one node.  Now looking into load balancing 3 nodes behind a LTM device (F5 Big-IP).  The server environment is the following:


a GlusterFS replicated "shared" file-system mounted on the 3 nodes
Craft app is installed in the shared file-system (so is the webroot and all common files, but Craft itself is outside of the webroot).
a replicated MySQL database cluster hosting the Craft database (Percona xtraDB Cluster)
Each node is configured with PHP ZendOpcache and Nginx.


Currently, Craft Vhost is enabled only on one node because I have the following questions:


What should I do with the "storage" folder.  Currently, it's on the shared file-system, so all the node share the same folder, is this an issue, i.e. should I move it to a local file system and set CRAFT_STORAGE_PATH accordingly?
overridePhpSessionLocation: I set to true (so it does not write to 'storage/runtime/sessions'
CacheMethod, is this for OPcaching or user data caching?  (Currently ZendOpcache is configured at the PHP level, but I still see entries in the storage/runtime/cache folder)


Any pitfalls I should be aware or specific configuration needed for a load-balanced set of Craft instances?

Thanks.
Update:

Am I allowed to change my mind on this? :)

My original answer didn't take into account storage/logo, storage/backups and anything else that a plugin might be storing in the craft/storage folder.

So it's probably going to be much cleaner and safer to have CRAFT_STORAGE_PATH point to the shared file system.




I would set CRAFT_STORAGE_PATH and have them write to their local file systems.  That way you have independent logs for each web server.
With that set to 'true', the PHP session files will go to whether PHP/nginx are configured to send them.
The cacheMethod config setting it purely for data caching. It's set to 'file' by default which will write to craft/storage/runtime/cache, but you can change that to some other caching method.


Actually, if you do #1, then 2 and 3 would resolve themselves, no? You'd want to make sure that your load balancer has stick sessions enabled so that a user would get sent to the same web server for subsequent requests.