Scale an Azure Cache for Redis instance

Azure Cache for Redis has different tier offerings that provide flexibility in the choice of cache size and features. Through scaling, you can change the size, tier, and number of nodes after creating a cache instance to match your application needs. This article shows you how to scale your cache using the Azure portal, plus tools such as Azure PowerShell and Azure CLI.

Types of scaling

There are fundamentally two ways to scale an Azure Cache for Redis Instance:

• Scaling up increases the size of the Virtual Machine (VM) running the Redis server, adding more memory, Virtual CPUs (vCPUs), and network bandwidth. Scaling up is also called vertical scaling. The opposite of scaling up is Scaling down.

• Scaling out divides the cache instance into more nodes of the same size, increasing memory, vCPUs, and network bandwidth through parallelization. Scaling out is also referred to as horizontal scaling or sharding. The opposite of scaling out is Scaling in. In the Redis community, scaling out is frequently called clustering.

Scope of availability

When to scale

You can use the monitoring features of Azure Cache for Redis to monitor the health and performance of your cache. Use that information to determine when to scale the cache.

You can monitor the following metrics to determine if you need to scale.

• Redis Server Load
  • High Redis server load means that the server is unable to keep pace with requests from all the clients. Because a Redis server is a single threaded process, it's typically more helpful to scale out rather than scale up. Scaling out by enabling clustering helps distribute overhead functions across multiple Redis processes. Scaling out also helps distribute TLS encryption/decryption and connection/disconnection, speeding up cache instances using TLS.
  • Scaling up can still be helpful in reducing server load because background tasks can take advantage of the more vCPUs and free up the thread for the main Redis server process.
  • The Enterprise and Enterprise Flash tiers use Redis Enterprise rather than open source Redis. One of the advantages of these tiers is that the Redis server process can take advantage of multiple vCPUs. Because of that, both scaling up and scaling out in these tiers can be helpful in reducing server load. For more information, see Best Practices for the Enterprise and Enterprise Flash tiers of Azure Cache for Redis.
• Memory Usage
  • High memory usage indicates that your data size is too large for the current cache size. Consider scaling to a cache size with larger memory. Either scaling up or scaling out is effective here.
• Client connections
  • Each cache size has a limit to the number of client connections it can support. If your client connections are close to the limit for the cache size, consider scaling up to a larger tier. Scaling out doesn't increase the number of supported client connections.
  • For more information on connection limits by cache size, see Azure Cache for Redis Pricing.
• Network Bandwidth
  • If the Redis server exceeds the available bandwidth, clients requests could time out because the server can't push data to the client fast enough. Check "Cache Read" and "Cache Write" metrics to see how much server-side bandwidth is being used. If your Redis server is exceeding available network bandwidth, you should consider scaling out or scaling up to a larger cache size with higher network bandwidth.
  • For Enterprise tier caches using the Enterprise cluster policy, scaling out doesn't increase network bandwidth.
  • For more information on network available bandwidth by cache size, see Azure Cache for Redis planning FAQs.

For more information on determining the cache pricing tier to use, see Choosing the right tier and Azure Cache for Redis planning FAQs.

Prerequisites/limitations of scaling Azure Cache for Redis

You can scale up/down to a different pricing tier with the following restrictions:

• You can't scale from a higher pricing tier to a lower pricing tier.
  • You can't scale from an Enterprise or Enterprise Flash cache down to any other tier.
  • You can't scale from a Premium cache down to a Standard or a Basic cache.
  • You can't scale from a Standard cache down to a Basic cache.
• You can scale from a Basic cache to a Standard cache but you can't change the size at the same time. If you need a different size, you can later do a scaling operation to the wanted size.
• You can't scale from a Basic cache directly to a Premium cache. First, scale from Basic to Standard in one scaling operation, and then from Standard to Premium in the next scaling operation.
• You can't scale from a larger size down to the C0 (250 MB) size. However, you can scale down to any other size within the same pricing tier. For example, you can scale down from C5 Standard to C1 Standard.
• You can't scale from a Premium, Standard, or Basic cache up to an Enterprise or Enterprise Flash cache.
• You can't scale between Enterprise and Enterprise Flash.

You can scale out/in with the following restrictions:

• Scale out is only supported on the Premium, Enterprise, and Enterprise Flash tiers.
• Scale in is only supported on the Premium tier.
• On the Premium tier, clustering must be enabled first before scaling in or out.
• On the Premium tier, there is GA support for scale out up to 10 shards. Support for up to 30 shards is in preview. (For caches with two replicas, the shard limit is 20. With three replicas, shard limit is 15.)
• Only the Enterprise and Enterprise Flash tiers can scale up and scale out simultaneously.

How to scale - Basic, Standard, and Premium tiers

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

How to scale up and out - Enterprise and Enterprise Flash tiers

