In the Lab Setup section of this white paper, we listed the key design goals of our DBaaS platform configuration:

• Achieve efficient resource utilization
• Maximize resilience
• Reduce operating expenses     

This section provides evidence for the first design goal – achieve efficient resource utilization. We illustrate how this platform intelligently distributed new resources using default, out-of-the-box configuration settings. We relied upon the AKS hybrid scheduler to evenly distribute worker node VMs across the physical Azure Stack HCI cluster nodes. Then, we allowed the data controller to automatically disperse the Azure Arc-enabled SQL MI pods across those worker nodes.

To simulate database traffic from a micro-services-based application, we ran TPCC-like workloads from a containerized version of HammerDB. The HammerDB pods ran in the dbaas-applications-1 workload cluster. We also created a robust PowerShell and T-SQL logging and reporting framework to harvest HammerDB Transactions Per Minute (TPM). This automated test harness allowed us to properly capture TPM metrics from multiple SQL database instances at SQL MI granularity with individualized batch request per second logging.

We standardized on Grafana to visualize the performance data at all layers of the solution architecture. Three distinct instances of Grafana were leveraged:

• Azure Stack HCI cluster layer – We installed Telegraf agents on each cluster node and configured them to forward performance data to an external Grafana instance in the lab.
• AKS hybrid layer – We enabled local monitoring during the creation of the workload cluster, which automatically configured Prometheus and Grafana.
• Azure Arc-enabled data services layer – The data controller came bundled with Fluent Bit for observability and its own instance of Grafana.