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.
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.
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:
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 use 16.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 use 256.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 use 12.25 Gi RAM and 4.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
The total capacity required for the database instances plus the data controller is:
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.
Your Kubernetes administrator may have set up resource quotas on your namespace/project. Keep these quotas in mind when planning your database instance sizes.
Administer an SQL Server database infrastructure for cloud, on-premises and hybrid relational databases using the Microsoft PaaS relational database offerings.