The Enterprise and Enterprise Flash tiers are able to scale up and scale out in one operation. Other tiers require separate operations for each action.

Scale using the Azure portal

1. To scale your cache, browse to the cache in the Azure portal and select Scale from the Resource menu.

   

2. To scale up, choose a different Cache type and then choose Save.

   Important

   You can only scale up at this time. You cannot scale down.

   

3. To scale out, increase the Capacity slider. Capacity increases in increments of two. This number reflects how many underlying Redis Enterprise nodes are being added. This number is always a multiple of two to reflect nodes being added for both primary and replica shards.

   Important

   You can only scale out, increasing capacity, at this time. You cannot scale in.

   

4. While the cache is scaling to the new tier, a Scaling Redis Cache notification is displayed.

   

5. When scaling is complete, the status changes from Scaling to Running.

Scale using PowerShell

You can scale your Azure Cache for Redis instances with PowerShell by using the Update-AzRedisEnterpriseCache cmdlet. You can modify the Sku property to scale the instance up. You can modify the Capacity property to scale out the instance. The following example shows how to scale a cache named myCache to an Enterprise E20 (25 GB) instance with capacity of 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Scale using Azure CLI

To scale your Azure Cache for Redis instances using Azure CLI, call the az redisenterprise update command. You can modify the sku property to scale the instance up. You can modify the capacity property to scale out the instance. The following example shows how to scale a cache named myCache to an Enterprise E20 (25 GB) instance with capacity of 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Scaling FAQ

The following list contains answers to commonly asked questions about Azure Cache for Redis scaling.

• Can I scale to, from, or within a Premium cache?
• After scaling, do I have to change my cache name or access keys?
• How does scaling work?
• Do I lose data from my cache during scaling?
• Can I use all the features of Premium tier after scaling?
• Is my custom databases setting affected during scaling?
• Will my cache be available during scaling?
• Are there scaling limitations with geo-replication?
• Operations that aren't supported
• How long does scaling take?
• How can I tell when scaling is complete?
• Do I need to make any changes to my client application to use clustering?
• How are keys distributed in a cluster?
• What is the largest cache size I can create?
• Do all Redis clients support clustering?
• How do I connect to my cache when clustering is enabled?
• Can I directly connect to the individual shards of my cache?
• Can I configure clustering for a previously created cache?
• Can I configure clustering for a basic or standard cache?
• Can I use clustering with the Redis ASP.NET Session State and Output Caching providers?
• I'm getting MOVE exceptions when using StackExchange.Redis and clustering, what should I do?
• What is the difference between OSS Clustering and Enterprise Clustering on Enterprise-tier caches?
• How many shards do Enterprise tier caches use?

Can I scale to, from, or within a Premium cache?

• You can't scale from a Premium cache down to a Basic or Standard pricing tier.
• You can scale from one Premium cache pricing tier to another.
• You can't scale from a Basic cache directly to a Premium cache. First, scale from Basic to Standard in one scaling operation, and then from Standard to Premium in a later scaling operation.
• You can't scale from a Premium cache to an Enterprise or Enterprise Flash cache.
• If you enabled clustering when you created your Premium cache, you can change the cluster size. If your cache was created without clustering enabled, you can configure clustering at a later time.

After scaling, do I have to change my cache name or access keys?

No, your cache name and keys are unchanged during a scaling operation.

How does scaling work?

• When you scale a Basic cache to a different size, it's shut down, and a new cache is provisioned using the new size. During this time, the cache is unavailable and all data in the cache is lost.
• When you scale a Basic cache to a Standard cache, a replica cache is provisioned and the data is copied from the primary cache to the replica cache. The cache remains available during the scaling process.
• When you scale a Standard, Premium, Enterprise, or Enterprise Flash cache to a different size, one of the replicas is shut down and reprovisioned to the new size and the data transferred over, and then the other replica does a failover before it's reprovisioned, similar to the process that occurs during a failure of one of the cache nodes.
• When you scale out a clustered cache, new shards are provisioned and added to the Redis server cluster. Data is then resharded across all shards.
• When you scale in a clustered cache, data is first resharded and then cluster size is reduced to required shards.
• In some cases, such as scaling or migrating your cache to a different cluster, the underlying IP address of the cache can change. The DNS record for the cache changes and is transparent to most applications. However, if you use an IP address to configure the connection to your cache, or to configure NSGs, or firewalls allowing traffic to the cache, your application might have trouble connecting sometime after the DNS record updates.

Do I lose data from my cache during scaling?

• When you scale a Basic cache to a new size, all data is lost and the cache is unavailable during the scaling operation.
• When you scale a Basic cache to a Standard cache, the data in the cache is typically preserved.
• When you scale a Standard, Premium, Enterprise, or Enterprise Flash cache to a larger size, all data is typically preserved. When you scale a Standard or Premium cache to a smaller size, data can be lost if the data size exceeds the new smaller size when it's scaled down. If data is lost when scaling down, keys are evicted using the allkeys-lru eviction policy.

