locked
Fault Tolerant/Load Balanced ASP.NET Web Server Architecture RRS feed

  • Question

  • Hi,

     

    I'm looking at designing a fault tolerant/load balanced server architecture to host a new ASP.NET application.

     

    As far as possible, I do not want to purchase "specialized" hardware for the job; I would like to use standard Windows Server 2003 installations.

     

    The application runs on ASP.NET 2 with SQL Server 2005.

     

    For the database itself, I plan to implement a mirrored database with a witness server. I know this won't provide load balancing as such, but the primary server have ample power to cope with all requests.

     

    However, I'm not sure what the best way to implement the application layer is. The application consists of an ASP.NET web application, and an ASP.NET web service. The web service will basically be a wrapper for the Business Logic of the application, to allow third parties to completely integrate with our system.

     

    My question is, should I implement my ASP.NET web application to communicate via the web service? It would look something like this:

     

    Web Server <--> Web Service Database Server
    Web Server <--> Web Service
    Web Server <--> Web Service

     

    The web service is completely stateless, so load balancing can be achieved via round robin DNS. The ASP.NET application on the web server would be using the database server for session state (and a client side cookie to identify the session), so again round robin DNS can be used to load balance (HTTPS is not required and so is not an issue).

     

    I perceive the advantages of structuring the application like this as:

    • The web servers being load balanced
    • The web services being load balanced
    • The web servers being independent of the web services

    I'm not sure if this kind of architecture is a) worth the hassle and b) if it would decrease performance to much to be usable. The other alternative would be to place the ASP.NET application on the same level as the web service:

     

    Web Service <--> Database Server
    Web Service <-->
    Web Service <-->
    Web Server <-->
    Web Server <-->
    Web Server <-->

     

     

    Can anyone offer any insight on this? Any help much appreciated.

     

    Kind regards,

     

    Andrew

    Friday, July 4, 2008 9:40 AM

All replies

  •  

    As to my understanding, You can have three web servers with Load balance. Two DB Server with DB Mirror. Then your application can connect to the DB using the DB Virtual Cluster Name, It should be no change on the asp.net code itself.
    Sunday, July 6, 2008 5:03 AM
  • Hi Andrew,

     

         About your question I think the best solution is the first one because as you said the Load Balancing is possible on all parts of the solution, so it will have a great performance, and answering to your questions is A) Yes I think it's worth the hassle because you'll gain a lot with the increase the avalability of your application and by doing that enhancing your solution performance, and by saying that my answer to B) is that the slight decrease in performance not real because when you do that your prepare you solution to grow and in two ways, Vertically, because your can put the several parts of your solution in different servers and by doing that you enhance the availability and the security, and Horizontally because by preparing the solution in this way you provide the possibility to grow in servers that are providing the several layers of the solution, and so if you need only more computing you increase only the number of servers providing the WebServices and not the presentation part (ASP.NET).

     

    Hope this answers your question.

     

    Tuesday, July 15, 2008 11:39 PM
  • I agree, you probably only need to start with two physical layers (Http facing + App) + (Database). Then increase the number of servers in the farm and/or the number of farms. If you ever need to you can then physically separate out Http facing and the app but my experience is that is rarely needed for performance reasons alone.

    Saturday, July 19, 2008 7:40 AM