The impact of virtualisation

I'm a member of

Quicksearch

Codenews Search

Disclaimer

The individual owning this blog works at Sun Microsystems GmbH in Germany, a subsidiary of Oracle. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< Virtualbox 3.0.6 | Blue to the bones >

The impact of virtualisation

Monday, September 14. 2009

My colleague Jan searched a little bit in the large heap of benchmarking certifications of SAP and found something really interesting. The benchmarks certified in document number 2009034 (Sun Fire X4270, 2 processors /8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory) yielded 15,320 SAPS on 8 vCPU. On the other side an Fujitsu PRIMERGY Model RX300 S5 (2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 96 GB main memory) yielded 11,230 SAPS (as certified by 2009029). I should add something ... in my opinion it's not the system, that was responsible for this large gap. So what's the difference?

Both benchmarks included an virtualisation layer. Both systems were limited to use 8 vCPU for the central server. And here is the difference: The Sun system used Containers on Solaris 10 with Oracle 10g and started the central server in a non-global zone. The Fujitsu system used SLES 10 with MaxDB as a VMware ESX 4.0 VM. Based on this benchmark, it looks like that the containerized system is able to yield 136 percent of the performance of the VMware-virtualized system. 35 percent performance are a quite significant difference.

Posted by Joerg Moellenkamp in English, Solaris, Sun/Oracle, Technology, The IT Business at 16:09 | Comments (5) | Trackbacks (0)

Defined tags for this entry: oracle

, solaris

, sun

Related entries by tags:

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Interesting, yet the Sun platform is at least 20% more expensive. Obviously containers have less overhead than VMs, but the technology to migrate VMs without dropping connections is well developed. VMs have less downtime than sun servers. Additionally the Oracle licenses are far more expensive than maxDB licenses. Consequently, the second configuration provides more results per dollar and has less downtime.

#1 Doug Sargent on 2009-09-14 17:38 (Reply)

Well, the Sun Server and the Fujitsu-Server are comparable, even in the aspect of hardware costs, but the VMWare hypervisor & SuSE Linux together are more expensive than a Solaris License. On top, running the DB of a productive SAP system in a VM is only supported for Solaris Container. Vmotion is not supported by SAP (See note 1374671).

#1.1 Jan Brosowski (Homepage) on 2009-09-14 18:44 (Reply)

1. A higher availability of VMs would imply that the Hypervisor can predict hardware damages or outages. There is just one case, where there is an reduction of downtime and this is the case of the planed downtime for the hypervisor. I just consider your statement as largely unfounded. When you work in your operating system you have the same procedures in a VM than on bare metal. Live migration doesn't help you with updates of your OS or your application. No difference here. Furthermore every moving part in a Sun Server is hot-swapable. Thus the story of "live migration to swap a fan" doesn't catch, as you could do it anyway.

From my perspective the impact to reduce unplanned downtime is rather low, as the system has to detect the upcoming failure early enough to initiate live migration. With 96 (or just 48 GBytes) the migration can take a while

The HA functionality of VMware is similiar provided to the one you find in SunCluster, it isn't stateless. The FT lockstepping functionality of VMware can't be used here, as FT just supports VM with 1 vCPUs.

2. The database has a low impact to the SAPS result as stated earlier in other articles in this blog. You would get similar results with the MaxDB.

3. The Fujitsu needs the additional SLES licenses and VMware licenses ans Support. Those aren't cheap as well. Solaris support is included in the SunHW support you would need for the VMware/sles version at any case.

#1.2 Jörg+M. (Homepage) on 2009-09-14 19:51 (Reply)

Hm.. I wonder.. what happens when a non-moving part in the Sun server has a problem, however?

An example would be a memory chip or CPU.
Even if the hot swap is possible, it could be risky; a human making a mistake during a hardware swap procedure is possible, e.g. power cable to PSU A accidentally ejected while swapping PSU B.

I'd be hesitant to draw conclusions on this question without empircal data comparing actual availability of VMware VM vs Sun container...

#2 Dracolith on 2009-09-15 05:57 (Reply)

1. A Sun server has enough LED on the outside and the inside for a christmas tree (even the DIMM slots have LEDs). Someone who swaps the wrong part should schedule a meeting with her or his ophthalmologist.

2. Regarding the non-movable parts failures. Solaris has the Fault Management Framework. It monitors the components of the system and take action in the case the errors start to reach certain thresholds: CPUs or cores are offlined when they start to throw to many correctable errors or a memory will be evacuated and retired, when it throws too many errors. It prints a nice message in your log, it throws an SNMP trap and you can schedule the repair at your convenience.

#2.1 Jörg+M. (Homepage) on 2009-09-15 08:13 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry

View as PDF: This entry | This month | Full blog

Competition entry by David Cummins powered by Serendipity v1.0

Links in this article

The LKSF book

The book with the consolidated Less known Solaris Tutorials is available for download here

Twitterfeeds

twitter.com/c0t0d0s0
http://twitpic.com/19ao33 - empty ....

twitter.com/codenews
6933239 An assertion fail in callout.c on Emerald system in snv_135 http://bit.ly/cHzbFO

twitter.com/SunPatches
Security patch: 120228-40 - Messaging Server 6.3-11.01: core patch. Available for SPARC since Mar/17/10. http://bit.ly/bk1hw3

twitter.com/SolPatchesX86
122301-49 - SunOS 5.9_x86: Kernel Patch. Available since Mar/17/10. http://bit.ly/9ETInV

twitter.com/SolPatchesSPARC
122300-49 - SunOS 5.9: Kernel Patch. Available since Mar/17/10. http://bit.ly/b9ZvRJ