Session State Server vs SQLServer

Hello and thank you for taking the time to read this.

I have been put in charge of re-architecting a moderately busy Internet
Site. Our daily logs are approximately 300MB with all of our virtual servers
combined and many of the subwebs are ASP.NET applications. I am going to
propose an architecture of 2 Dell Power Edge 1850 servers clustered via
Network Load Balancing (NLB). I want users to not miss a beat if the servers
failover in the middle of their session(s). This means that the Session State
will need to be maintained on a seperate server.

My question is this: "Should I use a Session State Server using the session
state service or should I opt for the SQLServer option?"

I think that it should also be said that I don't want the failure of any one
single server to take the entire web down, so I am thinking that I may even
want to have some redundancy for the Session State solution as well. Other
wise if the Session State server or SQL Server goes down, then the entire web
goes down.

Your thoughts and input is appreciated.

Thanks, Rob

Ken
Wed Aug 23 03:37:32 CDT 2006


"JayhawkTuba" <JayhawkTuba@discussions.microsoft.com> wrote in message
news:7EDD6F7D-BFB7-44FE-966A-0F2C2050256B@microsoft.com...
> Hello and thank you for taking the time to read this.
>
> I have been put in charge of re-architecting a moderately busy Internet
> Site. Our daily logs are approximately 300MB with all of our virtual
> servers
> combined and many of the subwebs are ASP.NET applications. I am going to
> propose an architecture of 2 Dell Power Edge 1850 servers clustered via
> Network Load Balancing (NLB). I want users to not miss a beat if the
> servers
> failover in the middle of their session(s). This means that the Session
> State
> will need to be maintained on a seperate server.
>
> My question is this: "Should I use a Session State Server using the
> session
> state service or should I opt for the SQLServer option?"
>
> I think that it should also be said that I don't want the failure of any
> one
> single server to take the entire web down, so I am thinking that I may
> even
> want to have some redundancy for the Session State solution as well. Other
> wise if the Session State server or SQL Server goes down, then the entire
> web
> goes down.


You can cluster SQL Server. I don't believe you are can cluster servers
running the ASP.NET Session state service. So if you want redundancy in your
session state storage, you will need to use the SQL Server option.

Cheers
Ken

JayhawkTuba
Wed Aug 23 08:06:02 CDT 2006

Thanks Ken, much appreciated.

"Ken Schaefer" wrote:

>
> "JayhawkTuba" <JayhawkTuba@discussions.microsoft.com> wrote in message
> news:7EDD6F7D-BFB7-44FE-966A-0F2C2050256B@microsoft.com...
> > Hello and thank you for taking the time to read this.
> >
> > I have been put in charge of re-architecting a moderately busy Internet
> > Site. Our daily logs are approximately 300MB with all of our virtual
> > servers
> > combined and many of the subwebs are ASP.NET applications. I am going to
> > propose an architecture of 2 Dell Power Edge 1850 servers clustered via
> > Network Load Balancing (NLB). I want users to not miss a beat if the
> > servers
> > failover in the middle of their session(s). This means that the Session
> > State
> > will need to be maintained on a seperate server.
> >
> > My question is this: "Should I use a Session State Server using the
> > session
> > state service or should I opt for the SQLServer option?"
> >
> > I think that it should also be said that I don't want the failure of any
> > one
> > single server to take the entire web down, so I am thinking that I may
> > even
> > want to have some redundancy for the Session State solution as well. Other
> > wise if the Session State server or SQL Server goes down, then the entire
> > web
> > goes down.
>
>
> You can cluster SQL Server. I don't believe you are can cluster servers
> running the ASP.NET Session state service. So if you want redundancy in your
> session state storage, you will need to use the SQL Server option.
>
> Cheers
> Ken
>
>
>