Sizing Guidance
Overview of sizing guidance
When planning for the deployment of Azure Arc data services, plan the correct amount of:
- Compute
- Memory
- Storage
These resources are required for:
- The data controller
- SQL managed instances
- PostgreSQL servers
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.
General sizing requirements
Note
If you are not familiar with the concepts in this article, you can read more about Kubernetes resource governance and Kubernetes size notation.
Cores numbers must be an integer value greater than or equal to one.
When you deploy with Azure CLI (az), use a power of two number to set the memory values. Specifically, use the suffixes:
Ki
Mi
Gi
Limit values must always be greater than to the request value, if specified.
Limit values for cores are the billable metric on SQL managed instance and PostgreSQL servers.
Minimum deployment requirements
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.
See the storage-configuration article for details on storage sizing.
Data controller sizing details
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.
Pod name | CPU request | Memory request | CPU limit | Memory limit |
---|---|---|---|---|
bootstrapper |
100m |
100Mi |
200m |
200Mi |
control |
400m |
2Gi |
1800m |
2Gi |
controldb |
200m |
4Gi |
800m |
6Gi |
logsdb |
200m |
1600Mi |
2 |
1600Mi |
logsui |
100m |
500Mi |
2 |
2Gi |
metricsdb |
200m |
800Mi |
400m |
2Gi |
metricsdc |
100m |
200Mi |
200m |
300Mi |
metricsui |
20m |
200Mi |
500m |
200Mi |
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.
You can override the default settings for the controldb
and control pods in your data controller YAML file. Example:
resources:
controller:
limits:
cpu: "1000m"
memory: "3Gi"
requests:
cpu: "800m"
memory: "2Gi"
controllerDb:
limits:
cpu: "800m"
memory: "8Gi"
requests:
cpu: "200m"
memory: "4Gi"
See the storage-configuration article for details on storage sizing.
SQL managed instance sizing details
Each SQL managed instance must have the following minimum resource requests and limits:
Service tier | General Purpose | Business Critical |
---|---|---|
CPU request | Minimum: 1 Maximum: 24 Default: 2 |
Minimum: 3 Maximum: unlimited Default: 4 |
CPU limit | Minimum: 1 Maximum: 24 Default: 2 |
Minimum: 3 Maximum: unlimited Default: 4 |
Memory request | Minimum: 2Gi Maximum: 128Gi Default: 4Gi |
Minimum: 2Gi Maximum: unlimited Default: 4Gi |
Memory limit | Minimum: 2Gi Maximum: 128Gi Default: 4Gi |
Minimum: 2Gi Maximum: unlimited Default: 4Gi |
Each SQL managed instance pod that is created has three containers:
Container name | CPU Request | Memory Request | CPU Limit | Memory Limit | Notes |
---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
Not specified | Not specified | The fluentbit container resource requests are in addition to the requests specified for the SQL managed instance. |
arc-sqlmi |
User specified or not specified. | User specified or not specified. | User specified or not specified. | User specified or not specified. | |
collectd |
Not specified | Not specified | Not specified | Not specified |
The default volume size for all persistent volumes is 5Gi
.
PostgreSQL server sizing details
Each PostgreSQL server node must have the following minimum resource requests:
- Memory:
256Mi
- Cores: 1
Each PostgreSQL server pod that is created has three containers:
Container name | CPU Request | Memory Request | CPU Limit | Memory Limit | Notes |
---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
Not specified | Not specified | The fluentbit container resource requests are in addition to the requests specified for the PostgreSQL server. |
postgres |
User specified or not specified. | User specified or 256Mi (default). |
User specified or not specified. | User specified or not specified. | |
arc-postgresql-agent |
Not specified | Not specified | Not specified | Not specified |
Cumulative sizing
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.
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.
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.
Example sizing calculation
Requirements:
- "SQL1": 1 SQL managed instance with 16-GB RAM, 4 cores
- "SQL2": 1 SQL managed instance with 256-GB RAM, 16 cores
- "Postgres1": 1 PostgreSQL server at 12-GB RAM, 4 cores
Sizing calculations:
The size of "SQL1" is:
1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores])
. For the agents per pod use16.25 Gi
RAM and 4.25 cores.The size of "SQL2" is:
1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])
. For the agents per pod use256.25 Gi
RAM and 16.25 cores.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
The size of "Postgres1" is:
1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores])
. For the agents per pod use12.25 Gi
RAM and4.25
cores.The total capacity required:
- For the database instances:
- 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
- For the database instances:
The total capacity required for the database instances plus the data controller is:
- For the database instance
- 284.75-GB RAM
- 24.75 cores
- For the data controller
- 16-GB RAM
- 4 cores
- In total:
- 300.75-GB RAM
- 28.75 cores.
- For the database instance
See the storage-configuration article for details on storage sizing.
Other considerations
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.
Maintain at least 25% of available capacity across the Kubernetes nodes. This capacity allows Kubernetes to:
- Efficiently schedule pods to be created
- Enable elastic scaling
- Supports rolling upgrades of the Kubernetes nodes
- Facilitates longer term growth on demand
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.
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.
Keep the maximum limits for a Kubernetes cluster size in mind.
Your Kubernetes administrator may have set up resource quotas on your namespace/project. Keep these quotas in mind when planning your database instance sizes.
Зворотний зв’язок
https://aka.ms/ContentUserFeedback.
Очікується незабаром: протягом 2024 року ми будемо припиняти використання механізму реєстрації проблем у GitHub для зворотного зв’язку щодо вмісту й замінювати його новою системою зворотного зв’язку. Докладніше:Надіслати й переглянути відгук про