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-arc/data/sizing-guidance.md
+90-47Lines changed: 90 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,19 @@ ms.topic: how-to
17
17
18
18
## Overview of sizing guidance
19
19
20
-
When planning for the deployment of Azure Arc data services you should plan for the correct amount of compute, memory, and storage that will be required to run the Azure Arc data controller and for the number of SQL managed instance and PostgreSQL servers that you will be deploying. Because Azure Arc-enabled data services is deployed on Kubernetes, you have the flexibility of adding additional capacity to your Kubernetes cluster over time by adding additional compute nodes or storage. This guide will provide guidance on minimum requirements as well as provide guidance on recommended sizes for some common requirements.
20
+
When planning for the deployment of Azure Arc data services, plan the correct amount of:
21
+
22
+
- Compute
23
+
- Memory
24
+
- Storage
25
+
26
+
These resources are required for:
27
+
28
+
- The data controller
29
+
- SQL managed instances
30
+
- PostgreSQL servers
31
+
32
+
Because Azure Arc-enabled data services deploy on Kubernetes, you have the flexibility of adding more capacity to your Kubernetes cluster over time by compute nodes or storage. This guide explains minimum requirements and recommends sizes for some common requirements.
21
33
22
34
## General sizing requirements
23
35
@@ -26,34 +38,40 @@ When planning for the deployment of Azure Arc data services you should plan for
26
38
27
39
Cores numbers must be an integer value greater than or equal to one.
28
40
29
-
When using Azure CLI (az) for deployment the memory values should be specified in a power of two number - i.e. using the suffixes: Ki, Mi, or Gi.
41
+
When you deploy with Azure CLI (az), use a power of two number to set the memory values. Specifically, use the suffixes:
42
+
43
+
-`Ki`
44
+
-`Mi`
45
+
-`Gi`
30
46
31
47
Limit values must always be greater than to the request value, if specified.
32
48
33
49
Limit values for cores are the billable metric on SQL managed instance and PostgreSQL servers.
34
50
35
51
## Minimum deployment requirements
36
52
37
-
A minimum size Azure Arc-enabled data services deployment could be considered to be the Azure Arc data controller plus one SQL managed instance plus one PostgreSQL server. For this configuration, you need at least 16GB of RAM and 4 cores of _available_ capacity on your Kubernetes cluster. You should ensure that you have a minimum Kubernetes node size of 8GB RAM and 4 cores and a sum total capacity of 16GB RAM available across all of your Kubernetes nodes. For example, you could have 1 node at 32GB RAM and 4 cores or you could have 2 nodes with 16GB RAM and 4 cores each.
53
+
A minimum size Azure Arc-enabled data services deployment could be considered to be the Azure Arc data controller plus one SQL managed instance plus one PostgreSQL server. For this configuration, you need at least 16-GB RAM and 4 cores of _available_ capacity on your Kubernetes cluster. You should ensure that you have a minimum Kubernetes node size of 8-GB RAM and 4 cores and a sum total capacity of 16-GB RAM available across all of your Kubernetes nodes. For example, you could have 1 node at 32-GB RAM and 4 cores or you could have 2 nodes with 16-GB RAM and 4 cores each.
38
54
39
55
See the [storage-configuration](storage-configuration.md) article for details on storage sizing.
40
56
41
57
## Data controller sizing details
42
58
43
59
The data controller is a collection of pods that are deployed to your Kubernetes cluster to provide an API, the controller service, the bootstrapper, and the monitoring databases and dashboards. This table describes the default values for memory and CPU requests and limits.
|**metricsdc**|100m|200Mi|200m|300Mi|Metricsdc is a daemonset which is created on each of the Kubernetes nodes in your cluster. The numbers in the table here are _per node_. If you set allowNodeMetricsCollection = false in your deployment profile file before creating the data controller, the metricsdc daemonset will not be created.|
You can override the default settings for the controldb and control pods in your deployment profile file or datacontroller YAML file. Example:
72
+
`metricsdc` is a `daemonset`, which is created on each of the Kubernetes nodes in your cluster. The numbers in the table are _per node_. If you set `allowNodeMetricsCollection = false` in your deployment profile file before you create the data controller, this `daemonset` isn't created.
73
+
74
+
You can override the default settings for the `controldb` and control pods in your data controller YAML file. Example:
57
75
58
76
```yaml
59
77
resources:
@@ -81,75 +99,100 @@ Each SQL managed instance must have the following minimum resource requests and
|fluentbit|100m|100Mi|Not specified|Not specified|The fluentbit container resource requests are _in addition to_ the requests specified for the SQL managed instance.|
94
-
|arc-sqlmi|User specified or not specified.|User specified or not specified.|User specified or not specified.|User specified or not specified.|
|`fluentbit`|`100m`|`100Mi`|Not specified|Not specified|The `fluentbit` container resource requests are _in addition to_ the requests specified for the SQL managed instance.|
112
+
|`arc-sqlmi`|User specified or not specified.|User specified or not specified.|User specified or not specified.|User specified or not specified.|
|fluentbit|100m|100Mi|Not specified|Not specified|The fluentbit container resource requests are _in addition to_ the requests specified for the PostgreSQL server.|
110
-
|postgres|User specified or not specified.|User specified or 256Mi (default).|User specified or not specified.|User specified or not specified.||
|`fluentbit`|`100m`|`100Mi`|Not specified|Not specified|The `fluentbit` container resource requests are _in addition to_ the requests specified for the PostgreSQL server.|
128
+
|`postgres`|User specified or not specified.|User specified or `256Mi` (default).|User specified or not specified.|User specified or not specified.||
The overall size of an environment required for Azure Arc-enabled data services is primarily a function of the number and size of the database instances that will be created. The overall size can be difficult to predict ahead of time knowing that the number of instances will grow and shrink and the amount of resources that are required for each database instance will change.
133
+
The overall size of an environment required for Azure Arc-enabled data services is primarily a function of the number and size of the database instances. The overall size can be difficult to predict ahead of time knowing that the number of instances may grow and shrink and the amount of resources that are required for each database instance can change.
116
134
117
-
The baseline size for a given Azure Arc-enabled data services environment is the size of the data controller which requires 4 cores and 16GB of RAM. From there you can add on top the cumulative total of cores and memory required for the database instances. For SQL managed instance the number of pods is equal to the number of SQL managed instances that are created. For PostgreSQL servers the number of pods is equal to the number of PostgreSQL servers that are created.
135
+
The baseline size for a given Azure Arc-enabled data services environment is the size of the data controller, which requires 4 cores and 16-GB RAM. From there, add the cumulative total of cores and memory required for the database instances. SQL Managed Instance requires one pod for each instance. PostgreSQL server creates one pod for each server.
118
136
119
-
In addition to the cores and memory you request for each database instance, you should add 250m of cores and 250Mi of RAM for the agent containers.
137
+
In addition to the cores and memory you request for each database instance, you should add `250m` of cores and `250Mi` of RAM for the agent containers.
120
138
121
-
The following is an example sizing calculation.
139
+
### Example sizing calculation
122
140
123
141
Requirements:
124
142
125
-
- **"SQL1"**: 1 SQL managed instance with 16 GB of RAM, 4 cores
126
-
- **"SQL2"**: 1 SQL managed instance with 256 GB of RAM, 16 cores
127
-
- **"Postgres1"**: 1 PostgreSQL server at 12 GB of RAM, 4 cores
- **"Postgres1"**: 1 PostgreSQL server at 12-GB RAM, 4 cores
128
146
129
147
Sizing calculations:
130
148
131
-
- The size of "SQL1" is: 1 pod * ([16 Gi RAM, 4 cores] + [250Mi RAM, 250m cores]) for the agents per pod = 16.25 Gi RAM, 4.25 cores.
132
-
- The size of "SQL2" is: 1 pod * ([256 Gi RAM, 16 cores] + + [250Mi RAM, 250m cores]) for the agents per pod = 256.25 Gi RAM, 16.25 cores.
133
-
- The total size of SQL 1 and SQL 2 is: (16.25 GB + 256.25 Gi) = 272.5 GB RAM, (4.25 cores + 16.25 cores) = 20.5 cores.
134
-
135
-
- The size of "Postgres1" is: 1 pod * ([12 GB RAM, 4 cores] + [250Mi RAM, 250m cores]) for the agents per pod = 12.25 GB RAM, 4.25 cores.
136
-
137
-
- The total capacity required for the database instances is: 272.5 GB RAM, 20.5 cores for SQL + 12.25 GB RAM, 4.25 cores for PostgreSQL server = 284.75 GB RAM, 24.75 cores.
138
-
139
-
- The total capacity required for the database instances plus the data controller is: 284.75 GB RAM, 24.75 cores for the database instances + 16 GB RAM, 4 cores for the data controller = 300.75 GB RAM, 28.75 cores.
149
+
- The size of "SQL1" is: `1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores])`. For the agents per pod use `16.25 Gi` RAM and 4.25 cores.
150
+
- The size of "SQL2" is: `1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])`. For the agents per pod use `256.25 Gi` RAM and 16.25 cores.
151
+
- The total size of SQL 1 and SQL 2 is:
152
+
- `(16.25 GB + 256.25 Gi) = 272.5-GB RAM`
153
+
- `(4.25 cores + 16.25 cores) = 20.5 cores`
154
+
155
+
- The size of "Postgres1" is: `1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores])`. For the agents per pod use `12.25 Gi` RAM and `4.25` cores.
156
+
157
+
- The total capacity required:
158
+
- For the database instances:
159
+
- 272.5-GB RAM
160
+
- 20.5 cores
161
+
- For SQL:
162
+
- 12.25-GB RAM
163
+
- 4.25 cores
164
+
- For PostgreSQL server
165
+
- 284.75-GB RAM
166
+
- 24.75 cores
167
+
168
+
- The total capacity required for the database instances plus the data controller is:
169
+
- For the database instance
170
+
- 284.75-GB RAM
171
+
- 24.75 cores
172
+
- For the data controller
173
+
- 16-GB RAM
174
+
- 4 cores
175
+
- In total:
176
+
- 300.75-GB RAM
177
+
- 28.75 cores.
140
178
141
179
See the [storage-configuration](storage-configuration.md) article for details on storage sizing.
142
180
143
181
## Other considerations
144
182
145
-
Keep in mind that a given database instance size request for cores or RAM cannot exceed the available capacity of the Kubernetes nodes in the cluster. For example, if the largest Kubernetes node you have in your Kubernetes cluster is 256 GB of RAM and 24 cores, you will not be able to create a database instance with a request of 512 GB of RAM and 48 cores.
183
+
Keep in mind that a given database instance size request for cores or RAM cannot exceed the available capacity of the Kubernetes nodes in the cluster. For example, if the largest Kubernetes node you have in your Kubernetes cluster is 256-GB RAM and 24 cores, you can't create a database instance with a request of 512-GB RAM and 48 cores.
184
+
185
+
Maintain at least 25% of available capacity across the Kubernetes nodes. This capacity allows Kubernetes to:
146
186
147
-
It is a good idea to maintain at least 25% of available capacity across the Kubernetes nodes to allow Kubernetes to efficiently schedule pods to be created and to allow for elastic scaling, allow for rolling upgrades of the Kubernetes nodes, and longer term growth on demand.
187
+
- Efficiently schedule pods to be created
188
+
- Enable elastic scaling
189
+
- Supports rolling upgrades of the Kubernetes nodes
190
+
- Facilitates longer term growth on demand
148
191
149
-
In your sizing calculations, don't forget to add in the resource requirements of the Kubernetes system pods and any other workloads which may be sharing capacity with Azure Arc-enabled data services on the same Kubernetes cluster.
192
+
In your sizing calculations, add the resource requirements of the Kubernetes system pods and any other workloads, which may be sharing capacity with Azure Arc-enabled data services on the same Kubernetes cluster.
150
193
151
-
To maintain high availability during planned maintenance and disaster continuity, you should plan for at least one of the Kubernetes nodes in your cluster to be unavailable at any given point in time. Kubernetes will attempt to reschedule the pods that were running on a given node that was taken down for maintenance or due to a failure. If there is no available capacity on the remaining nodes those pods will not be rescheduled for creation until there is available capacity again. Be extra careful with large database instances. For example, if there is only one Kubernetes node big enough to meet the resource requirements of a large database instance and that node fails then Kubernetes will not be able to schedule that database instance pod onto another Kubernetes node.
194
+
To maintain high availability during planned maintenance and disaster continuity, plan for at least one of the Kubernetes nodes in your cluster to be unavailable at any given point in time. Kubernetes attempts to reschedule the pods that were running on a given node that was taken down for maintenance or due to a failure. If there is no available capacity on the remaining nodes those pods won't be rescheduled for creation until there is available capacity again. Be extra careful with large database instances. For example, if there is only one Kubernetes node big enough to meet the resource requirements of a large database instance and that node fails, then Kubernetes won't schedule that database instance pod onto another Kubernetes node.
152
195
153
196
Keep the [maximum limits for a Kubernetes cluster size](https://kubernetes.io/docs/setup/best-practices/cluster-large/) in mind.
154
197
155
-
Your Kubernetes administrator may have set up [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) on your namespace/project. Keep these in mind when planning your database instance sizes.
198
+
Your Kubernetes administrator may have set up [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) on your namespace/project. Keep these quotas in mind when planning your database instance sizes.
0 commit comments