CPUSE upgrade of MDSM

[Vincent_Bacher]

Hello community,

i am researching for best practices for inline upgrade of a multi domain security management, especially from R77.* to R80.10.

In R80.10 installation and upgrade guide this way is mentioned but not explained.

Is there any thread, sk or how-to which I did not find yet?

Any hint is welcome.

Cheers

Vincent

[AlekseiShelepov]

Maybe you have some more specific questions on the difficulties that you see?

I think that most of things are covered in:

• Installation and Upgrade Guide R80.10 - Upgrading a High Availability Deployment
• Installation and Upgrade Guide R80.10 - Pre-Upgrade Verification and Tools
• Installation and Upgrade Guide R80.10 - Multi-Domain Server High Availability
• Installation and Upgrade Guide R80.10 - Upgrading Multi-Domain Servers and Domain Management Servers
• Installation and Upgrade Guide R80.10 - Updating Objects in the Domain Management Server Databases
• Installation and Upgrade Guide R80.10 - Managing Domain Management Servers During the Upgrade Process
• Installation and Upgrade Guide R80.10 - Upgrading Multi-Domain Security Management with CPUSE
• Installation and Upgrade Guide R80.10 - Installing and Upgrading with CPUSE
• CPUSE - Gaia Deployment Agent - sk92449

Create a snapshot (and all other backups) before upgrade. Use Pre-Upgrade Verifier and fix all listed issues before starting upgrade.

Bonus:

is there an easy way to upgrade large-scale environments to R80.10? 

One recommended approach is to use the gradual Multi-Domain upgrades.

TechTalk: Migrate to R80.10 and New Years Toast

[Vincent_Bacher]

Just wanted to know how cpuse upgrade works.

Is everything done automatically?

The reason why I ask is that there are no step by step guides. Or I found nothing.

[Kaspars_Zibarts]

Indeed, it's fully automatic. Just press button in GAIA webui

Just make sure that you have solid backup/snapshot to roll back to as our R80 to R80.10 stuffed up in CPUSE and automatically generated snapshot rollback didn't not work correctly. But it was not R77.x and surely things have improved since last year august.

If that's an option then lab in VM is always your friend

[Vincent_Bacher]

Great. Thanks a lot.

Backup is no problem as we have an ESX based installation.

[Maarten_Sjouw]

Vincent, do make sure to shutdown the MDSM before you make the VW Shapshot. You might run into weird problems if you don't. I have been warned for this on multiple occasions by TAC already.

Currently I run a 3 MDS R77.30 setup with around 150 domains and I will be planning to move this setup to R80.20 in 1 go with CPUSE as well. It's going to be a lot of work checking everything, but a lot less work than moving the domains 1 by 1. Taking into account that we also have a lot of VSX systems that are used through different domains, it adds a lot complexity for the manual upgrade as well. 

[Jason_Carrillo]

Kaspars, do you know if the snapshot is automatic in R80.10 (edit) before a CPUSE upgrade? I have a snapshot on my MDS that says that it was stored on the date I did the upgrade but has a "Created by" date is back in December for some reason. Is that normal? Do I have a bad snapshot?

[Tomer_Noy]

CPUSE upgrades work like this:

1) Create a new partition

2) Clean install the new version (so you get a fresh file system without any leftovers)

3) Copy over the previous configuration and upgrade it

The previous partition is automatically kept as a snapshot, so you can easily revert on crisis. A small "quirk" is that the date of the snapshot is the creation date of the partition and not the date that it was converted into a snapshot. This does not mean that it is corrupt.

Also note that HF / Jumbo installations are not upgrades and are installed onto the existing partition. This means that you can uninstall them and keep all configuration changes since the installation time. On the other hand, you don't have an automatic snapshot.

In the past, minor upgrades worked like HFs and were installed directly into the existing partition. After much deliberation, we decided that the major upgrade mechanism is more robust and useful, so minor upgrades (such as R80.10 => R80.20) also use the new partition mechanism.

Hope this technical background was helpful and also explains why R80 => R80.10 did not automatically have a CPUSE snapshot.

[Petr_Hantak]

Thanks for explanation. Actually automatic snapshot during the procedure was something what I was missing. I know the best practice is to take a snapshot before and also export it out from device just for sure.

On the other hand I know guys who don't care about snapshot creation at all until whole upgrade procedure went wrong and they waste a lot of toime on recovery. Automatic snapshot could save them for sure.

[PhoneBoy]

While you can do the whole MDM in one fell swoop with CPUSE, that has a much wider impact than doing it a Domain at a time.

Consequentially, this is how a lot of the larger multi-domain customers do it.

[Tomer_Noy]

Thanks Dameon

We actually have a mix of customers choosing CPUSE "in-place" upgrade versus others using domain-by-domain upgrades.

The domain-by-domain approach is helpful to try out the new version on some domains before deciding to move the entire estate. Also, it was helpful when some domains could not be upgraded due to previous limitations such as missing LSM or GVC in R80.10 (now available in R80.20).

However, an in-place CPUSE upgrade is much simpler to perform and doesn't require another HW or VM.

Either way, it's always a good idea to use the Upgrade Verification Service in advance to see if there are any verifications that need to be resolved.

[biskit]

Useful thread, thanks.  I'm doing an R77.30 > R80.20 MDSM upgrade tomorrow, in place using CPUSE.

I've sorted out a few issues from pre-upgrade verifier.  I'm loving the HTML report in /opt/CPInstLog 😁

Now all I'm mostly left with is

The first one comes up on most (but not all) domains.  The thing is, none of the domains have had their crypt.def file modified.

What method or criteria does PUV use to decide whether to throw up this warning or not?  I don't get why it warns for some domains and not others, when none have ever been manually altered?

The second one - I've checked and these services aren't used in any domain.  I presume it's safe to just ignore this message and let the upgrade delete the services automatically?

I also get this on just two of the domains.  Not sure what it's getting at, but IPS isn't currently enabled on those domains anyway so I'm going to ignore this and see what happens.