If the events of 2020 have high­light­ed any­thing for SAP envi­ron­ments, it’s the need for rapid-scale flex­i­bil­i­ty and reli­able per­for­mance of under­ly­ing infra­struc­ture. While not a new con­cept, oper­a­tional shifts of the past sev­er­al months have put the per­for­mance capa­bil­i­ties of even the most robust envi­ron­ments to the test. Unan­tic­i­pat­ed demand spikes, sud­den shifts in access require­ments, dis­rup­tions in sup­ply chain pro­ce­dures, and a height­ened reliance on data access — all of these have placed unfore­seen demands on the SAP application’s abil­i­ty to meet user demand to main­tain a com­pet­i­tive advan­tage for the business. 

In this five-part series, Bri­an Stur­gis and Rob McLaugh­lin, fel­low SAP spe­cial­ists at Dell Tech­nolo­gies, laid out the four big ideas dom­i­nat­ing inter­ac­tions with SAP users as the effects of a glob­al pan­dem­ic make their mark on every­day busi­ness oper­a­tions. In the sec­ond post, we explored the height­ened focus on the cloud and the need to build a cloud-first strategy. 

In this third post, we check in with Bri­an to delve more deeply into the scale and per­for­mance con­ver­sa­tion to under­stand how it’s evolv­ing and how recent expe­ri­ences can bet­ter pre­pare you for long-term SAP success.

In recent months, how has the scale and per­for­mance con­ver­sa­tion changed for SAP users?

Bri­an: For years, we have dis­cussed the impor­tance of infor­ma­tion life­cy­cle man­age­ment (ILM) for SAP envi­ron­ments. ILM is com­prised of many dif­fer­ent facets, one of which is data archiv­ing, which involves remov­ing data from the main data­base and stor­ing it else­where in a sec­ondary, relat­ed data­base. Among oth­er ben­e­fits, data archiv­ing allows you to reduce the size of in-mem­o­ry SAP HANA data­bas­es upon migra­tion from clas­sic RDBMS-based SAP to SAP HANA. Mem­o­ry is expen­sive, so reduc­ing data­base size helps min­i­mize cost, par­tic­u­lar­ly dur­ing cur­rent times, when SAP per­for­mance and access are so essen­tial and cost con­cerns are at the forefront. 

While some of the SAP teams I deal with have employed data archiv­ing, most have not. The main rea­son typ­i­cal­ly involves push­back from the busi­ness and the SAP users with­in the orga­ni­za­tion because archiv­ing can be dis­rup­tive to imple­ment and can alter typ­i­cal search/​inquiry process­es for less fre­quent­ly accessed data that has been archived. So, while IT is often a pro­po­nent of data archiv­ing, the busi­ness users do not often see how ben­e­fits out­weigh the costs. 

For SAP S/4HANA, how­ev­er, SAP has respond­ed with an alter­na­tive approach known as native stor­age exten­sions (NSE). NSEs allow you to store more fre­quent­ly accessed ​“hot” data in mem­o­ry and less fre­quent­ly accessed ​“warm” data in stor­age, all while being man­aged as a sin­gle, uni­fied data­base. The SAP soft­ware deter­mines auto­mat­i­cal­ly which data is hot and which data is warm and dis­trib­utes it accord­ing­ly. The loca­tion of the data — be it in mem­o­ry or in stor­age — is trans­par­ent to busi­ness users. And, unlike data archiv­ing, search/​inquiry process­es are not affected. 

But how does this actu­al­ly ben­e­fit the cus­tomer in terms of scale and cost reduc­tion?

Bri­an: Here’s a real-life exam­ple. A Dell Tech­nolo­gies cus­tomer recent­ly came to us with require­ments for an 8TB SAP HANA data­base, with the data and work area com­bined and that would like­ly be scal­ing even larg­er than that. One option — and cer­tain­ly the most expen­sive one — was to host that data­base com­plete­ly in RAM with an 8‑socket, 12TB RAM server. 

As an alter­na­tive, we pre­sent­ed the pos­si­bil­i­ty of using a 4‑socket, 6TB serv­er with SAP NSEs. With this option, only a lit­tle over 4TB of RAM — com­prised of SAP HANA hot data, work area, and a buffer cache — would be need­ed, while the remain­ing 4TB of the 8TB SAP HANA data­base would reside in stor­age as warm data. And, as we explained, the SAP HANA data­base could then grow to near­ly 12TB before the 6TB of RAM in the serv­er would be maxed out. 

