How Can You Test and Revert a Failover in Azure Cache for Redis Premium with Geo-Replication?

If you're using Azure Cache for Redis Premium with geo-replication across different regions, knowing how to test failover and revert it is essential to ensure your infrastructure can handle disasters seamlessly. In this article, we'll walk you through how to perform a manual failover test and revert it back using Azure Portal—helping you maintain operational stability between your cache instances in different regions.

Why Failover and Reverting Is Important?

Azure Cache for Redis Premium supports geo-replication, allowing you to replicate data between cache instances in different Azure regions. By testing the failover process, you can simulate disaster recovery scenarios where one region goes offline, and the other takes over automatically. Reverting back after a failover ensures that your original setup is restored without disruption once the primary region is available again.

In our case, we have two Redis caches:

• Primary cache located in Central US.
• Secondary cache located in East US 2.

Both caches are using Private Link endpoints to ensure secure and isolated connectivity.

Step 1: Testing the Failover in Azure Cache for Redis

Testing failover allows you to simulate a disaster recovery scenario where the secondary cache becomes the primary. Here’s how to do this through the Azure Portal:

1.1 Navigate to the Primary Redis Cache

• Log into the Azure portal.
• Search for Azure Cache for Redis and select your primary Redis cache (in Central US).

1.2 Access Geo-Replication Settings

• Under the Settings section of the Redis cache, select Geo-replication.
• You will see your secondary Redis cache (in East US 2) listed as a replica.

1.3 Initiate the Failover

• Click on the secondary Redis instance to open the details.
• At the top of the page, click Initiate Failover.

Once the failover is initiated, the secondary cache in East US 2 will become the new primary. This process typically takes a few minutes, and during that time, the new primary starts accepting traffic while the original primary goes into a secondary state.

1.4 Testing the New Primary

After the failover, test the new primary cache (East US 2) by writing and reading data to ensure that it's functioning correctly:

redis-cli -h <new-primary-private-endpoint> -a <new-primary-access-key> SET "test:key" "Data after failover" 

redis-cli -h <new-primary-private-endpoint> -a <new-primary-access-key> GET "test:key"

This verifies that the new primary cache is fully operational.

---

Step 2: Reverting the Failover to the Original Primary

Once the failover test is complete, you'll want to revert the setup to its original configuration, with Central US as the primary cache. Here’s how you can do that:

2.1 Break the Existing Geo-Replication

• Go to the new primary Redis cache (in East US 2).
• Navigate to Geo-replication under the Settings section.
• Click on the original primary cache (Central US) that is now secondary and select Unlink to break the geo-replication.

2.2 Re-establish the Original Setup

• Go to the original primary Redis cache (in Central US), which is now secondary.
• Select Geo-replication and click Add Replication.
• Choose the East US 2 Redis cache (the new primary) as the replica, and click Create.

This step promotes the Central US cache back to the primary, with the East US 2 cache becoming secondary again.

2.3 Verify and Test

Once geo-replication is re-established, write and read data from the Central US cache (the original primary) to confirm that the revert has worked successfully:

redis-cli -h <central-us-private-endpoint> -a <central-us-access-key> SET "revert-test:key" "Reverted to original primary" 

redis-cli -h <central-us-private-endpoint> -a <central-us-access-key> GET "revert-test:key"

Also, check the data consistency in the secondary cache (East US 2) to ensure replication is working:

redis-cli -h <east-us-2-private-endpoint> -a <east-us-2-access-key> GET "revert-test:key"

---

Conclusion

Testing and reverting failover in Azure Cache for Redis Premium is a critical part of maintaining a high-availability, disaster-ready infrastructure. By following the steps outlined, you can easily test failover scenarios and revert back to the original configuration—all within the Azure Portal.

Both the failover and revert processes ensure that your application remains resilient to regional outages, and help maintain data integrity and availability in your distributed systems. Make sure to monitor the health and performance of your Redis instances during the failover and reversion process to ensure optimal performance.

How Does a Private Endpoint Impact Redis Cache and Subnet Configuration in Azure?

Introduction

In Azure environments, using a Private Endpoint for services like Redis Cache ensures secure, private connections between resources. However, when configuring these endpoints, questions often arise regarding subnet usage, IP consumption, and overall networking best practices. This article addresses some common concerns and provides clarity on how to manage your subnets when working with Private Endpoints.

1. Where Can I See in the Azure Portal That My Private Endpoint Is Connected to a Subnet?

