As the article mentions, it seems odd that if you are paying a tremendous cost for HANA performance, you would want to run it on a VMware VM and take the performance hit. Yeah, maybe it isn't a huge performance hit, but the entire idea of HANA is that Oracle, DB2, etc will just not work because you have a workload that requires insanely high performance/low latency. HANA doesn't seem to be the sort of application you are going to run on a "good enough" OS/VM stack... especially when the only benefit is that it may save you an x86 server... which is less than the tax on HANA.
VMware and SAP have partnered to let a virtualized breed of the in-memory data muncher HANA run on customer-owned hardware as well as in the public cloud. The deal was announced by the two companies on Monday, and means that companies running vSphere 5.5 have another way to access SAP's in-memory data fiddler. When running on …
Tuesday 6th May 2014 17:30 GMT PowerMan@thinksis
Let's see some benchmarks
It's easy to say "Look what we have". Show some benchmarks. Run two systems side by side. One with Hana and no VMware and another with VMware and let's see how they compare. Further, what is the benefit of adding the cost and performance penalty of VMware? To use VMotion? Should be interesting to watch it try to move 1 TB of "in-memory" data.
I think customers are better off running their SAP environments using AIX on Power8 with DB2 10.5 with BLU Acceleration. They can virtualize everything, get the reliability and scalability and with Power8 they can get 2X the performance over x86 not to mention what DB2 BLU can do....wow - the compression, speed and the fact you don't have to buy huge memory machines to do it all. Last report I saw comparing DB2 vs Hana showed it was quite a bit less expensive as well.
Tuesday 6th May 2014 21:28 GMT Anonymous Coward
Re: Let's see some benchmarks
Agree, DB2 Blu would provide similar performance, probably almost exactly the same, to HANA at a lower cost.
HANA has no advantage for OLTP as you need to store writes on some persistent state storage with the standard write latency. Everyone has a read cache option on their DB and all in-memory for OLAP, which is all read data.
Tuesday 6th May 2014 18:51 GMT Anonymous Coward
I think the performance impact is probably less than 5%, which is well worth it when it comes to the benifits of managing the database as a VM, for some customers anyway.
Vmotion for example, I have seen a time trial using a 10gb nic and it is speedy to say the least... Vmotion completed in under 3 mins.
Disclaimer: i work for VMware... Double disclaimer, I have not run the trials myself, but this is from speaking with colleagues
Tuesday 6th May 2014 21:40 GMT Anonymous Coward
Re: Trade off
5% would have to be a very well tuned environment. The point is that if you are going to spend a huge amount on HANA software, you can probably afford to run bare metal. It is not like anyone is going to virtualize a HANA server and then put some NFS share on the same machine.
I don't know what sort of tools HANA comes with, but you don't really need VM level function for most DBs. You almost never see an Oracle DB, for instance, running on a VM... unless you include the bare metal hypervisors like PowerVM which is common. Part of that is a cost and support issue (Oracle considers VMware a soft partition), but it is also because Oracle has Data Guard, RAC, etc which supplant the VMware tools. Most HANA installs use IBM's GPFS and cluster the servers anyway, so no need motion stuff around.
Tuesday 6th May 2014 22:40 GMT Anonymous Coward
Re: Trade off
5% is easily achievable. It's not about money. It's about agility.
e.g. vMotion allows you to move to a different (bigger, better, smaller, fixed, etc.) underlying HW platform without downtime; Then you can spin up, snap, try and upgrade, roll-back, etc. instances without issue; etc. etc.
As for Oracle DBs being virtualised ... it's actually quite common now.
It's fully supported. Period.
Licensing is not an issue - even if you do choose to use DRS affinity rules over a dedicated cluster where there's no doubt. Go read the agreements properly and not Oracle FUD.
Dataguard and RAC (also supported!) are both complicated, expensive and often just not needed.
Thus, for those that don't need all the expensive bells and whistles (let's be honest, average resource utilisation across the estate will be 10-20%), it is now trivial to consolidate many Oracle DBs and save large of money on licensing.
(anon because I virtualise SAP and Oracle for large enterprise customers)
Wednesday 7th May 2014 02:04 GMT PowerMan@thinksis
Re: Trade off
vMotion from a Dell to a Cisco then? How about from a Westmere to a Ivy Bridge EX based server? How many vCPU's do you have in this 1 TB VM by the way? With just 2 HT how does that scale? I'm not trying to pick but just point out that just because it works in a lab doesn't mean it will work in a customer environment under load using a shared network. By the way, these features I describe do scale and do work with Power8 and PowerVM from min to max of it's capabilities.
With regard to your statement about "Licensing is not an issue". Licensing is always an issue on x86.The server are bigger because Intel creates bigger chips that are weaker per core but greater by their overall sum than the previous sum of the socket. Looks like a win but when a lot of software is priced by core like Oracle, it very much matters. Oracle DOES NOT acknowledge VMware for sub-capacity licensing purposes. You cannot turn off cores and you must license all cores in the server times .5 (ie 1/2). 60 core Ivy Bridge is 30 Oracle licenses even if running at 20% utilization with or without VMware. At $47,500 per core times 30 cores I would argue that licensing very much matters. You make the point for why businesses should consolidate x86 workloads onto servers like Power8....I wish I could also say Itanium and SPARC but I just don't see their technology keeping pace despite the claims. Would your employer accept you working at 20% utilization? Then why accept it for the servers? Take 5 of those 20% servers and consolidate onto a single server...better yet, take 10 or 20 of them because like rocks, pebbles and sand fill up a jar so do more workloads fit onto a (Power) processor and it's scheduler to drive more efficiency.
Wednesday 7th May 2014 08:45 GMT Anonymous Coward
Re: Trade off
Regarding SAP virtualisation...
Where appropriate, you can vMotion between processor types using EVC. It's not always appropriate. It's a balance between power and agility. In fact, in most cases, software is a couple of years behind the latest and greatest chipset specifics, so EVC makes next to no difference - quite surprising for us techies!
And vMotion was just one example of why to virtualise HANA, so let's not focus on that.
Maybe surprisingly to us technical types, users often prioritise agility over power and flashing lights. :-)
SAP publish their T-shirt sizes for what they regard as a good balance between CPU and memory. Same applies to virtualised boxes, although you can better monitor if you have the balance right.
And totally agree about your comment about "just because it works in the lab". These things should be done for business benefit, not to augment the technical team's CVs.
Regarding Oracle licensing...
You must licence all sockets in a physical machine, yes. No problem with that part of the OLSA.
You need NOT license all servers in a cluster however - as some dubious reps claim. That's clearly NOT in the OLSA.
I'll let others do the maths, but customers are using this to their advantage today.
The Power architecture is great, but it's not for everyone. It's usually not just a technical decision either. (Hell, Itanium was "technically" better in many ways, but look what happened there!)
x86 consolidation of Oracle DB is proving very popular in the enterprise space and for good reason.
But yes, consolidation is the key way to save money here on Power or x86. However, all the extras like HA for free and for all, "throwing away expensive clustering because your SLAs don't require it and HA is good enough", DRS, agility, better monitoring, etc. well, they are tipping the balance to x86 virtualisation for many.
Regarding Oracle support...
The requirement to reproduce on HW is no more onerous that the requirement to reproduce on IBM tin instead of Dell tin, or even MS SQL's and other's same requirements. That's totally fair. As a software vendor I'd not want to get 'trapped' in a support situation when it's down to some obscure hardware timing issue in a NIC causing a DB machine to crash (true story).
This is just Oracle rep's loudly proclaimed worry mongering to try and stop their license revenue (aka. commission) being eaten away.
Oracle FULLY support their databases on a VMware platform - even RAC. Period.
I'm not out to get everyone to virtualise all their HANA and Oracle workloads. I just want to pull down a few artificial barriers that Oracle (and others with entrenched views) put in their way. Then people (usually enterprises) can make their own fact based decision on whether they want to virtualise or not. In my experience, most do want to.
Next we'll get talking about how people really starting to push their SAP workloads into the cloud - that'll get you all talking!! :-)
Wednesday 7th May 2014 18:51 GMT Anonymous Coward
Re: Trade off
"Oracle FULLY support their databases on a VMware platform - even RAC. Period."
The official Oracle support statement:
"Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required."
Wednesday 7th May 2014 23:12 GMT Anonymous Coward
Re: Trade off
I can assure you that they do support it and this is just flannel.
They do not certify VMware as a platform. Neither do they certify Dell. Or HP. Or IBM.
But don't take my (unfortunately anonymous) word for it, go ask the big names on the block what they're doing. I obviously cannot mention names here, but a large proportion of enterprise customer (read "those that can and do stand up to Oracle's FUD") have virtualised some of their development Oracle DBs and many are virtualising some of their production estate.
But **only where appropriate**.
An older interesting blog post interpreting all the official statements is here:
Or an official Oracle video here maybe?
By all means do not virtualise Oracle DBs or SAP instances, but please please do not not do it because you're bullied into it by a company protecting their revenue stream.
Thursday 8th May 2014 02:32 GMT Anonymous Coward
Re: Trade off
"go ask the big names on the block what they're doing."
I know the big names with hundreds of Oracle core factors. The most common platform for super large Oracle DB shops is IBM pSeries (AIX). Some are running on Exadata. Some are running on bare metal x86 clusters. Very few mega Oracle DB workloads are running on VMware. The giant shops have very strict governance rules. They are not putting production DBs on a stack that is sort of supported.
"By all means do not virtualise Oracle DBs or SAP instances, but please please do not not do it because you're bullied into it by a company protecting their revenue stream."
I don't think this is a case of Oracle protecting revenue streams. It is ridic expensive to run Oracle DB on VMware because Oracle doesn't support sub-capacity or hard partition. They officially don't recognize VMware at all. Every core needs to be licensed whether it is being used or not. I think Oracle's issue is that VMware does not support truly isolated, electrically isolated partitions. This is different from Power-AIX/PowerVM where the LPARs are done at the firmware level. As such, Oracle supports sub-capacity licensing for Power-AIX because they know that if you are running Oracle on 12 cores of a 64 core machine, only 12 cores are being used. Soft vs hard partition.
"Or an official Oracle video here maybe?"
Again, official VMware video, nothing official from Oracle. The video illustrates another issue with licensing Oracle on VMware. You not only have to license every core on the machine, but you also have to license all VMotion connected servers. In a case where you are running Oracle on 12 cores in a 32 core machine which is VMotion connected to another 32 core machine, you are paying for 64 cores of Oracle licensing. This says nothing about support, just licensing. It is still that case that you must duplicate the problem on the base OS before Oracle engages unless it is a known issue on a supported base OS.
Wednesday 7th May 2014 19:03 GMT Anonymous Coward
Wednesday 7th May 2014 03:02 GMT Anonymous Coward
Re: Trade off
"It's fully supported. Period."
Fully supported by VMware, yes. Fully supported by Oracle, no. If you have an issue, you need to demonstrate to Oracle that it could not possibly be a VMware issue... i.e. take it off of VMware and duplicate the issue on bare metal or Oracle VM. I'm not saying that is fair, but it is not supported by Oracle. IBM PowerVM, IBM zVM, OracleVM, and Solaris are the only fully supported VMs for Oracle DB.... Also, as mentioned below, Oracle only recognizes VMware as a soft partition so you cannot do sub-capacity licensing. You must license every core on the server, which eliminates the major point of virtualizing.
The majority of HANA implementation use IBM's GPFS clustering file system.... similar to the way Google, fb, Amazon, etc run their implementations. Much more effective than motioning servers. VMotion is effective if you have a planned outage, but does nothing for you in the case of an unplanned outage. Clustering protects against both and allows you to use the power of parallel processing.