An ongoing discussion about SAP infrastructure

Support for HANA on Power with RedHat is finally here!!

SAP made a very exciting announcement this past Friday.  While it took a bit longer than expected, support for RHEL 7.3 with HANA on Power was announced by SAP in their usual overwhelming manner, i.e. they updated a SAP note:   SAP HANA 2235581: Supported Operating Systems.  RHEL is only supported on Power in Little Endian mode, i.e. only works with HANA 2.0.  This support is incredibly important for customers that have established RHEL as their standard for Linux and were either reluctant to introduce a different Linux distribution or were outright forbidden to by their corporate standards.  Taken together with the TDI Phase 5 SAPS based sizing announcement, yet another element that was inhibiting the already explosive growth of HANA on Power was removed.  I described that announcement as allowing the use of 5th gear after being limited to only 4.  Taking this metaphor a step further, RHEL support is like disengaging the parking brake.  I should mention that IBM does not develop a Linux variant of their own nor do they endorse any particular variety.  As such, I will not suggest any advantage of running RHEL or SLES for HANA and recommend, if a company has no firm policy either way, that you ask each distro partner to explain why they think theirs is better for HANA than the other.  At this time, both are supported only with PowerVM on Power Systems and with the exact same limits and multi-tenant/multi-VM flexibility.


October 9, 2017 Posted by | Uncategorized | , , , , , , , , | 4 Comments

Lintel for SAP App Servers – The right choice

Or is it? Running SAP application servers on IBM Power Systems with Linux results in a lower TCA than using x86 systems with Linux and VMware. Usually, I don’t start a blog post with the conclusion, but was so amazed by the results of this analysis, that I could not help myself.

For several years now, I have seen many customers move older legacy app servers to x86 systems using Linux and VMware as well as implementing new SAP app servers on the same. When asked why, the answers boil down to cost, skills and standards. Historically, Lintel servers were not just perceived to cost less, but could the cost differences could be easily demonstrated. Students emerging from colleges have worked with Linux far more often than with UNIX and despite the fact that learning UNIX and how it is implemented in actual production environments is very little different in real effort/cost, the perception of Linux skills being more plentiful and consequently less expensive persists. Many companies and government entities have decided to standardize on Linux. For some legacy IBM Power Systems customers, a complicating factor, or perhaps a compelling factor in the analysis, has compared partitions on large enterprise class systems against low cost 2-socket x86 servers. And so, increasingly, enterprises have defaulted to Lintel as the app server of choice.

Something has changed however and is completely overturning the conventional wisdom discussed above. There is a new technology which takes advantage of all of those Linux skills on the market, obeys the Linux standards mandate and costs less than virtualized Lintel systems. What is this amazing new technology? Surprise, it is a descendent of the technology introduced in 1990 by IBM called the RS/6000, with new Linux only POWER8 systems. (OK, since you know that I am an IBM Power guy and I gave away the conclusion at the start of this post, that was probably not much of a surprise.) At least, this is what the marketing guys have been telling us and they have some impressive consultant studies and internal analyses that back up their claims.

For those of you who have been following this blog for a while, you know that I am skeptical of consultant analyses and even more so of internal analyses. So, instead of depending on those, I set out to prove, or disprove, this assertion. The journey began with setting reasonable assumptions. Actually, I went a little overboard and gave every benefit of the doubt to x86 and did the opposite for Power.

Overhead – The pundits, both internal and external, seem to suggest that 10% or more overhead for VMware is reasonable. Even VMware’s best practices guide for HANA suggests an overhead of 10%. However, I have heard some customers claim that 5% is possible. So, I decided to use the most favorable number and settled on 5% overhead. PowerVM does have overhead, but it is already baked into all benchmarks and sizings since it is built into the embedded hypervisor, i.e. it is there even when you are running a single virtual machine on a system.