Can I use all the features of Premium tier after scaling?

No, some features can only be set when you create a cache in Premium tier, and are not available after scaling.

These features cannot be added after you create the Premium cache:

• VNet injection
• Adding zone redundancy
• Using multiple replicas per primary

To use any of these features, you must create a new cache instance in the Premium tier.

Is my custom databases setting affected during scaling?

If you configured a custom value for the databases setting during cache creation, keep in mind that some pricing tiers have different databases limits. Here are some considerations when scaling in this scenario:

• When you scale to a pricing tier with a lower databases limit than the current tier:
  • If you're using the default number of databases, which is 16 for all pricing tiers, no data is lost.
  • If you're using a custom number of databases that falls within the limits for the tier to which you're scaling, this databases setting is kept and no data is lost.
  • If you're using a custom number of databases that exceeds the limits of the new tier, the databases setting is lowered to the limits of the new tier and all data in the removed databases is lost.
• When you scale to a pricing tier with the same or higher databases limit than the current tier, your databases setting is kept and no data is lost.

While Standard, Premium, Enterprise, and Enterprise Flash caches have a SLA for availability, there's no SLA for data loss.

Will my cache be available during scaling?

• Standard, Premium, Enterprise, and Enterprise Flash caches remain available during the scaling operation. However, connection blips can occur while scaling these caches, and also while scaling from Basic to Standard caches. These connection blips are expected to be small and redis clients can generally re-establish their connection instantly.
• For Enterprise and Enterprise Flash caches using active geo-replication, scaling only a subset of linked caches can introduce issues over time in some cases. We recommend scaling all caches in the geo-replication group together where possible.
• Basic caches are offline during scaling operations to a different size. Basic caches remain available when scaling from Basic to Standard but might experience a small connection blip. If a connection blip occurs, Redis clients can generally re-establish their connection instantly.

Are there scaling limitations with geo-replication?

With passive geo-replication configured, you might notice that you can’t scale a cache or change the shards in a cluster. A geo-replication link between two caches prevents you from scaling operation or changing the number of shards in a cluster. You must unlink the cache to issue these commands. For more information, see Configure Geo-replication.

With active geo-replication configured, you can't scale a cache. All caches in a geo replication group must be the same size and capacity.

Operations that aren't supported

• You can't scale from a higher pricing tier to a lower pricing tier.
  • You can't scale from a Premium cache down to a Standard or a Basic cache.
  • You can't scale from a Standard cache down to a Basic cache.
• You can scale from a Basic cache to a Standard cache but you can't change the size at the same time. If you need a different size, you can do a scaling operation to the size you want at a later time.
• You can't scale from a Basic cache directly to a Premium cache. First scale from Basic to Standard in one scaling operation, and then scale from Standard to Premium in a later operation.
• You can't scale from a Premium cache to an Enterprise or Enterprise Flash cache.
• You can't scale from a larger size down to the C0 (250 MB) size.

If a scaling operation fails, the service tries to revert the operation, and the cache will revert to the original size.

How long does scaling take?

Scaling time depends on a few factors. Here are some factors that can affect how long scaling takes.

• Amount of data: Larger amounts of data take a longer time to be replicated
• High write requests: Higher number of writes mean more data replicates across nodes or shards
• High server load: Higher server load means Redis server is busy and has limited CPU cycles to complete data redistribution

Generally, when you scale a cache with no data, it takes approximately 20 minutes. For clustered caches, scaling takes approximately 20 minutes per shard with minimal data.

How can I tell when scaling is complete?

In the Azure portal, you can see the scaling operation in progress. When scaling is complete, the status of the cache changes to Running.

Do I need to make any changes to my client application to use clustering?

• When clustering is enabled, only database 0 is available. If your client application uses multiple databases and it tries to read or write to a database other than 0, the following exception is thrown: Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET ---> StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  For more information, see Redis Cluster Specification - Implemented subset.

• If you're using StackExchange.Redis, you must use 1.0.481 or later. You connect to the cache using the same endpoints, ports, and keys that you use when connecting to a cache where clustering is disabled. The only difference is that all reads and writes must be done to database 0.

  Other clients may have different requirements. See Do all Redis clients support clustering?

• If your application uses multiple key operations batched into a single command, all keys must be located in the same shard. To locate keys in the same shard, see How are keys distributed in a cluster?

• If you're using Redis ASP.NET Session State provider, you must use 2.0.1 or higher. See Can I use clustering with the Redis ASP.NET Session State and Output Caching providers?

How are keys distributed in a cluster?

