After they almost were hit by a tornado (it's Oklahoma!) last year that caused a week without connectivity, one of our clients moved their web servers to a service with backup sites around the country. Because of the lightened load and to save money on their renewal, we recently downgraded the Cluster to Hot-Standby. At first, everything seemed fine, but they then began having the error where the Hot-Standby-Slave was handling, and thus blocking, some HTTP requests. However, as confirmed by the developers in Germany, the problem was not the same one discussed here: https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/p/44235/157235#157235 . We were the only ones in the world to experience this – aren’t we special! Rather than recount the last few days in detail, here's the solution: [LIST=1] Turn Clustering off. This should cause the Slave to do a factory-Reset and shut down; if not, disconnect all Ethernet cables and do it manually. Change to "Hot-Standby" mode in the Master node with 'Auto-Configure' selected, giving it a minute or two to digest the change. Reconnect the Slave node and power it up. The Master should find it, auto-configure it and start syncing. Until the syncing is complete and the next step has begun, half of the browsers will experience the blocking of their surf attempts.* After the Slave has been synced, force a fail-over by doing a shutdown of the Master node from WebAdmin. Disconnect the Ethernet cables from the now-off device, turn it on, perform a Factory-Reset and power it down again. Reconnect the Ethernet cables and power-up. Everything should be copacetic! [/LIST] Our solution was to do step 3 one evening and 4 the next day, but that may not be long enough for installations with large email quarantines and substantial logs. Since the only problem is with categorization, you might want to try temporarily removing all the category checking in ‘HTTP/S’ and disabling all of your profiles. If, in step 4, you see in the HTTP Live Log that this doesn’t solve the blocking problem, just power down the Slave until the end of the workday to restart step 4. Don’t forget to re-establish your category blocks and re-enable your profiles when finished! Please feel free to suggest corrections, and I will try to update the above. Cheers – Bob

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

Downgrading from Cluster to Hot-Standby mode

After they almost were hit by a tornado (it's Oklahoma!) last year that caused a week without connectivity, one of our clients moved their web servers to a service with backup sites around the country.

Because of the lightened load and to save money on their renewal, we recently downgraded the Cluster to Hot-Standby. At first, everything seemed fine, but they then began having the error where the Hot-Standby-Slave was handling, and thus blocking, some HTTP requests. However, as confirmed by the developers in Germany, the problem was not the same one discussed here: https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/p/44235/157235#157235. We were the only ones in the world to experience this – aren’t we special!

Rather than recount the last few days in detail, here's the solution:
[LIST=1]

Turn Clustering off. This should cause the Slave to do a factory-Reset and shut down; if not, disconnect all Ethernet cables and do it manually.
Change to "Hot-Standby" mode in the Master node with 'Auto-Configure' selected, giving it a minute or two to digest the change.
Reconnect the Slave node and power it up. The Master should find it, auto-configure it and start syncing. Until the syncing is complete and the next step has begun, half of the browsers will experience the blocking of their surf attempts.*
After the Slave has been synced, force a fail-over by doing a shutdown of the Master node from WebAdmin.
Disconnect the Ethernet cables from the now-off device, turn it on, perform a Factory-Reset and power it down again.
Reconnect the Ethernet cables and power-up. Everything should be copacetic!

[/LIST]

Our solution was to do step 3 one evening and 4 the next day, but that may not be long enough for installations with large email quarantines and substantial logs. Since the only problem is with categorization, you might want to try temporarily removing all the category checking in ‘HTTP/S’ and disabling all of your profiles. If, in step 4, you see in the HTTP Live Log that this doesn’t solve the blocking problem, just power down the Slave until the end of the workday to restart step 4. Don’t forget to re-establish your category blocks and re-enable your profiles when finished!

Please feel free to suggest corrections, and I will try to update the above.

Cheers – Bob

This thread was automatically locked due to age.