You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-best-practices-enterprise-tiers.md
+49-24Lines changed: 49 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,43 +1,50 @@
1
1
---
2
2
title: Best practices for the Enterprise tiers
3
3
titleSuffix: Azure Cache for Redis
4
-
description: Learn about the Azure Cache for Redis Enterprise and Enterprise Flash tiers
4
+
description: Learn the best practices when using the high performance Azure Cache for Redis Enterprise and Enterprise Flash tiers
5
5
author: flang-msft
6
6
ms.service: cache
7
7
ms.topic: conceptual
8
-
ms.date: 03/09/2023
8
+
ms.date: 09/26/2023
9
9
ms.author: franlanglois
10
10
---
11
11
12
-
# Best Practices for the Enterprise and Enterprise Flash tiers of Azure Cache for Redis
12
+
# What are the best practices for the Enterprise and Enterprise Flash tiers
13
+
14
+
Here are the best practices when using the Enterprise and Enterprise Flash tiers of Azure Cache for Redis.
13
15
14
16
## Zone Redundancy
15
17
16
18
We strongly recommend that you deploy new caches in a [zone redundant](cache-high-availability.md) configuration. Zone redundancy ensures that Redis Enterprise nodes are spread among three availability zones, boosting redundancy from data center-level outages. Using zone redundancy increases availability. For more information, see [Service Level Agreements (SLA) for Online Services](https://azure.microsoft.com/support/legal/sla/cache/v1_1/).
17
19
18
-
Zone redundancy is important on the Enterprise tier because your cache instance always uses at least three nodes. Two nodes are data nodes, which hold your data, and a _quorum node_. Increasing capacity scales the number of data nodes in even-number increments.
20
+
Zone redundancy is important on the Enterprise tier because your cache instance always uses at least three nodes. Two nodes are data nodes, which hold your data, and a _quorum node_. Increasing capacity scales the number of data nodes in even-number increments.
19
21
20
22
There's also another node called a quorum node. This node monitors the data nodes and automatically selects the new primary node if there was a failover. Zone redundancy ensures that the nodes are distributed evenly across three availability zones, minimizing the potential for quorum loss. Customers aren't charged for the quorum node and there's no other charge for using zone redundancy beyond [intra-zonal bandwidth charges](https://azure.microsoft.com/pricing/details/bandwidth/).
21
23
22
24
## Scaling
23
25
24
-
In the Enterprise and Enterprise Flash tiers of Azure Cache for Redis, we recommend prioritizing scaling up over scaling out. Prioritize scaling up because the Enterprise tiers are built on Redis Enterprise, which is able to utilize more CPU cores in larger VMs.
25
-
26
-
Conversely, the opposite recommendation is true for the Basic, Standard, and Premium tiers, which are built on open-source Redis. In those tiers, prioritizing scaling out over scaling up is recommended in most cases.
26
+
In the Enterprise and Enterprise Flash tiers of Azure Cache for Redis, we recommend prioritizing _scaling up_ over _scaling out_. Prioritize scaling up because the Enterprise tiers are built on Redis Enterprise, which is able to utilize more CPU cores in larger VMs.
27
27
28
+
Conversely, the opposite recommendation is true for the Basic, Standard, and Premium tiers, which are built on open-source Redis. In those tiers, prioritizing _scaling out_ over _scaling up_ is recommended in most cases.
28
29
29
30
## Sharding and CPU utilization
30
31
31
-
In the Basic, Standard, and Premium tiers of Azure Cache for Redis, determining the number of virtual CPUs (vCPUs) utilized is straightforward. Each Redis node runs on a dedicated VM. The Redis server process is single-threaded, utilizing one vCPU on each primary and each replica node. The other vCPUs on the VM are still used for other activities, such as workflow coordination for different tasks, health monitoring, and TLS load, among others.
32
+
In the Basic, Standard, and Premium tiers of Azure Cache for Redis, determining the number of virtual CPUs (vCPUs) utilized is straightforward. Each Redis node runs on a dedicated VM. The Redis server process is single-threaded, utilizing one vCPU on each primary and each replica node. The other vCPUs on the VM are still used for other activities, such as workflow coordination for different tasks, health monitoring, and TLS load, among others.
32
33
33
-
When you use clustering, the effect is to spread data across more nodes with one shard per node. By increasing the number of shards, you linearly increase the number of vCPUs you use, based on the number of shards in the cluster.
34
+
When you use clustering, the effect is to spread data across more nodes with one shard per node. By increasing the number of shards, you linearly increase the number of vCPUs you use, based on the number of shards in the cluster.
34
35
35
-
Redis Enterprise, on the other hand, can use multiple vCPUs for the Redis instance itself. In other words, all tiers of Azure Cache for Redis can use multiple vCPUs for background and monitoring tasks, but only the Enterprise and Enterprise Flash tiers are able to utilize multiple vCPUs per VM for Redis shards. The table shows the number of effective vCPUs used for each SKU and capacity (that is, scale-out) configuration.
36
+
Redis Enterprise, on the other hand, can use multiple vCPUs for the Redis instance itself. In other words, all tiers of Azure Cache for Redis can use multiple vCPUs for background and monitoring tasks, but only the Enterprise and Enterprise Flash tiers are able to utilize multiple vCPUs per VM for Redis shards. The table shows the number of effective vCPUs used for each SKU and capacity (that is, scale-out) configuration.
36
37
37
-
The tables show the number of vCPUs used for the primary shards, not the replica shards. Shards don't map one-to-one to the number of vCPUs. The tables only illustrate vCPUs, not shards. Some configurations use more shards than available vCPUs to boost performance in some usage scenarios.
38
+
The tables show the number of vCPUs used for the primary shards, not the replica shards. Shards don't map one-to-one to the number of vCPUs. The tables only illustrate vCPUs, not shards. Some configurations use more shards than available vCPUs to boost performance in some usage scenarios.
38
39
39
-
### E10
40
+
### E5
41
+
|Capacity|Effective vCPUs|
42
+
|---:|---:|
43
+
| 2 | 1 |
44
+
| 4 | 2 |
45
+
| 6 | 6 |
40
46
47
+
### E10
41
48
|Capacity|Effective vCPUs|
42
49
|---:|---:|
43
50
| 2 | 2 |
@@ -46,8 +53,8 @@ The tables show the number of vCPUs used for the primary shards, not the replica
46
53
| 8 | 16 |
47
54
| 10 | 20 |
48
55
49
-
50
56
### E20
57
+
51
58
|Capacity|Effective vCPUs|
52
59
|---:|---:|
53
60
|2| 2|
@@ -66,8 +73,8 @@ The tables show the number of vCPUs used for the primary shards, not the replica
66
73
|8|30 |
67
74
|10|30|
68
75
69
-
70
76
### E100
77
+
71
78
|Capacity|Effective vCPUs|
72
79
|---:|---:|
73
80
|2| 6|
@@ -76,37 +83,57 @@ The tables show the number of vCPUs used for the primary shards, not the replica
76
83
|8|30|
77
84
|10|30|
78
85
86
+
### E200
87
+
|Capacity|Effective vCPUs|
88
+
|---:|---:|
89
+
|2|30|
90
+
|4|60|
91
+
|6|60|
92
+
|8|120|
93
+
|10|120|
94
+
95
+
### E400
96
+
|Capacity|Effective vCPUs|
97
+
|---:|---:|
98
+
|2|60|
99
+
|4|120|
100
+
|6|120|
101
+
|8|240|
102
+
|10|240|
103
+
79
104
### F300
105
+
80
106
|Capacity|Effective vCPUs|
81
107
|---:|---:|
82
108
|3| 6|
83
109
|9|30|
84
110
85
111
### F700
112
+
86
113
|Capacity|Effective vCPUs|
87
114
|---:|---:|
88
115
|3| 30|
89
116
|9| 30|
90
117
91
118
### F1500
119
+
92
120
|Capacity|Effective vCPUs |
93
121
|---:|---:|
94
122
|3| 30 |
95
123
|9| 90 |
96
124
97
-
98
125
## Clustering on Enterprise
99
126
100
127
Enterprise and Enterprise Flash tiers are inherently clustered, in contrast to the Basic, Standard, and Premium tiers. The implementation depends on the clustering policy that is selected.
101
-
The Enterprise tiers offer two choices for Clustering Policy: _OSS_ and _Enterprise_. _OSS_ cluster policy is recommended for most applications because it supports higher maximum throughput, but there are advantages and disadvantages to each version.
128
+
The Enterprise tiers offer two choices for Clustering Policy: _OSS_ and _Enterprise_. _OSS_ cluster policy is recommended for most applications because it supports higher maximum throughput, but there are advantages and disadvantages to each version.
102
129
103
-
The _OSS clustering policy_ implements the same [Redis Cluster API](https://redis.io/docs/reference/cluster-spec/) as open-source Redis. The Redis Cluster API allows the Redis client to connect directly to each Redis node, minimizing latency and optimizing network throughput. As a result, near-linear scalability is obtained when scaling out the cluster with more nodes. The OSS clustering policy generally provides the best latency and throughput performance, but requires your client library to support Redis Clustering. OSS clustering policy also can't be used with the [RediSearch module](cache-redis-modules.md).
130
+
The _OSS clustering policy_ implements the same [Redis Cluster API](https://redis.io/docs/reference/cluster-spec/) as open-source Redis. The Redis Cluster API allows the Redis client to connect directly to each Redis node, minimizing latency and optimizing network throughput. As a result, near-linear scalability is obtained when scaling out the cluster with more nodes. The OSS clustering policy generally provides the best latency and throughput performance, but requires your client library to support Redis Clustering. OSS clustering policy also can't be used with the [RediSearch module](cache-redis-modules.md).
104
131
105
-
The _Enterprise clustering policy_ is a simpler configuration that utilizes a single endpoint for all client connections. Using the Enterprise clustering policy routes all requests to a single Redis node that is then used as a proxy, internally routing requests to the correct node in the cluster. The advantage of this approach is that Redis client libraries don’t need to support Redis Clustering to take advantage of multiple nodes. The downside is that the single node proxy can be a bottleneck, in either compute utilization or network throughput. The Enterprise clustering policy is the only one that can be used with the [RediSearch module](cache-redis-modules.md).
132
+
The _Enterprise clustering policy_ is a simpler configuration that utilizes a single endpoint for all client connections. Using the Enterprise clustering policy routes all requests to a single Redis node that is then used as a proxy, internally routing requests to the correct node in the cluster. The advantage of this approach is that Redis client libraries don’t need to support Redis Clustering to take advantage of multiple nodes. The downside is that the single node proxy can be a bottleneck, in either compute utilization or network throughput. The Enterprise clustering policy is the only one that can be used with the [RediSearch module](cache-redis-modules.md).
106
133
107
134
## Multi-key commands
108
135
109
-
Because the Enterprise tiers use a clustered configuration, you might see `CROSSSLOT` exceptions on commands that operate on multiple keys. Behavior varies depending on the clustering policy used. If you use the OSS clustering policy, multi-key commands require all keys to be mapped to [the same hash slot](https://docs.redis.com/latest/rs/databases/configure/oss-cluster-api/#multi-key-command-support).
136
+
Because the Enterprise tiers use a clustered configuration, you might see `CROSSSLOT` exceptions on commands that operate on multiple keys. Behavior varies depending on the clustering policy used. If you use the OSS clustering policy, multi-key commands require all keys to be mapped to [the same hash slot](https://docs.redis.com/latest/rs/databases/configure/oss-cluster-api/#multi-key-command-support).
110
137
111
138
You might also see `CROSSSLOT` errors with Enterprise clustering policy. Only the following multi-key commands are allowed across slots with Enterprise clustering: `DEL`, `MSET`, `MGET`, `EXISTS`, `UNLINK`, and `TOUCH`.
112
139
@@ -120,7 +147,7 @@ For example, consider these tips:
120
147
121
148
- Identify in advance which other cache in the geo-replication group to switch over to if a region goes down.
122
149
- Ensure that firewalls are set so that any applications and clients can access the identified backup cache.
123
-
- Each cache in the geo-replication group has its own access key. Determine how the application will switch access keys when targeting a backup cache.
150
+
- Each cache in the geo-replication group has its own access key. Determine how the application switches to different access keys when targeting a backup cache.
124
151
- If a cache in the geo-replication group goes down, a buildup of metadata starts to occur in all the caches in the geo-replication group. The metadata can't be discarded until writes can be synced again to all caches. You can prevent the metadata build-up by _force unlinking_ the cache that is down. Consider monitoring the available memory in the cache and unlinking if there's memory pressure, especially for write-heavy workloads.
125
152
126
153
It's also possible to use a [circuit breaker pattern](/azure/architecture/patterns/circuit-breaker). Use the pattern to automatically redirect traffic away from a cache experiencing a region outage, and towards a backup cache in the same geo-replication group. Use Azure services such as [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md) or [Azure Load Balancer](../load-balancer/load-balancer-overview.md) to enable the redirection.
@@ -129,10 +156,8 @@ It's also possible to use a [circuit breaker pattern](/azure/architecture/patter
129
156
130
157
The [data persistence](cache-how-to-premium-persistence.md) feature in the Enterprise and Enterprise Flash tiers is designed to automatically provide a quick recovery point for data when a cache goes down. The quick recovery is made possible by storing the RDB or AOF file in a managed disk that is mounted to the cache instance. Persistence files on the disk aren't accessible to users.
131
158
132
-
Many customers want to use persistence to take periodic backups of the data on their cache. We don't recommend that you use data persistence in this way. Instead, use the [import/export](cache-how-to-import-export-data.md) feature. You can export copies of cache data in RDB format directly into your chosen storage account and trigger the data export as frequently as you require. Export can be triggered either from the portal or by using the CLI, PowerShell, or SDK tools.
159
+
Many customers want to use persistence to take periodic backups of the data on their cache. We don't recommend that you use data persistence in this way. Instead, use the [import/export](cache-how-to-import-export-data.md) feature. You can export copies of cache data in RDB format directly into your chosen storage account and trigger the data export as frequently as you require. Export can be triggered either from the portal or by using the CLI, PowerShell, or SDK tools.
0 commit comments