Utilization – Many experts have suggested that average utilization of VMware systems range in the 20% to 30% range. I found at least one analyst that said that the best run shops can drive their VMware systems up to 45%. I selected 45%, once again since I want to give all of the benefit of the doubt to Lintel systems. By comparison, many experts suggest that 85% utilization is reasonable for PowerVM based systems, but I selected 75% simply to not give any of the benefit of the doubt to Power that I was giving to x86.

SAPS – Since we are talking about SAP app servers, it is logical to use SAP benchmarks. The best result that I could find for a 2 socket Linux Intel Haswell-EP system was posted by Dell @ 90,120 SAPS (1). A similar 2-socket server from IBM was posted @ 115,870 SAPS (2).

IBM has internal sizing tables, as does every vendor, in which it estimates the SAPS capacity of different servers based on different OSs. One of those servers, the Power S822L, a 20-core Linux only system, is estimated to be able to attain roughly 35% less SAPS than the benchmark result for its slightly larger cousin running AIX, but this takes into consideration differences in MHz, number of cores and small differences due to the compilers used for SAP Linux binaries.

For our hypothetical comparison, let us assume that a customer needs approximately the SAPS capacity as can be attained with three Lintel systems running VMware including the 5% overhead mentioned above, a sustained utilization of 45% and 256GB per server. Extrapolating the IBM numbers, including no additional PowerVM overhead and a sustained utilization of 75%, results in a requirement of two S822L systems each with 386GB.

Lenovo, HP and Dell all offer easy to use configurators on the web. I ran through the same configuration for each: 2 @ Intel Xeon Processor E5-2699 v3 18C 2.3GHz 45MB Cache 2133MHz 145W, 16 @ 16GB x4 DIMMS, 1 @ Dual-port 10GB Base-T Ethernet adapter, 2 @ 300GB 10K RPM disk (2 @ 1TB 7200 RPM for Dell) and 24x7x4 hour 3-year warranty upgrades (3). Both the Lenovo and HP sites show an almost identical number for RedHat Enterprise Linux with unlimited guests (Dell’s was harder to decipher since they apply discounts to the prices shown), so for consistency, I used the same price for RHEL including 3-yr premium subscription and support. VMware also offers their list prices on the web and the same numbers were used for each system, i.e. Version 5.5, 2-socket, premium support, 3yr (4).

The configuration for the S822L was created using IBM’s eConfig tool: 2 @ 10-core 3.42 GHz POWER8 Processor Card, 12 @ 32GB x4 DIMMS, 1 @ Dual-port 10GB Base-T Ethernet adapter, 2 @ 300GB 10K RPM disk and a 24x7x4 hour 3-year warranty upgrade, RHEL with unlimited guests and 3yr premium subscription and support and PowerVM with unlimited guests, 3yr 24×7 support (SWMA). Quick disclaimer; I am not a configuration expert with IBM’s products much less those from other companies which means there may be small errors, so don’t hold me to these numbers as being exact. In fact, if anyone with more expertise would like to comment on this post and provide more accurate numbers, I would appreciate that. You will see, however, that all three x86 systems fell in the same basic range, so small errors are likely of limited consequence.

The best list price among the Lintel vendors came in at $24,783 including the warranty upgrade. RHEL 7 came in at $9,259 and VMware @ $9,356 with a grand total for of $43,398 and for 3 systems, $130,194. For the IBM Power System, the hardware list was $33,136 including the warranty upgrade, PowerVM for Linux $10,450 and RHEL 7 $6,895 for a grand total of $51,109 and for 2 systems, $102,218.

So, for equivalent effective SAPS capacity, Lintel systems cost around $130K vs. $102K for Power … and this is before we consider the reliability and security advantages not to mention scalability, peak workload handling characteristics, reduced footprint, power and cooling. Just to meet the list price of the Power System, the Lintel vendors would have to deliver a minimum of 22% discount including RHEL and VMware.

For customers making HANA decisions, it is important to note that the app server does not go away and SAP fully support heterogeneous configurations, i.e. it does not matter if the app server is on a different platform or even a different OS than the HANA DB server. This means that Linux based Power Boxes are the perfect companion to HANA DB servers regardless of vendor.

