The previous post we went through configuring HA between the two devices. In this post we'll look at how we can verify ConfigSync is working as expected. As noted on the very first post, I won't be convering failover or mirroring in this series.
Verification & Testing
At this point we should now have successfully setup an active/standby BIG-IP system as indicated by both devices showing as Online and In Sync.We can also confirm this on the CLI:
root@(ltm-1)(cfg-sync In Sync)(Standby)(/Common)(tmos)# show cm sync-status
-------------------------------------------------------------------------------------
CM::Sync Status
-------------------------------------------------------------------------------------
Color green
Status In Sync
Mode high-availability
Summary All devices in the device group are in sync
Details
ltm-2.lab.com: connected
LAB-SYNC-FAILOVER-GRP (In Sync): All devices in the device group are in sync
device_trust_group (In Sync): All devices in the device group are in sync
Now let's make a change on the active node and observe what happens. I'll create a dummy node object. Before I commit the change let's see what the status of the commit IDs are between the devices by using the run /cm watch-devicegroup-device command:
As soon as I create the object the Commit ID is incremented by 2 on the device I made the change.
root@(ltm-1)(cfg-synChanges Pending)(Standby)(/Common)(tmos)# run /cm sniff-updates
Listening for commit_id_update on -i internal:h port 6699 (^C to exit)
[09:43:05] ltm-2.lab.com (v11.6.0) -> LAB-SYNC-FAILOVER-GRP: UPDATE CID 46.0 (ltm-2.lab.com) at 09:43:05
At this point the system should tell us that changes are pending:
If we click the Changes Pending hyperlink and then perform the sync we can see that the Commit IDs are now back in sync between the devices:
[09:48:34] ltm-2.lab.com (v11.6.0) -> LAB-SYNC-FAILOVER-GRP: UPDATE CID 46.0 (ltm-2.lab.com) at 09:43:05 FORCE_SYNC
[09:48:34] 10.128.2.110:49090 -> LAB-SYNC-FAILOVER-GRP: SYNC_REQ CID 44.0 (ltm-2.lab.com) at 09:37:01
[09:48:35] ltm-1.lab.com (v11.6.0) -> LAB-SYNC-FAILOVER-GRP: UPDATE CID 46.0 (ltm-2.lab.com) at 09:43:05
If we go to Device Management ›› Overview, in the Devices section if we click Show Advanced View we can see some more useful information:
- CID Originator: The Commit ID originator displays the device that performed that last successful sync between the devices.
- CID Time: The Commit ID Time displays the most recent Commit ID time. This matches the output in the command above when the we first created the dummy node and clicked Create.
- Last Sync Time: Displays the time we initiated the ConfigSync. You'll see it matches the timestamp on the output just above the screenshot.
- Last Sync Type: Displays the last type of sync that was performed. If this is the first sync it will show as 'Manual Full Load'. If it is an incremental sync it will display 'Manual Incremental'. Note, it uses the word 'manual' because I have disabled Auto Sync.
- LSS Originator: This field displays the device that most recently performed a successful sync operation. Typically this will match the CID Originator.
- LSS Time: This field displays the most recent successful sync. Typically this will match the CID Time.
Apr 15 09:48:34 ltm-2 notice mcpd[6806]: 0107168c:5: Incremental sync complete: This system is updating the configuration on device group /Common/LAB-SYNC-FAILOVER-GRP device %cmi-mcpd-peer-/Common/ltm-1.lab.com from commit id { 44 6409145281621881942 /Common/ltm-2.lab.com } to commit id { 46 6409146844437164723 /Common/ltm-2.lab.com }.
At this point the new configuration should now be on both boxes.
Summary
High availability on a BIG-IP system is clearly a big topic as there are a number of different moving parts. If implemented properly and if you have a good understanding of the process it should make troubleshooting any issues a little easier.Thanks for reading.
No comments:
Post a Comment