Re: Veritas Cluster vs Oracle RAC for HA

On Mon, 09 Aug 2004 21:23:50 -0400, Mladen Gogala <gogala_at_sbcglobal.net> wrote:

> On Mon, 09 Aug 2004 16:46:41 +1000, Howard J. Rogers wrote:
>
>> 1. No RAC. Use hardware clustering features to start a second instance
>> when the first fails. This is Microsoft's (and the Failsafe) solution,
>> for
>> example.
>
> Yes it is, but I don't like that solution, because one must have
> unused HW capacity for this to work properly.

You'll think I'm just being picky, I'm sure... but even that's not totally true, and needs qualifying.

Although a Microsoft cluster (for example) consists of two machines only one of which can access the hard disk at a time (and hence only one of which can host an instance accessing an Oracle database) there is nothing to stop you simultaneously running programs on the second node which access a different hard disk, or which even access different partitions of the same hard disk. So whilst I am running an Oracle instance on Node A, I can be running a SQL Server instance on Node B, accessing the same disk hardware (just not the same hard disk partitions).

Therefore, both nodes are in use at the same time, and both are being exploited fully. Each offers failover facilities to the other, and therefore each node needs to be able to cope with the load of both nodes... but that's true of a true multi-instance RAC as well. And the degree of unused capacity allowed to accomodate the expected work from the second node does not have to be enormous: many customers might be (ie, are, in my experience) perfectly happy to run slowly, but run at all, in the event of a node failure. They don't expect performance to be equivalent after a failure to what it was before.

The "MS Solution" is not suitable for everyone, of course. But it's a perfectly valid solution, and doesn't require RAC (which I suppose is a moot point in 10g, now that it's part of the Standard Edition, but was a major plus in 9i given the expense of the RAC license). The 'shared-nothing' clustering approach has the merit of cheapness, and simplicity, even so.

>> 2. RAC, but only one active instance. The second instance should mean
>> failover happens faster, and gives you a constantly-ready administrative
>> instance. Nothing needs starting up from scratch. Sometimes called
>> 'active-passive' RAC.
>
> I have 5+ years of experience with RAC/OPS and have never seen a
> configuration like thus. I'm not sure what would be the point of that?

I thought I gave you the answer to that already: there is an administrative instance (so you can rebuild indexes or run reports without clobbering the main, working instance if you needed to). Because the instance is already up and running, and doesn't need starting from scratch, there's a faster failover. RAC Clusters Guard will also work in this configuration. And if I am perfectly happy with my current speed and throughput levels, I don't need RAC's speed-up and scale-up features; but I might well not be able to afford downtime, so nevertheless need to make use of RAC's High Availability features.

The last one is probably the most common reason for going this route. If you don't *need* scale-up or speed-up, then you really don't want the inter-instance messaging and associated overhead that RAC usually brings in its wake. But you want the facility for very fast instance fail-overs. Precisely what active_instance_count=1 configurations of RAC gives you.

>> 3. RAC, with 'co-equal' instances. This is the one to which your
>> constitutional quote makes allusion. It's the one everyone thinks of as
>> RAC. Sometimes known as active-active RAC, it allows for load balancing
>> as
>> well as speedy failover, as well as parallel processing across nodes,
>> and
>> hence scale-up and speed-up.
>
> Yes. That is the one I was talking about. Again, I've learned something
> from you. Your sense of humor is just fine.

Well, that's OK then. So long as you continue to take it in the spirit in which it's intended.

Regards
HJR Received on Mon Aug 09 2004 - 21:39:51 CDT