For customers that are refreshing older Power app servers, the comparisons can be a little more complicated in that there is a reasonable case to be made for running app servers on enterprise class systems potentially also housing database servers in terms of higher effective utilization, higher reliability, the ability to run app servers in an IFL (Integrated Facility for Linux) at very attractive prices, increased efficiencies and improved speeds through use of virtual Ethernet for app to DB communications. That said, any analysis should start with like for like, e.g. two socket scale-out Linux servers, and then consider any additional value that can be gained through the use of AIX (with active memory expansion) and/or enterprise class servers with or without IFLs. As such, this post makes a clear point that, in a worst case scenario, scale-out Linux only Power Systems are less expensive than x86. In a best case scenario, the TCO, reliability and security advantages of enterprise class Power Systems make the value proposition of IBM Power even more compelling.

For customers that have already made the move to Lintel, the message is clear. You moved for sound economic, skills and standards based reasons. When it is time to refresh your app servers or add additional ones for growth or other purposes, those same reasons should drive you to make a decision to utilize IBM Power Systems for your app servers. Any customer that wishes to pursue such an option is welcome to contact me, your local IBM rep or an IBM business partner.

1. Dell PowerEdge R730 – 2 Processors / 36 Cores / 72 Threads 16,500 users, Red Hat Enterprise Linux 7, SAP ASE 16, SAP enhancement package 5 for SAP ERP 6.0, Intel Xeon Processor E5-2699 v3, 2.3 Ghz, 262,144MB, Cert # 2014033, 9/10/2014

2. IBM Power System S824, 4 Processors / 24 Cores / 192 Threads, 21,212 Users, AIX 7.1, DB2 10.5, SAP enhancement package 5 for SAP ERP 6.0, POWER8, 3.52 Ghz, 524,288MB, Cert # 2014016, 4/28/2014



January 23, 2015 Posted by | Uncategorized | , , , , , , , , , , , , | 4 Comments

High end Power Systems customers have a new option for SAP app servers that is dramatically less expensive than x86 Linux solutions

Up until recently, if you were expanding the use of your SAP infrastructure or have some older Power Systems that you were considering replacing with x86 Linux systems, I could give you a TCO argument that showed how you could see roughly equivalent TCO using lower end Power Servers.  Of course, some people might not buy into all of the assumptions or might state that Linux was their new standard such that AIX was no longer an acceptable option.  Recently, IBM made an announcement which has changed the landscape so dramatically that you can now obtain the needed capacity using high end server “dark cores” with Linux, not at an equivalent TCO, but at a dramatically lower TCA.

The new offering is called IFL which stands for Integrated Facility for Linux.  This concept originated with System Z (aka mainframe) several years ago.  It allows customers that have existing Power 770, 780 or 795 servers with capacity on demand “dark cores”, i.e. for which no workload currently runs and the license to use the hardware, virtualization and OS software have not been activated, to turn on a group of cores and memory specifically to be used for Linux only workloads.  A Power IFL is composed of 4 cores with 32GB of memory and has a list price of $8,591.

In the announcement materials provided by IBM Marketing, an example is provided of a customer that would need to add the equivalent of 16 cores @ 80% utilization and 128GB of memory to an existing Power 780 4.4GHz system or would need the equivalent capacity using a 32-core HP DL560 2.7GHz system running at 60% utilization.  They used SPECint_rate as the basis of this comparison.  Including 3 year license for PowerVM, Linux subscription and support, 24×7 hardware maintenance and the above mentioned Power activations, the estimated street price would be approximately $39,100.  By comparison, the above HP system plus Linux subscription and support, VMware vSphere and 24×7 hardware maintenance would come in at an estimated street price of approximately $55,200.

