Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
EmilliXill
Explorer
Jump to solution

"Set cluster member admin up" doesn't work

Hello!

I have HA cluster (R80.40) and I want to change a Standby member to Active. But commands "set cluster member admin up" or "clusterXL_admin up" in expert mode don't work. Standby member remains the same (just "Member current state is STANDBY" in console). But "set cluster member admin down" on Active member works. I don't understand why it doesn't change the state using standard commands, is there some problem?

Please help me to figure it out. Thanks

0 Kudos
1 Solution

Accepted Solutions
Timothy_Hall
Champion
Champion

The clusterXL_admin up|down and equivalent  set cluster member admin up|down commands do not directly impact the state of the cluster, they create and clear a fake failure called "admin_down" that may cause a failover depending on the current state of the cluster and where the command was run.  Based on the exchange of CCP packets the cluster member in the best state (with the fewest failures) essentially "wins" and goes active. 

Here are some examples which assume that the default "maintain current active member" is set on the cluster object:

Member 1: Active

Member 2: Standby

Member 2: Runs clusterXL_admin down; clusterXL_admin up  

Result: No effect, Member 1 active

-----------

Member 1: Active

Member 2: Standby

Member 1: Runs clusterXL_admin down (failover to Member 2 occurs); clusterXL_admin up  

Result: Member 2 remains active

-----------

Member 1: Active

Member 2: Standby

Member 1: Runs clusterXL_admin down (failover to Member 2 who is now active)

Member 2: Runs clusterXL_admin down (no effect, both members have equal failure)

Result: Member 2 still active

Member 1:  Runs clusterXL_admin up (failover back to Member 1 who is now active)

Member 2: Runs clusterXL_admin up (no effect, neither member has a failure)

Result: Member 1 remains active

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

8 Replies
Timothy_Hall
Champion
Champion

The clusterXL_admin up|down and equivalent  set cluster member admin up|down commands do not directly impact the state of the cluster, they create and clear a fake failure called "admin_down" that may cause a failover depending on the current state of the cluster and where the command was run.  Based on the exchange of CCP packets the cluster member in the best state (with the fewest failures) essentially "wins" and goes active. 

Here are some examples which assume that the default "maintain current active member" is set on the cluster object:

Member 1: Active

Member 2: Standby

Member 2: Runs clusterXL_admin down; clusterXL_admin up  

Result: No effect, Member 1 active

-----------

Member 1: Active

Member 2: Standby

Member 1: Runs clusterXL_admin down (failover to Member 2 occurs); clusterXL_admin up  

Result: Member 2 remains active

-----------

Member 1: Active

Member 2: Standby

Member 1: Runs clusterXL_admin down (failover to Member 2 who is now active)

Member 2: Runs clusterXL_admin down (no effect, both members have equal failure)

Result: Member 2 still active

Member 1:  Runs clusterXL_admin up (failover back to Member 1 who is now active)

Member 2: Runs clusterXL_admin up (no effect, neither member has a failure)

Result: Member 1 remains active

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
EmilliXill
Explorer

Thank you! Does it mean that I can't change the state using the console (if it is needed for some reason not related to fault tolerance testing), and cluster members make their own decisions who is Active? 

Will "Increase Priority" button in Cluster properties have any effect?

0 Kudos
Oliver_Fink
Advisor
Advisor

You can change the active cluster member via SmartConsole when the cluster Mode ist "Primary Up" (In SmartConsole: "Switch to higher priority Cluster Member"). Then you can switch the priority of the cluster members and install policy.

I would suggest to stick with the clusterXL_admin command. This is more flexible and "Primary Up" cluster mode has a risk of cluster flapping if the primary node is not stable.

0 Kudos
(1)
Timothy_Hall
Champion
Champion

Agree with Oliver, use clusterXL_admin up|down (or set cluster member admin up|down) for administrative failovers.  One bonus of using this technique is that if you accidentally set both members to down an outage will not occur.  Doing a "Stop Member" from the old SmartView Monitor GUI is NOT the same thing (it actually runs a cphastop command under the hood), and if you accidentally stop all cluster members from the SmartView Monitor an outage will occur.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
the_rock
Legend
Legend

Never tested 3rd scenario, will give it a go at some point. Though, logically, I think it makes sense, since if you did admin down on active member, while other member is already down, status most likely should not change.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

As Tim has explained: "up" (local context) means a given node will participate as part of a cluster not that it will become active.

The rest is determined by the state/priority/cluster mode of all participating members. 

CCSM R77/R80/ELITE
0 Kudos
the_rock
Legend
Legend

Put it this way...in simple terms...

If you do clusterXL_admin down on current active member, if will fail over to other cluster member

If you then run clusterXL_admin up on same member (now showing as down), it will show as  backup, except in normal clustering state

Now, IF you do same process, but you have pre-empt mode enabled, then once firewall where you ran those commands comes back, it will be master again

By the way, I recommend @Timothy_Hall book, lots of fantastic things explained there, including clustering ;- )

0 Kudos
EmilliXill
Explorer

Thank you! I will take a look at this book 🙂

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events