Re: High Availability Options
- From: David Robillard <david.robillard@xxxxxxxxx>
- To: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- Date: Tue, 26 Oct 2010 17:10:20 -0400
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
