manager upgrade from r81.10 to r81.20

[Luis_Miguel_Mig]

I am planning to upgrade the firewall manager from r81.10 to r81.20.

Cpuse doesn't list r81.20 though. I can see different  r81.10 hot fixes but I can see any r81.20 package. Why would it happen? 
I have another firewall manager vm in the lab running r81.10 and I can see the list of r81.20 packages in cpuse.

[Bob_Zimmerman]

Again, a secondary management only becomes active if you log in to it with SmartConsole and explicitly tell it "The primary is dead. Become active." It's a four or five step process. As long as you don't do that, it will remain standby, and it will keep the data it had when it was last synchronized. Just don't go out of your way to intentionally tell both managements to become active, and this won't be a problem.

[the_rock]

@Luis_Miguel_Mig 

To ad on top of what @Bob_Zimmerman said, because I see still so many people get confused about it, so I will stress this out, in case its not clear.

-primary server will ALWAYS be primary

-secondary will ALWAYS be secondary (unless rebuilt)

-either one can be active or standby, so primary can be either active or standby and secondary can be either active OR standby

Andy

[Luis_Miguel_Mig]

It makes sense to make the secondary active before starting the process of upgrading the primary.
And it also makes sense to make the primary active after the upgrade for testing.
So it makes sense that management HA behaves like clusterXL in that sense (like Andy mentioned) to enforce that only one of them can be active at a given time.

[the_rock]

You got it.

[Bob_Zimmerman]

That doesn't make sense at all, no. A management upgrade only takes a few hours. Making the secondary active in that window is asking for trouble. Unless you have a really good reason (like if the upgrade fails and you decide to roll back), you absolutely should not make a secondary management active while upgrading the primary.

What goal are you trying to accomplish by making the secondary management active before you start upgrading the primary?

[the_rock]

Well, it can work sort of like clusterxl upgrade. If you leave status as is, its fine, but I know people who flip back and forth during the upgrade, thats fine too. I had done mgmt HA and clusterXL upgrades both ways, never had a problem.

Andy

[Luis_Miguel_Mig]

I think it make sense to get secondary active a few days before running the firewall manager upgrade. It is just good practice in general, you isolate the device were you are making changes and you test than the secondary is good.

However that is why I am asking here. If management HA doesn't handle well two managers running two major version and this operation is considered risky I will for sure make sure than the secondary is not active when I perform this change.

[emmap]

Assuming the primary is currently active, the secondary will not go active unless you log into it and make it active - don't do this unless you have to roll back.

Take an export of the primary using the migrate_server command per the upgrade guide. 

(optional) Test the import of this file in fresh R81.20 VM

Rebuild the primary to a fresh install of R81.20

Install recommended JHF onto primary

Import DB into primary

Make sure it all works (SIC is good, policies install, you get logs, all that), for however long you want. HA will fail so nothing you change will sync to secondary. The secondary won't be affected by this failing so you don't have to do anything about it.

Then if it's all good, fresh install the secondary, install same JHF and re-SIC it to primary.

[PhoneBoy]

That sounds accurate to me.

[JP_Rex]

The Problem with this update are the traffic logs.

How attached are you to these?

Regards

Peter

[Luis_Miguel_Mig]

Not an issue, we export logs to ELK.