MDS Migration from R77.30 to R80.30 fresh install with HA

[Chamila]

Hi Support,

Apologies, if this is not the right place to post this query as this may be an architectural query along side the migration.

Our MDS Servers are in a HA pair per region and we have a requirement to migrate them one at the time to R80.30 code rather than both at the same time. Current set up is, we have 2 servers in the UK (UK Primary MDS and US Secondary MDS) and 2 in the US (US Primary and UK Secondary) and two existing domains, domain US and domain UK, nothing fancy. 

After migration, we will have one MDS server per region for a period of time before introducing HA at a later date, e.g both UK and US MDS servers will be hosted in a US data center.

Are there any gotchas we need to be aware of when we do this migration or any advice on this matter is highly appreciated.

 Thanks in advace

Chamila

[Tommy_Forrest]

Here's my recommendation.

Get VMWare Workstation.  Stand up your MDSes with 77.30 and take an export of your production boxes and import them into your VMWare MDSes and test the upgrade there.

Whether you do an in place upgrade or a migrate/export/import upgrade to a fresh install, test, test and test some more.

In our case, when we went from 77.30 to 80.10 we had a large number of issues that required us to engage pro services to work through the issues.  In our instance, we had a dedicated environment for 77.30 and 80.10.

Engage your SE's, use them as resources to help you get it done.

While I can appreciate your management team's fear of doing one MDS at a time (I've been known to do 1 gateway one week and another gateway the next week), I wouldn't advocate you actually doing that to your management platform.

Here's why -

If your upgraded MDS fails, and you're not taking daily backups, you're going to be in a world of hurt.  I guess if you want to implement a change freeze, you could get around that until your backup is upgraded.  That wouldn't fly at my rock quarry.

This is where VMWare Workstation can also come in handy.  You can use it to test your upgrade path, and you can use it to test your roll-back path should something fail with the upgrade.

If you can demonstrate that you can take a fresh install of 77.30 and import the database, and bring the environment back from the brink, then there's exactly zero reason to not do the backup MDS in the same change window.

When I took us from 80.10 to 80.30, I exported the database and took the time to validate not only the export was valid, but the mds_backup was valid as well.  This added about 3 and a half hours of work to my change window.  But I'd set it for 7am until 11pm and still went into the next day.

If you take nothing else, test your migration thoroughly.  And when you're done testing it, wipe everything out and do it again.  Make sure you validate checksums of your data (md5sum in Gaia expert and Hashtab for Windows).  Keep your export/backups in 3 or 4 places while you're doing the upgrade.

[mdjmcnally]

As already said, prepare, test, do this multiple times so that happy that

A) migration process understood and documented fully is different for R80 compared to R77.x

B) demonstrate roll back just in case

The other thing to be aware of is is that you don't upgrade Secondary MDS boxes at R77.x level.

Instead you deploy a new one and then sync the Primary to the New.

[Tommy_Forrest]

I don't agree with deploying a fresh backup MDS and allowing it to sync to primary as a practice.  While you can do it, I don't think you should.

In my 80.10->80.30 upgrade, I did a migrate/export/import on the backup MDS and it worked great.  Plus it dramatically reduced sync times and I didn't have to dink around with re-SIC-ing the box or messing with any configuration changes on the primary MDS.

This method is what is prescribed in the 80.30 admin upgrade guide.

https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Installation_and_Upgrade_Gui...

On another note, don't forget to SCP into the MDS and snag a copy of your /home/admin directory while you're in there poking around.

[mdjmcnally]

And if you read my post then will see that specifically state that when upgrading R77,x.

R80.10 to R80.30 is DIFFERENT to R77.x to R80.30 as R80.10 upwards you can indeed do an upgrade on an R80.10 Secondary or HA MDS.   However you shouldn't do so on R77.30 which is where the this installation is at.

Hence my comment about R77.x and not upgrading the Secondary MDS.

[Tommy_Forrest]

The admin guide I posted covers upgrade to 80.30 from 80.20 and lower, including 77.30.

The recommended upgrade path from that guide is migrate/export/import.  Not a new install and re-syncing.

[Chamila]

Thank you all for you efforts and time in replying to my query. definitely you've shared some valuable points that I must consider before the migration.

I will keep you posted with the results at a later date.

Thanks again.

Chamila

[Maarten_Sjouw]

I completely agree with @mdjmcnally as a migration from an R77.30 to R80.x is really a different cookie from any R80.x to R80.x migration. When you go from R77.x to R80.x you are converting a flat file structure to a complete database structure for all configuration. While when moving from R80.x to R80.x is just moving and updating the database itself.

And that is really not waht you wanna do with a backup MDS from R77.x A major upgrade like this is certainly best done by deleting the HA, then do the migration.

What I do not see in the TA post is what their servers are running on, when they are VM's, like I expect, this is the easiest way to do the migration with the easiest roll back possible:

1. Build a new VM and instal R80.30 on it, do not run the FTW yet!!
2. On the original Primary MDS cleanup the HA
3. On the original Primary MDS mount the ISO of R80.30
4. Run the mds_setup and run the pre-migration verifier
5. When all is ok run the mds_setup again and run the export, which does an mdsstop
6. run mdsconfig and disable autostart of the CP product
7. now change the IP of the Primary MDS to a free IP in the same network
8. change the IP on the newly installed VM to the original IP of the Primary MDS
9. run the FTW (First Time Wizard)
10. copy the export file from the original Primary MDS
11. Import the file 
    1. keep in mind this will take multiple hours
12. Once it is done with the import go into each and every CMA and push policy at least 2 times 
    1. We have seen multiple problems when you don't, VPN's dying and not coming back before the second push
    2. Proxy arp's disapearing and coming back only after multiple pushes.

When you need to roll back this is very simple, you shutdown the newly installed machine and revert the IP on the original MDS and mdsstart, also reset the autostart in mdsconfig.