Re: RAC/CRS and OCFS2

On Mar 15, 2:23 pm, DA Morgan <damor..._at_psoug.org> wrote:
> Comments in-line.
>
>
>
> Keith wrote:
> > On Mar 15, 11:45 am, DA Morgan <damor..._at_psoug.org> wrote:
> >> Keith wrote:
> >>> Hello RAC gurus,
> >>> I am currently running 10.2.0.3 RAC/CRS on RHEL4. All our database
> >>> files are using ASM/raw devices. However, we now have the need for a
> >>> clustered file system. This file system likely would not be used
> >>> directly by the database, but requires high availability. So, we'd
> >>> like to use OCFS2 -- which has prompted some questions:
> >> I'm confused by your question ... OCFS is a file system. What does a
> >> file system not being used by the database have to do with highly
> >> available anything?
>
> >> Are you expecting your file system to load balance? To have failover?
> >> I'm at a bit of a loss here to understand your intention.
>
> >> About the only thing I can say is that I share hpuxrac's concern
> >> about your lack of testing and a file system not be used for Oracle
> >> has nothing to do with the CRS.
> >> --
> >> Daniel A. Morgan
> >> University of Washington
> >> damor..._at_x.washington.edu
> >> (replace x with u to respond)
> >> Puget Sound Oracle Users Groupwww.psoug.org
>
> > By highly-available, I'm referring to making a file system available R/
> > W from two or more nodes. Should a node fail, the file system would
> > still be available from a second (or more) node. I am not expecting
> > to load balance; simply minimize (or avoid) down time of the file
> > system.
>
> > My concern with CRS and OCFS2 is that both provide clustering services
> > and I'm not sure what the expected behavior is under certain
> > clustering situations. For example, if the clustering services of
> > OCFS2 have a split-brain-type situation, is it going to reboot the
> > system? Since I'm not supporting my DB over OCFS, I'm not sure I
> > would want such behavior.
>
> It would really be helpful if you stated what it is you intend to use
> the file system to do. SQL*Loader? External tables? UTL_FILE? Control
> Files? What you intend is still not stated.
>
> > I have 1-1/2 weeks before my migration, which isn't much time; but I
> > would definitely perform as much testing as I can. I'm just trying to
> > make a determination if this is feasible and practical; or if there's
> > simply a better way to do it, before attempting anything.
>
> A better way to do what? You still haven't stated what it is you are
> trying to do.
> --
> Daniel A. Morgan
> University of Washington
> damor..._at_x.washington.edu
> (replace x with u to respond)
> Puget Sound Oracle Users Groupwww.psoug.org

The database itself will not use the file system. We are trying to leverage the storage available on the DB servers' hosts for application servers that require a shared file system (Cold Fusion to be exact). This is in support of e-commerce sites. The files stored on the file system all contain transient data that is "no big deal" if we were to lose; but if the file system itself becomes unavailable among the app servers, orders cannot be placed (shop cart functionality will cease to work).

The file system, as we currently have it configured, is built from a single LUN mapped to one of the hosts. Should this host go down, we'll lose the NFS mount. So, we were thinking of using a clustered file system such that if one host goes down, our second host could still serve up the mount. Maybe there's some NFS cluster-aware services, but my guess is we'll have to remount the file system on the application servers to the surviving host -- but the file system will at least remain available to do so.

I'm trying to avoid the following situation:

"Holy crap! Node 1 just took a dive and the shared file system is no longer available.... what do we do?" Received on Thu Mar 15 2007 - 14:02:33 CDT