[Linux-HA] ocfs2 ra

[Andrew Beekhof]

On 10/18/06, Slawomir Mroczek <s.mroczek at wasko.pl> wrote:
> On Wed, 18 Oct 2006 09:30:55 +0200
> "Andrew Beekhof" <beekhof at gmail.com> wrote:
>
> > On 10/18/06, Slawomir Mroczek <s.mroczek at wasko.pl> wrote:
> > > OCFS2 RA is based on idea of moving ocfs2 control to user space. In
> > > other words OCFS2 RA wants to take all control of OCFS2 cluster. To
> > > make this happend you should get ocfs2 user space patches.
> > > However I think it's not a good idea. First, you will loose any
> > > kind of OCFS2 certifications,
> >
> > Possible, however this is the supported configuration on SLES10 so
> > must in some way be approved of by oracle.
>
> Take a look at http://oss.oracle.com/projects/ocfs2/ There is nothing
> about SLES10. Frankly, I doubt if Oracle would like to certify fencing
> or any cluster control solution outside the OCFS2. OCFS2 cluster
> integrity solution is more complicated and "low leveled". "OCFS2 RA"
> wants to mangle with directories in /config/cluster/$CLUSTER_NAME/. It
> is not possible while OCFS2 is at kernel level and some dirs are simply
> locked. So that's why you need patches for OCFS2 and that's why
> Filesystem RA with ocfs2 option set simply fails. Alan wrote about that
> some time ago. I spent few fighting with heartbeat, LVM2 and OCFS2, too
> - and now I have two HA production clusters working, but with
> modificated RA's. All SLES9 SP3.

I should have mentioned that I currently work for SUSE and I know that
we have a guy that works very closely with the OCFS2 team and his work
is approved of.

Though I do not know all the details, the likelihood that we'd go down
this path without the support of oracle is very minimal.

>
> > > second, OCFS2 works fine and there is no need to
> > > mess with it
> >
> > Not true.  You have a big problem if heartbeat and ocfs2 disagree
> > about who is (and is not) part of the cluster.
>
> I disagree. OCFS2 cluster works beyond heartbeat. It has its own
> solution which is using LAN and shared storage as well. Simply speaking
> OCFS2 cluster will survive without heartbeat or any other software and
> I think there is no integration with heartbeat needed. And mounting and
> unmouting OCFS2 filesystems just like that on resources restart is
> simply unnecessary. Heartbeat RA's should _read_ OCFS2 cluster status
> and use this informations but not to try mess with it.

I think we're going to have to agree to disagree here.

> > By having OCFS2 accept membership information from heartbeat you
> > eliminate this point of failure.
> >
> > > - you loose its fencing solution or even loose your
> > > data when something bad happend.
> >
> > Again, not true.
> > The heartbeat fencing is generally superior to the one built into
> > OCFS2 which relies (if I understand it correctly) on node suicide.
>
> True, OCFS2 fences posibble failed node by kernel oops. Note, that
> OCFS2 cluster have to provide consistent data on stared storage, so it
> can fence node faster than heartbeat could and its fencing mechanism
> should be trusted. What's the point to risk data inconsistency? And
> when we use i.e.:
>
> node1:~ # sysctl -e -p /etc/sysctl.conf
> net.ipv4.icmp_echo_ignore_broadcasts = 1
> net.ipv4.conf.all.rp_filter = 1
> kernel.panic = 60
> kernel.panic_on_oops = 60
>
> we can have cheap and really handy fencing "device".
>
> --
> Sławomir Mroczek
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>