« To RAC or not to RAC (reprise) | Main | New DNFS Performance Results »

October 29, 2008

Comments

Charlie Dellacona

"First, in the area of availability, Oracle RAC provides absolutely no downtime on the database as long as at least one node in the cluster survives."

IMHO, No. One node would provide ACCESS to your data.

I would argue accessibility is necessary but not sufficient for up time. Important applications have response time and transaction rate SLAs as well.

When these are not met you can not call that up time. When my trading system is on one node it will be so slow that the ask prices will crawl up during a buy program, when running on one node my e-commerce site will time out transactions from slow response and my customers will not complete their purchases. This is downtime as well.

With this definition downtime continues until enough nodes are booted into the RAC so that TPS rates are restored.

This makes it a horse race with your VMware HA cluster scenario.

To make an absolute claim of RAC superiority over VMware HA you would have to stipulate that every RAC node be large enough to meet all SLA driven demand.

------------------------

Charlie:

Thanks very much for your comment. While everything you say is true, it applies equally to VMware HA Cluster as well. Thus, there is a performance impact to failover of a VM to another node in the VMware HA cluster, and the failure of all nodes in the cluster but one would result in performance so miserable that it would be considered downtime as well. I think RAC and VMware HA Cluster are somewhat similar in that respect.

Where the similarity breaks down is in the way in which RAC performance tuning typically occurs. In a RAC context the RAC interconnect is often the area where performance is most impacted. Thus, you would tend to avoid blocks pinging across the interconnect. To do that, you would partition the workload and use node affinity to cause a given node to handle only a portion of the data, keeping that dataset within that node as much as possible.

In this respect, RAC is similar to a scale-out that I describe in the blog. The extent to which this can actually be accomplished varies greatly on the workload. Assuming that you could do this almost perfectly, then the failure of a given node would tend to affect RAC more than the failure of a node in the VMware HA cluster, because it would upset the node affinity / data partitioning scheme not only for the failed node, but for the surviving nodes as well.

The solution is to use an N+1 clustering scheme with RAC, basically keeping one node of the cluster pretty much idle. Then in the event of a failure of a node, that node's workload can be failed over to the spare node with minimal, if any, performance impact. You would then be exposed to more extreme impact in the event of the failure of a second node.

A similar approach can be used with VMware as well, of course.

Regards,
Jeff

Alan Davis

This has been an interesting and informative set of posts, thanks for posting. The design and architecture is interesting for a certain subset of HA database needs. You mention some of the possible applications, SaaS being one. The limitations of this architecture present challenges that you may also want to address in a future posting. Where the DB is to be used as a single-application datastore, or where rapid growth of individual DB subsets is anticipated. One other advantage that RAC provides is the reduced management cost of a single system image as opposed to the need to manage and monitor multiple Oracle instances.

The argument that RAC is more complex to configure is, in my opinion, a straw-man. You mention the complexity of setting up ssh equivalence across the cluster nodes as the type of issue that makes configuring RAC difficult. In my opinion, if someone has difficulty understanding and implementing ssh equivalence they are, at the very least, unprepared to configure and manage a mission-critical HA DB system.

These are not toys, as is evidenced by the high cost of the systems themselves. It's at least as important to have properly trained and experienced staff managing the systems as it is to have a sound system architecture.

Proper DB and application architecture goes a long way towards avoiding needless complexity. The design should address not only the needs of the running application, but also failure and recovery scenarios and processes. And besides, the fact that PITR of a tablespace is difficult isn't the issue - it's that recovery at that level is even possible, which is one reason to choose Oracle over PostgreSQL or other, less expensive, options.

Alan Davis

-----------------

Response:

I sort of agree with you. Certainly, Oracle is not a toy. However, the idea of using ssh equivalence as the communications medium for a cluster is kind of a kludge, wouldn't you agree? VMware HA cluster requires no such configuration detail.

A while ago I spoke to a senior Oracle person at a major Fortune 100 company, and he described Oracle accurately: It's like buying a car but getting a bunch of components instead. You have an engine, a transmission, four fenders, four wheels, and so forth, sitting in your garage. It is up to you to assemble the pieces.

That comes fairly close to capturing the essence of Oracle: It is not a product for the faint of heart. I kind of like that sort of thing (certainly I have built my share of cars), so I do not object to this unduly. I think most DBAs are of a similar type. Certainly, we are not complexity adverse.

Having said that, if you need to manage a large number of servers or instances, the Oracle method of management quickly becomes painful. VMware provides huge cost and manageability advantages when you begin to scale your server farm. I strongly recommend that customers at least consider it.

The comments to this entry are closed.

Powered by TypePad
View Jeff Browning's profile on LinkedIn

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.