Expand +



What Converged Infrastructures Mean for Your SAP Landscape: Q&A on Tailored Datacenter Integration (TDI) and SAP HANA Deployment Options

February 04, 2015

Thank you to all those who joined our online Q&A with Cisco's Konrad Lang, Robert Madl, and Michiel Bijlsma.

In this online chat, these three expert took readers' questions on SAP HANA Tailored Datacenter Infrastructure (TDI), appliance-based deployment, virtualization with SAP HANA TDI, and time to deployment, among other topics.

View the chat replay below and read the edited transcript to review all the Q&A discussion.

Live Blog Q&A on SAP HANA TDI and Converged Infrastructures for SAP HANA


SAPinsider: Looking forward to your questions about future look at datacenter and server management for your SAP landscape and SAP HANA deployments.

Cisco's Konrad Lang, Robert Madl and Michiel Bijlsma will take your infrastructure questions on sizing, scaling, and managing the IT footprint for your SAP and SAP HANA systems.

All your questions will go to our moderator, SAPinsider's Katherine Van Adzin, who will kick off today's Q&A.


Katie Van Adzin, SAPinsider: Welcome to today’s live Q&A! Thank you to everyone for joining us this morning from all over the globe.

Konrad Lang, Cisco: Hello everybody.

Robert Madl, Cisco: Hello everyone!

Michiel Bijlsma, Cisco: Hello! 

Katie Van Adzin: I’m joined today by three experts from Cisco’s EMEA team: Konrad Lang joined Cisco in 2009 as part of the Cisco Datacenter Technologies team and now runs the EMEAR team for SAP infrastructure sales. Robert Madl serves as sales specialist for SAP projects covering projects in Europe, Middle East, Africa and Russia. And Michiel Bijlsma is a technical solutions architect with Cisco.

Welcome, Konrad, Robert, and Michiel! Thank you for joining us and taking some questions here for the hour. We have quite a few questions already in from our readers, so I’ll let you get to those now!


Comment From Albert Backer, BMW

Appliances have a limited certification according to the SAP web site (latest Dec-2017). What does this mean to the customer? Will it also affect TDI certifications?

Michiel Bijlsma: Good question, since our understanding based on multiple years of experience with the certification process is that there is no expiration date, other than the point where we as a vendor decide on end-of-life and end-of-support-life of the actual physical server that was certified.
SAP has decided to add this "Cert. until" column to their listings. We have escalated with SAP in order to have them clarify this and are still waiting for an answer.
As far as Cisco is concerned, we will maintain (re-)certification for as long as we support the actual server model, which is typically at least 5 years or more starting on the launch date.
The same rules apply to TDI for production environments as they do to appliance certifications, since TDI still requires the server configuration to be on the certified hardware lists somewhere. Until we get clarification from our engineering contacts within SAP, we assume 5-year availability and will actively drive that for Cisco hardware.


Comment From Satya

Is there an ETA from SAP to open up HANA hardware configuration?

Konrad Lang:  Satya, with introducing the different phases of TDI, more and more flexibility has been added by SAP to the hardware configuration.  We from Cisco are well prepared for that as we integrate with different storage vendors by nature and also, of course, are ready to make use of shared networking.
The latest TDI phase includes E5 Processors which from Cisco will appear on the certification list very soon. Further steps and rules for certification are to be announced by SAP.


Comment From Albert Backer, BMW

What are the key problem sources with TDI for scale out?

Robert Madl: With TDI the customer has a free choice to mix vendors on a server, storage, and networking level as long as the products are certified within SAP TDI certification. Still we recommend sticking to pre-engineered reference architectures to leverage the engineering work that was done for our appliances.
For example, Cisco has done its appliances with EMC and NetApp, and to those storage vendors integrated support interfaces are in place and we have gained lots of experience from the past appliance and TDI installations.
TDI also allows using the infrastructure for other workloads than HANA. If you stick to a reference architecture, there are validated designs and whitepapers in place for using the architecture for VMware, Microsoft, SAP App Servers, etc.


Comment From Guest

Does TDI support virtualization?

