Skip navigation
1 2 3 Previous Next

Hitachi Solutions for SAP

44 posts

A few highlights from the Hitachi Solutions for SAP #SAPPHIRENOW event.

 

Paul_Lewis_Digital_Transformation_2018_SapphireNow.jpg

Paul Lewis sharing digital transformation insights.

 

SAPPHIRE_NOwVideo_Intelligence.jpg

Gunther Dell presenting on video intelligence.

SAPPHIRENOW_2018_PaulLewis.jpg

Paul Lewis presentation.

VMware_SAPPHIRENOW_hitachi.jpg

Erik Rieger from Hitachi Solutions for VMware presenting in the Hitachi Vantara booth.

There was a time when all the data you needed to effectively train for endurance events, like cycling and running, was a stopwatch with a second hand.  Now power files from the top pros are (largely) kept secret and those of competitors from local amateurs to world champions are dissected by watts, cadence, heart rate, elevation, and more.  This data can be used to answer, or at least give some insight into, questions like:

  • Why did rider “x” lose contact with their group on the last hill?
  • What are my “limiters”?  Or, what part of my fitness is holding me back in my key events?
  • What are the most effective intensities and durations to be training at?

 

Big Data and Analytics have become such an integral part of the sport that top teams like Team Sky have a Chief Data Scientist. The Chief Data Scientist’s role on teams like Sky is, in part, to provide insights to guide equipment selection and racing strategy.  Do the aerodynamic advantages of deep carbon fiber rims outweigh their weight disadvantage? Knowing a cyclist only has so many kJ of energy to expend in a ride, where are the most effective parts of the course to apply them?

 

WKO4.pngWKO4 is an “analytics engine” of sorts for cyclists and runners training and racing with power meters.  Tim Cusick is the Product Lead for WKO4 and coach for several world, national, and state champions in cycling.  Tim also comes to cycling with a background in big data, analytics, and machine learning.  Tim was kind enough field a few questions about big data, analytics and how they’re affecting endurance sports.

 

Dave Krenik:  Tim, would you inform the readers on what WKO4 is and how it leverages analytics to help athletes?

Tim Cusick:  WKO4 is a robust analytical engine specifically designed for endurance athletes. It was devised to evolve the paradigm of performance data analysis (the process of breaking complex data into smaller parts in order to gain a better understanding of it) into true performance analytics (the discovery, interpretation, and communication of meaningful patterns in data).  Analytics is multidisciplinary and uses mathematics, statistics, models, and descriptive techniques, but at the time, the existing programs out there lacked most of these elements, so we had to start from scratch. First, we worked with Dr. Andy Coggan to develop a highly accurate model of the human power-duration relationship. Once we had an accurate model, we needed to build a system that would allow for a multidisciplinary analysis with the ability to add math and statistics.  WKO4 is the realization of these goals.

 

How does it leverage analytics to help athletes? Well, that answer has three parts.  First, the use of advanced analytics allows historical performance data to be diagnostic.  One of the hardest things for a coach or self-coached athlete to do is to truly understand any particular athlete’s needs.  WKO4’s analytical capability provides a 360-degree view of an athlete from both a performance and physiological standpoint, which significantly improves the ability to diagnosis that athlete’s needs, thereby creating more effective training strategies.

 

Second, WKO4 gives us the ability to track training efficacy by increasing the timeliness and amount of analytics of the dose-response relationship of training stimuli and adaptation. This enables faster insights and training adjustments to ensure results.

 

Finally, analytics solves problems. All athletes train with a plan until something goes wrong or does not work. WKO4’s analytics supply deep insights into athletes’ performing physiology, and these insights lead to better solutions during crisis or change in training.

 

DK:  Does WKO4 use any of the of the available big data/analytics technologies like Hadoop?  Spark? Why/why not?

TC:  Well, before answering that, let’s clarify an important difference. Hadoop is a distributed file system, which isn’t applicable to WKO4; WKO4 is a desktop application and does not have that much data to require such a thing. Spark is simply a computing engine for Hadoop data. So to answer your question, we used standard big data and machine learning to develop our models, and then we took those models and implemented them in WKO4. Users can then apply our models to their own data to gain deeper insight.

 

DK:  Where do you see analytics and/or machine learning taking endurance athletics?  Catching cheaters?  Automated training programs?

TC:  I think the future is really in the evolution of analytics. If we look at how big data has led the way, we see a three-step evolution in data analytics: descriptive to predictive to prescriptive. What does this mean? Descriptive analytics can be called reports, and their function is to gain insight(s) from historical data with reporting, scorecards, and charts. Simply put, you review the data in well-compiled reports, find patterns on your own, and make decisions. Predictive analytics is the analysis of a variable (or set of variables) that can be measured for an individual to predict future behavior, or, more simply put, a solution. I think WKO4 was on the forefront of this evolution, moving from data analysis in well-formatted reports to using power analytics to create solutions. Our future goals are to continue to push the envelope and develop the third step—prescriptive analytics. This involves using predictive analytics to recommend decisions using optimization and target results, thus evolving from descriptive to predictive to prescriptive. If we think about it from the standpoint of what an athlete gets from his/her data, the evolution is from reports to solutions to decisions, which is an exciting benefit for athletes.

 

To address the specific question about catching cheaters, I don’t believe that is on the horizon, as you need to 100% sure of the quality of the data coming in, which is the core challenge. An athlete with a faulty data-gathering device, power meter, or heart rate monitor might be labeled a cheater when in reality it was the device that malfunctioned.

 

DK:  How might all this impact the coaching profession?

TC:  I have a simple answer here. Give a good coach an advanced tool, and you make a better coach. Give a poor coach an advanced tool, and you create confusion and misunderstanding.  The point here is that as data evolves, so must coaches. These advanced tools can revolutionize the coaching business by improving your athletes’ performance, but only if you invest in the learning and use the data to remove bias.

 

Thanks Tim – much appreciated.

 

On the subject of analytics, I should point out that SAP’s big end-user and Partner event – SapphireNOW– is this week (June 4-7) in Orlando, FL. Hitachi Vantara (including yours truly) will be present at the event.  During Sapphire we will be showcasing Hitachi’s great experience and expertise in helping customers make the most of their SAP investment for greater than 23 years. In particular we will be showcasing Hitachi Vantara’s integration with SAP on a Video Intelligence for Smart Cities demo.  We will also be demonstrating the new, enhanced, feature/functionality of Hitachi’s Storage Adapter for the SAP HANA Cockpit.  This adapter simplifies management and greatly streamlines processes for Admins working with SAP HANA.

 

SAPPDI.pngWe will also be showcasing new certifications for SAP’s Appliance and Tailored Datacenter Integration (TDI) programs.  Whether looking to leverage the management simplicity and performance of the Appliance model or wanting to leverage existing resources in the datacenter (TDI), Hitachi Vantara has certified offerings to help meet your business goals and grow with your business.  Lastly, we will be announcing a reference architecture that leverages the data integration capabilities of Pentaho software.  Data comes in several types:  structured, unstructured, and semi-structured. Pentaho Data Integration helps pull all your data sources (SAP HANA transactional databases & data warehouses, Hadoop, and NoSQL databases (like MongoDB)) together and realize the efficiencies of tiering data based on usage and gaining actionable insights from data with real-time access.

 

Big Data, Machine Learning, and Analytics already have made their way into our everyday lives. Addressing questions like “how hard should I go and for how long?” is only the beginning.  Cookie-cutter training plans will soon come to an end – freeing coaches to perform more value-added work with their clients.

 

