Michael Stone (@), Lead Architect and CIO
More and more companies are coming to understand that licensing costs for commercial products, such as Oracle, usually dwarf the cost of all other components of the stack combined. For instance, a late generation X86 server might have a fully loaded cost of $35K – $50K over a five-year lifespan. Whereas licensing Oracle core technology on that server could easily exceed $2M for the same period (or 40x the hardware cost).
Once we recognize this large disparity in expenditure, our choice of hardware becomes about maximizing the very costly investment in software licensing, and the evaluation of options across vendors and platforms becomes even more critical.
In the absence of real world comparison of any given application, we have to use industry standard benchmarks to approximate the relative performance of our candidate hardware choices. Because performance of a well-tuned database boils down to throughput, the gold standard we use at House of Brick for database applications is the SPECint_rate. We have found that this number allows for reasonable comparisons and translates well to real-world application.
Finally, other than the core-factor table, licensing Oracle on different platforms is identical from a contractual standpoint. One must account for licensing all processor cores where Oracle is installed and/or running. However, there is a fair amount of subtlety, false assertions, misinformation, and misunderstanding in the community, which we refer to collectively as FUD (fear, uncertainty and doubt). But at the end of the day, it is a simple calculation.
“Partitioning” is one of the first terms you will hear when you start delving into the FUD. It is a term that Oracle has adopted to describe the subdivision of processors within a server for licensing purposes. People are often surprised to learn that there is no mention of partitioning in any contractual document that describes their license agreement with Oracle. This means partitioning has no legal bearing on the licensing requirement – for any supported platform.
For decades, the IBM LPAR has enjoyed a privilege that Oracle voluntarily extended in the (non-contractual) Partitioning Policy Document, whereby customers are allowed to consider only those processors assigned to an LPAR for licensing purposes, regardless of where the Oracle software actually runs within the larger frame. Oracle calls this “hard partitioning” and explicitly acknowledges the IBM LPAR for such consideration. Recently however, Oracle has attempted to restrict that privilege, so it will be important for the IBM community to join the discussion that has been ongoing in the x86 community for years now.
Many platforms, including VMware and IBM (as well as most base operating systems), have the ability to control which processors a particular workload may run on. It is HoB’s assertion, that regardless of Oracle’s statements to the contrary, any type of “partitioning” that can limit (in an auditable fashion) where Oracle software is installed and/or running is valid for license considerations. Refer to our blog, Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right, for further details.
NOTE: At the current time, vSphere / VM CPU Affinity has operational limitations that may or may not be acceptable in your application. However, compliance with Oracle’s attempt to restrict the LPAR privilege may or may not be acceptable either.
Now that we understand the fact that “partitioning” (as defined by Oracle) has no bearing on the calculations, let’s look at the comparison.
Historically, we have used real-world results as well as SPEC results to establish that it was valid to compare X86 with POWER on a core-for-core basis without regard for Hyper-Threading (HT) or Symmetric Multi Processing (SMT). This held true through the POWER 7 line of processors, meaning that one X86 core was equivalent to one POWER core when it came to database performance and throughput. The discrepancy comes into play when we look at Oracle’s core-factor table, as it is immediately obvious that POWER is calculated at 1.0, while x86 enjoys a 0.5 multiplier.
Taking into account the core-factor, means that prior to POWER 8, licensing Oracle on X86 was half the price of POWER for comparable performance.
With the advent of POWER 8 and 8-way SMT, along with blazingly fast clock speeds, IBM has picked up an incremental performance advantage over the latest generation of X86 chips (at least for now).
In order to compare apples to apples, let’s look at two similar processor models and their associated (Per Core) SPECint_rate numbers:
According to this chart, the X86 processor core only offers 85% of the throughput of the POWER 8 core. But, keep in mind that it does so at half the license cost.
An astute reader may realize that IBM offers processor speeds in excess of 4GHz, and that this benchmark is all about throughput. Since partitioning doesn’t matter, and hardware cost pales in the face of licensing, the following chart must be considered as well:
We can see at the extreme that the X86 processor now only offers 75% of the throughput of the POWER 8 chip. But again, it does so at half the license cost. So I still get 50% more bang for my very costly Oracle licensing buck on x86.
Oracle runs equally well on both platforms and partitioning is a contractual right, so we can simply compare the relative advantages on a core-for-core basis.
- More choices for core counts and speeds
- Numerous good choices of vendors keep hardware prices competitive
- Easier to balance licensing goals with hardware acquisition costs
- 50% (or better) license cost advantage for comparable database performance / throughput
- Linux is a Tier 1 platform for Oracle support
- Core counts tend to drop off with increased clock speed
- Scales bigger, stronger, faster at the extremes
- LPARs are easier to work with than x86 “partitioning” methods
- Greater density and throughput – a lot of cores with blazing fast clock speeds
- While AIX is a primary platform, Linux on POWER has a low adoption rate with questionable support from Oracle
- Fewer choices of core counts and speeds
- Harder to balance licensing goals with hardware acquisition costs