We are pleased to announce a public preview of the geo-replication functionality in the Azure Redis service. Geo-replication gives you the ability to link Redis caches across different Azure regions to form a primary-replica relationship. It provides an ingredient necessary for any disaster recovery design in your application. Geo-replication preview is available now for all premium Azure Redis caches. At present, we support having one primary cache and one replica in a geo-redundant configuration.
Configuring Azure Redis Caches for Geo-Replication
To setup geo-replication, you need two instances of Azure Redis premium cache belonging to one Azure subscription, one to be used as the primary and the other as the replica. You create the replica cache in exactly the same way that you have created the primary. The replica cache needs to be equal or bigger in size than the primary cache and, additionally, have a matching number of shards if the primary cache is clustered. While there is no requirement for the two caches to be located in different Azure regions, that is the most commonly expected case. If they reside in VNET(s), the caches must be able to reach each other. You can refer to this GitHub document for the current list requirements and restrictions for using geo-replication.
Once you have the Redis caches that you want to use for geo-replication, you can link them together in the Azure management portal. You start by selecting your primary cache. You then find the geo-replication option under the Settings for that cache. By default, when you choose geo-replication, it will show you any replica cache that has been linked to the primary cache. Since we are setting up geo-replication for the first time, no caches are associated yet.
You use “Add cache replication link” to create a uni-directional replicating relationship from the primary cache to the replica. Clicking on that button gives you a list of eligible caches that can be used for geo-replication, grouped by Azure regions. You can switch to a specific Azure region using either the world map or the Location list.
After you choose which cache to be used as the replica, you need to click on the “Link” button to finish the setup.
This will configure the primary cache to replicate data to the replica and disable all other “write” operations to the latter. It takes some time to set up everything and copy existing data in the primary cache. When that whole process is completed, you will see the change in the Azure portal.
Failing over to the replica
The Azure Redis service does not support automatic failover across Azure regions in the first release. Geo-replication is used primarily in a disaster recovery scenario. In such an event, customers will want to bring up the entire application stack in a backup region in a coordinated manner rather than letting individual application components decide when to switch to their backups on their own. This is especially relevant to Redis. One of the key benefits of Redis is being a very low-latency store. If Redis used by an application fails over to a different Azure region but not the compute tier, the added roundtrip time will have a noticeable impact on performance. For this reason, we would like to avoid Redis failing over automatically due to transient availability issues.
Currently, to initiate the failover, you need to unlink the replica cache from the primary in the Azure portal and change the connection end-point in the Redis client from the primary cache to the replica. You will be able to do this using the Azure management SDK’s and command-line tools soon, so that you can script and automate the sequence if needed. When the two caches are disassociated, the replica becomes a regular read-write cache again and accepts requests directly from Redis clients.
Understanding additional costs
There is no extra charge for using the geo-replication functionality in the Azure Redis service. Having said that, there will be additional costs associated with sending network traffic between the two Azure regions should your primary and replica caches be located in different regions. You should be aware of this standard charge for network communication that Azure applies.
We hope that you will find Azure Redis geo-replication useful to your application. If you have any feedback about this new feature, please feel free to reach out to us at AzureCache@microsoft.com.
Quelle: Azure
Published by