<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 04/11/2012 04:31 PM, Parvez Shaikh wrote: <blockquote cite="mid:CAKrd5325z7NoA=T1bAYmnXomKv0cPOhRGCD_F_Bt1--J2nfshg@mail.gmail.com" type="cite">cluster.conf file - <blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">.... <failoverdomains> <failoverdomain name="my_domain" nofailback="1" ordered="1" restricted="1"> <failoverdomainnode name="my_blade2.my_domain" priority="2"/> <failoverdomainnode name="my_blade1.my_domain" priority="1"/> </failoverdomain> </failoverdomains> </blockquote> </blockquote> You have an "ordered" failoverdomain and you have priorities on your nodes. According to the setting above, your preferred node is "my_blade1.my_domain". That means that if the service is running on "my_blade2" (2nd-preferred) and "my_blade1" (1st-preferred) transitions to available, the service will relocate back onto that node. More info is available on: man 8 clurgmgrd: --- ordered domain : The order specified in the configuration dictates the order of preference of members within the domain. The highest-ranking member of the domain will run the service whenever it is online. This means that if member A has a higher rank than member B, the service will migrate to A if it was running on B if A transitions from offline to online. --- You can stop this behavior by either disabling "ordered" for the "my_domain" failover domain or by giving both nodes the same priority in their failover domain entries. However, you also seem to have "nofailback=1" set, which should prevent the behavior you describe. Again from "man 8 clurgmgrd": --- nofailback : Enabling this option for an ordered failover domain will prevent automated fail-back after a more-preferred node rejoins the cluster. Consequently, nofailback requires an ordered domain in order to be meaning-ful. When nofailback is used, the following two behaviors should be noted: * If a subset of cluster nodes forms a quorum, the node with the highest priority in the failover domain is selected to run a service bound to the domain. After this point, a higher priority member joining the cluster will not trigger a relocation. * When a service is running outside of its unrestricted failover domain and a cluster member boots which is a part of the service’s failover domain, the service will relocate to that member. That is, nofailback does not prevent transitions from outside of a failover domain to inside a failover domain. After this point, a higher priority member joining the cluster will not trigger a relocation. --- The second point does not apply to your configuration because both nodes are in the failover domain. Can we see some message logs of an event when the service fails over? Ryan Mitchell Red Hat Global Support Services </body> </html>