Oracle RAC in vergelijking met VMware HA | EarlyBert
« Open source alternatief voor Cisco's Nexus 1000V
De bare-metal client hypervisor van Citrix wordt een gratis product »
Oracle RAC in vergelijking met VMware HA
May 8, 2009 by Bert Bouwhuis
Jeff Browning heeft zijn eerdere bedenkingen met betrekking tot Oracle's ondersteuning voor virtualisatie nader toegelicht. Hij gaat met name in op de interessante vergelijking tussen een
hoog-beschikbare Oracle database op basis van de Oracle RAC-oplossing (Real Application Cluster) ten opzichte van
de manier waarop je de beschikbaarheid van de database kunt verhogen met VMware's HA oplossing.
Allereerst is belangrijk te onderkennen dat Oracle RAC een echte fout-tolerante oplossing biedt: een hardware-fout veroorzaakt geen enkele downtime van de database (alhoewel toegang vanaf de clients wel downtime kunnen ondervinden). VMware HA zorgt er daarentegen voor dat een virtuele machine bij een hardware-fout opnieuw wordt opgestart op een andere fysieke machine. De database die in die virtuele machine draait heeft hierbij dus wel downtime en dientengevolge de toegang vanaf de clients ook.
Binnen die context schetst Jeff de volgende verschillen:
VMware HA biedt een betere performance van de database dan Oracle RAC
De licentiekosten van Orace RAC zijn een stuk hoger dan die van VMware HA
VMware HA is eenvoudiger te beheren dan Oracle RAC
Zie Jeff Browning's post voor meer.
Overigens meldt Chris Wolf dat Oracle haar support policy ten aanzien van "vreemde" hypervisors (lees niet-Oracle) wel versoepelt. Het gaat met name om de nieuwe zinsnede daarin:
The use of platform vendors' virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle's policy with regards to 3rd-party products – that is, they are 'not explicitly certified, but supported'.
Alhoewel hier expliciet sprake is van Oracle's E-Business Suite mag je waarschijnlijk ook veronderstellen dat dit geldt voor een eventueel daaronder liggende database van Oracle.