As a cloud architecture and advisory member, I frequently come across several customer cases related to existing SAP Business Warehouse(BW) systems. Large customers usually have large data footprint (often in several terabytes) and a variety of data source systems. Additionally, several reporting/analytic tools are connected to existing SAP BW systems.
Most of these SAP BW related cases can be classified into two types:
Large SAP BW systems on RDBMS -> Ready to migrate to SAP BW on HANA
◈ Improve query performance for real-time insights and decision making
◈ Boost performance for data load processes, simpler data models, accelerated in-memory planning capabilities etc.
SAP BW on HANA on-premise systems -> Growing rapidly and expecting high data growth
◈ Due to ongoing digital transformations, business model adjustments, additional source systems, new subsidiaries, expansion plans bringing additional data to be reported/queried upon, additional analytical business cases and/or new business users etc.
For a growing/large business warehouse management system, customers would need to come up with a system landscape roadmap by solving the puzzle highlighted in Figure 1. For simplicity sake, we can call this SAP Business warehouse – data growth puzzle.
On a high-level, this puzzle has 4 different dimensions:
1. Data Optimization: What can be gained on SAP BW on HANA?
2. Multi-Temperature data management: SAP Dynamic Tiering or Near-line Storage or both?
3. Scalability of SAP BW on HANA system: SAP HANA scale-up or scale-out?
4. Business continuity: Ensuring high availability(HA) and disaster recovery(DR)?
Understanding all the dimensions separately and making it work together to provide a scalable business warehouse solution is the key to derive this roadmap. This will ensure decision support continuity and enhanced emphasis on analytics.
Standard HANA sizing guidelines for BW suggest 50 % of the data footprint for the available RAM so that there is sufficient space available for the intermediate query/reporting result-sets. Hence, this roadmap preparation is inevitable once existing / planned system data size approaches 3-4 TB (this limit may vary depending on the business cases and hardware availability).
Figure 1. Several options to manage SAP BW on HANA data: The Data growth puzzle
Most of these SAP BW related cases can be classified into two types:
Large SAP BW systems on RDBMS -> Ready to migrate to SAP BW on HANA
◈ Improve query performance for real-time insights and decision making
◈ Boost performance for data load processes, simpler data models, accelerated in-memory planning capabilities etc.
SAP BW on HANA on-premise systems -> Growing rapidly and expecting high data growth
◈ Due to ongoing digital transformations, business model adjustments, additional source systems, new subsidiaries, expansion plans bringing additional data to be reported/queried upon, additional analytical business cases and/or new business users etc.
For a growing/large business warehouse management system, customers would need to come up with a system landscape roadmap by solving the puzzle highlighted in Figure 1. For simplicity sake, we can call this SAP Business warehouse – data growth puzzle.
On a high-level, this puzzle has 4 different dimensions:
1. Data Optimization: What can be gained on SAP BW on HANA?
2. Multi-Temperature data management: SAP Dynamic Tiering or Near-line Storage or both?
3. Scalability of SAP BW on HANA system: SAP HANA scale-up or scale-out?
4. Business continuity: Ensuring high availability(HA) and disaster recovery(DR)?
Understanding all the dimensions separately and making it work together to provide a scalable business warehouse solution is the key to derive this roadmap. This will ensure decision support continuity and enhanced emphasis on analytics.
Standard HANA sizing guidelines for BW suggest 50 % of the data footprint for the available RAM so that there is sufficient space available for the intermediate query/reporting result-sets. Hence, this roadmap preparation is inevitable once existing / planned system data size approaches 3-4 TB (this limit may vary depending on the business cases and hardware availability).
Figure 1. Several options to manage SAP BW on HANA data: The Data growth puzzle
Data Optimization
An ‘as-is’ migration of SAP BW from RDBMS to HANA can be done and it will bring some instant gains. However, without optimizing the system data/code, the full potential of the new BW on HANA system cannot be realized. One of the ways to optimize the landscape is to remove the existing redundant data.
A classical SAP BW system on RDBMS would have a lot of Info-cubes underneath to improve its performance. These Info-cubes are usually 1:1 copies of data in the DSO (Data Store Objects) layers. As on HANA, these Info-cubes provide no additional performance benefit, they can be decommissioned once all the queries are re-directed to the original DSO’s. By performing this step, the data footprint will reduce and system performance can be gained. Additionally, this simplified data flow will reduce data mapping related errors.
When it comes to the data growth problems, this will give some additional breathing space to the system. This is an option that can be considered first up. Continuous improvement and optimization should also be planned alongside.
Multi-Temperature data management
Based on the access frequency, the data can be classified as hot, warm or cold.
In case of ‘cold’ historical data, SAP IQ based Nearline storage can be used to offload the data and reduce main-memory data footprint further. Typically, the data is sliced based on the time dimensions or it can be completely moved into the cold storage DB.
The read access to IQ NLS is in most cases much faster than READ access to the traditional databases. The unique advantage of such a native solution is that the performance of the BW query that requires the data from the Sybase IQ store can be optimized using HANA SDA (Smart Data Access). Smart data access enables remote data access as if they are local tables in HANA without copying data into HANA.
In case of the ‘warm’ data, dynamic tiering (DT) offers a consolidated mechanism to manage less frequently accessed and less critical data without the reduction in performance. The dynamic tiering server store extended tables on an extended node and try to optimize the RAM utilization within HANA. Main HANA and DT nodes share a common database making these nodes an integral part of the system. In case of DT, all data of a PSA (Persistent Staging Area) and w/o optimized DSO objects is in the PRIMARY disk. DT uses the main memory of the extended node servers (which can be powerful HANA nodes loaded with processing power) for caching and processing the data. The data stored on disks is accessed using the sophisticated algorithms.
While sizing the storage on the extended DT nodes, certain guidelines should be adhered to for e.g. SAP the recommended ratios of SAP HANA memory to SAP HANA dynamic tiering extended storage as per the SAP Note: 2086829 are:
SAP HANA memory <= 2.5TB: dynamic tiering storage should not exceed 4x the size of SAP HANA.
SAP HANA memory > 2.5TB: dynamic tiering storage should not exceed 8x the size of SAP HANA.
The ‘hot’ data would by-default reside in-memory and if this data is large the scalability mechanisms highlighted in the next section need to be considered.
Scalability of SAP BW on HANA System
BW on HANA is generally available for both single node and scale-out architectures. Choosing between scale-up and scale out can be subtle and must be eventually balanced with the costs.
In my opinion, if the actual data size is 3 TB or more (with expected data growth) then the scale-out design is the preferred option.
Existing BW systems can be evaluated using several mechanisms and future landscape design can be arrived at by following simple decision matrix highlighted in Figure 2.
Figure 2. SAP HANA Scale-up or Scale-out decision matrix
*Source: Digital Business Services Group and SAP HANA Enterprise Group
The typical scale-out architecture and for an SAP BW on HANA system is highlighted in Figure 3.
Figure 3. Scale-out Architecture SAP BW on HANA
Business continuity
To ensure that an organization can continue to operate in case of failures within a single datacenter or disasters/ catastrophic events across datacenters, it needs to have a plan and this plan need to consider three different aspects i.e. resilience (via spare, replication etc.), recovery (auto-recovery VM’s, automatic failover nodes etc.) and contingency (process in case of unforeseen conditions).
Various techniques to handle single failures within one datacenter can be categorized under ‘High Availability’ (HA) and failures across datacenters fall under ‘Disaster Recovery’ (DR).
High Availability of a BW on HANA system
For a single node HANA system, depending on the type of the HANA node (VM or bare metal), size of the node etc. a dedicated standby node is required. HANA uses HSR (HANA System Replication) with synchronous mode (to avoid any data loss) or Host Auto-failover mechanisms to guarantee the system recovery in case of failures.
HANA scale-out clusters are also safeguarded via standby node that can take the role of any node (master or any other worker/slave node). In case of large HANA clusters, a secondary standby node can be considered (but this also depend on the underlying clustered file system).
For BW ABAP app servers, the auto-recovery mechanism of the underlying virtual machine technology or additional redundant app servers can be used, to route the incoming requests properly a load-balancer or pair of HA-enabled web-dispatchers might be needed.
Disaster Recovery of a BW on HANA System
Two sets of BW systems need to be maintained in SYNC across two different data centers (can be short distance i.e. less than 50KM or long-distance i.e. more than 50KM) to ensure a reasonable RPO (Recovery Point Objectives) and RTO (Recovery Time Objective).
HANA systems can be configured in active-active pairs and asynchronous HANA replication can be configured across geographically remote systems. For the application servers, the file system replication should be configured. In case of disaster, the network should be able to route incoming requests to the secondary site.
SAP Hana Enterprise Cloud (HEC) approach
Existing customers often engage SAP to understand how SAP can support them in managing growing BW systems efficiently? What it takes to move these systems into SAP’s private managed cloud offering i.e. SAP Hana Enterprise Cloud (SAP HEC)? In the process, they also want to know if it can help them reduce the total cost of ownership and increase agility by optimizing operational efforts.
SAP HEC is a private managed cloud offering to help accelerate HANA adoption. The HEC service is designed to emulate customer’s on-premise environment in a cloud model (with SLA’s, can be subscribed, short-term projects/long-term production, application management services) and it can be deployed on Hyper-scaler environments such as AWS, Azure etc. Hence for SAP’s large heterogenous on-premise customer base, this offering is serving as a “bridge to the cloud”. Additionally, ‘net new’ customers also like SAP HEC as it helps them manage systems, licenses, operations, integration etc. in a single flexible contract (subscription, partial subscription or full subscription), so they can continue to ‘Run Simple’.
A very good introduction to the SAP HEC services is offered in the blog highlighted here.
In the context of SAP BW on HANA System, I would like to highlight one of the initial SAP HEC service here that can assist customers in solving SAP BW on HANA Data puzzle and arrive at a very viable potential landscape roadmap.
SAP HEC Assessment and Advisory service
In context to SAP BW on HANA, assessment service will allow a cloud architect to understand the ‘as-is’ state of the BW system. It is a collaborative exercise where a ‘to-be’ state for a viable solution can be defined. For existing customers, assessment discussion would revolve around BW on HANA sizing report outputs (Note: 2296290), available EWA reports, software versions, add-on’s, existing interfaces, new requirements, analytics tools, possible network solutions, request routing from client tools to SAP HEC (DNS zone transfer etc.), total number of users, expected concurrent users, different viable approaches to manage system data growth, system deployment phases, type of systems, type of application servers, SLA’s for non-production and production system, HA/DR requirements, potential deployment areas and regions, special requirements, support model for HEC, HEC roles and responsibilities, need for on-boarding and migration service etc. ‘Net new’ customers would be advised based on the list of provided requirements and points highlighted above.
A typical output of such an assessment would be a potential solution design based on SAP HEC reference architectures including network topology and pricing for the solution. The solution design will adhere to design principles & guidelines recommended by SAP product development, delivery, operations, maintenance and application management teams.
Figure 4 is drawn specifically to showcase how multi-faceted puzzle of data growth can be managed by SAP in HANA Enterprise cloud. Moreover, additional SAP Services help simplify the overall operations to achieve the required return on investment and reduce total cost of ownership.
Figure 4. SAP HEC – Reducing TCO for SAP BW System
No comments:
Post a Comment