SQL Server Session State, web farm, and counting the sessions - asp.net

I have 2 load balanced web servers. My application is using the SQL Server Session State database on SQL Server 2008.
The 2 web servers are identical in terms of IIS configuration, and if I understand correctly, the two web apps on the two servers will be mapped to the same app id in the ASPStateTempApplications table since they have the same IIS configuration. So, counting the number of sessions associated with this app Id (from the ASPStateTempSessions tabel) will result in the total count of sessions on the two web servers together.
My questions is:
Is there a way to know how many sessions are active on each server individually?
I have the problem that when I take one server out of the load balance, I want to know if there are still any active sessions on the server or not before recycling it.
Another scenario, if I have to recycle the IIS on one of the servers because another web app on the same server is crashing, I would like to know how many sessions will be affected when I do so.
Thanks.

Basically, they all may and actually SHOULD be active on both ) Because in this mode sessions are not bound to the web-servers at all.
You can stick each user to a single server with load-balancing techniques on your gateway and if so - better to use InProc mode with all its benefits )

Since the session data is stored in SQL Server, you shouldn't have to worry about how many sessions are active. Once the server is shutdown (or IIS is recycled, depending on the configuration), the load balancer will automatically send any new requests to the active IIS server. With the session data stored in SQL, the active server can retrieve the session data and the user will be unaware that any server switching has occured.
Ideally, you should test this procedure periodically to make sure everything is configured correctly. Also, you should follow this procedure when installing patches to the servers.

Related

Queued responses from SQL server with ASP website hosted in IIS

We're running an ASP website in IIS 7.5.
The site has a SQL backend database, running on a seperate SQL server.
There is a 10Gb fiber connection between both of these servers via a switch.
We're seeing some delays in requests to the SQL server being answered.. so like a request to add a record might go through within 0.25 seconds for one user, but then the same task might take 6 seconds for another user, or even the same user but later on in the day.
I haven't as of yet been able to identify any pattern to the performance issues, except to say it seems as if something is getting queued somewhere.
The machines themselves are virtual machines hosted on HyperV hypervisors.
They have an absolute abundence or memory and CPU resource allocated to them.
The network on the hypervisors is bonded for redundancy, and VMQ is disabled.
I've had perfmon running on both servers for quite a while and can't see anything obvious that points me in a particular direction.
Has anyone seen this sort of behavour before?
Thanks in advance

Losing session state in shared configuration IIS

Our configuration is like this:
Two web app servers in NLB cluster with shared IIS configuration
Two DB servers in DB cluster
Session is stored in database
When we test our clusters, if we shut down one app server and one DB server, user session is not preserved and user is redirected to the login page.
If we shut down only one DB server, session is preserved.
Do you have any idea what could be the cause of this behaviour?
Could it be something related to the IIS shared configuration?

Is NLB a good way to keep a website available while deploying new code?

I want to be able to deploy a new version of my asp.net/mvc website without loosing client session state or causing any downtime. The way I'm thinking of accomplishing this is by creating a Windows Network Load Balancing server so that clients can reach it via a single url such as https://mysite.org/. It would then redirect traffic to one of two other sites (A.mysite.org or B.mysite.org). I'll set the NLB's affinity to Single, and disable site B so that all sessions are are directed to site A. When I need to deploy a new version of the website, I'll deploy to site B, enable site B, and disable site A. So, everybody that was on site A can stay there (using version 1) until they log off. All new sessions will connect to site B and run version 2. The next time I deploy, I'll do the reverse.
I've never used NLB. Is this appropriate? Is there a simpler, easier way?
How does NLB know when a request from client X already has a session on A or B? Ie. when they log off the website, and try to login again, will the nlb send them to the same site they were on before?
There are quite a few considerations here
Firstly, rather than juggling the affinity on your NLB, you will probably be better storing your ASP.NET Sessions in StateServer or SQL based Session management to allow web clients (or web service clients) to access your site without 'sticky' affinity. Once you've set up the StateServer or created the SQL Session DB, it should be a simple change to your app's web config.
NLB itself works great for keeping your site up while you upgrade your site. You will typically drainstop a server in the cluster before reinstalling your app to it, test it, and then bring it back into the NLB cluster, before repeating the process with the next server etc.
AFAIK, NLB Single Affinity works at TCP/IP level and is does not interrogate ASP.NET sessions. Basically any connection from the same client IP to the same server IP:Port combination will be directed to the same server. Also AFAIK, both servers will be sharing the NLB IP (In addition to any existing IP's they have).
Since it seems your site uses SSL, it seems that unless you have affinity, that the SSL session keys will need to be renegotiated on each request, which could have performance implications.

How to get Web Application and DB Server High Availibility

I have a Web application made in ASP.NET and MS SQL 2005 as database
ASP.NET Web App is hosted on : http://192.168.0.90
and MS SQL Server DB on : 192.168.0.91
User use url : http://192.168.0.91 to access the server.
MY DR IP address for Web App http://192.168.0.150 and Database is : 192.168.0.151
Suppose my Web Server Fails. i need to Automatically divert user to my Web Application DR Server IP
same with DB Server.
without user knowing it ? how can i do it...
Waiting for your earliest revert.
Regards
Hasnain
preferred is the process should be automatic
For the web application use DNS instead like myapp.domain.com and assign two IPs (A records) to it. It will be working as round-robin load balancing and when one server will crash, it will direct you to the another one. This is the simplest yet quite effective method providing some extra availability, assuming you have session in external database or you are using clustered storage.
Also, when one of your webservers is not available, you can dynamically remove it's IP from the DNS, and this DNS A record should have 300 seconds TTL.

Does memcached have a mechanism to redistribute its cache?

Problem: I have a server farm which uses non-sticky IP's and a Session Server to maintain sessions for all the servers. So it doesn't matter which server a client comes back to because the server will always go to the Session Server to get that client's session data. When I take the Session Server down all the servers lose their session data.
One of the solutions to this problem is to use SQL Server as the Session Server. This unfortunately is not possible.
So I'm thinking in terms of Memcached. If I managed my session using memcached I still have the problem that session will be lost if I take one of the memcached servers down. However, if I could issue a call against that server saying "redistribute your cache to the other servers" then this should solve the problem.
How would you redistribute memcached's cache from a server being taken down to other servers?
I'm not sure there's such a feature in memcached. But, the point is, it's cache. The worst that can happen if a server goes down or restarts is that you get some cache misses (until it's rebuilt). Memcached isn't supposed to be a reliable DB (though there is a DB based on memcached) - your data should be kept in some lower persistent level as well and you shouldn't sweat it when a cache server goes down every once in a while as long as it doesn't invalidate your entire cache and doesn't happen too often.
Have you considered using SQL Server to maintain the session state?
Using SQL Server for ASP.Net session state
ASP.NET Session State (MSDN)

Resources