Re: High Availability Options
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: David Robillard <david.robillard@xxxxxxxxx>
- Date: Tue, 26 Oct 2010 16:30:25 -0500
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: