Skip to content

Commit edc551c

Browse files
committed
edit PM contribution
1 parent 4eb99e8 commit edc551c

File tree

1 file changed

+25
-36
lines changed

1 file changed

+25
-36
lines changed

articles/redis/how-to-scale.md

Lines changed: 25 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,8 @@ Azure Managed Redis supports scaling in two dimensions:
2929

3030
- **Memory** Increasing memory increases the size of the Redis instance, allowing you to store more data. When reducing the memory, you need to ensure that your current memory usage is less than new memory size you want to use.
3131

32-
- **vCPUs** Azure Managed Redis offers three tiers (_Memory Optimized_, _Balanced_, and _Compute Optimized_) that have an increasing number of vCPUs for each level of memory. Scaling to a tier with more vCPUs increases the performance of your instance without requiring you to increase memory. Unlike the community edition of Redis, which can only utilize a single vCPU, Azure Managed Redis uses the Redis Enterprise stack, which is able to use multiple vCPUs. This means that the number of vCPUs used by your Redis instance directly correlates with throughput and latency performance.
32+
- **vCPUs** Azure Managed Redis offers three tiers (_Memory Optimized_, _Balanced_, and _Compute Optimized_) that have an increasing number of vCPUs for each level of memory. Scaling to a tier with more vCPUs increases the performance of your instance without requiring you to increase memory. Unlike the community edition of Azure Cache for Redis, which can only utilize a single vCPU, Azure Managed Redis uses the Redis Enterprise stack, which is able to use multiple vCPUs. This means that the number of vCPUs used by your Redis instance directly correlates with throughput and latency performance.
33+
<!-- Community edition means what here? Basic, Standard and Premium? -->
3334

3435
## Performance tiers
3536

@@ -45,6 +46,8 @@ One tier stores data both in-memory and on-disk:
4546

4647
- _Flash Optimized_. Enables Redis clusters to automatically move less frequently accessed data from memory (RAM) to NVMe storage. This reduces performance, but allows for cost-effective scaling of caches with large datasets.
4748

49+
[!INCLUDE [tier-preview](includes/tier-preview.md)]
50+
4851
## Tiers and SKUs at glance
4952

5053
:::image type="content" source="media/how-to-scale/tier-diagram.png" alt-text="Table showing the different memory and vCPU configurations for each SKU and tier of Azure Managed Redis.":::
@@ -60,9 +63,9 @@ You can use the [monitoring](monitor-cache.md) features of Azure Managed Redis t
6063
You can monitor the following metrics to determine if you need to scale.
6164

6265
- **CPU**
63-
- High CPU usage means that the Redis server is unable to keep pace with requests from all the clients. Scaling up to more vCPUs helps distribute requests across multiple Redis processes. Scaling also helps distribute TLS encryption/decryption and connection/disconnection, speeding up cache instances using TLS.
66+
- High CPU usage means that the Redis server is unable to keep pace with requests from all the clients. Scaling to more vCPUs helps distribute requests across multiple Redis processes. Scaling also helps distribute TLS encryption/decryption and connection/disconnection, speeding up cache instances using TLS.
6467
- **Memory Usage**
65-
- 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. When reducing the memory, you need to ensure that your current memory usage is less than new memory size you want to use.
68+
- 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. When reducing the memory, you need to ensure that your memory usage or your current cache is lower than new memory size you want to use. You cannot put a large data set into a smaller cache size.
6669
- **Client connections**
6770
- 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 to a larger memory size or a higher performance tier.
6871
- For more information on connection limits by cache size, see [Performance testing with Azure Managed Redis](best-practices-performance.md).
@@ -73,19 +76,18 @@ You can monitor the following metrics to determine if you need to scale.
7376

