Rediger

Del via

Scale an Azure Cache for Redis instance

  • Artikkel

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

Tier Basic and Standard Premium Enterprise and Enterprise Flash
Scale Up Yes Yes Yes
Scale Down Yes Yes No
Scale Out No Yes Yes
Scale In No Yes No

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 the Redis server process can take advantage of multiple vCPUs. With multiple vCPUs, 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. To see how much server-side bandwidth is being used, check "Cache Read" and "Cache Write" metrics. 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.
  • Internal Defender Scans
    • On C0 and C1 Standard caches, while internal Defender scanning is running on the VMs, you might see short spikes in server load not caused by an increase in cache requests. You see higher latency for requests while internal Defender scans are run on these tiers a couple of times a day. Caches on the C0 and C1 tiers only have a single core to multitask, dividing the work of serving internal Defender scanning and Redis requests. You can reduce the effect by scaling to a higher tier offering with multiple CPU cores, such as C2.
    • The increased cache size on the higher tiers helps address any latency concerns. Also, at the C2 level, you have support for as many as 2,000 client connections.

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

Note

For more information on how to optimize the scaling process, see the best practices for scaling guide

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 in to the C0 (250 MB) size. However, you can scale in to any other size within the same pricing tier. For example, you can scale in 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, support for scale out up to 10 shards is generally available. 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

Scale up and down using the Azure portal

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

    Screenshot showing Scale on the resource menu.

  2. Choose a pricing tier in the working pane and then choose Select.

    Screenshot showing the Azure Cache for Redis tiers.

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

    Screenshot showing the notification of scaling.

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

Note

When you scale a cache up or down using the portal, both maxmemory-reserved and maxfragmentationmemory-reserved settings automatically scale in proportion to the cache size. For example, if maxmemory-reserved is set to 3 GB on a 6-GB cache, and you scale to 12-GB cache, the settings automatically get updated to 6 GB during scaling. When you scale down, the reverse happens.

Scale up and down using PowerShell

You can scale your Azure Cache for Redis instances with PowerShell by using the Set-AzRedisCache cmdlet when the Sizeor Sku properties are modified. The following example shows how to scale a cache named myCache to a 6-GB cache in the same tier.

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

For more information on scaling with PowerShell, see To scale an Azure Cache for Redis using PowerShell.

Scale up and down using Azure CLI

To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command. Use the sku.capcity property to scale within a tier, for example from a Standard C0 to Standard C1 cache:

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

Use the 'sku.name' and 'sku.family' properties to scale up to a different tier, for instance from a Standard C1 cache to a Premium P1 cache:

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

For more information on scaling with Azure CLI, see Change settings of an existing Azure Cache for Redis.

Note

When you scale a cache up or down programatically (e.g. using PowerShell or Azure CLI), any maxmemory-reserved or maxfragmentationmemory-reserved are ignored as part of the update request. Only your scaling change is honored. You can update these memory settings after the scaling operation has completed.

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.

Caution

The Enterprise and Enterprise Flash tiers do not yet support scale down or scale in operations.

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.

    Screenshot showing Scale selected in the Resource menu for an Enterprise cache.

  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.

    Screenshot showing the Enterprise tiers in the working pane.

  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.

    Screenshot showing Capacity in the working pane a red box around it.

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

    Screenshot showing notification of scaling an Enterprise cache.

  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?

  • 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, the cache is 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 the cache is 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 aren't available after scaling.

These features can't be added after you create the Premium cache:

  • Virtual network 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 reverts 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 the Redis server is busy and limited CPU cycles are available to complete data redistribution

Scaling a cache is non-trivial action and can take a long time.

Based on real world examples, the time to scale cache with one to two shards can be 1 to 2 hours when the cache is not under heavy loads.If you have more shards, the time to scale doesn't increase in a linear way.

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?

Important

When using the Enterprise or Enterprise FLash tiers, you are given the choice of OSS Cluster Mode or Enterprise Cluster Mode. 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 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.

Note

If you're using StackExchange.Redis as your client, verify that you are using the latest version of StackExchange.Redis 1.0.481 or later for clustering to work correctly. For more information on any issues with move exceptions, see move exceptions.

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 enable clustering for the first time.

Important

You can't undo enabling clustering. And a cache with clustering enabled and only one shard behaves differently than a cache of the same size with no clustering.

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?

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