RE: Rap on RAC
Monday, October 20, 200801:23 pm EDT
In Jeff Browning’s Oct. 15, 2008 post, ”To RAC or not to RAC (reprise)”, he compares some performance and cost metrics between a four node Oracle RAC cluster running on physical hardware, and a virtualized Oracle environment under VMware.
It’s not clear how Oracle was configured in the virtual environment, but straight off it’s not hard to compute the cost differences - Oracle RAC is not light on the IT budget. In a shared storage architecture, Oracle RAC costs go even higher if disaster recovery (DR) is factored in - add a replication solution like Oracle DataGuard, replicated SANs, and potentially big WAN pipes and the costs keep shooting up.
Regarding availability, as its name suggests, VMware HA will provide high availability (i.e. failover with potential lost in flights and definitely a non-zero flip time, meaning some app disruption) whereas Oracle RAC can provide marginally better availability although the SAN itself becomes a single point of failure, meaning potential database and application downtime.
The performance numbers are a bit perplexing - Oracle RAC can load balance across its compute nodes in a local data center so there’s some scale gain; how scalability resulted from VMware HA is unclear as this is not a scalability solution.
What is clear is that if performance could scale out across a pool of databases each in its own VM, then you would have the best of both worlds - better availability and scale. This is exactly what xkoto’s GRIDSCALE technology achieves (www.xkoto.com). With its shared nothing architecture, data can live in any storage model - SAN, NAS, DAS. If DAS is used, then each VM becomes a real autonomous database node that can share workloads with other nodes and provide continuous availability - neither database failure nor database maintenance affects application availability.
