Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://learn.microsoft.com/azure/azure-cache-for-redis/cache-how-to-scale below:

Scale an Azure Cache for Redis instance - Azure Cache for Redis

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.

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.

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

• Scale up and down with Basic, Standard, and Premium
• Scale out and in - Premium only

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

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

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

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.

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.

To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command. Use the sku.capacity 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 completes.

Clustering is enabled during cache creation from the working pane, when you create a new Azure Cache for Redis.

1. Use the Create an open-source Redis cache quickstart guide to start creating a new cache using the Azure portal.

2. In the Advanced tab for a premium cache instance, configure the settings for non-TLS port, clustering, and data persistence. To enable clustering, select Enable.

   You can have up to 30 shards in the cluster. After selecting Enable, slide the slider or type a number between 1 and 30 for Shard count and select OK.

   Each shard is a primary/replica cache pair managed by Azure. The total size of the cache is calculated by multiplying the number of shards by the cache size selected in the pricing tier.

   Once the cache is created, you connect to it and use it just like a nonclustered cache. Redis distributes the data throughout the Cache shards. If diagnostics is enabled, metrics are captured separately for each shard and can be viewed in Azure Cache for Redis using the Resource menu.

3. Finish creating the cache using the quickstart guide.

It takes a while for the cache to create. You can monitor progress on the Azure Cache for Redis Overview page. When Status shows as Running, the cache is ready to use.

For sample code on working with clustering with the StackExchange.Redis client, see the clustering.cs portion of the Hello World sample.

To change the cluster size on a premium cache that you created earlier, and is already running with clustering enabled, select Cluster size from the Resource menu.

To change the cluster size, use the slider or type a number between 1 and 30 in the Shard count text box. Then, select OK to save.

Increasing the cluster size increases max throughput and cache size. Increasing the cluster size doesn't increase the max. connections available to clients.

You can scale out your Azure Cache for Redis instances with PowerShell by using the Set-AzRedisCache cmdlet when the ShardCount property is modified. The following example shows how to scale out a cache named myCache out to use three shards (that is, scale out by a factor of three)

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

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

To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command and use the shard-count property. The following example shows how to scale out a cache named myCache to use three shards (that is, scale out by a factor of three).

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

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 programmatically (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 completes.

Note

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 don't yet support scale down or scale in operations.

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 can't 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 can't 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.

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

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

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?
• Is my cache 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?

• 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.

No, your cache name and keys don't change during a scaling operation.

• 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.
• When 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 configure NSGs or firewalls that allow traffic to the cache, your application might have trouble connecting after the DNS record updates.

• 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 original data size exceeds the new smaller size. If data is lost when scaling down, keys are evicted using the allkeys-lru eviction policy.

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:

• Injecting virtual networks
• 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.

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.

• 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.

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 scale a cache with some limitations. All caches in a geo-replication group must be the same size and capacity. For more information, see Configure active geo-replication for Enterprise Azure Cache for Redis instances.

• 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.

Scaling time depends on a few factors. The following factors can affect how long scaling takes:

• Amount of data: Larger amounts of data take a longer time to replicate.
• 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 isn't a trivial action and can take a long time. It can take one to two hours to scale a cache with one to two shards when it isn't under heavy loads. If you have more shards, the time to scale doesn't increase in a linear way.

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

• When clustering is enabled, only database 0 is available. If your client application uses multiple databases and tries to read or write to a database other than zero, the following exception occurs: 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 might have different requirements. See Do all Redis clients support clustering? for more information.

• 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? for more information.

Important

When using the Enterprise or Enterprise FLash tiers, you're 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.

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.

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.

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 making cross-slot multi-key requests.

Note

If you're using StackExchange.Redis as your client, verify that you're 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.

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.

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.

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.

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

• 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.

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.

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.

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 configuration.

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4