Be sure to come see Hitachi at SAP’s Sapphire Now Conference (booth #1307) – time to ride…

Analysts, software companies and even some end users are convinced that each microgram of data counts. It must be retrieved from wherever it “lives”, no matter what it looks like. Then, it has to be housed for a long term in a place guaranteeing the best analysis conditions.

 

There are, of course, several real life targets for that, such as Smart City, Smart Factory, Predictive Maintenance, Intelligent Vehicle, and Precision Agriculture. Some may sound futuristic whereas others are already part of our lives.

 

From a terminology perspective we have to deal with: Natural Language Processing, Sentiment Analysis, IOT, Data Streaming, Event Processing, Machine Learning, Predictive analytics… and of course, “Big Data”.

 

To achieve that, on the technical side we need tools and storage. In the SAP world we have that of course: HANA (and IQ). Nothing to say on the quality of the tools, but the cost of storage itself is daunting: as you remember, we work (mostly) in memory!  So, the idea is to put the huge amounts of data into a place that is tightly integrated with the SAP world. This place is Hadoop.

 

In short, Hadoop is an Apache (~free) project for storing and handling big amounts of data. The technical inspiration came from Google when it released the MapReduce algorithm in 2004. For the less technical part, and how the name came to be – at the time, Doug Cutting’s son (creator’s son) had a toy elephant named Hadoop.

 

SAP use cases

 

SAP supports Hadoop in some technical and business scenarios.

 

The DWF v1.0 (Data Warehousing Foundation) is a set of tools for data management. Among these tools, the DLM (Data Lifecycle Manager) is able to move the data according to its “temperature”. Cold data, i.e. infrequently used, can be stored according to predefined rules in a “cold store” that can be IQ, HANA Dynamic Tiering engine, as well as Hadoop.

 

The red arrows and forms show the data move which is customized (“what to move and where”) and scheduled (“when to move”) in HANA in an application running on top of the internal application server (the XS engine). In this example data is moved from HANA to Hadoop.

 

The black arrows show the path of an SQL query fetching data. This happens through a “Union View” which makes the underlying physical structures transparent for the application.

 

This mechanism is pure database oriented. In other words, this is a table oriented tool with no application level intelligence, meaning that it is not possible to ship purchase orders (for example) from HANA to Hadoop.  A purchase order is a business object spread over a quantity of tables. To be able to ship it from one place to another, we need knowledge similar to that of the archiving process (relationships between tables and even other related objects).

 

Hopefully the data aging process of S/4HANA will be able to use it in future versions.

 

SAP CAR (Customer Activity Repository), a retail industry oriented application, belongs also to the processes and applications for which SAP has documented the way to couple it to Hadoop. One of the functions of SAP CAR is to integrate the sales data from the stores for aggregation and then to send the aggregated results to the ERP (sales orders, goods movements, a.s.o.).

 

The non-aggregated remaining data could certainly be reused, for example for behavior analysis and forecasting purposes. The problem is of course the volume. And here comes Hadoop again.

 

SAP explains that there are two ways ship and hold CAR data on Hadoop:

  1. Transfer data from CAR to Hadoop with an SAP given report. Currently, this options (table content aging report) does not have a lot of documentation, except this explanation on SAP website.
  2. Use SDA (Smart Data Access) and create, for example, the TLOGF table (one of the biggest) on Hadoop. More on that can be found in the “Quickstart HDA for CAR 2.0 FP2” guide.

 

Of course, all other trendy processes and applications dealing with big data and running on SAP HANA or other SAP engines can take advantage of Hadoop. Hereunder an example combining the Complex Event Processing platform with its sources (IOT, Sentiment Analysis) and outputs.

 

Almost every data stream, whatever its nature, can go through an event processing engine for real-time analysis (for computing KPIs & raising Alerts for example). This can be sensor data from factories, trains, football players, or it can be discussion flows on Twitter.

 

Here also, the question is the same as for retailers with CAR: what to do with this data, that could potentially contain important information? Then, the answer could be the same: Hadoop.

 

What is Hadoop (more than a Google smelly toy)?

 

The heart of Hadoop has four major components:

  • Entry level servers.
  • A distributed filesystem (HDFS) spreading data across the cluster in a redundant way.
  • A resource negotiator (YARN) handling the workload distribution on the resources.
  • A Java framework (MAP REDUCE) enabling application development on top of the Hadoop cluster.

 

The next picture depicts that minimalistic Hadoop landscape from above in the center of a large ecosystem. It is not possible to represent all the members but here are some major ones:

 

It is important to note that most of these tools have their counterpart in terms of functionality in the SAP world (ex: Graph processing and Machine Learning are integrated into HANA, same for Workflow engine and Scheduler, other tools are concurrent to SAP CEP, Data Services and Lumira).

 

Other “semi-free” products like Pentaho can also cover several aspects around Hadoop like data integration and analytics as well as act like a bridge to other ecosystems (SAP, MongoDB…). It is “semi-free” because some of the tools need to be purchased on a subscription model (see for example the Pentaho Wikipedia page).

 

All of these tools are covered by lots of literature and are Apache (sub-) projects by themselves so we won’t talk about each of them. YouTube and Wikipedia will be good entry-points to learn more about them. However, we cannot talk about Hadoop without saying a few words on the frameworks and especially on MapReduce (especially since the goal is to discuss SAP Vora later on). Let’s try to understand its mechanism using an example.

 

The most common MapReduce example is the Word Count program. It is shipped among the example programs when you install Hadoop. The word count program tells you—for a given input file—how many times you see each word.

 

Here is how it works:

 

This is a simplified version because words were replaced by single letters and some intermediate steps (sort & shuffle) are not represented.

 

Programs running in the MapReduce framework have two procedures: map() and reduce(). These procedures are distributed and run in parallel in the Hadoop cluster:

  • The Map procedures will filter and sort the input and write output files containing “key,value pairs”. Here it associates each letter with 1. These Map output files are used by Reduce procedures as input files.
  • The Reduce procedures will aggregate the Map output and produce a result file.

 

What does not appear on the schema is that all the intermediate results are written and read from file and therefore make the MapReduce program IO intensive. The answer to that problem is Spark, which is another framework running also on top of Hadoop (HDFS & YARN).

 

Here is the rough difference at technical processing level:

  • Spark uses memory rather than file for intermediate storage. Where MapReduce defines a “small” (~100 MB) buffer for intermediate storage and writes to file when a buffer overflow occurs, Spark relies on operating system memory management mechanisms. Data is written to virtual memory, meaning that the operating system decides whether to put it into RAM or SWAP.
  • MapReduce systematically reads all the data from the input file and then start working. Spark starts processing only once it knows what kind of result is expected, so for example it can filter the input file and fetch only the relevant lines.
  • Spark is not bound to YARN & HDFS. It supports other cluster engines (Mesos) and has also its own. Same for the distributed filesystem, you can also use Amazon S3.

 

On the “functional” side, Spark differs also from MapReduce:

  • Spark includes natively some functions that are to be installed separately in a MapReduce context like Machine Learning, Streaming and Graph Processing. Graph processing, for example, gains to be run in Spark regarding the I/Os because this kind of processing has a lot of intermediate results. Better keep them in memory.
  • The initial Spark user interface is a shell (three are available: Scala, Python & R) which means that you don’t have to proceed to complex developments. The same spirit can be found on MapReduce side if you decide to install and use Hive.
  • Of course some tools can work with both: Oozie, Avro, Parquet.

 

When SAP enters the ring

 

For a couple of years (2001-2002), the trend was e-commerce and the underlying J2EE application servers. SAP acquired one of these Java application server editors: IN-Q-MY (with CEO Shai Agassi – do you remember?). The interesting part was when SAP “opened” the J2EE server and modified it (by developing closer integration towards the ABAP engine, adding table buffering capabilities) and named its whole technical layer (ABAP & JAVA): the Web Application Server (WAS).

 

Similarly to this “Java adventure”, now that the trend is big data & IoT, SAP is on its way towards Hadoop and comes with “Vora” in its luggage. Or, according to SAP AG, “HANA Vora” even if it does not sit on HANA but is integrated into Hadoop Spark. Vora contains SAP developments and even third party tools since Vora 1.2: HashiCorp Consul replacing (?) Zookeeper functionalities from earlier releases. SAP modelled the Java engine to fit its needs and now the same is happening to Hadoop.

 

Here is a high-level view of HANA and Vora.

 

Note: The arrow depicting the relationship goes in both directions:

  • Vora can access HANA (HANA is seen as a data source accessible using SPARKSQL); and
  • HANA can access Vora (via Spark Adapter/Controller).

 

For a complete overview of HANA <-> HADOOP integration, here is a link to SAP Online Help.

 

Check also Vora developers guide to see more details regarding how to access HANA data from Vora.

 

What can I do with Vora? The answer in version 1.2 is : “SAP HANA Vora enables OLAP analysis of Hadoop data, through data hierarchy enhancements in SparkSQL."

 

Here is an example on the OLAP-way of seeing data when it is organized in hierarchies, thanks to Vora and HANA (the business related technical terms are in French, but it isn’t critically important for general understanding).

  • On the left hand side, we have a train (most probably the common ancestor of TGV & Shinkansen) with sensors sending raw data to Hadoop.
  • On the right hand side, there is an application running in HANA which has the knowledge of the Bill of Material of our train. Could be an MRO application.
  • Both of these worlds have to be combined (joint) to have suitable information. With hierarchical enrichment of sensor data we are able to:
    • Raise an alert only if both thermometers are giving extreme values because we know they are on the same hierarchy level. If only one shows a critical value we have to further investigate to know if there is a problem on one thermometer and maybe also the train.
    • Anticipate which are the parent components that will fail in case of a child failure or the other way round
    • And more.

 

This is possible because Vora knows how to deal with hierarchies. They are integrated in a normalized form to Vora (cf. table in the picture) and can be queried with special functions like level(u), is_root(u), is_child(u,v), is_ancestor(u,v)… More on that in the developers guide.

 

Check also videos on this subject from the HANA Academy, available on YouTube. Here is the first in a series of 3 videos.

 

According to the “DMM200 – SAP HANA Vora: Overview, Architecture, Use Cases, and Roadmap” session at TECHED 2016, release 1.3 of Vora should also incorporate a time series engine and a graph engine, among other things. These features already exist in HANA, so when running both HANA and Vora, the question will be: “On which side should I run my calculations?”

 

Vora from a technician’s perspective (install, operate, size..)

 

Installation. Vora is an SAP product. In the SAP context, installation tasks have strong guidelines. Currently, three Hadoop distributions are certified by SAP: MAPR, Hortonworks and Cloudera. Check note 2213226 - Prerequisites for installing SAP HANA Vora: Operating Systems and Hadoop Components

 

Operations. Administration of the Hadoop cluster is done with tools like Ambari. For monitoring, Ganglia is a good candidate.

 

Data backup and safeguarding. Production Data in a Hadoop cluster can have the same criticality as in an ERP. Traditional backup tools exist with Hadoop agents (ex: Commvault). Another solution to safeguard data is to create a replicated cluster and use Hadoop native Apache DistCP2 tool.

 

Development. In a Hadoop environment, developments have the same importance as anywhere else in the IT world. This means that versioning, deployment and overall organization must rely on robust processes and tools. Here we are talking about tools like GIT, Jenkins & Maven as well as home grown scripts.

 

Regarding landscape and sizing, SAP as well as each component comes with recommendations.

 

The figures here are initial recommendations taken from installation and sizing guides. In addition to the initial guidelines, SAP gives also formulas for more precise estimation.

 

Here is a starting point:

 

In the SAP world we are used to have almost accurate sizings with the SAP Quicksizer tool. There is no such tool in the Hadoop world. The best recommendation is to make sizing benchmarks with significant amount of data, to be able to make the best extrapolations.

 

Here are three examples of hardware hosting Hadoop clusters:

 

Hadoop runs well on Raspberry PI. I have some doubts regarding Spark & Vora.

 

----------------------------------------------------------------------

 

Christian Lindholm is a leading Technical SAP Architect at oXya’s headquarters in Paris, France. Joining oXya in 2008, Christian has nearly 20 years of experience in technical SAP roles, starting as an SAP Basis Admin and progressing to one of oXya’s leading Technical SAP Architects around the world. In his role, Christian works with SAP customers around the world to design, optimize and implement complex solutions, to serve customers’ unique needs.

 

oXya, a Hitachi Group Company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~700 SAP experts, who service more than 330 enterprise customers with hundreds of thousands of SAP users around the world.

This blog is intended to assist you in protecting the data in your SAP HANA environments following the different backup, disaster recovery, and high availability solutions documented in various white papers.

 

For reference, here are links to collateral's documenting solutions for protecting SAP HANA environments.

 

Collateral's for Data Protection

The SAP HANA database keeps the bulk of its data in memory, using persistent storage to provide a fallback in case of failure. However, if the persistent storage is damaged due to disk failures or database corruption, backup provides protection against data loss. Refer to the following data protection-related documents:

Collateral's for Disaster Recovery

To protect customer's data in the event of a disaster, the customer needs two sites with the disaster recovery solution in place. Refer to the following disaster recovery solutions in the documents below:

 

Collateral's for High-Availability Solution with Scale-Up

The UCP for SAP HANA scale-up appliance configuration can be extended by adding another node to provide high availability following different solutions tested, as documented in the papers below:

When it comes to digital transformation, data is one of the biggest challenges that today’s organizations face. Data holds tremendous value and competitive advantage if you extract the right insights, but there’s more of it than ever. It pours in from global commerce and mobile platforms and through new Internet venues and social media. Then there’s the sheer quantity of internal data around customers and business processes, not to mention the growing datasets produced by billions of Internet of Things (IoT) connected devices.

The fact is that today’s digital world is causing radical upheaval in the systematic ways that businesses operate. And the possibility for enterprises to capitalize on this disruption becomes endless as IoT and artificial intelligence increasingly enable back-end systems that seamlessly connect sales and manufacturing to create more digital-powered end-to-end capabilities.

However, with these opportunities come a number of challenges for organizations across all industries. How do you integrate this data? How do you analyze it? Perhaps the single most important question is how to modernize current business processes and infrastructures to turn data into a competitive advantage. This challenge can be particularly significant for SAP environments because they are large and complex, and they often represent years of investment.

New solutions from Hitachi and SAP are designed specifically to transform legacy applications, infrastructures and processes into modern platforms that can handle growing amounts of data and that fully extract the value of that data.

How do we do it? We recognize that digital transformation is all about the data. We offer innovative services, solutions and infrastructure that help you access, manage, integrate and analyze that data. In addition, we can assist you at any stage of the journey – whether it’s early exploration on how to extract the full value of your data, proofs of concept that demonstrate the power of truly integrated solutions, or the deployment of some of the most forward-thinking data offerings on the market today.

For instance, the Hitachi Content Platform (HCP) portfolio is the only offering on the market that allows organizations to bring together object storage, file sync and share, cloud-storage gateways, and sophisticated search and analytics to create a tightly integrated, simple and smart cloud-storage solution. HCP provides massive scale, multiple storage tiers, powerful security, cloud capabilities, multitenancy and configurable attributes for each tenant, all backed by legendary Hitachi reliability. In addition, it carries built-in data-protection mechanisms and is designed to fluently evolve as storage technologies change.

Hitachi holds in excess of 2,000 patents for analytics technology – more than anyone else in the market. “Our objective has always been to help customers modernize traditional IT environments as a first step, with the ultimate goal of providing a foundational solution to allow them to extract value by using their data in new and interesting ways," says Peter Sjoberg, chief technology officer, cloud and mobility for Hitachi Data Systems.

In other words, we are uniquely positioned to offer companies like yours the services and technologies you need to adopt new business models that help you operate at the lightning speed demanded by today’s digital economy. We help you exceed customer demands – rather than just meet them – and we help you generate greater revenue with reduced costs so you can stay in business for a long, long time. And we offer a strong, fast return on investment (ROI), all while helping you increase revenue (more than nine percent on average) and boost profitability (more than 26 percent).1,2

Isn’t it time to rethink your operations for the new economy?

  1. Start by viewing our SAP Solutions.
  2. Take a look at how our solutions can help.

 

____________________________

 

1 Capgemini. “The Digital Advantage. How digital leaders outperform their peers in every industry.” www.capgemini.com/resource-file-access/resource/pdf/The_Digital_Advantage__How_Digital_Leaders_Outperform_their_Peers_in_Every_Industry.pdf

2 World Economic Forum. “Digital Enterprise.” http://reports.weforum.org/digital-transformation/wp-content/blogs.dir/94/mp/files/pages/files/digital-enterprise-narrative-final-january-2016.pdf.

Think of all the line-of-business (LOB) apps you rely on to compete today, and then consider how you want to operate and compete in the future. Will your current IT infrastructure get you there? Or are there just too many functional constraints within your legacy systems for you to achieve your visions for operational improvements?

The reality of today’s business world is that IT departments and business units are tightly connected. After all, technology lies at the heart of how businesses connect, communicate, operate and compete. But it is complicated to align the infrastructure, applications and business processes needed to operate today’s demanding business model. Even worse, it can become overly complex – even paralyzing – to set a vision and align technologies when future objectives are ill-defined and every dollar of expenditure is subject to scrutiny.

Organizational infrastructures – servers, storage and network components, along with the apps that run on them – are intricate, often cumbersome, and represent years of investment. Therefore, the challenge becomes how to modernize those systems so that they deliver today and in the future. And that leads to a whole different set of questions around cost and complexity.

That’s where Hitachi and SAP can help. We know that modernization is urgent for any organization that needs a competitive advantage. Our world is dynamic and fast-paced. Customers expect more, and they expect it in real time. For business leaders, modernization is about the transformation of big data into actionable insights and the generation of process improvements from the Internet of Things (IoT). It’s about running the business more effectively while providing better customer experiences.

Hitachi helps create SAP infrastructures and software solutions to enable dynamic business processes that can respond to unforeseen objectives and shifts in customer demands. How do we do it? We work with you to understand your business. By combining our IT and subject-matter expert (SME) industry experience from across more than 950 subsidiaries, Hitachi can develop a modernized infrastructure that melds with your company’s business strategy. Often, this process entails moving from inefficient, overly complex systems where data is siloed to modern platforms that consist of simplified and agile solutions that can more effectively support a changing future.

Together, solutions from Hitachi and SAP are ideal for businesses that want to modernize. Based on years of collaboration, you see greater performance – such as 38% faster application development and deployment time.[i] You also see higher availability of key systems. On average, we help save US$1.38 million in user productivity benefits per year.2 One company even reduced total cost of delivery by 85%.[ii] In addition, higher consolidation and reduced operational costs can dramatically lower total cost of ownership (TCO).

  Are you ready to modernize your SAP environment? Are you ready to see what a future with Hitachi solutions can achieve? Check out our infographic. Then, take a look at our solutions for help with your digital transformation.



[i] IDC. “Achieving Value with the Hitachi Unified Compute Platform.” www.hds.com/en-us/pdf/analyst-content/hitachi-infographic-achieving-value-with-ucp.pdf.

[ii] Hitachi Data Systems. “Infosys speeds operations with VMware Virtualization for SAP HANA on Hitachi Unified Compute Platform.” www.hds.com/en-us/pdf/case-study/hitachi-success-story-infosys-and-ucp.pdf.

SAP HANA is an in-memory database. New and changed data is written first to the SAP HANA memory, from where it is copied to the database persistence.

 

SAP HANA protects the database from power failures using its log area, frequent log area backups, and database savepoints (periodic save-to-disk of the newest data in the database). These all help to ensure that when the lights go out, the database is in a coherent state and can be safely recovered when the server is switched back on.

Unfortunately, what SAP HANA cannot protect against is a loss of the database persistence itself. Protection from the loss of database persistence requires regular database backups.

 

Hitachi Data Systems provides a backup tool for regular database backups: Hitachi Data Instance Director (HDID). This tool fully integrates with single-node SAP HANA databases to provide database snapshot-based backups on Hitachi Thin Image pools on Hitachi storage systems.

 

Data Instance Director can be used with many applications. Using HDID alongside a SAP HANA database allows the following three main functions:

  • Database backup and restore using HDID snapshots
  • Database backup and restore using HDID snapshots, plus SAP HANA log backup replay
  • Database copy (production to non-production, for example), using HDID snapshots

 

Database Backup, Restore Points, and Data Loss

One of the most important concepts to consider when implementing a backup policy is the recovery point objective — or RPO. This concept determines how much data might be lost in case of failure. If the RPO is one hour, then up to one hour’s data might be lost. Backing up with a lower RPO protects the database better, but also creates a higher load on the system. The following graphic describes the different backup and restore options available in a SAP HANA system.

 

Untitled.png

Source: SAP

 

The illustration above shows that, in case of failure, having the following can restore the complete database:

  • A database snapshot or a full backup
  • Log area backups
  • The log area itself, for the log entries not present in the latest log area backup

 

HDID can protect your SAP HANA database by creating backups of the first two of these items.

 

Database Backup and Restore Using HDID Snapshots

Hitachi Data Instance Director can create a snapshot of the SAP HANA data area, using the native ‘savepoint’ feature of SAP HANA itself. This adds very little overhead to the running system. This ‘savepoint’ occurs every five minutes (by default). These savepoint snapshots are then copied to a Hitachi Thin Image pool on the attached Hitachi storage system.

 

If a database restore becomes necessary, then HDID can do the following:

  • Stop the running SAP HANA instance
  • Revert the SAP HANA data area with a copy of the snapshot

 

The database can then be restored using the standard SAP HANA restore tools (SAP HANA Studio, or using the command line). Snapshot-based backups allow the database to be restored to the date and time the snapshot was taken.

 

Database Backup and Restore Using HDID Snapshots, Plus SAP HANA Log Backup Replay

For a more fine-grained backup policy, use Hitachi Data Instance Director to backup the log backup files for SAP HANA. Every five minutes or so, SAP HANA makes a backup of its redo-log area. These log backup files can be used, if present on the SAP HANA system, to allow a database restore to a more fine-grained time than only the snapshot date and time.

 

Using HDID to create backups of these log area backup files, alongside regular database snapshots, can allow the effective RPO of the backup to be as low as five minutes. It is not possible to back up the SAP HANA log area itself. This limitation exists in SAP HANA, because the database locks the files for its exclusive use. Only the log area backups can be saved by HDID.

 

Database backup using snapshots plus log area backups allows more fine-grained backup and restore times. During a database restore, the following happens:

  • Restores the SAP HANA data area and snapshot using HDID
  • Restores the log area backup files to their original locations (or another directory if preferred), again using HDID
  • Performs the database restore using the standard SAP HANA tools

 

The database snapshot is the basis for the restore. The log backups taken after the snapshot date and time are read automatically by the restore process.

 

Database Copy Using HDID Snapshots

While the main use of a database backup is to protect the installed applications from catastrophic data loss, one additional use case is system copy.

 

During a project lifecycle, it can be useful from time to time to refresh development and preproduction environments with a copy of the production database. Then you can use this copy for performance tests on comparable data volumes in the preproduction environment. Or, you can perform regression rests on real-life situations without impacting the production system.

 

Hitachi Data Instance Director can make the SAP HANA database snapshot visible to a second host. This makes replacing the SAP HANA data area in development or preproduction with the contents of the snapshot into a simple operation. You can do this with only a couple of commands under Linux.

 

Conclusion

Using Hitachi Data Instance Director, you can implement efficient backup and restore policies for your SAP HANA database, and even use it to make copies of your SAP HANA database.

 

To learn more about using Hitachi Data Instance Director on a scale-up SAP HANA database, please check the following implementation guide from Hitachi Data Systems: https://www.hds.com/en-us/pdf/white-paper/hdid-backup-for-scale-up-databases-on-sap-hana.pdf

The SAP HANA database keeps the bulk of its data in memory. It uses persistent storage to provide a fall-back in case of failure. However, if the persistent storage is damaged, you need snapshots of the database for recovery. The ability to restore real time data processing, such as the SAP HANA database, translates directly into revenue for your business.

 

In this, we will discuss how we can leverage Hitachi Storage Adapter for the SAP HANA Cockpit, which is storage management software to simplify IT. When used for infrastructure management, Storage Adapter for SAP HANA Cockpit uses Hitachi Thin Image (HTI) and Hitachi ShadowImage heterogeneous replication.

  • Hitachi Thin Image creates a storage snapshot of the data volumes. You can restore a SAP HANA database using this replica snapshot.
  • Hitachi ShadowImage heterogeneous replication creates a replica of logical volume in the same storage system without host. ShadowImage enables concurrent operations, such as backup and batch processing, with minimum impacts on online operation continuity.

 

This solution is for use by IT administrators, database administrators, storage administrators, SAP HANA administrators, and architects implementing snapshot, recovery, and cloning solutions.

 

Incremental Software and Hardware Components

As additional components to an existing scale-up implementation, you need the following components.

 

Hitachi Storage Adapter for SAP HANA Cockpit

Hitachi Storage Adapter for SAP HANA Cockpit is free-to-download software, which runs as a web application. When needed, the adapter calls the web service on the management server of the SAP HANA platform scale-up configuration. Then, the web service communicates to the attached Hitachi storage and returns the information to the adapter.

 

In addition, the web service collects device-mapping information from the SAP HANA host by using SSH. The web service executes SQL queries for retrieving information from the SAP HANA database.

 

The web service manages all configuration information, storing it in the local disk of the management server. Then, the adapter passes configuration information to the web service.

 

Hitachi ShadowImage Heterogeneous Replication

High-speed, non-disruptive local mirroring technology of Hitachi ShadowImage heterogeneous replication rapidly creates multiple copies of mission-critical information within all Hitachi storage systems.

 

ShadowImage heterogeneous replication keeps data RAID-protected and fully recoverable, without affecting service or performance levels. You can split replicated data volumes from the host applications and used for system backups, application testing, and data mining applications, while business continues to run at full capacity.

 

Hitachi Thin Image

The high-speed, nondisruptive snapshot technology of Hitachi Thin Image snapshot software rapidly creates up to one million point-in-time copies of mission-critical information within any Hitachi storage system or virtualized storage pool without impacting host service or performance levels.

 

Because snapshots store only the changed data, the volume of storage capacity required for each snapshot copy is substantially smaller than the source volume. As a result, Thin Image snapshot software can provide significant savings over full volume cloning methods.

 

Thin Image snapshot copies are fully read/write compatible with other hosts. They can be used for system backups, application testing, and data mining applications while the business continues to run at full capacity. Hitachi Storage Adapter for SAP HANA Cockpit uses Thin Image to create snapshots.

 

Additonal Hard Drives

You need additional hard drives to create a storage snapshot of the SAP HANA data volumes using Hitachi Thin Image or to create an exact replica of the logical volumes using Hitachi Shadow Image heterogeneous replication.

 

Use Cases and Best Practices

These are the use cases and best practices for Hitachi Storage Adapter for the SAP HANA Cockpit in Hitachi Unified Compute Platform for SAP HANA in a scale-up configuration to simplify IT management with storage management software.

 

Replicate Using Hitachi Thin Image

  • Use Hitachi Thin Image for backup to create a replica of the specified logical volume using a snapshot. Using Thin Image, you can create and restore a replica of an arbitrary point of time.
  • The capacity used to store a snapshot can be smaller than the storage needed to copy and store the entire volume data. This is because the snapshot data in the pool volume only stores data that is different from what is in the specified logical volume.
  • Hitachi Storage Adapter for SAP HANA Cockpit uses Thin Image to create snapshots of the SAP HANA database.

Replicate Using Hitachi ShadowImage Heterogeneous Replication

  • Hitachi ShadowImage heterogeneous replication creates a replica of logical volume (a pair) in the same storage system without a host. This software enables concurrent operations, such as backup and batch processing, with minimum impacts on online operation continuity. The ShadowImage pair performs all copy operations asynchronously after receiving the pair operation command.

Recover and Restore the Operating System LUN

  • Use Hitachi ShadowImage heterogeneous replication to create a local replica (S-VOL) of the operating system LUN (P-VOL) in the same storage. This replica can be used to restore the operating system in case of failure.

Recover and Restore the SAP HANA database Storage Snapshot

  • Create a SAP HANA storage snapshot to recover the SAP HANA database after a failure. Hitachi Storage Adapter for SAP HANA Cockpit uses Hitachi Thin Image to create a storage snapshot of the data volumes. Restore the SAP HANA database using this replica for a point in time recovery.

Copy and Clone the SAP HANA Database with Hitachi ShadowImage Heterogeneous Replication

  • Use Hitachi ShadowImage heterogeneous replication to create a local replica (S-VOLs) of the following in the same storage:
    • Operating system
    • SAP HANA shared
    • SAP HANA LOG
    • SAP HANA Data LUNs (P-VOLs)
  • You can use this replica to copy or clone the SAP HANA system.

 

 

Learn More

To learn more, see the following resources:

  Hitachi Storage Adapter for the SAP HANA Cockpit in Hitachi Unified Compute Platform for the SAP HANA Platform in a Scale-Up Configuration Best Practice Guide (PDF)

Analysts, software companies and even some end users are convinced that each microgram of data counts. It must be retrieved from wherever it “lives”, no matter what it looks like. Then, it has to be housed for a long term in a place guaranteeing the best analysis conditions.

 

There are, of course, several real life targets for that, such as Smart City, Smart Factory, Predictive Maintenance, Intelligent Vehicle, and Precision Agriculture. Some may sound futuristic whereas others are already part of our lives.01.png

 

From a terminology perspective we have to deal with: Natural Language Processing, Sentiment Analysis, IOT, Data Streaming, Event Processing, Machine Learning, Predictive analytics… and of course, “Big Data”.

 

To achieve that, on the technical side we need tools and storage. In the SAP world we have that of course: HANA (and IQ). Nothing to say on the quality of the tools, but the cost of storage itself is daunting: as you remember, we work (mostly) in memory!  So, the idea is to put the huge amounts of data into a place that is tightly integrated with the SAP world. This place is Hadoop.

 

02.png

In short, Hadoop is an Apache (~free) project for storing and handling big amounts of data. The technical inspiration came from Google when it released the MapReduce algorithm in 2004. For the less technical part, and how the name came to be – at the time, Doug Cutting’s son (creator’s son) had a toy elephant named Hadoop.

 

SAP use cases

 

SAP supports Hadoop in some technical and business scenarios.

 

03.png

The DWF v1.0 (Data Warehousing Foundation) is a set of tools for data management. Among these tools, the DLM (Data Lifecycle Manager) is able to move the data according to its “temperature”. Cold data, i.e. infrequently used, can be stored according to predefined rules in a “cold store” that can be IQ, HANA Dynamic Tiering engine, as well as Hadoop.

 

The red arrows and forms show the data move which is customized (“what to move and where”) and scheduled (“when to move”) in HANA in an application running on top of the internal application server (the XS engine). In this example data is moved from HANA to Hadoop.

 

The black arrows show the path of an SQL query fetching data. This happens through a “Union View” which makes the underlying physical structures transparent for the application.

 

This mechanism is pure database oriented. In other words, this is a table oriented tool with no application level intelligence, meaning that it is not possible to ship purchase orders (for example) from HANA to Hadoop.  A purchase order is a business object spread over a quantity of tables. To be able to ship it from one place to another, we need knowledge similar to that of the archiving process (relationships between tables and even other related objects).

 

Hopefully the data aging process of S/4HANA will be able to use it in future versions.

 

SAP CAR (Customer Activity Repository), a retail industry oriented application, belongs also to the processes and applications for which SAP has documented the way to couple it to Hadoop. One of the functions of SAP CAR is to integrate the sales data from the stores for aggregation and then to send the aggregated results to the ERP (sales orders, goods movements, a.s.o.).

 

The non-aggregated remaining data could certainly be reused, for example for behavior analysis and forecasting purposes. The problem is of course the volume. And here comes Hadoop again.

 

04.png

SAP explains that there are two ways ship and hold CAR data on Hadoop:

  1. Transfer data from CAR to Hadoop with an SAP given report. Currently, this options (table content aging report) does not have a lot of documentation, except this explanation on SAP website.
  2. Use SDA (Smart Data Access) and create, for example, the TLOGF table (one of the biggest) on Hadoop. More on that can be found in the “Quickstart HDA for CAR 2.0 FP2” guide.

 

Of course, all other trendy processes and applications dealing with big data and running on SAP HANA or other SAP engines can take advantage of Hadoop. Hereunder an example combining the Complex Event Processing platform with its sources (IOT, Sentiment Analysis) and outputs.

 

05.png

Almost every data stream, whatever its nature, can go through an event processing engine for real-time analysis (for computing KPIs & raising Alerts for example). This can be sensor data from factories, trains, football players, or it can be discussion flows on Twitter.

 

Here also, the question is the same as for retailers with CAR: what to do with this data, that could potentially contain important information? Then, the answer could be the same: Hadoop.

 

What is Hadoop (more than a Google smelly toy)?

06.png

 

The heart of Hadoop has four major components:

  • Entry level servers.
  • A distributed filesystem (HDFS) spreading data across the cluster in a redundant way.
  • A resource negotiator (YARN) handling the workload distribution on the resources.
  • A Java framework (MAP REDUCE) enabling application development on top of the Hadoop cluster.

 

The next picture depicts that minimalistic Hadoop landscape from above in the center of a large ecosystem. It is not possible to represent all the members but here are some major ones:

 

07.png

It is important to note that most of these tools have their counterpart in terms of functionality in the SAP world (ex: Graph processing and Machine Learning are integrated into HANA, same for Workflow engine and Scheduler, other tools are concurrent to SAP CEP, Data Services and Lumira).

 

Other “semi-free” products like Pentaho can also cover several aspects around Hadoop like data integration and analytics as well as act like a bridge to other ecosystems (SAP, MongoDB…). It is “semi-free” because some of the tools need to be purchased on a subscription model (see for example the Pentaho Wikipedia page).

 

All of these tools are covered by lots of literature and are Apache (sub-) projects by themselves so we won’t talk about each of them. YouTube and Wikipedia will be good entry-points to learn more about them. However, we cannot talk about Hadoop without saying a few words on the frameworks and especially on MapReduce (especially since the goal is to discuss SAP Vora later on). Let’s try to understand its mechanism using an example.

 

The most common MapReduce example is the Word Count program. It is shipped among the example programs when you install Hadoop. The word count program tells you—for a given input file—how many times you see each word.

 

Here is how it works:

 

08.png

This is a simplified version because words were replaced by single letters and some intermediate steps (sort & shuffle) are not represented.

 

Programs running in the MapReduce framework have two procedures: map() and reduce(). These procedures are distributed and run in parallel in the Hadoop cluster:

  • The Map procedures will filter and sort the input and write output files containing “key,value pairs”. Here it associates each letter with 1. These Map output files are used by Reduce procedures as input files.
  • The Reduce procedures will aggregate the Map output and produce a result file.

 

What does not appear on the schema is that all the intermediate results are written and read from file and therefore make the MapReduce program IO intensive. The answer to that problem is Spark, which is another framework running also on top of Hadoop (HDFS & YARN).

 

Here is the rough difference at technical processing level:09.png

  • Spark uses memory rather than file for intermediate storage. Where MapReduce defines a “small” (~100 MB) buffer for intermediate storage and writes to file when a buffer overflow occurs, Spark relies on operating system memory management mechanisms. Data is written to virtual memory, meaning that the operating system decides whether to put it into RAM or SWAP.
  • MapReduce systematically reads all the data from the input file and then start working. Spark starts processing only once it knows what kind of result is expected, so for example it can filter the input file and fetch only the relevant lines.
  • Spark is not bound to YARN & HDFS. It supports other cluster engines (Mesos) and has also its own. Same for the distributed filesystem, you can also use Amazon S3.

 

On the “functional” side, Spark differs also from MapReduce:

  • Spark includes natively some functions that are to be installed separately in a MapReduce context like Machine Learning, Streaming and Graph Processing. Graph processing, for example, gains to be run in Spark regarding the I/Os because this kind of processing has a lot of intermediate results. Better keep them in memory.
  • The initial Spark user interface is a shell (three are available: Scala, Python & R) which means that you don’t have to proceed to complex developments. The same spirit can be found on MapReduce side if you decide to install and use Hive.
  • Of course some tools can work with both: Oozie, Avro, Parquet.

 

When SAP enters the ring

 

For a couple of years (2001-2002), the trend was e-commerce and the underlying J2EE application servers. SAP acquired one of these Java application server editors: IN-Q-MY (with CEO Shai Agassi – do you remember?). The interesting part was when SAP “opened” the J2EE server and modified it (by developing closer integration towards the ABAP engine, adding table buffering capabilities) and named its whole technical layer (ABAP & JAVA): the Web Application Server (WAS).

 

Similarly to this “Java adventure”, now that the trend is big data & IoT, SAP is on its way towards Hadoop and comes with “Vora” in its luggage. Or, according to SAP AG, “HANA Vora” even if it does not sit on HANA but is integrated into Hadoop Spark. Vora contains SAP developments and even third party tools since Vora 1.2: HashiCorp Consul replacing (?) Zookeeper functionalities from earlier releases. SAP modelled the Java engine to fit its needs and now the same is happening to Hadoop.

 

Here is a high-level view of HANA and Vora.

 

10.png

Note: The arrow depicting the relationship goes in both directions:

  • Vora can access HANA (HANA is seen as a data source accessible using SPARKSQL); and
  • HANA can access Vora (via Spark Adapter/Controller).

 

For a complete overview of HANA <-> HADOOP integration, here is a link to SAP Online Help.

 

Check also Vora developers guide to see more details regarding how to access HANA data from Vora.

 

What can I do with Vora? The answer in version 1.2 is : “SAP HANA Vora enables OLAP analysis of Hadoop data, through data hierarchy enhancements in SparkSQL."

 

11.pngHere is an example on the OLAP-way of seeing data when it is organized in hierarchies, thanks to Vora and HANA (the business related technical terms are in French, but it isn’t critically important for general understanding).

  • On the left hand side, we have a train (most probably the common ancestor of TGV & Shinkansen) with sensors sending raw data to Hadoop.
  • On the right hand side, there is an application running in HANA which has the knowledge of the Bill of Material of our train. Could be an MRO application.
  • Both of these worlds have to be combined (joint) to have suitable information. With hierarchical enrichment of sensor data we are able to:
    • Raise an alert only if both thermometers are giving extreme values because we know they are on the same hierarchy level. If only one shows a critical value we have to further investigate to know if there is a problem on one thermometer and maybe also the train.
    • Anticipate which are the parent components that will fail in case of a child failure or the other way round
    • And more.

 

This is possible because Vora knows how to deal with hierarchies. They are integrated in a normalized form to Vora (cf. table in the picture) and can be queried with special functions like level(u), is_root(u), is_child(u,v), is_ancestor(u,v)… More on that in the developers guide.

 

Check also videos on this subject from the HANA Academy, available on YouTube. Here is the first in a series of 3 videos.

 

According to the “DMM200 – SAP HANA Vora: Overview, Architecture, Use Cases, and Roadmap” session at TECHED 2016, release 1.3 of Vora should also incorporate a time series engine and a graph engine, among other things. These features already exist in HANA, so when running both HANA and Vora, the question will be: “On which side should I run my calculations?”

 

Vora from a technician’s perspective (install, operate, size..)

 

Installation. Vora is an SAP product. In the SAP context, installation tasks have strong guidelines. Currently, three Hadoop distributions are certified by SAP: MAPR, Hortonworks and Cloudera. Check note 2213226 - Prerequisites for installing SAP HANA Vora: Operating Systems and Hadoop Components

 

Operations. Administration of the Hadoop cluster is done with tools like Ambari. For monitoring, Ganglia is a good candidate.

 

Data backup and safeguarding. Production Data in a Hadoop cluster can have the same criticality as in an ERP. Traditional backup tools exist with Hadoop agents (ex: Commvault). Another solution to safeguard data is to create a replicated cluster and use Hadoop native Apache DistCP2 tool.

 

Development. In a Hadoop environment, developments have the same importance as anywhere else in the IT world. This means that versioning, deployment and overall organization must rely on robust processes and tools. Here we are talking about tools like GIT, Jenkins & Maven as well as home grown scripts.

 

Regarding landscape and sizing, SAP as well as each component comes with recommendations.

 

12.png

The figures here are initial recommendations taken from installation and sizing guides. In addition to the initial guidelines, SAP gives also formulas for more precise estimation.

 

Here is a starting point:

 

In the SAP world we are used to have almost accurate sizings with the SAP Quicksizer tool. There is no such tool in the Hadoop world. The best recommendation is to make sizing benchmarks with significant amount of data, to be able to make the best extrapolations.

 

Here are three examples of hardware hosting Hadoop clusters:

 

13.png

Hadoop runs well on Raspberry PI. I have some doubts regarding Spark & Vora.

 

----------------------------------------------------------------------

2-color-oxya-hitachi-logo.png

Christian Lindholm is a leading Technical SAP Architect at oXya’s headquarters in Paris, France. Joining oXya in 2008, Christian has nearly 20 years of experience in technical SAP roles, starting as an SAP Basis Admin and progressing to one of oXya’s leading Technical SAP Architects around the world. In his role, Christian works with SAP customers around the world to design, optimize and implement complex solutions, to serve customers’ unique needs.

 

oXya, a Hitachi Group Company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~700 SAP experts, who service more than 330 enterprise customers with hundreds of thousands of SAP users around the world.

I’m excited to announce that once again Hitachi will be participating in SAP TechEd in Barcelona this year.  This year we are excited to be collaborating with our longtime partner, SUSE to present new solutions for SAP environments including SAP HANA, S/4HANA, and traditional SAP applications.

TECHEDBarca.png

Let’s consider the SAP experience and how it relates to our everyday life. We are all familiar with cars, right? You probably drive a car and understand how important it is to your everyday life. I don’t know about you, but when I drive I like to pretend I’m Mario Andretti or Michael Schumacher racing to the finish line, meaning, I want to get to my destination quickly and safely.  When I’m driving I feel like I’m one with my car! Well, that’s the experience your SAP Applications want too… to be one with their vehicle.  In the same way you drive your car, SAP Applications drive their SAP car. Together with SAP, Hitachi and SUSE have designed an SAP vehicle with a high performance SAP HANA engine that gives you the power and performance you need to win the race under extreme conditions safely and securely. So go ahead, turn your SAP Application loose to drive like Mario and Michael.

HDS - SAP TechEd Visual 302 x 257.jpg

  Check us out at SAP TechEd Barcelona at Booth # ___P.27_______

Come and take a test drive in our Excavator and have a chance to win a range of prizes.

 

Don’t just buy a SAP HANA engine when you can buy a high performance SAP vehicle that your SAP Applications have been begging you to drive!

 

For more info, on our participation at the event go to https://community.hitachivantara.com/docs/DOC-1007870

To ensure optimal performance, SAP HANA database holds the bulk of its data in memory. However, it still uses persistent storage to provide a fallback in case of failure.

During normal database operation, data is automatically saved from memory to disk every 5 minutes. Additionally, all data changes are recorded in the redo log. The redo log is saved from memory to disk with each committed database transaction. If there is a power failure, memory chip or CPU issue, the database can be restarted like any disk-based database, and it returns to its last consistent state by replaying the redo log since the last savepoint.

While savepoints and log writing protect your data against power failures, savepoints do not help if the persistent storage itself is damaged. Backups are required to protect against the data loss due to disk failures. Backups save the payload (the actual data) of the data area and log area to different locations.
Backups are performed while the database is running. The impact of backups on system performance is negligible, and users can continue to work normally while the backup is running. Backups complement other availability strategies such as system replication and storage replication. Backups are also used for other scenarios such as database copies.

 

A full data backup contains all current data, while a snapshot saves the content of the whole data area. Snapshots are an alternative to full data backups. Delta backups contain data that was changed since an earlier data backup. Differential & incremental delta backups are possible. 

 

Native backup/recovery functions and an interface for connecting 3rd party backup tools and support for storage snapshots, such as Hitachi Data Instance Director, are available within SAP HANA,. For recovery, SAP HANA offers many different options, including point-in-time recovery.

 

There are different options for carrying out backups for SAP HANA

1.       Backup to the file system

2.      Backups via the “Backup Interface for SAP HANA” API to 3rd party tools. 3rd party backup agent runs on SAP HANA server. Backups are transferred via pipes.

3.       Certified backup tools (connected via Backint API).

4.      Data snapshots using storage tools

 

Hitachi Protection Platform S2750  provides the features to support backup and recovery using Backint for SAP HANA with Veritas NetBackup. It is a backup appliance designed to deliver powerful, scalable and cost-efficient data protection storage for large SAP HANA databases.

 

Veritas NetBackup media server and master server performs backup of the SAP HANA database to Hitachi Protection Platform S2750. Install NetBackup Client software on all the SAP HANA nodes in the HANA cluster.  After configuring the NetBackup master and media server with recommended settings for use with SAP HANA, configure the NetBackup client (HANA nodes) to integrate with the NetBackup server using Backint for SAP HANA.

 

HPP.png

 

When initiating a backup or recovery process, NetBackup for the SAP HANA Agent runs on the SAP HANA nodes. It communicates with the NetBackup servers through the Backint interface to perform backup or recovery tasks.

 

You can mix different backup options for taking data and log backups.

 

Data backups can be triggered using (applicable to Backint as well):

1.       SAP HANA Cockpit

2.       SAP HANA Studio

3.       SQL commands

4.       DBA Cockpit (scheduling)

 

Log backups are written automatically and also to Backint, if configured. For improved performance, Backint can now use multiple parallel streams for data backups.

 

Backint has the following advantages:

1.       Consistency checks on block level

2.       Additional features, e.g. encryption or de-duplication

3.       Data center integration

4.       Backups immediately available for recovery

 

When Backint initiates a backup or recovery task from SAP HANA Studio or an SQL statement, SAP HANA creates a data stream pipe. The SAP HANA agent that runs on the SAP HANA node communicates with the Veritas NetBackup servers through the Backint interface using these data stream pipes to perform backup or recovery processes.

NetBackup for SAP HANA Agent reads the data stream from these pipes and passes them to the NetBackup server, which then is saved to Hitachi Protection Platform virtual tape libraries.

 

HPP1.png

 

 

Recovery is performed with the following  phases:

1.       Data recovery (full backup + delta backups + incremental backups, if applicable)

2.       Log replay (log backups + log entries from the log area, if applicable)

3.       Restart of database

 

When initiating a recovery task from SAP HANA Studio or an SQL statement, SAP HANA establishes communication with NetBackup for SAP HANA Agent using data stream pipes. SAP HANA requests the backup data from the Veritas NetBackup server, which reads the data from Hitachi Protection Platform virtual tape libraries. NetBackup for SAP HANA Agent then streams the backup data received from the NetBackup server through the data stream pipes to the SAP HANA services to perform the recovery.

 

HPP2.png

 

Refer the Reference Architecture Guide for details  on Backup and Recovery using Backint for SAP HANA with Veritas NetBackup on Hitachi Protection Platform, the UCP for SAP HANA Veritas NBU Appliance Integration Guide and the following SAP Notes for more details .

 

1730932 - Using backup tools with Backint for HANA

 

SAP Note

Title

1642148

FAQ: SAP HANA database backup and recovery

2031547

Backint Tools und Support

2039883

FAQ: SAP HANA database and storage snapshots

2165547

FAQ: SAP HANA Database Backup & Recovery in a SAP HANA System Replication landscape

2021789

SAP HANA revision and maintenance strategy

blog image benchmark.pngOn July 4, 2016, SAP, on behalf of the SAP Benchmark Council, certified (Certification number: 2016035) the latest SAP BW Advance Mixed Load Benchmark (BW-AML Benchmark) where Hitachi now ranks first for the  2 billion initial record load, see Benchmark Results.

 

For those of us at Hitachi, these results are no surprise. Hitachi’s converged platform, Hitachi Unified Compute Platform (UCP),, has been providing SAP HANA customers with a platform designed to meet the performance demands of the most data intensive environments. Our customers are witness to our commitment to delivering the highest performance systems, accompanied with highest reliability and availability available in the market.

 

Now you may ask, who would need to run 2 billion records and does this have a real world use case in an SAP BW environment? With massive explosion of data, and customers running databases in petabyte ranges, the answer is yes. A BW environment is very query intensive. There are nightly extracts from ERP that are loaded into the system as well as other source systems. When talking about huge databases the amount of data that is stored in BW can quickly skyrocket.

 

Take the retail sector for example an environment where we’ve seen big interest in our SAP HANA solutions for customers like Target CorporationSPAR and Dennis Department Store.   This $22 trillion industry with some retailers having hundreds of millions of customers on a weekly basis. It isn’t hard to imagine these retailers requiring the processing of billions of records at speeds that allow them to make business-relevant decisions in an environment where they face fierce competition every day.  More and more retailers are using real time analytics to make smart business decisions so they can stay ahead of their competition. Everything from customer’s buying patterns, previous purchases, and inventory management are data that they need access to in real time. Real time access to data allows retailers to maximize every customer interaction.  With the power of the SAP HANA platform, customers can access data that they could not previously access economically and in real time and Hitachi’s UCP is just the high performance converged platform they need for this environment. Hitachi's end-to-end SAP HANA offerings provides customers with a full range of platform solutions including managed services from oXya and consulting services from HCC.

 

Performance and speed of business are critical for any customer that is going through digital transformation – where most initiatives drive increasing waves of new data to manage – and adopting the SAP HANA platform as one of the means to thrive.  When they need to run their business in real time, customers need the peace of mind to know that the underlying platform will perform to the highest degree to meet the most demanding workloads. With Hitachi’s UCP for SAP HANA converged platform, we’re confident that this can be achieved quickly and simply while providing the customer with the highest ROI in the industry.  In SAP’s words, Run Live, Run Simple. And with Hitachi’s UCP for the SAP HANA Platform, customers can make it a reality with an end-to-end solution that has proven its world-record performance.

 

SAP-AML Benchmark Result Details

The SAP BW Advanced Mixed Load (BW-AML) Standard Application Benchmark performed on June 24, 2016, by Hitachi in Kanagawa, Japan, with a total of 2,000,000,000 records, was certified by SAP on behalf of the SAP Benchmark Council on July 4, 2016 with the following data:

 

Benchmark Phase 1

 

Number of initial records

2,000,000,000

 

 

Configuration:

 

Operating System, DB Server                   

SuSE Linux Enterprise Server 12

Operating System, Application Servers    

SuSE Linux Enterprise Server 11

Database

SAP HANA 1.0

Technology Platform Release

SAP NetWeaver 7.50

 

 

Database server

Hitachi Compute Blade 520XB3, processors / 96 cores/192 threads, Intel Xeon Processor E7-8890 v4, 2.20 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 60 MB L3 cache per processor, 1024 GB main memory

 

This latest world record from Hitachi is achieved using an everyday 4 socket server that can be found in most customer data centers today.  It will deliver customers the performance they need for their environment without the added complexity or cost.

 

SAP and Hitachi are strong strategic partners and over the last few years Hitachi has made some significant investments to create an entire eco-system around SAP and this benchmark result shows the results of this partnership. This collaboration has only gotten stronger since the release of SAP HANA and we have been there with SAP since the beginning of this journey.  And now both companies are helping customers make their digital transformation journey a reality.

 

Stay informed by connecting with Hitachi on our SAP Community.

SAP HANA Cockpit is a web-based user interface for deploying, running, and managing your web applications and connecting them with services on the cloud.  It is a Web-based user interface, which is used to manage SAP HANA Cloud Platform accounts and applications and to access key information about your application on SAP HANA Cloud Platform.

 

Our customers are using Hitachi UCP for SAP HANA converged and Hitachi Unified/Enterprise range of storage platforms to run their physical/virtualized SAP HANA databases.

 

In addition, Hitachi Data Systems has a growing portfolio of SAP HANA management tool integrations (aka adapters) to extend access to the data/ functionality of our storage and converged solutions for SAP HANA database administrators, and to make the job of administration simpler and more effective.

 

Unified Compute Platform for SAP HANA converged-infrastructure solutions help you accelerate adoption and achieve faster time to value of the SAP HANA platform.  The solution provides a foundation for high-speed analytics with SAP NetWeaver Business Warehouse (BW), as well as a high-performance transaction-processing platform with SAP Business Suite layered on the SAP HANA platform.

 

In addition to offering the infrastructure, Hitachi offers an end-to-end SAP HANA solution.  We can bundle a complete enterprise data warehouse solution for SAP Business Warehouse on SAP HANA.  This tighter integration will allow customers to purchase the Unified Compute Platform, the SAP HANA software including the appropriate licenses, and managed services from Hitachi Data Systems.

 

The SAP HANA Cockpit Adapter will complement the UCP for SAP HANA solution by providing the capability to monitor the hardware components and provide local replication, snapshot, copy and cloning features for the SAP HANA system.

 

The Hitachi Adapter is accessed from SAP HANA Cockpit after you install Hitachi HANA Management Service on the Windows management server, and import the delivery unit to the SAP HANA Cockpit.

 

The screen below appears so that you access the tile for the adapter.

 

BD_1.png

 

The following screen shot shows the SAP HANA Server Adapter – Overview of HANA host:

BD_2.png

 

I’ve included more details on the SAP for HANA Cockpit adapter as follows:


The Hitachi SAP HANA Server Adapter for SAP HANA Cockpit

The Hitachi Adapter for the SAP HANA Cockpit is installed on the HANA server and is accessed through the SAP HANA cockpit.  The Hitachi Server Adapter will provide server discovery, and additional monitoring functionality.  Specifically, the adapter:

  • Allows users to discover Hitachi Compute Blade server components (such as chassis, blade, and others).
  • Allows users to monitor the health information of Hitachi Blades.

 

The Hitachi Adapter for SAP HANA runs as a cockpit web application.  When the adapter’s services are needed, the adapter calls the web service.  Then the web service communicates to HCSM (Hitachi Compute System Manager) a systems management software application, and returns server related information to the adapter.


The Hitachi Adapter for SAP HANA Cockpit will support the following features:

  • Discover Hitachi Compute Blade 500, and 2500
  • Display blade servers component information in SAP HANA Cockpit
  • HANA workload mapping
  • Health information for server
  • Capture events from Hitachi blades and display alerts in HANA Cockpit.
  • Display Hitachi blade chassis and blade firmware version for CB500, 2500 servers in HANA Cockpit.

 

The Hitachi SAP HANA Storage Adapter for SAP HANA Cockpit

The Hitachi Adapter for SAP HANA Cockpit will enable the systems administrators/DBAs to take a clone/snapshot of HANA Database HDS storage directly from the SAP HANA Cockpit.  This provides a single user interface to monitor SAP HANA, Hitachi Server Components, Hitachi Storage and Manage Storage Snapshots.


The SAP HANA Cockpit is a web-based tool for administration and monitoring of a single SAP HANA database.

 

The Hitachi Adapter for the SAP HANA Cockpit is installed on the HANA server and accessed through the SAP HANA cockpit. The Hitachi Adapter provides storage configuration, discovery, and additional management functionality for storage local replication and snapshots.

 

The Hitachi Adapter for SAP HANA Cockpit will support the following features:

  • Storage Snapshot (ShadowImage and HTI)
  • SAP HANA supports the creation of storage snapshot, which can later be used for SAP HANA recovery.
  • Cloning: Using Hitachi SAP HANA Cockpit adapter, user can clone SAP HANA Database using Shadow Image replication.
  • Reports: Hitachi HANA Cockpit adapter will show the mapping between HANA database, Hitachi Server and Hitachi Storage.
  • Performance: Hitachi HANA Cockpit adapter will show historical storage and server performance metrics.


This screenshot shows the UI to create the storage snapshots using the Hitachi SAP HANA Cockpit Storage Adapter

BD_3.png

 

The Hitachi Adapter will also show the mapping between HANA database, Hitachi Server and Hitachi Storage and the Hitachi HANA Cockpit adapter will show historical storage and server performance metrics as follows:


The Hitachi Adapter for SAP HANA Cockpit is designed for reports about different storage system components, mapping, configurations, usage, and performance summaries.


The adapter will generate a comprehensive number of reports allowing a deeper understanding of your data and storage:

  • Adapter will show Storage Statistics Report
  • Storage Device to OS Device Mapping Report
  • Storage to HANA Database Mapping Report
  • Replication Information Report
  • LUN Performance Statistics Report
  • Port Performance Statistics Report
  • HANA DB snapshot support using HTI
  • HANA DB cloning support using ShadowImage
  • Support HANA Scale-up configurations

 

The following screen shot shows the SAP HANA Cockpit Server Adapter with storage device mapping to the host:

BD_4.png

 

The Hitachi Adapter supports two Operating Systems: SuSE Linux and RHEL. It also supports the Windows server and Hitachi local replication software including HTI and Shadow Image. The adapter will support all the Hitachi RAID family series including the new series which includes VSP Fx00 and Unified.

 

The following table summarizes the support matrix for the Hitachi Adapters for SAP HANA Cockpit:

 

Management Server OS


OS VersionSupported
Windows 2012 R2X

 

 

HANA Database OS


OS VersionSupported
RHEL 6.6-HANA SPS10 Scale Up Single ContainerX
SuSE Linux 11.3-HANA SPS10 Scale Up Single ContainerX
SuSE Linux 11.3-HANA SPS 11 Scales Up Single ContainerX
SuSE Linux 12.0 HANA SPS 11 Scale Up Single ContainerX

 

 

Storage Models


ModelSupported
HUS-VMX
VSP G1000X
VSP Gx00 (G200, G400, G600, G800)X
VSP Gx00 UnifiedX
VSP Fx00

 

 

Replication Software


SoftwareSupported
Hitachi Shadow ImageX
Hitachi Thin ImageX


 

Host Interface


InterfaceSupported
FCX


 

Volume Type


InterfaceSupported
HDP/HDT/HRTX
Parity GroupX


HANA Multitenant Database Containers, or HANA MDC, is something fairly new in the SAP world. It first became supported in SPS 09 (Revision 90), less than two years ago, in late 2014. Since it’s a new technology, there are relatively few customers using it. At oXya, we do have customers to which we helped implement MDC. In this blog I will describe the technology, what challenges it solves, what issues it actually creates, and which type of organizations can benefit from it.

 

 

Background: HANA before MDC

sap-hana.png

 

SAP HANA is an innovative in-memory database system. We’re taking large database systems, and we’re putting them all in-memory, which is pretty expensive from the hardware perspective – they need expensive hardware, with strong compute power and lots of memory.

 

Before HANA MDC, you had to have a separate SAP HANA instance – possibly on the same hardware, but still a separate SAP HANA instance – for each different database (meaning for each landscape). The meaning was that every time you wanted to install a new HANA system, you either had to buy a new physical appliance; or you had to install a new HANA instance for each different database, on the existing hardware.

 

The challenge is that HANA appliances are installed by the vendor, and delivered to the customer as an already-configured system. The vendor also certifies that the appliance was correctly configured. Now, if you want to install another HANA instance on that appliance, you either have to engage the appliance vendor again, for them to install another HANA instance in a certified manner; or the customer has to go through the painstaking steps of making sure that the new HANA instance is installed correctly.

 

In order to perform the installation, you needed a HANA expert to install the new instance, and that’s often done by the vendor that sells you the appliance. In other words, each new installation of HANA was complex, took a lot of time, and often may have also resulted in the need to purchase a new appliance.

 

All of the above is a rather inefficient way to install new HANA instances, and it obviously generated a lot of extra work.

 

Another challenge, as you probably guessed, was that the above method was very wasteful, with regards to hardware usage. Not only did SAP face the challenge of making the HANA install process quicker and easier, but also the challenge of reducing hardware costs, that was slowing down HANA sales. The hardware needed for this in-memory computing system is very expensive; SAP’s goal was to reduce hardware costs and footprint of the HANA landscape.

 

Let’s use an example, to explain all of the above. Imagine a customer (and we have an actual customer like that), who has SAP ERP and SAP BW (Business Suite applications), and they’re both running on HANA. Each of these applications has Sandbox, Development, Quality Assurance, and Production systems, all running on HANA. Before MDC, if the customer wanted to run their ERP on HANA, they needed to buy multiple appliances, one for each system:

  1. An appliance for Sandbox
  2. Separate appliance for Development
  3. Third appliance for Quality Assurance
  4. Fourth and separate appliance for Production.

 

So far we’re talking about four HANA appliances, and that’s only for their ERP application. If the customer wanted to duplicate their data and also run their BW on HANA, then they would need to buy additional appliances for the BW systems (Sandbox, Development, Quality Assurance, Production).

 

And of course, it’s not just about the hardware costs, but also a matter of license costs. Do additional instances also mean you needed additional licenses, therefore additional license costs?

 

Well, the answer in general is “Yes”, or sort of. As a general rule, HANA is licensed by the amount of memory that the application needs. There is a difference between using separate appliances, and using one larger appliance with MDC; that can affect not only hardware costs, but also (to a lesser degree) the licensing costs. I’ll explain that later on, when referring to MDC sizing.

 

 

So what is SAP HANA MDC?

container-489933 (Custom).jpg

 

SAP released a newer feature, Multitenant Database Containers (MDC), which is supported as of HANA SP9 revision 95 and higher. In a nutshell, MDC allows us to take multiple SAP systems, say 2 sandboxes, 1 ERP, 1 BW, 2 development systems and 2 quality assurance systems, and put them all on the same HANA appliance.

 

The beauty of it: once the hardware provider had provided the appliance and did the initial set-up for the HANA system, we can very quickly and easily create the new database containers for each of our different systems, and allows these different products to cohabitate in the same appliance.

 

The MDC feature provides huge economy savings in terms of hardware, because instead of buying a separate appliance for each system (or perhaps not an appliance for each system, but an appliance for each landscape – possibly have your ERP’s Dev and QA on one appliance, and the same for BW), you can now take all of these, put them all on a single appliance, and better utilize that hardware.

 

Of course, as a general rule, we're not going to mix production and non-production systems. So, we still need to separate the Production system. However, for all of our non-production systems, MDC introduced significant flexibility.

 

 

MDC Challenges

 

MDC does come with some challenges, and we hope that SAP will eliminate these challenges in the future. These are current challenges, so you are aware:

 

First, when you perform replication at present, you take your HANA system and you replicate the databases to another site. There is no ability to replicate just a single database tenant – you have to replicate everything. The replication treats all database tenants as a single database system, as opposed to completely independent database systems. Hence, in the case of a failover to a secondary site, you'd have to perform the failover for all HANA database tenants on that appliance, and not for just one database.

 

Second, there’s a challenge in terms of version maintenance. In a traditional SAP landscape, we apply patches gradually:

  • We apply the patches to our Sandbox, and test
  • Then, we apply the patches to the Development, and we test
  • Then, we apply the patches to the QA system, and test again
  • And only then, after multiple patching is done on non-production systems, plus testing, we patch the Production system.

 

The benefit of the above method is we can test patching in many different systems, before going to Production. The challenge with MDC is that when you apply patches to this multitenant environment – you’re applying patches to all the systems simultaneously, because it’s impossible to perform individual patching for each database tenant. Essentially, once you patch your HANA appliance through the MDC, you have patched all the environments that are on the appliance – all at the same time!

 

“But wait”, you may say, “is this really a challenge? Is patching everything a challenge? Don't you want to patch everything? Doesn’t it save you work and time?”

 

The answer is – take another look at the patching process I outlined above. Our goal is to prevent impact to the Production system. In an SAP environment, we perform multiple tests on patches in non-production systems, before implementing in Production. The way to ensure that patching is successful, and doesn't cause any negative impact, is by performing multiple iterations: first Sandbox, then Development, then QA. By the time you get to Production, you've already performed patching 3 times.

 

However, in the case of MDC, once you performed patching on your non-production MDC system, you’ve done that simultaneously to all the systems within the same appliance. You’re not getting those multiple iterations, which is a huge disadvantage.

 

cargo-449784 (Custom).jpgAlso, there’s another caveat to patching. Let’s say you have ERP and BW on the same appliance, and patching is only required for one product, but not for the other. In the case of MDC, we don’t have a choice – we have to patch them both, at the same time.

 

This patching challenge is not an insurmountable issue, but it is something to get used to. This is also another reason why the Production system must be separate from non-production – you certainly don’t want to do patching on Production without testing it first!

 

But all in all, and despite of the above challenges – MDC is a great technology. We're able to spin up new containers in minutes, with a simple command on the HANA system. This, as opposed to having to engage a HANA expert to install the new instance, or perhaps even purchase new hardware every time you need a new a system. MDC adds significant flexibility, and I believe SAP is working to enable the replication of individual containers, and it will be available in the near future.

 

 

Difference between HANA system and the Containers

 

One important thing to understand is the difference between the HANA system and the containers, as each container has its own SID (system ID), in addition to the SID for the HANA appliance itself. For a customer that is going to use MDC, it’s important to realize that they have to name their HANA appliance uniquely for the entire appliance, and then name each container based on its purpose. In other words, you have an SID for the HANA instance on the appliance, and then you have a separate SID for each container.

 

Let’s explain that using an example. Let’s say that the SID of the HANA appliance would be HA1. Then, we’ll give various names to the containers, usually according to some kind of a key. For example, we will use "Q" for quality assurance, “D” for Development, “E” or “B” for ERP and BW, and an "H" to indicate that it's a HANA system.

 

With the above method, your development ERP container could be “DEH”, and your development BW container could be “DBH”. The QA containers will be “QEH” and “QBH”.

 

 

MDC Sizing

tape-measure-1186496 (Custom).jpg

 

Earlier, I mentioned sizing and said that customers may also save some money on license purchases. In order to explain that, let’s start with the traditional sizing for HANA, meaning separate appliances for each system.

 

HANA is a database, and each database system (Development, QA, Production, etc.) needs its own memory to contain its database. There are no savings in terms of reducing the volume of each database, because they stay the same, whether in separate HANA appliances or when using MDC, on one larger appliance.

 

However, when performing sizing, one doesn’t size just perfectly – you always leave room for growth, meaning a buffer. When you size for separate HANA systems (say one Dev and one QA), you will oversize for both systems, to make sure that you have sufficient space. However, when you do that, you often significantly oversize, and you actually “waste” hardware. In fact, I Can guarantee that if you look around the world, at various HANA systems, there's lots of memory and CPU that are not being used. Customers are paying for this over capacity, not only in hardware costs, but also in HANA licensing costs.

 

Consolidating systems omits the above, and provides great savings. When consolidating HANA databases, we don’t need to oversize for each database separately. We can better utilize the resources on the server, and oversize to a smaller extent, for all databases combined.

 

Basically, what you're saying is that if before we needed 2 appliances, let's say each 1 with half a terabyte of memory, then when we combine them all on the same appliance, we need actually 1 appliance with 1 terabyte, that's 2 halves and you may be able to save a little out of the 1 terabyte, put a little less because you don’t buffer twice or you don't oversize twice.

 

Take one of oXya’s customers, for example. This customer has 5 different HANA systems, with each database in need of 200GB (already includes space for future growth), meaning we need a total of 1TB. If you went ahead and bought separate appliances for each database, as was the case before MDC, then you would buy five appliances with 256GB each (5 x 256GB). This means you’re wasting more than 250GB, above and beyond your needs. These systems will be gravely underutilized.

 

However, when you consolidate those systems, then you only need to buy a 1TB appliance (which again, already includes space for future growth). Then, as some databases grow, those databases that need the additional resources are able to utilize them. Furthermore, not only do you better utilize the hardware and licenses, but you may even be able to add additional systems onto the same hardware, once it's running.

 

Having said all of the above, it’s important to understand that Sizing is a bit of an art (and not really a Science, as some people claim). When you perform sizing, you make assumptions regarding what is going to be once it’s running, and it doesn’t always happen this way. That’s one reason why there’s a tendency to oversize. When we're sharing several databases onto a single system using MDC, we're able to better utilize resources.

 

Come see us at SAP SAPPHIRE this week – stop by the Hitachi booth, look for the oXya team, and discuss your SAP challenges with us.

 

----------------------------------------------------------------------

 

oXya_HGC_logo (Custom 300).jpgSevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of ten SAP professionals, at oXya’s service center in New Jersey.

 

oXya, a Hitachi Group company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs more than 650 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.

Two interesting things happened in the last couple of weeks, that led to writing this blog:

  1. We received a new white paper from research firm ESG, analyzing the impact of SAP S/4HANA on the SAP market and on our own business – Technical SAP Consulting & Managed Cloud Services.
  2. I attended an interesting meeting with individuals from several other Hitachi Group companies, to discuss various things regarding the SAP market and our activities in the coming year.

 

One of the things I realized in that meeting, and this sometimes also happens in conversations with various people working in the SAP ecosystem, is that there’s a lack in understanding some of SAP’s newest technologies in the market. Specifically, I’m referring to the difference between HANA and S/4HANA; what each of these does; and what is the revolution taking place these days in the SAP market, due to these technologies.

 

By “lack of understanding” I don’t refer to fellow technical SAP experts, they certainly understand the above, and possibly also know the “behind the scenes” of the war that is taking place in the last few years. But do your business people, marketing experts, sales folks – all those non-technical experts in the SAP ecosystem – do they know what the difference is, and what’s going on? Or do they think, as I sometimes hear, that S/4HANA is in fact “HANA version 2.0”, or some other variant ?

 

So, today’s blog is dedicated mostly for the non-techi folks in the SAP ecosystem, but all you techi friends are also welcome to read. This will be a story full of emotion about the longtime rivalry between two of the world’s leading tech giants, and a real battle that’s taking place today around SAP customers.

 

For those who want the short version, here it is – SAP HANA is a database. SAP S/4HANA is the new business suite of SAP applications, that runs on the HANA database. That’s it, but there’s so much beyond that. So go ahead and read the full story.

 

And a word of caution – to best serve the non-technical audience for which this blog is written, it is going to be simplistic and high-level, with as little technology deep-dive as possible.

 

 

What is SAP – in 2 minutes

SAP-logo-2011.png

When an organization has a mission-critical SAP system, it actually means they have a system that consists of various layers of software and hardware. Let’s leave the hardware aside for the moment, since it’s less relevant at this point. On the software side, an SAP system has three main layers:

  1. Operating System (OS)
  2. Database (DBMS)
  3. Applications

 

Traditionally, SAP was an applications vendor. Everyone in the industry knows these applications very well – ERP, Supply-Chain Management, Finance, HR, Logistics, Manufacturing, Retail, and many other applications that SAP has been producing over the years, for running an enterprise at all levels.

 

Also traditionally, SAP applications ran on top of third party databases (this is where the actual data is stored), as SAP did not have a database of its own. The main databases on which SAP applications run are Oracle, MS-SQL and IBM DB2, though there are additional databases that SAP runs on, such as Sybase (which SAP acquired back in 2010, for $5.8 billion; here’s an interesting article from that year, on why SAP acquired Sybase).

 

Oracle Corp plays an interesting role here. On the one hand, Oracle is a bitter competitor of SAP, because it’s application suite – Oracle Applications – is a direct competitor of the SAP application suite. On the other hand, Oracle is one of the leading databases in the world, with many SAP customers running their SAP applications on the Oracle database. In other words, the SAP market is a major revenue generator for Oracle Corp on the database side; Oracle database license revenues from SAP customers make a major percentage of Oracle Corp’s total revenues.

 

All of that synergy lived relatively well until 2012 – SAP focused mostly on the applications side and led the market in that category, with Oracle being a distant #2 (here are two Forbes’ articles covering Gartner’s analysis of the ERP market and the Supply-Chain Management market). On the database side, Oracle has been the market leader as far as license revenues; Oracle generated (and still generates) a significant portion of its revenues from SAP customers running on Oracle.

 

And then came SAP HANA.

 

 

SAP Introduces HANA – The In-Memory Database

 

6224518717_976c2ba19a_z (Custom).jpg

SAP officially launched SAP HANA in November 2010. HANA is an in-memory database, which is a revolutionary technology, compared to “standard” databases. In regular databases, all the information is stored on disks that “live” in enterprise storage systems. When a database gets an inquiry, it goes to the disks, searches for the information, retrieves it to the system’s memory, and then performs various operations on (or using) this data. Once it has finished with the specific piece of data, it stores it back onto the disk, until the next time it needs this data.

 

An in-memory database operates differently. The infrastructure for this database consists of an enormous amount of memory and compute power (compared to “standard” storage), the data resides at the memory level at all time, and all actions are performed within the memory itself. Since memory is significantly faster than disk (memory access time is measured in nanoseconds, while disk access time is measured in milliseconds), HANA performance is also significantly faster when compared to that of standard databases. In addition, HANA brings other meaningful advantages – I covered HANA benefits in a blog that focused on Considerations Before Migrating to SAP HANA.

 

The launch of the SAP HANA database was like waving a red flag at a bull; the bull’s name was Oracle. Here, SAP no longer competed only on the application layer of the business; Oracle suddenly saw a direct, potential threat at its bread-and-butter – the database business and the revenues it generates. And it reacted (photo credit: Naoki Nakashima, Flickr).

 

Larry Ellison, Oracle’s Founder, Chairman and CTO (and one of the 10 richest people in the world), launched a series of fierce attacks on SAP and HANA. In a series of keynote speeches and interviews, that started almost immediately after the HANA launch in 2010 and is still ongoing, Ellison has been doing his best to bash HANA and install doubt and fear in the minds of SAP customers. Some of his speeches and recordings have become iconic in the industry, such as this 2-minute video from 2012, or his keynote speech at the 2014 Oracle OpenWorld, to name just two cases.

Larry (Custom).png

Bill_McDermott (Custom).png

 

The bottom line of Larry’s comments – HANA is a brand new system, not yet tested, and not proven for mission-critical workloads. SAP will never substitute their long-time, proven Oracle database, for the HANA database.

 

SAP’s reaction to these attacks was polite and respectful. Here’s an example from a Yahoo Finance 2-minute video interview with Bill McDermott, SAP’s CEO, following one of Larry’s bash attacks.

 

What actually happened in the field? Like with any new and innovative technology – not to mention mission-critical in its influence – adoption has been slow. It takes an Innovator, visionary CIO to be one of the first in the market to adopt a brand new technology for one of the organizations’ most mission-critical systems (SAP). (graphics credit: The University of Arizona).

 

orr7.gif

Overall, HANA adoption lagged behind SAP’s own estimates. Customers did take their time to migrate to HANA. In its FY2015 reports, SAP wrote (page 7 of the PDF) that “In just a few short years, nearly 10,000 customers and startup companies chose to innovate on SAP HANA…”, which means an adoption rate of less than 5% from SAP’s customer base. However, the quarterly reports that SAP publishes also show an acceleration in adoption, as was expected.

 

At oXya, we had the privilege to work with a few such innovative customers, and support them in their migration to SAP HANA. As of May 2016, more than 50 out of our 335 enterprise managed services customers (roughly 15% of oXya customers) are already running on SAP HANA or are in the process of migrating to HANA. We are very proud of this significantly-above-industry-average percentage, and that we are an industry leader in migrating SAP customers to SAP HANA and S/4HANA (and I’ll write on S/4HANA in the following section).

 

Since SAP saw that adoption of the HANA database has been slow, what did it do to accelerate this adoption, and to further innovate in the market? It introduced SAP S/4HANA.

 

 

SAP Introduces S/4HANA – The New Suite of Business Applications

 

In February 2015 SAP introduced SAP S/4HANA, which is “a next-generation business suite designed to provide the digital core SAP customers need to run their entire business in a digitized world.” (quote from SAP’s FY2015 annual report).

 

SAP S/4HANA is not a database. Rather, it is a new and revolutionary application suite from SAP. Research firm ESG writes that “This (SAP S/4HANA) is perhaps the single biggest shift in SAP technology for the last 25 years, since SAP R/3 was introduced in 1992”. Many SAP experts agree with this statement. SAP S/4HANA includes many innovative technologies and features, that all have one common goal – to enable organizations to run their SAP in a simpler, faster, and far more efficient way, while supporting new work processes (such as mobile). With all that, SAP S/4HANA helps customers to be more competitive in the market place, and better align with modern challenges of the digital world. We wrote in the past about some of the new features in S/4HANA, such as Fiori, the new SAP GUI (see the table and video in this blog post, for a comparison of time and efficiency between the old SAP system and the new one).

 

And the kicker about S/4HANA – as its name implies, this new suite of applications only runs on the HANA database!

 

In other words, customers who will want to upgrade to the newest and best SAP suite of applications, will have to also adopt the HANA database and run on it. They will not be able to choose any other database – it only runs on HANA.

 

 

So what does it all mean?

 

There are a few interesting questions to ask, in the aspect of S/4HANA:

  1. What will the adoption of S/4HANA look like?
  2. Which SAP customers will migrate to S/4HANA?
  3. How will this migration cycle affect the IT industry?

 

Let’s answer these, one by one.

 

How will the adoption of S/4HANA look?

Like with any new technology, it will be in stages, exactly like in the adoption cycle graph shown earlier. First come the Innovators, and we already see enterprises who have migrated to S/4HANA, or new SAP customers who performed greenfield installations of SAP S/4HANA. oXya has a few such customers, including in North America – we hope to share their stories in the future. After the Innovators will come the Early Adopters, and then the Majority – Early and Late.

 

ESG estimates, in its paper, that “This (SAP S/4HANA) will become the mandatory standard for SAP customers in the near future, assuming they wish to stay current on SAP product enhancements. At some point, support of older versions will start to become increasingly difficult.”

 

My own estimate is that the “near future” that ESG is referring to will take some time. We are still at the Innovators stage. It will probably take a few good years to cover the percentages “needed” until the market reaches the stage of Majority adoption, but it will come. The reason for that is explained in the next paragraph.

 

Which SAP customers will migrate to S/4HANA?

In my estimate – everyone, eventually, or at least the majority of customers. After all, it is exactly like ESG says – any customer that wishes to stay current with SAP technology, and maintain a competitive place in the market. SAP customers cannot afford to stay behind with old, dated systems, that are less efficient.

 

Customers will want to keep current with their competition, and will eventually be “forced” to move to S/4HANA (which, of course, will continue to evolve and improve). I suspect it’s still 4-5 years away (and possibly a bit more) before we see the large mass of SAP customers migrating to S/4HANA (and to HANA, as a result), but I have no doubt that it’s coming.

 

How will this migration cycle affect the IT industry?

In a huge way. The move from “regular/current” SAP systems to HANA and to S/4HANA affects many facets of the IT industry:

  • Infrastructure for SAP: First, HANA requires different infrastructure than current SAP systems. There are already various infrastructure vendors who are playing in this field, with more who will probably enter the market. Hitachi Data Systems, with which we closely cooperate, is a leading player in the SAP HANA market, with its Hitachi Unified Compute Platform (UCP). And second, as customers choose new infrastructure, they will often want to avoid the high Capex costs that are associated with the HANA hardware; instead, many customers will prefer to move to a cloud system with an opex-based consumption of hardware, such as the one oXya offers.
  • Functional/Design for SAP: The system integrators’ (SI) community will also have its hand full with the transition to S/4HANA; while SAP recommends using the standard applications and creating minimal adjustments, many organizations will probably want to adjust the new applications to their specific needs. Hitachi Consulting (HCC), our sister company, is a leader in this area, and we’re closely cooperating with them.
  • Technical Services for SAP: Companies such as oXya will certainly have their hands full. Most SAP customers do not have the necessary in-house knowledge and expertise in order to migrate to HANA and S/4HANA; They will require external help, from the likes of oXya, who have already done that numerous times, and can help assure a fast and painless transition.
  • Managed Services for SAP: This is another market in which oXya is a major player. As SAP customers adopt these new technologies, they will require skilled personnel to run the new SAP systems around the clock, to make sure the new SAP provides peak performance and generates a great ROI for the organization. This may mean choosing an SAP partner that you can count on, a partner that provides you with a dedicated team that is an extension of your own IT organization, and various other unique features. As you can read in the new white paper from ESG, there is a shortage of skilled technical IT people in the market, across multiple areas. Many of these areas are covered by oXya’s dedicated support teams, once a customer chooses our services for running their SAP – so working with oXya as a partner can immediately solve multiple recruiting challenges, of the following expertise areas:
    • SAP Basis (not in the ESG table, but huge shortage in the market)
    • Server virtualization/private cloud infrastructure
    • Compliance management, monitoring and reporting
    • IT architecture/planning
    • Data protection
    • Database administration
    • Storage administration
    • Server administration
    • Network administration

 

Of course, there’s another potential effect on specific industry players – the database vendors. The main one to get hurt is probably Oracle, which presumably has the largest share of database revenues from current SAP customers. I wouldn’t go out on a limb in estimating that we can expect the level of bashing and attacks from Oracle to increase in the coming years, or at least stay at current (pretty high) level. Oracle Corp have very smart people, and no doubt they analyze the marketplace in a similar way to what I did above – some of Oracle’s core customer base is about to disappear, and migrate off Oracle in the coming years.

 

I hope to see many of you at SAP SAPPHIRE – stop by the Hitachi booth, look for me and the rest of the oXya team, and feel free to discuss your SAP challenges with us. You can also email me at any time, to mduboullay@oxya.com.

 

oXya logo for LinkedIn 300x300.png

----------------------------------------------------------------------

Melchior du Boullay is Managing Director, Americas at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.

 

oXya, a Hitachi Group company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs more than 600 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.