From: Michael Kershaw (mike.kershaw_at_gmail.com)
Date: Sun Jun 03 2007 - 03:27:04 CEST
Message-ID: <a7b43ddc0706021827x2271b1f1g8bad1f31e5bee3d9@mail.gmail.com> Date: Sat, 2 Jun 2007 21:27:04 -0400 From: "Michael Kershaw" <mike.kershaw@gmail.com> Subject: [suse-sles-e] Re: [suse-oracle] Oracle on raw devices in SLES9
First off, I would never listen to anything REDHAT has to say about
anything...seriously...maybe just my personal opinion, but it comes
from a lot of experience between the two big commercial players out
there...ok..with that said, I have multiple Sles9 Sp3, 10g clusters
running at the moment. Some 2 node clusters, all the way up to
multiple 18 node clusters in production. They all utilize shared
fiber storage, and raw devices with ASM. I use the device-mapper for
my persistent binding, and udev for the persistent permissions. I've
created a multipath.conf file aliasing my devices to the UID of each
of the multipath'd luns. Here's an entry for an individual lun:
multipath {
wwid 1HITACHI_R450A82C09A5
alias ora_registry1
path_grouping_policy multibus
path_checker readsector0
path_selector "round-robin 0"
failback 60
}
and then make entries in my /etc/raw file like so:
##
# First 5 devices for Oracle services
##
raw1:mapper/ora_voting1p1
raw2:mapper/ora_voting2p1
raw3:mapper/ora_voting3p1
raw4:mapper/ora_registry1p1
raw5:mapper/ora_registry2p1
The p1 obviously is the partition for the device of the alias created.
I simply lay out a partition on each of the luns before I pull them
into the device-mapper for consistency, and that way anyone else in my
team can easily see what devices are free on the system in question if
there is no partition on said device when they're looking. From the
/etc/raw file, I just have my entries for permissions in
/etc/udev/udev.permissions and away we go. I've had our larger
clusters running in this fashion for well over a year now. If you
have any more questions on anything more specific, or If I've confused
you even more, just let me know and I can get into more detail.
Hope this helps,
Mike
On 6/2/07, Shashi Kanth Boddula <shashi-kanth.boddula@hp.com> wrote:
> Ok , the problem "persistence ownership" on raw volumes is over by using
> udev, now i am facing a one more problem in SLES9 SP3, and the problem
> is with SAN disks (raw disks) (persistent binding).
>
> I am trying to solve the problem by using same udev concept, as i found
> that we need add line in the udev rules file, and redhat documentation
> said that we need add a line in /etc/udev/rules.d/20-names.rules file.
>
> http://kbase.redhat.com/faq/FAQ_85_8082.shtm
>
> (KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="UUID",
> NAME="devicenam
>
> As SLES9 ships a single udev rules file, i have added the above line in
> /etc/udev/udev.rules in SLES9.
>
>
> KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
> RESULT="3600508b4001007d000017000044a0000", NAME="disk/fc/fc_lun0"
>
> For each LUN, i have added a line like above.
>
> Now in the YaST, when i run (#yast2 disk) , in the YaST GUI, i am seeing
> all my assigned names.
>
> /dev/disk/fc/fc_lun0
>
> /dev/disk/fc/fc_lun2
>
> /dev/disk/fc/fc_lun3
>
> so on..................
>
>
> But in any LUN, if i try to create a partition, YaST doesn't through any
> error, but actually the partition will not be created.
>
> when you run YaST next time, that partitions own't be there .
>
> Any one has any solution for this?
>
> How others are doing ?
>
>
> Thanks
>
>
>
> Alexei_Roudnev wrote:
> > If you use standard SuSe orarun, then oracle get a secondary group 'disk'
> > and have read/write access to the raw devices by default. It works for
> > everything except CSSFile on CRS (RAC cluster).
> >
> > Other method is, yes, to modify udev permissions.
> >
> > But I use modified rawnames script which
> > - creates symlinks for raw devices so that oracle dont work with 'raw' names
> > but works with names such as 'DISK1', 'LOG2' and so on;
> > - it uses 'sleep 5; chown' so it set up owner after udev finish t's work.
> >
> >
> >
> > ----- Original Message -----
> > From: "Kevin Lyons" <kevin.x.lyons@oracle.com>
> > To: "Shashi Kanth Boddula" <shashi-kanth.boddula@hp.com>
> > Cc: <suse-oracle@suse.com>; <suse-sles-e@suse.com>
> > Sent: Friday, June 01, 2007 9:36 AM
> > Subject: Re: [suse-oracle] Oracle on raw devices in SLES9
> >
> >
> >
> >> On Fri, 2007-06-01 at 21:37 +0530, Shashi Kanth Boddula wrote:
> >>
> >>> Hi All,
> >>>
> >>> I am installing Oracle 10gR2 on SLES9 SP3 raw volumes which is made by
> >>> Linux LVM. As per the oracle documentation, all the raw devices should
> >>> be owned by oracle user, for that we need to change the ownership on all
> >>> raw devices where your installing database to oracle user.
> >>>
> >>> The problem is , after you create a mapping file in /etc/raw, and when
> >>> you start the raw service (#rcraw start), the permission again set back
> >>> to root.
> >>>
> >>> I have tried to solve this problem by modifying /etc/init.d/raw file ,
> >>> but still , always , when you start the raw services, the ownership on
> >>> raw devices again go back to root.
> >>>
> >>> Anyone has any solution for this ?
> >>>
> >>>
> >> Modifying the /etc/init.d/raw script is not the way to go.
> >>
> >> When the raw devices (or really any devices) are created, the udev
> >> subsystem automatically sets the permissions to root:disk:660.
> >>
> >> On SLES9 edit the /etc/udev/udev.permissions file which has rules for
> >> what permissions are given to devices files as they are created.
> >>
> >> For raw devices, the permissions are set by the following line:
> >>
> >> raw/raw*:root:disk:660
> >>
> >> You want to add some rules to set the permissions for the raw devices
> >> that you are going to use like so:
> >>
> >> raw/raw1:oracle:oinstall:644
> >> raw/raw2:oracle:oinstall:644
> >> raw/raw3:oracle:oinstall:644
> >> raw/raw*:root:disk:660
> >>
> >> Or whatever is appropriate for your setup. The rules can contain some
> >>
> > standard
> >
> >> shell expansions like 'raw/raw[1-3]' or similar. The man page has more
> >>
> > details.
> >
> >> Note that the file is processed in order, and when a matching rule is
> >>
> > found
> >
> >> processing stops. So you need to have the default rule come after your
> >>
> > custom
> >
> >> rules or it will not work.
> >>
> >> Thanks,
> >> Kevin
> >>
> >>
> >>
> >> --
> >> To unsubscribe, email: suse-oracle-unsubscribe@suse.com
> >> For additional commands, email: suse-oracle-help@suse.com
> >> Please see http://www.suse.com/oracle/ before posting
> >>
> >>
> >>
> >
> >
>
>
> --
> To unsubscribe, email: suse-oracle-unsubscribe@suse.com
> For additional commands, email: suse-oracle-help@suse.com
> Please see http://www.suse.com/oracle/ before posting
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Sun Jun 03 2007 - 05:30:49 CEST