Michiel Bijlsma: Yes, exactly as virtualization is supported by the appliance, but more so due to the flexible nature of TDI. For example, more flexibility in the storage layout can actually help to support scenarios where HANA is migrated from physical to virtual or vice versa.
Also, if the elasticity of a virtual HANA appliance is leveraged by oversizing and subsequently right-sizing the virtual appliance, then TDI supports the reuse of the resources that are freed up, whereas in the appliance they can't be leveraged for anything else.


Comment From Albert Backer, BMW

How much extra time will TDI typically require for a project (scale out)?

Robert Madl: If you stick to a pre-tested reference architecture, project management gets a lot easier. The main difference is then that the systems need to be set up on-site, which takes around 2-4 weeks depending on the complexity of the systems.
If you have a complex setup, the single-system-per-appliance approach might not fit for you anyway, and you would have to reconfigure the appliance too, which basically is the same work.
Key is that the partner who is doing the implementation work already has knowledge on how to configure the servers and the storage for HANA as well as knowing how to set up and configure Linux and the HANA DB itself. Configuring those systems for HANA is quite different to setting up those systems for a virtualization landscape.


Comment From Nic Jones

What is the largest (TB) ECC database that you can currently support with an appliance? Ditto question for a TDI configuration?

Michiel Bijlsma: For ECC, the Suite on HANA case, our largest appliance is 6TB.
In TDI, with an additional special request by SAP - and depending on how SAP evaluates your use case - it may be possible to distribute the ECC tables over multiple nodes, in which case the configuration will be restricted to 4x 6TB nodes, so we can actually support 24TB.
Be aware that this comes with a strong recommendation not to fill up the nodes completely. So if you have a use case needing an ECC that, after compression and reduction of tables, etc., is still over 20TB in size, please consult with SAP directly.  
Bangkok Airways, one of our references on YouTube, is actually a scale-out ECC configuration, though it is not nearly as large as 20TB.

Comment From Nic Jones: Thanks for the previous answer.


Comment From Guest

With TDI, do you see any challenges to add blades or otherwise scale our systems in the future?

Robert Madl: From a Cisco hardware perspective, there will not be any challenges to add blades and scale the systems. We also are now able to add nodes on-line.
With the Intel CPU platform change from Westmere to Ivy Bridge, SAP introduced the rule that you are allowed to mix both CPU types, but not have more Ivy Bridge than Westmere nodes within one SAP System (SID).
Cisco’s shared infrastructure part will stay the same and you can mix different generations of servers within the system. But we don't know which rules SAP will come up with in the future.
You also have to keep in mind that adding a node is easy -- but redistributing data on an SAP HANA DB level is hard.


Comment From Atul Kumar Jain

What should be the major key point to select between HANA on premises and HANA on Cloud?

Konrad Lang: Great question. Making use of cloud services or building on premise is a broader equation, not only for HANA, and heavily depends on your situation and use case. It is about risk, TCO, legal constraints, data privacy considerations, organizational requirements, time constraints, SLA, needed flexibility, elasticity…
If, for example, you are looking for elasticity and fast provisioning time to support a PoC or development project, or because you are a very fast-moving company with fast-changing requirements, this could be an easy business case for cloud deployment.
If you already have a skilled IT department and a big environment to be migrated to HANA, then an on-premise solution might be the easier business case.
But these are really individual considerations.
With our HANA cloud reference architecture, we are also prepared to build private clouds for HANA in a TDI setup to provide the required flexibility in combination with the safety of on-premise data and control by the local operation team.  We are often in these discussions with customers and happy to support you in your further consideration.


Comment From Guest

Is HANA long-term support/maintenance different with TDI vs. appliance deployments?

Robert Madl: Cisco has different options regarding support. The different support agreements are mandatory with the appliance but optional with TDI.
First, there is a hardware break&fix support contract, which is the same support for both models. With TDI you would have the option to go for 8x5 instead of 24x7, but break&fix is not a big portion of the price.
Then with the appliance, Cisco is the Single Point of Contact for the whole stack - also for the EMC or NetApp storage option. In the appliance model, SAP has an interface to Cisco where SAP can open tickets on behalf of the customer. With TDI it’s the customer’s responsibility to open tickets with every vendor in the stack.
Cisco offers an option to take the responsibility and act as SPOC for the hardware stack (e.g., Cisco, Storage, Linux, ev. VMware). Just the integration of SAP with the hardware vendors is not offered by SAP with TDI.


