First step - migrate old instance to new one
-
Double-click on the new
OnePart installer.
-
Select the install directory for the new instance (for example,
e:\projects\mig\OPnew ).
-
Do not check
Unzip Only.
-
Check
Migration.
-
Give the path to old instance's
datadir. Be careful not confuse with old install
dir (for example,
e:\projects\mig\OPold\datadir ).
-
Give the path to the licence file. This field can eventually
left empty, that leads to use old instance's license file (for example, leave
this field empty).
-
Give the new instance name. As expected in a classic
installation (non-migration), this name must not be already used in the list of
windows services (for example,
OPnew ).
-
Give the instance's
hostname as usual, default value is probably
the best value, see
OnePart install if needed (for example, we keep the default value
determined by installer).
-
Define the window account if needed (for example, check
The localSystem account).
-
Define the new instance's
baseport. It is important to understand that
both instances old and new will be up at the same time, so choose another port
range than old instance's one, and do not forget any
OnePart instance port range spreads from its baseport
to baseport+99 (for example, 20000).
-
Do not check any of the following check boxes, or change port
base yet, until you know exactly what you're doing. Those features give access
to post-migration tools that will described in the following steps. It is
possible to invoke them all at once but we encourage using them in a second
time.
-
Click
install.
When the installer stops, the new
OnePart instance is installed based on the
configuration of the old one. This means the new instance is up on its own
port, and its configuration inherited from the old one. Some configuration
files are patched by the migration to ensure their compatibility from the old
version to the new one (AppsSecurity, supported connectors, custom
configuration). Everything else, including new features, new data model,
plugins, etc... even storage were installed and configured by migration in the
new instance. Accounts, including admin, are also inherited from the old
instance. So the new
OnePart is fully functional, exactly as was the old
OnePart, but on a different port, and without any data
in its index.
Note:
Some configuration modifications, and certain connectors are
not supported by migration. Therefore, you may need to manually change the
customization or connectors to make them compatible with the new
OnePart version. We recommend that you make these
changes now and test them.
Second step - populate index with data
At this stage, two options are available to get data into the
new
OnePart instance:
- You can switch to the
console (either
OnePart's or
Exalead CloudView's) and do a scan of every connector (this includes
non-supported connectors by migration). As we already said in the foreword, if
a lot of part are due to be converted by XCV, that will probably last for a
very long time. During that time, new instance will not be available with all
its data. When finished, this procedure provides a fully functional with
completely up-to-date data instance, ready to replace old one.
- In case you have to scan a
huge amount of data, and need a quickly available instance filled with those
data, you can use Data migration feature. This feature will copy old instance's
Consolidation Server storage to new instance. Then it will apply a "force
aggregation" that will push the Consolidation Server's content "as it is" into
the new index. This procedure by-passes XCV conversion, then we will quickly
import old data into new instance. But, as we said in the foreword, this data
is not up-to-date with new signatures and eventual new metas. This could lead
to some malfunctions depending on the versions of old and new instances. If
this method is used, it is possible some features using signatures could behave
slightly differently as expected. It is mandatory to check afterwards, if new
OnePart behavior is acceptable. Once the data migration is completed,
it is your decision to use new
OnePart as a production instance (even if side effects may occur), or
as a beta version. It is also still possible to clean the index completely and
use the above option (classic scan).
-
Click on
post-install shortcut in
Windows start menu / Dassault Systemes OnePart /
Tools
-
Choose the new
OnePart installation dir (example:
e:\projects\mig\OPnew ).
-
Skip view about Window account which is disabled.
-
Check
Migrate-data.
-
Click
install.
Third step - update migrated data
If you performed a "data migration" instead of a classical
scan on the connectors, the new
OnePart instance displays data that is not up-to-date with XCV
conversion, and whose signatures can potentially produce buggy behavior. Thus,
you need to update data doing
Force rescan.
Force rescan will update data, using connectors
(only supported ones), which means XCV conversions will be done and the new
instance's index will be updated. Note while this operation is in progress,
OnePart will still be available. As data migration is designed for huge
indexes which are very long to reload from scratch, the force rescan will be a
very long process. During this period of time, data will still be available in
OnePart.
Note:
This operation enables a specific PAPI filter designed specially
for data migration purpose and force rescan.
-
Click on
post-install shortcut in
Windows start menu / Dassault Systemes OnePart /
Tools
-
Choose the new
OnePart installation dir (example:
e:\projects\mig\OPnew ).
-
Skip view about Window account which is disabled.
-
Check
Force rescan.
-
Click
install.
-
When rescan is finished you must manually disable
Data Migration PAPI filter in the
Exalead CloudView
Administration Console.
- Go to
Connectors > OnePartPAPIFilters > Data
Migration and disable the option
Enable this PushAPI filter.
Note:
When the tool ends the Force rescan begins, however, this
rescan will probably last for a long time. To check if rescan is still going,
go to the
Administration Console and verify that the connectors are no longer scanning. Once
the scan is finished it must be disabled.
Fourth step - go to production
Anytime you decide to go to production and replace the old
OnePart instance by new one. You must follow the procedure below.
-
Stop old instance by any means you wish.
-
Update the new instance's storage with the old one. This is done
using post-migration tools as we saw above and checking
Migrate storage.
-
Change baseport of new instance. This can also be done by
editing the post-migration
Change port base.
|