9

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:

  1. 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?
  2. overridePhpSessionLocation: I set to true (so it does not write to 'storage/runtime/sessions'
  3. 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.

5

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.


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

  2. With that set to 'true', the PHP session files will go to whether PHP/nginx are configured to send them.

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

10
  • Thank Brad. After moving CRAFT_STORAGE_PATH, Should I keep storage/userphotos on the shared fs i.e. using a symbolic link, or does a variable exists that can override its location? – Mathieu P. Nov 13 '14 at 23:52
  • No variable current exists for that, so you'd probably need to symlink it. – Brad Bell Nov 13 '14 at 23:55
  • Hi Brad, I ended up leaving CRAFT_STORAGE_PATH to the shared file system but moved / sym-liked the "runtime" sub-folder to a node local partition. This leaves all other storage sub-folders, i.e. backups, userphotos, logo and any plugin created folders on the shared file system. So far so good. – Mathieu P. Jan 22 '15 at 22:44
  • A bit confused by @BradBell's answer...I'm not seeing CRAFT_STORAGE_RUNTIME as defined constant at all. "So it's probably going to be much cleaner and safer to have CRAFT_STORAGE_RUNTIME point to the shared file system." seems to contradict with "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." – Tim Kelty Jan 11 '17 at 16:32
  • @TimKelty Sorry, typo. Should have been CRAFT_STORAGE_PATH. – Brad Bell Jan 11 '17 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.