Answers.Body: <p><strong>Update:</strong></p>
  
  <p>Am I allowed to change my mind on this? :)</p>
  
  <p>My original answer didn't take into account <code>storage/logo</code>, <code>storage/backups</code> and anything else that a plugin might be storing in the <code>craft/storage</code> folder.</p>
  
  <p>So it's probably going to be much cleaner and safer to have <code>CRAFT_STORAGE_PATH</code> point to the shared file system.</p>
  
  <hr>
  
  <ol>
  <li><p>I would set <code>CRAFT_STORAGE_PATH</code> and have them write to their local file systems.  That way you have independent logs for each web server.</p></li>
  <li><p>With that set to 'true', the PHP session files will go to whether PHP/nginx are configured to send them.</p></li>
  <li><p>The <a href="http://buildwithcraft.com/docs/config-settings#cacheMethod" rel="nofollow noreferrer">cacheMethod</a> config setting it purely for data caching. It's set to 'file' by default which will write to <code>craft/storage/runtime/cache</code>, but you can change that to some other caching method.</p></li>
  </ol>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-13T23:52:23.417Z
Answers.Text: 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?
Answers.UserDisplayName: Mathieu P.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-13T23:55:26.497Z
Answers.Text: No variable current exists for that, so you'd probably need to symlink it.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-22T22:44:59.580Z
Answers.Text: 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.
Answers.UserDisplayName: Mathieu P.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-11T16:32:34.370Z
Answers.Text: 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."_
Answers.UserDisplayName: Tim Kelty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-11T23:20:39.197Z
Answers.Text: @TimKelty Sorry, typo.  Should have been `CRAFT_STORAGE_PATH`.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T13:12:55.557Z
Answers.Text: @BradBell Ok, then which are you recommending (seems like you say both) `CRAFT_STORAGE_PATH` shared or independent?
Answers.UserDisplayName: Tim Kelty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T22:36:32.900Z
Answers.Text: @TimKelty Everything above the `<hr>` is my updated answer. `CRAFT_STORAGE_PATH` shared.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-16T13:43:00.687Z
Answers.Text: @BradBell OK, so with that setup, you wouldn't be able to have separate logs per-server though, right? Currently I have `CRAFT_STORAGE_PATH` shared between servers, but then `CRAFT_STORAGE_PATH`/runtime per-server (via relative symlink).
Answers.UserDisplayName: Tim Kelty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-17T14:54:41.357Z
Answers.Text: So I've found if I dedicate the runtime folder per-server, I end up with session/login trouble. Logins fail about 50% of the time (go figure, we have a 2 server LB). By "fail" I mean the cp login simply reloads on submit, no error.
  
  Once the login succeeds, sticky sessions are working fine, and the user stays logged in.
  
  If I make the runtime folder shared between servers, logins work fine, but we now don't have server-specific logs.
Answers.UserDisplayName: Tim Kelty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-27T15:24:08.057Z
Answers.Text: @TimKelty FWIW we had the dicey-login trouble on a load-balanced project and got around it by using Craft's `overridePhpSessionLocation` and pointing to a Redis (RDS) store instead.
Answers.UserDisplayName: Matt Stein
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-03-06T14:26:49.520Z
Answers.Text: @BradBell Is NFS share a requirement for Craft4 too? Based on documents, it looks like we can skip it. Not sure what would be impact on application.
Answers.UserDisplayName: dhumketu
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-03-06T21:11:22.210Z
Answers.Text: @binarymemoir Not necessarily NFS, but _a_ shared storage solution solves many problems in a load-balanced environment. See: https://craftcms.com/knowledge-base/configuring-load-balanced-environments
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-13T23:34:17.653Z
Answers.LastActivityDate: 2017-01-11T23:20:09.367Z
Answers.LastEditDate: 2017-01-11T23:20:09.367Z
Answers.UserDisplayName: Brad Bell
Body: <p>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:</p>
  
  <ul>
  <li>a GlusterFS replicated "shared" file-system mounted on the 3 nodes</li>
  <li>Craft app is installed in the <strong>shared</strong> file-system (so is the webroot and all common files, but Craft itself is outside of the webroot).</li>
  <li>a replicated MySQL database cluster hosting the Craft database (Percona xtraDB Cluster)</li>
  <li>Each node is configured with PHP ZendOpcache and Nginx.</li>
  </ul>
  
  <p>Currently, Craft Vhost is enabled only on one node because I have the following questions:</p>
  
  <ol>
  <li>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?</li>
  <li>overridePhpSessionLocation: I set to true (so it does not write to 'storage/runtime/sessions'</li>
  <li>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)</li>
  </ol>
  
  <p>Any pitfalls I should be aware or specific configuration needed for a load-balanced set of Craft instances?</p>
  
  <p>Thanks.</p>
  
Tags: <config><install><performance>
Title: Load balancing nodes configuration (3 Craft nodes behind F5 Big-IP)
ThreadText: # Load balancing nodes configuration (3 Craft nodes behind F5 Big-IP)
  
  (Asked by: username_0 on 2014-11-13)
  
  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.
  
  **Tags:** config, install, performance
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-11-13. Score: 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](http://buildwithcraft.com/docs/config-settings#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.
  
  > **Comments:**
  > **username_0**: Thank username_1.  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?  
  > **username_1**: No variable current exists for that, so you'd probably need to symlink it.  
  > **username_0**: Hi username_1, 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.  
  > **username_2**: A bit confused by @username_1'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."_  
  > **username_1**: @username_2 Sorry, typo.  Should have been `CRAFT_STORAGE_PATH`.  
  > **username_2**: @username_1 Ok, then which are you recommending (seems like you say both) `CRAFT_STORAGE_PATH` shared or independent?  
  > **username_1**: @username_2 Everything above the `<hr>` is my updated answer. `CRAFT_STORAGE_PATH` shared.  
  > **username_2**: @username_1 OK, so with that setup, you wouldn't be able to have separate logs per-server though, right? Currently I have `CRAFT_STORAGE_PATH` shared between servers, but then `CRAFT_STORAGE_PATH`/runtime per-server (via relative symlink).  
  > **username_2**: So I've found if I dedicate the runtime folder per-server, I end up with session/login trouble. Logins fail about 50% of the time (go figure, we have a 2 server LB). By "fail" I mean the cp login simply reloads on submit, no error.  Once the login succeeds, sticky sessions are working fine, and the user stays logged in.  If I make the runtime folder shared between servers, logins work fine, but we now don't have server-specific logs.  
  > **username_3**: @username_2 FWIW we had the dicey-login trouble on a load-balanced project and got around it by using Craft's `overridePhpSessionLocation` and pointing to a Redis (RDS) store instead.  
  > **username_4**: @username_1 Is NFS share a requirement for Craft4 too? Based on documents, it looks like we can skip it. Not sure what would be impact on application.  
  > **username_1**: @binarymemoir Not necessarily NFS, but _a_ shared storage solution solves many problems in a load-balanced environment. See: https://craftcms.com/knowledge-base/configuring-load-balanced-environments  
  
  ---
  
  