Re: High Availability Options
- From: Frits Hoogland <frits.hoogland@xxxxxxxxx>
- To: jeremy.schneider@xxxxxxxxxxxxxx
- Date: Tue, 26 Oct 2010 23:43:12 +0200
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:
>>
>> //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:
