This content has been marked as final. Show 21 replies
My suggestion is not to bother with ASMlib.
You have two multipath devices:
Determine the WWIDs of these devices.
[root@ahmed-ol6 sf_Softs]# cat /proc/partitions major minor #blocks name <snipped> 253 0 11612160 dm-0 253 1 5210112 dm-1
Configure fixed/static logical mpath device names for these, using +/etc/multipath.conf+. At the same time configure the IO scheduler and parameters to use for these paths - I assume it is fabric channel? Storage vendors usually have notes on what multipath configuration should be for their specific SAN models.
For ASM - you set the disk discovery string to "+/dev/mpath/*+".
The only other issue is disk permissions. The +/dev/dm-0+ device you have is a multipath device that sits "on top" of a number of scsi devices like +/dev/sdj+, +/dev/sdag+ and so on. You can look at the path using multipath -l command.
ASM needs to use +/dev/dm-0+ (via the static name in +/dev/mpath+ that assigns a fixed "pretty" name for the device, e.g. <i>/dev/mpath/FRA1</i>) - as that provides the multiple I/O paths. Underlying scsi devices like +/dev/sdag+ sees that LUN via a single specific path.
As ASM needs to use +/dev/dm-n+ devices, permissions need to be set for these devices (no need for the underlying scsi devices). This is done via +/etc/udev/rules.d/40-multipath.rules+.
These are standard Linux kernel modules using standard configuration settings and features. It it not something different. Not something special. It is how the Linux kernel is designed to be used.
The kernel you have it installed, uses udev. It is not optional. Part of its job is to recognise multipath devices - scsi devices that, via different I/O paths, sees the same physical storage device or LUN.
udev uses multipath to deal with this. multipath configures the I/O paths access to the physical storage device/LUN and provide the consistent names to udev to create.
This is how the Linux kernel works. This is what is happening on your server.
Now you say you do not want to configure this correctly, as it "bypasses" ASMLib!?
Basic statements from multiple Linux manuals and sources:
Udev is the device manager for the Linux 2.6 kernel that creates/removes device nodes in the /dev directory dynamically. It is the successor of devfs and hotplug.
Udev provides a persistent device naming system through the /dev directory, making it easier to identify the device.
udev supplies the system software with device events, manages permissions of device nodes and may create additional symlinks in the /dev directory, or renames network interfaces. The kernel usually just assigns unpredictable device names based on the order of discovery. Meaningful symlinks or network device names provide a way to reliably identify devices based on their properties or current configuration.
First get the basics right. Configure udev for supporting your devices - which are multipath devices and requires that part of the udev configuration to be set.
Afterwards decide on ASMLib or Powepath or whatever other driver layer you want to use on top of this. Or skip such additional device layer complexities all together.
Dude, why do you say that i'm using RHEL6 kernel?Because you uname output shows: 2.6.32-279.19.1.el6.i686.
If you were using the Oracle UEK kernel, output should be similar to 2.6.39-200.29.2.el6uek.i686.
The system ships with 2 kernels, the UEK kernel and original RHEL kernel. The UEK kernel under Oracle Linux is the default. You either selected the wrong boot option at the Grub startup or have configured the system to use the RHEL kernel instead.
And btw, you use a 32-bit configuration and limit resource utilization by today's common standards. Unless you have a very old machine or need to run a legacy 32-bit Oracle Database, I'd question the reason.
I think there is nothing wrong to have a certain opinion based on your own findings. But trying to "*missionize*" others to avoid ASMLib, e.g., mentioning it with every post, without knowing or providing the underpinning technical details about ASMlib is not.
I too questioned the reason for ASMlib in the past and found it difficult to find the necessary technical info. However, it would have never reached my mind to warn other about using ASMlib.
Every piece of software may add uncertainties to your system. Even Linux wasn't always bright in the past, but do you warn others about Linux? Probably not because you use it, right?
I think it has become quite clear according to other simlar threads about this topic, that ASMlib does not replace Multipath and Udev. ASMlib is a complementary product, and not mandatory. Apparently other people have noticed an increase in CPU wait time after removing ASMlib, which is not justifing your cause. And even if the technical arguments were not reasonably explained by your standard, what about ASM management, which an be a valid argument.
As for the reason or benefit of ASMlib, there is some information in previous posts and http://www.oracle.com/technetwork/topics/linux/asmlib/index-101839.html. Some of the information was apparently added last year.
Edited by: Dude on Jan 24, 2013 5:19 AM
My perspective is the opposite - that the perception exists that ASMlib is mandatory for using ASM, and not using it means a problematic and less than robust ASM implementation. And that this perception is reinforced by comments and postings here on OTN.
The important point that needs to be made is that udev is part of the Linux kernel of today. And with it, multipath. It is not something optional that needs to be added afterwards to the kernel.
Valid reasons are needed to add new kernel modules to the driver stack - and that turning this question around and questioning the use of standard kernel modules on which the o/s depends, does not make sense. IMO.
By all means, use ASMlib if that is based on an informed decision. But do not disregard udev/multipath in favour of ASMlib, based on an ill-informed perception.
Perhaps you are right, based on perception, that people may disregard udev and multipath in favor of ASMlib, based on perception. But even so, it is not necessarily wrong. It all depends on technical justification and usage and user aspects, as we all know.
To say however that ASMlib is unsupported because it is not available for RHEL 6, and anyway useless and obsolete based on personal or whatever past experiences, and adding that some big shop does not use ASMlib to emphasize it, to me is no good justification.