Already sounds like a good deal, but I am a skeptic, so I needed to run the numbers myself.  I find SPECint_rate to be a good indicator of performance for almost no workloads and an incredibly terrible indicator of performance for SAP workloads.  So, I took a different approach.  I found a set of data from an existing SAP customer of IBM which I then used to extrapolate capacity requirements.  I selected the workloads necessary to drive 16 cores of a Power 780 3.8GHz system @ 85% utilization.  Why 85%?  Because we, and independent sources such as Solitaire Interglobal, have data from many large customers that report routinely driving their Power Systems to a sustained utilization of 85% or higher.  I then took those exact same workloads and modeled them onto x86 servers assuming that they would be virtualized using VMware.  Once again, Solitaire Interglobal reports that almost no customers are able to drive a sustained utilization of 45% in this environment and that 35% would be more typical, but I chose a target utilization of 55% instead to make this as optimistic for the x86 servers as possible.  I also applied only a 10% VMware overhead factor although many sources say that is also optimistic.  It took almost 6 systems with each hosting about 3 partitions to handle the same workload as the above 16-core IFL pool did.

Once again, I was concerned that some of you might be even more optimistic about VMware, so I reran the model using a 65% target utilization (completely unattainable in my mind, but I wanted to work out the ultimate, all stars aligned, best admins on the planet, tons of time to tune systems, scenario) and 5% VMware overhead (I don’t know anyone that believes VMware overhead to be this low).  With each system hosting 3 to 4 partitions, I was able to fit the workloads on 5 systems.  If we just go crazy with unrealistic assumptions, I am sure there is a way that you could imagine these workloads fitting onto 4 systems.

Next, I wanted to determine the accurate price for those x86 systems.  I used HP’s handy on-line ordering web site to price some systems.  Instead of the DL560 that IBM Marketing used, I chose the DL360e Gen8 system, with 2@8-core 1.8GHz processors, 64GB of memory, a pair of 7200rpm 500GB hard drives, VMware Enterprise for 2 processors with 3 yr subscription, RH Enterprise Linux 2 socket/4 guest with 3 yr subscription, 3yr 24×7  ProCare Service and HP installation services.  The total price comes to $27,871 which after an estimated discount of 25% on everything (probably not realistic), results in a street price of $20,903.

Let’s do the math.  Depending on which x86 scenario you believe is reasonable, it either takes 6 systems at a cost of $125,419, 5 systems @ $104,515 or 4 systems @ $83,612 to handle the same load as a 4 IFL/16-core pool of partitions on a 780 at a cost of $39,100.  So, in the most optimistic case for x86, you would still have to pay $44,512 more.  It does not take a rocket scientist to realize that using Power IFLs would result in a far less expensive solution with far better reliability and flexibility characteristics not to mention better performance since communication to/from the DB servers would utilize the radically faster backplane instead of an external TCP/IP network.

But wait, you say.  There is a better solution.  You could use bigger x86 systems with more partitions on each one.  You are correct.  Thanks for bringing that up.  Turns out, just as with Power Systems, if you put more partitions on each VMware system, the aggregate peaks never add up to the sum of the individual peaks.  Using 32-core, DL560s @ 2.2GHz, 5% VMware overhead and 65% target utilization, you would only need 2 systems.  I priced them on the HP web site with RH Linux 4 socket/unlimited guests 3yr subscription, VMware Enterprise 4 socket/3yr, 24×7 ProCare and HP installation service and found the price to be $70,626 per system, i.e. $141,252 for two systems, $105,939 after the same, perhaps unattainable 25% discount.  Clearly, 2 systems are more elegant than 4 to 6, but still, this solution is still $66,839 more expensive than the IFL solution.

I started off to try and prove that IBM Marketing was being overly optimistic and ended up realizing that they were highly conservative.  The business case for using IFLs for SAP app servers on an existing IBM high end system with unutilized dark cores compared to net new VMware/Linux/x86 systems is overwhelming.  As many customers have decided to utilize high end Power servers for DB due to their reliability, security, flexibility and performance characteristics, the introduction of IFLs for app servers is almost a no-brainer.






Configuration details:

