Azure Arc data controller and SQL MI comes with minimal sizing requirement and guidance. We recommend reviewing the Sizing Guidance and consulting with Microsoft to arrive at the correct amount of compute, memory, and storage required to run a Kubernetes cluster, Azure Arc data controller, and the number of SQL managed instances.
Note: The SQL MI has a resource limit for vCPU and Memory allocation. We can request an increase to these resource limits by using the commands from Azure CLI or from Azure Studio. There is a significant difference between SQL MI vCPU and Memory limits and requests. For more information, see the Overview of Azure SQL Managed Instance resource limits.
The configuration options described in the following sections are used for the SQL MIs performance cases.
To view the arguments that can be used for SQL MI deployments, run:
az sql mi-arc create –help
The General purpose tier deploys a single SQL MI instance that supports a multitude of workload scenarios for SQL Server. It deploys a single pod (cluster of one) AlwaysOn Availability Group Cluster or CAG (Contained Availability Group).
The business-critical tier deploys a three-pod (default) AlwaysOn Availability Group Cluster or CAG (Contained Availability Group).
In both the tier the pod will have four containers running as listed in the below table.
Table 9. SQL MI containers
Container Name | Description |
arc-sqlmi | SQL Server executable |
arc-monitor-collected | Application to collect performance metrics |
arc-monitor-fluentbit | Logging and metrics processing |
arc-ha-supervisor | SQL Server HA monitor and agent for bridging between SQL Server and Kubernetes |
The following Azure CLI command was issued to create the first General Purpose SQL MI, named ‘sqlmi-01’ in the lab to run the test cases mentioned in the following sections. Subsequent SQL MIs used for the test cases were create by changing the CPU and memory specifications with the same storage and volume values as listed below.
az sql mi-arc create --name sqlmi-01 --k8s-namespace arc --dev --replicas 1 --cores-request "2" --cores-limit "2" --memory-request "4Gi" --memory-limit "6Gi"
--storage-class-data "vxflexos-xfs-sql-data" --storage-class-logs "vxflexos-xfs"--storage-class-datalogs "vxflexos-xfs-sql-datalogs" --volume-size-backups "30Gi" --volume-size-data "50Gi" --volume-size-logs "20Gi"--volume-size-datalogs "50Gi" --use-k8s
The following Azure CLI command was issued to create the SQL MI with the business-critical trier enabled, named ‘bizcrtcl-01’ in the lab to run the test cases mentioned in the following sections.
az sql mi-arc create --name bizcrtcl-01 --k8s-namespace arc --dev --tier BusinessCritical --replicas 3 --cores-request "4" --cores-limit "4" --memory-request "4Gi" --memory-limit "6Gi" --storage-class-data "vxflexos-xfs-sql-data" --storage-class-logs "vxflexos-xfs"--storage-class-datalogs "vxflexos-xfs-sql-datalogs" --volume-size-backups "30Gi" --volume-size-data "50Gi" --volume-size-logs "20Gi"--volume-size-datalogs "50Gi" --use-k8s