HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

cluster Redhat parameter question

 
tatty
Occasional Contributor

cluster Redhat parameter question

Hi,

 

i have a redhat cluster with a failover domain configured in this way:

                        <failoverdomain name="SERVICE" nofailback="1" ordered="1" restricted="0">
                                <failoverdomainnode name="node1-priv" priority="2"/>
                                <failoverdomainnode name="node2-priv" priority="1"/>
                        </failoverdomain>

 

as you can see there are both parameter: nofailback and ordered.

 

So this configuration can generated some conflicts? the no failback option setted to "1" means that the resource in that failover domain can't return on the previus node after a failover.

 

The ordered  parameter setted to "1" means that there are a preferred server for the resource.

 

but i don't know if these parameters can live together.

 

Regards,

Stefano Peccenini

1 REPLY
Matti_Kurkela
Honored Contributor

Re: cluster Redhat parameter question

Yes, the "nofailback=1" and "ordered=1" options can live together. There is no conflict.

 

  • "ordered=1" means the cluster will use the node priority values on the failoverdomainnode lines whenever it needs to determine where to failover/failback a service to.
  •  With "nofailback=1", when a service that uses this failover doman has failed over from node2-priv to node1-priv, the cluster won't automatically move the service back to node2-priv as soon as it is functional again. The service would stay on node1-priv until commanded to move, or until node1-priv fails. If node2-priv had failed and then been fixed, and then node1-priv failed while the service was running on it, the service would automatically failover to the highest-priority available node, i.e. node2-priv.
  • The "restricted=0" option means that if you add a third node to your cluster (e.g. node3-priv), the service would be allowed to failover to it if and only if both node1-priv and node2-priv had failed. With "restricted=1", the service would be restricted to node1-priv or node2-priv only: it would never failover to node3-priv.

The "nofailback=1" setting can be useful if your service takes a long time to start up and you get an intermittent fault (e.g. a network problem) on node2-priv. With "nofailback=0", the service would move back and forth between the nodes, spending most of its time either starting up or shutting down instead of staying on the failover node and doing useful work there. "nofailback=1" makes the service keep running on node1-priv (unless it fails too) until someone can diagnose and fix the problem and verify that it stays fixed.

 

 

 

MK