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

Mark,

In regards to the reload time, now with the current version of SAP HANA that is SPS10, some things have changed.

As Allan mentioned, there is always the lazy load of the column store which does not interfere in terms of RTO, as the system will be available (although with degraded performance until the key objects are reloaded in memory).

So, when I see questions related with fail-over time, it always means what is the expected RTO on each HA scenario.

And here there are quite some different options.

The picture above gives you an overview of all possibilities.

So, we can make this discussion in two ways: discuss what is the optimal RTO we can expect for each of these scenarios; or what is the right solution depending on the customer specific requirements.

Defining what is the expected RTO for each of the High Availability solutions above is always dangerous, because it depends on quite some variables.

So, in the hope of answering your question, let me take one example.

If you have one SAP HANA system consisting of a single node of 6 TB, possible RTOs for the different applicable solutions could be something like:

• SAP HANA System Replication across 2 VMs, using a clustering software like the SLES Failover Cluster:
  • SAP HANA System Replication has multiple configuration options, but HA purposes I would assume the following as usable:
    • Synchronous: The write is successful once it is acknowledged on the secondary system, but is not "pre-loaded in memory"
    • Synchronous in-memory: same as before but, all data is pre-loaded in memory on the secondary node;
    • Full Sync: is an additional parameter to the "sync" options, where the write is only acknowledged once it is written on the LOG volume of the secondary system. No impact on RTO, but ensures a zero RPO.
  • For sync: you have to account for about 30 seconds to 1 minute of failover time (as SAP HANA has a default time out to declare a failure of 30 seconds), then you would need to load the "minimum needed tables" for th instance to be accessible again. I'll discuss further ahead what is the "minimum tables needed".
  • For sync in-memory, there the RTO is just the 30 seconds time-out of HANA plus the DNS redirect, so could be in the order of less than 1 minute.
• SAP HANA Host Auto-failover: no need for clustering software as HANA makes that work of orchestrating the failover.
  • In this scenario, the secondary system would have the HANA services started, but no data and no activity.
  • The failover mechanism would be managed by HANA and would imply the "faiover of the persistency" plus the load of the "minimum tables necessary" for the system to become available.
  • So, the times would be:
    • The time for the SAP HANA Secondary NameServer to take control (few seconds) + trigger the SCSI persistency reservations clean-up, rewrite, and mount of LUNs on the secondary server (few seconds more) + recovery of the database (can go from seconds to minutes depending on the volume of pending transactions to be rolled-forward or rolled-back) + load of "minimum number of tables" necessary for the system to come online.

So, both in the case of HANA System Replication in "sync mode" without pre-load, and HANA host auto-failover, you would need to load a minimum number of tables for the system to become available.

Those tables are system tables (can be column or row) and all the other ROW tables. The problem in previous versions of HANA was that the ROW tables, while being reloaded, also triggered the rebuild of all its "in-memory indexes", which made the whole process to take quite some time. I heard values like 2 GB for second, but you need to remember that this number depends a lot on the number and speed of the HBAs on the server, the number and speed of the CPUs on the server, the configured front-end connectivity on the storage, and these are just few examples. Meaning this number can be higher or lower depending on each customer case.

Now with SAP HANA SPS10, this rebuild of the indexes is triggered asynchronously after the basic tables are loaded and the instance comes online, and I've heard comments on 6 TB systems coming up in times like 2 minutes. Of course the size of the data to be reloaded will also play a great role here, and the fact that the system has 6 TB doesn't mean it has a very big or small row store as that depends on each customer system. This means that the 2GB/second no longer makes sense, and I don't have yet number on SPS10 from customers.

Final aspect: if you think on a scenario of storage replication, you need to add to the scenario I described above of "HANA Host Auto-failover" the boot time of the system, which can be considerable for a physical server, and can be under 3 minutes for a virtual machine.

Conclusion: for a scenario of SAP HANA Host Auto-Failover, I believe it is reasonable - with SAP HANA SPS10, for a typical 6TB node - to expect failover times between 2 and 5 minutes.

So, I cannot give you a "rule of thumb" as this changes a lot with version, and system topology, but hope this explanation helps you understand the variables involved.

The customer performing good "house keeping" work in reducing the volume of data on the ROW store, avoiding creating ROW tables unless absolutely necessary, avoid marking column tables as pre-load unless absolutely necessary, are all mechanisms that can help them keep the RTO very low with a clean and simple solution such as SAP HANA Host Auto-failover or Storage replication.

I believe that the key thing is to have the system available again as fast as possible, even assuming that not all data will be in memory, as it will be loaded in a "lazy mode", and so assuming as well that the performance won't be as good while the whole "working data" is back in RAM.

If the question goes to "how much time to load my whole data back to RAM and have 100% performance", I have no better number's than what Allan has provided, although I know Allan's numbers are previous to SPS10, and I'll be curious to see how that looks with these new optimizations of the ROW store load SAP came up on this latest version.

Let me know if this helps, ok?

