migrate_server instead of migrate export/import

[Carsten_R]

Dear all,

When the management server is running R80.20 or higher, and you'd like to upgrade to a higher version, you'd propably done that is the past with database script "migrate export".

Now, a new script is in place, and it is a different way to do the export/import as in the past.

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

I have already walked through the process, but still have some questions, perhaps someone is able to provide some answers.

1. hugh diffecence in filesize
   • a migrate export on my R80.20 server with the old tool to the same version (R80.20) results in a filesize of 1,7GB.
   • export with the new tool to version R80.40 results in a filesize of ~350MB (without logs/indexes) - wow, that's a lot much less. After the import, I saw, that any database revisions are gone. Is this the reason?
2. slow import process
   • I've used the upgrade tool, build version 993000252 (sk135172) 
   • it took round about 1 hour to import the database. I have the feeling, that the script is slower than the old method. But what Im missing, is a progress bar or anything else. However, no logfile was written (/var/log/opt/CPshrd-R80.40/migrate*). . A liitle more conversation would be good.

The server is running on HP DL360 Gen8, 16 Cores, 48 GB RAM.

[PhoneBoy]

I believe that may be one of the things we do in migrate export is not take every revision, which can definitely reduce file size of the export.

One benefit of the new migrate_server tool is that we can update it independently of a regular maintain release. @Eran_Habad showed me a video of an improvement coming to the CLI version that will show some progress when doing the upgrade.

There is also an interactive upgrade report in the Gaia WebUI that updates as the upgrade is going on.

[Itai_Minuhin]

Hi,

Please note that not only that the name of the script was changed from migrate to migrate_server, but the entire management upgrade mechanism is new. Some of the benefits of the new upgrade mechanism can be found in this post.

Indeed the export file is smaller, there are two main reasons for that. First, only the latest revision is being upgraded and not the entire database as before. In future versions we may change that and allow upgrade of several revisions. Also, migrate export takes all data files from the database, while migrate_server introduced an optimization and takes only the required part of the data.   

Regarding to the upgrade process, we have plans to reduce the upgrade time in upcoming versions. A new HTML report was introduced, it shows the progress and status of the upgrade. The upgrade report helps us to get visibility for what took the major time, and improve. If you agree to share with us the report we could also learn from it.

Regarding upgrade logs, from R80.40 the new upgrade mechanism collects all upgrade logs by default. Once upgrade process is finished, either successfully or with a failure, all upgrade logs (including the HTML report) are being stored in the management server under /var/log/.

• /var/log/upgrade-export.<time stamp>.tgz
• /var/log/upgrade-import.<time stamp>.tgz

Indeed one of the great benefits of the new upgrade mechanism is the updatable upgrade tools package, which allows faster delivery of fixes and enhancements, independently from regular maintain release. Soon we will introduce an improved UI to the advanced upgrade (via CLI), it will be released as part of the updatable upgrade tools package. A video is attached.

Thanks,

Itai

[PhoneBoy]

FYI, I edited your post to add the video inline.

[genisis__]

Can you please confirm how to use this command and exclude the logs and then index files.  When I ran this command it took three days to finish which is not practical.

In a MDS environment we almost need a two step approach.  Step 1 would be to migrate the the main database quickly into a R81 server; step 2, a secondary process to then important the close logs files; which would need to be re-indexed somehow.

I do have a TAC case open, so lets see what the feed back is.

[PhoneBoy]

Precisely which command?
migrate_server does not get logs by default, as far as I know.
You can copy the log files over separately and force a reindex.

[Itai_Minuhin]

Correct, migrate_server does not migrate logs by default. 

To migrate logs run migrate_server with '-l', to index run with '-x',  

[genisis__]

Just attempted to run the migrate_server command on on my Secondary MDS but the verification has failed; I assume that there should be no reason why this should not work?

Here's the message I received when running the verify.

 # $MDS_FWDIR/scripts/migrate_server verify -skip_upgrade_tools_check -v R81
Verification failed:
1. Upgrade operation is not supported in current configuration. Make sure that Global Domain Management Server is in active state and primary and try again.

The above suggests the 'migrate_server' command cannot be used on a secondary MDS.

[genisis__]

Believe I found the problem, looks like the MDS though it was active rather then standby.

cpprod_util FwIsActiveManagement !! View current status; 1 is Active, 0 is Standby
Status reported was 1 when it should be 0

cpprod_util FwSetActiveManagement 0

# $MDS_FWDIR/scripts/migrate_server verify -skip_upgrade_tools_check -v R81
The verify operation finished successfully.

[genisis__]

I suspect the command provided included -l which would explain allot.  I will rerun with no parameter (as per the video).

You also mentioned force re-index, is this done automatically (perhaps after a reboot or stopping/starting services) or is there a specific command to run per CMA or at a MDS level?

Is it possible to watch the upgrade_report-<xxxxx>.html report in real-time?

[Ido_Shoshana]

Hi,

Can you please elaborate on the log file size and the machine HW (CPU, memory, etc)?

Also, Can you specify the task ID? I would like to follow.

Thanks in advance,

Ido S.

(SmartEvent and Logging team)

[Ido_Shoshana]

Second try 🙂

Thanks in advance,

Ido S.

(SmartEvent and Logging team)

[genisis__]

Just attempted to migrate a R80.30 SMS to R81 (VM LAB).  Using the latest migration tool I found that the R81 tools for some reason is not exporting the data correct, at least this is what I think.

The migrate tool produced a file size of 60MB when using R81 as the target version.

On the LAB running the verify all succeeds, but the FWM process terminates when the process hits 4% (which just sits their).  If you do a find / -name migration_had_failed   notice this file was created which implies the migration process had failed and this is why the FWM process terminated (delete this file and then cprestart).

I have engaged TAC on this but still waiting on some real feed back from them (been over 24hrs).

In the mean time I followed the same process for R80.40 and this just worked!  The conclusion here is the migration tool used for R81 is not correctly exporting the data from the SMS.  File size on the exported file was 208MB.

[PhoneBoy]

Are you doing this with migrate export or migrate_server? 

[genisis__]

migrate_server.

TAC have not even started to look at this yet, but will pass Itai the Ticket reference.

[Itai_Minuhin]

Hi, 

'migration_had_failed' file is being created in case upgrade fails. The purpose is to make sure users will not start working on the system which wasn't upgrade successfully.  (this is  done by keeping FWM down). You should not remove migration_had_failed file manually and start the server.

On the next upgrade attempt the upgrade code will remove this file automatically.  

I will be happy to check the failed upgrade to R81. 

Lets take it offline - please email me the upgrade logs and SR #.

Best regards, 

Itai

[genisis__]

Itai - can you ping me your email please.  TAC have just asked me for the export file that I uploaded to the sftp on Sunday at the engineers request! (On Sunday).

[Itai_Minuhin]

Sure, its itaim@checkpoint.com

[genisis__]

Thanks - pinged you an email.

[genisis__]

Itai - not really seen any viable response from TAC yet,  pinged you an email again to see if the CFG task was actually being progressed.  I have noted that the R81 migrate tool has been updated today, will try this to see if the tool has been fixed.