SC 3.0 - Cluster Filesystem for Oracle Binaries - Is there Risk of DB Crash on the surving node when loosing second node which helds "primary access path" ?

From: Harald Wakonig (Harald.Wakoning@oskarmobil.cz)
Date: Fri Jan 03 2003 - 11:25:13 EST


Server: 2x SunOS sd01kn03 5.8 Generic_108528-16 sun4u sparc SUNW,Sun-Fire-880
Sun Cluster 3.0
Sun HA Agent for Oracle
Oracle 8.1.7 (NOT OPS !!!)
Veritas Volumne Manager, Veritas Filesystem
EMC-Storage

The very interesting Sun Technical Whitepaper "Sun Cluster 3.0 Software -
Cluster Filesystem (CFS): Making the Most of the Global File Service"
http://wwws.sun.com/software/whitepapers/wp-globalfileservices/wp-globalfiles
ervices.pdf
 describes very detailed this service how it works, but some details of the
failover scenarios are missing or confusing.

As Also Oracle Support Forum "Metalink" contains documents which recommend
Global File Service for Oracle-Binaries (but of course not for Oracle
Datafiles) I am really interested in using CFS for Oracle-Binaries.

Example:

/u01/oracle (including /u01/oracle/product/8.1.7/bin) is visible to
(1) Server NodeA hosting database DB_A and (--> should fail over to NodeB in
case of loss of node)
(2) Server NodeB hosting database DB_B (--> should fail over to NodeA in case
of loss of node)

The storage used is a dual-hosted IO device, the active (primary) path is set
to NodeA, that means

*) DB_A uses accesses the filesystem direct using the active (primary)
IO-Path

*) DB_B accesses this filesystem via Cluster-Interconnect to NodeA and from
there through the active IO Path, the "direct connection" from NodeB to Global
File System /u01/oracle.. is not used, this is the "inactive / secondary
IO-Path".

==> or is this a missinterpretation ? Or are reads also done via "inactive /
secondary IO-Path" ? (I am confused by 2nd Paragraph in Chapter 2)

My Questions are
======================

What happens in case of Loss of one node with the primary access path when
using a dual-hosted IO device for Globl File System (e.g. /u01/oracle) ?

(1) NodeA crashes, DB_A of course too.
==> now the "active IO-patch from NodeA to dual-hosted device" is
interrupted.

==> Exactly now DB_B running on the surviving node needs to reload Library
from /u01/oracle.../lib

Question: For how many seconds / minutes is the access for Node_B interrupted,
until the "inactive / secondary IO-Path" from NodeB to /u01/oracle... is
changed to be the "active / primary IO-path" ?

==> Is there the theoretical possibility of a database crash on the healty
nodeB because of loss of NodeA ?

==> If yes, how likely is that

=============================================================================
=====================
Some quotes and related Questions from the Whitepaper - I DID read it and
it's really interesting
=============================================================================
=====================
http://wwws.sun.com/software/whitepapers/wp-globalfileservices/wp-globalfiles
ervices.pdf

2nd paragraph in Chapter 2
---------------------------

This notion of active (primary) and inactive (secondary) I/O paths is used
throughout this document. I/O operations that are performed through these
paths are made highly available via a checkpointing/minitransaction framework.
This ensures that operations failing to complete - due to events such as node
failures - are transparently restarted. The mechanism is required only for
operations that modify system state in some way.

Comment / Question ==> How to understand this ? This gives the impression that
"read only operations" of the surviving node are not affected at all by
loosing the other node.

For example, creating a file will necessitate its use because, if the primary
node failedl arbitrarily during the operation, the secondary node would need
to know if: a) the file existed before the primary node failed, and b) the
primary node successfully completed the creation. Either way, it must return
a
file handle or a UNIX (r) error to the calling process. In cases that do not
modify system state, such as reading data pages or file attributes, no such
overhead is necessary, because the calling node can simply reexecute the
desired method when the initial call fails.

But in Chapter 4 / 3rd paragraph (page 10)
---------------------------------------------

In general, I/O performance characteristics of the system are independent of
which
volume management product is employed: Sun Volume Manager or Veritas Volume
Manager. Because it does not perform a device discovery operation on the new
primary before starting the volumes, Sun Volume Manager offers slightly
faster
volume fail-over times.

Question: What is the impact of this "fail-over-time" on the surving node in
case of an CFS during failover ? What is not available on the surviving Node
during Failover ?

This paragraph is somewhat differenct / confusing compared with the previous
quoted paragrah.

Best Regards,

Harald
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:32 EDT