Introduction
Windows Server AppFabric extends Windows Server to provide enhanced hosting, management, and caching capabilities for Web applications and middle-tier services. It consists of two main feature areas: AppFabric Hosting and AppFabric
Caching.
AppFabric Hosting features provide an easy way for users to deploy and manage Windows Workflow Foundation (WF) workflows that are hosted in Windows
Communication Foundation (WCF) services. AppFabric includes an extension of the Internet Information Services management tool that enables an IIS administrator to monitor the performance of services and workflows. There is also a set of Windows PowerShell
commands to manage persistence, hosting, and monitoring tasks.
The AppFabric caching features add a distributed, in-memory object cache to Windows Server that makes it easier to scale out high-performance .NET applications, especially ASP.NET applications.
Windows Server AppFabric is installed as a prerequisite for SharePoint 2013. AppFabric is installed as an extension to the Windows Server Application
Server Role and consist of two main components:
- Distributed caching – Previously codename Velocity
- Service and workflow management
How is AppFabric leveraged in the context of SharePoint 2013?
- What is AppFabric distributed caching and how does it work?
AppFabric 1.1 for Windows Server Caching features uses a cluster of servers that communicate with each other to form a single, unified application cache system. As a distributed cache system, all cache operations are abstracted
to a single point of reference, referred to as the cache cluster. In other words, your client applications can work with a single logical unit of cache in the cluster regardless of how many computers make up the cache cluster.
The value is stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppFabric\V1.0\Configuration in the registry.
-
AppFabric implements the caching methodology by using a cache cluster containing a number of caching servers. This cache cluster automatically handles the complexity of load balancing, scaling and failover. Each
one of the servers in the cache cluster has AppFabric installed and is running an instance of the AppFabric Caching Service. As an addition to storing data in the cache cluster AppFabric Caching Service also has the ability to store data in a local cache on
the server. This can be used to provide faster access to certain data which can be configured to automatically synchronize with cached items in the cache cluster.
When a cached item is being requested the local cache is checked first (if it is being used). If the item is found it is returned to the client. If the item does not exist the query is sent to the cache cluster and returned if it exists. This interaction with
the caching service is transparent to the client which only sees the cluster and local cache as a single entity. This way the client does not have to worry about which server the caching is stored on.
All data in the cache cluster is stored in memory on the cache servers. By default the data is stored in the memory on only one server in the cache cluster. By enabling the high-availability
option in the AppFabric Caching Services a second copy of each cached item is created on another server in the cache cluster. The first cached item is called the primary item and the second copy is the secondary item. In case a server in the cache cluster
becomes unavailable the data is available on one of the other servers. The secondary item is then promoted to the primary item and a new secondary item is created on another server in the cluster.
- How does SharePoint 2013 utilize AppFabric distributed caching?
The distributed caching is used by SharePoint 2013 for caching social elements and FedAuth tokens. Every time a user accesses a front end server the user needs to be authenticated which can become an issue when using
multiple front end servers. In SharePoint 2010 this was handled by enabling load balancing affinity (Sticky Sessions) to ensure that the user stayed on the same front end server. By caching the FedAuth token in the distributed cache it is no longer necessary
to enable sticker. The first cached item is called the primary item and the second copy is the secondary item. In case a server in the cache cluster
becomes unavailable the data is available on one of the other servers. The secondary item is then promoted to the primary item and a new secondary item is created on another server in the cluster.
- How does SharePoint 20y session since the authentication token is now available from all front end servers through the cache cluster.
Prerequisite: Windows Server AppFabric cache service.
In SharePoint 2010 and previous versions of SharePoint, authentication happened at the server level within Internet Information Services (IIS). The
authentication cookie was tied to the server (often as a session cookie) and if you jumped to a new server you had to log in again. In a load balanced environment, this required “sticky sessions” where the load balancer had to remember where it had sent you
previously within the same session so that you didn’t have to log in again. All of your SharePoint requests had to go to that server (images, pages, etc.) instead of being actively load balanced.
SharePoint takes advantage of this service in quite a few ways, specifically through user profiles and authentication.
- For user profiles, it enables everything to be “in sync” and have minimal visible
POSTs back to the server. Instead, the browser POSTs to the distributed cache and returns quickly because the distributed cache is resident in server memory. The data doesn’t have to be persisted to the database. Behind the scenes, a process
is doing the persistence from the distributed cache to the database, but the browser does not have to wait for it. This drastically improves responsiveness.
-
For authentication, it means that the authentication information exists above the IIS Cache level (see diagram). So you can move from server to server with ease without
being redirected to the login page. This allows your load balancers to actively balance the load of all requests. So you could get the page you requested from server A, but all of the images may come from server B. The end result is a faster response and a
healthier, more balanced SharePoint farm. It makes login easier and allows load balancing to be more robust. Additionally, we get another level of cache that’s farm-wide aside from the Hierarchical Object Store that you can use.
What Is Distributed Cache Service?
Distributed Cache Service is a customized version of Windows App Fabric (code named Velocity) deployed in SharePoint 2013.
The Distributed Cache service provides caching functionality to features (not to be confused with site features) in SharePoint Server 2013. The Distributed Cache service is either required by or improves performance of the following features:
- Authentication
- Newsfeeds
- OneNote client access
- Security Trimming
- Page load performance
Any server in the farm running the Distributed Cache service is known as a
cache host. A cache cluster is the group of all cache hosts in a SharePoint Server 2013 farm. A cache host joins a cache cluster when a new application server running the Distributed Cache service is added to the farm. When
using a cache cluster, the Distributed Cache spans all application servers and creates one cache in the server farm. The total cache size is the sum of the memory allocated to the Distributed Cache service on each of the cache hosts.
Things to Remember
- In a SharePoint Server 2013 farm, there must be at least one cache host running the Distributed Cache service.
- The Distributed Cache service’s memory allocation for the cache size is set to a default value of 10 percent of total physical memory when SharePoint Server 2013 installs. The Distributed Cache service
uses half of that memory allocation for data storage (also known as cache size), and the other half of that memory allocation is used for memory management overhead. When the cached data grows, the Distributed Cache service uses the entire 10 percent of the
allocated memory.
- The Distributed Cache service can be assigned a maximum of 16GB of memory per cache host in the cache cluster.
- The maximum number of hosts per cluster is 16.
- On a server that has more than 16 GB of total physical memory, allocate a maximum of 16 GB of memory to the Distributed Cache service. If you allocate more than 16 GB of memory to the Distributed Cache
service, the server might unexpectedly stop responding for more than 10 seconds.
- Do not manage the Distributed Cache service through either the Services MMC snap-in or the generic Windows Server AppFabric tools. Use SharePoint
Central Administration and the SharePoint PowerShell cmdlets. You may see the following message while trying to manage the service from services.msc.
The Distributed Cache service can end up in a nonfunctioning or unrecoverable state if you do not follow the procedures that are listed in this article. In extreme scenarios, you might have to
rebuild the server farm. The Distributed Cache depends on Windows Server AppFabric as a prerequisite. Do not administer the
AppFabric Caching Service the
Services window in Control Panel. Do not use the applications in the folder named Start menu.
- The Distributed Cache service on a cache host throttles requests when memory consumption approaches 95%. Until memory utilization levels drop back to (approximately) 70%, cache read
and write requests are not accepted.
- The Distributed Cache service can run on either a physical or virtual server. When using virtualization, do not use Dynamic Memory to manage shared memory resources among other virtual machines and
the Distributed Cache servers. This is NOT SUPPORTED. See Certain Microsoft SharePoint Server 2013 installation scenarios are not supported.
For more information about planning for the Distributed Cache service, see
http://technet.microsoft.com/library/jj219572.aspx.
Configuring Distributed Cache Service
Firewall Exceptions and Port Configuration
It is important that all cache servers have firewall exceptions for the cache, cluster, and arbitration ports. The AppFabric Configuration Wizard can automatically configure these
firewall exceptions; but you may want to confirm these exceptions when troubleshooting communication issues.
Each cache host refers to the cluster configuration settings to determine the appropriate ports to use to communicate with the cluster. Use the Windows PowerShell Get-CacheHostConfig command to see which ports are being used by
each cache host.
|
Port nameIt is important that all cache servers have firewall exceptions for the cache, cluster, and arbitration ports. The AppFabric Configuration Wizard can automatically configure these
firewall exceptions; but yourong>
|
Default value
|
|
cache port
|
22233
|
|
cluster port
|
22234
|
|
arbitration port
|
22235
|
|
replication port
|
22236
|
Cache Port
The cache port is used for transmitting data between the cache hosts and your cache-enabled application. The default is 22233.
Cluster Port
The cache hosts use the cluster port to communicate availability to each of their neighbors in the cluster. The default is 22234.
Arbitration Port
If a cache host fails, the arbitration port is used to make certain that the cache host is unavailable. The default is 22235.
Replication Port
The replication port is used to move data between hosts in the cache cluster. This supports features such as high availability and load balancing. The default is 22236.
Start and Stop the Distributed Cache service
- From Central Administration
- In Central Administration, click Application Management.
- In Service Applications, click Manage Services on Server.
- On the Services on Server page, locate the Distributed Cache service.
- To start the service, under Action, click Start. To stop, click Stop.
- Using PowerShell
# Start the Distributed Cache service by using Windows PowerShell
$InstanceName = "SPDistributedCacheService Name=AppFabricCachingService";
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_= "SPDistributedCacheService Name=AppFabricCachingService";
$serviceInstance = Get-SPServiceInstance | ? {(.server.name) -eq $env:computername}
$serviceInstance.Provision();
# Stop the Distributed Cache service by using Windows PowerShell
$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Unprovision();
Getting Started with Distributed Cache
- Run the Use-CacheCluster command to use the connection settings from the current computer.
Use-CacheCluster command sets the context of your PowerShell session to a particular cache cluster. You must run this command before using any other Cache Administration commands and without any parameters to use the connection settings that reside on the current
machine. If you need to connect to a different cache cluster, use the Provider and ConnectionString parameters to specify the cache cluster explicitly.
Use-CacheCluster - http://technet.microsoft.com/en-us/library/ff428183(v=ws.10).aspx
- Run the PowerShell command Get-CacheClusterHealth to retrieve the health statistics for all of the named caches in the cache cluster.
Get-CacheClusterHealth - http://technet.microsoft.com/en-us/library/ff428190(v=ws.10).aspx
- Retrieve the list of all the cache host services in a cluster using Get-CacheHost command
Get-CacheHost provides the list of each cache host service that is a member of the cache cluster. You can specify the following parameters along with this command
-HostName- Name of the cache host
-CachePort- Cache port number used by the cache host. The default value for the cache port number is 22233.
For example: Get-CacheHost -ComputerName localhost -CachePort 22233 | fl
This will return the cache host service on the local computer and the port number used by it.
Get-CacheHost - http://technet.microsoft.com/en-us/library/ff428165(v=ws.10).aspx
Check and Change The Memory Allocated To Distributed Cache
To check the existing memory allocation for the Distributed Cache service on a server, run the following command at the Windows PowerShell (run as administrator) command prompt:
Use-CacheCluster
Get-AFCacheHostConfiguration -ComputerName <YourServerName> -CachePort "22233"
Where:
ComputerName is the computer name of the server that you are running the PowerShell cmdlet on.
Change the memory allocation of the Distributed Cache
- Stop the Distributed Cache service on all cache hosts.
To stop the Distributed Cache service, go to Services on Server in Central Administration, and Stop the Distributed Cache service on all cache hosts in the farm.
- To reconfigure the cache size of the Distributed Cache service, run the following command one time only on any cache host at the Windows PowerShell command prompt:
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize
Where:
CacheSize is the cache size's memory allocation assignment in MB.
- Restart the Distributed Cache service on all cache hosts.
To restart the Distributed Cache service, go to Services on Server in Central Administration, and Start the Distributed Cache service on all cache hosts in the farm.
See Also
