Running an Orchard CMS site behind a load balancer

Question

I need to deploy an orchard application within a site that sits on a web farm, behind a load balancer. This seems like it would be a fairly common scenario, but I can't seem to find any guidance on how to make this work outside of Windows Azure.

The Orchard documentation describes how to deploy with multiple instances on Windows Azure. It points out three problems that must be solved, but the solutions are all Azure specific.

http://docs.orchardproject.net/Documentation/Deploying-Orchard-to-Windows-Azure

1. Media files stored on the file system. There are also files stored in the App_Data folder, e.g. the search indexes. Won't this be a problem also? What's the best approach to solving this? Running the site off a file share? Using Windows DFS to replicate changes? I'd prefer not to use a file share
2. Output and database caching use local memory for storage, combined with signals trigger cache invalidation on only the local server. Does the Distributed Events module solve this problem? https://orcharddistributedevents.codeplex.com/ Or perhaps the Orchard.Redis features?
3. Session state is stored in local memory. I suppose I could enable sticky sessions on the load balancer or just use SQL Server for session state.

I found an old post (Orchard CMS on Load Balanced web servers, back on Orchard 1.1) which suggests setting the machine key setting in the web.config.

I suspect I'll run into problems with the warm-up module? And I ran across the Orchard.TaskLease module which seems to imply that there is a problem with tasks running on multiple servers when they should only run on one.

Has anyone successfully deployed Orchard in a load balanced, non-Azure environment? What modules and special configuration would you suggest to make this work?

Byram

The difficulty is that there isn't a unique answer to this question. It depends on a lot of things about the hosting environment. There is a bunch of modules that may or may not help. Having synchronized machine keys is the bare minimum, but a lot more can be done with a mix of replication (running from a share is rarely a good idea), and usage of specialized modules and technology such as Redis. Session is rarely used, but setting up session affinity is another thing to look at in those cases where it is (TempData is one such case). – Metallurgy