This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG 252 Active/Active Up2Date 9.006 > 9.007 Took 2.5 hours

Hi guys,

Please review the timeline for a scheduled Up2Date that I did over the weekend. There seem to be a few things wrong with my installation that I want to get resolved before completing Up2Dates.

I have a pair of ASG 525 in Active/Active configuration. Starting version was 9.006 and AD SSO for web filtering was working properly. This was purely as Up2Date for the sake of keeping current.

All told, the update procedure took nearly 3 hours to complete, with almost all of the time being consumed by replication procedures. During the time that Node2 was the active node and Node1 was syncing users were unable to use AD-SSO for web browsing.

1) I'm sure that there is a fix for the AD-SSO not working when the primary machine in a cluster is down - isn't this something about the computer account for the ASG needing to be redone?

2) I'm sure that taking more than an hour for a sync process to run between a pair of ASG 525s is excessively long. How can I track this down?

In both cases, I've got support with Sophos, but I want to be armed with the proper information before opening up a ticket.

------------------

Fri 22:00  - Scheduled Up2Date begins.
"Node 2 changed state: ACTIVE -> UP2DATE"

Fri 22:04 - Up2Date on secondary node seems to have applied.
"Node 2 changed version! 9.006005 -> 9.007005"
"Node 2 upgraded to version 9.007005 successfully"
"Cluster up2date successful, initiating graceful takeover"
"Node 2 changed state: UP2DATE -> ACTIVE"

Fri 22:05 - Master node detects that secondary is online but at a higher version.
"Version conflict with Master 2! Initiating up2date process from version 9.006005 to 9.007005"
"--- Node is disabled ---"
"Starting local up2date process to version 9.007005"

Fri 22:08 - Master node reboots and sees the secondary node.
"Node 2 joined with version 9.007005"
"Node 2 changed state: DEAD -> ACTIVE"
"Node 2 changed mode: WORKER -> MASTER"
"Up2date successful!"
"Upgraded to master version successfully"

Fri 22:09 - Original Master node becomes a worker node in the cluster. Original secondary node is master.
"Slave is dead, taking over!"
"Switching to Slave mode"
slon_control[4027]: Set mode to SLAVE
slon_control[4027]: Slonik error, process exited with value 255
slon_control[4027]: Slonik error, process exited with value 255
slon_control[4027]: Starting replication from Node 2 to 1

Fri 22:59 - Node 2 seems still be sending the config back to node 1
"Deactivating sync process for config on node 1"

Fri 23:38 - Node 1 seems to finally have gotten the config replicated back to it and is ready to take over.
slon_control[7213]: Initial synchronization for node 1 finished!
"Deactivating sync process for database on node 1"
Initial synchronization finished!"
"Node 1 changed state: SYNCING -> ACTIVE"
"Preempt Slave 1, initiating graceful takeover!"

Fri 23:38 - Node 2 relinquishes master duties
"Node 2 changed mode: MASTER -> SLAVE"
"No active Master found, initiating graceful takeover!"
"Switching to Master mode"
"Another slave around!"
"Activating sync process for database on node 2"
"Node 2 changed mode: SLAVE -> WORKER"
slon_control[4027]: Starting controlled switchover from Node 2 to 1
Slonik error, process exited with value 255

Fri 23:38 - Node 2 starts syncing config back from node 1
"Node 2 changed state: ACTIVE -> SYNCING"
"Node 2 changed mode: WORKER -> SLAVE"

Sat 00:48 - Node 2 finally gets the config and comes up into active mode
slon_control[4027]: Initial synchronization for node 2 finished!
"Deactivating sync process for database on node 2"
"Initial synchronization finished!"
"Node 2 changed state: SYNCING -> ACTIVE"

----------------


This thread was automatically locked due to age.
Parents Reply Children
No Data