RE: High Availability Options
- From: "Amaral, Rui" <Rui.Amaral@xxxxxxxxxxxxxxxx>
- To: "'jhthomp@xxxxxxxxx'" <jhthomp@xxxxxxxxx>, "Mark.Bobak@xxxxxxxxxxxx" <Mark.Bobak@xxxxxxxxxxxx>
- Date: Thu, 28 Oct 2010 13:23:26 -0400
There is another reason for using things like udev which we have been equating
with persistent device naming... and that is the limited availability of the
major-minor numbers for devices. I have had the odd time, when I was first
starting out with this stuff, of devices "disappearing" completely which is
tied to the dynamic assignment of those numbers to devices. This is briefly
outlined in the following from one of the creators of udev:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
persistent device naming is also persistent device assignment which would allow
ASM to track down the /dev tree to find it's disks.
Rui Amaral
Database Administrator
ITS - SSG
TD Bank Financial Group
220 Bay St., 11th Floor
Toronto, ON, CA, M5K1A2
(bb) (647) 204-9106
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of John Thompson
Sent: Thursday, October 28, 2010 11:37 AM
To: Mark.Bobak@xxxxxxxxxxxx
Cc: jeremy.schneider@xxxxxxxxxxxxxx; Freek.DHooge@xxxxxxxxx;
Paul.McManus@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: High Availability Options
I've been using ASMLIB for going on 2 yrs now in production on 22 servers
without any issues. We use EMC Powerpath which ensures the names are correct on
reboots.
On Thu, Oct 28, 2010 at 10:24 AM, Bobak, Mark
<Mark.Bobak@xxxxxxxxxxxx<mailto:Mark.Bobak@xxxxxxxxxxxx>> wrote:
Jeremy makes a good point. As long as permissions are good, and the device
naming matches what's specified in asm_diskstring, ASM will happily discover
all the required disks and figure out how to use them.
-Mark
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] On
Behalf Of Jeremy Schneider
Sent: Thursday, October 28, 2010 10:55 AM
To: Freek.DHooge@xxxxxxxxx<mailto:Freek.DHooge@xxxxxxxxx>
Cc: Paul.McManus@xxxxxxxxxxxx<mailto:Paul.McManus@xxxxxxxxxxxx>;
oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: High Availability Options
Also worth noting that ASM actually doesn't require or care about
persistent device naming. The only thing that matters is getting
permissions applied correctly, so that ASM (a non-root, user process)
can access its disks. If you hard-code a "chmod" statement in your
rc.local, that's when you get messed up after device re-numbering.
But as long as permissions are correct, it doesn't actually matter to
ASM if the device name changes.
On 10/28/10, D'Hooge Freek
<Freek.DHooge@xxxxxxxxx<mailto:Freek.DHooge@xxxxxxxxx>> wrote:
> Paul,
>
> If you use linux multipathing (which is often the case), this will also
> ensure persistent device naming (certainly when you provide an alias).
>
> I like to use udev to then create the devices for asm (based upon the alias
> name given in multipath) in a separate directory to avoid picking a device
> that was not ment to be used for asm.
> (and to set the ownership / privileges correctly).
>
> Regards,
>
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> email: freek.dhooge@xxxxxxxxx<mailto:freek.dhooge@xxxxxxxxx>
> tel +32(0)3 451 23 82
> http://www.uptime.be<http://www.uptime.be/>
> disclaimer: www.uptime.be/disclaimer<http://www.uptime.be/disclaimer>
> ________________________________________
> From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
> On Behalf Of Paul McManus
> Sent: donderdag 28 oktober 2010 16:01
> To: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
> Subject: Re: High Availability Options
>
>
>> +1 IMHO: both udev or ASM Lib just useless. Why we should introduse
>> any additional layers when we can avoid those.
>> Keep it simple. Use devices directly (ASM will read headers for you,
>> just set the discovery string right) + rc.local will fix privileges
>> esely.
>>
>> Just my .2$,
>> Yurt
> I thought UDEV and/or ASMLIB were recommended to ensure persistent device
> naming.
>
> I have certainly seen RAC environments fall over when new LUNS were
> presented that caused the device names to switch and so messed up a
> rawdevices configuration which meant voting disks and OCR files were not
> where they were supposed to be.
> PMcM
>
> _DISCLAIMER:
>
> This message is intended only for the use of the person(s) ("the intended
> recipient(s)") to whom it is addressed.
>
> It may contain information which is privileged, proprietary and/or
> confidential within the meaning of applicable law.
>
> If you are not the intended recipient, be advised that you have received
> this email in error and that any use, dissemination, forwarding, printing or
> copying of this message (including any attachments) is strictly prohibited.
>
> If you have received this message in error, please contact the sender of
> this message as soon as possible.
>
> The views or opinions expressed in this message are those of the author and
> may not necessarily be the views held by Maxima Holdings plc.
> Maxima Holdings plc. Cotswold Court, Lansdown Road, Cheltenham, Glos, GL50
> 2JA. Registered in England. 5043538. VAT Number - 728778184
> ____________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
http://www.ardentperf.com<http://www.ardentperf.com/>
+1 312-725-9249
Jeremy Schneider
Chicago
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
NOTICE: Confidential message which may be privileged. Unauthorized
use/disclosure prohibited. If received in error, go to www.td.com/legal for
instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié.
Utilisation/divulgation interdites sans permission. Si reçu par erreur, allez
au www.td.com/francais/avis_juridique pour des instructions.
Other related posts:
