How SAP Complexity Impacts Performance on IBM i
September 13, 2017 Alex Woodie
The IBM i server and SAP’s enterprise resource planning (ERP) software is a powerful combination that propels thousands of businesses around the world. The duo’s success is apparent to those who pay attention, even if it’s not widely acknowledged. But ensuring smooth SAP operations on IBM i is not always as straightforward as it could be, especially for those uninitiated with the complexity of this setup.
The fact that SAP has its own way of doing things is nothing new. Ever since a group of five former IBMers from Germany led by Hasso Plattner formed up to create the first release of SAP software decades ago, the company has been carving its own path through the enterprise software landscape. From TAM to FMC to ABAP and Netweaver, SAP has long been known for creating its own tools and technologies to support its customers’ environments.
Here’s another indisputable fact: SAP’s ERP software delivers a heck of a lot of functionality for businesses in all industries. That’s largely why SAP, along with close competitor Oracle, are considered the two leaders in the global ERP market.
But that high level of functionality also comes with a comparable level of complexity. Consider that its flagship ERP platform contains more than 30,000 relational database tables. That’s a huge number, to be sure, and largely stems from the fact that SAP stores its application code in the database itself, a relative oddity in the field. But it also allows SAP to support all sorts of different business processes across an array of RDBMs, including native support for Db2 for i.
SAP has cut into the complexity somewhat with S/4 HANA, a line of business software designed to simplify the database and application levels, and consolidate some of the sprawl by converging transactional and analytical workloads into a single in-memory, column-oriented database. When SAP launched HANA a few years back, and then added S/4 software in 2015, the company bragged how it could run its own business on HANA using a relatively small server.
However, while the application component of HANA runs on IBM Power processors, the database is not currently supported on Db2 for i, which leaves the traditional Netweaver environment and SAP ERP Central Component (ECC) the go-to products for IBM i shops investing in SAP software.
In a way, this simplifies the number of configuration options for IBM i customers. But that doesn’t mean the whole process of sizing Power Systems hardware and software for use with SAP ERP software is at all simple. In fact, to ensure that performance levels remain acceptable, there are quite a few things that should be considered.
Rising Complexity
Kolby Hoelzle, the SAP on IBM i practice leader in IBM Systems Lab Services, discussed some of the basic performance considerations that SAP on IBM i customers should be aware of during a recent webinar held by a prominent, Minnesota-based systems management software vendor for IBM i.
“For those of you who’ve been on SAP for a while, SAP has always been complex by its very nature,” Hoelzle said during the webinar. “But that complexity was limited to a single application – to R/3 in most cases. But as that landscape has changed a bit over the last…10 years, that complexity has increased by leaps and bounds, as SAP has introduced additional products in addition to its ERP product.”
The “i” stands for integrated, but that’s hardly the case anymore.
The core ERP component, which used to be called R/3 and is now called ECC, remains at the center of the SAP universe. But depending on the needs of the customer, ECC will be surrounded with all manners of modules for various functions: supply chain planning, customer relationship management, production planning, material management, human resources, accounting and controlling, and sales and distribution. (And don’t forget the technical modules available for security and everybody’s favorite programming language, ABAP).
In some cases, SAP customers will be running multiple databases to support these various applications. And although it’s all bundled under a “centralized” suite of software that ostensibly simplifies life for administrators, the reality is that all these pieces raise complexity – especially when integrating with non-SAP products.
“Even though one of the selling points of SAP is you can get rid of all your other applications and run your business on SAP, the reality is there’s still a lot of integration with other non-SAP applications that’s required,” Hoelzle said. “This leads to very complex landscapes that need to be managed and need to be analyzed and optimized.”
SAP has taken steps to rein in this complexity, particularly with a separate product called Solution Manager designed to help customers manage complex deployments. But its ability to manage and monitor complex infrastructures is limited, Hoelzle said. “They do a good job of providing certain metrics and certain aspects of monitoring the infrastructure,” he said. “But really the Solution Manager and the built-in management and monitoring function within SAP are really meant to manage SAP itself.”
The growth-of-complexity problem isn’t limited to SAP and integration with other software products, but also is impacting the server platform itself. This is one of the most important sources of complexity for IBM i shops, Hoelzle said.
“Early on, especially with IBM i, you had an IBM i or AS/400 and that was it. It ran on Power hardware. You had internal disk and everything was right there at your fingertips and you didn’t have to worry about all these other components,” he said. “You had your server, you plugged it into the network, and everything was managed right here.”
At some point along the way – Poof! – those simpler days disappeared. “We still have servers, but now we have virtualization. We have PowerVM. We have virtualized storage, which means we have to introduce something like VIOS…We have this complex infrastructure with lots of different components and different systems.”
Instead of managing everything through IBM i, customers who ostensibly “run” SAP on IBM i must also know some AIX, because VIOS is a Unix app. And if their SAP on IBM i runs its database on an external storage array, they will need to learn that operating system, too.
“There are a lot of advantages to the infrastructure that we have today, with a highly virtualized infrastructure providing a lot of great features and flexibility,” Hoelzle said. “But it comes at a price, and that price is typically more complexity. It’s less integrated than a single server. You might have to learn different interfaces and operating systems. And, of course, it makes it a little bit trickier to do end-to-end monitoring.”
Unique Attributes
Hoelzle elaborated on some of the other attributes that make running SAP on IBM i unique, as well as how that impacts day-to-day management of this powerful setup.
One of the most important attributes of SAP-on-IBM i performance is the wide use of subsystems by SAP when running on IBM i. Using IBM i subsystems “provides us with a level of isolation with our SAP environment that allows us to run in consolidated SAP environments, which is fairly unique in IBM i,” Hoelzle said.
Instead of running development and testing environments on separate boxes, as other platforms require SAP customers to do, IBM i customers can consolidate their development, test, and production workloads on the same Power Systems server. That eliminates server sprawl, which has long been the bane of X86 environments – and has long been the IBM i server’s secret weapon against them.
The fact that most SAP jobs run within IBM i subsystems is an advantage for monitoring, Hoelzle said. However, not all of jobs run that way, including remote database access jobs, so this is worth keeping in mind when constructing a monitoring plan.
SAP is very data-centric; it even stores compiled application code in relational database tables, Hoelzle said. For IBM i implementations, SAP wants to store almost everything in Db2 for i, but not everything. For instance, SAP uses a range of libraries to store journal receivers that track the database. Part of the “kernel library” is stored in a traditional IBM i library too.
Many SAP runtime logs are stored in IFS directories, which is an important consideration for understanding SAP-on-IBM-i performance. “So, if you have issues with SAP, maybe at startup or some other issue, for SAP runtime those logs are written to the IFS,” Hoelzle said. “Typically, no business data should be stored in the file system, but I’m sure that happens on occasion.”
Here is one very important point when it comes to monitoring SAP users: SAP does not use IBM i user profiles. It uses its own user authentication system, and the only time it uses IBM i user profiles is for administrators.
“SAP is SQL-centric and database-centric,” Hoelzle said. “Everything revolves around the database and then it uses some of these other components like the file system for miscellaneous tasks such as logging.”
Black Boxes
To appropriately monitor an SAP on IBM i environment, there are various places one should be looking, including (to name a few) subsystem status, job status, library and directory growth, temporary storage, and journal receiver libraries.
However, because there are so many places to look – not just on IBM i but on SAN arrays too – there is a “black box” effect where users lack the appropriate insight into what’s actually going on in regard to the three primary performance metrics: processor, memory, and disk I/O.
“These constraints and bottlenecks can occur anywhere,” Hoelzle said. “No single component is immune to constraints or bottlenecks. That’s why we want to remove these black boxes. We want to have visibility in to all of these areas because any one of these areas can slow down the entire system.”
Superior performance – including better scalability and memory I/O — is one of the key advantages that the IBM i platform holds over other servers that SAP supports. The possibility of growing system complexity masking performance challenges has emerged as a serious challenge awaiting joint SAP-IBM i customers.
“We need to understand how our systems are being used, what the constraints are, and really our goal here is to maintain what I call a balanced system,” Hoelzle said. “Effective, comprehensive monitoring is the key to that, especially as our environments get more complex.”
RELATED STORIES
SAP HANA Now Available On IBM Power
SAP on IBM i Kernel Upgrade Taxes CPU
