BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Microsoft Announce General Availability of Azure Redis Cache Geo-Replication

Microsoft Announce General Availability of Azure Redis Cache Geo-Replication

This item in japanese

Bookmarks

Microsoft recently announced the general availability of geo-replication support for the Azure Redis Cache service, Microsoft’s hosted implementation of the open-source Redis cache. The announcement follows a public preview that was announced in June 2017.

The geo-replication support requires two instances of Azure Redis Cache, one acting as a primary cache and one acting as a secondary cache. There is no requirement to have the replica in a different region to the primary cache, but doing so provides resilience in the situation where the primary cache region is not available. In the current implementation it is only possible to replicate to a single region. The secondary cache is read-only for applications with the writing handled asynchronously by the service.

Geo-replication is configured by linking the primary and secondary caches through the Azure Portal.

Image source: https://docs.microsoft.com/en-us/azure/redis-cache/cache-how-to-geo-replication#add-a-geo-replication-link

There are some prerequisites that must be met before geo-replication can be configured:

  • The caches must be in the Premium tier
  • The caches must be in the same subscription
  • The secondary cache must be either the same pricing tier or a larger pricing tier than the primary linked cache
  • If the primary cache is clustered, the secondary cache must also be clustered with the same number of shards
  • The caches must both be running
  • Redis persistence must not be enabled for either cache

Azure Redis Cache geo-replication does not currently support automatic failover between the primary and secondary cache. This introduces a manual step that requires application configuration changes and can mean some downtime for a service. Ye Gu, principal program manager at Microsoft, provides an explanation in the blog post:

…the physical distance between two Azure Regions can add significant delays to the overall response time. Because of that, Azure Redis Cache will not automatically failover to a geo-replicated cache in another Region.

Failover is managed by unlinking the secondary cache from the primary cache. Once unlinked, the secondary cache becomes the new primary cache and can accept write requests.

The service faces competition from other cloud vendors, including Amazon, Heroku and Redis directly.

Amazon AWS ElastiCache supports multizone geo-replication through the Multi-AZ with automatic failure functionality. Like Azure Redis Cache, the failover step is not immediate and can take a few minutes before being operational, but it is automatic and will reconfigure DNS settings to reduce the need for application reconfiguration.

Heroku Redis supports high availability by having a standby replica in a second availability zone. It supports automatic failover in a similar fashion to AWS ElastiCache, and like AWS is not immediate, as it tries to ensure that the primary is no longer available rather than simply experiencing a transient outage. At higher tiers of the service, failover is transparent for the applications using it.

The Redis Enterprise Cloud solution supports multi-region like AWS ElastiCache, but claims a failover time of seconds rather than minutes, and operates as "serverless" rather than instance-based like the other major vendors.

The Azure Redis Cache functionality is only available on the Premium tier of the service. The cost is dependent on the level of Premium tier, with current pricing ranging from around $400/month for the P1 tier to over $3,200/month for the P4 tier. Whilst the service itself is free, you do need two instances on the same tier or have the secondary on a higher tier. In addition, if the secondary cache is in a different region, as suggested by Microsoft, the service will incur additional data egress charges for the synchronization between the primary and secondary cache instances.

Rate this Article

Adoption
Style

BT