To verify which subnet your Private Endpoint is connected to, you can follow these steps in the Azure portal:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Search for your Redis Cache: In the search bar, type "Redis" and select your Redis Cache resource.
3. Access Private Endpoints: Under the "Settings" section, select Private Endpoint Connections to view the associated endpoints.
4. Check Subnet Details: Select the Private Endpoint and review the Network Configuration section to identify the subnet.

This straightforward process will give you insight into which subnet your Redis Cache's private endpoint is connected to.

2. Is It Fine to Have Other Components in the Same Subnet as My Redis Cache’s Private Endpoint?

Yes, it is typically fine to have multiple components in the same subnet as long as your network is properly configured. However, there are a few factors to consider:

• Subnet IP Address Range: Ensure that there are enough available IP addresses to accommodate all resources within the subnet, including the Redis Cache's private endpoint.
• Network Security Group (NSG): Double-check that your NSG rules do not block necessary traffic to and from the Redis Cache.
• Private DNS Zone: Make sure that the private DNS zone resolves the Redis Cache’s private endpoint correctly to ensure seamless internal communication.

Testing Redis Cache Connectivity

To ensure everything is working smoothly, you can test the Redis Cache using:

• Redis CLI: Try connecting to the Redis Cache using a client or the Redis CLI from a VM in the same virtual network and run commands like PING, SET, or GET.
• Azure Network Watcher: Use Connection Troubleshoot to test connectivity between the source (e.g., VM) and the Redis Cache private endpoint.
• Logs: Review Redis Cache logs to detect any potential connectivity issues.

3. How Many IPs Does Redis Cache Using a Private Endpoint Use in a Subnet?

When Redis Cache is connected via a Private Endpoint, it consumes one IP address in the subnet for each private endpoint. This IP address is assigned to the private link interface that connects the Redis Cache to the virtual network.

It's important to note that the Redis Cache service itself doesn't consume additional IPs directly from the subnet—only the Private Endpoint requires one. If you have multiple private endpoints for the same Redis Cache across different subnets or regions, each of those endpoints will also consume one IP address per subnet.

4. What Size Should My Subnet Be for a Redis Cache Private Endpoint?

Determining the correct subnet size is crucial for both current operations and future scalability. Here’s how you can plan:

IP Address Consumption

• Private Endpoint: Each private endpoint consumes 1 IP address.
• Azure Reserves: Azure reserves the first 4 and last 1 IP addresses of every subnet for internal use, leaving the rest for your resources.
• Other Resources: Any other VMs, application gateways, or services in the same subnet will consume additional IP addresses.

Subnet Size Calculation

Consider using the following CIDR blocks based on your needs:

• /28 gives 16 IP addresses (11 usable).
• /27 gives 32 IP addresses (27 usable).
• /26 gives 64 IP addresses (59 usable).
• /25 gives 128 IP addresses (123 usable).

For a Redis Cache private endpoint with minimal additional resources, a /28 subnet might suffice. However, for future scalability and more components, a /26 subnet is recommended.

5. Why Does Azure Reserve 5 IP Addresses in a Subnet?

Azure reserves 5 IP addresses in every subnet, regardless of size, for the following reasons:

1. First IP (Network address): This IP defines the subnet and is reserved for the network identifier.
2. Second IP: Reserved for Azure services.
3. Third IP: Reserved for future use by Azure.
4. Fourth IP (Default gateway): This IP is used as the default gateway for routing traffic outside the subnet.
5. Last IP (Broadcast address): Reserved as the broadcast address, though broadcast traffic isn't typically used in Azure.

For example, in a 10.0.0.0/24 subnet:

• 10.0.0.0 is the network identifier.
• 10.0.0.1 is reserved for Azure.
• 10.0.0.2 is reserved for future use.
• 10.0.0.3 is the default gateway.
• 10.0.0.255 is the broadcast address.

Conclusion

Configuring Redis Cache with Private Endpoints in Azure requires a solid understanding of how subnets, IP addresses, and networking rules work together. By following these guidelines, ensuring adequate subnet sizing, and testing your configuration, you can optimize performance and maintain secure connections.

Always monitor your subnet usage, plan for scalability, and review security configurations regularly to ensure smooth operations within your Azure environment. 

About Me

I’m Sujith Sagar Gandi, an IT professional with extensive experience in cloud architecture, networking, and infrastructure solutions. I specialize in configuring and managing Azure environments, with a focus on optimizing infrastructure for businesses and individuals alike. Sharing insights about cloud technologies is something I’m passionate about, and I aim to simplify complex concepts for others.

Feel free to connect with me on LinkedIn to follow my work and get in touch!