[Linux-cluster] FailOver Domains not working properly

[Marcos David]

Juan Ramon Martin Blanco wrote:
>
>
> On Tue, Feb 3, 2009 at 7:31 PM, Marcos David <marcos.david at efacec.pt
> <mailto:marcos.david at efacec.pt>> wrote:
>
>     Hi,
>     I have a 4 node cluster using RHEL 5.3.
>
>     I have 4 services which I want to spread trough the servers so I can
>     have some load-balancing.
>     Each server should run one of the services when they are enabled, but
>     what is happening is that the services always start on the node from
>     which I enabled them.
>
>     My configuration is this:
>
>     FailOverDomain1 -> includes node1 only, unrestricted, unordered
>     FailOverDomain2 -> includes node2 only, unrestricted, unordered
>     FailOverDomain3 -> includes node3 only, unrestricted, unordered
>     FailOverDomain4 -> includes node4 only, unrestricted, unordered
>
> Hi Marcos,
>
> From the Red Hat documentation:
>
> A failover domain is a named subset of cluster members that are
> eligible to run a cluster service in the event of a system failure. A
> failover domain can have the following characteristics:
>
>    *
>
>       Unrestricted — Allows you to specify that a subset of members
>       are preferred, but that a cluster service assigned to this
>       domain can run on any available member.
>
>    *
>
>       Restricted — Allows you to restrict the members that can run a
>       particular cluster service. If none of the members in a
>       restricted failover domain are available, the cluster service
>       cannot be started (either manually or by the cluster software).
>
>    *
>
>       Unordered — When a cluster service is assigned to an unordered
>       failover domain, the member on which the cluster service runs is
>       chosen from the available failover domain members with no
>       priority ordering.
>
>    *
>
>       Ordered — Allows you to specify a preference order among the
>       members of a failover domain. The member at the top of the list
>       is the most preferred, followed by the second member in the
>       list, and so on.
>
> By default, failover domains are unrestricted and unordered.
>
>
> Configure them as restricted
>
>
> Greetings,
>
> Juanra
>
>  
>
>
>
>     service1 is allocated to FailOverDomain1
>     service2 is allocated to FailOverDomain2
>     service3 is allocated to FailOverDomain3
>     service4 is allocated to FailOverDomain4
>
>     when I execute:
>     clusvcadm -e service1
>     clusvcadm -e service2
>     clusvcadm -e service3
>     clusvcadm -e service4
>
>     all the services start on the same node (the one where I executed the
>     above commands)
>
>     Shouldn't they start on the node in their respective failover domain?
>     Am I doing something wrong?
>
>     Thanks for the help.
>
>
>
>
>     --
>     Linux-cluster mailing list
>     Linux-cluster at redhat.com <mailto:Linux-cluster at redhat.com>
>     https://www.redhat.com/mailman/listinfo/linux-cluster
>
>
> ------------------------------------------------------------------------
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
Hi,
I based my configuration on the redhat documention:


          Preferred node or preferred member:

This is a notion which is no longer present in rgmanager. In older
versions, the preferred node was the member designated to run a given
service if the member is online. In most cases, it was used with the
"Relocate on Preferred Node Boot" service option (as it was generally
thought to be useless without!). *In newer rgmanagers, we can emulate
this behavior by specifying an unordered, unrestricted failover domain
of exactly one member.* There is no equivalent to the "Relocate on
Preferred Node Boot" option in Cluster Manager 1.0.x.

So it was supposed to work.
Or is the restricted option necessary in my case?

Greetings,
Marcos David


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20090203/592e2a32/attachment.htm>