This section shares the results of functional testing of the DBaaS platform in the Dell Technologies lab. We performed common administrative tasks to demonstrate elastic scale and life cycle management.

Each layer in the DBaaS platform is elastic and capable of scaling to meet the demands of the database workloads. We used Grafana and Azure Monitor Container Insights extensively to monitor performance and capacity at the AKS-HCI and Azure Arc-enabled SQL Managed Instance layers. 

Because we only tested the general-purpose tier of SQL Managed Instance, we were only able to scale up an instance rather than scale out. Read scale out is only available at the business-critical service tier (currently in preview). We tested scaling up a managed instance by adding more compute vCores and memory. The following figure shows the original compute capacity of sqlmi-07 using Azure Data Studio.

Figure 34.    Original CPU and memory request and limit on sqlmi-07

We could have changed the requests and limits in Azure Data Studio, but we opted to run the following command using the Azure CLI:

PS D:\Source\Lab> az sql mi-arc edit --cores-limit 8 --cores-request 8 --memory-limit 18Gi --memory-request 16Gi -n sqlmi-07 --k8s-namespace arc --use-k8s

Updating sqlmi-07 in namespace `arc`

sqlmi-07 is Ready

We could use kubectl to see the results of running this command:

PS D:\Source\Lab> kubectl get sqlmi sqlmi-07 -o jsonpath='{.spec.scheduling.default.resources}'

{"limits":{"cpu":"8","memory":"18Gi"},"requests":{"cpu":"8","memory":"16Gi"}}

According to the SQL Server logs, the SQL database was unreachable for approximately 3 to 4 minutes during the scale-out procedure because the sqlmi-07 pod was terminated and re-created. Because this was a single-instance general-purpose tier SQL MI, this was expected behavior. 

Note: Currently, you cannot expand storage that is allocated to the SQL MI after the MI has been created. You must size the storage of the MI correctly during the initial creation.