Hi, Is there any rules around running SAP HANA in an infrastructure partially shared with a hosting/cloud provider? Does TDI extends to cloud provider which resources at some layers like compute may be shared with their customers? Or there is other certification around for them to obtain before they could win our business?

Thanks.

Shu

For production the same rules apply even if virtualized on TDI, i.e. dedicated host for the Compute.

Also the same rules apply for the shared storage, e.g. number of production nodes for the model concerned.

Antonio, this is spot on, I appreciate it!

While this discussion here is about TDI, my question is how do you position TDI compared to appliance model?  For example, if appliance model is seen as cheaper within 3 years compared to costs of TDI solution, why customer would go for TDI?  Surely, one may argue that you get to use existing resources (if you have those), but you can also see the other side which says they can save on those resources.  Obviously feature set of TDI would need to prevail to be of critical importance and something that SAP or appliance supplier would not have on roadmap within next HW refresh cycle for TDI solution, but I keep wondering is it really so. Of course, there are other drivers like how healthy your internal IT structure is (I assume those less healthier will probably drive SAP folks more towards appliance model).  How do you deal with such challenges?  What is the crucial benefit of TDI that would drive someone to consider it?

Hrvoje,

All your considerations may be relevant when you think only about SAP HANA and about CAPEX. In that perspective, purely from a CAPEX perspective, there will be no cheaper solution than a server with internal disks.

Then I would invite you to broaden your reasoning with the following aspects:

• OPEX accounts for more of the TCO than CAPEX, even within a 3 year period. Think for example on lifecycle management activities like patching the system or refreshing data in a test system. Enterprise storage enables you for example just to take a snapshot of the production volumes while doing applying a patch, providing you a quick "rollback point" in case of errors, then also enabling shorter downtime windows and less cost on labor when performing these tasks. The larger your environment, the more relevant this will be. The same with Test system data refresh, with storage, you just take a snapshot from the production volumes and mount it back to the test system, and this also shortens the run time of these tasks significantly, enabling you to do them more often and better support your functional teams in their change needs. Then think on the combination of these examples with the possibilities offered by virtualization and SAP LVM, opening possibilities to deploy test systems and better support a very dynamic change environment. If you put a measurement on the organization's need for agility and fast pace of change, you can easily come to the conclusion that an appliance model will not do it.
• Think on the other side that most customers have more than just SAP HANA in the datacenter. Then think on the major savings driven by datacenter wide standardization on technologies, processes, skillsets and tools. Having the same platform for all your applications drives major benefits. This is why technologies like server virtualization have gained such importance over the last years, as not only it enables better flexibility and automation, but it also drives better utilization of assets. All these variables are as important when talking about SAP HANA as when you talk on other business systems in the datacenter.

These are just a few examples, but the point is that the benefits here go beyond just a "SAP HANA discussion" into an IT strategy, architecture and operations discussion. When you expand the perspective, then the benefits of being able to leverage those standards across the datacenter for SAP HANA as well, are a no brainer.

Let me invite you as well to have a look at the presentation we did recently for SAPinsider. The link to that webminar and other materials specific to the "business case for SAP HANA TDI" can be found at: https://community.emc.com/docs/DOC-49035

So, the appliance vs TDI discussion for me makes no sense on a "feature vs feature" discussion, as this is all about datacenter strategy, operations simplification, enabling simpler change and better business agility, which in the end will drive a lower TCO.

One final comment as EMC is best known in the data storage market: if you only look at disk latency and acquisition cost, there would be no market for shared storage in the world, as internal disks in servers provide a lower acquisition cost and a lower latency than any SAN based solution. So why companies have made this a standard across their datacenters in the world? Because it enables simpler protection of data, streamlines replication and DR mechanisms, simpler lifecycle management, simpler scalability, simpler change... and many other benefits that come from the fact that the only guaranteed thing an organization have in these days of globalized economies, is that change will happen.

Note that my perspective comes from the experience with large global organizations with a mixed portfolio of applications in the datacenter, being SAP HANA just one, and where being agile is today one of their major challenges, building silos in the datacenter doesn't help their cause.

Again, please review our webminar for SAPinsider and our whitepaper with the "Business case for SAP HANA TDI", and let us know if this answers your questions, ok?

Kind Regards,

This Ask the Expert event has officially ended, but don't let that retract you from asking more questions. At this point our SME are still welcomed to answer and continue the discussion though not required. Here is where we ask our community members to chime in and assist other users if they're able to provide information.

Many thanks to our SMEs who selflessly made themselves available to answer questions. We also appreciate our users for taking part of the discussion and ask so many interesting questions.

ATE events are made for your benefit as members of ECN. If you’re interested in pitching a topic or Subject Matter Experts we would be interested in hearing it. To learn more on what it takes to start an event please visit our Ask the Expert Program Space on ECN.

hi im new herer in this  community and need expert advice.

can you help me?

Hi, this Ask the Expert event is finished, though you may post your question on this thread, with specifics about your inquiry, so that anyone who is following it can try to answer you. If by any chance you still don't receive help specific to the question you posted, my advice is for you to access www.support.emc.com and either file an SR or request help through chat or phone.

Good luck!