- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: "Set cluster member admin up" doesn't work
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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
- Labels:
-
ClusterXL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ;- )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you! I will take a look at this book 🙂
