Load Balancing in ASP. NET sites

Load Balancing in ASP. NET sites:

Based on the HTTP protocol, we may find that we have to solve two problems:

First, to achieve load balancing, we need a Load balancer.

You can use DNS round robin to obtain different IP addresses for each DNS query of the same host name that performs load balancing on the DNS server. The advantage is that the configuration is easy to invest a little. The disadvantage is that the browser has equal access to each server and cannot automatically route requests to a server with a smaller load.

You can use a dedicated server Load balancer device to automatically forward HTTP requests to servers with lighter loads by monitoring the loads of several backend servers. In addition, you must monitor the IIS load of the backend server, rather than the CPU load of the whole server. At the same time, you may need to establish a heartbeat connection between the Server Load balancer and backend service applications to Prevent IIS processes on a server or applications running in the server from being down, instead, the Server Load balancer detects that the server has the smallest load and forwards a large number of requests, achieving the opposite effect.

Second, session state persistence and migration.

Due to the stateless nature of the HTTP protocol, we generally store some client status data in the session. After Server Load balancer, the servers on which the two HTTP requests arrive may not be the same, this may cause this situation. The session set in the previous request processing becomes unavailable in the second request, resulting in an application error. So we need to migrate the session. The solution is to store the session and share the session with the server.

In ASP. NET, there are five ways for the server to save the session. If off is left blank, inproc is saved in the memory of the server process, which obviously cannot meet the requirements. The other two types can meet the following requirements:

StateServer stores sessions in dedicated State servers. In this way, each server accesses the same StateServer to achieve sharing.

Sqlserver stores sessions in the database. The same goal can be achieved.

The custom storage solution of custom can be implemented by writing it on our own.

Compared with custom, it is difficult to implement it by yourself. sqlserver can use the database cluster to achieve high performance and high availability. Of course, StateServer can also achieve high availability through means, however, it seems that the cluster cannot be implemented, so the performance is also limited.

In addition, if you want to configure session in StateServer and sqlserver, you must overwrite the machinekey node in Web. config:

<Machinekey

Validationkey = "1234567890123456789012345678901234567890 aaaaaaaaaa"

Decryptionkey = "123456789012345678901234567890123456789012345678"

Validation = "sha1"

Decryption = "Auto"

/>

Otherwise, the sessions received by each application server are different.

It is possible that the custom mode can define the Access session mode to ignore the machinekey, which may be unnecessary because it has not been done.