Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
marc_koderer
Explorer

Implementation with distributed database at Mahindra & Mahindra Limited


Introduction


Running ERP at scale in the cloud with SAP S/4HANA


In the age of Cloud ERP, customers can focus on the business value they draw from their ERP systems. Customer IT, liberated from a large share of basis workload, becomes primarily an enabler of business innovation.

At the same time, many companies have built out their SAP S/4HANA and SAP ECC systems with adaptations of standard processes and a variety of customer applications as a means to differentiate themselves from their competitors.

SAP S/4HANA cloud, private edition is also the solution for even some of the most demanding, largest cloud ERP systems in the world. Supporting the database scale-out technology of SAP HANA, there are no limits in achievable scale compared to classical on-premises installations of SAP S/4HANA.

Google Cloud as key partner for SAP S/4HANA cloud infrastructure


Google Cloud provides a platform for SAP to build, deploy and manage SAP S/4HANA cloud, private edition for the smallest to the most demanding customers. Google Cloud’s scalable infrastructure and high bandwidth low latency network provides excellent performance and stability for running SAP applications and delivers high application performance for scale-up and scale-out SAP S/4HANA systems.

Background


Mahindra & Mahindra Limited


Mahindra & Mahindra Ltd. is an Indian multinational automotive manufacturing corporation headquartered in Mumbai. It was established in 1945. Part of the Mahindra Group, Mahindra & Mahindra Limited, is one of the largest vehicle manufacturers by production in India.

In 2019, Mahindra & Mahindra went live with SAP S/4HANA after 18 months of a project for conversion of the existing SAP Business Suite (ECC 6.0) system to SAP S/4HANA 1709. The SAP Application is supporting more than  25000+ users and 80+ different company codes, running a broad range of SAP S/4HANA core modules such as FI/CO, MM, SD, PP, Asset Management, and core processes such as record-to-report, order-to-cash and procure-to-pay.

Move to SAP S/4HANA cloud, private edition