HP ProLiant DL360e Gen8 8 SFF Configure-to-order Server – (Energy Star)661189-ESC $11,435.00

HP ProLiant DL360e Gen8 Server
HP DL360e Gen8 Intel® Xeon® E5-2450L (1.8GHz/8-core/20MB/70W) Processor FIO Kit x 2
HP 32GB (4x8GB) Dual Rank x4 PC3L-10600 (DDR3-1333) Reg CAS-9 LP Memory Kit x 2
HP Integrated Lights Out 4 (iLO 4) Management Engine
HP Embedded B120i SATA Controller
HP 8-Bay Small Form Factor Drive Cage
HP Gen8 CPU1 Riser Kit with SAS Kit + SAS License Kit
HP 500GB 6G SATA 7.2K rpm SFF (2.5-inch) SC Midline 1yr Warranty Hard Drive x 2
HP 460W Common Slot Platinum Plus Hot Plug Power Supply
HP 1U Small Form Factor Ball Bearing Gen8 Rail Kit
3-Year Limited Warranty Included

3yr, 24×7 4hr ProCare Service $1,300.00

HP Install HP ProLiant $225.00

Red Hat Enterprise Linux 2 Sockets 4 Guest 3 Year Subscription 24×7 Support No Media Lic E-LTU $5,555.00

VMware vSphere Enterprise 1 Processor 3 yr software $4,678.00 x 2 = $9,356.00

DL360e Total price $27,871.00


ProLiant DL560 Gen8 Configure-to-order Server (Energy Star) 686792-ESC    $29,364.00

HP ProLiant DL560 Gen8 Configure-to-order Server
HP DL560 Gen8 Intel® Xeon® E5-4620 (2.2GHz/8-core/16MB/95W) Processor FIO Kit
HP DL560 Gen8 Intel® Xeon® E5-4620 (2.2GHz/8-core/16MB/95W) Processor Kit x3
HP 16GB (2x8GB) Dual Rank x4 PC3L-10600 (DDR3-1333) Reg CAS-9 LP Memory Kit x 4
ENERGY STAR® qualified model
HP Embedded Smart Array P420i/2GB FBWC Controller
HP 500GB 6G SAS 7.2K rpm SFF (2.5-inch) SC Midline 1yr Warranty Hard Drive x 2
HP iLO Management Engine(iLO 4)
3 years parts, labor and onsite service (3/3/3) standard warranty. Certain restrictions and exclusions apply.

HP 3y 4h 24×7 ProCare Service   $3,536.00

Red Hat Enterprise Linux 4 Sockets Unlimited Guest 3 Yr Subscription 24×7 Support No Media Lic E-LTU     $18,519.00

VMware vSphere Enterprise 1 Processor 3 yr software $4,678.00 x 4 = $18,712.00

HP Install DL560 Service   $495.00

DL560 Total price:   $70,626.00

October 21, 2013 Posted by | Uncategorized | , , , , , , , , , | Leave a comment

ERP Platform Selection – An analysis of Gartner Group’s presentation

Recently, a document from The Gartner Group found its way across my desk.  This document was written by Philip Dawson and Donald Feinburg and was called: “Virtualizing SAP and Oracle: ERP Optimization”.  The document seemingly has a single point; everything except x86 is dead so all new implementations should go on x86 and almost everything else should be migrated to x86 when possible.   Not only is this conclusion short sighted and oblivious to the requirements of large SAP implementations, but we should remember that this is the same company that proclaimed the mainframe dead about 20 years ago, a fact that is as incorrect today as it was back then.