7477
For more information on determining the cache pricing tier to use, see [Choosing the right tier](overview.md#choosing-the-right-tier).
7578

76-
> [!NOTE]
77-
> For more information on how to optimize the scaling process, see the [best practices for scaling guide](best-practices-scale.md)
78-
>
79+
For more information on how to optimize the scaling process, see the [best practices for scaling guide](best-practices-scale.md)
7980

8081
## Limitations of scaling Azure Managed Redis
8182

8283
- You can't scale from the **Memory Optimized**, **Balanced**, or **Compute Optimized** tiers to the **Flash Optimized** tier, or vice-versa.
83-
- When reducing the memory for your Redis instance, the current memory usage of your Redis instance should be less than the intended new memory size. See [this](#what-will-happen-to-my-data-if-i-scale-to-smaller-memory-size) for more details.
84-
- When reducing the memory or vCPU for your Redis instance, you can only scale to SKUs which have a vCPU and shard configuration that is compatible with the configuration on your current instance. See this [table](add link) for a guideline on which SKUs can you scale down your Redis instance to.
84+
- When reducing the memory for your Redis instance, the current memory usage of your Redis instance should be less than the intended new memory size. For more details, see [What will happen to my data if I scale to smaller memory size?](#what-will-happen-to-my-data-if-i-scale-to-smaller-memory-size).
85+
- When reducing the memory or vCPU for your Redis instance, you can only scale to SKUs which have a vCPU and shard configuration that is compatible with the configuration on your current instance.
86+
<!-- We removed the table so we need to find a way convey this information -->
8587
- In some cases when scaling, the underlying IP address of the Redis instance can change. The DNS record for the instance changes and is transparent to most applications. However, if you use an IP address to configure the connection to your Redis instance, or to configure NSGs, or firewalls allowing traffic to the Redis instance, your application might have trouble connecting sometime after the DNS record updates.
8688
- Scaling an instance in a geo-replication group has some more limitations. See [Are there scaling limitations with geo-replication?](#are-there-scaling-limitations-with-geo-replication) for more information.
8789

88-
## How to scale
90+
## How to scale (preview)
8991

9092
### Scale using the Azure portal
9193

@@ -94,16 +96,17 @@ For more information on determining the cache pricing tier to use, see [Choosing
9496
:::image type="content" source="media/how-to-scale/managed-redis-enterprise-scale.png" alt-text="Screenshot showing Scale selected in the Resource menu for an Enterprise cache.":::
9597

9698
1. To scale your vCPUs, choose a different **Cache type** and then choose **Save**.
99+
97100
> [!IMPORTANT]
98-
> If you select a SKU that cannot be scaled to, the **Save** option is disabled. Review the [Limitations of scaling Azure Managed Redis](#prerequisiteslimitations-of-scaling-azure-managed-redis) section for details on which scaling options are allowed.
101+
> If you select a SKU that cannot be scaled to, the **Save** option is disabled. Review the [Limitations of scaling Azure Managed Redis](#limitations-of-scaling-azure-managed-redis) section for details on which scaling options are allowed.
99102
100103
:::image type="content" source="media/how-to-scale/managed-redis-enterprise-scale-up.png" alt-text="Screenshot showing the Enterprise tiers in the working pane.":::
101104

102105
1. While the cache is scaling to the new tier, a **Scaling Redis Cache** notification is displayed.
103106

104107
:::image type="content" source="media/how-to-scale/managed-redis-enterprise-notifications.png" alt-text="Screenshot showing notification of scaling an Enterprise cache.":::
105108

106-
1. When scaling is complete, the status on the Overview blade changes from **Scaling** to **Running**.
109+
1. When scaling is complete, the status changes from **Scaling** to **Running** when viewing the **Overview** section of the Resource menu.
107110

108111
### Scale using PowerShell
109112

@@ -142,45 +145,31 @@ The following list contains answers to commonly asked questions about Azure Mana
142145

143146
### Can I scale within or across tiers?
144147

145-
You can always scale to a higher performance tier at the same memory size or a larger memory size within the same performance tier. For scaling to a lower performance tier or smaller memory size, see the table below for SKUs that your cluster can scale to. Please note that this table is just a guidance and we recommend you run the "listskusforscaling" REST API to get the list of SKUs that you can scale to.
146-
147-
| **Size (GB)** | **Memory Optimized** | **Balanced** | **Compute Optimized** |
148-
|---------------|----------------------------------------------------------------------------------|--------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
149-
| **0.5** | - | - | - |
150-
| **1** | - | B0 | - |
151-
| **3** | | B1, B0 | B3, B1, B0 |
152-
| **6** | B5, B3, B1, B0<br>X5, X3 | M10<br>B5, B3, B1, B0<br>X5, X3 | M10<br>B10, B5, B3, B1, B0<br>X5, X3 |
153-
| **12** | M10<br>B10, B5, B3, B1, B0<br>X10, X5, X3 | M20, M10<br>B10, B5, B3, B1, B0<br>X10, X5, X3 | M20, M10<br>B20, B10, B5, B3, B1, B0<br>X10, X5, X3 |
154-
| **24** | M20, M10<br>B20, B10, B5, B3, B1, B0<br>X20, X10, X5, X3 | M50, M20, M10<br>B20, B10, B5, B3<br>X20, X10, X5, X3 | M50<br>B50, B20<br>X20, X10 |
155-
| **60** | M50, M20, M10<br>B50, B20, B10, B5, B3<br>X50, X20, X10, X5, X3 | M100, M50<br>B50, B20<br>X20, X10 | M100<br>B100, B50<br>X50, X20 |
156-
| **120** | M100, M50<br>B100, B50, B20<br>X100, X50, X20, X10 | M150, M100<br>B100, B50<br>X100, X50, X20 | M150<br>B150, B100<br>X100, X50 |
157-
| **180** | M150, M100, M50<br>B150, B100, B50, B20<br>X150, X100, X50, X20, X10 | M200, M150, M100<br>B150, B100, B50<br>X150, X100, X50, X20 | M200, M150<br>B200, B150, B100<br>X150, X100, X50 |
158-
| **240** | M200, M150, M100<br>B200, B150, B100, B50<br>X200, X150, X100, X50, X20 | M350, M200, M150, M100<br>B200, B150, B100<br>X200, X150, X100, X50 | M350<br>B350, B200, B150<br>X200, X150, X100 |
159-
| **360** | M350, M200, M150, M100<br>B350, B200, B150, B100, B50<br>X350, X200, X150, X100 | M500, M350, M200, M150<br>B350, B200, B150, B100<br>X350, X200, X150, X100, X50 | M500, M350<br>B350, B200, B150<br>X350, X200, X150, X100 |
160-
| **480** | M500, M350, M200, M150<br>B500, B350, B200, B150, B100<br>X500, X350, X200, X150, X100, X50 | M700, M500, M350<br>B500, B350, B200, B150<br>X350, X200, X150, X100 | M700, M500, M350<br>B350, B200, B150<br>X500, X350, X200, X150, X100 |
161-
| **720** | M700, M500, M350, M200, M150<br>B700, B500, B350, B200, B150, B100<br>X700, X500, X350, X200, X150, X100, X50 | M1000, M700, M500, M350<br>B1000, B700, B500, B350, B200, B150<br>X700, X500, X350, X200, X150, X100 | |
162-
| **960** | M1000, M700, M500, M350<br>B1000, B700, B500, B350, B200, B150<br>X700, X500, X350, X200, X150, X100 | - | |-
163-
| **1440** | M1000, M700, M500, M350<br>B1000, B700, B500, B350, B200, B150<br>X700, X500, X350, X200, X150, X100 | - | - |
148+
You can always scale to a higher performance tier at the same memory size or a larger memory size within the same performance tier. For scaling to a lower performance tier or smaller memory size, we recommend you run the "listskusforscaling" REST API to get the list of SKUs that you can scale to.
149+
<!-- Perhaps we can add some code or cli commands to show this. -->
164150

165151
### What will happen to my data if I scale to smaller memory size?
166152

167-
You can scale to a smaller memory size only if the current memory usage is less than the intended smaller memory size. If the current memory usage is higher than the intended smaller size, your scaling request will fail. You can reduce the current memory usage by deleted unwanted key value pairs or by running the flush operation. (Add link)
153+
You can scale to a smaller memory size only if the current memory usage is less than the intended smaller memory size. If the current memory usage is higher than the intended smaller size, your scaling request will fail. You can reduce the current memory usage by deleted unwanted key value pairs or by running the flush operation.
154+
155+
<!-- (Add link) -->
168156

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

171-
No, your cache name and keys are unchanged during a scaling operation.
159+
No, your cache name and access keys are not changed during a scaling operation.
172160

173161
### How does scaling work?
174162

175-
- When you scale a Redis instance, one of the nodes in the Redis cluster is shut down and reprovisioned to the new size. Then data transferred over, and then the other node does a similar failover before it's reprovisioned. This is similar to the process that occurs during patching or a failure of one of the cache nodes.
163+
- When you scale a Redis instance, one of the nodes in the Redis cluster is shut down and reprovisioned to the new size. Then data transfers over, and the other node does a similar failover subsequently before it's reprovisioned. This is similar to the process that occurs during patching or a failure of one of the cache nodes.
176164
- When scaling to an instance with more vCPUs, new shards are provisioned and added to the Redis server cluster. Data is then resharded across all shards.
177165

178166
For more information on how Azure Managed Redis handles sharding, see [Sharding configuration](architecture.md#sharding-configuration).
179167

180168
### Do I lose data from my cache during scaling?
181169

182170
- If high availability mode is enabled, all data should be preserved during scaling operations.
183-
- If you're scaling to a smaller memory level, you need to ensure that the current memory usage is lower than the intended new memory size. If the current memory usage is more than the intended SKU memory size, you can flush your data using Flush operation (add link) or choose key values to delete manually.
171+
- If you're scaling to a smaller memory level, you need to ensure that the current memory usage is smaller than the intended new memory size. If the current memory usage is more than the intended SKU memory size, you can flush your data using Flush operation or manually choose key values to delete.
172+
<!-- - add link -->
184173
- If high availability mode is disabled, all data is lost and the cache is unavailable during the scaling operation.
185174

186175
### Will my cache be available during scaling?
@@ -204,7 +193,7 @@ Generally, when you scale an instance with no data, it takes approximately 10 mi
204193

205194
### How can I tell when scaling is complete?
206195

207-
In the Azure portal, you can see the scaling operation in progress. When scaling is complete, the status of the cache changes to **Running**.
196+
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 viewing **Overview** on the Resource menu.
208197

209198
### Does Azure Managed Redis use clustering?
210199

@@ -229,6 +218,6 @@ For more information, see [Keys distribution model](https://redis.io/topics/clus
229218

230219
The largest cache size you can have is 4.5 TB, called Flash Optimized A4500 instance. [Azure Cache for Redis Pricing](https://azure.microsoft.com/pricing/details/cache/).
231220

232-
## Next steps
221+
## Related content
233222

234223
- [Best practices for scaling](best-practices-scale.md)

0 commit comments

Comments
 (0)