Migrate HA-SMS (VSX) R80.40 to R81.x

[bluecross]

Hello,

we'd like to upgrade our HA-SMS (Smart-1) for our VSX gateways from R80.40 to R81.x.
As it's an installation with some history (installed in 2019 with R80.20) and also some minor issues, we're looking for a clean installation without loosing our config or recent logs.

We're having some issues with the size of postgresql on the standby server (size about 5times larger than on active server) that's why TAC recommended a new installation of standby member to R81.10 Take109 and install a wrapper script before syncing/switching with active member.
In our lab this action plan didn't work, so while working further on that case with tac, we wonder if there is an alternative way to fix that issue without upgrading to R81.10 in the same step.
Maybe some other user already had a similar issue and knows some details about similar problems with different postgresql sizes on active and standby member?

Thanks for any feedback!

[Bob_Zimmerman]

Management HA has two major concepts: primary/secondary, and active/standby. They're separate. Use the command 'cpprod_util FwIsPrimary' to confirm which management is primary and which is secondary.

Is the big database on the primary or a secondary? The primary management is the only one which matters. All secondary managements just get wiped, and they get a new copy of the management database from the primary.

[bluecross]

Hi,
sorry for the confusion. In our case primary and active are currently the same. So the problem (big database) is on the secondary, which is working as standby.
In the meantime TAC also confirmed that the secondary is unusable and should be installed again.
Nevertheless, we'll need to install the provided fix for the database independently of the upgrade of the SMS.

Remaining questions: Can there be any issues regarding VSX during or after the upgrade of the SMS (apart from unavailability of the management during the update)?

[Bob_Zimmerman · Accepted solution]

It's not exactly confusion. I point this out because I wouldn't bother fixing problems on a secondary management server. You don't upgrade secondary managements, you wipe them clean and rebuild them. You would be installing a fix which only applies to your old version on a system you're about to wipe to no longer run that old version. May as well skip ahead to the wipe and save yourself hours to days of time.

With your management server down, you won't be able to make changes to VSs' interfaces or static routes. You also won't be able to make any policy changes on any firewalls. If your management server is your log server, your firewalls will log locally for the duration of the management outage.

[Lesley]

Sounds like a bug in R80.40:

PRJ-41890, PRHF-25534

Security Management

High Availability synchronization fails if automatic purge is configured to run on the Standby Management Server.

PRJ-42304, PRHF-25869

Security Management

UPDATE: Improved the "Purge revisions" operation to reduce the size of the database.

PRJ-27121, PMTR-70628

Security Management

UPDATE: The "Purge revisions" operation has been improved to reduce the database's size.

Would recommend before you export / update to fix the stand-by unit.