Does that reduce cost? Absolute­ly. For SAP HANA, think of RAM as the expen­sive, beach­front prop­er­ty and stor­age as the less expen­sive homes a cou­ple blocks off the beach that don’t have quite the view and require a lit­tle walk­ing to get down to the ocean. If part of the ​“group” for which you are mak­ing reser­va­tions will stay beach­front, and part is fine with being a few blocks off the beach, then this becomes an ide­al solu­tion with sig­nif­i­cant cost sav­ings. These sav­ings can then be invest­ed into future vaca­tions, bet­ter nightlife, or a rainy-day fund. 

This is a great exam­ple of how inno­v­a­tive think­ing can ben­e­fit a busi­ness dur­ing times of change and ulti­mate­ly leave them in a stronger posi­tion for the long term.

OK, but what about those cus­tomers who need max­i­mum per­for­mance for their SAP HANA data­bas­es but are still cost-sen­si­tive?

Bri­an: Of course, NSEs are not going to be right for every­one, but inno­v­a­tive per­for­mance options exist. When we think of RAM, we typ­i­cal­ly think of DRAM (dynam­ic ran­dom-access mem­o­ry). But recent­ly, a new class of mem­o­ry, known as Intel Optane per­sis­tent mem­o­ry, or PMem, has been approved for SAP HANA con­fig­u­ra­tions. PMem is indeed mem­o­ry, so it is near­ly as per­for­mant as DRAM. How­ev­er, it is less expen­sive than DRAM and per­mits, in many cas­es, the size of mem­o­ry to be larg­er when com­pared to all-DRAM. It also enables faster SAP HANA node restart times. 

Analy­sis of a spe­cif­ic SAP HANA work­load is typ­i­cal­ly need­ed to deter­mine the fit and fea­si­bil­i­ty of PMem, but it is not uncom­mon to use a 1 to 2 DRAM-to-PMem ratio for HANA serv­er. For exam­ple, in a 4‑socket serv­er, you could have 3TB of DRAM and 6TB of PMem, which yields a total of 9TB to host the SAP HANA data­base. When com­pared with a 9TB-plus all-DRAM serv­er, this option is typ­i­cal­ly much less expen­sive, yet near­ly as high performing. 

As an SAP spe­cial­ist, how does this envi­ron­ment affect your solu­tion approach? What are you doing dif­fer­ent­ly to respond to scale and per­for­mance require­ments?

Bri­an: One thing has con­tin­ued to stay the same, for sure — indi­vid­ual busi­ness require­ments dri­ve the solu­tion. Each SAP envi­ron­ment is dif­fer­ent, and it is impor­tant to take into account all rel­e­vant vari­ables, like cur­rent infra­struc­ture, strat­e­gy, past expe­ri­ences, com­pa­ny stan­dards, data­base sizes, growth rates, cost and bud­get con­cerns, per­for­mance demands, and so on, before we engage heav­i­ly in solu­tion­ing. No two solu­tion approach­es are alike.

What is chang­ing today is the tech­nol­o­gy evo­lu­tion with­in and around SAP. New options, tech­niques, and the like con­tin­ue to emerge. Some of this is dri­ven by recent glob­al events, and some are the nor­mal course of inno­va­tion and busi­ness trans­for­ma­tion. It is imper­a­tive that we as spe­cial­ists stay informed, con­ver­sant, and adept at design­ing SAP infra­struc­ture solu­tions accord­ing­ly. It is our job to ensure that SAP users are aware of the options avail­able to them. With­in the past few months, since start­ing this blog series, sev­er­al of my con­tacts have reached out want­i­ng to dis­cuss SAP data tier­ing tech­niques using NSEs, PMem, etc. This is an excit­ing trend and I hope read­ers here will reach out if they have ques­tions of their own.

ASUG mem­bers can reg­is­ter for the Exec­u­tive Exchange Vir­tu­al Round­table: Refreshed Strat­e­gy on Dig­i­tal Trans­for­ma­tion Ini­tia­tives on Nov. 19.