WEB farm - Load Balancing in Asp.net

In the Open Query File dialog box, browse to the UninstallSqlState.sql script file, and then click Open. By default, UninstallSqlState.sql is located in one of the following folders:

system drive\Windows\Microsoft.NET\Framework\version\

After UninstallSqlState.sql opens in SQL Query Analyzer, click Execute on the Query menu to run the script.

After you uninstall SQL Server mode session state management configuration, you must restart the w3svc service. To restart the w3svc process, type net starts w3svc at a command prompt.

Security Considerations Sql Server [Session]:

The following aspects need to be kept in mind:

• Use Windows authentication to the database
• Encrypt sqlConnectionString
• Limit the application's login in the database
• Secure the channel

Caching Considerations

There are three options explained below.

1. Synchronizing all servers in web farm
2. Centralized Cache location to be maintained.
3. SQL server caching

1. Synchronizing all servers in web farm

By providing a wrapper class simply having a CacheControl.aspx receiver page in each of the Applications, it is possible to send a WebRequest to each of the machines (maintained in an easy-to-configure web.config AppSettings element) and have each enabled with code to do its own update "on demand".

So, whenever add a "real" item to the Cache, it will also create a new populated instance of the same class, serialize it into a compact byte stream, and iterate through our server list sending it over the wire via the WebRequest so that each app in the farm, WebGarden, etc can receive and deserialize it, and update its own Cache. Simple, elegant, and fast! Even if it is a complex object such as a class that you have added to your Cache, provided that it is serializable, it will work.

2. Centralized Cache location

One Cache-application is to be created, which will take care of the caching and returning the cached items. And that is to be placed in centralized location. All applications should send the data to be cached, to that cache-application. The Cache-application will store the data. When any application requests the cached data, it will be retrieved from the Cache-application. (The centralized Cache-application can be called with credentials.)

3. SQL server caching

SQL Server caching is easy to implement by using ADO.NET and the .NET Framework, and it provides a common development model to use with existing data access components. It provides a robust security model that can easily be configured to work across a Web farm using SQL Server replication.

If the application requires cached data to persist across process recycles, reboots, and power failures, in-memory cache is not an option. In such cases, Caching mechanism based on a persistent data store, such as SQL Server or the NTFS file system. It also makes sense to use SQL Server to cache smaller data items to gain persistency.

Because the cache service needs to access SQL Server over a network and the data is retrieved using database queries, the data access is relatively slow. We need to carefully compare the cost of recreating the data versus retrieving it from the database.

NLB(Network Load Balancing):

Network Load Balancing_NLB is a network driver that distributes the load for networked client/server applications across multiple c luster servers. Network Load Balancing works by distributing client requests across a set of servers.

Shopping cart contents at an e-commerce site and Secure Sockets Layer (SSL) authentication data are examples of a client's session state. Network Load Balancing can be used to scale applications that manage session state spanning multiple connections. When its client affinity parameter setting is enabled, Network Load Balancing directs all TCP connections from one client IP address to the same cluster host. This allows session state to be maintained in host memory.

NLB provides the client affinity parameter, which, when enabled, basically makes you "always come back to the server you landed on first", thereby insuring that your Session and Application variables don't get thrown away. Use the client affinity feature. When client affinity is enabled, Network Load Balancing directs all TCP connections to the same cluster host. This allows session state to be maintained in host memory. You can enable client affinity in the Add/Edit Port Rules dialog box in Network Load Balancing Manager. Choose either Single or Class C affinity to ensure that only one cluster host will handle all connections that are part of the same client session. This is important if the server application running on the cluster host maintains session state (such as server cookies) between connections.

Network Load Balancing, a clustering technology included in the Microsoft Windows 2000 Advanced Server and Datacenter Server operating systems, enhances the scalability and availability of mission-critical, TCP/IP-based services, such as Web, Terminal Services, virtual private networking, and streaming media servers. This component runs within cluster hosts as part of the Windows 2000 operating system and requires no dedicated hardware support.

Other Tasks

Request distribution: Incoming HTTP requests must be distributed among all servers by using a mechanism such as round-robin DNS, Microsoft Application Center 2000, or a third-party load distribution device.

Log aggregation: Before you process HTTP usage logs, it is a good idea to combine the logs to create a single log that includes requests sent to all systems.

Monitoring: To detect problems that affect a single server or the whole site, you must monitor both the external URL for the site and the URLs for each of the Web servers.

Scheduler: Scheduling an event to occur on a single server should cause only that one server to run the task. Scheduling an event to occur on all servers should cause all servers to run the task. [Updations need to be done and should get reflected in all servers hence scheduler should appropriately picked-up]

Centralized database: Web applications that use a database must have a single database that is shared between multiple Web servers. In environments that require no single point of failure, cluster the database server.

Synchronize Configuration and Content

You need to ensure that the config files are present in the right path on all the servers, and that their contents are continuously in sync.

You can copy configuration files to servers by using any standard file copy or synchronization method, including DFS, the File Replication service, and Microsoft Application Center 2000.

The following batch file will work in environments where each Web server has the virtual server root folder shared as:

wwwroot$: XCOPY \\source-server\wwwroot$ \\destination-server#\wwwroot$\D\E\O\X

When you deploy configuration information and ASP.NET content to multiple servers, it is critical to deploy the content from a single staging server to all production servers at the same time. This reduces the chance of problems occurring when a user's requests are sent to different servers. Microsoft recommends that all configuration and content updates occur on the staging server. Ideally, this staging server does not receive requests from users. It is dedicated to the task of testing and deploying new content.