MDS migration to new machine

[fjulianom]

Hi guys,

My customer wants to upgrade the MDS to latest version (from R81.10 to R81.20), and because in the past it had several issues and some fixes, he wants to start with a new clean machine. I have been reviewing and I think the best approach is "Upgrade with migration", which means to do a R81.20 fresh-install in an new machine, and then migrate the database from the old MDS to the new MDS. The process is explaine here. It seems quite simple, but:

1. What about this step

My new MDS will have the same IP of the old MDS. Do I need a new license? If not, how can I export the current license to the new MDS?

2. In the last steps I will turn off the old MDS and turn on the new MDS (both are VMs):

Is that simple? No SIC problems or anything else?

3. I see the process quite simple, and with Check Point always there are surprises. Anything else to consider? All is migrated? Log Exporter, licenses, etc.

Any tip will be highly appreciated.

Regards,

Julián

[PhoneBoy]

If the IP of the new system is the same, then you do not need a new license.
You also do not need to re-establish SIC.

Not sure if the Log Exporter configuration is included in migrate_server output if it was configured in the CLI (versus in SmartConsole).

[emmap]

Log exporter config from CLI is included in the migration but should be reviewed and tested as part of step 10.

Otherwise yes it really is that simple.

[fjulianom]

Hi,

Then the process of licensing is automatic because the license is bound to the IP adress in SmartUpdate and the IP is the same?

Regards,

Julián

[PhoneBoy]

The existing license is included in the migrate_server export output.
Since the IP of the new server is the same, that license will still be valid.
If the IP were different, you would have to generate new licenses, possibly with the help of Account Services.

[Amir_Senn]

In my honest opinion I think you should try to convince them to use CPUSE anyway. If there's no specific reason to perform clean install, CPUSE is the best way to upgrade MDS. If they encountered issues in the past we need to rebuild their confidence in CPUSE upgrade. Doing the advance upgrade migration will not necessarily avoid issues, it all depends on what the issue is. Worst case scenario we have ways to revert back quickly and efficiently.

If they insist on advanced upgrade I have a few more pointers:

a. Make sure to use the -x flag - it will take significantly more time depends on the amount of logs and indexes but you definitely want to keep them.

b. Make sure to cancel/prolong timeout on your SSH session before export/import

[fjulianom]

Hi guys,

Thank you very much for your replies. About these points:

a. Make sure to use the -x flag - it will take significantly more time depends on the amount of logs and indexes but you definitely want to keep them.

      a1. --> One issue the MDS has now is with logs and indexes. If the indexes are bad and you export them... is not a good idea to export logs without indexes and then in the new machine index them? What will the process be for indexing them? Will it be to run command with -l option and after follow sk111766? Do I need to remove FetchedFiles?

      a2. --> According to this post there is also the possibility of copying all log files to an external storage, do the migrate without logs, and then when the new server is running, copy log files to and index them. Is this the previous point? I mean, run command "migrate_server" with -l option and after that index the logs.

b. Make sure to cancel/prolong timeout on your SSH session before export/import --> What is this for?

Regards,

Julián

[Amir_Senn]

a1. If you have an issue with indexes it might be the indexer itself or something in the query process, not with indexes themselves. You can try using dr-log to debug. Anyway, you can definitely export logs only with -l flag and re-index them with the SK you suggested.

a2. It is possible but there's more room for error if you're no well acquainted with this. I suggest using dedicated tool for migration to do it.

b. If you're using SSH to reach the server and you're doing import it may take some time. During this time you will probably won't touch anything so the session could theoretically timeout. The operation will continue but you won't be able to see status, respond to request to start the processes and might miss errors that will happen during import. Use TMOUT=0 .

[fjulianom]

Hi guys,

One more doubt about this. Section "Prerequisites for Upgrading and Migrating of Management Servers and Log Servers" indicates: "For Advanced Upgrade or MigrationClosed procedure, the hard disk on the Management Server or Log Server must be at minimum 5 times the size of the exported database."

How can I know the size of the database I will export?

Regards,

Julián

[Tal_Paz-Fridman]

You can perform the export "just to see" the final file size.

This does not even need to be related to the "overall" migration process you are planning - just to see that the export is successful and for the file size. Obviously it's recommended to run it again as close to the actual migration as possible. 

[fjulianom]

Hi guys,

One more doubt about this please. When you do a migration with command "migrate_server export/import" from R81.10 to R81.20, what part of Gaia configuration do you migrate? Hostname, IP, log exporter, NTP, authentication servers, etc.? From tests I realized IP is not migrated, but hostname is. Log exporter before R81.20 was not included in the migration process, but from R81.20 on is. But I am not clear about all the Gaia sections are migrated.

Regards,

Julián

[PhoneBoy]

None of the underlying Gaia OS configuration is migrated with migrate_server, only the Security Management configuration.
This will need to be migrated a different way (from Gaia CLI: save configuration xxx)

[fjulianom]

Hi,

Great, I will migrate Gaia configuration with save configuration and load configuration. Thanks.

Regards,

Julián