QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. 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 |
The impact of virtualisationMonday, September 14. 2009Trackbacks
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
on
2009-09-14 17:38
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. 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 ![]() 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.
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
on
2009-09-15 05:57
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. The author does not allow comments to this entry
|
The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Comments
about Mon, 01.05.2017 11:21
Thank you for many interesting
blog posts. Good luck with al
l new endeavours!
about Fri, 28.04.2017 13:47
At least with ZFS this isn't c
orrect. A rmdir for example do
esn't trigger a zil_commit, as
long as you don't speci [...]
about Thu, 27.04.2017 22:31
You say:
"The following dat
a modifying procedures are syn
chronous: WRITE (with stable f
lag set to FILE_SYNC), C [...]
|