SAP ERP is the mainstay of business operations of many Forbes 2000 enterprises across domains. SAP pioneered the ERP system, helping companies replace multiple, disconnected and disparate applications with a single application that integrated diverse business functions. The company also envisaged supporting an integrated database and offering a single pane of view of business functions and processes across the enterprise in the long run. As enterprises evolved with the onset of digitization to harness the potential of data available in online transactional processing (OLTP) systems, the need arose to have dedicated analytical solutions.

Typically, OLTP and OLAP applications process data differently, requiring separate databases for transaction processing, reporting and analysis. This necessitates frequent synchronization between the two systems. Such synchronizations are usually scheduled for lean times to avoid the performance penalty of extracting data from the OLTP system. This resulted in a perpetual lag in data reported by the reporting system as compared to current data, and reports never reflected real-time status.

This proved to be a big bottleneck with the advent of the digital era as application users demanded real-time insights from the data. Also, the disk-centric DBMS engine had its own scalability limits and the traditional database architecture of the RDBMS was unable to cater to the real-time demands of emerging digital enterprises. A new approach was the need of the hour, and in-memory computing was born.

SAP HANA - The database that rules

Driven by Moore’s Law, CPU and memory capacity have grown manifold over the years. This has made in-memory computing feasible as well as cost-effective. However, CPU cache is even faster than memory. To accelerate database performance, you need a database design which not only leverages large memory but also maximizes CPU cache hit rate. To address this need, OLTP systems favor row-oriented data structures and OLAP systems favor column-oriented data structures.

HANA database uses two table fragments, the read-friendly Main fragment that contains data that is less prone to change, and a smaller write-friendly Delta fragment containing the latest data, which changes frequently. When the Delta fragment becomes too large, it is merged into the Main fragment, creating an empty Delta. Leveraging an intelligent combination of columnar storage, compression, insert only options and data in-memory, SAP HANA results in tremendous performance gains for OLTP and OLAP transactions simultaneously.

SAP HANA deployment: Challenges and best practices

While the potential is huge, SAP HANA has its set of deployment considerations.  Here’s a list of some of the typical deployment issues encountered with SAP HANA and how it is addressed:

• Impersistence of memory: Memory is fast but not persistent, which means data gets lost on power recycle or reboot. Hence, HANA instance needs to make sure every write is synchronously committed to a disk log. This impacts write performance, which is still bound by the disk speed.  Hence, having lowest possible latency for log disk is very important for overall HANA system performance. Use of ultra-low latency disk technology like Intel Optane SSD can be key here (See Figure 1).

1-Source: www.intel.com/benchmarks

Figure1: Comparison of different drive type latency

Database scalability: You have two approaches to scaling a HANA system. Scale-up and Scale-out. Scale-up is limited by hardware capability. Typical 4-socket system can scale to maximum 6TB memory. A few vendors have 8-socket systems which can scale to 12 TB memory. HPE is the only x86 vendor which can provide 32 socket system scaling up to 48TB memory. Scaling-out using small systems is more cost -effective option with some compromise on performance. Scaling out a HANA DB and leveraging the aggregated power of multiple systems may lead to additional complexities and hence SAP recommends exhausting single system memory limits before resorting to scaling out.

Source: https://www.sap.com/documents/2019/09/e2426a08-687d-0010-87a3-c30de2ffd8ff.html

Figure 2: Approaches to scaling a HANA system

Consolidation of multiple DBs: Some operations call for multiple small HANA DB systems on a single piece of hardware and having a dedicated hardware for every HANA DB maybe a challenge.  There are different levels at which multiple HANA systems can be consolidated on single hardware instance. Figure 3 shows how you can have consolidation at schema level called MCOD (Multiple Component in single Database) or at instance level (MCOS: Multiple components in single system) or at Database level containers (MDC: Multi-tenant Database container) or at operating system level (Virtualization).  Each of these options have their pros and cons and demand careful analysis of the requirements to choose one.

Figure 3: Consolidation of multiple databases