First, the argument that Gartner did not make and is strangely absent but, I think, most customers have as their number #1 criteria: TCO.   Actually, they did in a backhanded sort of way, but in support of legacy UNIX systems and only for tier 2 ERP instances.  I have worked directly with hundreds of SAP and Oracle customers.  While a delight to work with one without financial constraints, these are few and far in between.  Most customers must find ways to save money.  A complex ERP landscape requires a wide array of systems/partitions, high availability, DR, backup/recovery, storage devices, etc.  Companies like International Technology Group (ITG) found that when TCO is analyzed, landscapes based on IBM Power Systems are less expensive than x86:  Solitaire Interglobal Ltd analyzed TCO and many other factors without limiting their analysis to ERP systems and came up with a similar conclusion:  I have put together many landscape comparisons for SAP and have also been able to show the same effect when considering the support that is required for mission critical environments, the cost of enterprise level virtualization technologies and the cost of high availability software with all being supported for a minimum of 3 years with 24×7 by 4 hour maintenance.

All by itself, a consultant’s report which purports to help customers choose their ERP platforms but does not take this vital issue into consideration is questionable at best.  That said, allow me to take a few of the arguments they did make in the document and explain where each falls short.

Argument #1 – “ISVs focus new application functionality first on x86 Tier 1 ports. Largest installed base. – Invest!”  At least in the case of SAP, with the exception of HANA, new functionality is available on all Tier 1 platforms simultaneously, not first on x86.  AIX is considered a Tier 1 platform and shares in this “first” port.  Oracle understandably supports its OSs first, i.e. Linux and Solaris, but actually ports to AIX and other Tier 1 platforms during the same development process and simply limits other OS availability for marketing purposes.  Second point; Gartner, as a company, certainly has the experience that apparently these two, either naive or misinformed, individuals don’t, i.e. that number of installs does not equate to size of the install base.   A Fortune 100 company may have 1,000 or more times the number of SAP users and hundreds of thousands more employees compared to a small customer, but the number of installed copies of an ISV’s software may be exactly the same.  Install base is far more relevant when one considers the % of revenue/profit derived from a type of platform than number of CDs cut.  I know of a few food manufacturers that have thousands of retail customers, but sell the vast majority of their products through “just” Walmart and a few other mega retailers.  By the authors’ logic, they should abandon the mega retailers as the “largest install base” as a count of individual companies they deal with lies in the mom and pop grocery stores.

Argument #2 – “Unix/RISC & Itanium  Viable for mainstream applications and functions (but be prepared to accept delays in new features, functions and patches). Declining installed bases —Move to mainstream on system refresh!”  Some of this is certainly true for the Itanium environment due to Oracle’s explicit removal of Itanium support.  On the AIX side, however,  this statement could not be more incorrect.  Neither Oracle nor SAP has published any such guidance, made any public pronouncements or changed their level of investment with IBM and ongoing development and support efforts continue as before, i.e. AIX is a tier 1 platform and supported as such.  The install base for Power, by the way, is not declining and is benefiting from those customers moving away from HP/Itanium and Oracle/Solaris.

Argument #3 – “Move ERP application deployments toward Linux or Windows on x86. Everything else moving to niche.”  Their conclusion, as with the first argument, is based on marketshare numbers which are not published by SAP or Oracle and are unrelated to the value of installations.  SAP, for example, has a product availability matrix and nothing in that matrix suggest anything remotely close to niche status for AIX.

Argument #4 – “x86 performance and RAS features reach parity, drive Windows and Linux volumes further.”  If only there was a shred of proof to that, this might be an interesting conclusion.  The highest x86 result on the single system SAP SD 2-tier benchmark is 25,500 users/140,720 SAPS using the IBM x3850 x5 with 80 cores.  Not bad, but the highest Power Systems result is 126,063 users/688,630 SAPS using the Power 795 with 256 cores.  That is almost 5 times the size of the x86 result.  Perhaps they meant per core.  While Gartner published this last year and therefore did not have the benefit of the recent results publishes on the SAP benchmark web site, I will share them here: the best x86 result is for the IBM x3650 M4 with 2 @ E5-2690 processors/16 cores achieved 7,855 users/42,880 SAPS  or 2,680 SAPS/core.  The Power 730, with 2 Power7 3.55Ghz chips/16 cores, achieved 8,704 users/47,600 SAPS or 2,975 SAPS/core.  While the x86 results are impressive, they do not achieve parity with Power unless Gartner’s has submitted a new definition to Webster’s Dictionary of parity being 90% not 100%.

