Our monthly Virtual Happy Hour is happening this week, Fri Feb 23!
Hi Episerver CMS forum
We have a setup where we have two different frontend servers with a loadbalancer in front (Netscaler). We are also using Episerver Commerce, but I don't know if that is related to our experience.
Everything seems to work as expected, except that our editors experience that they are asked to login again once in a while.
I have a suspicion that this occurs when the user for some reason reaches the other frontend server than he was using on the previous request. Could that be true, or could there be some other explanation for this?
Is Episerver keeping things in the session that are lost when the user switches frontend server?
Would enabling database session state solve our problem, or do you have any other suggestions?
We would like to be able to remove one of the frontend servers from the cluster for deployment, maintenance, etc. without affecting the users, so session affinity/sticky-sessions are not something we would prefere to look at.
Thank you for your help.
In a multiserver environment, you shouldn't use In-Process session state mode.
You should use SqlServer mode instead.
Also, don't forget to configure the remote events: http://world.episerver.com/documentation/items/developers-guide/episerver-cms/9/event-management/wcf-event-management/
You could also use Redis to store your sessions instead, there are few nuget projects that make this easy. Redis is a lot quicker than SQL and means your database is concentrating on dealing with commerce and CMS requests instead of dealing with your sessions. I wouldn't recommend it but you could also use sticky sessions on the ELB. This is from the Amazon setup page, whcih is interesting, even if you are not using Amazon.
The core parts of EPiServer CMS does not use Session State but some functionality does, such as some of the Visitor Groups criteria. There are two approaces to enabling session state, either use the sticky session feature (also known as session affinity) in the Elastic Load Balancer to make sure all requests from a user is reaching the same server combined with the default in-memory session state provider. Another approach to enable better scaling is using an optimized provider for Amazon, such as the session provider for Amazon DynamoDB.
Also I am assuming you are NOT running your admin on the front end web servers. If you are, then you are opening yourself up to being hacked easier.
A colleague of mine looke at Redis some time ago, because we were looking for a distributed cache framework. We abandoned it again, because we couldn't find out if it was working properly on Windows.
Do you have any more information on how to setup Redis on Windows? I have tried to google a bit again, but I didn't find anything that I liked. But perhaps I used the wrong search terms :)
We are using Azure for our blob storage. If we should use Amazon for session state, I think we would introduce too many different cloud services, so I will skip Amazon DynamoDB.
We are still setting up our website, so it is not final yet. We don't plan on making the admin interface available from the internet, but I'm a bit concerned about best practices on how to do that. I will start a new thread on the forum to get imput, and then leave this thread for the loadbalancing and session question. But feel free to reply to the other thread also :)
Thank you for your input so far.
Thank you for your input.
We have the remote events covered, but it is a good reminder. Now the session is what we are looking at.
No problem, for development, we use https://github.com/MSOpenTech/redis/releases . When you are looking at deployment you can use azure offering of Redis https://azure.microsoft.com/en-gb/services/cache/?&wt.mc_id=AID529440_SEM_ . You may also find http://world.episerver.com/Documentation/Items/Developers-Guide/Episerver-CMS/75/Deployment/Deployment-scenarios/Deploying-to-Azure-websites/ useful. That suggests using Redis cache for session state. I have worked only with setting up on AWS, which is why I pointed you in that direction.