1) Is there special standard software to create an ASP.NET web farm?

No.

2) Or should we create a web farm ourselves, by transferring requests between different web servers manually (using ASP.NET / C#)?

No.

To build a web farm, you will need some form of load balancing. For up to 8 servers or so, you can use Network Load Balancing (NLB), which is built in to Windows. For more than 8 servers, you should use a hardware load balancer.

However, load balancing is really just the tip of the iceberg. There are many other issues that you should address, including things like:

1. State management (cookies, ViewState, session state, etc)
2. Caching and cache invalidation
3. Database loading (managing round-trips, partitioning, disk subsystem, etc)
4. Application pool management (WSRM, pool resets, partitioning)
5. Deployment
6. Monitoring

In case it might be helpful, I cover many of these issues in my book: Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server.

I d say you should configure an NLB cluster (Network Load Balancing), which basically splits all requests between cluster nodes (And as an added benefit detects if things are down and stops sending them requests). There s features built into windows for this, but they don t compare to a hardware device for performance or scalability. If you re using Windows 2008 it really is simple to set one up. If you do this make sure you have a shared machine key or you ll start getting exceptions for viewstate being invalid (When 1 server submits the form and it posts to the other and they re using different keys to encode the data).

You can also use DNS round-robin but at 20 servers presumably in 1 datacenter I wouldn t see a point to going to such crazy lengths. If you ve got multiple data centers though this is definitely worth considering (As NLB won t really work well between data centers).

You ll also want to be sure if a user swaps servers they don t loose their session. The simplest way would be to use a Session State database (Configurable in the web.config, or you can do it server-wide in IIS s configs). If you don t use sessions though just turn them off in the Pages directive of the web.config and call it a day. You could also use a session state server, but I don t have any experience with this.

It may also be worth considering spending some time optimizing the code or adding caching directives to static content - it can be very cost-effective even if you only trim the need for a few of those servers.

Hope that helps.

If you keep your server stateless, it is easy with a good router that implements some round-Robbin protocol (that send each call to the single published server ip to a different web server).

if it is not stateless (like - if a login is required, or ssl) than you need to keep each session to the same server.

Here is some info about MS Application Request Routing - you will get everything there:

IIS Load balancing

I would not recommend #2. You will do much better off with a load balancer.

Pay attention to session state management. Unless you configure the load balancer to keep each user on the same web server, you will have to use the session state server or database.

Also, check your code s usage of Application and Cache variables. These will be different on every web server. If those values are static, you may not have a problem. But if they can change, you can end up with different values on each web server.

There used to be a problem with ViewState in 1.x, as explained here. I m not sure if this problem still exists.

Then, there are some changes that you need to make to the Machine Key in web.config, as explained here.