Re: High Availability Options

I agree with your view on the asmlib/udev matter. I like udev over asmlib, but 
if you are not able to manage udev, asmlib will probably do without much heavy 
linux lifting.

From what I've seen Oracle did not  fork a kernel of their own. They just 
rolled a kernel of their own, just like every distro does. I don't understand 
the hassle around it. Anyone can download the kernel source and roll a kernel 
of their own. Probably the reason lies in in some stuff needed by the database 
machine (OFED/infiniband, the # processors/cpu threads, NUMA), so some tweaked 
stuff. But really, what is the deal?

Frits Hoogland

http://fritshoogland.wordpress.com
mailto: frits.hoogland@xxxxxxxxx
cell: +31-6-53569942




On Oct 26, 2010, at 11:30 PM, Jeremy Schneider wrote:

> Yes, both udev and asmlib are integrated into the kernel.  Asmlib is not 
> distributed by redhat in the kernel rpm, so as you have pointed out, it needs 
> to be kept in sync.  This would be the case for any kernel modules installed 
> separately.  I have also occasionally seen network or hba drivers that are 
> installed separately and require separate maintenance with any kernel 
> upgrade.  On a side note, I bet that this will change in the new Oracle 
> kernel - quite likely you won't need the separate step anymore, now that 
> Oracle has officially forked their own kernel. 
> 
> I was involved in the engineering effort at a very large org and we decided 
> to use udev.  (In fact, I was one of the main proponents of this approach.)  
> It has in fact fallen by the wayside since I left, because noone else can 
> figure out how to write those cryptic udev rules.  One of the major problems 
> was that for every new device that came along, we had to figure out new udev 
> rules to detect this device.  (New HBA vendor, new multipath driver, new SSD 
> card, etc.)  As long as I was around to reverse engineer what kinds of kernel 
> rules we needed to write, it was fine.  But noone else could really figure it 
> out.  With Asmlib, there's no new effort for new devices - any block device 
> is just as easy to work with.
> 
> Personally, I love the flexibility and control of udev.  But I really do 
> think it's a bear to learn - you pretty much have to understand basic linux 
> kernel internals to get it...  there are some people out there who can do 
> that, but not everyone can.  I think that (for better or worse) pretty much 
> anyone can use Asmlib.
> 
> -Jeremy
> 
> 
> David Robillard wrote:
>> 
>> Hello Jeremy,
>> 
>> On Tue, Oct 26, 2010 at 4:32 PM, Jeremy Schneider
>> <jeremy.schneider@xxxxxxxxxxxxxx> wrote:
>>   
>>> David Robillard wrote:
>>>     
>>>> Should you decide to use ASM, I strongly suggest to stay away from ASMLib 
>>>> and use udev instead.
>>>>       
>>> I'm a little curious about the reasoning for this.  I wrote a few blog
>>> posts (long ago) about uncertainty in the state of ASMLib... but these
>>> days I'm not so convinced anymore that it's worth avoiding.
>>>     
>> 
>> Unless things have changed since last summer, I think the main reason
>> to stay away from ASMLib is because it's a kernel module which depends
>> on the exact kernel version the machine was running on when ASMLib was
>> installed. That creates a problem when a kernel upgrade happens and
>> you reboot the machine. If you forgot to update ASMLib, then it won't
>> load because the kernel version changed. What you end up with is no
>> ASM disks :(
>> 
>> That's not a problem with udev(8) because it's independent of the
>> kernel version. Which means you can upgrade your kernel, udev will
>> still do it's job and you won't have any ASM disk problem.
>> 
>> One other thing I like with udev is that it's part of the official
>> RedHat (or OEL) release. So when a bug fix/enhancement happens to
>> udev, you benefit from it from the standard OS maintenance procedure.
>> With ASMLib, you have to keep an eye on the Oracle website. IMHO, it's
>> easier to maintain software when it's part of the OS.
>> 
>> Of course if you use ASMLib and have clear standard operating
>> practices and clear documentation that says you should update ASMLib
>> each time you upgrade a kernel, then I guess it's fine. But most
>> companies I've seen don't have that kind of rigid update procedures.
>> More often, the person in charge of ASM is not the same as the one in
>> charge of keeping the OS up to date. That situation can lead to
>> problems with special kernel modules like ASMLib.
>> 
>>   
>>> UDEV is kinda nice if you understand it... but the documentation is poor and
>>> frankly I've met precious few who do understand it.  I tend to tell most
>>> people now to just use ASMLib unless they already know UDEV.
>>>     
>> 
>> Well, ok, udev's documentation may not be very easy to grasp at first.
>> But it's not that difficult either. And once you have it up and
>> running, maintenance is easier then ASMLib.
>> 
>> I've always wanted to blog about how to setup udev so that people have
>> a clear document how to set it up. But until I can find the time and
>> if you're curious, Freek D'Hooge and I had a long thread on this list
>> about the configuration of udev. You can find the thread archive here:
>> 
>> http://www.freelists.org/post/oracle-l/OCR-VD-external-vs-normal-redundancy-using-NFS,13
>> 
>> 
>>   
>>> I'm skeptical that it's worth the time required to learn it.
>>>     
>> 
>> That depends. A day or two learning udev might look like long. But
>> they're nothing compared to the time and stress required to debug a
>> node that comes up with no ASM disks because of a kernel version
>> mismatch with ASMLib. You also have to calculate the time required to
>> check for new ASMLib versions on Oracle website, download and install
>> it compared to a standard OS upgrade with yum(8) when you use udev.
>> But, as always, YMMV.
>> 
>> Let me know if that answers your question?
>> 
>> Cheers,
>> 
>> David
>> --
>> http://ca.linkedin.com/in/davidrobillard
>> 
>>   
> 
> 
> -- 
> http://www.ardentperf.com
> +1 312-725-9249
> 
> Jeremy Schneider
> Chicago

Other related posts: