Forum Discussion

Greg_Robinson_1's avatar
Apr 22, 2014
Solved

Best way to query for active member in cluster

We're creating a home brew automation tool for configuring the F5. We know that some objects (Self IPs, routes, etc) must be created on each member in a cluster; however, some objects such as floating IPs should be created once on the active member and replicated to the standby via configsync. My question is, what is the best REST API call to find the active member in a cluster? We'd like to write to the active member and allow auto config sync to replicate the shared configuration changes to the standby member(s). Also, if we push a configuration object to the active member, is it agreed that the best validation is to query each member to ensure the new object was replicated properly?

 

  • Auto config sync is only available for Sync-Only groups, so there is no concept of the 'active' device, and in addition this happens when a change is made to any group members

     

    For failover/sync groups I think you can manually initiate config-sync from any of the devices (doesn't have to be active).

     

13 Replies

  • Are you talking about a REST call to initiate config sync? Technically, if you use the floating self-IP, you should be talking to the active unit.

     

  • We are not running a floating self-IP on the HA interface. We're making REST calls to the management interface.

     

  • Auto config sync is only available for Sync-Only groups, so there is no concept of the 'active' device, and in addition this happens when a change is made to any group members

     

    For failover/sync groups I think you can manually initiate config-sync from any of the devices (doesn't have to be active).

     

    • Greg_Robinson_1's avatar
      Greg_Robinson_1
      Icon for Cirrus rankCirrus
      Are you sure about this? I have auto config-sync running on a failover-sync pair and I just tested configuration replication successfully.
    • nitass's avatar
      nitass
      Icon for Employee rankEmployee
      auto sync for sync-failover device group is introduced in 11.4.0.
  • Well, and in the absence of more sophisticated json parsing foo, the following can get you the state of the failover member:

    curl -sk -u admin:admin -H "Content-Type: application/json" -X GET https://x.x.x.x/mgmt/tm/cm/failover-status | egrep -o '"status":{"description":"\w+"}' | cut -d '"' -f 6
    
  • If you're using a single traffic-group, you can use this:

     

    curl -sk -u admin:admin -H "Content-Type: application/json" -X GET

     

    but if you are using multiple traffic groups, every cluster member will show active. Thus, it's better to query the traffic groups for the active member of that group alone:

     

    curl -sk -u admin:admin -H "Content-Type: application/json" -X GET

     

  • Those commands work on physical LTM's, but not on the management interface of an LTM provisioned in a Viprion. I am not sure if that was clear in my original post.

     

    Get this on physical box when I curl for failover status: {"kind":"tm:cm:failover-status:failover-statusstats","selfLink":"","entries":{"":{"nestedStats":{"entries":{"color":{"description":"green"},"":{"nestedStats":{"entries":{"":{"nestedStats":{"entries":{"details":{"description":"active for /Common/traffic-group-1"}}}}}}},"status":{"description":"ACTIVE"},"summary":{"description":"1/1 active"}}}}}}

     

    Get nothing on ltm provisioned on viprion when I curl for failover status or traffic group

     

  • I cannot help you here. I use VCMP on my Viprions so I don't know how LTM directly on Viprion hardware operates.

     

  • You should be able to make a REST call that correspond to this TMSH command:

     

    [root@localhost:/S1-green-P:Active:Standalone] config tmsh show sys cluster

     

    Sys::Cluster: default

    Address x.x.x.x/22 Availability available State enabled Reason Cluster Enabled Primary Slot ID 1 Primary Selection Time 08/26/15 16:17:36

     

    | Sys::Cluster Members | ID Address Availability State Licensed HA Clusterd Reason

     

    | 1 x.x.x.x available enabled true active running Run | 2 x.x.x.x available enabled true active running Run