As to RAS, wow!, where do I start?  Well, RAS starts with error detection.  Since the mid 90’s, Power Systems have offered First Failure Data Capture (FFDC), previously only found on mainframe systems.  This technology is used pervasively throughout the system down to the processors and memory subsystems.  It is instrumented to detect soft and hard errors in virtually every part of the system and each chip such that the service processor can make intelligent decisions as to whether an error might cause a partition or system failure and then take appropriate actions to avoid or minimize such an event.  In the unlikely event of an unpredicted failure than can’t be contained, this technology allows the service processor to pinpoint the location of the failure such that the failing component can be blacklisted, the system or partition rebooted around the failing component or in a worst case scenario, a FRU number or the failing component to be sent to IBM for immediate replacement.  Intel recently introduced Machine Check Architecture Recovery (MCA Recovery) which is less instrumented and less functional than FFDC was back in the mid 90’s.  Currently, it can pinpoint only memory errors, but it does not utilize a service processor and instead asks the operating system or virtualization manager to handle the error.  This is sort of like GM instrumenting their engines such that when they detect a problem such as poor fuel quality or low air temperature, that the car does nothing or perhaps fails and suggests the user call a repair shop instead of the system automatically detecting the problem and adjusting the fuel injection system to compensate.

Add to this features like dynamic processor deallocation, L2 and L3 cache line delete, enhanced error detection and recovery for PCI adapters, to name just a few, for which there is no equivalent in x86 systems.  Or go one step further and look at Power System’s ability to retry an instruction on any processor in the event of a processor core error detection or being able to pick up the actual thread and drop it on another processor in the system, with no interruption to application execution, if the core is determined to be failing.  No such thing exists in x86.  How about memory protection keys which locks down memory such that, for instance, a failing device driver can corrupt the OS kernel’s memory or a misbehaving an application can corrupt the file system’s memory?  No such thing exists in x86 land.  High end Power Systems even offer the ability to recover from a system clock failure through a redundant clock as well as to add/remove a processor card while the system is running without any interruption to the running partitions such that a failing component can be replaced.  Once again, x86 systems do not offer these sort of features.  So, it makes you wonder on which planet these Gartner guys reside when they make such statements!

Argument #5 – “Consider x86 virtualization for HA.” Where do I start with such an absurd statement?   First of all, Oracle has stated that if you run with VMware or other non-Oracle VM products and have a problem, you must prove that the problem was not caused by the virtualization software by recreating the problem on a standalone system.  If that was not enough to cause a customer to avoid placing a database under virtualization, then the high I/O overhead and increased latencies probably will.  That said, some customers might still but DB under x86 virtualization, but then the issue of HA must be considered.   VMware HA does a great job of detecting a failed system or partition and recovering one or more on other systems, but VMware HA does not do system stack recovery.  For customers that run SAP, for instance, in addition to the database running, one must also ensure that the messaging and enqueue servers are running, that all network files that must be accessed are available, that all file systems are available and that if something is not, that retry or repair actions are initiated prior to restarting the entire partition.  VMware does provide an API by which third parties might write application APIs, as Symantec has done, but few proof points exist as to how well this works in production SAP environments.

Argument #6 – “All UNIX for Large Oracle DBMS deployments greater than 64 cores.”  So, if a Power platform running AIX is less expensive, more reliable and more secure, Gartner’s argument is that you should ignore these facts and, for smaller DBMS instances than 64 cores, place these on x86.  Interesting and hard to argue with an statement that makes no logical sense.

In conclusion, Gartner has produced a document which suggests a system selection based on incorrect facts, assumptions and which ignores the criteria that is important to customers.  By comparison, there is a wealth of arguments that can be made as to why Power Systems continues to be the most robust, cost effective, reliable and secure platform for ERP and other applications.

March 23, 2012 Posted by | Uncategorized | , , , , , , , , , , | 2 Comments