Re: Active/Passive "high availability"

On 4/13/07, Allen, Brandon <Brandon.Allen_at_oneneck.com> wrote:
>
> I've noticed there seems to be some disagreement about whether or not RAC
> is really a "High Availability" solution. There is no doubt that
> Oracle advertises it as such:
>
> E.g. from
> http://www.oracle.com/technology/products/database/clustering/pdf/ds_rac.pdf
> :
>

Kind of the 'Truth in Advertising" concept? ;)

  On page 13 there is a graphic of RAC with a mirrored disk subsystem, and
> again the claim of "No Single Point of Failure"
>

Last time I looked, a mirrored disk resides in some type of disk farm. SAN, NFS, whatever, it is a SPOF.

SAN failures are not exacly unheard of.

So, it seems to come down to how you define a "single point". If you look
> at the "database" as a single point, then yes there is a SPOF, but if you
> look at it more granularly and consider that the database resides on
> hardware with mirrored disks and multiple controllers, fibre channels, fans,
> power supplies, etc. - then there isn't really a SPOF at the database level
> either because it would really require multiple failures to bring down the
> database.
>

No, it doesn't require multiple failures. I am not a storage expert, but having redundant components in a SAN does not make it HA. It makes it more resistant to failiure, but it cannot be relied on to guarantee a high percentage of availability.

I have also seen SAN's fail more than once.

A single database is also not HA.

A system requiring 99.9% availability allows only 8.76 hours of downtime per year. Can you do that with a single db?

1 SAN = SPOF
1 Database = SPOF

I like this diagram for an HA cluster:
http://en.wikipedia.org/wiki/High-availability_cluster

A disaster such as flood, fire, earthquake, vandalism, etc. could easily
> bring down the entire disk array at once, but that falls under the category
> of Disaster Recovery, not HA and I think we all agree that RAC is generally
> not a DR solution although I believe some are running RAC with the nodes
> geographically dispersed in an attempt to incorporate DR as well.
>

It isn't really necessary to have a physical disaster.

A careless tech can bring down your SAN for quite a long time.

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

--
http://www.freelists.org/webpage/oracle-l