Comment From Nic Jones

Do you have any experience with (or comment on) being able to run systems with Synchronous System Replication across distances >100km and/or >1ms latency?

Michiel Bijlsma: We don't have experience with customers synchronously replicating over such a large distance and SAP doesn't support it - at least not unless you put in a special request with SAP. Synchronous system replication support by SAP goes only up to 25km. I myself would not recommend this due to the very low-latency KPIs that SAP sets for HANA performance and the extremely high cost that would result from having to provide the necessary bandwidth over such long distances.


Comment From Guest

What effect on performance would you see for a large-scale HANA db (>10TB) with sync replication over a distance of >10KM? Do you have customers (large-scale) running sync replication today with HANA?

Michiel Bijlsma: You're likely to see a measurable reduction in (user) response times at replication over any distance. But as long as your HANA configuration continues to meet the KPIs set by SAP for HANA performance, this is no issue that will affect HANA stability. The usual trade-offs for performance, robustness, and recoverability continue to apply.
We have a customer with an 8TB scale-out configuration doing such synchronous replication. It didn't affect the response times as perceived by their users at all, but in fairness, the distance is much less than 10km in this particular case. This was a TDI engagement where the performance KPIs were extensively tested and met or exceeded.


Comment From Guest

Any recommendations on key KPIs for HANA infrastructure? Downtime? Bandwidth? Latency?

Michiel Bijlsma:  I hope I interpret the question right, but please respond if I don't: 
The two most important ones I know as an architect are (high) availability and disaster recovery, as they prove time and again to have the most impact on cost and the biggest impact on operational complexity.

There are no defined standards in the HANA appliance model of how to address the infrastructure design of such solutions -- only options you can leverage, such as HANA System replication or storage replication.

The key difference between other vendor architectures/appliances and Cisco UCS in such scenarios is the ease of management that Cisco UCS delivers as part of the architecture, and the flexibility, such as migrating UCS service profiles (physical server hardware identities) between data centers in a disaster recovery scenario in an automated way.

With HANA virtualization being as restricted as it is currently, the ability to migrate a physical server to another piece of hardware at another site as if it's a virtual one cannot be overestimated.

With regard to inter-site bandwidth, this is always the most difficult one to estimate beforehand, as it will depend on use case and workload of the primary production appliance.

With regard to HANA appliance KPIs, those are pre-set by SAP, so any vendor appliance is equal to any other vendor's in that regard -- whether they use, for instance, expensive enterprise flash storage or reliable spinning disks.

A differentiator with TDI is that more flexible design of the persistence layer (storage) becomes possible, for instance to facilitate the use of clever backup solutions based on snapshot / data mirroring technologies.


Comment From Arto

How about VMware-Cisco-HANA combination usage and certifications?

Michiel Bijlsma: Cisco fully supports the use of VMware for HANA and one of our appliance models (1TB C460M4) is available also fully preconfigured with VMware vSphere 5.5 currently. But we actually support and can sell VMware licenses included with all our appliance models which by implication, makes it applicable to TDI configurations also.
The key thing to be aware of is that SAP currently sets the restrictions around production use of HANA on VMware. The most limiting restriction in my view, currently, is that only a single production VMware HANA is allowed on any physical HANA appliance. The rest of the appliance may be used for other (i.e. application server) workloads on VMware, but not any other HANA, neither prod nor non-prod.
Cisco actually employs full-time VMware engineers in our SAP competence center to work with SAP and VMware to improve and remove all these restrictions. We expect a lot from the upcoming VSphere 6 launch in the area of HANA support.


Comment From Guest

What are risks around persistency with HANA? How is this managed in TDI vs. appliance?

Robert Madl: Storage performance is the bottleneck in a HANA system as the system writes synchronous savepoints from all nodes every five minutes.
Also, although during normal operation HANA does not read data from the persistency layer during load (or failover) of the database, storage performance is important, as the entire database needs to be loaded into memory for full performance, which impacts your RTO.
As storage KPIs are not only defined by database size but also by node number, smaller but more nodes are much better regarding startup time and RTO in case of disaster, as memory check and dataload times scale linear with the size of the node.
With TDI you should discuss your storage usage and disk layouts with the SAP Competency Center of your storage vendor if you want to use the storage for additional workloads other than HANA. There is a tool from SAP to test storage performance within a TDI installation.


