We defined the five test groups listed in the following table. We ran each test independently and documented the results. 

Table 9.      Testing matrices

In tests 1 - 4, we attempted to discover the SQL MI size that would provide an optimal balance of price and performance. We also wanted to see if there was any substantial difference between the following test configurations:

• vCPU requested = vCPU limit
• vCPU requested < vCPU limit 

Azure Arc-enabled data services consumption-based billing applies to vCPU limit – not vCPU requested. The AKS hybrid scheduler reserves workload cluster capacity and guarantees that each SQL MI pod is allocated its requested vCPU configuration. When setting vCPU requested equal to limit for all pods, we were not able to achieve the desired SQL MI density across the dbaas-databases-1 workload cluster.  

Memory remained constant for all tests, as memory is not compressible. We set the memory resource configuration for all SQL MIs to be 4Gi requested and 8Gi limit. We remained consistent with the vCPU configuration approach by setting memory requested to be less than the memory limit to maximize SQL MI deployment density. Additionally, the minimum and maximum memory resource configuration aligned to core fundamental SQL Server instance tuning best practices.

After we discovered the ideal SQL MI pod size in tests 1 – 4, we deployed the maximum number of pods allowed by the AKS hybrid scheduler to the workload cluster. We did not need to manually create a deployment plan. Instead, we relied on the automation built into AKS hybrid to perform capacity management and make logical placement decisions for us.