A few days ago VMware and SAP jointly announced full production support for SAP HANA on VMware vSphere. This is a major milestone and I know both VMware and SAP have put in a lot of effort to get to this point. This is the culmination of three years of testing and benchmarking by VMware and SAP. It was with much anticipation I read the announcement as I’d worked with customers wanting to virtualize SAP HANA for production for quite some time. Now you can run production SAP HANA systems up to 1TB RAM on VMware vSphere and be fully supported by both SAP and VMware, without losing the manageability aspects of VMware that you’ve come to rely on, such as vMotion, HA and DRS. This article will briefly look at the highlights, what’s included, and what is still in the pipeline.
Here are the highlights of the announcement:
- Support for SAP HANA instances up to 1TB RAM and up to 64 vCPU in size (32 physical CPU cores*).
- You can run multiple SAP HANA instances of varying sizes on a single VMware vSphere Host.
- Only SAP HANA certified server hardware and storage is supported. Hardware must be on the SAP HANA certified list as well as the VMware HCL.
- Only 2 socket and 4 socket servers with E7 processors are supported*.
- Key VMware features such as Host Profiles, vMotion, DRS and HA are supported for use with production SAP HANA.
Some of the things still in the pipeline and not yet supported:
- SAP HANA on 8 socket servers.
- Scale-out SAP HANA instances (with active/passive instances).
This makes VMware the first company that has production support for running HANA both on premises and in a public cloud, on a single platform. This gives customers a lot of flexibility in how they wish to run and deploy their systems. Why run HANA on physical appliances when you can get the performance you need, availability, superior manageability, much faster provisioning and time to market, and significantly lower TCO? VMware vCloud Suite can be the foundation of running SAP HANA where ever and however you wish, while delivering the best possible service levels and lowest possible TCO.
Here are all the key resources you need to get started and get the detailed information:
SAP HANA on VMware vSphere Best Practices Guide
SAP HANA on VMware Production Environments FAQ
SAP HANA on VMware Best Practices Resource Guide
SAP HANA on VMware Production Environments Datasheet
SAP HANA on VMware Production Support Press Release
SAP HANA on VMware vSphere 5.5 Production Scenarios – Blog Article
This announcement makes it possible for your to now fully leverage the power of both SAP HANA and VMware vSphere and gain even more business value that was ever possible before. Even though scale out deployment models are not yet supported I’m sure they will be in the future, allowing you to take HANA to even more places. But don’t let that stop you a 1TB HANA instance is up to 10TB worth of data in standard database terms. This covers a very large percentage of the SAP system population. I’d be interested to hear how you plan to deploy SAP HANA now, especially as the performance is near native, you’re not losing out anywhere.
This post appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
[…] the faster the read responses. If only you could load your entire database in memory (such as with SAP HANA and Oracle Times […]
"You can run multiple SAP HANA instances of varying sizes on a single VMware vSphere Host.
in production environments, just 1 SAP HANA VM per physical ESXi host is supported, see http://www.vmware.com/files/pdf/SAP_HANA_on_vMwar…
Thanks, I hadn't noticed that. Although you can use HANA in a VMware backed cloud and for small instances I doubt it would be one instance per server. This space will evolve rapidly and I expect we'll see scale out designs supported before too long also.
Hey Michael, what's the reason your customers want to virtualise SAP HANA? Wouldn't that cancel or at least reduce the benefits it was supposed to deliver?
Virtualizing HANA actually increases the benefits. If you virtualize it on vSphere you get near native performance while still being able to take advantage of high availability, vMotion for non-disruptive server maintenance and the ability to create new instances very quickly and on demand. You get all the benefits of HANA and all the benefits of virtualization.
But HANA is an in-memory computing platform that runs DBs in RAM only, so I'm no sure how it can benefit from high availability. What SAP is really after is something like FT, but it needs to support massive systems for which HANA was built. HANA is about performance (real-time ops and BI), while virtualisation is about savings, so near-native perfs…
I think you misunderstand virtualization. At least when it comes to virtualization of business critical apps. When virtualizing business critical apps performance and SLA's matter way more than consolidation or cost savings. It is about improving on SLA's. Also HANA relies on having persistent storage to save checkpoints and recover points for the in-memory data. This is so it can be recovered in the case of a system outage. You can effectively stripe data across multiple HANA instances for reliability and recovery also. But when you add virtualiztation you gain manageability and reliability features you wouldn't otherwise have if the system was running bare metal native configuration on the hardware, such as vMotion, such as HA. HA allows you to get back to 100% operational state much quicker than if you didn't have it. vMotion allows for non-disruptive updates and maintenance of physical servers. The additional integration with tools such as LVM, when it supports HANA, will allow for complete automation and creation and tear down, or resizing of landscapes, without having to do manual operations. The difference in performance tests between traditional queries of a BW workload taking 77 minutes is 14 seconds on HANA, and 14.91 seconds when HANA is virtualized. Would you really make a decision to not virtualize and miss out on the benefits (manageability, flexibility, reliability and availability) of that for 0.91 seconds of additional performance? How long does it take to stand up a pure physical HANA instance? A few weeks, as you have to order new hardware etc. How long does it take to stand up a new vHANA instance? A few minutes. Applications and dev/test teams can be far more productive when their systems are virtualized, including production systems. Virtualizing business critical applications is about not compromising and designing the system from the ground up to meet the requirements, including performance, and not compromising SLA's, while gaining all of the benefits of virtualization. Some cost savings are probable, but that is not the main driver, and that is a nice to have. If you're trying to virtualize critical apps only for cost savings then you're doing it wrong, and you'll likely cut corners that will end up costing you far more than any potential savings would have.