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)
Related
So I'm having reverse proxy server, where Nginx working as proxy server and loadbalancer. My biggest problem, that I have 2 app backends, which I need sometimes to shutdown. When I write after server down the backend, shutdown and looses sessions. How can I gracefully shutdown one of my app server? So that Nginx wait while all sessions will be completed or for some time?
My simple config:
upstream loadbalancer {
ip_hash;
server 192.168.0.1:443;
server 192.168.0.2:443;
}
Ok the issue is that each server has it's own session manager, and when the server is dead the session data is lost with that server, a good solution is to make a centralized session storage, for example the same server which is load balancing, and the other 2 servers connect to it to get the session data, if one server is down, and the other server tries to serve the connection that was being served by the other server then the data will still be found because the data is stored elsewhere, common methods to do so is using memcached as session storage.
As for the pros, you can add and remove as much app servers as you want and the users won't even notice any change.
But for the cons, if that single server dies, all session data is lost, because the data is centralized.
You haven't really tagged your question with what language you are using, but if you search for it on google you'll easily find useful posts to help you.
My question is on ASP.net session management. In the current web application we have "sticky sessions" (user is always redirected to server it started talking to). Below is my problem statement.
From one of our client there are huge number of request hitting our servers. Somehow requests are sent from 1 or at most 2 IPs. We have 5 servers running to serve those request. Now the problem here is that 1-2 server might be heavily getting hits while other servers might be idle because sticky sessions will not allow request to be processed by serverB which was initially answered by serverA
What we need is exactly the opposite. Any server should be able to process incoming request maintaining the continued conversation.
I have put my problem in very plain words. Any pointer will be appreciated.
Why not just store the session state on a SQL server?
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.
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.
I have an ASP.NET application that is running on two load balanced servers. Everything is working fine except for one group of customers. All of these customers are coming from the same company. Randomly, an unhandled NullReferenceException error is thrown. It happens at random times in random places. It seems as if the session is just totally gone. since this is only happening for a specific group of users I have to assume that is has something to do with thier environment. I have seen users coming in with IE6, IE7, IE8 and FF and it the error occurs in all cases.
I am not 100% sure how to troubleshoot this. Does anyone have any ideas?
EDIT: Session is set to "InProc"
<sessionState mode="InProc" cookieless="false" timeout="20" />
InProc session isn't shared between servers, so it sounds like this group of users is moving from one server to another and the others aren't. Maybe your load balancer is trying to achieve sticky sessions using something like IP address or whatever and this organisation is blocking that information.
I got in contact with the user that was having the porblem. I asked him to open a browser and go to whatsmyip.org and tell me what it says is his IP address. Then I asked him to refresh the screen a few times. Well, wouldn't you know it, the IP address changed. It kept switching between two different IP addresses. This was not the IP address of his machine but of two different proxies. Each request could come form one or the other apparently.
Our load balancer (something called Zeus - I am not a network guy) was set to estabilsh session affinity (a.k.a. sticky connections) using IP addresses. We changed the settings so that the load balancer would drop a cookie and use that to maintain the session and everything works correctly now.
If you're using SQL to store session state, check that all the servers in the farm are looking at the same SQL database - I've been caught out by this one before and it took quite a while to work it out!
Edit:
Actually you might need to set it to StateServer as you're running in a web farm.
See this about Session-State Modes from MSDN.
If your load balancing is based on directing every hit to the least-busy server, then InProc isn't going to work. you would need to use StateServer or SQLServer modes.
Imagine the first hit from a client is directed to server A - that starts a new session on server A. The second hit from the same client could go to server B, supplying the session cookie from server A which server B doesn't recognise.
If you have 'sticky' (or client affinity) load balancing, where the first hit is allocated to the least-busy server, but then subsequent hits from the same session are directed to the same server, then InProc should still work.