Comment From Guest

What are the differences in server provisioning and patching in a converged approach?

Konrad Lang: Converged infrastructure delivers minimization of risk to the hardware by using wire-once principles; minimization of risk to availability by using integrated management tooling that covers storage, servers, and networking integrally; and using pretested combinations of HW and minimization of risk to investments by allowing flexible (re-)use of deployed hardware capacity, compared to build-your-own stand-alone (appliance) server and storage array configurations. It also accelerates the time to market, of course, due to less test and integration effort.

Comment From Guest

How do we know what WAN bandwidth is required for >500km between DCs for an RPO of 30 minutes and an RTO of 8 hours?

Michiel Bijlsma: It depends - I’ll need more information. But I'll assume you're not talking about stretching a HANA scale-out cluster over those 500km. To my knowledge SAP don't support that.
So this would be a storage replication or HANA system replication scenario. >500km means you will likely go async, so the bandwidth requirement is relaxed and can be averaged over time, as is further evidenced by the 30-minute RPO.
I don't think the RTO has much influence on it, but it does mean that the need for HANA instance preload in the secondary site instance is not a strict requirement (unless it's a really big config).
The real dependency will be on the amount of write traffic going to HANA, because that is the only data that gets pushed over the WAN. For OLTP this is expected to be much higher than for OLAP.
For some use cases, a 100Mbit/sec link will be more than sufficient while for other use cases even a trunk of four 1Gbit/sec links might not be enough to keep up with OLTP activity over the span of a full day.
I would average out, over a day, the amount (gigabytes) of data writes into the HANA DB divided by the amount of elapsed seconds. Taking that as the bandwidth requirement (assuming async HANA system replication) would seem to be the safe approach.
I am assuming no rewrites of the same data block within the span of a day, which is an unrealistic assumption but has the consequence that I'm probably on the high side of the actual bandwidth requirement.
If no existing HANA system is present to measure this, the only option you have is to do the same measurement on the current database of the system - for instance the ERP DB, if that is the HANA use case in question.
For BW specifically there can be the problem of ETL data load times, but HANA by itself does not affect that differently by much.
With HANA, SAP makes available a technology called SLT, which allows continued synchronization and ETL of a BW HANA with its (ERP) source system, or a checkpointed/buffered version of that, which could reduce peak bandwidth requirements very much when used.


Comment From Albert Backer, BMW

Do you have experience/reference installations with scale-out architectures for BW on HANA at customers?

Robert Madl: Yes. We have some official references where you will find YouTube videos like Bangkok Airways or EMC. The world’s largest productive BW scale out system is the one from eBay according to information from SAP.
If you have a look at this video they will talk about their experience with HANA and Cisco. There are also quite big (>20 nodes) installations in the range of BMW where we can happily arrange a direct call.


Comment From Guest

Thanks all. Can we get a copy of the Q&A?

Katie Van Adzin: You're welcome! Yes, the replay will be available immediately after the Q&A and we will alert you when the edited transcript is posted. Thanks for joining us today! 

Michiel Bijlsma: Thanks everyone for all the great questions!  You can reach me at

Katie Van Adzin: And thanks again to Konrad Lang, Robert Madl, and Michiel Bijlsma for joining us today. 

Robert Madl: Thank you very much. If you have any additional questions reach out to us via email, and LinkedIn. 

Konrad Lang: Thanks everyone for joining. You can reach me at Please have a look at this IDC study on ROI of Cisco SAP/HANA infrastructure and feel free to reach out to us.

Katie Van Adzin: For more information on Cisco’s offerings for SAP customers, visit their resources here and download the IDC white paper with specifics on SAP customers’ experience with Cisco datacenter integration. I invite you to visit the SAPinsider HANA Channel – and our Admin/Dev channel – for more IT advice for SAP.
Thanks again, and have a great day everyone!

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!