Re: RedHat 6 RAC Specific Questions & Concerns

From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Mon, 19 Aug 2013 10:58:31 -0500
Message-ID: <CA+fnDAYEmQCdtocnWP_afA6zq8XPbVTb0cgrgVZEFqTisEtgHQ_at_mail.gmail.com>

Can't use a non-clustered filesystem.
If you already have a supported cluster filesystem for other reasons (e.g. datafiles on veritas cfs) then you can also put CRS files here. In this case recovery isn't bad because the dependency chain is clear and simple: DB -> ASM -> Oracle CRS -> Veritas.

If you don't have a CFS then you can use block devices directly. (Sorry, it's probably confusing that I called them "raw" devices... creating the extra raw layer hasn't been necessary for some years now. Oracle CRS will use the block devices directly in non-buffered/direct.)

Frankly ASM is the "simplest" thing to setup... I would just contend that block devices are a worthwhile tradeoff b/c while it's a little more complicated to setup initially it's a lot simpler to recover.

-J

--
http://about.me/jeremy_schneider


On Mon, Aug 19, 2013 at 10:47 AM, <Christopher.Taylor2_at_parallon.com> wrote:



> So, if I were to want to design a system of less complexity (i.e. less

> potential stress), would you recommend using a normal/standard clustered

> filesystem for OCR and voting disks such as GFS for RedHat, or OCFS2 for

> Oracle Linux and would it have to be a raw device, or would a cooked

> filesystem mounted with O_DIRECT be sufficient?  ****

>

> ** **

>

> I would imagine that high-end performance of OCR/Voting files is of "least

> concern" when it comes to clustering, and recoverability (and ease of

> recoverability) would be the driving factor here?****

>

> ** **

>

> Thoughts?****

>

> ** **

>

> Chris****

>

> ** **

>

> *From:* Jeremy Schneider [mailto:jeremy.schneider_at_ardentperf.com]

> *Sent:* Monday, August 19, 2013 10:33 AM

>

> *To:* Taylor Christopher - Nashville

> *Cc:* Oracle-L

>

> *Subject:* Re: RedHat 6 RAC Specific Questions & Concerns****

>

> ** **

>

> I have set up clusters in all of these configurations - raw, CFS and ASM

> for OCR/voting.****

>

> ** **

>

> A few weeks ago I unexpectedly had to completely recover a multi-TB

> cluster database from backups.  It was an intense situation with several

> levels of management watching over our shoulders and sweating every minute

> of downtime.  In this case the OCR and voting disk were stored on ASM.****

>

> ** **

>

> We did get everything recovered - but there are a lot of surprises in

> store for you guys when you first try to recover a database where

> OCR/Voting are on ASM.  The problem is all the bootstrapping and

> interdependencies between ASM and CRS.  And they changed the syntax of

> recovery commands between 11.2 point releases.  And there are still gaps in

> the documentation - even on metalink/MOS.****

>

> ** **

>

> After my experience with that recovery, I would personally counsel people

> to avoid putting the OCR/Voting disks on ASM when possible until it

> stabilizes a little (no more syntax changes in point releases!!) and until

> the documentation is a bit better.  I would recommend still using raw

> devices -- even with 11gR2.  Contrary to popular belief, raw devices *are*

> still supported by the 11gR2 software (this is in the docs and on MOS)...

> you just have to use the command line to configure it because Oracle

> removed support from the installer and other GUIs.****

>

> ** **

>

> On a related note, I would also recommend that you use dedicated volumes

> for your OCR and Voting Disks -- this offers a few advantages over using a

> volume which also hosts other data (data files, ACFS volumes, etc).  For

> example... try doing a space reorg that requires dropping a ASM disk that

> has a voting disk on it...  and BTW I think the 12c docs mention this as a

> recommendation too.****

>

> ** **

>

> But note that the 12c docs state that they have completely removed support

> for raw devices in that release and whenever the time finally comes to

> upgrade to 12c you will be forced to migrate to ASM or CFS for your voting

> disk and OCR.  IMHO Oracle's whole architectural decision to force the OCR

> and voting disks into ASM volumes is completely premature.  ASM is

> generally treated as a "cluster resource" which can't start until

> clusterware is running and you need lots of "special" backdoors to get the

> OCR/Voting disks into it.  It's beyond me why they decided not to allow raw

> devices anymore.  Especially when they still recommend a "quorum" volume

> dedicated to voting disks in 12c!  If a LUN is only for a voting disk, then

> adding an ASM layer only does one thing: complicate recovery.  I really

> don't see any advantage at all.****

>

> ** **

>

> Sorry, /end ranting...  and just my opinion anyway, after a recent

> irritating experience with a restore...****

>

> ** **

>

> -J****

>

> ** **

>

>

> ****

>

> --

> http://about.me/jeremy_schneider****

>



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

Received on Mon Aug 19 2013 - 17:58:31 CEST