Windows Server AppFabric Cache – Architecture

The AppFabric Cache Host is a physical server that runs on Windows Server 2012, Windows Server 2008 R2 and Windows Server 2008 Service Pack 2 and has sufficient amount of physical memory like 32 / 64 GB based on the hardware configurations allowed in your environment. These physical servers can form Cache cluster when you add more servers to Windows Server AppFabric cache environment based on your business requirements. When you install Windows Server AppFabric Cache, each host is installed with AppFabric Caching Service – which is a windows service that provides to manage cache environment through Powershell administration console.

The interesting point to note here is that these Windows Servers need not be configured to be in cluster. It is the Cache hosts (more than one server) that forms internally as cluster and provides you high availability feature. Hence when one of a Cache Host goes down for any hardware failure, the other servers in the cluster take request from Cache client. And since these Cache Hosts form cluster, the data items that are stored in one Cache Host will be copied seamlessly behind the scene to other hosts as well.

The way Windows Server AppFabric Cache stores items inside can be broadly classified into three ways:

1. A Key and Value pair.

2. Key and Value pair stored inside Regions.

3. Key and Value pairs stored inside Regions and marked by Tags.

Each AppFabric Cache node, once installed should first create named cache to hold items inside Cache. Applications refer to AppFabric server by this named cache. These named cache have a default time duration of 10 minutes – we call as Time to Live (TTL) to hold these cached items. We can specify in the New-Cache command using PowerShell administration console about the duration of persistence for these cached items.

By default, each cached object is stored on only one machine in a cache cluster. To improve resilience if a cache server goes down, AppFabric Caching Services has a high-availability option that creates a secondary copy of each cached data item on another machine in the cluster. If the cache server holding the primary copy of this data fails, the secondary remains available.

In this case, the high-availability option is turned on, and so each cached data item is held in two different cache servers. The primary copy, shown in the figure as a filled-in shape, handles all changes to the item. Those changes are automatically propagated to the secondary copy, shown as an open shape. Here, the cache server holding the primary copy of data item X goes down, either intentionally or inadvertently (step 1). When a cache client accesses data item X (step 2), the cache cluster silently redirects that request to the secondary copy and return its value (step 3).

This example shows a read, but updates also work when the cache server holding a primary copy goes down. Once AppFabric Caching Services detects that the primary is unavailable, it promotes the existing secondary copy to a primary, then creates a new secondary copy. None of this is visible to the cache client—everything works just as if no failure had occurred.

The data items stored inside AppFabric Cache can be controlled to designated valid users / groups of Active Directory members. This enables security restrictions to users of an application to gain access to AppFabric Cache and manage administration through Powershell. Below is the command you use to enable through Powershell administration console.

Grant-CacheAllowedClientAccount -Account "SERVICE_ACCOUNTS"

Grant-CacheAllowedClientAccount -Account "AD_GROUP"