High Availability in Azure In-Role Cache
Updated: February 13, 2015
|For guidance on choosing the right Azure Cache offering for your application, see Which Azure Cache offering is right for me?.|
In-Role Cache allows you to maintain high availability for cached objects. Use the Azure role properties to enable high availability for each cache that requires this feature. No code changes are required; you need only to recalculate the required memory capacity for your workload. This can be done by turning on the High Availability setting in the capacity planning spreadsheet. For more information, see Capacity Planning Considerations for Azure In-Role Cache.
With high availability, cached objects are replicated within the same cloud service deployment for resiliency against hardware failure. Secondary copies are also placed across different fault domains and upgrade domains to increase availability. If one of the virtual machines in the cache cluster goes down for any reason, the cache cluster can use the secondary copies to prevent data loss.
High availability requires multiple instances of the associated role. A second copy of the cached item is maintained on a separate instance that belongs to a different fault domain and upgrade domain. That way if one instance goes down, a backup copy exists on another instance. In this scenario, the secondary copy is promoted to the primary copy. A new secondary copy is then made on one of the remaining instances to maintain high availability.
In order to implement high availability, all cache writes are made to both the primary and secondary copies.
|Note that even when high availability is disabled, the cache cluster attempts to preserve data during planned shutdowns, such as a reboot. In this scenario, the cache cluster attempts to transfer cached items to other servers before the shutdown. However, depending on the amount of data to transfer, this graceful shutdown is not guaranteed to complete. Also, unlike high availability, the data is not preserved during unexpected shutdowns.|
The role that hosts In-Role Cache should be configured to run on at least four instances. High availability can be enabled on roles that are configured for two or three running instances, but it is not recommended for the following two reasons.
Azure sometimes reboots virtual machines for routine maintenance. In-place updates of an application also take virtual machines offline. In both scenarios, it is better to have at least three servers in the cache cluster. That way if one of the servers goes down, the cache cluster still has three servers on which to make primary and secondary copies of cached objects. With only one running server, the cache is still accessible, but high availability is impossible.
Although three servers meet the previous requirement, four servers are recommended. This helps to more evenly distribute the primary copies across fault domains. This improves data distribution across the cache cluster, which also improves network traffic patterns and performance.
When an instance becomes unavailable, there is a short period of time where secondary copies are promoted to primary copies and routing information is updated. During that time, clients receive DataCacheException exceptions with an ErrorCode of RetryLater. In-Role Cache applications should use normal error handling and retry logic to correctly react to this condition.
Because all writes are made to both the primary and secondary copies, high availability increases latency and decreases throughput. This can be a reasonable trade-off for caches that benefit from high availability.
|By definition, the use of high availability multiplies the amount of required memory for each cached item by two. Consider this memory impact during capacity planning tasks. For more information, see Capacity Planning Considerations for Azure In-Role Cache.|
Double-click the role that has In-Role Cache enabled.
On the Configuration tab, verify that the Instance count is
On the Caching tab, select the High Availability checkbox for the cache that requires high availability. The following screenshot shows High Availability enabled for two of the three caches.