On Tue, 2007-12-11 at 14:12 +0530, Koustubha Kale wrote:
> Does it work as expected? There seem to be two problems to me...
>
> a) when we use something like.. (from your cookbook)
> disk {
> fencing resource-and-stonith;
> }
> handlers {
> outdate-peer "/sbin/obliterate"; # We'll get back to this.
> }
> when this handler gets called both nodes will try to fence each other. Is
> that the intended effect?
Yes, in a network partition of a two-node cluster, both nodes will race
to fence. One wins, the other dies. ;)
> b) If we try to do ssh <host> -c "drbdadm outdate all", gfs is still mounted
> on top of drbd and drbd is primary so here is no effect of the command and
> the split brain continues. I have seen this.
... but with resource-and-stonith, drbd freezes I/O until the
outdate-peer script returns a 4 or 7... If it doesn't return
> >I don't fully understand. You want to start a service on a node which
> >doesn't have access to DRBD - but the service depends on DRBD?
>
> We are using a three server node cluster. Two of the server nodes act as the
> shared storage in Active-Active DRBD. The third
> server node mounts the gfs volumes through a manged NFS service. All three
> cluster nodes act as servers for diskless nodes ( XDMCP through LVS -->
> Direct Routing method). The diskless nodes are not part of RHCS cluster. They
> are thin clients for students.
> What I was wondering about is if there is a way to switch over a users
> session in the event of a server cluster node crashing. It wont have to
> depend on DRBD as the other server node will still be active as drbd primary,
> also the third server will continue working with NFS failing over to the
> remaining DRBD machine.
Fail over an xdmcp session? I think xdm/gdm/etc. were not designed to
handle that sort of a failure case. It sounds like a cool idea, but I
would not even know where to begin to make that work.
-- Lon
--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster
