Ask the Expert: SAP HANA TDI with EMC - Implementation, Rules and Details

Hi All,

This ask the expert session is now open! All questions are welcome.

Just post your question as reply to the main message on this threat, and myself alongside my colleagues moderating this discussion, will come on a regular basis to provide you with responses.

This discussion will be open for 2 weeks as of today, and we'll welcome any questions in relation to SAP HANA Tailored Datacenter Integration, SAP HANA virtualization, and SAP HANA in general.

Be also aware that we will be hosting a high level session on SAP HANA TDI at SAPinsider on the September 17th, and all questions on details will be able to be answered here.

Note that on the moderators team, together with me we have our colleague responsible for all SAP HANA deployment services in VCE so with a welth of implementation experience, and our colleague responsible for EMC's engineering roadmap bringing a unique perspective from solutions engineering.

So, looking forward to answering all questions you may have on this topic.

Português: coloque as suas questões também em Português, que eu e o Wesley Gentine responderemos.

Español: coloque sus dudas también en Español, que yo y  Wesley Gentine le contestaremos.

Hi, I was in a customer discussion today and was asked if HANA TDI applies only to certain SAP applications or if TDI based HANA systems can be used for any SAP application. Can you comment?

Posting  a questions on HANA TDI. Few are more general to SAP.

1) Any plan to support SGI TDI with any standard HA configuration ? Their HA uses DT instead.

That's a question we keep getting, and also yesterday one global service provider asked the same.

The simple answer is that the TDI rules apply regardless of the SAP application or the size of the SAP HANA node, as its SAP that defines the rules, and that's how SAP has defined it.

But going deeper, I believe the question keeps popping up because the simple answer I gave above, doesn't match the "gut feel" of all those experienced architects that have been designing SAP systems for years new.

Why? Our experience shows us that the "right infrastructure requirements" for a certain SAP application is a factor of the number of users, number of interfaces, batch workload and database size. So, in our minds it seems wrong that the TDI rules are the same regardless of all these factors.

We need then to look at the SAP HANA TDI rules as a guideline for certification.

SAP HANA, being still such a young product, still lacks broad experienced resources in the market.

SAP by defining these rules, is defining a baseline from which the customers can build systems and where performance will not be a major challenge. So, these rules are a starting point, as once the application is in production, its up to the customer to monitor it and administer it, and adapt the allocation of resources to its actual needs.

In summary: look at this TDI rules as a "safe starting point", as a guideline. Not as a hard rule written in stone.

There are many options for HA configurations.

Obviously the SAP supplied options for hot/warm standby being one.

SuSe Linux has it's own HA capabilities, in fact SuSe now do the certification of
all HA products that work with SAP as announced last year at SAP Tech'ed.

If you have EMC storage then there are multiple options for DR as well,

e.g. recovery point, SRDF, VPLEX

Large memory size means need fast restart times and time to read storage and load into memory without waiting for hours.  From a HANA Roadmap we are looking at standard SAP System Replication for local HA (instaead or in addition to remote DT) to meet the high RTO needs.  EMC value is the expectation  that XtremIO on HANA for local HA saves 50% of the storage footprint on top of the normal compression/dedupe XtremIO savings.  With EMC and XtremIO on HANA combining best of SAP and EMC get great restart times and low storage need.  Will also look at restart with just XtremIO.  We hope to quantify and report by early Q1.    

Unlike SRDF and VPLEX, Recover Point for HANA is not yet supported but planned for Q4/Q1.  Stay tuned. 

Jason,

There is definitely a space for ScaleIO for SAP HANA.

ScaleIO as a software is absolutely viable, but you need to understand how it plays in the HANA stack and in each organization's datacenter strategy.

First, ScaleIO by being a software only solution, will always need hardware to be ran on. In that sense, it is not required to be certified by SAP under the TDI program. What needs to be certified if the hardware components the SAP HANA software will run on.

So, as you can see from SAP Note 800326, SAP looks at ScaleIO as one OS component that can be used in conjunction with SAP HANA software. Here I must highlight that the critical component in terms of performance is the hardware configuration that SAP HANA and ScaleIO will be running on, as our engineering lab testing proved that ScaleIO can deliver against the most demanding performance KPIs as long as the underlying infrastructure is properly designed. We have a couple of whitepapers (this one being one example) documenting the conclusions of this engineering testing.

Second, the ScaleIO discussion is all about a different datacenter architecture strategy, as the idea behind ScaleIO is to enable its usage on top of low cost servers, providing s virtual SAN with elastic capabilities, and the more nodes you have on the ScaleIO cluster, the better it will perform. We see this being requested mainly by Service Providers, where I would say such architectures observe a lot of interest. Putting ScaleIO for a single SAP HANA system might not be the best choice, since ScaleIO needs a minimum of 3 servers in the cluster to work, and its sweet spot is from 10 to 20 servers onwards.

Does this answer your question?

Hi, can you speak about EMC ScaleIO as a TDI solution for SAP HANA?  Is it viable?  Is there customer interest?  If not, why?

Jason,

You ask is there customer interest.  As you know the SAP market is made up of SAN storage today.  So the SAP databases are running on that SAN storage.  I see ScaleIO as a greenfield need coming especially when a net new environment is be implemented as with a new SP or cloud offer.  We have it supported for HANA after resolving some early issues with the HA required scsi 3 reservations.  I will be interested as the market matures.  For now expecting only a few.  Glad we are ahead of the curve here.

In HANA Failover HA scenarios (not HANA System Replication), is there a rule of thumb for failover time per GB or TB of HANA resident in memory?

Hi folks.  Two part question.  First, in TDI scenarios, are both Cisco and Brocade SAN switches viable choices?  The specific scenario is SGI scale-up with VNX.  Second question, so long as EMC TDI recommendations are adhered to, are there any major objections to hosting PRD, QAS, and DEV on the same VNX array?

Let me take a stab.

For supported switches there is no SAP site that certifies and reports them.  Per the SAP HANA TDI FAQ:

"Not all combinations of network interface cards and switches work as expected. Therefore, before making the decision for a certain combination, customers must contact the server vendor and inquire which switches are supported for the network interface cards of the given server."

So Cisco and Brocade have hardware that does work and supported on certain servers.  Best to check with server vendor.  To make a server sale, support is something that can be negotiated with server vendor.

As far as sharing test and production on the same VNX there is no issue as long as recommendations are followed.

As far as rule of thumb for normal HANA HA to a local standby node that is a great question.  Since the standby node is up and running, there is only the short scsi reservation time plus the"lazy"  load of required tables into memory.  I have my rule of thumb but like any rule of thumb is probably wrong 99% of the time. Based on what I have seen, HANA restart for a 512GB node is around 10-15 minutes, I would divide the entire HANA per node memory in GB by 512gb and multiply by 10-15 minutes.  So a SGI 12TB would be 24 * 10 minutes  to 24 * 15 minutes.  Add 10% fudge factor to err on high side and account for any other times.  This assumes the low end 10K drives and only using so many HBA's, FA's, etc.  15K and SDD drives or more paths would expect better times,  I have no rule of thumb for those yet

Hope this helps

Allan

Thank you Allan!  Sounds like a good place to start on the failover estimation.