The cost of cloud based VMs for hosting SAP HANA workloads can form a significant proportion of your overall cloud spend. The default sizing and configuration of SAP HANA systems or incorrect sizing can easily lead to unnecessarily large VMs and higher than expected cloud compute costs.
You may have a new greenfield implementation of SAP S/4HANA or an established implementation of SAP ECC on HANA. Either way, over the coming months it will inevitably grow and at some point, approach the VM memory limit. You will then need to consider options to either increase the VM size (with the associated increase in compute spend), archive data or configure SAP HANA to manage the data differently.
By way of an example, the following graph shows a sample of Azure VM sizes for hosting SAP HANA workloads and how the cost of these VMs can escalate without proper planning and attention. While Azure is already considering new VM sizes between 6TB and 12TB, there are ways in the meantime to better plan and manage costs as the HANA database grows.
As an IT Manager responsible for the Azure platform but with limited access to SAP tools, you want to be able to assess the growth of data within your SAP HANA systems to:
- validate that the VM size is appropriate
- budget for future growth
- understand which tables are contributing to the data growth
Wouldn’t it be useful to have access to a tool that provided this level of information with the additional ability to predict when your most important ERP system is approaching the virtual machine limit? Fortunately, the Azure Monitor for SAP Solutions (AMS) now has this functionality built in.
Azure Monitor for SAP Solutions (AMS)
Overview of AMS
Azure Monitor for SAP Solutions (AMS) is an Azure native monitoring tool designed to monitor connected SAP systems in your SAP estate. You can collect various infrastructure, SAP, and database metrics in one central location. Some of these metrics offer near real-time information on which alerts can be triggered; other metrics are more useful for gaining an insight into trends over longer periods of time. AMS can monitor different components such as Linux OS via Prometheus, Pacemaker clusters, SAP HANA, SAP NetWeaver, and SQL Server.
Aliter Consulting recently collaborated with Microsoft Engineering to provide an extension to AMS to monitor HANA columnar data and in-memory usage. This extension collects HANA column store monitoring data every 6 hours and stores it in the log analytics workspace of your choice.
Reporting of the various AMS metrics is then performed against the collected log analytics data in pre-defined workbooks visualizations.
For an overview of the AMS, please look at the following Microsoft documentation Azure Monitor for SAP Solutions Overview and Architecture.
Deployment of the AMS to start collecting SAP HANA data size information over the coming months would be beneficial to any company wanting to be proactive with capacity planning and cloud spend tracking. For instructions on how to deploy AMS in your Azure subscription, please follow the instructions in Microsoft documentation Deploy Azure Monitor for SAP Solutions with the Azure Portal.
Creating HANA Providers for AMS
Since HANA 2.0, all systems are multitenant with a minimum of the SYSTEMDB and the first application tenant database. The standard AMS “HANA Provider” wizard recommends connecting to the SYSTEMDB. To provide table level information an, AMS “HANA Provider” needs to be configured for the SYSTEMD DB and each database tenant running on the instance.
For details on creating AMS HANA providers, please follow the instructions in Microsoft documentation Azure Monitor for SAP Solutions Providers.
Analysing Collected Data
Once you’ve connected all your tenant databases, AMS will start collecting the relevant metrics to support the log analytics analysis but to see meaningful data and predictions, wait for a few days whilst enough data about your systems is collected. You’ll then be able to analyse the collected data in your AMS resource by selecting the SAP HANA monitoring node. The HANA Data Size extension is available on the right-most tab.
After some time, you’ll start to see a picture emerging about the growth of your systems in the workbook and even predict when capacity limits might be reached based on the knowledge AMS currently has.
The next section in the workbook provides a list of the top 10 columnar tables by size with a trend line to predict any tables that could reach the row-limit of 2 billion rows per partition within the next 12 months.
By selecting an individual entry, you can drill down to see a more detailed graph for number of rows (records) in the table and a second graph that shows the size of the table, the loaded size of the table and a trend-line for loaded size growth.
In the final section of the workbook, we see all the filesystems used by HANA. These metrics come from HANA, not the operating system. Again, by selecting an individual entry, you can drill down to a graph showing the historical growth of data on disk.
As part of our “SAP on Azure: Run” service, we can help you deploy AMS to start collecting data in relation to HANA capacity planning and management and help you make the right decisions as your systems continue to grow and approach capacity.