High Availability for Windows Server AppFabric Caching (Part-III)

In my earlier articles, we have spoken about AppFabric, its pros and cons and how it fares against its competitors.

In this article, we will focus on how we can configure high-availability for AppFabric caching.

What is high availability?

High availability is a characteristic of a software system which aims to ensure an agreed level of performance, uptime and fault-tolerant to drive business needs.
Every application running out there, wants to make sure the users get consistent and equally compelling performance. In addition to this, all these systems are expected to be available all the time, 24x7x365 whenever users need it. 

How AppFabric Caching works?

When high availability is enabled, a copy of each cached object or region is maintained on a separate cache host under Same Named Cache. The cache cluster manages maintenance of these copies and supplies them to your application if the primary copies are not available. No code changes are required to make your cache-enabled applications highly available. The following figure illustrates how copies of objects and regions are stored on separate hosts when the high availability feature is enabled.

High Availability Configuration

High availability is configured at the cache level in the cluster configuration settings. 
As a property of the cache, you can enable it when you first create the cache by using the New-Cache command with the Secondary's parameter equal to 1. This tells the cache administration Windows PowerShell cmdlets that you want one copy of each cached object or region.

By default, the high availability option is disabled when you create a new cache.
This features requires all nodes in the cache cluster to be running the Enterprise Edition (or higher) of Windows Server 2008 or Windows Server 2008 R2.
Please confirm that all high availability cache nodes are running on a supported operating system. 

Secondary Copy Storage

The cache cluster chooses where the secondary copies of objects and regions are stored. Just as AppFabric distributes cached objects across all cache hosts in the cluster, it also distributes the secondary copies of those objects across all cache hosts in the cluster.

How Consistency Is Maintained

Regardless of whether high availability is enabled, cache-enabled applications work as if only the primary copy of the cached object exists. All Add, Put, and Remove method calls are first initiated on the primary object on whichever cache host they reside. After the call is initiated to the cache host that maintains the primary object or region, the resulting action differs depending on whether high availability is enabled. 

If high availability is enabled, there is an added step of notifying the host maintaining the secondary copy that a change is about to occur. Then, the cache host with the primary copy of the object waits for an acknowledgment from the other host before acknowledging back to the client that the operation is complete.

For an example, a cache hosts A and B in the following diagram. As soon as cache host A receives a request, it starts processing the request and notifies cache host B of the change. Then cache host B sends an acknowledgment back to cache host A. When cache host A receives the acknowledgment, it finishes the change and sends an acknowledgment back to the cache-enabled application. This process makes sure that the secondary copy of the object or region is always in the same state as the primary COPY. This process is referred to as strong consistency.

Performance Considerations

Because the cache host maintaining the secondary copy of the object or region must acknowledge all changes that pertain to the primary copy, there is a small performance cost in the response time of writes from the cache-enabled application. Note that this performance impact does not affect reads of items already in the cache. You should also consider the time required to reload the cache with objects if the cache host that maintains the primary copies of those objects is lost.

What Happens When a Cache Host Fails

If a cache host fails (assuming there are still a sufficient number of cache hosts available to keep the cluster running) nothing changes for the cache-enabled application (client). The cache cluster re-routes requests for the object to the cache host that maintained the secondary copy of the object.

Within the cluster, the secondary copies of all the primary objects are then elevated to become the new primary objects. Then, secondary copies of those new primary objects are distributed to other cache hosts across the cluster. Secondary objects on the cache host that failed are replaced by new secondary objects and distributed across the cluster. This process also applies to regions.

Evaluating App Fabric as a data store (Part-I)

High Availability for Windows Server AppFabric Caching (Part-II)

Happy Learning!