Every site (or site admin in that case) desires to serve the users that are visiting the site on the best way, handle the traffic situation on the best side (if doesn't it's annoying the user and there is a chance that they won't come again).
Well known solution to this problem is to hold two (or more) servers needed to handle user requests. The main idea behind this web farm is to share pooled resources. There is a need to hold a common front end dispatcher to perform load control and manage customer requests.
My working web application answers these criterions mentioned above, it should be serving hugh amount of clients, therefore there is a usage of multi servers to give the best outcome, and I had to deal with that situation...
There several approach to deal this 'problem' that I could think of and listed ahead:
Session Management
There are 2 solutions supplied by ASP.NET regarding sharing state information between multiple servers:
State Server - In the specific web farm, you must approve that each web server holds the same <machinekey>. On the second step, if we'll want to maintain the session state across the web servers, each website's application path in the IIS metabase should be the same in the web farm.
One more important thing is to make sure of all the objects should (that you want to store in the session of course) be serializable (remember previuos post?).
SQL Server - Although I am using Oracle Database to store the current application data, I just wanted to mention this solution and will expand some basic details about this solution; Firstable, you should make sure all the objects are serializable, and like before, each website's application path in the IIS metabase should be the same in the web farm. This solution requires some SQL Server configuration in order to maintain the session management. You can read about it in more details here and here. Some very important security issues that you must consider are:
- Don't forget to encrypt your connection string (stored in the web.config or somewhere else).
- Use Windows authentication to the database and limit the application's login in it.
- Run the application in a secure channel.
Machine Authentication Check (MAC)
This solution comes for maintaining the form's information after firing events that are causing server postback. If you are working on one webserver, well... everything will act just fine; A common user behavior will fire a postback event which will go back to the server and deal with the sent data. BUT, what will happen if the event's data will be posted to another webserver? (All data will be lost...)
To solve this 'problem' you should modify the pages element in the machine.config of each webserver and set the enableViewStateMac attribute:
<system.web>
<pages enableViewStateMac="false" />
</system.web>
This will mention that the process should run a machine authentication check (MAC) on the pages' view state when the page is posted back from the client; true if the view state should be MAC checked and encoded; otherwise, false. The default is false.
"A view state MAC is an encoded version of the hidden variable that a page's view state is persisted to when sent to the browser. When you set the EnableViewStateMac attribute to true, the encoded and encrypted view state is checked to verify that it has not been tampered with on the client." (from MSDN).
Data Caching
- Shared Cache Application -You should use a cache application in order to cache you application's data. A good solution is to create am application that will be place in a single location. Each application (or each webserver) will send its data to this cache application to be cached. Each data retrieval will requested from the cache apllication firstly, otherwise will grab it from the specific data source (database etc...).
- SQL Server Caching - You can cache the data into Sql Server, it's quite easy to apply using ADO.NET and the .NET Framework provides a common development model to use with existing data access components. You can read some details about it here. Since in most case there is a single database that holds the data, you can use this kind of solution.
These are some of the ways for maintaining data over multi servers. I will be glad to hear about some more solutions and ways...