views:

171

answers:

5

What issues do I need to be aware of when I'm deploying an ASP.NET application as a web farm?

+6  A: 

Sessions is a big one, make sure you use SQL Server for managing sessions and that all servers point to the same SQL Server instance.

Lloyd
+1 but I would say: `State information`, just to be more generic; this realm includes `Cache` and `Application` data
Rubens Farias
+1 and a good comment from Rubens too
LorenVS
That is true yes.
Lloyd
+4  A: 

One of the big ones I've run across is issues with different machineKeys spread across the different servers. ASP.NET uses the machineKey for various encryption operations such as ViewState and FormsAuthentication tickets. If you have different machineKeys you could end up with servers not understanding post backs from other servers. Take a look here if you want more information: http://msdn.microsoft.com/en-us/library/ms998288.aspx

LorenVS
Here's a link to a tool that will generate keys for you http://aspnetresources.com/tools/keycreator.aspx
David Liddle
+7  A: 

All session state information would need to be replicated accross servers. The simplest way would be to use the MSSQL session state provider as noted.

Any disk access, such as dynamic files stored by users, would need to be on an area avialable to all servers. Such as by using some form of Network Attached storage. Script files, images and html etc would just be replicated on each server.

Attempting to store any information in the application object or to load information on application startup would need to be reviewed. The events would fire each time the user hit a new machine in the farm.

Machine keys across each server is a very big one as other people have suggested. You may also have problems if you are using ssl against an ip address rather than a domain.

You'll have to consider what load balancing strategy your going to go through as this could change your approach.

Lee Hesselden
Consider having SSL terminate at the load balancer and then plain HTTP requests to the individual web servers. Balancers like F5's BigIP or similar support this.
devstuff
+2  A: 
  1. Don't use sessions, but use profiles instead. You can configure a SQL cluster to serve them. Sessions will query your session database way too often, while profiles just load themselfs, and that's it.
  2. Use a distributed caching store like memached for caching data, and ASP.Net cache for stuff you'll need alot
  3. Use a SAN or an EMC to serve your static content
  4. Use S3 or something similar to have a fallback on 3.
  5. Have some decent loadbalancer, so you can easily update per server, without ever needing to shut down the site
Jan Jongboom
+1  A: 

HOW TO: Set Up Multi-Server ASP.NET Web Applications and Web Services

Log aggregation is easily overlooked - before processing HTTP logs, you might need to combine them to create a single log that includes requests sent to across servers.

cxfx