In 2021, Mahindra & Mahindra decided to adopt SAP S/4HANA cloud, private edition, choosing Google Cloud as the infrastructure provider. Project planning and safeguarding was provided through SAP MaxAttention services from the planning stage to Go-Live. Mahindra & Mahindra were also supported by the SAP S/4HANA customer care program (https://influence.sap.com/sap/ino/#/campaign/71), whose project coaches helped to move ahead efficiently with regards to clarification of new SAP S/4HANA product features and quick issue resolutions. Customer care also helped Mahindra & Mahindra to quickly adapt  innovation and introduce  90+ standard- as well as 200 custom SAP Fiori apps.

On the technical side, Mahindra & Mahindra expected the cloud system to match the existing on-premises system in terms of performance and throughput.

As the project progressed, intensive load testing showed that the originally foreseen single-node database infrastructure did not provide sufficient CPU capacity to sustain estimated peak workload.

Therefore, in August of 2022, the option of implementing SAP HANA database scale-out was introduced into the project plan. Only three-and-a-half months later, the system went live successfully with the first ever SAP S/4HANA cloud system operating on a distributed HANA database. The productive collaboration of Mahindra & Mahindra, SAP teams and Google Cloud paved the path to this impressive achievement.

SAP S/4HANA cloud, private edition


SAP S/4HANA Cloud, private edition enables companies to safeguard their existing SAP ERP investment while benefiting from a new level of flexibility. They can tailor the software to meet their specific needs, retain the company-specific configurations and customizations of the existing SAP ERP system, and access the latest capabilities that give them a competitive advantage.

SAP S/4HANA operating on HANA scale-out


SAP HANA scale-out is a HANA deployment option that allows to stretch the HANA database across multiple physical database servers (typically referred to as “nodes”). It is based on a shared nothing architecture, wherein each node controls its own data volumes, and generally, a given data set is stored and managed by one particular node. For applications, the scale-out cluster is represented as one single ACID-compliant database via the SAP HANA interfaces. Efficient connectivity to the optimal database node is ensured by the feature of client-side statement routing in the database client.


Figure 1: SAP HANA scale-out


Scale-out is used to scale the available physical memory, as well as the available CPU resources in the SAP HANA system. Though adding some complexity, scale-out enables growth beyond single node limits:

  • Total database sizes are reachable that are beyond the capacity of the largest available single servers.

  • Application workload can be distributed across multiple database nodes – also enlarging the CPU capacity available to the application.

  • Scale-out allows for more flexibility: it enables to react to strong system growth by adding additional scale-out hosts (within boundaries set by the applications).


For the core applications of SAP S/4HANA, a concept of scale-out by component placement has been developed. The main goals of this concept are:

  • Minimize the impact of inter-node communication for the core transactional workload thus ensuring good response times.

  • Provide a table distribution that is stable in time, not requiring frequent moving of database objects between the nodes.

  • Allow for a reasonable distribution of data volume and workload across the database nodes.


The fundamental design choices

  • Tables are clustered by application criteria, so that tables that are used within the same application context belong to the same table group. SAP provides a set of table groups as a starting point for projects, the initial proposal is adapted to each customer, including z-coding and z-tables.

  • OLTP-queries joining tables from different groups are avoided in the application standard.

  • All tables of a given group are kept on the same database node. Multiple groups may share the same node.

  • Selected master data or similar tables may be shared between all database nodes by means of a table replication concept.



Figure 2: S/4HANA Scale-out


The concept also allows flexibility to adjust to the actual situation in a given customer system:

  • Customers can adapt the SAP-provided set of table groups according to their specific needs, based on analysis of their core workload:

    • Merging multiple groups to one larger group

    • Adding additional tables (SAP- or customer-tables) to existing groups

    • Defining new groups



  • Customers can choose to replicate additional tables as required.


Since its introduction in the year 2017, several large SAP S/4HANA installations have been deployed using this scale-out offering. Mahindra & Mahindra are the first customer to have adopted scale-out in SAP S/4HANA cloud, private edition.

Details of the project


Collaboration between Mahindra&Mahindra, SAP, and Google Cloud


Throughout the project phase, teams from Mahindra & Mahindra, Google Cloud, and SAP worked in a well-aligned setup to safeguard the project, convert findings into actions and steer towards successful go-live.

Mahindra & Mahindra's existing setup and processes for load and performance testing proved an invaluable asset. It enabled testing and fine-tuning scale-out aspects such as table distribution or table replication to minimize impact of cross-node queries on statement performance and query throughput. Similarly, it made it possible to find optimization potential in custom development objects with respect to the underlying data distribution.

With the load test system on production-identical hardware, the teams could also spot and address optimization potential in the technology stack, be it in database parameterization or physical infrastructure.

Mahindra & Mahindra's test team was also quick to adjust the load test scenario where needed to reflect more closely the actual workload in the planned production system. This flexibility ensured that the test cycles provided highly meaningful results for understanding and safeguarding productive system behavior.

Google Cloud's technical infrastructure and SAP experts provided analysis of infrastructure KPIs and identified opportunities for VM deployment and configuration optimization as part of a Google Cloud Safeguarding service. Google Cloud's PSO team was on standby during the go live to help resolve any issues if they would arise, but the go live went through without any incidents for Google Cloud.


Figure 3: Collaboration



Implementing SAP S/4HANA on scale-out with cluster protection


In order to enlarge the compute bandwidth there was the clear need to scale horizontally with HANA scale-out. Vertical scaling will require moving to Google Cloud Bare Metal HANA systems. Furthermore, adding an additional HANA node doubles the I/O bandwidth of the disks which was also a very important aspect as it improves performance for backups and other operational tasks.

Due to the high resilience requirements of the customer the scale-out setup needs to be distributed across Google Cloud Availability Zones. To protect the system in case of failure the system was protected via Pacemaker Cluster software.


Figure 4: Please note: this setup is only available in RISE with SAP S/4HANA Cloud, private edition, tailored option with expert analysis and approval



Running scale-out clusters on Google Cloud


SAP HANA scale-out has been supported on Google Cloud since 2018 and Google Cloud provides standard best practices for setting up an SAP HANA scale-out clusters supporting high availability across availability zones. The scale-out architecture consists of one master host, a number of worker hosts, and, optionally, one or more standby hosts. The hosts are interconnected through a network that supports sending data between hosts at rates of up to 100 Gbps on selected machine types using high-bandwidth networking with the lowest possible latency.

As the workload demand increases, especially when using OLAP, a multi-host, scale-out architecture can distribute the load across all hosts.

The following features help ensure the high availability of an SAP HANA scale-out system:

  • Compute Engine live migration

  • Compute Engine automatic instance restart

  • SAP HANA host auto-failover with up to three SAP HANA standby hosts


For more information about high availability options on Google Cloud, see the SAP HANA high-availability planning guide.

Increasing disk IO using hyperdisk Extreme


Large SAP HANA system can require very high peak I/O throughput specifically to support HANA e.g., delta merges, savepoints and backups. Google Cloud provides linear scalable persistent disks with up to 1200MB/s throughput, 40000 read and 40000 write IOPS per VM used in the deployment of SAP HANA at Mahindra & Mahindra.

Mahindra & Mahindra’s SAP system was observed at peak throughput during stress testing to still be within these limits, so it was not a bottleneck for the go live. Google Cloud has recently released a new disk type, Hyperdisk Extreme, a high performing and scalable disk solution, providing up to 5000MB/s throughput and up to 350,000 IOPS. Hyperdisk Extreme is certified for SAP HANA workloads and is available for RISE with SAP Private Cloud Edition customer deployments on request.

Outcome


Successful go-live on scale-out after 3.5 months project time.

Stable system operations, outperforming requirements with respect to performance and throughput.

In total 12% faster response times after migration to RISE Google Cloud environment.


Figure 5: Response time comparison













SAP Notes




 
19 Comments