Tuesday, December 17, 2013

SharePoint 2013 Load Balancing Affinity / Persistence / Sticky Sessions

I remember hearing that 2013 no longer requires sticky sessions (affinity/persistence) in the load balancing solution. This is due to the new distributed cache service which now hosts the login tokens. see more below


Improvements in claims infrastructure

SharePoint 2013 also includes the following improvements in claims authentication infrastructure:
  • Easier migration from classic mode to Windows-based claims mode with the new Convert-SPWebApplication Windows PowerShell cmdlet
    Migration can be run against each content database and each web application. This is in contrast to SharePoint 2010 Products, in which the migration was run against each web application. For more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013.
  • Login tokens are now cached in the new Distributed Cache Service
    SharePoint 2013 uses a new Distributed Cache Service to cache login tokens. In SharePoint 2010 Products, the login token is stored in the memory of each web front-end server. Each time a user accesses a specific web front-end server, it needs to authenticate. If you use network load balancers in front of your web front-ends, users need to authenticate for each web front-end server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By storing the login tokens in the Distributed Cache Service in SharePoint 2013, the configuration of affinity in your load balancing solution is no longer required. There are also scale-out benefits and less memory utilization in the web front-ends because of a dedicated cache service.
  • More logging makes the troubleshooting of authentication issues easier
    SharePoint 2013 has much more logging to help you troubleshoot authentication issues. Examples of enhanced logging support are the following:
    • Separate categorized-claims related logs for each authentication mode
    • Information about adding and removing FedAuth cookies from the Distributed Cache Service
    • Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt
    • Information about where authentication requests are redirected
    • Information about the failures of user migration in a specific site collection

No comments:

Post a Comment