Organizations embarking on their SAP HANA journey can get overwhelmed by the multiple architectural choices to host their SAP HANA based applications. SAP tried to simplify the deployment for their clients by offering appliance model.

SAP initially followed an appliance-based approach in association with multiple system vendors, but the option proved to be too rigid. It also ruled out existing compute and storage investments made by the client. 

SAP has also certified cloud infrastructure providers to host SAP HANA applications along with their own cloud offering.

SAP HANA deployment options and the considerations to know the right one

Organizations today have multiple hosting options for their SAP HANA applications as well as different architectural constructs to achieve performance, scalability, availability, disaster recovery, customization and cost optimization.  Here’s a quick peek at some of the most popular deployment options and their key considerations:

SAP Cloud: This is a Software-as-a-Service (SAAS) offering from SAP, with two variants - Essentials and Extended editions. The Essentials edition supports only greenfield implementation. The Extended edition allows greater flexibility and functionality, with shared infrastructure and platform across multiple customers. The degree of flexibility is however limited in cloud editions. The Extended edition also allows selective data transition. There is no need to invest in software licenses and customers can simply subscribe to SAP Cloud and start using it. These offerings are mostly opted for when the need for customization and concern on shared infrastructure is low.

SAP HEC: SAP HANA Enterprise Cloud is a full functionality software with dedicated infrastructure hosted in the SAP service providers’ data center but fully managed by SAP. SAP has partnered with multiple providers across geographies to provide and manage the infrastructure. While SAP provides technical application managed services, SAP application support is provided by the chosen SAP partners. The default SLA is 99.5% up-time with upgrades at extra cost. The SAP licenses are owned by the customers, but there are limitations on the extent of customization supported. Infrastructure flexibility is low as compared to the cloud with minimal catalog options.

HEC is mostly opted for by customers who want privacy of infrastructure with outsourced management of the SAP platform.

Public cloud IaaS: This is similar to on-premise SAP implementation and operation but the underlying infrastructure is owned by hyper-scalers who offer virtual machines on shared infrastructure or dedicated bare metal instances. Customers own their SAP licenses and manage everything – from the operating systems to applications. Clients with a dynamic requirement of infrastructure, typically in the midst of a long project, usually prefer this option. Non-production on public cloud in steady state operations is another common use case. However, organizations with high infrastructure and performance requirements, steady usage, and latency sensitive business operations with strict regulations and compliance requirements usually shy away from hosting their SAP application on public cloud infrastructure.

SAP on-premise: This is the most leveraged option by SAP customers. These organizations generally have large IT teams of their own or they outsource infrastructure and/or application management to professional companies, while retaining control of technology. With mission-critical and strategic data, they have high sensitivity to latency. These organizations also face typical challenges of technology obsolescence, platform lifecycle maintenance, talent recruitment and retention, and most importantly, maintaining operational efficiency. IT infrastructure needs to be overprovisioned to avoid long procurement delays. A high degree of success is dependent upon their infrastructure and the application partners’ capability.

Hybrid option: Large organizations who want to retain mission-critical application infrastructure within the safe confines of their datacenter or private dedicated hosting spaces are on the lookout for contextualized and curated services with on-demand availability of infrastructure. Opting for a hybrid platform provides them the ease of starting a new project with unpredictable and dynamic resource demand in public cloud and then shifting it back to private cloud once resource consumption gets steady.

The HANA journey toward transformation

SAP HANA helps simplify the IT landscape and reduce data management burdens for organizations with their enterprise-proven database platforms. However, as organizations embrace digitization at scale and harness their data to understand their business and customer needs better, the need for efficiency and scale of processing will increase, driving improvements in existing ERP systems.

With the experience of implementing and supporting multiple modes of SAP application hosting for our customers, Wipro has partnered with HPE and Intel to create the next-gen model of a private on-premise HANA Platform as a Service offering.

To know about Wipro HANA Private Platform as a Service offering, check out part 2 (Wipro HANA Private Platform as a Service: The Game Changer for SAP HANA) of the paper.

To learn more about our SAP HANA solutions, click here