Production HANA on VMware – for the few, for now

Production HANA on VMware is in “controlled availability, allowing selected customers, depending on their scenarios and system sizes to go live with SAP HANA on VMware vSphere immediately” per SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.  However, the SAP marketing team left this small stipulation off the press release and got everyone very hot and bothered.

It sounds like everyone should be able to put their HANA system on VMware.  First, my wife, who is not in the IT world, sent me a link to the NY Times SAP and VMware Head for the Future Together and then I got about dozen copies of the Market Watch Report: SAP and VMware Announce SAP HANA® for Production Use on VMware vSphere 5.5.  Well, at least that mentioned you needed the latest version of VMware.

So for now, if you want to production HANA on VMware, the main requirements are below and included in SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.

  • Must be approved for controlled availability by SAP
  • Must be on VMware vSphere 5.5
  • Must be on SAP HANA SPS07
  • Maximum of 1 TB
  • Must be on SAP approved HANA server and storage
  • Must comply to SAP’s current recommendations for vCPU and RAM
  • Must not over-provsion the CPU nor RAM
  • Maximum of 1 Virtual Machine (VM)

In other words you need the latest and greatest version of VMware and HANA running on your HANA approved appliance in a nearly non-virtual manner.  While this is less than what we all want, it is a step in the right direction.  It will allow you to manage the HANA instance under your VMware management utilities.  It makes HANA part of your Software Defined Environmental strategy.  I’m confident that over time, as it becomes Generally Available, that production HANA will have far fewer restrictions.

I’m actually looking forward to when we can run production HANA on lots of virtualization schemes.  I look forward to more of software defined service level agreement (SLA) with SAP so that other virtualization environments including the cloud providers can provide production services. Right now it is about shipping hardware to Waldorf, DE for certification and is so specific, it is not practical even for hardware manufactures.

SAP needs to move to software defined SLA would be good for everyone including SAP by making HANA more available and take less effort to certify platforms, hardware and cloud providers who want the ability to vary the make-up of servers based on market conditions and newer evolutions of chipsets, and especially my clients who want HANA, but in but running in a completely virtual word they are defining, not the one SAP is trying to define for them.

As Vishal Sikka (former SAP CTO) exits, limited Production HANA on VMware is great first step for the product he called his child, HANA. Unlimited production HANA on VMware would be a great toddler-hood.  I really look forward to seeing it rapidly reach its teenage years and start trying to run on everything everywhere.  Isn’t that what teenagers do?

 

Advertisements

SAP HANA MCOD – What I really want for my data center

The real SAP game changer will be when I have one (1) HANA DB for all my production applications.  I want single, giant in-memory DB where my ECC, BW, CRM, PLM, SCM, BOBJ, etc. all consume the same data.  I want a row  view for the OLTP ECC-like applications and column view for OLAP BW-like applications.  It would look like the picture below.

sap hana mcod system
What we really need from SAP! The SAP HANA MCOD system.

Right now, I can’t really recommend using HANA on anything but OLAP based applications.  In the future, when we can do the analytic transformations in memory without silly exports, extractors, DSO’s and the like, we will really have a very* different scenario.  For now, the cost of the HANA license and risk of losing transactions only committed to memory is not justifiable.

In this new vision with MCOD, there will be two (2) key issues.  First, how do we support MCOD.  I’ve seen MCOD come and go since 1993 several times. Each time, it was easy to build and impossible to support.  The overlapping requirements became overwhelming. Second, HANA will need a data aging architecture which can age data out of main memory to some slightly slower memory or device.

IBM is working on some important technology, Phase Change Memory, that will be of great value (http://www.zurich.ibm.com/sto/memory/).   It may provide the near DRAM speeds while being cost effective and non-volatile.  Maybe IBM will build out series of servers specifically designed to run in-memory databases such as HANA with massive DRAM and massive PCM capacities.  PCM could then provide the roll-back logs and more at near DRAM speeds. PCM won’t solve the MCOD and data aging problems, but at least the risk of running rapidly transacting OLTP systems would go to near zero and certainly lower than that of even today’s highly cached disk writing databases.

It is going to be a fun watching HANA make it from infancy to toddler-hood.  I wonder how fast she’ll mature.

* Mark Twain said every time a writer was tempted to use “very” in a sentence, they should use the word “damn” and then the editor would strike the word and the sentence would read as it should.