Per the Redis documentation on Keys distribution model: The key space is split into 16,384 slots. Each key is hashed and assigned to one of these slots, which are distributed across the nodes of the cluster. You can configure which part of the key is hashed to ensure that multiple keys are located in the same shard using hash tags.

• Keys with a hash tag - if any part of the key is enclosed in { and }, only that part of the key is hashed for the purposes of determining the hash slot of a key. For example, the following three keys would be located in the same shard: {key}1, {key}2, and {key}3 since only the key part of the name is hashed. For a complete list of keys hash tag specifications, see Keys hash tags.
• Keys without a hash tag - the entire key name is used for hashing, resulting in a statistically even distribution across the shards of the cache.

For best performance and throughput, we recommend distributing the keys evenly. If you're using keys with a hash tag, it's the application's responsibility to ensure the keys are distributed evenly.

For more information, see Keys distribution model, Redis Cluster data sharding, and Keys hash tags.

For sample code about working with clustering and locating keys in the same shard with the StackExchange.Redis client, see the clustering.cs portion of the Hello World sample.

What is the largest cache size I can create?

The largest cache size you can have is 4.5 TB. This result is a clustered F1500 cache with capacity 9. For more information, see Azure Cache for Redis Pricing.

Do all Redis clients support clustering?

Many clients libraries support Redis clustering but not all. Check the documentation for the library you're using to verify you're using a library and version that support clustering. StackExchange.Redis is one library that does support clustering, in its newer versions. For more information on other clients, see the Playing with the cluster section of the Redis cluster tutorial.

The Redis clustering protocol requires each client to connect to each shard directly in clustering mode, and also defines new error responses such as 'MOVED' na 'CROSSSLOTS'. When you attempt to use a client library that doesn't support clustering, with a cluster mode cache, the result can be many MOVED redirection exceptions, or just break your application, if you're doing cross-slot multi-key requests.

How do I connect to my cache when clustering is enabled?

You can connect to your cache using the same endpoints, ports, and keys that you use when connecting to a cache that doesn't have clustering enabled. Redis manages the clustering on the backend so you don't have to manage it from your client.

Can I directly connect to the individual shards of my cache?

The clustering protocol requires the client to make the correct shard connections, so the client should make share connections for you. With that said, each shard consists of a primary/replica cache pair, collectively known as a cache instance. You can connect to these cache instances using the Redis-CLI utility in the unstable branch of the Redis repository at GitHub. This version implements basic support when started with the -c switch. For more information, see Playing with the cluster on https://redis.io in the Redis cluster tutorial.

You need to use the -p switch to specify the correct port to connect to. Use the CLUSTER NODES command to determine the exact ports used for the primary and replica nodes. The following port ranges are used:

• For non-TLS Premium tier caches, ports are available in the 130XX range
• For TLS enabled Premium tier caches, ports are available in the 150XX range
• For Enterprise and Enterprise Flash caches using OSS clustering, the initial connection is through port 10000. Connecting to individual nodes can be done using ports in the 85XX range. The 85xx ports will change over time and shouldn't be hardcoded into your application.

Can I configure clustering for a previously created cache?

Yes. First, ensure that your cache is in the Premium tier by scaling it up. Next, you can see the cluster configuration options, including an option to enable cluster. Change the cluster size after the cache is created, or after you have enabled clustering for the first time.

All Enterprise and Enterprise Flash tier caches are always clustered.

Can I configure clustering for a basic or standard cache?

Clustering is only available for Premium, Enterprise, and Enterprise Flash caches.

Can I use clustering with the Redis ASP.NET Session State and Output Caching providers?

• Redis Output Cache provider - no changes required.
• Redis Session State provider - to use clustering, you must use RedisSessionStateProvider 2.0.1 or higher or an exception is thrown, which is a breaking change. For more information, see v2.0.0 Breaking Change Details.

I'm getting MOVE exceptions when using StackExchange.Redis and clustering, what should I do?

If you're using StackExchange.Redis and receive MOVE exceptions when using clustering, ensure that you're using StackExchange.Redis 1.1.603 or later. For instructions on configuring your .NET applications to use StackExchange.Redis, see Configure the cache clients.

What is the difference between OSS Clustering and Enterprise Clustering on Enterprise tier caches?

OSS Cluster Mode is the same as clustering on the Premium tier and follows the open source clustering specification. Enterprise Cluster Mode can be less performant, but uses Redis Enterprise clustering, which doesn't require any client changes to use. For more information, see Clustering on Enterprise.

How many shards do Enterprise tier caches use?

Unlike Basic, Standard, and Premium tier caches, Enterprise and Enterprise Flash caches can take advantage of multiple shards on a single node. For more information, see Sharding and CPU utilization.

Next steps

• Configure your maxmemory-reserved setting
• Best practices for scaling