Re: [suse-oracle] Linux-Clustering

From: Martin Konold (martin.konold@erfrakon.de)
Date: Fri Sep 19 2003 - 16:35:28 CEST


From: Martin Konold <martin.konold@erfrakon.de>
Date: Fri, 19 Sep 2003 16:35:28 +0200
Message-Id: <200309191635.30588.martin.konold@erfrakon.de>
Subject: Re: [suse-oracle] Linux-Clustering

Am Friday 19 September 2003 12:25 pm schrieb Lars Marowsky-Bree:

Hi Lars,

> > Michael: Does Oracle provide service for DRDB setups?
>
> This is being worked on.

So this alone is imho enough reason not to use DRDB in a mission critical
Oracle environment. I am not saying that DRDB is not a nice educational tool
or not good for less critical setups. But HA Oracle is not inexpensive and
often done in mission critical environments.

> > If your application does not allow for the simple replication mechanism
> > then imho shared media is the most reliable solution.
>
> Except that of course the shared media becomes the single point of
> failure, unless you have a lot of money to throw at the problem.

Not really if you use Fibre Channel attached RAID-1 storage with mirroring.
Also you may use dual controller SCSI shared storage (e.g. Hewlett-Packard).

> FailSafe is not actively maintained for SLES8.

Good to know from one of the developers/porters of failsafe.

Maybe SuSE should change their website to reflect this fact.

http://www.suse.de/de/company/customer_references/services.html#cluster

Otherwise SuSE customers get the impression that Failsafe is still an option
on SLES.

> > 2.) DRDB assumes that stricter acknowledge semantics improve reliability
> > while forgetting that stricter acknowledge semantics also cause tighter
> > coupling of the nodes and consequently blocking/starvation of the
> > cluster services.
>
> Not more so than any raid1 / replication solution.

Well replication within a SCSI RAID-1 device is much less error prone compared
to depending on tcp/ip networking. Networking is unreliable by definition.

> a slight loss of performance. No doubt about it. Any replicated scenario
> will be slightly slower than the same scenario without replication,
> there is absolutely no doubt about it.

Writing to a RAID-1 device is typically the very same speed like writing to a
single device. Disk mirroring can easily be scaled up by additionally using
striping (RAID-10) while DRDB does not scale.

> benefit of replication is another story. Otherwise, people would not run
> RAID at all, or at least only RAID1 and never RAID5. But obviously,
> reliability benefits and (in the case of RAID5 vs RAID1, for example)
> cost also are important to keep in mind.

RAID-5 is often a bad idea for serious database usage. In most cases RAID-10
is best.

> That is true. Though only protocol C does provide strict transactional
> semantics and no other protocol should be used for databases.

> > c.) a block is only then considered to be really written to disk when
> > both the active and the passive node made sure that the data is
> > physically on the harddisk. This should while beeing horribly slow in
> > practice in theory assure the transactional properties of the DBMS.
>
> It is not horribly slow in practice. Please provide benchmark numbers to
> back up your claims.
>
> I've seen write speeds of 70MB/s (which is all my disks and GigE
> interconnect could take) with protocol C. Remember latency is typically
> very good with local GigE interconnects.

I very much doubt your numbers! I dont believe that you get 70MB/s with DRDB
over GigE for typical Oracle write performance.

> whether it is "horribly slow" depends entirely on the target scenario,
> ie ratio of writes to reads, ratio of barriers to writes, dependencies
> within those barriers on other barriers etc.

All ERP systems I am aware of mainly write _very_ small junks of data to the
db. Therefor the performance gets latency bound. DRDB makes latency much
worse than direct SCSI.

> possible while being in the same city and barring nuclear strikes ;),
> realtime and transactionally consistent replica of the database
> available for failover?

You can optain the same feature with FC (though more expensive ;-))

> I highly recommend "Distributed Algorithms" by Nancy Lynch or in

Thanks for telling me! (I did academic research on distributed systems for
many years.... :-)

But to make a long story short: The plain fact that DRDB is currently not an
Oracle certified configuration alone forbids to recommend it as a technology
to build a highly available and highly reliable mission critical system.

Things may change in the future though.

Regards,
-- martin

Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de

---------------------------------------------------------------------
To unsubscribe, e-mail: suse-oracle-unsubscribe@suse.com
For additional commands, e-mail: suse-oracle-help@suse.com
Please see http://www.suse.com/oracle/ before posting



This archive was generated by hypermail 2.1.7 : Fri Sep 19 2003 - 16:41:53 CEST